Acceso para equipos: Identity Center y federación

Una empresa de 200 personas con 15 cuentas de AWS no puede crear 3.000 usuarios de IAM. Ya tiene un lugar donde viven sus empleados: Microsoft Entra ID, Okta, Google Workspace o un Active Directory. Lo sensato es que AWS confíe en ese lugar en vez de duplicarlo. Eso es la federación de identidades.

Federación: SAML y OIDC

El proveedor de identidad (IdP) es el sistema que autentica a las personas. AWS no ve su contraseña: recibe una afirmación firmada que dice «esta es Ana, del grupo Finanzas» y, a partir de eso, le entrega credenciales temporales de un rol.

• SAML 2.0: el estándar clásico de las empresas para inicio de sesión único (SSO) con directorios corporativos.
• OpenID Connect (OIDC): el estándar moderno basado en OAuth 2.0. Lo usan proveedores web y también sistemas de CI/CD, como GitHub Actions, para obtener un rol sin guardar llaves.

IAM Identity Center: un portal para todas las cuentas

AWS IAM Identity Center (antes AWS SSO) es la forma recomendada de dar acceso a personas. La gente entra una vez a un portal y ve las cuentas y los niveles de acceso que le tocan.

1. 1

   Conecta la fuente de identidades

   Usa el directorio propio de Identity Center, un Active Directory o un IdP externo por SAML. Usuarios y grupos se pueden sincronizar con SCIM.
2. 2

   Define conjuntos de permisos

   Un permission set es una plantilla de permisos, como «SoloLectura» o «Desarrollador». Identity Center la convierte en un rol dentro de cada cuenta donde la asignes.
3. 3

   Asigna grupo + cuenta + permiso

   Por ejemplo: grupo Desarrolladores → cuentas de desarrollo → «Desarrollador»; y en producción → «SoloLectura».
4. 4

   La persona entra por el portal

   Elige cuenta y rol, y obtiene credenciales temporales para la consola o la CLI. Al salir de la empresa, la desactivas en un solo lugar.

Roles entre cuentas

A veces una identidad de la cuenta A necesita trabajar en la cuenta B: un equipo de seguridad que audita, o un pipeline que despliega. En B se crea un rol con una política de confianza que nombra a A como principal. Desde A, la identidad llama a sts:AssumeRole y recibe credenciales temporales de B.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Esta política de confianza, en la cuenta B, permite que la cuenta 111111111111 asuma el rol. Además, en A, la identidad necesita permiso para sts:AssumeRole sobre ese rol. Hacen falta las dos mitades: B confía y A autoriza. Lo que el rol puede hacer dentro de B lo dicen sus políticas de permisos.

Amazon Cognito: los usuarios de tus aplicaciones

Todo lo anterior es para tu equipo. Los clientes de tu app (miles o millones de personas que se registran en tu tienda en línea) no deben vivir en IAM. Para ellos está Amazon Cognito.

• 

  Cognito user pools

  Un directorio para tu app: registro, inicio de sesión, recuperación de contraseña, MFA e inicio con Google, Apple o Facebook, o con un IdP corporativo.
• 

  Cognito identity pools

  Cambia la identidad de un usuario de tu app por credenciales temporales de AWS, para que su teléfono suba una foto a S3 directamente con permisos limitados.
• 

  AWS IAM Identity Center

  El portal de empleados

  Acceso de tu personal a varias cuentas de AWS y a aplicaciones empresariales, con conjuntos de permisos.
• 

  AWS Directory Service

  El directorio corporativo en la nube

  Un Microsoft Active Directory administrado por AWS (AWS Managed Microsoft AD) o un puente hacia el AD que ya tienes (AD Connector). Útil para cargas Windows y como fuente de Identity Center.