Conditional Access: los errores de configuración más comunes
Conditional Access es el control de acceso más potente de Entra ID, pero también uno de los más fáciles de configurar mal de forma silenciosa: una política que parece correcta puede tener un hueco que la deja sin efecto para un subconjunto de usuarios o escenarios, y ese hueco no se descubre hasta que alguien lo explota.
Exclusiones que se convierten en agujeros permanentes
Es habitual excluir temporalmente a un usuario o grupo de una política de Conditional Access para resolver un problema puntual —una cuenta de servicio que falla, un administrador que necesita acceso urgente sin MFA— con la intención de revertirlo después. En la práctica, esas exclusiones rara vez se retiran: se acumulan durante meses o años, y cada una es una excepción a las políticas de seguridad que nadie recuerda por qué existe. Una auditoría de Conditional Access debe empezar siempre por listar y justificar cada exclusión activa.
No cubrir todas las aplicaciones ni todos los flujos de autenticación
Una política que aplica "a todas las aplicaciones en la nube" puede parecer completa, pero muchos tenants tienen aplicaciones heredadas o protocolos legacy (POP, IMAP, SMTP AUTH) que no pasan por el mismo flujo de autenticación moderno y, por tanto, no evalúan Conditional Access de la misma forma. Si la autenticación heredada no está explícitamente bloqueada, sigue siendo una vía de acceso sin MFA aunque todas las políticas "modernas" estén bien configuradas: es, de hecho, uno de los vectores más explotados en compromisos de Microsoft 365.
Políticas en modo "solo informe" que nunca se activan
Microsoft recomienda desplegar políticas nuevas en modo "solo informe" (report-only) para validar su impacto antes de aplicarlas. El problema aparece cuando esa fase de prueba se alarga indefinidamente: la política queda registrando eventos sin bloquear nada, dando una falsa sensación de protección. Es fundamental fijar una fecha de revisión para pasar cada política de "solo informe" a "activada" tras validar que no rompe flujos legítimos.
Cómo auditar tus políticas de Conditional Access
Una revisión completa cubre: (1) inventariar todas las políticas activas, en modo informe y deshabilitadas, con su cobertura real de usuarios y aplicaciones; (2) verificar que la autenticación heredada está bloqueada globalmente; (3) listar y justificar cada exclusión de usuario o grupo; (4) simular escenarios de acceso (usuario nuevo, dispositivo no gestionado, ubicación fuera de España) para detectar huecos de cobertura; (5) usar el simulador "What If" de Entra ID para verificar que las políticas se comportan como se espera antes y después de cualquier cambio.
FAQ
¿Basta con tener una política de MFA para todos los usuarios?
No. Una sola política amplia de MFA no cubre autenticación heredada, no diferencia por riesgo de sesión ni por dispositivo, y no protege frente a robo de tokens. Un diseño robusto combina varias políticas específicas: bloqueo de legacy auth, MFA resistente al phishing en cuentas críticas, y políticas basadas en riesgo (Identity Protection).
¿Cómo pruebo una política sin arriesgarme a bloquear a usuarios legítimos?
Desplégala primero en modo "solo informe" sobre un grupo piloto reducido, revisa los registros de inicio de sesión durante al menos una o dos semanas, y usa la herramienta "What If" de Entra ID para simular su efecto antes de activarla en producción para todos los usuarios.