Brechas de Cobertura de Acceso Condicional en Entra ID

Las brechas de cobertura de política base de acceso condicional Entra ID que arrastran los tenants son la forma más elemental de fallo de Acceso Condicional que existe: no una política mal configurada, no una exclusión demasiado amplia, sino ninguna política en absoluto que cubra los roles admin, todos los usuarios, todas las apps en la nube o el cumplimiento de dispositivos. Un tenant puede tener una docena de políticas de Acceso Condicional en el centro de administración — bloqueos de autenticación legacy, reglas de inicio de sesión basadas en riesgo, excepciones específicas de aplicaciones — y aun así tener cero cobertura en cualquiera de estas cuatro bases. Brechas acceso condicional Entra ID: que errores dejan una exposicion real cubre la deriva de alcance, las exclusiones y la autenticación legacy dentro de políticas ya existentes. Este artículo trata sobre la pregunta que precede a todo eso: ¿existe siquiera una política base?

Brechas de Cobertura de Política Base de Acceso Condicional Entra ID: Los Cuatro Puntos Ciegos

La propia guía de despliegue de Acceso Condicional de Microsoft es explícita en que un tenant debería poder señalar un pequeño conjunto de políticas base que se apliquen ampliamente, no un montón de excepciones estrechas. Como lo expresa Microsoft en su guía de planificación de despliegue, las organizaciones deberían crear una política que se dirija a todos los usuarios, todos los recursos sin exclusiones de aplicaciones, y que exija autenticación multifactor — porque eso "garantiza que no sea necesario actualizar las políticas de Acceso Condicional cada vez que se incorpora una nueva aplicación". Un tenant al que le falte cualquiera de las cuatro brechas siguientes no ha alcanzado esa base, sin importar cuántas otras políticas tenga configuradas.

Sin política dirigida a roles admin (CA_NO_POLICY_ADMINS)

La política común de Acceso Condicional de Microsoft para administradores recomienda exigir MFA resistente a phishing en al menos catorce roles altamente privilegiados como mínimo: Administrador Global, Administrador de Roles Privilegiados, Administrador de Seguridad, Administrador de Acceso Condicional, Administrador de Usuarios, y otros con impacto en todo el tenant. Sin una política que se dirija específicamente a estos roles de directorio — en lugar de depender de una política MFA genérica para todos los usuarios que podría estar excluida o mal delimitada para los inicios de sesión admin — una credencial de administrador comprometida no encuentra ningún control de acceso adicional.

Sin política dirigida a todos los usuarios (CA_NO_POLICY_ALL_USERS)

Una política que se dirige a grupos o aplicaciones específicas no es lo mismo que una política que se dirige a Todos los usuarios. La documentación de Microsoft sobre la asignación de usuarios en Acceso Condicional señala que Todos los usuarios en una asignación de Acceso Condicional incluye tanto a los invitados B2B como a los miembros, que es exactamente el punto: la cobertura parcial de usuarios, construida grupo por grupo, tiende a pasar por alto el tipo de cuenta que a nadie se le ocurrió añadir. Un tenant con MFA sólida en su equipo de marketing y nada en contratistas o personal recién incorporado tiene esta brecha, aunque la lista de políticas parezca completa.

Sin cobertura de todas las apps en la nube (CA_NO_ALL_APPS_COVERAGE)

La guía de despliegue de Acceso Condicional de Microsoft afirma sin rodeos que "desde una perspectiva de seguridad, es mejor crear una política que incluya Todos los recursos (antes 'todas las apps en la nube')" precisamente porque el alcance aplicación por aplicación significa que cada nueva aplicación SaaS incorporada empieza desprotegida hasta que alguien recuerda añadirla a una política. Un tenant que solo redactó una política de Acceso Condicional para Exchange Online y el portal Azure ha dejado todos los demás recursos — incluyendo aplicaciones OAuth de terceros y Microsoft Graph — fuera de cualquier evaluación de Acceso Condicional, ya que los inicios de sesión hacia recursos no incluidos no están regidos por nada.

Sin requisito de cumplimiento de dispositivos (CA_NO_DEVICE_COMPLIANCE)

Microsoft documenta una política de Acceso Condicional que exige que los dispositivos que acceden a recursos estén marcados como conformes con las políticas de cumplimiento de Intune de la organización, o unidos de forma híbrida a Microsoft Entra. Sin ella, los inicios de sesión que satisfacen la MFA desde dispositivos no gestionados, sin parchear o personales llegan a los mismos recursos que los inicios de sesión desde un portátil corporativo endurecido y verificado como conforme — la MFA prueba quién inicia sesión, no que el dispositivo que usa sea seguro para confiarle la sesión.

⚠️

⚠️ Advertencia: Estas cuatro brechas son independientes entre sí. Un tenant puede exigir MFA para todos los usuarios y aun así no tener ninguna política específica para admins, o cubrir cada app en la nube con MFA sin exigir en ningún sitio el cumplimiento de dispositivos. Cada una debe verificarse por separado — cumplir una no implica que las demás estén cubiertas.

Por Qué "Tenemos Acceso Condicional" No Significa Que Exista Cobertura Base

Dos cosas dan regularmente a los tenants una falsa confianza de que estas cuatro brechas base están cerradas cuando no lo están.

Security Defaults no es un sustituto, y desaparece en el momento en que se crea cualquier política personalizada. Microsoft activa Security Defaults automáticamente para los tenants nuevos con el fin de ofrecer una base mínima de MFA, pero Security Defaults y las políticas de Acceso Condicional son mutuamente excluyentes — no pueden activarse al mismo tiempo. La trampa: un administrador que crea una única política de Acceso Condicional estrecha (por ejemplo, bloquear la autenticación legacy para un solo departamento) desactiva silenciosamente Security Defaults en todo el tenant en el mismo movimiento, aunque esa única política no cubra en absoluto los roles admin, todos los usuarios, todas las apps o el cumplimiento de dispositivos. El tenant termina con menos protección base que antes, mientras el centro de administración sigue mostrando "Acceso Condicional: configurado". Endurecimiento del tenant Azure: corregir defaults inseguros cubre esta y otras trampas de configuración predeterminada en tenants nuevos.

Las políticas gestionadas por Microsoft cubren un alcance más estrecho de lo que "base" sugiere, y arrancan en modo solo informe. Desde finales de 2023, Microsoft despliega automáticamente un conjunto de políticas de Acceso Condicional gestionadas por Microsoft a los tenants elegibles, incluyendo requisitos de MFA para admins y para todos los usuarios. Es una mejora genuina, pero dos límites importan para este artículo: primero, la política gestionada centrada en admins se dirige específicamente a los inicios de sesión hacia los portales de administración de Microsoft (portal Azure, centro de administración de Microsoft 365, centro de administración Entra, y similares), no a los inicios de sesión con rol admin hacia aplicaciones de negocio arbitrarias; segundo, Microsoft crea estas políticas en modo solo informe por defecto, que evalúa pero no aplica. Un tenant que depende de la política gestionada sin comprobar nunca si salió del modo solo informe tiene la misma exposición práctica que si no tuviera ninguna política — un modo de fallo distinto pero adyacente a la deriva en modo solo informe cubierta en Brechas acceso condicional Entra ID: que errores dejan una exposicion real.

Detección

Detectar brechas de cobertura base significa enumerar lo que realmente existe en el conjunto de políticas de Acceso Condicional del tenant — no lo que el tenant pretendía configurar.

Señal	Dónde comprobarlo	Qué te indica
Alcance `conditions.users` de la política en todas las políticas	Microsoft Graph `GET /identity/conditionalAccess/policies`, o `Get-MgIdentityConditionalAccessPolicy` (`Policy.Read.All`)	Si alguna política activada incluye `All` (todos) los usuarios/roles frente a solo grupos específicos — la comprobación directa para `CA_NO_POLICY_ALL_USERS` y `CA_NO_POLICY_ADMINS`
`conditions.users.includeRoles` de la política con los ID de roles de directorio admin	Misma consulta Graph, filtrada al estado activado	Confirma que existe una política dirigida específicamente a roles de directorio privilegiados, y no simplemente una regla MFA genérica para todos los usuarios que podría excluir a los admins
Valor `conditions.applications.includeApplications` de la política	Misma consulta Graph	`All` significa que existe cobertura de Todos los recursos/Todas las apps en la nube; cualquier otro valor significa que la política está limitada a aplicaciones específicas y cada aplicación no listada queda desprotegida
`grantControls` de la política que contiene `compliantDevice` o `domainJoinedDevice`	Misma consulta Graph	Confirma si alguna política aplicada exige realmente cumplimiento de dispositivos o unión híbrida, frente a solo MFA
Valor `state` de la política (`enabled` frente a `enabledForReportingButNotEnforced`)	Misma consulta Graph, o la pestaña Solo informe en el centro de administración	Distingue una política aplicada de una política gestionada por Microsoft o personalizada que aún está en modo solo informe — una política en modo solo informe no cierra la brecha
Libro de análisis de brechas de Acceso Condicional	Centro de administración Entra → Monitorización y estado → Libros → sección Acceso Condicional (requiere Lector de informes y un área de trabajo Log Analytics)	Diseñado específicamente para mostrar usuarios, aplicaciones y ubicaciones con nombre sin ninguna política de Acceso Condicional aplicada, usando evidencia real de inicio de sesión en lugar del texto de las políticas
Campo `conditionalAccessStatus` en las entradas de los registros de inicio de sesión	Registros de inicio de sesión del centro de administración Entra, o `GET /auditLogs/signIns`	`notApplied` en un inicio de sesión de un rol admin, un usuario estándar o un dispositivo no gestionado es la confirmación en tiempo real de que la brecha base correspondiente es real, no teórica

💡

💡 Consejo: Revisión de políticas antes que revisión de inicios de sesión. Un libro de análisis de brechas o una consulta de registros de inicio de sesión solo muestra evidencia de identidades y aplicaciones que realmente iniciaron sesión durante la ventana de observación. Enumerar primero el conjunto de políticas vía Graph indica de forma definitiva si las cuatro políticas base existen, independientemente de si alguien disparó la brecha ese día.

Remediación: cerrar las brechas de cobertura

Despliega primero una política MFA dedicada a roles admin. Dirígete al conjunto documentado de roles altamente privilegiados (Administrador Global, Administrador de Roles Privilegiados, Administrador de Seguridad, Administrador de Acceso Condicional, y el resto de la lista de roles admin de la política común de Microsoft — ver Acceso privilegiado Azure: roles, PIM y administracion permanente para el contexto completo de estos roles), exige MFA o una fuerza de autenticación superior, y excluye solo las cuentas break-glass — ver Cuentas de Acceso de Emergencia Break Glass Entra ID antes de crear esa exclusión.
Despliega una política base para todos los usuarios, dirigida a Todos los usuarios y Todos los recursos. Evita el alcance aplicación por aplicación o grupo por grupo para la capa base; añade políticas más estrechas y fuertes encima para aplicaciones específicas de alto valor en lugar de intentar enumerar cada aplicación que necesita la base.
Añade un requisito de cumplimiento de dispositivos o unión híbrida para, como mínimo, el mismo conjunto de roles admin y recursos sensibles cubierto arriba, usando las políticas de cumplimiento de Intune como fuente de aplicación.
Comprueba si existen políticas gestionadas por Microsoft y si siguen en modo solo informe. Si es así, o bien pásalas a aplicadas tras una ventana de revisión validada, o reemplázalas por políticas propiedad del tenant que cubran el alcance más amplio descrito en este artículo, en lugar de solo los portales de administración de Microsoft.
Si Security Defaults fue desactivado silenciosamente por una política estrecha anterior, no te limites a reactivarlo — reemplázalo por las políticas base explícitas anteriores; Security Defaults y el Acceso Condicional personalizado siguen siendo mutuamente excluyentes, y reactivarlo eliminaría la política más estrecha que motivó la pregunta en primer lugar.
Valida con la herramienta What If y el libro de análisis de brechas para una cuenta admin representativa, un usuario estándar representativo y un dispositivo no gestionado representativo antes de considerar cerrada la brecha — la configuración de la política y su aplicación confirmada no son la misma evidencia.

Cómo Detecta Esto EtcSec

Las comprobaciones Azure/Entra de EtcSec se corresponden directamente con las cuatro brechas de este artículo: CA_NO_POLICY_ADMINS y CA_NO_POLICY_ALL_USERS señalan la ausencia de cualquier política activada dirigida a roles admin o a todos los usuarios respectivamente, CA_NO_ALL_APPS_COVERAGE señala la ausencia de una política que cubra todas las apps en la nube/recursos, y CA_NO_DEVICE_COMPLIANCE señala la ausencia de cualquier control de concesión de cumplimiento de dispositivos. AZ_SECURITY_DEFAULTS_NO_CA detecta la trampa específica descrita arriba: Security Defaults desactivado sin una base de Acceso Condicional compensatoria en su lugar.

ℹ️

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

Brechas de Cobertura de Política Base de Acceso Condicional Entra ID: Sin Política para Administradores, Todos los Usuarios o Todas las Aplicaciones