Identidad Azure: MFA y Security Defaults

Que es la identidad Azure?

La identidad Azure en Microsoft Entra ID no se reduce a una pregunta binaria del tipo "MFA si o no". Para un equipo tecnico la pregunta correcta es mas exigente: que metodos de autenticacion siguen permitidos, que identidades administrativas permanecen expuestas, que excepciones sobreviven y que workload identities o trust externos quedan fuera del modelo de control esperado.

Microsoft documenta que Security Defaults son una baseline inicial, pero no sustituyen un diseno completo de identidad para tenants con necesidades mas complejas. Microsoft tambien documenta que para administradores se recomienda phishing-resistant MFA, no simplemente cualquier segundo factor. Eso cambia la lectura del riesgo: un tenant puede declarar que usa MFA y seguir siendo vulnerable a metodos o flujos demasiado debiles para su nivel de privilegio.

Por que MFA sola no basta

No todas las MFA protegen igual

Microsoft Entra distingue entre MFA tradicional, passwordless y phishing-resistant MFA. Para cuentas administrativas, el objetivo defensivo serio no es solo registrar un segundo factor, sino exigir metodos resistentes a phishing cuando el riesgo y la licencia lo permitan.

Security Defaults no cubren todo el problema

Security Defaults aportan una baseline rapida: MFA para admins, registro de metodos, bloqueo de autenticacion legacy y controles iniciales sobre acciones privilegiadas. Pero si el tenant depende de mas granularidad, de guest access complejo, de workload identities o de politicas condicionadas, hace falta una estrategia basada en Conditional Access y en gestion moderna de metodos.

Las politicas de metodos importan tanto como el requisito MFA

Microsoft recomienda gestionar metodos en Authentication methods policy. Si el tenant sigue mezclando ese modelo con politicas MFA/SSPR heredadas, el resultado suele ser confuso: metodos permitidos por herencia, experiencia de registro incoherente y controles dificiles de explicar.

Las identidades no humanas siguen siendo identidad

Los service principals y otras workload identities no se comportan como usuarios interactivos. Si el tenant protege bien al admin humano pero mantiene principals con secretos estaticos y permisos altos, la postura de identidad sigue siendo parcial.

Guest y trust externos cambian el alcance real del control

Las organizaciones externas, los invitados y la confianza de MFA entre tenants afectan la seguridad tanto como las cuentas internas. Si la identidad externa entra con reglas mal definidas, el tenant puede tener MFA en teoria y demasiado hueco operativo en la practica.

Auditoria tecnica minima

1. Verificar Security Defaults

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled

2. Revisar Authentication methods policy

Get-MgPolicyAuthenticationMethodPolicy |
  Select-Object -ExpandProperty AuthenticationMethodConfigurations |
  Select-Object Id, State

Aqui hay que revisar si el tenant ya migro de verdad al modelo moderno y si los metodos habilitados son coherentes con el riesgo de sus poblaciones mas sensibles.

3. Revisar admins y cuentas de emergencia

Get-MgDirectoryRole | Select-Object DisplayName, Id

A partir de ahi, conviene revisar miembros, exclusiones, pruebas de break-glass y evidencia de uso real.

4. Revisar guest y cross-tenant access

Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
Get-MgPolicyCrossTenantAccessPolicyDefault

No basta con saber si hay invitados. Hace falta saber quien los invita, como se revisan, que confianza se acepta del tenant externo y con que controles compensatorios.

Donde aparece el abuso real

Una cadena de abuso tipica sobre identidad Azure suele mezclar varios factores:

MFA presente pero no resistente al phishing para identidades de alto valor
Security Defaults deshabilitados sin una cobertura equivalente bien diseniada
metodos de autenticacion heredados o mal gobernados
cuentas de emergencia poco vigiladas
invitados, trust externos o aplicaciones con reglas demasiado permisivas
service principals con secretos largos en el tiempo y alcance privilegiado

El resultado no es simplemente un login exitoso. Es la posibilidad de ampliar privilegios, emitir consentimiento, persistir en aplicaciones o mantener acceso administrativo con poca friccion.

Detection

Para este tema conviene vigilar:

cambios en Security Defaults
cambios en Authentication methods policy
nuevas exclusiones o modificaciones en Conditional Access para admins
cambios en guest collaboration o cross-tenant access
asignaciones de roles privilegiados
secretos nuevos o prolongados en identidades aplicativas
uso de cuentas de emergencia fuera de prueba o incidente real

La deteccion madura mezcla telemetria de sign-in y auditoria con un inventario continuo de posture. No basta con una exportacion puntual del portal.

Remediacion

1. Elegir una baseline explicita

Si el tenant puede operar con Security Defaults, deben estar activos. Si necesita mas control, entonces debe existir un conjunto de politicas Conditional Access y de governance que reemplace claramente esa baseline.

2. Gestionar metodos desde el modelo moderno

La administracion de metodos debe estar en Authentication methods policy. Mantener decisiones dispersas entre modelos nuevos y legacy complica la seguridad y la operacion.

3. Exigir controles mas fuertes a los admins

Para roles administrativos, la MFA minima no deberia ser el objetivo final. El objetivo es elevar la resistencia del metodo y reducir excepciones.

4. Tratar break-glass como excepcion gobernada

Los break-glass accounts son necesarios, pero deben ser pocos, probados, documentados y vigilados. No son cuentas comodin para el dia a dia.

5. Incluir service principals y workload identities

Las identidades no humanas con privilegios altos necesitan inventario, reduccion de permisos y, cuando sea posible, sustitucion de secretos estaticos por managed identities.

6. Revisar trust externo con criterio defensivo

Aceptar la MFA o claims de un tenant externo debe ser una decision deliberada, no una herencia comodamente ignorada.

7. Validar el tenant con varios tipos de identidad

Una buena prueba final no se limita a un admin humano. Conviene validar:

un admin sujeto a MFA fuerte
una cuenta de emergencia bajo procedimiento controlado
un invitado con el flujo permitido
una workload identity critica

Si una de estas cuatro poblaciones sigue fuera de la baseline real, la postura de identidad todavia no esta madura.

Validacion

La validacion correcta debe demostrar que:

existe una baseline de identidad clara
los metodos se gestionan en el modelo adecuado
los admins usan controles mas fuertes que la minima MFA posible
las cuentas de emergencia siguen bajo gobernanza
guest y trust externos estan limitados y entendidos
las workload identities privilegiadas estan inventariadas y minimizadas

Si estos puntos no estan claros, el tenant puede parecer bien configurado y seguir siendo facil de abusar. La diferencia entre una postura cosmetica y una postura defensible suele estar precisamente en estas identidades que nadie mira juntas.

Gobernar workload identities como parte del mismo modelo

Muchas organizaciones tratan usuarios y workload identities como problemas distintos, y ahi es donde se abre una brecha de gobierno. Un service principal con permisos altos, secretos de larga vida y sin owner operativo claro rompe la idea de que la identidad administrativa esta protegida solo porque los admins humanos usan MFA. Si la revision de postura no incluye aplicaciones, secretos, certificados y managed identities, la evaluacion de identidad queda incompleta desde el principio.

La regla util para un equipo tecnico es sencilla: cualquier identidad que pueda cambiar permisos, leer datos sensibles, registrar aplicaciones o tocar configuracion del tenant debe entrar en el mismo inventario de control que un administrador humano. Cambia el flujo de autenticacion, pero no cambia la criticidad.

Security Defaults, Conditional Access y metodos: una sola historia

Tambien es frecuente analizar Security Defaults, Conditional Access y Authentication methods policy como si fueran piezas separadas. En realidad son tres capas del mismo control. Security Defaults define una baseline simple. Conditional Access decide a que poblaciones y recursos aplica una politica concreta. Authentication methods policy limita que factores pueden usarse realmente. Si una de esas capas no acompana a las otras, el resultado es inconsistente: una politica exige MFA pero un metodo demasiado debil sigue permitido, o Security Defaults se desactivan sin que exista una replacement baseline comprobable.

Matriz minima de prueba despues de cada cambio

Despues de tocar la postura de identidad conviene repetir siempre la misma matriz de validacion:

admin humano con el metodo fuerte esperado
usuario interno normal
cuenta de emergencia
guest o external user
workload identity con acceso relevante

Esta matriz obliga a validar tanto el login como el control exacto aplicado. Si una sola de estas poblaciones queda fuera del comportamiento esperado, la correccion no deberia darse por cerrada aunque el portal parezca alineado.

Revisar propietarios y ciclo de vida de los metodos

Tambien merece la pena revisar quien puede registrar, resetear o aprobar metodos de autenticacion y como se controla el ciclo de vida de esos cambios. Un tenant puede exigir MFA y aun asi mantener un proceso debil para altas de metodos, reseteos administrativos o registros urgentes que luego nadie revisa. Para perfiles tecnicos, este punto es importante porque muchas desviaciones no aparecen en la politica, sino en el proceso operativo que rodea al metodo.

Fuentes primarias

Como EtcSec detecta esto

EtcSec cubre este tema con varios hallazgos relacionados:

MFA_NOT_ENFORCED_ADMINS
AZ_SECURITY_DEFAULTS_DISABLED
CA_NO_MFA_REQUIREMENT

La pregunta util no es si MFA aparece marcada en el portal. La pregunta util es si las identidades que administran el tenant son realmente dificiles de reutilizar, escalar o mantener fuera de control.

Identidad Azure: MFA, metodos y Security Defaults