AZ-104

Deep Dive

D1 · Identidad y Acceso

Acceso Condicional

Políticas IF-THEN que evalúan señales de contexto y aplican controles de acceso. El AZ-104 evalúa la configuración de políticas, named locations, condiciones de riesgo y controles de sesión.

Icon-identity-233

Conditional Access — el motor de decisiones de acceso

Conditional Access es el motor de políticas IF-THEN de Entra ID. Evalúa señales de contexto (quién es, desde dónde, qué dispositivo, qué app, qué nivel de riesgo) y decide si permite, bloquea o agrega controles adicionales (MFA, dispositivo compliant, etc.).

Requiere Entra ID P1 mínimo. Para señales de riesgo (Identity Protection) requiere P2.

Ejemplos de políticas — lógica IF → THEN

SI Usuario es Global Admin + login desde cualquier ubicación
ENTONCES Require MFA siempre
SI Login desde IP fuera de Named Locations de confianza
ENTONCES Require MFA
SI Login desde dispositivo NO compliant (Intune) a apps M365
ENTONCES Block access
SI Sign-in risk = High (Identity Protection)
ENTONCES Require MFA + password change
SI App = Microsoft Azure Management (portal, CLI, PowerShell)
ENTONCES Require compliant device + MFA
SI Login con protocolo legacy (IMAP, SMTP básico, MAPI)
ENTONCES Block access — no soportan MFA
SI Usuario en grupo "External Partners" accede a SharePoint
ENTONCES Allow + sign-in frequency: 1 hora

Señales disponibles (Conditions)

Users / Groups

A quién aplica la policy. Incluir: todos, grupos específicos, roles de directorio. Excluir: cuentas break-glass, cuentas de servicio.

Cloud apps / Actions

Sobre qué apps aplica. Todas las apps, selección específica (ej: Salesforce), o acciones de usuario (ej: registrar dispositivo).

Locations

Basado en IP. Named Locations (rangos IP confiables) o países/regiones. "Any location" vs "All trusted locations" vs ubicaciones específicas.

Device platforms

Sistema operativo: Windows, macOS, iOS, Android, Linux. Útil para diferente tratamiento mobile vs desktop.

Client apps

Tipo de cliente: Browser (moderno), Mobile/Desktop apps, Exchange ActiveSync (legacy), Other clients (legacy). Útil para bloquear autenticación legacy.

Sign-in risk (P2)

Score de riesgo calculado por Identity Protection: Low, Medium, High. Basado en ML: login desde país nuevo, Tor, credential spray, etc.

User risk (P2)

Riesgo acumulado del usuario: credenciales filtradas, comportamiento anómalo histórico. Low/Medium/High.

Device compliance / Hybrid join

Estado del dispositivo en Intune (compliant) o si está unido a AD DS on-prem (Hybrid Azure AD join). Requiere Intune o Entra Connect.

Controles de acceso

Grant controls

Qué hacer si la condición se cumple. Se pueden combinar con AND u OR.

Block access

Deniega el acceso completamente. El usuario ve error de acceso.

Require MFA

El usuario debe completar MFA para obtener acceso.

Require compliant device

Dispositivo debe estar marcado como compliant en Intune.

Require Hybrid Azure AD join

Dispositivo debe estar unido a AD DS on-prem vía Entra Connect.

Require approved client app

Solo apps de Intune-managed o apps específicas de Microsoft.

Require authentication strength

Especificar nivel mínimo (ej: passwordless, phishing-resistant).

Session controls

Controlan el comportamiento dentro de la sesión (no el acceso inicial).

Sign-in frequency

Cada cuánto el usuario debe re-autenticarse. Ej: "1 hora" para apps sensibles. Reemplaza el token lifetime fijo.

Persistent browser session

"Never persistent" — el browser no recuerda la sesión. Útil en dispositivos compartidos.

App-enforced restrictions

Solo Exchange Online y SharePoint: controles dentro de la app (no descargar, no copiar, solo lectura).

Conditional Access App Control (MCAS)

Proxy de Microsoft Defender for Cloud Apps para inspección en tiempo real del contenido de la sesión.

Disable resilience defaults

Si Entra ID tiene outage, no permitir acceso con tokens en caché. Máxima seguridad, menor resiliencia.

Named Locations

Definir rangos de IP de confianza (oficinas, VPN corporativa) o ubicaciones geográficas para usar como condiciones en CA policies.

IP ranges (IPv4 / IPv6)

Entra ID → Security → Named locations → New location → IP ranges.

NameOficinas Corporativas LATAM
Mark as trustedSí → aparece como "trusted location" en condiciones
IP ranges203.0.113.0/24, 198.51.100.0/24 (IPv4 CIDR)

Máximo 2.000 Named Locations por tenant. Cada una hasta 2.000 rangos IP.

Countries location

Agrupar países para políticas geográficas. Útil para bloquear logins desde países no esperados.

• Seleccionar uno o más países/regiones

• Basado en la GeoIP de la dirección IP del login

• Caso: bloquear acceso de empleados desde países sin operaciones de la empresa

• Limitación: IPs de VPN o proxies pueden bypasear la detección geográfica

Trampa del examen: "All trusted locations" en una CA policy solo incluye Named Locations marcadas como "Mark as trusted location" — no todas las Named Locations.

Identity Protection — señales de riesgo (P2)

Microsoft analiza miles de millones de señales diarias para detectar logins sospechosos. Requiere Entra ID P2.

Sign-in risk

Probabilidad de que el login específico no sea legítimo. Se calcula en tiempo real.

LowPropiedades desconocidas menores
MediumIP anónima (Tor), propiedades atípicas
HighCredential spray, password spray, login imposible (2 países simultáneos), malware-linked IP

User risk

Probabilidad de que la identidad del usuario esté comprometida. Acumulativo.

LowPatrones de login levemente inusuales
MediumActividad inusual combinada
HighCredenciales filtradas (HIBP, dark web), logins imposibles, actividad de malware

CA para Workload Identities — Service Principals y MIs

Conditional Access no solo aplica a usuarios humanos. También puede aplicarse a Workload Identities (service principals y managed identities). Requiere licencia Entra ID Workload Identities Premium.

Condiciones disponibles para Workload Identities

Service principal risk

Entra ID Identity Protection calcula un riesgo para el SP basado en comportamiento anómalo, uso de IPs comprometidas, etc.

IP location (Named Locations)

Restringir el SP a llamar a Azure solo desde rangos de IP específicos. Útil para apps que solo deben ejecutarse en IPs corporativas o de Azure.

Caso real: Tienes un Service Principal usado en tu pipeline de CI/CD que solo debería llamar a Azure Resource Manager. Si alguien roba el Client Secret y lo usa desde una IP externa, la CA policy bloquea el acceso porque la IP no está en las Named Locations permitidas.

Configurar CA para Service Principal

1.Entra ID → Security → Conditional Access → New policy
2.Assignments → Users or workload identities → Workload identities
3.Seleccionar: All service principals o específicos
4.Conditions → Locations → Include: Any location, Exclude: Trusted locations (IPs corporativas)
5.Access controls → Grant: Block access
6.Enable policy en modo Report-only primero para verificar impacto
Icon-identity-233

Authentication Context — step-up auth

Authentication Context permite aplicar controles de CA adicionales para acciones específicas dentro de una aplicación, no solo al login inicial. Implementa "step-up authentication".

Escenario: app bancaria

Login inicial (CA policy normal)

Usuario inicia sesión → requiere MFA estándar → accede a ver saldo y transacciones.

Acción sensible: transferir dinero

La app marca esta acción con un Authentication Context "transfer-funds". La CA policy para ese context exige re-autenticación con phishing-resistant MFA.

El usuario debe volver a autenticarse con su FIDO2 key solo para la transferencia, aunque ya está autenticado en la app.

Configuración

1.Entra ID → Security → Conditional Access → Authentication context → New authentication context
2.Crear el contexto (ej: "c1" con nombre "High-value transaction")
3.Crear CA policy → Cloud apps: seleccionar apps específicas → Authentication context: c1
4.Access controls → Grant: Require phishing-resistant MFA
5.La app incluye el claim "acrs": "c1" en su request de token cuando el usuario hace la acción sensible
6.Entra ID evalúa la CA policy para ese context y exige el nivel de auth configurado

Nota: La app debe soportar Authentication Context — necesita llamar a Entra ID con el parámetro correcto. Requiere implementación en el código de la app.

CA para registro de dispositivos

Puedes controlar qué usuarios pueden registrar o unir dispositivos a Entra ID usando CA policies o restricciones directas.

Restricción de registro

Entra ID → Devices → Device settings

"Users may register their devices" → All / Selected / None. Si Selected: solo el grupo configurado puede registrar.

Evitar que usuarios BYOD personales registren sus dispositivos sin autorización previa.

CA policy para User Actions

CA policy → Cloud apps or actions → User actions

"Register or join devices" como trigger. Aplicar condiciones: require MFA, require compliant device para poder registrar uno nuevo.

Exigir MFA cuando alguien registra un nuevo dispositivo para evitar registro no autorizado.

Intune enrollment restrictions

Intune → Devices → Enrollment → Enrollment restrictions

Limitar qué plataformas (iOS, Android, Windows) pueden enrolarse en Intune. Limitar número de dispositivos por usuario.

Control granular del enrolamiento MDM más allá del registro en Entra ID.

Icon-identity-235

Buenas prácticas y errores frecuentes

✓ Buenas prácticas

  • Usar Report-only mode antes de activar cualquier policy en producción.
  • Siempre excluir cuentas break-glass de TODAS las CA policies.
  • Nombrar policies con convención clara: [Scope]-[Condition]-[Action] ej: "ADMINS-AnyLocation-RequireMFA".
  • Empezar con scope limitado (grupo piloto) y expandir gradualmente.
  • Revisar sign-in logs tras activar — buscar impacto no deseado.
  • Combinar múltiples controles con "Require one of the selected controls" para balance seguridad/UX.

✗ Errores que causan lockouts

  • Crear policy "Block all" sin excluir admins → todos bloqueados incluido el creador.
  • No excluir cuentas break-glass → si hay problema con MFA, nadie puede entrar.
  • Exigir "compliant device" a todos sin Intune configurado → usuarios legítimos bloqueados.
  • Activar policy sin probar en Report-only → impacto no previsto en producción.
  • No considerar cuentas de servicio y automatizaciones que fallan con MFA.
  • Mezclar Per-User MFA con Conditional Access → comportamientos inesperados.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

¿Qué condición de Acceso Condicional permite bloquear el inicio de sesión desde países donde la empresa no opera?