Active Directory

Entra ID: Acceso Condicional y Políticas Básicas

Entra ID: Acceso Condicional y Políticas Básicas

El acceso condicional de Entra ID (anteriormente Azure Active Directory) es la columna vertebral de la seguridad basada en la identidad en la nube. Permite aplicar controles de acceso granulares basados en condiciones específicas, como la ubicación del usuario, el estado del dispositivo, la aplicación a la que se intenta acceder y el nivel de riesgo detectado. No es una funcionalidad adicional, sino un elemento fundamental para proteger los recursos y garantizar el cumplimiento. Lee también: GDPR Admin. Sistema: Obligación y Rol

Estas políticas son cruciales para mitigar ataques como el relleno de credenciales (credential stuffing), el phishing y los ataques de repetición (replay attacks), que explotan credenciales débiles o robadas. Implementar un conjunto de políticas básicas es el primer paso para cualquier organización que utilice Entra ID, independientemente de su tamaño o sector. Te permite reforzar la seguridad sin comprometer la usabilidad para los usuarios legítimos, aplicando controles solo cuando y donde sea necesario.

Entra ID: Acceso Condicional en 60 segundos

Para configurar y gestionar rápidamente las políticas de acceso condicional en Entra ID, estos son los comandos esenciales desde PowerShell, usando el módulo Microsoft.Graph:

# Instalación del módulo Microsoft.Graph (si no está ya presente)
Install-Module -Name Microsoft.Graph -Scope CurrentUser

# Conexión a Microsoft Graph con los permisos necesarios para leer las políticas
Connect-MgGraph -Scopes Policy.Read.All

# Listado de las políticas de acceso condicional existentes y su estado
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State

# Visualizar los registros de acceso con fallos de acceso condicional (últimos 20)
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 20

# Desconexión de la sesión Graph
Disconnect-MgGraph

Versiones de referencia: Microsoft Entra ID (la versión estable actual, consultada en noviembre de 2026) · documentación consultada en noviembre de 2026

Qué es el acceso condicional y qué licencia se necesita

El acceso condicional es el motor de políticas de Entra ID que permite implementar reglas «si-entonces». Por ejemplo: si un usuario intenta acceder desde una ubicación desconocida, entonces solicita la autenticación multifactor (MFA). Esto permite cambiar el enfoque de la simple verificación de la contraseña a una evaluación del riesgo en tiempo real para cada intento de acceso. Las políticas se aplican antes de que el usuario acceda al recurso, añadiendo un nivel de protección proactivo.

Para utilizar el acceso condicional, se necesita una licencia Entra ID P1 o P2. La P1 ofrece las funcionalidades básicas, mientras que la P2 añade funcionalidades avanzadas como la integración con Identity Protection para detectar riesgos en tiempo real (por ejemplo, credenciales comprometidas, accesos desde IP anómalas) y automatizar las respuestas. Sin una de estas licencias, la funcionalidad no estará disponible o estará limitada a un subconjunto de políticas predefinidas.

Requisitos Previos

Antes de implementar cualquier política de acceso condicional, asegúrate de tener:

  • Licencia Entra ID P1 o P2: Verifica que todos los usuarios a los que se aplicarán las políticas tengan la licencia adecuada.
  • MFA habilitada y configurada: Los usuarios deben haber registrado al menos un método MFA (ej. Microsoft Authenticator, SMS, llamadas) para poder satisfacer los requisitos de las políticas MFA.
  • Cuentas de emergencia: Identifica y crea al menos dos cuentas de emergencia (break-glass accounts) con privilegios elevados, excluidas de cualquier política de acceso condicional. Estas cuentas son cruciales para recuperar el acceso al inquilino en caso de una configuración errónea de las políticas.
  • Grupos de seguridad: Utiliza grupos de seguridad de Entra ID para asignar las políticas. Esto simplifica la gestión y reduce el riesgo de errores en comparación con la asignación a usuarios individuales. Crea grupos para administradores, usuarios estándar, usuarios con necesidades particulares, etc.
  • Planificación y comunicación: Informa a los usuarios sobre las nuevas políticas y cómo podrían afectar su acceso. Una comunicación clara reduce la resistencia y los tickets de soporte.

1. Primera regla: excluir las cuentas de emergencia

Este es el paso más crítico y a menudo pasado por alto. Las cuentas de emergencia, o ‘break-glass accounts’, son cuentas con privilegios elevados (como Global Administrator) que se utilizan solo en situaciones de emergencia, por ejemplo, si todas las políticas de acceso condicional bloquean inadvertidamente el acceso a todos los administradores. Estas cuentas deben ser excluidas de todas las políticas de acceso condicional. Si no lo haces, podrías encontrarte en una situación en la que nadie pueda acceder al inquilino para corregir un error de configuración, lo que resultaría en un bloqueo total.

La protección de estas cuentas se basa en controles procedimentales y físicos (ej. credenciales conservadas en una caja fuerte, monitoreo intensivo de los accesos), en lugar de en políticas de acceso condicional que podrían bloquearlas. Microsoft recomienda configurar al menos dos de estas cuentas. Su actividad debe ser monitoreada constantemente a través de registros de auditoría y alertas específicas para detectar cualquier uso indebido.

2. MFA obligatoria para los administradores

Esta es la política más importante para la seguridad de tu inquilino. Las cuentas con roles administrativos (Global Administrator, Application Administrator, Exchange Administrator, SharePoint Administrator, etc.) son objetivos primarios para los atacantes. La compromiso de una de estas cuentas puede llevar a un control total de tu entorno. Requerir MFA para los administradores reduce drásticamente el riesgo de accesos no autorizados, incluso si la contraseña es robada.

Cómo configurarla:

  1. Navega a Entra ID > Protección > Acceso condicional > Nueva política.
  2. Asigna un nombre significativo, por ejemplo «MFA – Administradores».
  3. En Usuarios o cargas de trabajo de identidad > Incluir, selecciona Roles de directorio y elige todos los roles administrativos relevantes (ej., Global Administrator, Security Administrator, Cloud Application Administrator, etc.).
  4. En Controles de acceso > Conceder, selecciona Requerir autenticación multifactor.
  5. Establece la política en Activa (después de haberla probado en modo solo informe, como veremos más adelante).

Esta política es un requisito estándar para el cumplimiento de normativas como NIS2 (Art. 21) e ISO 27001:2022, que enfatizan la protección de las cuentas privilegiadas. Lee también: NIS2: Obligaciones y Adaptación de Empresas

3. Bloquear la autenticación heredada

La autenticación heredada se refiere a protocolos como POP3, IMAP, SMTP, MAPI y otras API que no admiten la autenticación moderna y, en consecuencia, la MFA. Estos protocolos son un vector de ataque común, ya que permiten a los atacantes intentar accesos con credenciales robadas sin tener que enfrentar el desafío de MFA. La deshabilitación de la autenticación heredada es una recomendación de seguridad clave de Microsoft y CISA.

Cómo configurarla:

  1. Crea una nueva política de acceso condicional, por ejemplo «Bloqueo Autenticación Heredada».
  2. En Usuarios o cargas de trabajo de identidad > Incluir, selecciona Todos los usuarios (o un grupo específico si quieres aplicarla gradualmente).
  3. En Aplicaciones en la nube o acciones > Incluir, selecciona Todas las aplicaciones en la nube.
  4. En Condiciones > Clientes de aplicación, selecciona Sí y luego marca Clientes de correo electrónico/protocolos de autenticación heredados.
  5. En Controles de acceso > Bloquear acceso.
  6. Establece la política en Activa.

Un resultado típico al listar el estado de las políticas después de la creación:

DisplayName                           State
----------                           -----
MFA - Administradores                 Enabled
Bloqueo Autenticación Heredada         Enabled

Atención: antes de activar esta política para todos los usuarios, verifica el uso de clientes heredados en tu entorno. Herramientas como Outlook 2010 o algunas aplicaciones de terceros podrían dejar de funcionar. Monitoriza los registros de acceso para identificar a los usuarios y las aplicaciones que los utilizan.

4. MFA para todos los usuarios, con las excepciones correctas

Después de proteger a los administradores y bloquear los protocolos heredados, el siguiente paso es extender la MFA a todos los usuarios. Esto eleva significativamente la postura de seguridad general del inquilino. Sin embargo, aplicar MFA de manera indiscriminada puede crear fricciones para los usuarios. Aquí es donde las condiciones de acceso condicional se vuelven útiles para crear excepciones basadas en escenarios específicos.

Cómo configurarla:

  1. Crea una nueva política, por ejemplo «MFA – Todos los usuarios».
  2. En Usuarios o cargas de trabajo de identidad > Incluir, selecciona Todos los usuarios. En Excluir, añade las cuentas de emergencia y, si es necesario, grupos específicos de usuarios que no deben usar MFA (ej. cuentas de servicio, pero con mucha cautela).
  3. En Aplicaciones en la nube o acciones > Incluir, selecciona Todas las aplicaciones en la nube.
  4. En Controles de acceso > Conceder, selecciona Requerir autenticación multifactor.
  5. En Condiciones puedes añadir excepciones:
  • Ubicaciones: Excluye las ubicaciones de red definidas como de confianza (ej. la red corporativa con IP públicas conocidas). Esto permite a los usuarios no tener que hacer MFA cuando están en la oficina. Lee también: Zabbix Agent 2: Instalación, Configuración y Plugins
  • Dispositivos: Requiere que el dispositivo sea «Conforme» o «Unido a Azure AD Híbrido» para omitir la MFA, incentivando el uso de dispositivos gestionados y seguros.
  1. Establece la política en Solo informe inicialmente, para luego activarla.

5. Usar el modo solo informe antes de activar

Cada nueva política de acceso condicional, o modificación significativa a una existente, debe implementarse primero en modo Solo informe. Este modo te permite simular la aplicación de la política sin que esta influya realmente en el acceso de los usuarios. Los resultados se registran en los registros de acceso de Entra ID, permitiéndote ver qué usuarios o aplicaciones habrían sido bloqueados o habrían requerido MFA.

Por qué es fundamental: Evita interrupciones inesperadas. Un error de configuración puede bloquear el acceso a categorías enteras de usuarios o aplicaciones críticas. El modo solo informe te ofrece la posibilidad de identificar y corregir estos problemas antes de que tengan un impacto real en la producción. Es una práctica operativa esencial para cualquier sysadmin o ingeniero de seguridad.

Cómo activarlo: Cuando creas o modificas una política, en el panel Habilitar política, selecciona Solo informe en lugar de Activa.

6. Leer los registros de acceso para entender qué se bloqueó

Una vez que las políticas están en modo Solo informe (o incluso después de la activación), es crucial monitorear los registros de acceso para entender su impacto. Los registros de acceso de Entra ID proporcionan detalles valiosos sobre cada intento de acceso, incluidos los resultados de las políticas de acceso condicional aplicadas.

Para acceder a los registros:

  1. Navega a Entra ID > Supervisión e integridad > Registros de inicio de sesión.
  2. Utiliza los filtros para restringir la búsqueda. Los filtros más útiles incluyen:
  • Estado del acceso condicional: «Error» o «Solo informe (éxito/error)».
  • Usuario: Para investigar problemas específicos de un usuario.
  • Aplicación en la nube: Para ver el impacto en una aplicación específica.

Busca los eventos en los que el «Estado del acceso condicional» indica un fallo o un bloqueo. Esto te dirá exactamente qué política causó el bloqueo y por qué motivo. Analizar estos registros te ayuda a perfeccionar las políticas y a resolver los problemas de acceso para los usuarios.

Utilizar PowerShell para filtrar eventos específicos de fallo es también un enfoque eficiente:

# Conexión a Microsoft Graph (si no está ya conectado)
Connect-MgGraph -Scopes AuditLog.Read.All

# Visualizar los registros de acceso con fallos de acceso condicional (últimos 20)
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 20 | Format-Table CreatedDateTime, UserDisplayName, AppDisplayName, ConditionalAccessStatus

Este comando te dará una visión general rápida de los accesos bloqueados, esencial para la resolución de problemas.

7. Listar las políticas desde PowerShell

Administrar las políticas de acceso condicional a través de la GUI del portal de Azure es intuitivo, pero para auditorías, automatización o simplemente para una visión general rápida, PowerShell ofrece una alternativa potente. Utilizando el módulo Microsoft.Graph, es posible listar todas las políticas y visualizar su estado, lo que es útil para la documentación o para verificar rápidamente las configuraciones.

Para listar las políticas, asegúrate de tener los permisos Policy.Read.All y de estar conectado a Microsoft Graph:

# Conexión a Microsoft Graph con los permisos necesarios
Connect-MgGraph -Scopes Policy.Read.All

# Listado de todas las políticas de acceso condicional
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State, GrantControls, Conditions

El resultado de Get-MgIdentityConditionalAccessPolicy mostrará el nombre de la política, su estado (Enabled, Disabled, ReportOnly) y detalles sobre los controles de acceso (GrantControls) y las condiciones (Conditions). Esto es particularmente útil para identificar rápidamente políticas activas o en modo solo informe y para tener una visión general de sus reglas principales. Lee también: Docker Espacio Disco: Prune, Logs y Imágenes

Errores Comunes y Resolución de Problemas

Error o mensaje exacto Causa Solución
«Acceso bloqueado por la política de acceso condicional» Usuario o condición no satisfecha por una política activa. Revisa los registros de acceso para identificar la política y las condiciones. Modifica la política o excluye al usuario/grupo.
«MFA requerida pero no configurada» El usuario no ha registrado métodos MFA. Pide al usuario que registre MFA a través de aka.ms/mfasetup.
El usuario no logra acceder a Outlook de escritorio Bloqueo de la autenticación heredada activo. Verifica si el usuario utiliza un cliente obsoleto. Habilita la autenticación moderna en el cliente o excluye temporalmente al usuario de la política (con precaución).
Administrador bloqueado después de una nueva política Cuentas de emergencia no excluidas o política demasiado restrictiva. Utiliza una cuenta de emergencia para acceder y deshabilitar/modificar la política.
Política inesperada aplicada (o no aplicada) Orden de las políticas, condiciones superpuestas o grupos erróneos. Revisa el orden de procesamiento (no es secuencial como los firewalls, sino que todas las políticas que coinciden se evalúan). Revisa las inclusiones/exclusiones de usuarios/grupos.

Preguntas frecuentes

¿El orden de las políticas de acceso condicional es importante?

No, a diferencia de los firewalls tradicionales, el orden de procesamiento de las políticas de acceso condicional en Entra ID no es secuencial. Todas las políticas aplicables a un usuario, aplicación y condición dados se evalúan simultáneamente. Si una sola política requiere un control (por ejemplo, MFA) y una sola política bloquea el acceso, esta última prevalece. Es importante diseñar las políticas de manera que no se superpongan de forma contradictoria.

¿Puedo excluir a un usuario específico de una política?

Sí, cada política de acceso condicional tiene una sección «Excluir» donde puedes especificar usuarios o grupos. Esto es fundamental para las cuentas de emergencia o para probar las políticas en un subconjunto de usuarios antes de extenderlas. Utiliza siempre los grupos para las exclusiones, para facilitar la gestión y reducir los errores manuales.

¿Cuál es la diferencia entre Entra ID P1 y P2 para el acceso condicional?

Entra ID P1 ofrece las funcionalidades de acceso condicional básicas, permitiéndote crear políticas basadas en usuarios, grupos, aplicaciones, ubicaciones y estado del dispositivo. Entra ID P2 incluye todas las funcionalidades P1 y añade la integración con Identity Protection, que permite incorporar el riesgo del usuario y el riesgo de acceso como condiciones en las políticas. Esto permite respuestas dinámicas basadas en la probabilidad de compromiso de la identidad.

¿Cómo puedo probar una nueva política sin bloquear a los usuarios?

El modo «Solo informe» es la solución. Cuando crees o modifiques una política, establece su estado en «Solo informe» en lugar de «Activa». Esto hará que la política sea evaluada y sus resultados registrados en los registros de acceso, pero sin aplicar realmente los controles. Podrás analizar los registros para ver el impacto potencial y afinar la política antes de activarla para todos.

¿Es posible aplicar políticas de acceso condicional a invitados o usuarios externos?

Sí, las políticas de acceso condicional también pueden aplicarse a los usuarios invitados (B2B) que acceden a tu inquilino. Esto es fundamental para proteger los recursos compartidos con socios externos o consultores. Puedes incluir a los usuarios invitados en los grupos a los que se aplican las políticas o crear políticas específicas para ellos, garantizando que incluso los accesos externos respeten tus estándares de seguridad.

Conclusiones con Puntos Clave Operativos

La implementación del acceso condicional en Entra ID no es una opción, sino un imperativo de seguridad. Empezando con las políticas básicas – exclusión de las cuentas de emergencia, MFA obligatoria para los administradores, bloqueo de la autenticación heredada y MFA para todos los usuarios con excepciones inteligentes – puedes construir una base sólida para la protección de tu inquilino. Recuerda utilizar siempre el modo «Solo informe» para probar el impacto de tus políticas y monitorear constantemente los registros de acceso. Estos pasos te permitirán reforzar tu postura de seguridad, reducir la superficie de ataque y garantizar el cumplimiento de las normativas vigentes, protegiendo tus identidades en la nube de forma proactiva y escalable.

Fuentes

Actualizado: noviembre de 2026

Comparte este artículo:

Escrito por

Rosario Giordano

Rosario Giordano es administrador de sistemas y consultor de TI especializado en c iberseguridad y cloud, con más de 20 años de experiencia en la gestión de infraestructuras Linux empresariales. Sus áreas de especialización incluyen el hardening de SSH, plataformas Kubernetes , bases de datos PostgreSQL, virtualización con VMware/Proxmox y el cumplimiento de los marcos de seguridad NIS2 e ISO 27001.