DORA y Active Directory: Obligaciones de Seguridad para Entidades Financieras
El supervisor del Banco de España no va a preguntar si tenéis una política de seguridad.
Va a preguntar cuándo fue la última vez que comprobasteis técnicamente que funciona.
DORA entró en vigor en enero de 2025. Llevo meses hablando con equipos de seguridad de entidades financieras que tienen los controles documentados perfectamente y el Active Directory sin auditar técnicamente desde hace años. No es negligencia — es que nadie hasta ahora lo había exigido de forma vinculante. Eso cambió.
DORA (EU 2022/2554) crea obligaciones concretas y exigibles sobre la gestión del riesgo TIC, no objetivos de mejora. El Active Directory es el activo TIC del que depende toda la operación de una entidad financiera. Si un atacante lo compromete, cae con él la capacidad de autenticar usuarios, acceder a aplicaciones críticas y operar con normalidad. Este artículo explica qué exige exactamente DORA sobre el AD y cómo preparar la evidencia antes de que te la pida el supervisor.
Qué exige DORA sobre el Active Directory
DORA no menciona el Active Directory por su nombre. No hace falta: los artículos del reglamento cubren directamente los dominios que hacen del AD el activo más relevante para el cumplimiento TIC de cualquier entidad financiera.
Art. 6 — Marco de gestión del riesgo TIC
El artículo 6 obliga a identificar todos los activos TIC críticos, documentar las dependencias entre ellos y mantener un inventario actualizado. El Active Directory cumple esta definición con claridad: es el punto único de autenticación del que dependen los sistemas bancarios, las plataformas de trading, los accesos a bases de datos de clientes y los sistemas de back office. Si no está en el inventario de activos críticos con sus controles documentados, el marco de gestión del riesgo TIC está incompleto.
Art. 9 — Protección y prevención
Este artículo exige controles de acceso, gestión de identidades privilegiadas y segmentación de sistemas críticos. Traducido al entorno AD: inventario de cuentas con privilegios elevados (Domain Admins, Enterprise Admins, operadores de backup), revisión periódica de esos privilegios, y separación de las cuentas de administración del dominio respecto a las cuentas de uso diario. También cubre la protección contra técnicas de escalada que permiten a un atacante pasar de un usuario sin privilegios a administrador de dominio.
Art. 10 — Detección
DORA exige capacidades de monitorización continua y detección de anomalías. En el contexto del Active Directory, esto significa que los inicios de sesión inusuales, los cambios de permisos sobre objetos críticos, las solicitudes de replicación del dominio y las modificaciones de configuración de Kerberos deben estar siendo detectados en tiempo real. No es suficiente tener un SIEM configurado: hay que poder demostrar que los eventos relevantes del AD están siendo consumidos y correlacionados.
Art. 11 — Respuesta y recuperación
El plan de respuesta a incidentes debe contemplar escenarios de compromiso del Active Directory. Un compromiso total del dominio — obtención del hash de krbtgt, creación de cuentas de administrador ocultas, extracción masiva de credenciales — es el escenario de mayor impacto para una entidad financiera. Si el plan de respuesta no cubre ese escenario con pasos concretos de contención y recuperación, no cumple los requisitos del artículo 11.
Art. 13 — Pruebas de resiliencia TIC (TLPT)
Este es el artículo que más preocupa a los responsables de seguridad. Para las entidades consideradas significativas, DORA exige pruebas de penetración basadas en inteligencia de amenazas (Threat-Led Penetration Testing, TLPT). Estas pruebas deben realizarse por equipos externos independientes, con alcance sobre los sistemas críticos de la entidad — entre ellos, el Active Directory. No es una prueba de caja negra genérica: es un ejercicio técnico guiado por inteligencia de amenazas real, donde el AD es objetivo prioritario.
Los vectores de ataque AD más relevantes para DORA
Los mismos vectores que el CCN-CERT detecta en organizaciones del sector financiero son los que los equipos de TLPT van a buscar cuando realicen las pruebas exigidas por el Art. 13. Conocerlos con antelación no es opcional: es la diferencia entre controlar el resultado o descubrir los problemas en el peor momento.
Kerberoasting
Cualquier usuario del dominio puede solicitar un ticket de servicio Kerberos para una cuenta que tenga un SPN registrado. Si esa cuenta tiene una contraseña débil — cosa habitual en cuentas de servicio heredadas — el ticket puede crackearse offline sin necesidad de interactuar más con el DC. En entidades financieras con entornos AD que llevan años en producción, es frecuente encontrar cuentas de servicio con SPNs registrados, contraseñas que nunca expiran y acceso a sistemas de negocio críticos.
Artículos DORA implicados: Art. 9 (identidades privilegiadas) y Art. 10 (detección de solicitudes de tickets anómalas). Evidencia requerida: inventario de cuentas con SPN, política de contraseñas para cuentas de servicio, y verificación técnica de que ninguna cuenta de servicio con acceso a sistemas críticos tiene contraseña crackeada.
ADCS — Escalada mediante certificados
Las misconfiguraciones en las plantillas de Active Directory Certificate Services permiten a un atacante solicitar certificados en nombre de otras identidades, incluyendo administradores de dominio. La vulnerabilidad ESC1 permite impersonar a cualquier usuario del dominio. ESC8 permite hacer relay de autenticación NTLM hacia el servicio de certificados para obtener un certificado de dominio válido.
Artículos DORA implicados: Art. 9 (controles de acceso y gestión de identidades) y Art. 11 (plan de respuesta — un certificado fraudulento puede seguir siendo válido durante años después de un compromiso). Evidencia requerida: revisión de todas las plantillas de certificados, verificación de configuraciones ESC1 a ESC16.
DCSync
Si una cuenta tiene permisos de replicación sobre la partición del dominio, puede simular ser un controlador de dominio y solicitar una replicación completa — incluyendo todos los hashes NTLM del directorio. El atacante obtiene las credenciales de todos los usuarios, incluyendo el hash de krbtgt, que permite generar Golden Tickets con validez indefinida.
Artículos DORA implicados: Art. 9 (acceso a activos críticos), Art. 11 (escenario de máximo impacto, recuperación requiere rotación de krbtgt y revisión completa). Evidencia requerida: auditoría de ACLs sobre la raíz del dominio, inventario de cuentas con permisos de replicación.
Delegaciones Kerberos sin restricciones
Un equipo con delegación sin restricciones (TrustedForDelegation) almacena en memoria los TGTs de todos los usuarios que se autentican contra él. Un atacante con acceso local a ese equipo puede reutilizar esos tickets para impersonar a cualquier usuario del dominio.
Artículos DORA implicados: Art. 9 (segmentación y control de accesos privilegiados), Art. 10 (monitorización de configuraciones de riesgo). Evidencia requerida: inventario de equipos y cuentas con delegación configurada, justificación de negocio y controles compensatorios para cada caso.
La diferencia entre cumplimiento documental y resiliencia real
La mayoría de entidades financieras tienen políticas de seguridad para el Active Directory. Política de contraseñas, procedimiento de revisión de accesos privilegiados, plan de recuperación ante desastres. El problema es que estas políticas se redactan, se aprueban en comité y raramente se verifican técnicamente de forma sistemática.
DORA, y en particular el Art. 13, hace que esa distinción sea relevante ante el supervisor. Una entidad puede presentar una política de gestión de identidades privilegiadas correctamente redactada y aun así tener cuentas de servicio con contraseñas de diez años, plantillas ADCS con ESC1 activo y objetos con permisos de DCSync no justificados.
La diferencia concreta que empieza a hacer el regulador es esta: "tenemos una política de contraseñas para cuentas de servicio" versus "hemos verificado técnicamente que no existe ninguna cuenta con SPN y contraseña crackeable en nuestro entorno". La primera es documentación. La segunda es evidencia.
Los equipos de TLPT van a ejecutar exactamente esas verificaciones sobre vuestro entorno real. El resultado del ejercicio va a documentar lo que el regulador verá. Prepararse antes — con las mismas herramientas técnicas que un equipo ofensivo utilizaría — es la única forma de controlar ese resultado.
Cómo preparar la evidencia para el supervisor
El Banco de España, la CNMV y la DGSFP no van a pedir documentos genéricos. Van a pedir evidencias técnicas concretas que demuestren que la gestión del riesgo TIC es real y continua, no un ejercicio de redacción de políticas.
La documentación que necesitas tener preparada incluye:
- Inventario de cuentas privilegiadas actualizado, con fecha de última revisión y justificación de negocio para cada cuenta con acceso elevado
- Registro de cambios en el AD — quién modificó qué, cuándo, y con qué autorización — consumido y almacenado de forma que no pueda ser alterado
- Resultados de pruebas técnicas periódicas sobre el estado del directorio: vectores detectados, severidad, fecha de detección y estado de remediación
- Plan de remediación con fechas comprometidas para cada hallazgo técnico abierto
ADscan genera todo esto automáticamente en una sola sesión de análisis. El informe incluye mapeo explícito de cada hallazgo a los artículos DORA correspondientes, rutas de ataque detectadas con puntuación CVSS, y un roadmap de remediación priorizado por impacto real.
Para entidades financieras bajo DORA que necesitan preparar esta documentación antes de una inspección supervisora o de un ejercicio TLPT, solicita una evaluación gratuita de tu AD en adscanpro.com/es/evaluacion. El informe DORA se entrega ese mismo día.
Conclusión
DORA no inventa la necesidad de auditar el Active Directory. Lo que hace es convertirla en obligación regulatoria con consecuencias exigibles. La pregunta ya no es si deberíais auditar vuestro AD: es cuándo lo vais a hacer y con qué evidencia lo vais a demostrar ante el supervisor.
Para la mayoría de entidades financieras, el estado real del Active Directory no se corresponde con lo que dicen sus políticas de seguridad. La brecha entre ambos es exactamente lo que un equipo de TLPT va a documentar — y lo que el regulador va a ver.
Conocer ese estado real antes que el regulador no es una ventaja competitiva. Es el mínimo que DORA exige.