Cómo utilizo Microsoft Entra ID como origen central de identidad en laboratorios con Azure, AWS y Google Cloud.
Cuando preparo laboratorios multicloud para algunos de mis cursos aparece muy pronto un problema que no tiene que ver con desplegar máquinas virtuales, redes o almacenamiento: cómo gestionar las identidades de los participantes de forma sencilla, segura y sostenible.
Podría crear una identidad independiente en Azure, otra en AWS y otra en Google Cloud. Funcionaría, pero multiplicaría la administración y complicaría especialmente el alta, la baja y la revocación de acceso cuando termina una formación.
Por eso, en algunos de mis laboratorios utilizo otro enfoque: Microsoft Entra ID actúa como origen central de identidad para las tres plataformas.
El objetivo puede resumirse en una frase:
Una persona, una identidad, tres nubes.
La arquitectura que describo en este artículo está basada en un entorno real de formación, pero los nombres, dominios, identificadores de cuentas, proyectos y demás datos operativos se han simplificado o anonimizado deliberadamente.
Figura 1. Arquitectura simplificada y anonimizada utilizada en los laboratorios multicloud.
Una identidad común no significa un IAM común
Hay una distinción importante que conviene hacer desde el principio.
Centralizar la identidad no significa sustituir los sistemas de autorización de Azure, AWS o Google Cloud.
En este diseño, Microsoft Entra ID responde principalmente a una pregunta:
¿Quién es este usuario?
Después, cada proveedor sigue respondiendo de forma independiente a otra:
¿Qué puede hacer este usuario en mi plataforma?
Esta separación entre autenticación y autorización es una de las características que más me gustan de la arquitectura.
Azure continúa utilizando Azure RBAC, AWS mantiene IAM Identity Center, Permission Sets y sus políticas, y Google Cloud sigue utilizando su propio IAM.
Microsoft Entra ID proporciona el punto común de identidad, pero cada cloud conserva su modelo de seguridad nativo.
Azure: la integración más directa
Azure es el caso más sencillo porque utiliza directamente las identidades de Microsoft Entra ID.
Los participantes pueden autenticarse con la misma identidad que utilizamos como referencia para todo el entorno, mientras que Azure RBAC determina posteriormente qué recursos pueden administrar.
Azure RBAC permite asignar roles a usuarios o grupos sobre un ámbito concreto, como una suscripción, un Resource Group o un recurso individual. Microsoft Learn
En un laboratorio puede utilizarse, por ejemplo, un modelo como este:
Usuario
↓
Grupo
↓
Azure RBAC
↓
Resource Group del laboratorioDe esta forma, un participante puede disponer de bastante autonomía dentro de su entorno sin recibir privilegios administrativos sobre Microsoft Entra ID ni sobre los recursos asignados a otros usuarios.
Es una distinción importante: dar libertad dentro de un sandbox no significa dar privilegios sobre toda la plataforma.
AWS: federación mediante IAM Identity Center
AWS requiere un intermediario adicional: AWS IAM Identity Center.
En lugar de crear IAM Users para cada participante, Microsoft Entra ID se configura como proveedor de identidad externo.
La integración utiliza dos protocolos diferentes:
SAML 2.0 para autenticación.
SCIM 2.0 para aprovisionar y sincronizar usuarios y grupos.
AWS documenta específicamente la integración de Microsoft Entra ID con IAM Identity Center mediante ambos mecanismos. Documentación de AWS
Conceptualmente:
Microsoft Entra ID
│
├── SAML → autenticación
│
└── SCIM → usuarios y grupos
│
▼
AWS IAM Identity Center
│
▼
Permission Sets
│
▼
AWS AccountLa diferencia entre SAML y SCIM es relevante.
SAML permite que AWS confíe en Entra ID cuando un usuario inicia sesión, pero no proporciona un mecanismo para descubrir automáticamente qué usuarios y grupos existen en el proveedor de identidad. Para eso se utiliza SCIM. Documentación de AWS
Una vez dentro de AWS, la autorización vuelve a ser responsabilidad de AWS.
IAM Identity Center asigna Permission Sets a usuarios o grupos sobre cuentas concretas, y controles superiores como las Service Control Policies de AWS Organizations siguen aplicándose con independencia de la identidad utilizada para iniciar sesión.
En próximos artículos entraré con bastante más detalle en esta parte.
Google Cloud: Entra ID y Cloud Identity
Google Cloud utiliza un modelo diferente.
En este caso utilizo Cloud Identity para mantener la representación de los usuarios y grupos dentro del ecosistema Google, mientras Microsoft Entra ID continúa siendo el origen de identidad y el sistema utilizado para la autenticación.
Google documenta precisamente este patrón: los usuarios y grupos pueden aprovisionarse desde Entra ID hacia Cloud Identity y la autenticación puede delegarse posteriormente a Entra ID mediante SAML. Google Cloud Documentation
El flujo simplificado sería:
Microsoft Entra ID
│
├── Provisioning
▼
Cloud Identity
│
└── Usuarios y grupos
│
▼
Google Cloud IAM
│
▼
ProyectoProvisioning y autenticación son dos procesos distintos.
Una cosa es que un usuario exista dentro de Cloud Identity y pueda ser referenciado por Google Cloud IAM.
Otra es quién valida sus credenciales cuando intenta iniciar sesión.
En esta arquitectura, esa autenticación se delega en Microsoft Entra ID mediante SAML. Google Cloud Documentation
De nuevo, la autorización permanece en manos del proveedor cloud.
Los grupos pueden recibir roles sobre proyectos concretos sin que Entra ID tenga que conocer los detalles internos del modelo IAM de Google Cloud.
Cloud Shell cambia bastante el diseño
Hay otra decisión que simplifica mucho este tipo de entorno: utilizar las Cloud Shell de cada proveedor.
El participante entra desde el navegador utilizando su identidad federada y, desde ahí, puede trabajar con las herramientas de línea de comandos de la plataforma.
El flujo es aproximadamente:
Microsoft Entra ID
↓
Proveedor cloud
↓
Cloud Shell
↓
TerraformEsto tiene una consecuencia de seguridad especialmente interesante: no es necesario repartir credenciales estáticas entre los participantes.
En AWS evitamos crear Access Keys para IAM Users.
En Google Cloud no necesitamos entregar ficheros con claves privadas de Service Accounts.
Y en Azure podemos trabajar directamente con la identidad utilizada para abrir la sesión.
AWS, además, documenta que los desarrolladores pueden iniciar sesión con sus identidades existentes y utilizar credenciales temporales generadas automáticamente para el acceso desde CLI. Documentación de AWS
Para un entorno de formación esto resulta especialmente cómodo: menos configuración en los equipos de los alumnos y muchos menos secretos que controlar posteriormente.
El verdadero beneficio no es tener una sola contraseña
El Single Sign-On es probablemente la parte más visible de la arquitectura.
Pero no creo que sea la más importante.
La ventaja principal es centralizar el ciclo de vida de la identidad.
Cuando comienza una formación puedo habilitar las identidades necesarias y asignarlas a los grupos correspondientes.
Durante el curso, cada plataforma aplica sus propios permisos.
Y cuando termina, puedo bloquear el acceso desde el origen de identidad y retirar las asignaciones existentes en los proveedores cloud.
El modelo queda aproximadamente así:
Microsoft Entra ID
Identidad
Autenticación
Ciclo de vida
↓
Azure AWS Google Cloud
Azure RBAC IAM Identity Cloud IAM
CenterLa experiencia para el usuario es sencilla.
La arquitectura de seguridad que hay detrás no tiene por qué serlo.
Y eso es algo positivo.
Hay una trampa: identidad y sesión no son lo mismo
Durante las pruebas de esta arquitectura apareció además un comportamiento especialmente interesante.
Deshabilitar un usuario en Microsoft Entra ID no significa necesariamente que todas las sesiones que ya había obtenido en las plataformas cloud desaparezcan en ese mismo instante.
Las credenciales temporales, tokens y sesiones emitidos previamente pueden tener su propio periodo de validez.
Eso obliga a pensar también en duración de sesiones, revocación de tokens y procedimientos de finalización del acceso.
Es un tema suficientemente interesante como para tratarlo por separado, porque permite entender muy bien la diferencia entre:
identidad, autenticación, autorización y sesión.
Volveré sobre ello más adelante en esta serie.
Una arquitectura para laboratorios, no una receta universal
Conviene remarcar que este diseño responde a un caso de uso concreto: laboratorios de formación multicloud en los que cada participante necesita bastante autonomía dentro de un entorno controlado.
Una organización podría necesitar controles adicionales: privilegio mínimo mucho más granular, Privileged Identity Management, Conditional Access, procesos Just-In-Time, aprobaciones, políticas más restrictivas o controles específicos de compliance.
Pero el principio arquitectónico sigue siendo perfectamente válido:
Centralizar la identidad no obliga a centralizar la autorización.
Microsoft Entra ID puede proporcionar una identidad común mientras cada proveedor conserva sus mecanismos nativos de control de acceso.
El resultado, desde el punto de vista del participante, parece muy sencillo:
una identidad para Azure, AWS y Google Cloud.
Detrás siguen existiendo tres plataformas, tres modelos IAM y tres planos de autorización independientes.
Y precisamente esa separación es una de las fortalezas del diseño.
Próximo artículo
En la siguiente entrada bajaré un nivel y veremos la integración que probablemente tiene más piezas:
Entra ID + AWS: SSO sin usuarios IAM
Veremos qué función desempeñan SAML y SCIM, cómo interviene AWS IAM Identity Center, cómo se utilizan los grupos y Permission Sets y cómo podemos trabajar con AWS CloudShell y Terraform sin entregar Access Keys a los participantes.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.