¿Qué es Conditional Access en Microsoft Entra?

Conditional Access decide qué condiciones debe cumplir un acceso a los recursos de una organización en Microsoft Entra. Combina señales como quién solicita entrar, a qué aplicación, desde qué dispositivo o bajo qué circunstancias. Una política puede bloquear el acceso o exigir controles adicionales antes de concederlo.

La pregunta útil ya no es únicamente si alguien conoce una contraseña. Para una aplicación sensible puede importar también el estado del equipo o la autenticación utilizada. Las políticas convierten esas exigencias en decisiones aplicables al acceso, con un alcance que debe diseñarse y comprobarse antes de afectar a toda la plantilla.

Si ocurre esto, exige aquello

Una política puede dirigirse a usuarios o grupos, recursos y determinadas condiciones. Después establece controles de concesión o de sesión según las opciones admitidas. El resultado depende de todas las políticas aplicables, por lo que revisar una regla aislada no basta para explicar necesariamente un inicio de sesión.

Pensemos en una aplicación de gestión financiera. Como ejemplo propio, la organización podría exigir un dispositivo conforme y una autenticación determinada para acceder a ella. Ese diseño necesita definir qué significa cumplir cada requisito: no basta con escribir «equipo seguro» en el nombre de la política y confiar en que Entra adivine el resto.

La MFA, o autenticación multifactor, es uno de los controles posibles, pero no convierte todas las políticas en equivalentes. La fortaleza de autenticación permite expresar requisitos sobre métodos admitidos en escenarios compatibles. Un acceso bloqueado y uno que necesita completar un control son resultados distintos, aunque ambos impidan continuar en ese momento.

-InfraCrew dice: El nombre «Acceso seguro definitivo» no cuenta como condición técnica. Aunque lleve tres versiones.-

La red es una señal, no una absolución

Las ubicaciones y direcciones IP pueden aportar contexto, igual que las señales de dispositivo o riesgo disponibles. Estar en una red conocida no demuestra por sí solo que una cuenta sea legítima. Conviene evitar diseños que conviertan una única señal en un permiso universal y permanente para recursos muy diferentes.

Conditional Access tampoco sustituye la asignación de permisos dentro de una aplicación. Una persona puede superar sus condiciones de acceso y seguir sin autorización para una operación concreta. Entrar en el servicio y tener permiso para administrar sus datos pertenecen a controles diferentes, que deben funcionar de forma coherente.

Microsoft sitúa la aplicación de estas políticas después de completar la autenticación del primer factor. No es una defensa frontal contra cualquier tráfico que llegue a Internet, ni un reemplazo de las protecciones del servicio. Su función es evaluar y exigir condiciones en el flujo de acceso que controla.

Probar una política sin convertir la oficina en el laboratorio

El modo report-only permite observar el resultado de la evaluación de muchas políticas sin imponer sus controles. Es útil para detectar usuarios, aplicaciones o situaciones que quedarían afectados. Una política en ese estado todavía no está protegiendo mediante su aplicación efectiva, y hay ámbitos que requieren revisar sus particularidades.

Antes de habilitar una política nueva, se puede delimitar un piloto y estudiar los registros de inicio de sesión. La herramienta What If ayuda a explorar escenarios, pero una simulación no sustituye todas las pruebas de acceso reales. Hay que contemplar dispositivos, clientes y formas de trabajo que existan en la organización.

Cambiar una política ya activa a report-only tiene otra consecuencia: deja de imponer esos controles. El mismo selector puede servir para preparar un despliegue o para retirar una protección existente. Registrar el estado anterior, el objetivo del cambio y la forma de volver atrás evita una sorpresa difícil de explicar después.

-InfraCrew dice: «Solo está en pruebas» tranquiliza bastante menos cuando era la política que protegía producción.-

Una denegación necesita poder explicarse

Ante un fallo de acceso, empieza por el evento concreto: usuario, recurso, hora y resultados de las políticas evaluadas. La pantalla del usuario describe el síntoma; el registro aporta el contexto de la decisión. Desactivar reglas al azar puede ocultar la causa y abrir accesos que no formaban parte de la incidencia.

El diseño también necesita una estrategia de acceso de emergencia, controlada y monitorizada, para evitar que una configuración incorrecta bloquee la administración. Las excepciones deben ser explícitas y revisables, no una colección de grupos con nombres improvisados. Mantenerlas sin seguimiento puede deshacer el propósito de las políticas.

Las capacidades y licencias dependen de las funciones utilizadas; las políticas basadas en riesgo tienen requisitos propios. Verifica el derecho de uso y la disponibilidad de cada señal en tu entorno, sin asumir que una receta de otra organización sirve igual. La política útil es la que protege el recurso previsto y permite explicar sus decisiones cuando alguien necesita trabajar.

-InfraCrew dice: Una buena política también debería superar esta prueba: que otro administrador pueda entenderla sin llamar a su autor.-

Diccionario de la Crew

MFA — Autenticación que requiere factores de categorías diferentes para comprobar la identidad.

Report-only — Estado de evaluación de una política compatible que registra su resultado sin imponer sus controles.