Acceso condicional modo solo informe, exclusiones obsoletas

Acceso condicional modo solo informe, exclusiones obsoletas: qué significa realmente «aplicado»

El modo de solo informe (report-only) del Acceso condicional y las exclusiones obsoletas son las dos razones más comunes por las que una política de Acceso condicional aparece como «Activada» en el centro de administración de Microsoft Entra sin bloquear absolutamente nada. Ambas situaciones pasan fácilmente inadvertidas en una revisión rápida del portal, porque la política sigue existiendo, sus condiciones siguen configuradas correctamente y sigue apareciendo en la lista de políticas:

La política — o un cambio realizado en ella — está en modo de solo informe, que evalúa los inicios de sesión y registra el resultado, pero nunca concede, bloquea ni desafía el acceso.
La política está aplicada, pero su lista de exclusiones ha crecido más allá del motivo estrecho y documentado para el que se creó, de modo que los inicios de sesión que más importan pasan de largo sin ser tocados.

Ninguna de estas dos situaciones es un error. Ambas son funciones de Microsoft Entra compatibles e intencionadas. La brecha es operativa: nadie volvió a comprobar si la excepción seguía siendo necesaria. Brechas acceso condicional Entra ID: que errores dejan una exposicion real cubre el alcance y el panorama de controles más amplio — políticas ausentes, identidades de carga de trabajo, autenticación heredada. Este artículo se mantiene deliberadamente acotado: qué ocurre después de que una política existe, cuando su estado de aplicación o su lista de exclusiones se desvía silenciosamente de lo que el tenant cree que está protegido.

Modo de solo informe: el no-control silencioso

El modo de solo informe es un estado por política dentro del Acceso condicional. Microsoft lo documenta como una forma de permitir a los administradores «probar la mayoría de las políticas de Acceso condicional antes de habilitarlas» — durante el inicio de sesión, el sistema evalúa la política pero no aplica los controles de concesión o de sesión, y a los usuarios nunca se les solicita MFA, cumplimiento del dispositivo, ni son bloqueados por una política en modo de solo informe.

⚠️

⚠️ Advertencia: el modo de solo informe no es una versión debilitada de «Activada». Equivale funcionalmente a «Desactivada» a efectos de aplicación — la política produce evidencia en los registros, no control de acceso.

Por qué el modo de solo informe deriva de un estado de prueba a uno permanente

El mecanismo que hace esto peligroso en la práctica no es el despliegue inicial — la mayoría de los equipos escalonan deliberadamente las políticas nuevas en modo de solo informe durante una ventana de revisión. El riesgo aparece en la deriva posterior: una política aplicada puede volver silenciosamente a modo de solo informe por parte de cualquiera con permisos de Administrador de acceso condicional. La documentación de Microsoft es explícita en que el modo de solo informe nunca aplica los controles de concesión o de sesión, sin importar el estado previo de la política: «durante el inicio de sesión, el sistema evalúa las políticas en modo de solo informe pero no las aplica». Ese único interruptor, cambiado durante una sesión de resolución de problemas o una excepción de acceso de emergencia y nunca revertido, elimina silenciosamente un control que todos los paneles y listas de políticas siguen mostrando como configurado.

La recomendación de Microsoft es validar los cambios en una política ya aplicada clonándola en una copia en modo de solo informe, en lugar de cambiar el interruptor de la política original — comparando los resultados de la copia con los de la política activa y descartando la copia una vez satisfecho. Cuando no se sigue este patrón, la política original termina siendo la que queda en modo de solo informe, a veces indefinidamente.

Exclusiones obsoletas y excesivas: cómo se erosiona la cobertura con el tiempo

Las exclusiones existen por razones operativas reales: una oficina remota que aún no puede cumplir un requisito de ubicación, un dispositivo heredado pendiente de reemplazo, una cuenta de acceso de emergencia (break-glass). La propia guía de Microsoft sobre la gestión de usuarios excluidos es explícita en que esto empieza pequeño y se convierte en un problema:

«Con frecuencia, cuando configura una exclusión por primera vez, hay una lista corta de usuarios que omiten la política. Con el tiempo, se añaden más usuarios a la exclusión y la lista crece. En algún momento, debe revisar la lista y confirmar que cada uno de estos usuarios sigue siendo elegible para la exclusión.»

Tres formas en que las listas de exclusión empeoran más de lo que parece

Las exclusiones individuales de usuarios o de grupos locales heredados no ofrecen visibilidad continua. Los usuarios a menudo no saben que están excluidos, y si la exclusión usa un grupo sincronizado desde el entorno local o un grupo dinámico, los administradores tienen visibilidad limitada sobre quién forma parte de él y por qué.
La pertenencia de autoservicio puede convertir una exclusión en un método de evasión. Si el grupo de exclusión permite la incorporación de autoservicio (un patrón legítimo para el escenario del «empleado en viaje»), cualquier usuario que descubra el grupo puede añadirse a sí mismo.
La elegibilidad nunca se vuelve a comprobar. Un usuario excluido por un dispositivo heredado ya reemplazado, o una exclusión de contratista que sobrevivió al fin del contrato, permanece excluido indefinidamente porque nada obliga a una nueva revisión.

El control compensatorio: grupos asignados más revisiones de acceso recurrentes

El control compensatorio recomendado por Microsoft consiste en respaldar cada exclusión con un grupo de seguridad de Microsoft Entra dedicado, de pertenencia Asignada (no una lista de usuarios individuales ni un grupo sincronizado heredado), y adjuntar una revisión de acceso recurrente a ese grupo. El patrón documentado para una exclusión basada en ubicación es una revisión que se ejecuta cada semana, nunca termina, exige autoatestación de cada miembro y elimina automáticamente a quien no responde. Para una exclusión de autenticación heredada, el patrón recomendado es una revisión recurrente con los propietarios de la unidad de negocio como revisores y aplicación automática de los resultados. Ambos patrones requieren una licencia Microsoft Entra ID P2, Microsoft Entra ID Governance o Enterprise Mobility + Security E5 — las revisiones de acceso no están disponibles en los niveles inferiores.

💡

💡 Consejo: si un grupo de exclusión no tiene ninguna revisión de acceso adjunta, trate eso como el hallazgo en sí mismo — no «¿es razonable esta exclusión ahora?», sino «nada en este tenant volverá a hacer esa pregunta jamás».

Las exclusiones también tienen un punto ciego de alcance que la mayoría de los revisores no comprueba: las exclusiones de recursos en las políticas de «Todos los recursos». Microsoft está desplegando un cambio de aplicación, a partir del 15 de junio de 2026, que cierra exactamente esta brecha. Anteriormente, cuando una política de «Todos los recursos» tenía alguna exclusión de recursos, los inicios de sesión que solicitaban solo un conjunto reducido de «ámbitos de referencia» (openid, profile, email, offline_access, User.Read y algunos ámbitos de directorio similares) quedaban silenciosamente exentos de toda aplicación — incluso si el administrador que había creado la política creía que «Todos los recursos» significaba realmente todo. Clientes públicos como Azure CLI o VS Code, y aplicaciones web confidenciales que solo solicitan esos ámbitos, pasaban sin ser desafiados. Los atacantes que abusan de flujos OAuth solicitando ámbitos mínimos, en un espíritu similar a lo que ocurre en el device code phishing, son exactamente el tipo de inicio de sesión que esta brecha habría dejado pasar sin revisión. Este es un caso en el que la propia telemetría de Microsoft confirmó que las exclusiones a nivel de recurso producían brechas de cobertura más amplias y no deseadas de lo que los tenants creían — el mismo modo de fallo del que trata este artículo, solo que en la capa de ámbito en lugar de la capa de usuario.

Detección

La detección aquí es un ejercicio de correlación entre la evidencia de inicio de sesión y el historial de cambios de política, no una alerta única.

Señal	Dónde encontrarla	Qué indica
Resultado por política en la pestaña Solo informe de una entrada del registro de inicio de sesión	Centro de administración de Entra → detalles del registro de inicio de sesión	Si ese inicio de sesión concreto habría pasado, fallado o requerido una acción si la política estuviera aplicada
`appliedConditionalAccessPolicies[].result` vía Microsoft Graph	`GET /auditLogs/signIns` (los valores de solo informe requieren el encabezado `Prefer: include-unknown-enum-members`)	Versión programática de la pestaña anterior — valores de enumeración: `success`, `failure`, `notApplied`, `notEnabled`, `reportOnlySuccess`, `reportOnlyFailure`, `reportOnlyNotApplied`, `reportOnlyInterrupted`
`enforcedGrantControls` / `enforcedSessionControls` en el mismo objeto	Microsoft Graph `appliedConditionalAccessPolicy`	Confirma qué controles se aplicaron realmente en un inicio de sesión dado frente a los que la política está configurada para exigir
Libro de Conditional Access Insights and Reporting	Centro de administración de Entra, requiere Entra ID P1 + un área de trabajo de Log Analytics que reciba registros de inicio de sesión	Comparación agregada de solo informe frente a aplicado en un rango de tiempo, conjunto de aplicaciones y conjunto de usuarios — la forma más rápida de detectar una política que lleva en modo de solo informe mucho más allá de una ventana de prueba
Vista de impacto de política (versión preliminar)	Centro de administración de Entra, rol Lector de seguridad o superior	Instantánea de 24h/7d/1 mes del impacto potencial y existente de una política, sin construir una consulta de libro
Registro de auditoría: cambios de estado «Enable policy»	Centro de administración de Entra → Registros de auditoría, filtrados por actualizaciones de políticas de Acceso condicional	El evento específico sobre el que alertar: cualquier transición de Activada a Solo informe en una política previamente aplicada
Pertenencia al grupo de exclusión + resultados/registros de auditoría de revisiones de acceso	ID Governance → Revisiones de acceso → Resultados / Registros de auditoría	Quién fue eliminado, aprobado automáticamente o nunca respondió — la evidencia real de que existía una exclusión obsoleta
`membershipType` del grupo de exclusión	Endpoint `groups` de Microsoft Graph o centro de administración de Entra	Señala grupos de exclusión sincronizados desde el entorno local o dinámicos en lugar de Asignados — el patrón que Microsoft identifica como reductor de visibilidad

🚨 Peligro: una política sin ningún evento reportOnlyFailure o Failure no está necesariamente bien ajustada. Igualmente puede significar que sus exclusiones son tan amplias que casi nada se evalúa realmente contra ella.

Remediación

Cerrar la deriva del modo de solo informe

Extraiga el estado Activada actual de cada política y la fecha de su último cambio. Cualquier política en modo de solo informe sin una fecha de fin de ventana de revisión documentada es la brecha — no solo «¿es esto una prueba nueva?», sino «¿alguien es responsable de graduarla a aplicada?».
Alerte específicamente sobre los eventos del registro de auditoría de Activada a Solo informe. Esta transición es rara, deliberada y peligrosa cuando ocurre en una política previamente aplicada — nunca debería producirse en silencio.

Cerrar la deriva de exclusiones

Reemplace las exclusiones de usuarios individuales y de grupos sincronizados heredados por grupos de seguridad de Microsoft Entra dedicados, de pertenencia Asignada. Este es el requisito previo del siguiente paso; las revisiones de acceso apuntan a grupos, no a listas de usuarios ad hoc.
Adjunte una revisión de acceso recurrente a cada grupo de exclusión, siguiendo los patrones documentados por Microsoft: autoatestación con eliminación automática para exclusiones de viaje/ubicación, revisión por el propietario con aplicación automática para exclusiones de autenticación heredada o de dispositivo. Esto requiere una licencia Entra ID P2 o Entra ID Governance.
Revise cada política de «Todos los recursos» que tenga una exclusión de recursos frente al despliegue de aplicación de ámbitos de referencia previsto para el 15 de junio de 2026. Decida de forma deliberada — habilite la nueva aplicación de forma anticipada mediante la configuración de ámbitos de referencia, o use «Personalizar comportamiento» para las aplicaciones específicas que realmente necesitan la exención heredada — en lugar de dejar que el despliegue predeterminado de Microsoft decida en silencio.
Revalide con evidencia, no con intenciones. Después de cualquier graduación de solo informe a aplicada o limpieza de grupo de exclusión, confirme el resultado en los registros de inicio de sesión para cuentas representativas, tanto excluidas como incluidas, no solo en la pantalla de configuración de la política.

Cómo lo detecta EtcSec

Las comprobaciones de Azure/Entra de EtcSec se corresponden directamente con los dos modos de fallo de este artículo: CA_POLICY_REPORT_ONLY señala las políticas de Acceso condicional que aún están en modo de solo informe, CA_EXCESSIVE_EXCLUSIONS y CA_GROUP_EXCLUSION_LARGE señalan políticas cuyo alcance de exclusión ha crecido de forma desproporcionada respecto a su propósito, y CA_USER_EXCLUSIONS_STALE señala exclusiones a nivel de usuario que no muestran evidencia de revisión reciente. Dado que ambos modos de fallo tratan sobre una deriva y no sobre un error de configuración puntual, el valor está en volver a ejecutar la auditoría de forma periódica — un tenant que superó esta comprobación hace seis meses puede fallarla silenciosamente hoy sin que se haya eliminado ninguna política ni cambiado ninguna pantalla de configuración.

ℹ️

ℹ️ Nota: EtcSec comprueba automáticamente esta vulnerabilidad en cada auditoría de AD/Azure. Ejecute una auditoría gratuita para verificar su entorno.

Acceso condicional modo solo informe, exclusiones obsoletas: qué significa realmente «aplicado»