Endurecimiento del tenant Azure: baseline segura

¿Qué es el Endurecimiento del Tenant Azure?

Microsoft ahora habilita los Valores predeterminados de seguridad (Security Defaults) automáticamente para los tenants nuevos de Microsoft 365 y Azure, con un período de gracia de 24 horas antes de que se apliquen, y solo si el tenant no cuenta ya con políticas de Acceso Condicional ni con MFA heredado por usuario. En la práctica, muchos tenants de producción siguen funcionando sin una línea base de seguridad real: los Valores predeterminados de seguridad se desactivan en el momento en que un administrador empieza a crear Acceso Condicional personalizado, y la política de reemplazo nunca llega a completarse; los protocolos de autenticación heredada siguen siendo accesibles, las invitaciones de invitados están abiertas a cualquier usuario, y ninguna política de Acceso Condicional bloquea los huecos que quedan.

El endurecimiento del tenant es el proceso de revisar y corregir sistemáticamente estos valores predeterminados. No es un trabajo vistoso, pero es fundamental: cualquier otro control de seguridad de Azure (Acceso Condicional, PIM, Identity Protection) depende de que la configuración del tenant sea correcta.

Este artículo cubre las comprobaciones más críticas de configuración del tenant Azure, y cómo validarlas y corregirlas.

Cómo Funciona

La configuración del tenant Azure se gestiona en múltiples ubicaciones:

Entra ID > Propiedades — configuración a nivel de tenant, incluidos los Valores predeterminados de seguridad
Entra ID > Identidades externas — configuración de invitados y colaboración B2B
Entra ID > Métodos de autenticación — qué métodos de MFA están permitidos
Centro de administración de Exchange Online — configuración de autenticación heredada para protocolos de correo
Centro de administración de Microsoft 365 — configuración de seguridad a nivel de servicio

Las configuraciones incorrectas en cualquiera de estos puntos pueden crear superficie de ataque que evade todos los demás controles. Una política de Acceso Condicional perfectamente configurada es irrelevante si la autenticación heredada sigue habilitada a nivel de Exchange.

La Cadena de Ataque

Explotación de los Valores Predeterminados de Seguridad Desactivados

Cuando los Valores predeterminados de seguridad están desactivados y ninguna política de Acceso Condicional cubre el hueco:

# Password spray contra M365 sin línea base de MFA
o365spray --spray -U users.txt -P passwords.txt --domain corp.com

# Bypass de autenticación heredada: el acceso IMAP ignora el Acceso Condicional
curl -u [email protected]:Password1 imaps://outlook.office365.com/INBOX

Explotación de la Configuración B2B Abierta

# Con cualquier cuenta de miembro: invitar una identidad externa controlada por el atacante
New-MgInvitation -InvitedUserEmailAddress "[email protected]" `
    -InviteRedirectUrl "https://myapps.microsoft.com" `
    -SendInvitationMessage $false

Lista de Verificación de Auditoría de Configuración

1. Estado de los Valores Predeterminados de Seguridad

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled
# Debería ser True (si no hay políticas de CA implementadas)

2. Estado de la Autenticación Heredada

# Comprobar las políticas de autenticación heredada de Exchange Online
Connect-ExchangeOnline
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuth*
# Todos los valores AllowBasicAuth* deberían ser False

3. Configuración de Invitaciones de Invitados

# Comprobar quién puede invitar invitados
Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
# Valores válidos: none, adminsAndGuestInviters, adminsGuestInvitersAndAllMembers, everyone
# Debería ser: none o adminsAndGuestInviters

4. Política de Métodos de Autenticación

# Enumerar los métodos de autenticación habilitados
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations |
    Where-Object {$_.State -eq "enabled"} | Select-Object Id, State
# Verificar que SMS no sea el único método de MFA (vulnerable a phishing); preferir Authenticator App o FIDO2

5. Configuración de Acceso entre Tenants

# Comprobar si la colaboración B2B entrante está abierta a todas las organizaciones externas
Get-MgPolicyCrossTenantAccessPolicyDefault | Select-Object -ExpandProperty B2BCollaborationInbound |
    Select-Object -ExpandProperty UsersAndGroups
# AccessType no debería ser "allowed" para el destino "AllUsers" sin restricciones adicionales

Detección

Puntuación de Seguridad de Microsoft 365

La Puntuación de seguridad de Microsoft 365 (Secure Score) ofrece una evaluación automatizada de la configuración del tenant frente a la línea base recomendada por Microsoft. Puede consultarse en security.microsoft.com > Puntuación de seguridad.

Microsoft limita cada acción recomendada a un máximo de 10 puntos, y muchas de ellas se puntúan como un porcentaje de la configuración de su tenant en lugar de un valor fijo: no existe un valor de puntos universal y fijo por acción. Como ejemplos concretos de la propia guía de puntuación de Microsoft: exigir MFA para los roles administrativos vale 10 puntos, garantizar que todos los usuarios puedan completar el MFA vale 9 puntos, y bloquear la autenticación heredada mediante Acceso Condicional vale 7 puntos. Restringir las invitaciones de invitados y habilitar Privileged Identity Management también aumentan la puntuación; consulte la propia lista de recomendaciones de Secure Score para conocer los valores exactos en su tenant.

Registros de Auditoría de Entra ID

// Detectar la desactivación de los Valores predeterminados de seguridad
AuditLogs
| where OperationName == "Update security defaults"
| mv-expand props = TargetResources.modifiedProperties
| where tostring(props.newValue) has "false"

💡

💡 Consejo: Supervise su Microsoft Secure Score semanalmente. Una caída significativa suele ser el primer indicio de que un cambio de configuración introdujo un nuevo hueco de seguridad.

Remediación

💡

💡 Victoria rápida: Ejecute la lista de verificación de auditoría anterior y corrija cualquier hallazgo en el que la autenticación heredada esté habilitada o los Valores predeterminados de seguridad estén desactivados sin una política de CA que los reemplace.

Habilitar los Valores Predeterminados de Seguridad (Si No Hay Acceso Condicional)

Entra ID > Propiedades > Administrar valores predeterminados de seguridad > Habilitado = Sí

Deshabilitar la Autenticación Heredada de Forma Global

# Crear una política de autenticación que bloquee toda la autenticación básica
New-AuthenticationPolicy -Name "Block Basic Auth"
Set-AuthenticationPolicy -Identity "Block Basic Auth" `
    -AllowBasicAuthImap $false -AllowBasicAuthPop $false `
    -AllowBasicAuthSmtp $false -AllowBasicAuthWebServices $false `
    -AllowBasicAuthRpc $false -AllowBasicAuthMapi $false

# Aplicar a todos los usuarios
Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "Block Basic Auth"

Restringir las Invitaciones de Invitados

Entra ID > Identidades externas > Configuración de colaboración externa:
Configuración de invitación de invitados = "Solo los usuarios a los que se han asignado roles de administrador específicos pueden invitar"

Habilitar Métodos de MFA Resistentes al Phishing

Entra ID > Métodos de autenticación > Claves de seguridad FIDO2 = Habilitado (para todos o para administradores)
Entra ID > Métodos de autenticación > Microsoft Authenticator = Habilitado
Entra ID > Métodos de autenticación > SMS = Deshabilitado (vulnerable a phishing; sustituir por Authenticator)

Cómo lo Detecta EtcSec

EtcSec audita la configuración completa de su tenant Azure en cada análisis, comprobando todos los ajustes que afectan a la línea base de seguridad.

AZ_SECURITY_DEFAULTS_DISABLED marca los tenants en los que los Valores predeterminados de seguridad están desactivados: un hueco fundamental en la línea base que elimina protecciones a nivel de tenant, como la exigencia básica de MFA.

CA_NO_LEGACY_AUTH_BLOCK marca la ausencia de una política de Acceso Condicional que bloquee los protocolos de autenticación heredada, dejando abierto un bypass de MFA para cualquier atacante que disponga de una contraseña robada.

GUEST_INVITATION_UNRESTRICTED marca los tenants en los que la política de invitación de invitados permite que cualquier usuario invite a invitados externos, en lugar de restringir las invitaciones a administradores o roles específicos.

ℹ️

ℹ️ Nota: EtcSec audita la configuración del tenant Azure de forma automática. Ejecute una auditoría gratuita para validar la postura de endurecimiento de su tenant.

Prioridades de Revisión

El Endurecimiento del tenant Azure: cómo corregir los valores predeterminados inseguros de fábrica debe abordarse como una exposición real dentro de su tenant de Entra ID y Azure, no como un único ajuste aislado. Empiece por definir el perímetro de revisión: qué administradores, invitados, entidades de servicio, registros de aplicaciones, exclusiones de políticas y cuentas de emergencia (break-glass) se ven afectados, de qué flujos de trabajo de negocio dependen, qué privilegios exponen y qué excepciones de emergencia se fueron añadiendo con el tiempo. Ese paso de acotación evita una remediación superficial, porque el síntoma técnico suele ser más pequeño que el radio de impacto operativo real. Al documentar el camino completo desde la configuración hasta el privilegio, el equipo puede priorizar los cambios que reducen el riesgo rápidamente sin romper el acceso en producción. Esto también crea una línea base defendible para validaciones posteriores y ofrece a la dirección una explicación clara de por qué el problema importa ahora.

Controles Adyacentes a Revisar

Cuando los atacantes llegan a su tenant de Entra ID y Azure, rara vez se detienen en el primer punto débil. En torno al Endurecimiento del tenant Azure: cómo corregir los valores predeterminados inseguros de fábrica, normalmente comprueban si la ruta expuesta puede encadenarse con autenticación heredada, gobierno débil de invitados, consentimiento amplio de aplicaciones, cuentas de emergencia obsoletas y roles que nunca se revisaron. Esto significa que los defensores deben revisar no solo la debilidad principal, sino también cada dependencia cercana que convierte el acceso en persistencia o escalada de privilegios. Confirme qué identidades, roles, permisos y supuestos de confianza podría reutilizar un operador motivado. Si una corrección cierra solo un objeto y deja intactas las rutas de privilegio adyacentes, el riesgo efectivo apenas cambia. Una revisión disciplinada de las posibilidades de encadenamiento es lo que convierte este tema del artículo en un ejercicio práctico de endurecimiento, en lugar de una simple casilla que se marca una sola vez.

Evidencia y Telemetría a Recopilar

Una respuesta sólida al Endurecimiento del tenant Azure: cómo corregir los valores predeterminados inseguros de fábrica necesita evidencia que puedan revisar tanto los equipos de ingeniería como los de detección. Recopile registros de inicio de sesión, registros de auditoría, cambios en asignaciones de roles, eventos de consentimiento, cambios en credenciales de aplicaciones y señales de inicio de sesión de riesgo; compare los cambios recientes con las ventanas de mantenimiento conocidas, y aísle las cuentas o sistemas cuyo comportamiento cambió sin una razón de negocio clara. Use esa evidencia para responder tres preguntas: cuándo apareció la ruta de riesgo, quién todavía puede usarla, y si existe una exposición similar en otro lugar de su tenant de Entra ID y Azure. Una buena revisión de telemetría también le ayuda a separar la deuda técnica heredada del uso indebido activo. Esa distinción importa, porque el plan de remediación para una configuración incorrecta obsoleta es distinto del plan para una ruta que ya muestra actividad similar a la de un atacante o excepciones de política repetidas.

Debilidades Adyacentes que Vale la Pena Revisar

Muy pocos entornos contienen únicamente el Endurecimiento del tenant Azure: cómo corregir los valores predeterminados inseguros de fábrica de forma aislada. En la práctica, el mismo tenant o segmento del directorio suele contener también autenticación heredada, gobierno débil de invitados, consentimiento amplio de aplicaciones, cuentas de emergencia obsoletas y roles que nunca se revisaron, y esas debilidades vecinas determinan si el problema es simplemente ruido o realmente crítico. Revise los propietarios compartidos, los permisos heredados, las excepciones duplicadas y los atajos administrativos de larga duración. Compruebe si el mismo equipo aprobó patrones de riesgo similares en varios lugares, porque las decisiones repetidas suelen apuntar a un fallo de proceso más que a un único error técnico. Esta revisión más amplia evita una limpieza parcial y le da mejores posibilidades de eliminar toda la ruta de ataque. También mejora la preparación para auditorías, porque el estado final es más fácil de explicar y de supervisar con el tiempo.

Orden de Remediación que Reduce el Riesgo Rápidamente

Para el Endurecimiento del tenant Azure: cómo corregir los valores predeterminados inseguros de fábrica, la remediación debe seguir un orden que reduzca la exposición antes de perseguir la perfección. Elimine primero las rutas de expansión de privilegios más fáciles, luego blinde las identidades u objetos de mayor valor, y solo después limpie los huecos de higiene secundarios. Use Acceso Condicional, PIM, mínimo privilegio, revisiones de acceso, comprobaciones de propiedad de aplicaciones, flujos de aprobación y MFA robusto como el conjunto de controles que define el estado objetivo. Cada cambio debe tener un propietario, una nota de reversión y un paso de validación. Esto evita que los proyectos largos se estanquen tras la primera corrección técnica. Si un rediseño completo no es posible de inmediato, documente controles provisionales que reduzcan hoy el potencial de abuso y programe el trabajo estructural dentro de la próxima revisión operativa semanal y la revisión de endurecimiento mensual. Lo importante es la reducción medible del riesgo, no el cumplimiento cosmético.

Validación Después de Cada Cambio

Después de cambiar cualquier ajuste relacionado con el Endurecimiento del tenant Azure: cómo corregir los valores predeterminados inseguros de fábrica, valide el resultado tanto desde la perspectiva de administración como desde la perspectiva de la ruta de ataque. Confirme que los usuarios y sistemas previstos siguen funcionando, y luego demuestre que la ruta peligrosa ya no otorga la misma capacidad de abuso. Vuelva a ejecutar la recopilación de evidencia sobre registros de inicio de sesión, registros de auditoría, cambios en asignaciones de roles, eventos de consentimiento, cambios en credenciales de aplicaciones y señales de inicio de sesión de riesgo; revise los registros de aprobación, y compruebe si los objetos vecinos todavía conservan alguna vía alternativa. La validación también debe incluir una declaración escrita simple de los criterios de éxito, para que el equipo sepa qué significa el cierre. En los equipos maduros, este paso es lo que evita las regresiones: la corrección solo se acepta cuando la ruta de riesgo está cerrada, el servicio de negocio sigue funcionando, y el estado resultante coincide con el objetivo de endurecimiento que realmente se busca.

Endurecimiento del Tenant Azure: Validación Antes del Cierre

Una revisión sólida del Endurecimiento del tenant Azure debe terminar con evidencia de producción, no con la suposición de que la ruta de riesgo desapareció. Antes de cerrar el hallazgo, vuelva a comprobar las asignaciones de roles, el alcance de las políticas, los permisos de aplicaciones o la configuración de invitados, la evidencia de inicio de sesión, auditoría o riesgo del tenant real, y la ruta de excepción que podría recrear la exposición de forma silenciosa. Confirme que el estado más seguro se aplica al alcance que realmente importa: la OU de producción, la asignación de rol efectiva, la ruta de la aplicación, o la ruta de confianza y delegación que un atacante realmente explotaría. Registre el propietario técnico, la dependencia de negocio y la condición de reversión, de modo que la siguiente revisión pueda determinar si el estado más seguro se mantuvo.

Use una breve lista de verificación de cierre:

verifique que el estado de riesgo ha desaparecido desde el punto de vista del atacante, no solo en una captura de pantalla de administración
conserve una exportación o muestra de registro de antes/después que demuestre que el alcance afectado cambió
documente el propietario y la decisión de excepción si el control no pudo aplicarse por completo

Para exposiciones adyacentes, contraste el resultado con Cumplimiento AD & Azure: NIS2, ISO 27001, CIS, Brechas acceso condicional Entra ID: que errores dejan una exposicion real, Acceso privilegiado Azure: roles, PIM y administracion permanente, y Comparativa herramienta auditoria AD: cómo comparar PingCastle, Purple Knight y flujos de auditoría repetibles. El mismo hueco de control suele reaparecer en rutas de identidad cercanas, huecos de registro o permisos delegados, por lo que el paso final de validación importa tanto como el hallazgo inicial.

Endurecimiento del Tenant Azure: Evidencia a Conservar para el Próximo Ciclo de Revisión

El siguiente revisor no debería tener que reconstruir el caso de memoria. Conserve la evidencia que justificó originalmente el hallazgo, la prueba de que el cambio se aplicó, y la nota que explica por qué el estado final es aceptable. Para este tema, la evidencia más útil suele combinar la exportación del tenant o la captura de pantalla que muestra el alcance afectado, la evidencia de inicio de sesión, auditoría o política que demuestra que el control ya se aplica, y la nota de propietario, aprobación y excepción para el estado final. Ese paquete compacto hace mucho más rápidas las revisiones trimestrales o posteriores al cambio, y ayuda a explicar si el problema se eliminó, se redujo o se aceptó formalmente.

Conservar	Por qué importa
Evidencia de alcance y asignación del tenant	Muestra el alcance afectado y los objetos que cambiaron
Prueba de inicio de sesión, auditoría o política	Demuestra que el control se aplicó en producción
Registro de propietario, aprobación y excepción	Preserva la propiedad y la justificación de negocio

Si un cambio posterior de administración, política o aplicación reabre la ruta, esta evidencia histórica también facilita demostrar qué se desvió. Eso es lo que convierte el Endurecimiento del tenant Azure de una comprobación puntual en un proceso repetible de aseguramiento.

Lecturas Relacionadas

Revise este tema junto con Brechas acceso condicional Entra ID: que errores dejan una exposicion real, Acceso privilegiado Azure: roles, PIM y administracion permanente, Cuentas invitado Azure: gobierno, MFA y riesgo de acceso externo, Registros de Aplicaciones Azure: Apps Sobreprivilegiadas, y Azure Identity Protection: Bloqueo de Credenciales Filtradas. Estas publicaciones relacionadas muestran cómo las mismas debilidades de identidad suelen encadenarse en una evaluación real, en lugar de aparecer como hallazgos aislados.

El uso de estas referencias mantiene la discusión sobre remediación centrada en la ruta de ataque completa, en lugar de en un único hueco de control.

Validar la Línea Base de Endurecimiento a lo Largo del Tiempo

Los valores predeterminados deben tratarse como un punto de partida, no como el resultado final del endurecimiento. Después de aplicar valores predeterminados de tenant más seguros, confirme qué equipos todavía dependen de excepciones amplias, si las nuevas aplicaciones o usuarios pueden eludir los controles previstos, y cómo se supervisa la deriva de configuración con el tiempo. Un tenant endurecido solo se mantiene resiliente cuando la propiedad, la cadencia de revisión y la gestión de excepciones son tan disciplinadas como el despliegue inicial.