El Acceso Condicional (CA) de Microsoft Entra ID es el principal mecanismo de control de acceso para organizaciones en Microsoft 365 y Azure. Sin embargo, configurarlo correctamente requiere atender múltiples escenarios que pueden quedar cubiertos solo parcialmente. TecnetSOC evalúa automáticamente tu configuración de CA contra 13 mejores prácticas y te indica exactamente qué falta. Este artículo explica cada brecha, cómo interpretarla, y cómo remediarla.
---
El análisis de brechas de CA se ejecuta en cada sincronización con Entra ID (cada 2 horas). Lee todas tus políticas de Acceso Condicional y verifica si cubren los 13 escenarios de seguridad más importantes. El resultado es un score de postura de 0% a 100%, donde 100% significa que las 13 mejores prácticas están implementadas.
El análisis detecta tanto la ausencia de políticas como políticas que existen pero están en modo Report-Only (monitoreo sin aplicación). Las políticas en modo Report-Only no cuentan como implementadas — deben estar en modo "Enabled" para puntuar.
Nota: El análisis verifica la existencia y configuración de las políticas, pero no valida su lógica interna en detalle. Una política mal configurada (por ejemplo, que excluye a demasiados usuarios) puede pasar el análisis pero no proteger efectivamente.
---
Qué verifica: Existe una política que requiere MFA para todos los usuarios (o casi todos) al acceder a cualquier aplicación en la nube.
Por qué importa: Sin esta política, los usuarios pueden acceder a aplicaciones corporativas solo con contraseña. Es el control más básico y el que más reduce el riesgo de compromiso de cuentas.
Cómo remediar: En Entra Admin Center → Protection → Conditional Access → + New policy:
Qué verifica: Existe una política que requiere MFA específicamente para roles administrativos, incluso si ya existe la política general de GAP-01.
Por qué importa: Los administradores son el objetivo principal de los atacantes. Una política dedicada permite aplicar controles más estrictos (como requerir métodos resistentes a phishing) solo para ellos.
Cómo remediar: Similar a GAP-01, pero en Usuarios selecciona "Directory roles" y elige todos los roles administrativos relevantes.
---
Qué verifica: Existe una política que bloquea los protocolos de autenticación heredados (SMTP básico, IMAP, POP3, ActiveSync antiguo).
Por qué importa: Los protocolos heredados no soportan MFA. Un atacante que use autenticación heredada con una contraseña comprometida puede saltar todos los controles de CA que requieren MFA. Microsoft reporta que más del 97% de los ataques de password spray usan autenticación heredada.
Cómo remediar: En la política de CA, en la condición "Client apps", selecciona "Exchange ActiveSync clients" y "Other clients". En Controles, selecciona "Block access".
---
Qué verifica: Existe una política que requiere que el dispositivo desde el que se accede sea conforme con Intune o unido a Hybrid Azure AD.
Por qué importa: Esta política asegura que solo dispositivos corporativos administrados puedan acceder a los recursos. Un atacante con credenciales válidas desde un dispositivo personal o desconocido sería bloqueado.
Cómo remediar: En Controles de la política de CA, selecciona "Require device to be marked as compliant" o "Require Hybrid Azure AD joined device". Requiere Intune o Hybrid AD configurado.
---
Qué verifica: Existe una política que aplica MFA cuando Identity Protection detecta un sign-in de riesgo medio o alto.
Por qué importa: Los sign-ins de riesgo incluyen accesos desde IPs anónimas (Tor/VPN), viaje imposible, y patrones de ataque conocidos. Sin esta política, estos accesos se permiten sin verificación adicional.
Cómo remediar: En la política de CA, en Condiciones selecciona "Sign-in risk" → High y Medium. En Controles, selecciona "Require MFA". Requiere Entra ID P2.
---
Qué verifica: Existe una política que aplica controles cuando Identity Protection marca a un usuario con nivel de riesgo medio o alto.
Por qué importa: El riesgo de usuario es diferente al riesgo de sign-in: indica que la cuenta misma está probablemente comprometida (credenciales filtradas, comportamiento anómalo persistente). Sin esta política, las cuentas comprometidas pueden seguir operando normalmente.
Cómo remediar: En Condiciones selecciona "User risk" → High y Medium. En Controles, selecciona "Require password change" y "Require MFA". Requiere Entra ID P2.
---
Qué verifica: Existe una política que bloquea completamente los sign-ins clasificados como de alto riesgo por Identity Protection.
Por qué importa: A diferencia de GAP-05 (que requiere MFA), esta política bloquea directamente los accesos de mayor riesgo. Es una defensa más agresiva para escenarios donde MFA podría no ser suficiente (por ejemplo, ataques de token replay).
Cómo remediar: En Condiciones → Sign-in risk selecciona "High". En Controles, selecciona "Block access". Requiere Entra ID P2.
---
Qué verifica: Las políticas de CA no tienen más de 2-3 cuentas en sus grupos de exclusión.
Por qué importa: Cada cuenta excluida de CA es una puerta trasera potencial. Las únicas cuentas que deberían estar excluidas son las cuentas de break-glass (acceso de emergencia). Si hay más exclusiones, la política pierde efectividad.
Cómo remediar: Revisa los grupos de exclusión de cada política en Entra Admin Center → Conditional Access. Elimina todas las exclusiones que no sean cuentas de break-glass. Si necesitas exclusiones temporales, usa grupos con fecha de expiración.
---
Qué verifica: Existe una política que requiere dispositivos conformes (Intune) o unidos a Hybrid AD específicamente para roles administrativos.
Por qué importa: Los administradores manejan los controles más críticos del tenant. Si un administrador inicia sesión desde un dispositivo personal comprometido, el atacante obtiene control total. Requerir dispositivos gestionados añade una capa de seguridad física.
Cómo remediar: Crea una política dirigida a Directory Roles (Global Admin, Security Admin, etc.) con Controles → Require device to be marked as compliant. Requiere Intune configurado.
---
Qué verifica: Existen políticas que limitan la duración de sesión o requieren reevaluación frecuente para aplicaciones críticas.
Por qué importa: Sesiones de larga duración significan que aunque revoques el acceso de un usuario, un atacante con un token robado puede seguir accediendo hasta que expire. Limitar la frecuencia de sign-in reduce esta ventana.
Cómo remediar: En Controles de sesión de la política de CA, configura "Sign-in frequency" en 1-4 horas para aplicaciones sensibles (Azure Portal, Exchange Admin, SharePoint Admin).
---
Qué verifica: Existen políticas que aplican controles diferentes según la ubicación geográfica o red de origen del acceso.
Por qué importa: El acceso desde fuera de ubicaciones conocidas tiene mayor riesgo. Usar Named Locations permite diferenciar entre accesos desde la oficina (menor riesgo) y accesos remotos (mayor riesgo).
Cómo remediar: Primero define tus IPs corporativas en CA → Named Locations. Luego crea políticas que requieran MFA o bloqueen acceso desde ubicaciones fuera de las definidas.
---
Qué verifica: Ningún flujo de acceso permite autenticación con solo usuario y contraseña, sin un segundo factor.
Por qué importa: El acceso solo con contraseña es el vector de ataque más explotado. Si cualquier aplicación o flujo permite acceso sin MFA, es una brecha crítica que puede explotarse con credenciales filtradas.
Cómo remediar: Verifica que la política de MFA para todos los usuarios (GAP-01) no tenga exclusiones que permitan acceso password-only. Bloquea también la autenticación heredada (GAP-03) que inherentemente no soporta MFA.
---
Qué verifica: Existen políticas de CA específicas para usuarios de tipo Guest (B2B) que aplican controles apropiados.
Por qué importa: Los usuarios invitados (proveedores, partners) acceden a recursos corporativos pero generalmente no están bajo las mismas políticas que los empleados. Sin políticas específicas, pueden acceder sin MFA o desde dispositivos no gestionados.
Cómo remediar: Crea una política dirigida a "Guest or external users" que requiera MFA y limite las aplicaciones a las que pueden acceder. Considera también requerir Terms of Use.
---
El score de postura de CA es el porcentaje de las 13 brechas que han sido remediadas con políticas activas (no Report-Only).
| Rango | Interpretación |
|---|---|
| 0% — 30% | Postura crítica: la mayoría de los vectores de acceso no están controlados |
| 31% — 60% | Postura débil: los controles básicos existen pero hay brechas significativas |
| 61% — 85% | Postura aceptable: cobre los casos principales, con oportunidades de mejora |
| 86% — 100% | Postura sólida: implementación madura de Acceso Condicional |
El score de postura se muestra en el Dashboard de Identidades como parte del resumen de Acceso Condicional.
Nota: Un score de 100% no garantiza que no haya brechas. El análisis verifica la existencia de políticas, no su correcta configuración interna. Siempre revisa que las políticas no tengan exclusiones excesivas o condiciones que las neutralicen.
---
Define siempre tus rangos de IPs corporativas en Named Locations. Esto te permite crear políticas diferenciadas para acceso interno vs. externo sin tener que crear políticas complejas por usuario.
Cada exclusión es una brecha potencial. Las únicas cuentas que deben estar excluidas de políticas críticas son las cuentas de break-glass. Si necesitas excluir usuarios temporalmente, usa grupos con fecha de expiración.
Al crear nuevas políticas, empiézalas en modo Report-Only por 48-72 horas. Revisa los logs para confirmar que no bloquearía usuarios legítimos antes de activarla. TecnetSOC te mostrará estas políticas en Report-Only como brechas pendientes de activación.
Usa las descripciones de las políticas en Entra ID para documentar qué protege cada una, quién la aprobó, y cuándo fue implementada. Esto facilita las auditorías y la revisión periódica.
Los grupos de exclusión tienden a crecer con el tiempo. Establece un proceso trimestral para revisar quién está excluido de qué políticas y confirmar que las exclusiones siguen siendo necesarias.
---
Última actualización: Abril 2026 | TecnetOne Knowledge Base