Brechas acceso condicional Entra ID: que errores dejan una exposicion real

Brechas acceso condicional Entra ID: esa es la forma mas directa de nombrar la diferencia entre policies que parecen amplias en el admin center y controles que realmente evaluan los users, guests, apps, protocols y workload identities que importan en produccion. Un tenant puede mostrar una cobertura de Conditional Access aparentemente correcta y aun asi dejar una exposicion real por exclusiones, protocolos legacy, rutas guest o service principals que nunca estuvieron en el scope correcto.

Este articulo trata Conditional Access como un problema de evidencia, no como un problema de capturas. El objetivo es explicar que cuenta como una brecha real, que senales de Microsoft la prueban, como remediarla sin provocar lockout operativo y como validar que el estado mas seguro si quedo aplicado despues del cambio. Para una revision mas amplia del tenant, empieza por Como auditar la seguridad de Microsoft Entra ID (Azure AD): guia practica.

Brechas acceso condicional Entra ID: que cuenta como una brecha real?

Una brecha de Conditional Access es cualquier desajuste entre la policy que crees imponer y los sign-ins que Microsoft Entra evalua de verdad. Microsoft describe Conditional Access como un motor de policy que combina senales, aplica assignments y conditions, y luego concede, bloquea o restringe el acceso. El mecanismo es potente, pero no se prueba solo. Una policy solo reduce riesgo si apunta a las identidades y resources correctas, evalua la ruta de protocolo adecuada y deja evidencia en sign-in logs y audit logs.

En la practica, una brecha suele aparecer en alguno de estos casos:

• falta por completo una policy para un scope sensible
• existe una policy, pero excluye a los users o roles que mas importan
• una policy protege users, pero no workload identities
• una policy apunta a las resources o rutas cliente equivocadas
• una policy usa un grant demasiado debil para la resource que protege
• una policy sigue en report-only y nunca pasa a enforcement

Microsoft tambien recuerda que Conditional Access se evalua despues del primer factor de autenticacion. Por eso no hay que presentar Conditional Access como un control magico “antes de la autenticacion”. Es una capa de decision alrededor de un sign-in, y la calidad de esa decision depende del scope, la telemetry y el diseno de la policy.

Por Que Conditional Access Puede Seguir Dejando una Exposicion Real

Muchas organizaciones piensan en Conditional Access como un estado binario: activado o no activado. La exposicion real es mas desordenada. Microsoft Entra evalua todas las policies que aplican a un sign-in y el usuario debe satisfacer todos los requisitos aplicables antes de que el acceso sea concedido. El problema es que muchos sign-ins que deberian estar gobernados nunca llegan a ser “aplicables” en la practica.

El primer ejemplo es la deriva de scope. Los equipos de seguridad suelen creer que una policy amplia cubre a todos porque usa All users. Microsoft documenta que All users incluye B2B guests, lo cual es util, pero eso no significa que todas las rutas de identidad esten cubiertas. Las workload identities son una clase de asignacion distinta y las policies scopeadas a users no gobiernan automaticamente los service principals. Si el tenant depende de app registrations, automatizacion o integraciones backend, hay que revisarlo con la misma seriedad que a los usuarios humanos.

El segundo ejemplo es la diferencia entre un grant amplio y un grant fuerte. Require multifactor authentication y Require authentication strength no son el mismo control. Si la expectativa del negocio es autenticacion resistente al phishing para roles admin o aplicaciones sensibles, un simple requisito MFA puede ser mas debil que la intencion real. Por eso Seguridad de Identidad Azure: Por que el MFA por si solo no basta y MFA Fatigue: deteccion y prevencion en Microsoft Entra ID suelen ir de la mano con una revision de Conditional Access.

El ultimo problema recurrente es la deriva de validacion. Las policies acumulan exclusiones, borradores en report-only, templates superpuestas y excepciones de emergencia. El portal sigue mostrando muchas policies, pero los sign-ins importantes pueden seguir entrando sin challenge o ser evaluados por rutas mas debiles de lo previsto.

Brechas de Scope: Users, Guests, Roles, Resources y Workload Identities

Users, directory roles y exclusions

El primer paso de revision es mapear a quien apuntan realmente las policies. Conditional Access puede incluir o excluir todos los users, users y groups seleccionados, directory roles, guests y external users, ademas de workload identities. Un tenant con buena cobertura user todavia puede dejar roles privilegiados o exclusions privilegiadas mal gobernadas. Esto es aun mas relevante si el acceso privilegiado ya es excesivo, como en Acceso privilegiado Azure: roles, PIM y administracion permanente.

Las emergency access accounts son el ejemplo mas claro de exclusion intencional. Microsoft recomienda excluirlas de las policies de Conditional Access para evitar lockout del tenant, pero esa recomendacion no justifica exclusions de comodidad. Cada exclusion debe tener una razon estrecha, un owner y monitorizacion activa. Si la misma break-glass se usa para administracion normal, la brecha es operativa, no teorica.

Guests y external users

El acceso guest y externo merece su propia revision, no una suposicion rapida de que All users ya lo resolvio. Microsoft Entra permite apuntar a tipos concretos de guests y external users, y el comportamiento externo tambien depende de cross-tenant trust settings. Por ejemplo, cuando usas authentication strengths para external users, Microsoft documenta que el resource tenant tambien evalua la confianza MFA del home tenant. Eso significa que la cobertura guest no es solo una cuestion de que exista una policy. Es una cuestion de scope y trust. Por eso Cuentas invitado Azure: gobierno, MFA y riesgo de acceso externo suele formar parte de la misma revision.

Resources, apps y user actions

Otra brecha de scope consiste en proteger el conjunto equivocado de resources. Las policies pueden asignarse a todas las resources o a resources seleccionadas. Si el tenant protege los admin portals de Microsoft pero no las aplicaciones de negocio o SaaS a las que los users llegan primero, la historia de control queda incompleta. El mismo problema aparece cuando el equipo se queda con una captura de una cloud app en vez de revisar la ruta real de resource que un atacante reutilizaria despues de un robo de credenciales o sesion. Los ataques que abusan de sesiones validas o de rutas OAuth suelen encadenarse con estas brechas, de ahi que Device Code Phishing: como OAuth Device Flow compromete cuentas Entra ID sea un articulo claramente relacionado.

Workload identities

Los service principals y las workload identities son el punto ciego mas frecuente en tenants por lo demas maduros. Microsoft documenta que las llamadas hechas por service principals no son bloqueadas por policies de Conditional Access scopeadas a users, y que debe usarse Conditional Access para workload identities cuando esas identidades necesiten tratamiento de policy. En la practica, esto significa que un tenant puede mostrar una buena cobertura MFA user mientras deja fuera del modelo Conditional Access a identidades de automatizacion y de aplicacion.

Eso no significa que todas las workload identities deban recibir la misma policy. Significa que el tenant debe demostrar que sabe que workload identities existen, cuales quedan fuera por diseno y cuales siguen dependiendo de patrones mas debiles que deberian migrarse a managed identities cuando sea posible.

Brechas de Control: MFA, Authentication Strengths, Legacy Authentication y Risk Policies

La cobertura MFA no es lo mismo que un diseno de autenticacion fuerte

Un tenant puede tener muchas policies que exigen MFA y aun asi dejar accesos de alto valor sobre metodos mas debiles de lo esperado. Microsoft documenta authentication strengths como un control de Conditional Access que restringe que combinaciones de metodos pueden usarse para acceder a una resource. Esa distincion importa siempre que el objetivo de la policy sea mas fuerte que “cualquier MFA sirve”. Para roles admin o aplicaciones sensibles, la diferencia entre un grant MFA amplio y una exigencia resistente al phishing o passwordless debe ser explicita.

Legacy authentication sigue siendo una brecha real cuando todavia esta disponible

Legacy authentication necesita precision porque a menudo se describe de forma demasiado vaga. Microsoft indica que los protocolos legacy no soportan MFA y no transmiten estado del dispositivo. Microsoft tambien recomienda bloquear las requests de autenticacion que usen esos protocolos y senala que esas rutas siguen muy presentes en campanas de password spraying y credential stuffing.

La formulacion defensable es esta: legacy authentication es una brecha cuando esos protocolos siguen disponibles para identidades o resources que el tenant cree protegidas por requisitos modernos de Conditional Access. Algunos tenants cierran esa brecha con una policy dedicada de bloqueo. Otros se apoyan en grants mas amplios para todos los client apps. La buena revision no consiste en copiar un template. Consiste en demostrar, con sign-in logs, que los clientes legacy estan bloqueados o ausentes. Si el tenant ya esta revisando debilidad de primer factor, enlazalo con Password Spraying: deteccion y prevencion en Active Directory y Entra ID.

Las risk policies no vienen implicitas en una buena madurez de Conditional Access

Un tenant sin policies de sign-in risk o user risk no esta automaticamente mal configurado, porque esas policies dependen de capacidades de Microsoft Entra ID Protection y del nivel de licencia adecuado. Pero si el discurso de seguridad afirma que el acceso se adapta al riesgo, el tenant debe probar que esos controles existen y se aplican. Microsoft documenta las sign-in risk policies por separado y deja clara la dependencia de P2. Si el tenant no licencia o no usa esa capacidad, hay que decirlo de forma directa en lugar de insinuar un control inexistente. Vease tambien Azure Identity Protection: Politicas de Riesgo.

Deteccion

La deteccion de brechas de acceso condicional Entra ID es un ejercicio de correlacion, no una alerta basada en un unico campo.

Revisar primero la evidencia de sign-in

Los sign-in logs de Microsoft Entra son la fuente principal de prueba. Para sign-ins interactivos y no interactivos, revisa al menos estas dimensiones:

La matizacion importante es esta: un sign-in exitoso con conditionalAccessStatus = notApplied no basta por si solo. La pregunta real es si ese sign-in deberia haber sido gobernado segun el diseno del propio tenant.

Revisar audit logs para detectar deriva de policy

Los audit logs son la segunda fuente de prueba. Usalos para revisar creacion de policies, actualizaciones, cambios de enablement, transiciones a report-only, cambios de exclusions y eliminaciones. Si un tenant cambia el scope de Conditional Access una y otra vez sin conservar evidencia del porque, la brecha real es tanto una deriva de gobernanza como un problema de diseno.

Revisar el estado de la policy, no solo su texto

El modo report-only y la herramienta What If son utiles, pero responden preguntas distintas. report-only ayuda a estimar impacto sin enforcement. What If ayuda a simular que policies aplicarian a un sign-in de user o de service principal. Ninguno sustituye a la evidencia de produccion. Una revision madura usa ambos y luego confirma el resultado en datos reales de sign-in.

Remediation y remediacion

La remediacion debe cerrar primero las brechas de scope y de control con mayor impacto.

1. Establecer una baseline amplia para users y resources. El tenant debe poder senalar las policies base que protegen el acceso de usuario normal sobre las resources que importan, no solo un admin portal o una aplicacion favorita.

2. Revisar exclusions antes de anadir nuevas policies. Si las exclusions ya esconden admins, guests o grupos de alto valor, nuevas policies pueden dar una falsa sensacion de avance mientras dejan intacta la exposicion real.

3. Bloquear o eliminar rutas de legacy authentication. Cuando Conditional Access esta disponible, usa scope de policy y validacion para bloquear legacy authentication. Cuando sigan existiendo dependencias de servicio o aplicacion, documentalas explicitamente y tratalas como excepciones a retirar, no como hipotesis permanentes de diseno.

4. Separar la cobertura user de la cobertura workload identity. Si el tenant depende de service principals, automatizacion o identidades de aplicacion, debe existir una via de revision distinta para workload identities. No asumas que las policies de users ya hicieron ese trabajo.

5. Usar authentication strengths cuando el objetivo de acceso sea mas fuerte que un MFA generico. Aplicaciones sensibles, accesos externos y roles privilegiados suelen necesitar algo mas que un grant MFA amplio.

6. Anadir risk policies solo cuando el tenant pueda operarlas de verdad. Si la evaluacion de riesgo basada en P2 forma parte del discurso de seguridad, la evidencia debe demostrarlo. Si no esta licenciada o desplegada, el articulo debe tratarlo como una limitacion consciente, no como madurez oculta.

Validacion Despues de Cambios en las Policies

La validacion es donde mas fracasa el trabajo de Conditional Access.

Primero, usa What If para verificar la aplicacion esperada de las policies en users representativos, roles admin, guests y service principals. Segundo, usa report-only cuando corresponda para entender el blast radius antes del enforcement. Tercero, confirma el resultado real en sign-in logs despues de habilitar la policy.

Esa validacion debe responder preguntas concretas:

• los users previstos pasan por las policies previstas?
• las cuentas excluidas siguen excluidas de forma intencional y monitorizada?
• los sign-ins guest siguen la ruta de policy esperada?
• las workload identities siguen fuera de controles scopeados a users?
• los intentos con clients legacy ahora fallan o desaparecen?
• si se introdujeron authentication strengths, los sign-ins afectados muestran en la practica la fortaleza esperada?

Un tenant que no pueda responder a esas preguntas con evidencia de sign-in y audit no ha terminado la remediacion.

Evidencia que Conviene Conservar Entre Revisiones

Conditional Access deriva en silencio, asi que el paquete de evidencia importa.

Ese conjunto de evidencia es lo que permite que la siguiente revision mida la deriva en lugar de volver a empezar desde cero. Si el tenant tambien necesita un encuadre mas amplio para cumplimiento, Requisitos NIS2 de seguridad de identidad: que deben demostrar los equipos de AD y Entra es el articulo complementario correcto, no un sustituto de esta revision tecnica.

Como EtcSec Ayuda a Medir las Brechas de Acceso Condicional

Aqui, EtcSec debe posicionarse de forma estrecha: no como un detector magico de sign-ins, sino como una forma de volver a medir con el tiempo condiciones estructurales de brecha en Conditional Access.

Para este articulo, los findings realmente relevantes son los que ya corresponden a problemas reales de diseno de policy:

• CA_NO_MFA_REQUIREMENT
• CA_NO_LEGACY_AUTH_BLOCK
• CA_NO_RISK_BASED_SIGNIN
• LEGACY_AUTH_ALLOWED

Ese mapeo es util porque sostiene una revision recurrente. El tenant puede volver a auditar despues de cambios en las policies y confirmar si las mismas brechas estructurales siguen existiendo, en lugar de tratar Conditional Access como una simple configuracion inicial.

Referencias Primarias

• What is Conditional Access?
• Conditional Access: Users, groups, agents, and workload identities
• How to use conditions in Conditional Access policies
• Block legacy authentication with Conditional Access
• Troubleshoot Conditional Access policies with the What If tool
• Analyze Conditional Access policy impact with report-only mode
• How Conditional Access authentication strengths work
• Conditional Access authentication strength for external users
• Conditional Access for workload identities
• Manage emergency access administrative accounts in Microsoft Entra ID
• Require multifactor authentication for elevated sign-in risk
• What are Microsoft Entra sign-in logs?
• signIn resource type - Microsoft Graph v1.0
• Audit logs in Microsoft Entra ID