Identidad Azure: MFA y Security Defaults

¿Qué es la seguridad de identidad Azure?

La seguridad de identidad Azure es el conjunto de controles que protege las cuentas de Microsoft Entra ID, los roles con privilegios, los métodos de autenticación, el acceso de aplicaciones y las sesiones administrativas en Microsoft 365, Azure y las aplicaciones SaaS conectadas. Es la puerta de entrada al tenant. Si la capa de identidad es débil, un atacante puede no necesitar explotar un servidor: una contraseña robada, un flujo de autenticación vulnerable a phishing, una excepción débil o una sesión con privilegios pueden bastar.

La MFA es parte de la respuesta, pero por sí sola no constituye una estrategia completa de seguridad de identidades en Azure. Un tenant también necesita cobertura de Conditional Access, métodos de autenticación sólidos para los roles con privilegios, respuesta basada en riesgo, controles de acceso de emergencia, gobernanza de aplicaciones y validación de que las directivas realmente se aplican a los inicios de sesión reales.

Los dos fallos base que aparecen una y otra vez son sencillos:

cuentas con privilegios sin autenticación sólida forzada
Security Defaults deshabilitado sin una cobertura equivalente de Conditional Access

Esos fallos crean una brecha entre lo que los administradores creen que está protegido y lo que Microsoft Entra ID realmente aplica.

Security Defaults frente a Conditional Access

Security Defaults son las protecciones base integradas de Microsoft para organizaciones que necesitan un punto de partida sencillo. La documentación de Microsoft describe Security Defaults como apropiado para organizaciones que quieren mejorar su seguridad pero no saben por dónde empezar, y para organizaciones que usan el nivel gratuito de Microsoft Entra ID.

Security Defaults exige que todos los usuarios se registren para la autenticación multifactor, exige que los administradores realicen MFA en cada inicio de sesión, solicita MFA a otros usuarios cuando Microsoft lo considera necesario, bloquea los protocolos de autenticación heredados, bloquea el flujo de código de dispositivo y exige MFA para actividades con privilegios como el acceso al portal de Azure, el centro de administración de Microsoft Entra, Azure PowerShell y Azure CLI. Son intencionadamente simples y no personalizables: el interruptor está activado o desactivado, sin ámbito y sin exclusiones.

Conditional Access es el motor de directivas más flexible. Las organizaciones con licencias Microsoft Entra ID P1 o P2 y requisitos más complejos generalmente necesitan Conditional Access para segmentar por aplicación, estado del dispositivo, ubicaciones, condiciones de riesgo, fuerza de autenticación, controles de sesión y excepciones específicas.

El estado peligroso es la brecha de transición: Security Defaults está deshabilitado, pero Conditional Access todavía no ofrece una protección equivalente o superior. La guía de Microsoft para abandonar Security Defaults indica que las organizaciones deben habilitar inmediatamente directivas de Conditional Access para proteger la organización después de deshabilitar Security Defaults. Microsoft ahora distribuye directivas de Conditional Access administradas por Microsoft para cubrir esa transición: Bloquear la autenticación heredada, Requerir autenticación multifactor para la administración de Azure, Requerir autenticación multifactor para administradores y Requerir autenticación multifactor para todos los usuarios. Nótese su estado predeterminado. Microsoft las crea en modo solo informe (Report-only), que evalúa y registra pero no aplica nada, y las habilita a más tardar 30 días después si se dejan así. Hasta ese cambio, una lista de directivas que parece cubrir el riesgo no está aplicando nada: la misma trampa descrita en Modo de solo informe de Conditional Access y exclusiones obsoletas.

Por qué la MFA por sí sola no basta

La MFA mejora la resistencia frente al compromiso basado solo en contraseñas, pero no todos los métodos de MFA ofrecen el mismo nivel de protección. Un tenant puede seguir expuesto si:

los administradores están excluidos de las directivas de Conditional Access del tenant por motivos de solución de problemas de emergencia
Conditional Access se aplica solo a determinadas aplicaciones mientras los portales de administración siguen siendo accesibles
los usuarios con privilegios usan métodos vulnerables a phishing cuando existen métodos más sólidos viables
existen cuentas break-glass pero no se supervisan en cada inicio de sesión
la autenticación heredada o clientes antiguos siguen disponibles para algunos flujos de trabajo
el registro y la recuperación de métodos de autenticación están débilmente controlados
las sesiones y los tokens de actualización siguen siendo válidos después de un evento de riesgo

Una de estas brechas ya se ha cerrado a nivel de plataforma, y eso cambia cómo debe interpretarse el problema de las exclusiones. Microsoft ahora fuerza la MFA en los inicios de sesión de Azure con independencia de la configuración del tenant: desde octubre de 2024 para el portal de Azure, el centro de administración de Microsoft Entra y el centro de administración de Microsoft Intune; desde febrero de 2025 para el centro de administración de Microsoft 365; y desde el 1 de octubre de 2025 para Azure CLI, Azure PowerShell, la aplicación móvil de Azure, las herramientas de IaC y los endpoints REST de Azure Resource Manager en operaciones de creación, actualización y eliminación. Esta aplicación forzada tiene prioridad sobre la intención del tenant: Microsoft indica que las excepciones y exclusiones de Conditional Access ya no se aplican a ella, y que cubre todas las cuentas de usuario, incluidas las cuentas break-glass. No se extiende a Microsoft Graph, que sigue rigiéndose por las directivas propias de cada organización, y Microsoft actualmente no la aplica en Azure Government de EE. UU. ni en otras nubes soberanas. La MFA a nivel de plataforma eleva el mínimo en una lista corta de superficies administrativas. No proporciona al tenant cobertura de Conditional Access, fuerza de métodos ni condiciones de dispositivo y riesgo.

Las fuerzas de autenticación de Microsoft Entra existen porque la solidez del método importa. Una fuerza de autenticación de Conditional Access puede exigir combinaciones específicas de métodos, incluidas opciones resistentes al phishing como claves de acceso/llaves de seguridad FIDO2 o la autenticación basada en certificados donde esté implementada y sea compatible.

La cadena de ataque

Paso 1 - Encontrar la ruta de identidad débil

Un atacante busca cuentas que puedan autenticarse sin controles sólidos: cuentas de administrador sin MFA, cuentas excluidas de Conditional Access, cuentas obsoletas, cuentas de emergencia sin supervisión o aplicaciones con permisos amplios.

Paso 2 - Obtener una credencial o sesión válida

El acceso inicial puede provenir de la reutilización de contraseñas, el phishing de credenciales, el robo de tokens, el abuso del servicio de asistencia técnica o un dispositivo comprometido. La técnica exacta varía, pero la pregunta de control de identidad es la misma: ¿exige el tenant un método de autenticación más sólido, un dispositivo compatible, un inicio de sesión de bajo riesgo o una ruta de administración aprobada antes de conceder el acceso?

Paso 3 - Alcanzar una superficie administrativa

Si la cuenta puede llegar al portal de Azure, al centro de administración de Microsoft Entra, a los portales de administración de Microsoft 365, a Microsoft Graph o a PowerShell sin los controles previstos, el tenant tiene una brecha en la directiva efectiva.

Paso 4 - Preservar el acceso

Una vez dentro, el atacante puede intentar añadir un método de autenticación, crear un nuevo usuario, asignar un rol, registrar una aplicación, añadir una credencial a una entidad de servicio o debilitar una directiva de Conditional Access. Esas acciones deben tratarse como eventos de auditoría de alta relevancia para las identidades con privilegios.

Detección

Señales de inicio de sesión y de directivas

Revise los registros de inicio de sesión de Microsoft Entra y los resultados de Conditional Access en busca de:

inicios de sesión con privilegios exitosos en los que no se exigió MFA pero debería haberse exigido
inicios de sesión en los que el método de autenticación no satisface la fuerza esperada
acceso administrativo desde dispositivos no administrados o ubicaciones inesperadas
inicios de sesión de riesgo medio o alto que se completaron con éxito
fallos repetidos seguidos de un éxito en una cuenta de administrador
inicios de sesión de cuentas de emergencia
uso de clientes o protocolos heredados donde deberían estar bloqueados

Señales del registro de auditoría

Supervise los cambios del tenant que puedan debilitar los controles de identidad:

Área de cambio	Por qué importa
Actualización de una directiva de Conditional Access	Puede eliminar requisitos de MFA, dispositivo, riesgo o aplicación
Actualización de una exclusión de Conditional Access	Puede crear una ruta de omisión silenciosa
Cambio de método de autenticación	Puede facilitar la recuperación de cuentas o la persistencia
Asignación de roles	Puede convertir una cuenta en control del tenant
Cambio de credencial de aplicación	Puede crear persistencia duradera basada en aplicaciones
Cambio en Security Defaults	Puede eliminar la protección base si no se reemplaza

Advertencias sobre la detección

No genere alertas solo por la existencia de MFA. Genere alertas por los resultados efectivos. La pregunta no es "¿tiene el tenant una directiva de MFA?". La pregunta es "¿este inicio de sesión, a este recurso, por parte de esta identidad, cumplió el control requerido?". Los resultados de Conditional Access, los detalles de autenticación, el nivel de riesgo, el rol del usuario, la aplicación, el dispositivo y la ubicación importan todos.

Remediación

La base segura es, o bien Security Defaults para tenants sencillos, o bien un diseño completo de Conditional Access para tenants más complejos. Dejar ambos ausentes es el fallo evitable.

1. Reactivar Security Defaults o reemplazarlo de inmediato

Si el tenant no cuenta con un diseño maduro de Conditional Access, active Security Defaults. Si la organización usa Conditional Access, documente la base de reemplazo antes de deshabilitar Security Defaults y pruébela contra escenarios reales de inicio de sesión.

Como mínimo, el diseño de reemplazo debe cubrir a los usuarios con privilegios, la administración de Azure, las superficies de administración de Microsoft 365, los inicios de sesión de riesgo y la exposición a la autenticación heredada.

2. Exigir autenticación sólida para los roles con privilegios

Para los usuarios con privilegios habituales, exija MFA y considere métodos más sólidos para los roles más sensibles. Use las fuerzas de autenticación de Conditional Access para exigir métodos resistentes al phishing donde el entorno lo permita.

Las poblaciones de roles de alto valor más comunes incluyen:

Administrador global
Administrador de roles con privilegios
Administrador de acceso condicional
Administrador de seguridad
Administrador de aplicaciones
Administrador de aplicaciones en la nube
Administrador de Exchange y Administrador de SharePoint en tenants con un uso intensivo de Microsoft 365

3. Gestionar las cuentas de acceso de emergencia por separado

Las cuentas de emergencia son necesarias para la resiliencia. Microsoft recomienda dos o más cuentas de acceso de emergencia solo en la nube en el dominio *.onmicrosoft.com, sin federar ni sincronizar desde entornos locales. Estas cuentas no deben usarse como identidades de administración cotidianas, y su diseño de control debe evitar dependencias que puedan fallar precisamente durante la emergencia que están destinadas a resolver.

La autenticación resistente al phishing en estas cuentas ya no es opcional. La aplicación obligatoria de MFA también se aplica a las cuentas break-glass, por lo que una cuenta de emergencia protegida solo con contraseña es hoy un bloqueo esperando a suceder. La guía actual de Microsoft es registrar uno de los dos métodos sin contraseña que satisfacen el requisito obligatorio de MFA: una clave de acceso (passkey/FIDO2), que Microsoft recomienda, o la autenticación basada en certificados donde ya exista una PKI, y mantener ese método distinto del que usan las cuentas de administración habituales. Excluya estas cuentas de las directivas de Conditional Access que bloquean o restringen el inicio de sesión (las directivas en modo solo informe no necesitan exclusión), guarde las credenciales en ubicaciones seguras independientes, mantenga la asignación de Administrador global permanentemente activa en lugar de admisible en PIM, genere alertas por cada inicio de sesión y valide las cuentas al menos cada 90 días. Si una cuenta de emergencia inicia sesión, el equipo de seguridad debe saberlo.

4. Eliminar las excepciones innecesarias

Revise cada usuario, grupo, ubicación, aplicación y condición de dispositivo excluidos en Conditional Access. Las excepciones creadas durante la solución de problemas suelen volverse permanentes. Cada excepción debe tener un propietario, un motivo, una fecha de caducidad o periodicidad de revisión, y una supervisión compensatoria.

5. Combinar la seguridad de identidades con la respuesta a riesgos

Security Defaults y la MFA no sustituyen a la respuesta basada en riesgo en tenants más grandes. Use las señales de riesgo de Microsoft Entra ID Protection a través de las condiciones de riesgo de Conditional Access para exigir autenticación adicional (step-up), reautenticación, remediación del riesgo o bloqueo cuando se detecte riesgo. La recomendación actual de Microsoft es exigir la remediación del riesgo cuando el riesgo del usuario sea alto, y MFA más frecuencia de inicio de sesión "Cada vez" cuando el riesgo de inicio de sesión sea medio o alto. Cree estas reglas como directivas de Conditional Access en lugar de hacerlo desde el panel de ID Protection: las directivas de riesgo heredadas configuradas dentro de Microsoft Entra ID Protection se retiran el 1 de octubre de 2026, por lo que los tenants que aún las usan deben recrear los equivalentes en Conditional Access y deshabilitar las antiguas.

Validación después de cambios en las directivas

Valide la ruta de directiva efectiva en lugar de confiar en capturas de pantalla de configuración:

pruebe el inicio de sesión de un usuario con privilegios en el portal de Azure y confirme que se exige el control esperado
pruebe el inicio de sesión de un usuario con privilegios en Microsoft Graph o PowerShell donde corresponda
confirme que la misma cuenta no está excluida a través de otro grupo, ubicación, aplicación o condición de dispositivo
revise los registros de inicio de sesión para confirmar el resultado de Conditional Access y los detalles del método de autenticación
valide las alertas de las cuentas de emergencia revisando la ruta de la alerta, no asumiendo que existe
revise los inicios de sesión de riesgo y confirme que se aplicarían las directivas basadas en riesgo
confirme que la autenticación heredada está bloqueada donde Security Defaults o Conditional Access deberían bloquearla
compruebe si los requisitos de fuerza de autenticación se satisfacen únicamente con los métodos previstos

Un control que existe pero no se aplica a los inicios de sesión que los atacantes pueden usar no es un control de seguridad de identidades.

Cómo lo detecta EtcSec

EtcSec audita los controles de identidad de Azure en cada análisis del tenant. Las tres comprobaciones siguientes son a nivel de tenant: establecen si el control existe en absoluto, que es la condición previa para la pregunta por inicio de sesión que aborda este artículo.

MFA_NOT_ENFORCED_ADMINS marca un tenant en el que ninguna directiva de Conditional Access habilitada dirige a roles de directorio con un control de concesión de MFA.

AZ_SECURITY_DEFAULTS_DISABLED marca un tenant cuyo interruptor de Security Defaults está desactivado. Si una base equivalente de Conditional Access lo ha reemplazado es la revisión independiente que describe este artículo.

CA_NO_MFA_REQUIREMENT marca un tenant en el que ninguna directiva de Conditional Access habilitada exige MFA en sus controles de concesión.

La pregunta relevante no es si un tenant tiene directivas sobre el papel. Es si los inicios de sesión con privilegios realmente se enfrentan a los controles previstos y si las sesiones de riesgo desencadenan una respuesta.

Controles relacionados

Este control debe revisarse junto con Azure Identity Protection: bloqueo de credenciales filtradas, Acceso privilegiado en Azure: demasiados administradores globales, Endurecimiento del tenant de Azure: corrección de la configuración predeterminada insegura, Cuentas invitado de Azure: la superficie de ataque olvidada de su tenant y Registros de aplicaciones de Azure: aplicaciones del tenant con privilegios excesivos. Una postura débil de MFA empeora mucho cuando ese mismo tenant también tiene privilegios de administración permanentes, acceso amplio de invitados, aplicaciones de riesgo o una respuesta débil basada en riesgo.

Identidad Azure: MFA, metodos y Security Defaults