Cómo utilizo Microsoft Entra ID, SAML, SCIM e IAM Identity Center para dar acceso a cuentas AWS sin distribuir credenciales permanentes.
En el primer artículo de esta serie expliqué la idea general de la arquitectura: utilizar Microsoft Entra ID como origen central de identidad para laboratorios con Azure, AWS y Google Cloud, manteniendo la autorización dentro de cada proveedor.
En AWS esto plantea una cuestión interesante.
Si las identidades están en Entra ID, ¿cómo permitimos que un alumno entre en una cuenta AWS, utilice la consola, abra CloudShell y trabaje con Terraform sin crearle un IAM User ni entregarle Access Keys?
La respuesta, en mi caso, es AWS IAM Identity Center.
La arquitectura que describo está basada en un entorno real que utilizo para algunos laboratorios de formación, pero nombres, dominios, identificadores, cuentas y demás información operativa se han anonimizado o simplificado deliberadamente.
Figura 1. Flujo simplificado de identidad y autorización entre Microsoft Entra ID y AWS.
El objetivo: que el usuario no exista como IAM User
Durante mucho tiempo, uno de los patrones más habituales para dar acceso programático a AWS consistía en crear un IAM User y generar:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEYEn un laboratorio esto resulta especialmente incómodo.
Hay que distribuir las claves, almacenarlas en algún sitio, evitar que terminen en un repositorio y, al finalizar el curso, acordarse de revocarlas.
En este entorno quería eliminar completamente esa necesidad.
El modelo buscado era:
Microsoft Entra ID
↓
AWS IAM Identity Center
↓
AWS Account
↓
Console / CloudShell
↓
TerraformEl participante mantiene su identidad en Entra ID.
No existe un IAM User equivalente dentro de cada cuenta AWS.
Lo que IAM Identity Center termina aprovisionando en las cuentas son roles IAM asociados a los Permission Sets, no usuarios IAM individuales. Documentación de AWS
IAM Identity Center como punto de unión
AWS IAM Identity Center es el componente que conecta las identidades corporativas con las cuentas de AWS.
En este caso, Microsoft Entra ID se configura como proveedor de identidad externo.
Pero hay dos problemas diferentes que resolver:
- ¿Cómo demuestra el usuario quién es?
- ¿Cómo sabe AWS qué usuarios y grupos existen?
Para resolverlos se utilizan dos estándares distintos:
SAML 2.0 → autenticación
SCIM 2.0 → aprovisionamiento de usuarios y grupos
Esta distinción es probablemente la parte más importante de toda la integración.
SAML responde: «¿Quién eres?»
Cuando un participante necesita acceder a AWS, la autenticación real se realiza en Microsoft Entra ID.
Usuario
↓
Microsoft Entra ID
↓
SAML assertion
↓
AWS IAM Identity Center
↓
AWS Access PortalAWS confía en Entra ID como Identity Provider.
Por tanto, AWS no necesita almacenar ni validar la contraseña del alumno.
Esto también significa que podemos seguir utilizando en Entra ID los controles de autenticación que correspondan: MFA, Conditional Access u otras políticas que puedan existir en el entorno.
Pero SAML por sí solo no resuelve todo el problema.
SCIM responde: «¿Qué usuarios y grupos existen?»
IAM Identity Center necesita conocer previamente los usuarios y grupos a los que posteriormente se les van a conceder permisos.
Para eso utilizamos SCIM — System for Cross-domain Identity Management.
Microsoft Entra ID
│
│ SCIM
▼
AWS IAM Identity Center
Users
Groups
MembershipsAWS documenta la combinación de SAML y SCIM para utilizar Microsoft Entra ID como proveedor externo de IAM Identity Center. Documentación de AWS
En Entra ID utilizo además un principio que considero importante: no sincronizar indiscriminadamente todo el directorio.
Solo deben llegar al entorno de formación los usuarios y grupos que realmente lo necesitan.
Training-Students
Student-01
Student-02
Student-03
...y aprovisionar únicamente esos objetos hacia IAM Identity Center.
Esto hace que el directorio de AWS represente solo la población que debe poder utilizar esas cuentas.
Aprovisionar una identidad no le concede permisos
Otro concepto que a veces genera confusión es que aparecer en IAM Identity Center no significa tener acceso automáticamente a AWS.
El usuario puede existir. El grupo puede existir. Pero todavía debemos definir qué puede hacer.
Ahí aparecen los Permission Sets.
Grupo
↓
Permission Set
↓
AWS AccountPor ejemplo:
Student-01
↓
Lab-Administrator
↓
AWS Account 01El usuario perteneciente a Student-01 podrá entonces utilizar el Permission Set asignado sobre esa cuenta.
IAM Identity Center crea los roles IAM necesarios en las cuentas donde el Permission Set está provisionado. Documentación de AWS
Esta separación es muy útil porque identidad y permisos evolucionan independientemente.
Cambiar al alumno no requiere rediseñar las políticas AWS. Normalmente basta con cambiar la membresía del grupo.
¿Permisos administrativos para un alumno?
Aquí hay una decisión de diseño específica del escenario de formación.
Dentro de determinados laboratorios, los participantes necesitan bastante libertad: crear redes, máquinas, buckets, policies, roles y otros recursos.
Por eso puede tener sentido utilizar un Permission Set con privilegios elevados.
En un entorno empresarial normal probablemente sería una mala idea.
En un laboratorio cambia el contexto porque cada participante trabaja en una cuenta AWS dedicada y existen controles superiores mediante AWS Organizations.
Permission Set
permisos amplios
│
▼
AWS Account aislada
│
▼
Service Control Policies
│
▼
Máximo realmente permitidoUna SCP puede, por ejemplo, impedir determinados servicios, regiones o tipos de recurso independientemente de que el usuario tenga permisos administrativos dentro de la cuenta.
Es una arquitectura que utilizo bastante en formación: libertad dentro del sandbox, límites fuera de él.
No intento construir un IAM extremadamente restrictivo para cada práctica. Prefiero proporcionar autonomía en la cuenta de laboratorio y utilizar guardrails organizativos para impedir aquello que no debe hacerse.
El otro guardrail: el tiempo
Los Permission Sets tienen otra propiedad especialmente interesante: Session duration.
AWS permite configurar cuánto tiempo puede permanecer activa la sesión asociada a un Permission Set. El valor predeterminado es una hora y AWS permite configurarlo entre una y doce horas. Documentación de AWS
En los laboratorios utilizo sesiones cortas.
Quién puede entrar → Entra ID
Dónde puede entrar → IAM Identity Center
Qué puede hacer → Permission Set + SCP
Durante cuánto tiempo → Session DurationY este último punto terminó siendo más importante de lo que inicialmente parecía.
Volveremos sobre ello al hablar del cierre de sesiones y de qué ocurre cuando una identidad es deshabilitada en Entra ID mientras todavía tiene credenciales AWS válidas.
AWS CloudShell elimina otro problema
Una vez que el alumno ha accedido a la cuenta AWS, todavía queda otra cuestión: ¿cómo utiliza AWS CLI o Terraform?
Podríamos configurar AWS CLI localmente mediante IAM Identity Center. AWS soporta este modelo y puede obtener y renovar automáticamente credenciales temporales utilizando aws configure sso. Documentación de AWS
Pero para los laboratorios hay una opción todavía más cómoda: AWS CloudShell.
CloudShell es una shell basada en navegador y previamente autenticada. Cuando se abre desde AWS Management Console, las credenciales utilizadas por la sesión de consola están disponibles automáticamente dentro de la shell. Documentación de AWS
Entra ID
↓
IAM Identity Center
↓
AWS Console
↓
CloudShellsin ejecutar aws configure y, sobre todo, sin introducir Access Key ni Secret Access Key.
Y entonces aparece Terraform
En los laboratorios utilizamos Terraform desde CloudShell.
Login con Entra ID
↓
Seleccionar cuenta AWS
↓
Abrir CloudShell
↓
terraform init
terraform plan
terraform applyTerraform puede utilizar las credenciales temporales que ya están disponibles en la sesión.
Por tanto, el alumno no necesita un fichero ~/.aws/credentials con claves permanentes creadas específicamente para él.
Esto resuelve dos problemas simultáneamente: reduce la configuración necesaria para comenzar un laboratorio y evita distribuir secretos de larga duración que después tendrían que localizarse y revocarse.
La cadena de confianza completa
Microsoft Entra ID
│
┌───────────┴───────────┐
│ │
SAML SCIM
│ │
│ Users + Groups
└───────────┬───────────┘
▼
AWS IAM Identity Center
│
Group mapping
│
▼
Permission Set
│
▼
AWS Account
│
┌─────────┴─────────┐
▼ ▼
AWS Console AWS CloudShell
│
▼
TerraformHay varios controles superpuestos, pero cada uno tiene una función distinta.
Entra ID controla la identidad.
SAML proporciona la federación de autenticación.
SCIM mantiene usuarios y grupos.
IAM Identity Center conecta grupos, cuentas y Permission Sets.
Las políticas IAM determinan permisos dentro de la cuenta.
AWS Organizations puede establecer límites superiores mediante SCPs.
La duración de sesión limita temporalmente las credenciales emitidas.
La arquitectura parece más compleja que crear un IAM User y generar dos claves. Lo es. Pero también elimina una cantidad considerable de deuda de seguridad.
El alta y la baja se vuelven mucho más sencillas
El valor de este modelo se aprecia especialmente en los extremos del ciclo de vida.
Para dar acceso a un nuevo participante no necesito entrar en varias cuentas AWS creando IAM Users. Trabajo con la identidad y los grupos.
Y cuando termina la formación, puedo:
Deshabilitar identidad en Entra ID
↓
Revocar sesiones
↓
Retirar asignaciones de IAM Identity Center
↓
Limpiar la cuenta de laboratorioLa cuenta AWS puede reutilizarse posteriormente para otra edición del curso. La identidad que accede a ella puede ser completamente distinta.
Y no queda una colección de Access Keys personales que haya que rastrear posteriormente.
Pero hay una sorpresa importante
Deshabilitar al usuario en Entra ID no implica necesariamente que una sesión AWS previamente emitida desaparezca inmediatamente.
La identidad, la sesión de IAM Identity Center y las credenciales temporales asociadas a un rol tienen ciclos de vida relacionados, pero no idénticos.
Precisamente durante las pruebas del entorno comprobamos que este detalle tiene implicaciones importantes para la respuesta ante incidentes y para un proceso de offboarding realmente efectivo.
Pero merece su propio artículo.
Qué me llevo de esta arquitectura
Si tuviera que resumir el diseño en una sola idea, no sería «hemos implementado SSO».
El usuario necesita una identidad, no unas Access Keys.
La federación permite mantener la identidad en el sistema corporativo.
IAM Identity Center traduce esa identidad al modelo de acceso de AWS.
Los Permission Sets proporcionan permisos. AWS Organizations establece guardrails. CloudShell proporciona un entorno de trabajo ya autenticado. Y Terraform puede funcionar utilizando credenciales temporales asociadas a esa sesión.
Para un laboratorio multicloud es una combinación especialmente cómoda.
Pero los mismos principios son aplicables a muchos entornos reales: identidades centralizadas, acceso federado, credenciales temporales y autorización nativa de cada plataforma.
Próximo artículo
En la siguiente entrada veremos la otra mitad de la arquitectura:
Entra ID + Google Cloud: federación, Cloud Identity y SAML
Veremos por qué aparece Cloud Identity, cómo se provisionan usuarios y grupos desde Entra ID, qué papel desempeña SAML y cómo esos grupos terminan recibiendo permisos sobre proyectos de Google Cloud.
Referencias
AWS — Microsoft Entra ID + AWS IAM Identity Center
Documentación oficial de AWS
AWS — Permission Sets en IAM Identity Center
Documentación oficial de AWS
AWS — Duración de sesiones de Permission Sets
Documentación oficial de AWS
AWS — Credenciales de IAM Identity Center para CLI y SDK
Documentación oficial de AWS
AWS — CloudShell e IAM
Documentación oficial de AWS
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.
Francisco Sepúlveda
Instructor de Cloud Computing y Ciberseguridad, Diseñador de Experiencias Formativas
Instructor y consultor en Cloud Computing, Ciberseguridad e IA, con más de 25 años de experiencia en entornos empresariales reales. Diseño e imparto programas de formación técnica combinando experiencia profunda en la materia con diseño de experiencias formativas, para que los conceptos complejos de seguridad realmente se queden. Comparto análisis técnico aplicado en Cloud Security in Practice.
Conoce más →