El arquitecto AZ-305 diseña la capa de control de acceso: políticas de Conditional Access como motor central, MFA resistente a phishing, acceso privilegiado just-in-time con PIM, y gobernanza continua con access reviews. La pregunta del examen siempre es: ¿qué combinación de controles cumple los requisitos con la menor fricción y costo?
Contenido
Conditional Access (CA) es el motor de políticas Zero Trust de Entra ID: evalúa señales (usuario, ubicación, dispositivo, app, riesgo) y aplica controles (bloquear, exigir MFA, exigir dispositivo compliant). Requiere licencia Entra ID P1; las políticas basadas en riesgo requieren P2.
Señales (IF)
Controles de acceso (THEN)
Controles de sesión
Buenas prácticas de diseño (caen en el examen)
| Método | Resistente a phishing | Notas de diseño |
|---|---|---|
| FIDO2 / Passkeys | Sí | Estándar oro. Hardware keys o passkeys en dispositivo. Para roles privilegiados y entornos regulados. |
| Windows Hello for Business | Sí | Biometría/PIN ligado al dispositivo. Passwordless para fuerza laboral con Windows gestionado. |
| Certificate-based auth (CBA) | Sí | Smartcards/certificados — organizaciones gubernamentales o que migran desde ADFS. |
| Microsoft Authenticator (push + number matching) | Parcial | Buen balance usabilidad/seguridad para la mayoría. Number matching mitiga MFA fatigue. |
| SMS / llamada de voz | No | Vulnerable a SIM swapping. Solo como fallback; eliminar para cuentas privilegiadas. |
Authentication Strengths
En lugar de exigir "MFA genérico", una política CA puede exigir una authentication strength específica — ej: "phishing-resistant MFA" (solo FIDO2, WHfB, CBA) para administradores globales. Si el escenario pide "MFA resistente a phishing para roles privilegiados", la respuesta es CA + authentication strength, no MFA per-user.
Privileged Identity Management (PIM) elimina los privilegios permanentes: los usuarios son elegibles para un rol y lo activan solo cuando lo necesitan, por tiempo limitado, con justificación, MFA y aprobación opcional. Requiere Entra ID P2.
Qué cubre PIM
Configuración por rol
Señal en el examen
Frases como "just-in-time", "solo cuando lo necesiten", "reducir privilegios permanentes", "aprobación antes de elevar" → PIM. Si además pide revisar periódicamente quién conserva el acceso → PIM + Access Reviews.
Sign-in risk (riesgo del inicio de sesión)
¿Este login específico parece legítimo?
User risk (riesgo del usuario)
¿Esta identidad está comprometida?
Diseño recomendado: en lugar de las políticas legacy de Identity Protection, crear políticas de Conditional Access basadas en riesgo (señal de user/sign-in risk como condición). Requiere P2. La detección de credenciales filtradas solo funciona con Password Hash Sync habilitado.
Access Reviews
Revisiones periódicas (ej: trimestrales) de quién conserva acceso a grupos, apps, roles de Entra y asignaciones PIM. El revisor (manager, dueño del recurso o el propio usuario) aprueba o revoca. Puede auto-remover a quien no responda.
Señal en examen: "revisar periódicamente el acceso de invitados B2B" → Access Reviews.
Entitlement Management
Access packages: paquetes de recursos (grupos + apps + sitios SharePoint) que los usuarios solicitan con flujo de aprobación, expiración automática y reviews integradas. Ideal para onboarding de proyectos y colaboración B2B gobernada.
Señal: "los usuarios deben poder solicitar acceso con aprobación y expiración" → access packages.
| Requisito | Solución | Licencia |
|---|---|---|
| Exigir MFA solo desde fuera de la red corporativa | Conditional Access + named locations | P1 |
| Bloquear POP/IMAP/SMTP básico | CA — bloquear legacy authentication | P1 |
| MFA resistente a phishing para Global Admins | CA + authentication strength (FIDO2/WHfB/CBA) | P1 |
| Exigir MFA cuando el sign-in sea riesgoso | CA basado en sign-in risk | P2 |
| Forzar reset seguro si hay credenciales filtradas | CA basado en user risk (+ PHS) | P2 |
| Roles de administrador activados solo cuando se necesiten | PIM (eligible + activación JIT) | P2 |
| Revisión trimestral del acceso de invitados | Access Reviews | P2 |
| Solicitud de acceso self-service con aprobación y expiración | Entitlement Management (access packages) | P2 |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa exige que sus administradores globales: (1) no tengan el rol asignado de forma permanente, (2) requieran aprobación de un responsable antes de usarlo, y (3) usen MFA resistente a phishing al activarlo. ¿Qué combinación de servicios diseñas?
Inicia sesión para llevar tu progreso.