La gestión de identidades en entornos enterprise con cientos de cuentas AWS requiere federación centralizada. IAM Identity Center, Cross-Account Roles y los distintos mecanismos de federación son temas de peso en el SAP-C02.
Contenido
IAM Identity Center es el servicio recomendado para gestionar acceso centralizado a múltiples cuentas AWS y aplicaciones SaaS desde un único punto. Reemplaza la gestión manual de IAM users en cada cuenta.
Es el sucesor de AWS Single Sign-On (SSO). En el examen SAP-C02 sigue apareciendo como "AWS SSO" en algunas preguntas.
Identity Sources soportadas
Identity Center Directory
Directorio integrado de Identity Center. Para empresas sin IdP propio. Gestión directa de usuarios y grupos.
Active Directory (AD)
Conecta con AWS Managed AD o AD on-premises via AD Connector. Sincroniza usuarios y grupos.
External IdP (SAML 2.0)
Conecta con Okta, Azure AD, PingFederate, etc. Identity Center actúa como SP (Service Provider).
Flujo de autenticación
Usuario accede al portal de Identity Center
Identity Center autentica contra el Identity Source configurado
Usuario selecciona cuenta AWS y Permission Set
Identity Center asume el rol IAM correspondiente via STS
Usuario obtiene credenciales temporales (AssumeRoleWithSAML)
El mecanismo de Cross-Account Access permite que un principal (usuario, rol, servicio) en una cuenta Cuenta-A asuma un rol en una Cuenta-B mediante STS AssumeRole.
| Elemento | Dónde se configura | Qué hace |
|---|---|---|
| Trust Policy del rol | Cuenta-B (donde está el rol) | Define quién puede asumir el rol (Principal: cuenta-A, usuario, rol) |
| Permissions Policy del rol | Cuenta-B (donde está el rol) | Define qué puede hacer el rol una vez asumido en cuenta-B |
| sts:AssumeRole permission | Cuenta-A (donde está el caller) | IAM policy que permite al principal llamar a sts:AssumeRole |
| ExternalId (opcional) | Trust Policy del rol en Cuenta-B | Previene el Confused Deputy Problem cuando terceros asumen el rol |
Confused Deputy Problem
Cuando un servicio de terceros tiene permiso de asumir un rol en tu cuenta, un actor malicioso podría hacer que ese servicio asuma tu rol. Solución: ExternalId — un secreto que solo tú y el tercero conocen, requerido en la Trust Policy. Sin el ExternalId correcto, el AssumeRole falla.
SAML 2.0 — federación para empleados
Para empresas con Active Directory o IdP corporativo (Okta, ADFS). Los usuarios se autentican contra el IdP y reciben una aserción SAML que AWS STS canjea por credenciales temporales.
OIDC — federación para aplicaciones web/móvil
Para aplicaciones que usan Google, Facebook, Cognito, GitHub, etc. como Identity Provider. El usuario se autentica con el IdP OIDC y recibe un ID token que AWS STS canjea por credenciales.
| Servicio | Tipo | AD propio requerido | Mejor para |
|---|---|---|---|
| AWS Managed Microsoft AD | AD completo en AWS (managed) | No — AWS crea y gestiona | Empresas que migran a AWS y necesitan un AD en la nube. Soporta trust con AD on-premises. |
| AD Connector | Proxy a AD on-premises | Sí — el AD on-premises debe existir | Redirigir autenticación a AD existente sin sincronizar usuarios. Sin caché local. |
| Simple AD | AD compatible (Samba 4) | No — AWS crea Samba 4 | Organizaciones pequeñas. No soporta trust con AD real, sin MFA, sin RDS SQL Server. |
AD Connector vs Managed AD — clave del examen
Si el escenario dice "mantener el AD on-premises como fuente de verdad y no querer sincronizar usuarios a AWS" → AD Connector. Si dice "necesitan un AD completo en AWS con trust a on-premises" → Managed Microsoft AD.
Los Permission Sets son plantillas de permisos que IAM Identity Center despliega como roles IAM en cada cuenta. Permiten gestionar el acceso de cientos de cuentas desde un punto central sin modificar roles individualmente.
Características de Permission Sets
Ejemplo de estructura en una org
Trampa: "IAM Identity Center crea IAM Users en cada cuenta"
Realidad: FALSO. Identity Center gestiona acceso temporal vía roles IAM. No crea ni sincroniza IAM users en las cuentas miembro.
Trampa: "AD Connector sincroniza usuarios de on-premises a AWS"
Realidad: FALSO. AD Connector es solo un proxy — redirige solicitudes de autenticación al AD on-premises sin almacenar usuarios ni contraseñas en AWS.
Trampa: "AssumeRoleWithSAML crea credenciales permanentes"
Realidad: FALSO. STS siempre genera credenciales temporales (access key + secret key + session token). Máximo 12 horas con MaxSessionDuration.
Trampa: "Permission Sets son roles IAM en Identity Center"
Realidad: Son templates. Los roles IAM reales se crean en cada cuenta miembro cuando se asigna el Permission Set.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa usa Active Directory on-premises como fuente de verdad de identidades. Tienen 300 cuentas AWS y quieren que sus empleados accedan a las cuentas correctas usando sus credenciales corporativas AD sin crear IAM users en cada cuenta. ¿Cuál es la solución más apropiada y escalable?
Inicia sesión para llevar tu progreso.