NIS2 y Active Directory: Guía Práctica de Cumplimiento para CISOs
La mayoría de las entidades esenciales e importantes tienen las medidas de gestión de riesgos documentadas.
Muy pocas han comprobado técnicamente que esas medidas aguantan sobre su Active Directory.
Después de auditar entornos AD en organizaciones que caen bajo el alcance de NIS2, veo el mismo patrón: políticas de control de acceso escritas, MFA declarado en el papel, y rutas de compromiso abiertas que nadie ha probado contra el dominio real. La revisión documental da un aprobado. Una prueba de penetración lo suspendería.
La Directiva (UE) 2022/2555 no exige un checklist de productos. Exige medidas de gestión de riesgos "adecuadas y proporcionadas" y, sobre todo, hace responsable a la dirección de que funcionen. La pregunta que llega con NIS2 no es "¿tenéis una política de control de acceso?". Es "¿cuándo verificasteis por última vez que resiste a un atacante dentro de vuestro dominio?".
Esta guía explica qué medidas del Art. 21 tocan directamente al Active Directory, cómo se concretan en la capa técnica del Reglamento de Ejecución (UE) 2024/2690, y cómo generar la evidencia que un auditor exigente te va a pedir.
¿Qué exige NIS2 sobre el Active Directory?
NIS2 no nombra el Active Directory, pero cuatro de las medidas mínimas del Art. 21(2) recaen de lleno sobre él: control de acceso y gestión de activos (i), autenticación multifactorial (j), criptografía y cifrado (h) e higiene básica y formación (g).
La Directiva (UE) 2022/2555 (NIS2) sustituye a la NIS original y amplía el número de sectores obligados. Distingue entre entidades esenciales (energía, transporte, banca, sanidad, agua, infraestructura digital, administración pública) y entidades importantes (servicios postales, gestión de residuos, fabricación, alimentación, químicas, proveedores digitales), con un régimen de supervisión más estricto para las primeras. Si tu organización cae en cualquiera de las dos categorías, el Active Directory entra en el alcance, porque es el sistema del que depende toda la autenticación y el control de acceso de la entidad.
El Art. 21(2) fija las medidas mínimas de gestión de riesgos que toda entidad debe implantar. Estas son, con su texto literal, las que impactan directamente sobre el directorio activo:
Art. 21(2)(i) — "seguridad de los recursos humanos, políticas de control de acceso y gestión de activos"
Esta medida cubre el corazón del gobierno del AD: quién tiene acceso a qué, con qué privilegio y sobre qué activos. Aplicada al directorio, significa mantener un inventario actualizado de cuentas privilegiadas (Domain Admins, Enterprise Admins, administradores locales), poder demostrar que esos privilegios están justificados y revisados, y controlar los permisos delegados sobre objetos del dominio. Las ACL olvidadas y las delegaciones sin justificación son incumplimientos directos de esta medida.
Art. 21(2)(j) — "uso de soluciones de autenticación multifactorial o de autenticación continua"
NIS2 eleva la autenticación multifactor de recomendación a medida mínima. En un entorno AD, esto expone las cuentas que dependen solo de una contraseña: cuentas de servicio, cuentas con la preautenticación de Kerberos desactivada, y protocolos heredados como NTLM que permiten relay. Donde no llega el MFA, llega el spraying, el AS-REP roasting y el relay de credenciales.
Art. 21(2)(h) — "políticas y procedimientos relativos a la utilización de criptografía y, cuando proceda, de cifrado"
Esta medida cubre las decisiones criptográficas del dominio. En AD eso significa retirar RC4 de Kerberos en favor de AES, proteger las claves más sensibles del directorio (la de krbtgt, la clave privada de la CA de ADCS) y no dejar cifrados débiles en circulación. Un ticket de servicio con cifrado RC4 es crackeable offline: es una debilidad criptográfica antes que un problema de contraseñas.
Art. 21(2)(g) — "prácticas básicas de ciberhigiene y formación en ciberseguridad"
Buena parte de las rutas de compromiso del AD nacen de higiene básica que nadie mantuvo: la firma SMB y el channel binding de LDAP sin forzar (que abren la puerta a la coerción y el relay), contraseñas en ficheros GPP dentro del SYSVOL, o SPN de cuentas de servicio que nunca rotan y quedan expuestos a Kerberoasting. Son configuraciones de higiene, y su ausencia es lo primero que un atacante busca.
Cuando un auditor evalúa tu directorio activo bajo NIS2, las preguntas son directas: ¿Tenéis inventario de cuentas privilegiadas? ¿El MFA cubre los accesos privilegiados de verdad, o solo el portal? ¿Con qué frecuencia comprobáis técnicamente las rutas de escalada? ¿Podéis demostrar esa comprobación con evidencia?
¿Qué dice la capa técnica del Reglamento de Ejecución 2024/2690?
El Reglamento de Ejecución (UE) 2024/2690 concreta las medidas del Art. 21 en requisitos técnicos detallados. Su Anexo, sección 11 (control de acceso), es la traducción operativa de la medida (i) y (j): gestión de derechos de acceso, cuentas privilegiadas, identificación única y autenticación con MFA.
La sección 11 del Anexo del Reglamento de Ejecución desglosa el control de acceso en requisitos que se leen casi como una auditoría de AD:
- 11.2 — gestión de derechos de acceso: asignar, revisar y retirar derechos siguiendo mínimo privilegio. Es el inventario de cuentas privilegiadas y la revisión periódica que la medida (i) pide en abstracto.
- 11.3 — cuentas privilegiadas: control reforzado sobre las cuentas de administración, separación de funciones y limitación de su uso. Toca directamente a Domain Admins, Enterprise Admins y a quién tiene derechos de replicación sobre el dominio.
- 11.5 — identificación única: cada usuario y cada acceso debe ser atribuible a una identidad singular. Una cuenta de administrador local reutilizada en cien equipos rompe esta identificación única antes de ser un problema de movimiento lateral.
- 11.6 y 11.7 — autenticación y MFA: mecanismos de autenticación robustos y factor múltiple para los accesos que lo requieran. Es la concreción técnica de la medida (j).
Un matiz de alcance importante, para no vender humo. El Reglamento de Ejecución 2024/2690 vincula directamente a los proveedores de infraestructura digital: servicios DNS, registros de nombres de dominio de primer nivel (TLD), proveedores de servicios en la nube, centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados (MSP y MSSP), mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza. Para el resto de sectores de NIS2, este Reglamento funciona como referencia autorizada de "qué se considera adecuado" para cumplir el Art. 21, sin ser una obligación universal. Es la mejor guía disponible de lo que un supervisor entiende por control de acceso suficiente, aunque su carácter vinculante se limite a esos sectores.
¿Qué medida de NIS2 toca cada vía de compromiso del AD?
Cada vía de ataque del Active Directory toca una o varias medidas concretas del Art. 21(2) y de la sección 11 del Reglamento de Ejecución. Esta es la tabla que un auditor tiene en la cabeza y que casi nunca aparece escrita: la vía técnica, la medida que la cubre, y la evidencia que demuestra que la medida funciona de verdad.
Una aclaración de honestidad antes de la tabla: NIS2 no nombra "Kerberoasting" ni "Active Directory". El texto de cada medida es literal de la Directiva 2022/2555 y del Reglamento 2024/2690; el mapeo de cada vía a su medida es una lectura técnica nuestra, defendible pero nuestra. No leas esto como "lo que más se incumple", sino como "los controles que tu auditor revisa y la vía de AD que los pone a prueba".
| Vía de compromiso | Medida NIS2 | Qué demuestra la evidencia |
|---|---|---|
| Kerberoasting | 21(2)(g) higiene · 21(2)(h) cripto | Ninguna cuenta de servicio con SPN sin rotar tiene contraseña crackeable ni ticket RC4 |
| AS-REP roasting | 21(2)(j) MFA/autenticación | Ninguna cuenta tiene la preautenticación de Kerberos desactivada |
| Spraying de contraseñas | 21(2)(j) MFA/autenticación | La política de contraseñas y el MFA resisten un spraying de baja frecuencia |
| Abuso de ACL (GenericAll, WriteDACL) | 21(2)(i) · Anexo 11.2/11.3 | Ningún grupo controla, por un ACE olvidado, objetos que no le corresponden |
| Delegación (unconstrained/RBCD) | 21(2)(i) · Anexo 11.2/11.3 | Ninguna cuenta puede suplantar a otra sin justificación de negocio |
| Cruce de tiers / admin local reutilizado | 21(2)(i) · Anexo 11.5 | Identificación única: LAPS desplegado, sin credenciales locales reutilizadas |
| Credenciales en GPP / shares | 21(2)(g) higiene · Anexo 11.5 | El SYSVOL no contiene contraseñas heredadas descifrables |
| NTLM relay | 21(2)(j) MFA/autenticación | Donde falta MFA no hay protocolos que permitan relay de credenciales |
| Coerción + NTLM relay | 21(2)(g) higiene | La firma SMB y el channel binding de LDAP están forzados |
| ADCS / PKI (ESC1, ESC8) | 21(2)(h) cripto · 21(2)(i) | Ninguna plantilla permite un SAN arbitrario; la clave de la CA está protegida |
| RC4 / TGS con RC4 | 21(2)(h) cripto | Kerberos usa AES y no se emiten tickets con cifrado RC4 |
| DCSync (post-compromiso) | 21(2)(i) · Anexo 11.3 + protección de claves | Solo los controladores de dominio tienen el permiso de replicación del directorio |
La columna que separa un checklist de una auditoría real es la tercera. Una medida puede estar documentada como "implantada" y a la vez ser explotable: la diferencia se ve cuando alguien intenta la vía contra tu propio dominio y comprueba si el control aguanta. En nuestras verificaciones de estas técnicas en laboratorio (GOAD), una cuenta de servicio con SPN devolvió un ticket con cifrado RC4 ($krb5tgs$23$) crackeable offline: el primer paso real de una escalada, y una configuración que habría pasado una revisión documental de las medidas (h) y (j) sin levantar una sola bandera.
Conviene separar dos momentos que un checklist confunde. Kerberoasting, AS-REP roasting o el abuso de una ACL son vías de entrada y escalada: las usa alguien que todavía no controla el dominio, y Kerberoasting sigue siendo la cadena de compromiso más frecuente que encontramos. DCSync es distinto. Casi nunca es la vía de entrada, porque muy pocas cuentas sin privilegios tienen derechos de replicación sobre el dominio. Es la técnica post-compromiso más habitual: la ejecuta quien ya es Domain Admin para volcar el NTDS y crackear todos los hashes, incluido el de krbtgt. Por eso la protección de las claves y la auditoría de quién tiene derechos de replicación (Anexo 11.3) importan: son la última barrera y la que demuestra si un compromiso llegó hasta el final.
¿Cómo auditar tu AD para NIS2?
Una auditoría técnica de AD para NIS2 debe cubrir cinco áreas: inventario de cuentas privilegiadas, rutas de escalada activas, cobertura real del MFA, configuración criptográfica de Kerberos y ADCS, y mapeo explícito de cada hallazgo a la medida del Art. 21 que pone a prueba.
El enfoque tradicional es contratar una consultoría externa. El coste típico de una auditoría técnica de AD en España oscila entre 5.000 y 10.000 euros, el plazo suele ser de semanas, y el resultado es un informe puntual que queda obsoleto en cuanto cambia algo en el entorno. NIS2 pide gestión continua del riesgo, no una foto anual.
Una auditoría técnica de AD para NIS2 debe cubrir cinco áreas:
- Inventario de cuentas privilegiadas — Domain Admins, Enterprise Admins, administradores locales, cuentas con derechos de replicación, cuentas de servicio con SPN
- Detección de rutas de escalada activas — Kerberoasting, ADCS, delegaciones, GPP, ACL con permisos excesivos, cruce de tiers
- Cobertura real del MFA y de la autenticación — qué accesos privilegiados dependen solo de contraseña, qué protocolos heredados permiten relay
- Configuración criptográfica — uso de AES sobre RC4 en Kerberos, plantillas ADCS, protección del krbtgt y de la clave de la CA
- Informe con mapeo explícito a las medidas del Art. 21 — cada hallazgo referenciado a la medida NIS2 (y, cuando aplique, a la sección 11 del Reglamento de Ejecución) que pone a prueba, con el riesgo y la recomendación
ADscan automatiza estas cinco fases en una sola sesión. Detecta los vectores, los prioriza por impacto real (no por severidad teórica), y genera el informe con el mapeo de medidas incluido. Sin instalar agentes en los controladores de dominio. Sin cambios en la infraestructura.
Para entender el enfoque de ADscan sobre cada control regulatorio del directorio, tienes también la guía de cumplimiento de NIS2 para Active Directory en adscanpro.com/es/nis2, y si tu organización opera además bajo el Esquema Nacional de Seguridad, la guía de ENS Alto y Active Directory cubre el mapeo equivalente a los controles del Anexo II.
¿Cómo funciona la evaluación gratuita de AD para NIS2?
Un técnico de ADscan se conecta vía VPN, ejecuta el análisis en directo sin instalar agentes y entrega el informe con el mapeo a las medidas de NIS2 ese mismo día.
Si tu organización cae bajo el alcance de NIS2 y quieres conocer el estado real de tu Active Directory antes de que lo mire un auditor o un supervisor, ADscan ofrece una sesión de evaluación gratuita en tu entorno.
Cómo funciona: un técnico de ADscan se conecta vía VPN a vuestra red, ejecuta el análisis en directo mientras el equipo lo observa, y entrega el informe ese mismo día. No se instala ningún agente. No se hacen cambios en la infraestructura. El proceso completo dura entre una y dos horas.
El informe incluye:
- Rutas de ataque detectadas en vuestro entorno, con demostración de la cadena de explotación
- Mapeo explícito de cada hallazgo a las medidas del Art. 21 correspondientes
- Priorización por impacto real, no por severidad teórica
- Recomendaciones de remediación para cada vector
Sin coste. Sin compromiso. Sin instalación.
Solicita tu evaluación gratuita en adscanpro.com/es/evaluacion
¿Qué exige NIS2 en la práctica?
NIS2 no exige ser invulnerable. Exige demostrar que conoces tu exposición, que la gestionas de forma sistemática y que puedes probarlo con evidencia técnica, con la dirección respondiendo de que las medidas funcionan. Esa responsabilidad de la dirección es lo que diferencia a NIS2 de los marcos anteriores.
Conviene tener presente el contexto español. A fecha de hoy, NIS2 no está transpuesta en España: la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE el 9 de julio de 2026 (caso INFR(2024)0270) por el retraso en la transposición, pidiendo una suma a tanto alzado y una multa diaria hasta que se corrija. Circulan cifras de sanciones de 10 millones de euros o el 2% de la facturación, pero esas proceden del anteproyecto español, que todavía no es ley promulgada. La obligación europea existe ya; el régimen sancionador nacional exacto se conocerá cuando se apruebe la norma de transposición.
El Active Directory es el activo del que depende toda la autenticación de tu organización y el más frecuentemente comprometido en los incidentes reales. Una auditoría técnica periódica no es un lujo ni un coste adicional: es la evidencia que un supervisor va a pedir y la diferencia entre demostrar gestión del riesgo con solidez o exponer carencias en el peor momento.
El primer paso es siempre el mismo: conocer tu estado actual. Para eso existe la evaluación gratuita.
