El módulo 3 terminó con una lista incómoda: contraseñas escritas a mano, secretos dentro de cadenas de conexión y permisos amplios "porque era lo rápido". Hoy empieza el trabajo de cerrar esa deuda, y empieza por el sitio correcto. En una infraestructura clásica, la seguridad se construía sobre el perímetro: si estabas dentro de la red de la oficina de Barcelona, eras de confianza. En Azure ese perímetro no existe —Marta Ríos administra la producción desde un portátil en un aeropuerto y app-contoso-reservas-pro se ejecuta en un centro de datos al que nadie de Contoso Airlines ha entrado nunca—, así que la identidad pasa a ser el perímetro. Cada llamada a la API de Azure, cada consulta a db-reservas y cada lectura de un blob de sttarjetascontosopro se autoriza en función de quién la hace. Y ese "quién" lo define un único servicio: Microsoft Entra ID. Toda la seguridad del resto del módulo —RBAC, identidades administradas, Key Vault, Defender for Cloud— se apoya en lo que montes hoy.

Aviso importante: las decisiones de identidad de esta lección (acceso condicional, MFA obligatorio, bloqueos geográficos, roles privilegiados) afectan a quién puede entrar en los sistemas de la empresa y tienen implicaciones legales y de cumplimiento. Antes de aplicar cualquier configuración de este tipo en producción, debe revisarla un profesional de seguridad o el equipo de compliance de tu organización. Una política mal medida puede dejar fuera a toda la plantilla o abrir una puerta que creías cerrada.

1. La identidad como perímetro
2. Qué es Microsoft Entra ID y en qué se diferencia de Active Directory
3. Inquilino, directorio y suscripciones
4. Tipos de identidad en Entra ID
5. Usuarios y grupos de Contoso con Azure CLI
6. Grupos dinámicos por atributo
7. Autenticación: contraseñas, MFA y sin contraseña
8. Acceso condicional: el motor de decisiones
9. Privileged Identity Management y roles a demanda
10. Roles de Entra ID frente a roles de Azure: deshaciendo la confusión
11. Entra External ID para los pasajeros
12. Revisiones de acceso e identidad híbrida
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

El modelo de confianza cero se resume en tres principios que conviene tener presentes durante todo el módulo:

• Verificar explícitamente: autenticar y autorizar con todas las señales disponibles (usuario, dispositivo, ubicación, riesgo), no solo con una contraseña correcta.
• Privilegio mínimo: dar el permiso más pequeño que permite trabajar, y durante el menor tiempo posible.
• Asumir la brecha: diseñar como si el atacante ya estuviera dentro, segmentando y registrando todo.

Traducido a Contoso: que Diego Salas conozca la contraseña de la base de datos no debería bastar para leer las reservas, y que un atacante robe las credenciales del portal no debería darle acceso a la suscripción de producción. Los tres principios se van a materializar en herramientas concretas: hoy la autenticación, en 04-02 la autorización y las identidades sin contraseña, en 04-06 las reglas que nadie puede saltarse.

Microsoft Entra ID (el servicio que durante años se llamó Azure AD; no uses ya ese nombre) es el servicio de identidad y acceso de la nube de Microsoft. Es el que autentica a las personas que abren el portal de Azure, a las que usan Microsoft 365 y a las aplicaciones que llaman a APIs protegidas.

El error conceptual más extendido es pensar que Entra ID es "Active Directory alojado en la nube". No lo es: son productos distintos, con protocolos distintos y modelos distintos.

Consecuencia práctica para Contoso: el AD local de la oficina de Barcelona sigue siendo necesario para las impresoras, los recursos compartidos y los equipos unidos al dominio; Entra ID no lo sustituye. Lo que hace es coexistir con él y convertirse en la autoridad de identidad para todo lo que vive en Azure y en internet. Cómo se sincronizan es el apartado 12.

Tres conceptos que se confunden a diario:

• Inquilino (tenant): una instancia dedicada de Entra ID que pertenece a una organización. Contoso tiene uno: contosoairlines.example, con su identificador (GUID). Es la frontera de la identidad.
• Directorio: el contenido del inquilino —usuarios, grupos, aplicaciones, dispositivos—. En la práctica se usan como sinónimos.
• Suscripción: un contenedor de facturación y de recursos de Azure. Contoso Airlines - Producción y Contoso Airlines - Desarrollo son dos suscripciones distintas.

La relación clave: una suscripción confía en exactamente un inquilino, y ese inquilino autentica a quien intenta entrar. Un inquilino, en cambio, puede tener muchas suscripciones. Las dos suscripciones de Contoso confían en el mismo inquilino, y por eso Marta Ríos tiene una sola identidad para ambas, aunque sus permisos en cada una sean distintos.

Si mueves una suscripción a otro inquilino (operación real y ocasional en fusiones), todas las asignaciones de rol se pierden, porque apuntaban a identidades del inquilino anterior. Los recursos siguen ahí; el acceso, no.

Todo lo que puede autenticarse se llama entidad de seguridad (security principal). Hay cuatro familias:

Dos matices que ahorran errores:

• Registro de aplicación frente a entidad de servicio: el registro es la definición global de la aplicación (su identificador, sus permisos, sus URI de redirección); la entidad de servicio es la instancia de esa aplicación dentro de un inquilino concreto, y es a ella a la que se asignan roles. Una app registrada en Contoso y usada por otra empresa tiene un registro y dos entidades de servicio.
• Grupos de seguridad frente a grupos de Microsoft 365: solo los primeros sirven para asignar permisos de Azure. Y si un grupo va a recibir roles de directorio, hay que crearlo con isAssignableToRole activado; esa propiedad no se puede cambiar después y hace que solo los administradores privilegiados puedan modificar su pertenencia.

Las identidades administradas son la pieza que elimina las contraseñas de las aplicaciones, y merecen su propia lección: se desarrollan por completo en 04-02. Aquí basta con saber que existen y que son entidades de servicio con el ciclo de vida gestionado por Azure.

Contoso organiza el acceso en cuatro grupos de seguridad. Contoso-DBA-Reservas ya existe desde la lección 03-02, donde se designó como administrador de Microsoft Entra ID de sql-contoso-reservas-pro.

--force-change-password-next-sign-in true es obligatorio en cualquier alta: la contraseña que escribes tú no debe sobrevivir al primer inicio de sesión. Fíjate también en que --department no es decorativo: se usará en el apartado 6 para la pertenencia dinámica.

La regla de oro, que se repetirá en 04-02: los permisos se asignan a grupos, nunca a personas. Cuando Diego Salas cambie de equipo, su acceso cambia con un group member remove, no revisando cincuenta asignaciones de rol repartidas por dos suscripciones.

Un grupo dinámico calcula su pertenencia a partir de una regla sobre los atributos del usuario. Nadie añade ni quita a nadie: cuando Recursos Humanos cambia el departamento en el alta, la pertenencia se recalcula sola (en minutos, no instantáneamente).

Cuidado con dos cosas: los grupos dinámicos requieren licencia Entra ID P1 y una regla mal escrita puede vaciar el grupo (y con él los permisos de medio equipo) sin previo aviso. Contoso los usa para pertenencias amplias y descriptivas —"todo el departamento de desarrollo"—, y mantiene asignación manual en los grupos con privilegio real, como Contoso-Infraestructura.

La recomendación real, sin adornos: MFA para el 100 % de los usuarios y métodos sin contraseña resistentes a phishing para todo el que tenga privilegios. El SMS no es MFA de verdad frente a un atacante decidido, pero es infinitamente mejor que nada. Contoso aplica llaves FIDO2 a los cuatro miembros de Contoso-Infraestructura y Authenticator sin contraseña al resto.

Complementos que conviene conocer: restablecimiento de contraseña de autoservicio (SSPR), que quita al servicio de soporte el 30 % de sus tickets; protección de contraseñas con lista de términos prohibidos (contoso, airlines, reservas); y Protección de identidad (licencia P2), que puntúa el riesgo de cada inicio de sesión —viaje imposible, IP anónima, credenciales filtradas— y alimenta las políticas del apartado siguiente.

El acceso condicional es un motor de reglas que se evalúa después de la autenticación correcta y antes de conceder el token. Su estructura es siempre la misma: si se dan estas señales, entonces exijo estos controles.

Los controles de concesión habituales son: exigir MFA, exigir dispositivo conforme o unido a Entra híbrido, exigir aplicación cliente aprobada, exigir términos de uso, o bloquear directamente. Además hay controles de sesión: frecuencia de inicio de sesión y sesión de navegador no persistente.

Dos políticas concretas de Contoso:

Política 1 — MFA obligatorio para administradores. Se aplica a los roles de directorio privilegiados (Administrador global, Administrador de seguridad, Administrador de aplicaciones) y a Contoso-Admins-Entra, sobre todas las aplicaciones en la nube, exigiendo MFA y una frecuencia de inicio de sesión de 8 horas.

Política 2 — Bloqueo geográfico. Contoso Airlines opera en España, Portugal, Francia e Italia, y su personal viaja a esos destinos. Se crea una ubicación con nombre con esos países y se bloquea el acceso desde cualquier otro, aplicándolo solo a los empleados (no a los invitados, que se tratan aparte). No es una medida infalible —una VPN la esquiva— pero elimina de golpe el ruido de fondo de intentos automatizados desde otros continentes.

La regla que nunca debes saltarte: crea siempre una cuenta de acceso de emergencia (break-glass) y excluida de todas las políticas de acceso condicional. Dos cuentas, en realidad: sin MFA basada en teléfono, con contraseña larguísima guardada en sobre lacrado o caja fuerte, con rol de Administrador global permanente, y con una alerta que avise a todo el equipo si se usa. El motivo es sencillo: una política mal escrita, un proveedor de MFA caído o un fallo de federación pueden dejarte fuera de tu propio inquilino sin ninguna forma de entrar a arreglarlo. Ha pasado en organizaciones grandes y no tiene solución rápida.

Toda política nueva se despliega primero en modo solo informe, que la evalúa y registra el resultado sin aplicarlo. Se revisan los inicios de sesión afectados durante una o dos semanas, se corrigen las exclusiones necesarias y solo entonces se activa. Es el mismo patrón "detectar antes que bloquear" que verás en 04-04 con el WAF y en 04-06 con Azure Policy.

Que Marta Ríos sea Propietaria de la suscripción de producción de forma permanente significa que, si le roban la sesión un martes cualquiera a las tres de la tarde, el atacante también lo es. Privileged Identity Management (PIM), incluido en Entra ID P2, cambia el modelo: los roles pasan de asignados a aptos (eligible), y quien los necesita los activa durante un tiempo limitado.

PIM funciona tanto con roles de Entra ID como con roles de Azure (RBAC), y se complementa con alertas (demasiados administradores globales, roles activados fuera de horario) y con las revisiones de acceso del apartado 12. Contoso lo aplica a Propietario, Administrador de acceso de usuario y Administrador global: nadie los tiene en reposo.

Esta es la confusión clásica, y conviene romperla ahora mismo con una frase: son dos sistemas de permisos completamente separados que no se heredan entre sí.

El ejemplo que lo aclara: un Administrador global de Entra ID no puede, por defecto, leer un blob de sttarjetascontosopro. Manda sobre el directorio, no sobre los recursos. (Puede concederse ese acceso activando la opción de elevación de acceso, y eso queda registrado —precisamente porque es excepcional.) Y al revés: el Propietario de la suscripción de producción no puede crear usuarios ni cambiar políticas de MFA. Los roles de Azure y todo su modelo de autorización son el tema completo de la lección 04-02.

Los miles de pasajeros que se registran en Contoso Reservas no deben ser usuarios del inquilino corporativo. Mezclar clientes y empleados en el mismo directorio es un error de diseño con consecuencias inmediatas: las políticas de acceso condicional pensadas para la plantilla se aplicarían a los clientes, las licencias se dispararían y el listado de usuarios sería inmanejable.

La solución es Microsoft Entra External ID en su configuración para clientes (CIAM), un inquilino separado dedicado a identidades externas:

Los usuarios B2B (invitados) son la tercera categoría, y no debe confundirse con las anteriores: la auditora externa de PCI DSS que aparecerá en 04-05 se invita al inquilino corporativo como invitada, con su propia identidad en su empresa, sin que Contoso gestione su contraseña.

Los permisos se acumulan: alguien entra en un proyecto, recibe acceso, el proyecto termina y el acceso se queda. Las revisiones de acceso (P2) automatizan la limpieza: cada trimestre, el responsable de Contoso-Infraestructura recibe la lista de miembros y debe aprobar o retirar a cada uno, con la opción de retirar automáticamente a quien no reciba respuesta. Contoso las programa sobre los cuatro grupos, sobre los invitados B2B y sobre los roles privilegiados de PIM.

Y queda el AD local de Barcelona. Microsoft Entra Connect (y su sucesor, Entra Cloud Sync) sincroniza usuarios y grupos del AD local hacia Entra ID, de modo que cada empleado tiene una sola identidad. Hay tres modelos de autenticación —sincronización de hash de contraseña (el recomendado por sencillez y resiliencia), autenticación de paso a través y federación con ADFS— y una regla de oro: la sincronización es unidireccional hacia la nube para los objetos de usuario, así que el AD local sigue siendo la fuente de la verdad y los cambios se hacen allí. Es una introducción deliberada: montar Entra Connect es un proyecto en sí mismo y aquí solo necesitas saber dónde encaja.

• No tener cuenta de acceso de emergencia. Es el error que puede dejarte permanentemente fuera de tu inquilino. Créala hoy, documenta dónde está la credencial y pruébala cada seis meses.
• Activar una política de acceso condicional directamente en producción. Usa siempre el modo solo informe primero. Una política que exija dispositivo conforme sin haber inscrito los dispositivos bloquea a toda la plantilla en cinco minutos.
• Asignar permisos a personas y no a grupos. Funciona el primer día y es ingobernable el mes doce.
• Confundir roles de Entra ID con roles de Azure. Si alguien "es administrador" y no puede leer un blob, no es un error: son sistemas distintos (apartado 10).
• Registrar a los clientes en el inquilino corporativo. Usa Entra External ID; separar es mucho más barato que migrar después.
• Tener diez administradores globales permanentes. El objetivo son entre dos y cuatro, y con PIM ninguno en reposo.
• Crear un grupo normal y descubrir después que lo necesitabas asignable a roles. isAssignableToRole no se puede cambiar: hay que recrear el grupo.
• Consejo: activa el bloqueo inteligente y la protección de contraseñas antes que nada; son gratuitos y paran los ataques por fuerza bruta más burdos.
• Consejo: los registros de inicio de sesión de Entra ID solo se conservan 7 o 30 días según la licencia. Envíalos a Log Analytics (07-02) desde el primer día; el día que investigues un incidente, agradecerás tener seis meses de historial.

El proyecto "Contoso Millas" (centro-coste=CC-2077) arranca con: cinco desarrolladores internos, dos consultores de una empresa externa que trabajarán seis meses, un servicio de la aplicación que debe leer un blob, y unos 80.000 clientes que consultarán sus millas en una web pública.

1. Indica qué tipo de identidad corresponde a cada uno de los cuatro colectivos.
2. ¿Qué grupos crearías y cuáles serían dinámicos?
3. ¿Qué medida programarías para los consultores externos, sabiendo que el proyecto dura seis meses?

Contoso quiere exigir MFA a todo el personal de administración y bloquear el acceso desde fuera de España, Portugal, Francia e Italia.

1. Enumera las señales y los controles de cada una de las dos políticas.
2. ¿Qué identidades excluirías obligatoriamente y por qué?
3. Describe el proceso de puesta en marcha para no bloquear a nadie por error.

Explica la causa y la solución de cada situación:

1. Marta Ríos es Administradora global y no puede descargar una tarjeta de embarque de sttarjetascontosopro; el portal le dice que no tiene autorización.
2. Un desarrollador que dejó la empresa hace cuatro meses sigue apareciendo con acceso a rg-contoso-reservas-dev.
3. Tras activar la política de bloqueo geográfico, la canalización de despliegue nocturna empieza a fallar con un error de autenticación.

Solución 1:

1. Los cinco desarrolladores, usuarios miembro del inquilino corporativo. Los dos consultores, usuarios invitados (B2B): mantienen su identidad en su empresa y Contoso no gestiona sus contraseñas ni sus altas y bajas. El servicio que lee el blob, una identidad administrada (04-02), nunca un usuario con contraseña. Los 80.000 clientes, un inquilino de Entra External ID separado del corporativo.
2. Contoso-Millas-Desarrollo con los cinco internos y Contoso-Millas-Externos con los dos consultores, separados porque tendrán permisos distintos y porque el segundo se revisa aparte. El primero puede ser dinámico por department y extensionAttribute de proyecto; el de externos, manual, porque el privilegio y la temporalidad exigen control explícito.
3. Una revisión de acceso trimestral sobre el grupo de externos con retirada automática si el revisor no responde, y adicionalmente una fecha de caducidad en la invitación B2B. Lo importante es que la baja no dependa de que alguien se acuerde.

Solución 2:

1. Política de MFA: señales = pertenencia a roles de directorio privilegiados y a Contoso-Admins-Entra, sobre todas las aplicaciones en la nube; controles = exigir MFA y frecuencia de inicio de sesión de 8 horas. Política geográfica: señales = todos los usuarios miembro, cualquier aplicación, ubicación distinta de la ubicación con nombre "Países de operación"; control = bloquear.
2. Las cuentas de acceso de emergencia, siempre y en ambas políticas. Además, las entidades de servicio de las canalizaciones automatizadas, que no pueden hacer MFA y cuya IP de origen es un agente hospedado por Microsoft en una región cualquiera; para ellas se usan políticas de identidades de carga de trabajo con IP de confianza, no las de usuario.
3. Crear ambas en modo solo informe, esperar de una a dos semanas y analizar en los registros de inicio de sesión quién habría sido bloqueado. Corregir exclusiones, avisar a la plantilla del cambio, activar primero la de MFA (menos disruptiva) y una semana después la geográfica. Y comprobar antes que la cuenta de emergencia funciona.

Solución 3:

1. No es un fallo: los roles de Entra ID no otorgan acceso a los datos de los recursos. Administrador global manda sobre el directorio. Necesita el rol de Azure Lector de datos de Blob Storage sobre la cuenta o el contenedor (04-02), o usar la elevación de acceso, que queda registrada y es excepcional.
2. Falta gobierno del ciclo de vida: la baja de RRHH no se propagó a Azure. Solución inmediata, retirar la asignación y deshabilitar la cuenta; solución estructural, sincronizar altas y bajas desde el sistema de RRHH, usar grupos en lugar de asignaciones individuales y programar revisiones de acceso periódicas.
3. La canalización se autentica con una entidad de servicio que la política, aplicada a "todos los usuarios", también evalúa; su tráfico sale de un agente hospedado fuera de los países permitidos. Solución: excluir explícitamente esa entidad de servicio o pasar a agentes autohospedados con IP fija declarada como ubicación de confianza. Es el motivo de fondo del modo solo informe.

La identidad es el perímetro, y ya sabes por qué: en Azure no hay una red de confianza dentro de la cual todo valga, así que cada acceso se decide por quién lo pide. Has visto que Microsoft Entra ID no es Active Directory en la nube sino un servicio distinto, plano, basado en OAuth 2.0, OpenID Connect y Microsoft Graph, que coexiste con el AD local de Barcelona en lugar de sustituirlo. Distingues inquilino, directorio y suscripción, y sabes que una suscripción confía en un solo inquilino. Conoces las entidades de seguridad —usuarios miembro e invitados B2B, grupos de seguridad y grupos asignables a roles, registros de aplicación y entidades de servicio— y has creado los grupos Contoso-Infraestructura, Contoso-Desarrollo, Contoso-Operaciones y Contoso-Admins-Entra junto al ya existente Contoso-DBA-Reservas, con la regla que gobierna todo lo que viene: los permisos se asignan a grupos, no a personas.

En autenticación tienes la recomendación real —MFA para todos y métodos sin contraseña resistentes a phishing para quien tenga privilegios—, el acceso condicional con sus señales y controles, las dos políticas de Contoso y la advertencia que no admite excepciones: cuenta de acceso de emergencia excluida de todo, y despliegue en modo solo informe antes de aplicar. Con Privileged Identity Management entiendes por qué nadie debe ser Propietario permanente y qué significa activar un rol a demanda. Y has deshecho la confusión clásica: los roles de Entra ID mandan sobre identidades y los roles de Azure sobre recursos, sin herencia entre ellos. Cierran la lección Entra External ID para los pasajeros, las revisiones de acceso que evitan la acumulación silenciosa de permisos y Entra Connect como puente con el AD local.

Ahora existen identidades bien gobernadas, pero todavía no dicen nada sobre qué puede tocar cada una: Contoso-Desarrollo sigue sin permisos, y app-contoso-reservas-pro sigue conectándose a db-reservas y a sttarjetascontosopro con secretos en su configuración. En la siguiente lección, RBAC e identidades administradas, montarás el sistema de autorización de Azure —la tríada entidad, rol y ámbito—, descubrirás por qué el rol Colaborador no deja leer un blob, crearás el rol personalizado "Operador de Reservas de Contoso" y darás a la aplicación una identidad administrada con la que autenticarse sin una sola contraseña.