Cumplimiento AD & Azure: NIS2, ISO 27001, CIS

¿Qué es el Cumplimiento de AD y Azure?

El Cumplimiento de AD y Azure solo resulta útil cuando los requisitos del marco normativo se traducen en evidencia de producción. En entornos construidos sobre Active Directory y Microsoft Entra ID, eso significa demostrar cómo se aplican realmente la política de contraseñas, el acceso privilegiado, la MFA, el registro de auditoría, la gobernanza del ciclo de vida y los controles de acceso de terceros.

La parte difícil es la traducción. El texto de los marcos normativos es intencionalmente de alto nivel, mientras que la evidencia técnica que un auditor o un responsable de seguridad realmente necesita es específica: qué política de contraseñas está activa, qué cuentas de administrador todavía tienen privilegios permanentes, qué protecciones de inicio de sesión se aplican, qué registros se conservan y qué rutas de invitados o entre inquilinos siguen abiertas.

Este artículo relaciona los requisitos habituales de cumplimiento con controles técnicos de identidad que se pueden verificar en AD y Azure sin convertir el ejercicio en una auditoría de solo hoja de cálculo.

Cómo Funciona

Las revisiones de cumplimiento centradas en identidad suelen examinar cinco áreas:

• Política de autenticación, como la longitud y complejidad de las contraseñas, la MFA y la exposición a protocolos heredados
• Control de acceso privilegiado, como el alcance de los roles de administrador, el acceso justo a tiempo y la gobernanza de cuentas de emergencia (break-glass)
• Auditoría y monitorización, como la Política de Auditoría Avanzada en los Controladores de Dominio, los registros de auditoría de Entra y la cadencia de revisión
• Ciclo de vida del acceso, como el aprovisionamiento, la limpieza de cuentas obsoletas y la baja de cuentas
• Acceso externo y de aplicaciones, como la gobernanza de invitados, el consentimiento de aplicaciones y la confianza entre inquilinos

Cada área se puede traducir en un conjunto de verificaciones técnicas y evidencia de respaldo.

Mapeo del Marco de Cumplimiento de AD y Azure

Directiva NIS2

El Artículo 21(1) de NIS2 exige que los Estados miembros garanticen que las entidades esenciales e importantes adopten "medidas técnicas, operativas y organizativas adecuadas y proporcionadas" para gestionar sus riesgos de ciberseguridad. En materia de identidad, esto suele traducirse en los siguientes controles:

CIS Controls v8.1

Los CIS Controls convierten el hardening de identidad en acciones defensivas priorizadas. La numeración sigue CIS Controls v8.1, la versión actual, y no ha cambiado respecto a la v8:

ISO 27001:2022

Los controles del Anexo A de ISO 27001 que con más frecuencia se relacionan con la seguridad del directorio incluyen:

Expectativas de Hardening del Directorio al Estilo ANSSI

Para las organizaciones que se alinean con las directrices de estilo ANSSI, los temas prácticos de identidad son consistentes; consulte la Guía ANSSI de Active Directory para conocer el conjunto completo de recomendaciones:

• reducir la autenticación y la criptografía heredadas cuando la compatibilidad de las aplicaciones lo permita
• aislar o reforzar las cuentas privilegiadas en lugar de permitir que las identidades de uso diario mantengan privilegios permanentes
• documentar las excepciones para los sistemas heredados en lugar de arrastrarlas silenciosamente de forma indefinida
• validar que la monitorización, el acceso privilegiado y los controles de contraseñas se aplican en producción y no solo se declaran en la política

La Evaluación de Brechas de Cumplimiento

Paso 1 - Establezca la Línea Base de su Estado Actual

# Línea base de la política de contraseñas
Get-ADDefaultDomainPasswordPolicy |
  Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# Línea base de Acceso Condicional en Entra
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {$_.State -eq "enabled"} |
  Select-Object DisplayName, State

# Línea base de la política de auditoría en un controlador de dominio
auditpol /get /category:"Account Logon","DS Access","Account Management" |
  Select-String "Success|Failure"

Paso 2 - Relacione las Brechas con Controles Nombrados

$policy = Get-ADDefaultDomainPasswordPolicy

# La caducidad de contraseña deliberadamente NO se puntúa como un control. Microsoft eliminó
# las políticas de caducidad de contraseña de sus líneas base de seguridad de Windows en 2019 y la califica
# como "una mitigación antigua y obsoleta de muy poco valor". Capture MaxPasswordAge como
# evidencia, y puntúelo solo cuando un marco normativo o una política interna sigan exigiendo la rotación.
$policy.MaxPasswordAge

$checks = @{
    "Min password length >= 14"   = $policy.MinPasswordLength -ge 14
    "Password complexity enabled" = $policy.ComplexityEnabled
    "DS Changes audit enabled"    = (auditpol /get /subcategory:"Directory Service Changes") -match "Success"
    "Kerberos audit enabled"      = (auditpol /get /subcategory:"Kerberos Authentication Service") -match "Success"
}

$checks.GetEnumerator() | ForEach-Object {
    [PSCustomObject]@{
        Control = $_.Key
        Status  = if ($_.Value) { "PASS" } else { "FAIL" }
    }
} | Format-Table -AutoSize

Paso 3 - Priorice por Exposición, no por Cantidad de Casillas Marcadas

1. Crítico: Sin MFA para identidades privilegiadas, sin control sobre las asignaciones de roles de alto riesgo, delegación sin restricciones, principals capaces de DCSync
2. Alto: Política de contraseñas débil, falta de cobertura de auditoría, demasiados administradores permanentes, gobernanza de invitados débil
3. Medio: Cuentas obsoletas, ausencia de LAPS, proceso de revisión de roles incompleto, controles granulares ausentes donde se necesitan
4. Bajo: Brechas de documentación, inconsistencias de nomenclatura, problemas de presentación no materiales

Detección

La evidencia de cumplimiento es débil si solo existe en el momento de la auditoría. Los controles que importan deben poder revisarse de forma continua.

Verificaciones de Cumplimiento Continuas

# Desviación de grupos privilegiados en los últimos 7 días, verificada en cada controlador de dominio.
# whenChanged NO se replica: cada DC mantiene su propio valor, así que consultar un único DC pasa
# silenciosamente por alto un cambio que se escribió en otro lugar.
$cutoff = (Get-Date).AddDays(-7)
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-ADGroup "Domain Admins" -Properties whenChanged -Server $dc |
      Where-Object {$_.whenChanged -gt $cutoff} |
      Select-Object @{Name="DC";Expression={$dc}}, Name, whenChanged
}

# Cuentas habilitadas inactivas durante 90 días o más.
# -Filter no es un bloque de script de PowerShell: solo acepta <atributo> <operador> <valor>, así que
# el límite se debe calcular primero. LastLogonDate tampoco está en el conjunto de propiedades
# predeterminado, así que se debe solicitar explícitamente o la columna vuelve vacía.
$inactive = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true -and LastLogonDate -lt $inactive' -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate

Remediación

Secuencia de Remediación Prioritaria

1. Aplicar MFA para cuentas privilegiadas y acceso sensible a la nube
2. Reducir el privilegio permanente revisando las asignaciones de roles y usando la elevación justo a tiempo donde esté disponible
3. Habilitar la cobertura de auditoría en los Controladores de Dominio y en Entra para que los fallos de control sean revisables
4. Corregir la higiene de contraseñas, incluyendo la longitud, la complejidad, las listas de contraseñas prohibidas y la proliferación de excepciones
5. Limpiar las identidades obsoletas y huérfanas en AD y Azure
6. Revisar el acceso de invitados y entre inquilinos para que el acceso de terceros esté gobernado
7. Documentar las excepciones justificadas con propietario, motivo y fecha de revisión

Cómo lo Detecta EtcSec

EtcSec relaciona los hallazgos técnicos con las familias de controles a las que se hace referencia con más frecuencia en el trabajo de cumplimiento.

Cada hallazgo relevante ayuda a responder tres preguntas prácticas:

• qué control de identidad falta o es débil
• qué cuentas, roles u objetos se ven afectados
• qué evidencia debería recopilar el equipo de seguridad para demostrar que la brecha está cerrada

La categoría Compliance es útil cuando se quiere convertir hallazgos técnicos en bruto en una lista de remediación accionable, en lugar de una hoja de cálculo genérica de marcos normativos.

Paquete de Evidencia de Cumplimiento de AD y Azure

Una revisión de cumplimiento sólida suele fallar por dos motivos: el control nunca se implementó en producción, o el equipo no puede demostrar que se implementó. Construya un paquete de evidencia que resista tanto un cuestionamiento interno como una auditoría externa:

• salida actual de la política de contraseñas y cualquier excepción granular aprobada
• exportaciones de roles privilegiados y pertenencia a grupos privilegiados, incluidas las asignaciones permanentes
• estado del Acceso Condicional o de los Valores Predeterminados de Seguridad para el inquilino en cuestión
• salida de la política de auditoría del Controlador de Dominio para las subcategorías en las que se basa la detección
• configuración de acceso de invitados, entre inquilinos y de aplicaciones para las poblaciones cubiertas por la revisión
• propietario, motivo de la excepción y fecha de revisión para todo lo que aún no pueda cumplir el estado objetivo

Ese paquete de evidencia es lo que convierte el Cumplimiento de AD y Azure de un ejercicio de presentación en una revisión de control repetible.

Ejecutar una Revisión en Lugar de Tres

Las organizaciones que se enfrentan a NIS2, ISO 27001 y CIS Controls al mismo tiempo rara vez necesitan tres ciclos de revisión independientes. Los tres marcos normativos convergen en el mismo puñado de primitivas de identidad (MFA, gobernanza del acceso privilegiado, higiene de contraseñas y cobertura de auditoría), por lo que una única revisión técnica puede producir evidencia que satisfaga las tres relaciones a la vez.

Un enfoque práctico de secuenciación:

1. Construya primero una única línea base de controles. Capture una vez la política de contraseñas, el estado del Acceso Condicional, la salida de la política de auditoría y la pertenencia a grupos privilegiados. Cada relación de marco normativo anterior parte del mismo puñado de datos.
2. Etiquete los hallazgos frente a todos los marcos que satisfacen, no solo uno. Una única brecha de MFA en una cuenta de Administrador Global es simultáneamente una brecha del Artículo 21(2)(j) de NIS2, una brecha del Control CIS 6 y una brecha de A.8.5 de ISO 27001. Registrarla una vez con varias etiquetas evita recopilar la misma evidencia tres veces.
3. Priorice por valor para el atacante y complete después el papeleo. Corregir primero las brechas de mayor exposición (delegación sin restricciones, cuentas capaces de DCSync, acceso de Administrador Global permanente sin MFA) cierra hallazgos en los tres marcos normativos antes de marcar una sola casilla de cumplimiento.
4. Mantenga la documentación de excepciones en un solo lugar. Una aplicación heredada que no puede admitir MFA es un único registro de excepción con un único propietario y una única fecha de revisión, no tres justificaciones distintas presentadas ante tres marcos normativos diferentes.

Esta secuenciación es más importante para los equipos que heredaron el trabajo de cumplimiento como efecto colateral de una revisión de seguridad, en lugar de equipos que parten de un documento de marco normativo en blanco. La evidencia técnica subyacente (política de contraseñas, cobertura de auditoría, estado del acceso privilegiado) no cambia según el marco normativo que la solicite.

Brechas Comunes que Reaparecen Cada Trimestre

Incluso los equipos maduros tienden a reabrir las mismas brechas de cumplimiento de identidad:

• excepciones de aplicaciones heredadas que preservan silenciosamente la autenticación débil
• identidades privilegiadas obsoletas que nunca se eliminaron tras un proyecto o un cambio de personal
• exclusiones de Acceso Condicional añadidas durante un incidente y nunca revisadas
• rutas de acceso de invitados que siguen siendo más amplias de lo que permite la política escrita
• controles de monitorización que se documentaron una vez pero ya no se validan en los Controladores de Dominio actuales ni en el alcance actual del inquilino

Si esas brechas no se registran como deuda operativa con un propietario asignado, la relación con el marco normativo parecerá saludable mientras la superficie de ataque permanece prácticamente sin cambios.

Lecturas Relacionadas

Para profundizar en el aspecto técnico de estas mismas familias de controles, consulte Acceso privilegiado Azure: roles, PIM y administracion permanente, Azure Identity Protection: Bloqueo de Credenciales Filtradas, Auditar la seguridad de Active Directory: qué revisar primero y cómo demostrar la remediación, y Registros de Aplicaciones Azure: Apps Sobreprivilegiadas. Esos artículos ayudan a convertir el lenguaje de los marcos normativos en pasos concretos de hardening y validación.