Endurecimiento del tenant Azure: baseline segura

Que es el endurecimiento del tenant Azure?

El endurecimiento del tenant Azure es el trabajo que convierte un tenant Microsoft Entra ID utilizable en un tenant defensible. Para un equipo tecnico no significa solo activar una opcion de seguridad. Significa verificar que baseline aplica realmente, que excepciones siguen vivas, que identidades externas se aceptan y que administraciones privilegiadas o workload identities quedan fuera del control esperado.

Los errores mas comunes se repiten en casi todos los tenants poco maduros:

Security Defaults deshabilitados sin reemplazo claro por Conditional Access
metodos de autenticacion gestionados todavia con politicas legacy MFA/SSPR
autenticacion legacy o SMTP AUTH tolerados por excepcion sin fecha de salida
invitaciones guest demasiado abiertas
trust cross-tenant configurado con demasiada confianza
cuentas de emergencia, de sincronizacion o identidades aplicativas fuera de la revision tecnica

El riesgo no esta en un "default malo" aislado. El riesgo esta en la suma de defaults, excepciones y objetos privilegiados que nadie revisa juntos.

La baseline que hay que comprobar primero

1. Security Defaults o Conditional Access, pero nunca vacio

Microsoft documenta que Security Defaults son una baseline inicial para organizaciones sin requerimientos avanzados. Si estan deshabilitados, el equipo debe demostrar que existe un conjunto de politicas Conditional Access que cubre de forma equivalente los controles esenciales.

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

Si IsEnabled = False, la pregunta correcta no es "tenemos algunas policies?" sino que protecciones concretas sustituyen la baseline predeterminada.

2. Gestion moderna de metodos de autenticacion

Microsoft recomienda administrar los metodos desde Authentication methods policy. Las antiguas politicas MFA y SSPR siguen existiendo como modelo legacy y Microsoft ha anunciado su retirada progresiva. Eso significa que un tenant puede parecer limpio en interfaz y seguir heredando decisiones viejas sobre registro y uso de metodos.

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

Aqui conviene responder tres preguntas:

que metodos siguen habilitados
si queda gestion legacy influyendo en el comportamiento real
si las poblaciones sensibles usan metodos coherentes con el riesgo real del tenant

3. Invitados y colaboracion externa

Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom

En muchos tenants el problema no es un ajuste descaradamente abierto. Es una suma de decisiones pequenas: demasiadas personas pueden invitar, los invitados duran mas de lo necesario, y nadie revisa el acceso despues de la colaboracion inicial.

4. Cross-tenant access

Get-MgPolicyCrossTenantAccessPolicyDefault

Los cross-tenant access settings determinan si el tenant confia en la MFA, en device claims o en compliance claims del tenant externo. Aceptar esa confianza por inercia es una mala practica. Debe existir una decision explicita por partner y por flujo.

5. Excepciones sobre auth moderna y SMTP AUTH

Si el tenant mantiene excepciones de autenticacion legacy o SMTP AUTH en Exchange Online, esas excepciones deben tener owner, justificacion y fecha de salida. Un hardening serio no deja este tema como deuda informal indefinida.

Cuentas de emergencia, sincronizacion y workload identities

Microsoft documenta que los break-glass accounts pueden quedar fuera de ciertas policies estrictas para evitar lockout total, pero eso no los convierte en cuentas libres de control. Tambien documenta que las cuentas de sincronizacion y los service principals no siguen exactamente el mismo modelo que los usuarios interactivos.

En una revision tecnica conviene separar claramente:

cuentas de emergencia humanas
cuentas de sincronizacion
service principals privilegiados
managed identities frente a secretos estaticos

Si el tenant protege muy bien a los usuarios admin pero ignora sus identidades no humanas, la postura sigue siendo incompleta.

Que busca un atacante

En un tenant poco endurecido el atacante suele encadenar varias debilidades moderadas:

baseline debil o incompleta
admins con controles de MFA mejorables
metodos o politicas heredadas sin limpiar
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 objetivo final no es solo un inicio de sesion exitoso. Es llegar a control administrativo del tenant, consentimiento aplicativo, persistencia cloud o acceso duradero a Microsoft 365.

Detection

Para este tema conviene vigilar:

cambios en Security Defaults
cambios en Authentication methods policy
modificaciones de Conditional Access sobre admins, guest o recursos criticos
cambios en cross-tenant access o parametros de invitacion
nuevos role assignments privilegiados
nuevos secretos de aplicaciones o extensiones de vida inesperadas

La postura madura combina auditoria periodica e historial de cambios. No basta con una revision puntual de 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. Mover la gestion de metodos al modelo moderno

No conviene dejar decisiones repartidas entre el modelo nuevo y el modelo legacy. La limpieza de politicas antiguas es parte del hardening, no una tarea cosmetica.

3. Endurecer invitados y trust externos

Para guest y external users:

limitar quien puede invitar
aplicar revisiones periodicas de acceso
decidir si se acepta la MFA del tenant externo o se exige challenge local
reducir el alcance funcional de esas identidades

4. Revisar cuentas de emergencia y sincronizacion

Los break-glass accounts deben ser pocos, probados y documentados. Las cuentas de sincronizacion y otras identidades tecnicas privilegiadas deben estar fuera del uso humano y con revisiones separadas.

5. Reducir secretos estaticos en workload identities

Siempre que sea viable, sustituye secretos estaticos por managed identities. Cuando no lo sea, reduce permisos, acorta lifetime del secreto y revisa periodicamente el uso real.

6. Planificar la salida de auth legacy

Una excepcion a SMTP AUTH o a flujos legacy no puede quedar indefinidamente. Debe existir un plan de migracion real y una fecha de fin.

7. Probar la baseline con un escenario operativo real

Muchos tenants quedan "bien" en papel y mal en la practica porque nadie valida el conjunto completo. Conviene probar, al menos de forma controlada:

un admin legitimo sujeto a las nuevas exigencias
un guest con el flujo permitido de acceso
una aplicacion o workload identity critica
una cuenta de emergencia bajo procedimiento documentado

Esta prueba revela rapidamente incoherencias entre baseline, excepciones y operacion diaria.

8. Revisar cuentas de emergencia de forma separada del resto de administradores

Las cuentas de emergencia no deben entrar en el inventario como si fueran otro admin cualquiera. Microsoft recomienda que sean pocas, con credenciales muy fuertes, sin uso diario y probadas periodicamente. En el hardening real eso obliga a comprobar:

si estan excluidas solo de lo imprescindible y no de mas
si las credenciales se guardan y rotan bajo un proceso verificable
si siguen sin tener licencias, grupos o accesos operativos innecesarios
si el procedimiento de prueba se ejecuta y se registra de verdad

Un tenant con buen Conditional Access pero con break-glass sin control sigue teniendo una via de acceso administrativo dificil de gobernar.

9. Tratar la confianza cross-tenant como una decision de arquitectura

Aceptar MFA o device claims del tenant externo no es un detalle cosmetico. Es una decision de confianza entre organizaciones. Conviene revisar cada partner relevante y responder:

que claims se aceptan exactamente
para que usuarios y que recursos
quien aprobo esa confianza
como se revoca si el partner cambia o el proyecto termina

Sin esa trazabilidad, el tenant acaba heredando confianza externa sin poder explicar porque existe ni a quien sigue sirviendo.

Validacion

La validacion correcta debe demostrar que:

existe una baseline de tenant clara y comprobable
los metodos de autenticacion se gestionan desde el modelo moderno
guest y cross-tenant access siguen una politica explicita
las cuentas de emergencia no son una via paralela de administracion
las workload identities privilegiadas estan inventariadas y minimizadas
las excepciones legacy tienen owner y horizonte de salida

Sin esto, el tenant puede parecer ordenado en superficie y seguir siendo facil de abusar. La validacion final debe dejar claro tambien que las decisiones de confianza con terceros y con identidades no humanas ya no dependen de memoria tribal ni de tickets viejos, sino de un criterio de seguridad repetible.

Que evidencia merece quedarse despues de la remediacion

Un hardening serio no termina con un portal "verde". Conviene conservar evidencia tecnica simple pero suficiente:

export de Security Defaults o de las politicas CA que reemplazan la baseline
listado de metodos de autenticacion vigentes y de exclusiones legacy pendientes
inventario de break-glass, sync accounts y workload identities con owner claro
matriz corta de partners cross-tenant y claims aceptados
prueba de que invitados, admins y workloads criticos pasaron por el flujo esperado

Esa evidencia permite que la siguiente revision detecte deriva rapidamente y evita volver a discutir el tenant desde cero cada vez que cambia el equipo.

Fuentes primarias

Como EtcSec detecta esto

EtcSec cubre este tema con varios hallazgos relacionados:

AZ_SECURITY_DEFAULTS_DISABLED
CA_NO_LEGACY_AUTH_BLOCK
GUEST_INVITATION_UNRESTRICTED

La pregunta util no es si el tenant tiene muchas opciones activadas. La pregunta util es si un atacante se encontraria un limite claro y consistente al intentar ampliar privilegios, reutilizar identidades externas o explotar deuda de configuracion historica.

Endurecimiento del tenant Azure: corregir defaults inseguros