Endurecimiento Active Directory

El endurecimiento Active Directory no es un simple proyecto de GPO ni una checklist que se ejecuta una sola vez. Un plan útil de endurecimiento de Active Directory reduce el número de rutas privilegiadas, elimina protocolos débiles y secretos reutilizables, y demuestra que los controles siguen funcionando después del despliegue. Si primero necesita el flujo general de revisión, empiece por Auditar la seguridad de Active Directory: qué revisar primero y cómo demostrar la remediación. Este artículo es más estrecho: se centra en qué bloquear primero.

Qué significa realmente el endurecimiento Active Directory

En la práctica, endurecer Active Directory significa reducir el número de maneras en que un atacante puede alcanzar el control privilegiado y después proteger y vigilar las rutas administrativas que permanecen. La estrategia de acceso privilegiado de Microsoft trata explícitamente el acceso privilegiado como la prioridad de seguridad más alta y recomienda limitar las acciones privilegiadas a unas pocas vías autorizadas, después estrechamente protegidas y supervisadas.

Por eso un buen trabajo de endurecimiento tiene que seguir un orden. Si empieza con ajustes cosméticos de baseline antes de separar identidades privilegiadas, endurecer hosts administrativos y retirar secretos reutilizables, el plano de control puede seguir siendo fácil de alcanzar. La Guía ANSSI Active Directory: cómo aplicar las recomendaciones de seguridad en la práctica llega a la misma conclusión operativa desde otro ángulo: primero compartimentar el modelo de administración y después endurecer los controles que lo sostienen.

El endurecimiento de Active Directory empieza por los accesos privilegiados y las rutas administrativas

La primera prioridad es el acceso privilegiado, no porque sea un tema de moda, sino porque la compromisión de cuentas y rutas privilegiadas suele derrumbar el resto del modelo de seguridad del directorio. La guía de Microsoft sobre secure administrative hosts es directa: nunca se debe administrar un sistema de confianza desde un host menos confiable, y los hosts administrativos dedicados no deberían ejecutar software de uso diario como correo, navegadores web o suites ofimáticas.

Eso da la primera secuencia de endurecimiento:

Separar las cuentas privilegiadas de las identidades del día a día.
Mover la administración privilegiada a estaciones dedicadas, jump hosts o secure administrative hosts equivalentes.
Restringir dónde pueden autenticarse las identidades de alto privilegio.
Medir si todavía se producen sesiones privilegiadas desde equipos de usuario normales.

Aquí es también donde encajan controles como el grupo de seguridad Protected Users y Authentication Policies / Authentication Policy Silos. Son controles de contención útiles para las cuentas correctas, pero no son ajustes universales que deban activarse por defecto. Microsoft documenta caveats importantes: los miembros de Protected Users deben poder autenticarse con AES, no se deben añadir cuentas de servicio ni de equipo, y las cuentas altamente privilegiadas no deberían añadirse hasta validar el impacto operativo. Los authentication policy silos pueden restringir además en qué hosts determinados usuarios, equipos y cuentas de servicio muy privilegiados están autorizados a autenticarse, lo que los hace útiles una vez definidos los tiers administrativos y sus rutas.

Reducir después la exposición de protocolos y del directorio

Una vez estrechadas las rutas privilegiadas, el siguiente paso en el endurecimiento de Active Directory es reducir la exposición de protocolos que todavía permite interceptación, manipulación o hábitos de administración débiles.

LDAP signing y channel binding

Microsoft documenta LDAP signing y LDAP channel binding como protecciones del tráfico LDAP de AD DS. LDAP signing ayuda a verificar autenticidad e integridad, mientras que channel binding vincula la capa de aplicación con la sesión TLS subyacente para ayudar a impedir secuestro y escenarios man-in-the-middle. En la práctica, esto significa que un plan serio de endurecimiento debe revisar si los SASL binds no firmados o los patrones LDAP inseguros siguen tolerados por los controladores de dominio.

El error clásico es imponer el ajuste a ciegas. Antes de endurecerlo, valide qué aplicaciones, appliances, scripts o middleware legacy siguen dependiendo de un comportamiento LDAP débil. Después conserve la prueba de esa revisión de compatibilidad y del estado final impuesto. El deep dive asociado sigue en inglés: LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

SMB signing

La guía de Microsoft sobre SMB signing es igual de útil como control de endurecimiento porque protege la integridad de los mensajes y ayuda a defenderse frente a relay y spoofing. Exigir SMB signing en rutas administrativas y de gestión de archivos de alto valor suele ser un control prioritario.

De nuevo, el orden de imposición importa. Microsoft señala que pueden aparecer problemas de compatibilidad cuando se exigen firmas en entornos con servidores de archivos no Microsoft. El movimiento correcto no es «activarlo en todas partes de inmediato», sino «medir dónde sigue existiendo SMB sin firma, validar dependencias y después imponer con evidencia». El deep dive asociado es Firma SMB deshabilitada: por qué sigue habilitando NTLM relay.

El endurecimiento de Active Directory implica reducir secretos reutilizables

Muchas intrusiones en AD siguen acelerándose porque los secretos reutilizables continúan siendo demasiado fáciles de robar, reutilizar o mover lateralmente. Esta es la tercera prioridad porque suele limitar hasta dónde puede propagarse la compromisión de un solo host.

Windows LAPS

Microsoft documenta Windows LAPS como la funcionalidad integrada que administra y respalda automáticamente las contraseñas de las cuentas de administrador local, y también puede gestionar la contraseña DSRM en controladores de dominio Windows Server Active Directory. Eso lo convierte en un control central de endurecimiento, no en una mera comodidad. Si las contraseñas de administrador local o DSRM siguen siendo estáticas, compartidas o rotadas manualmente, el entorno conserva un riesgo lateral evitable.

El objetivo no es solo desplegarlo. Hay que validar la rotación de contraseñas, los permisos de recuperación, el destino del backup y si las excepciones siguen dejando parte del parque fuera del control. Deep dive asociado: Windows LAPS no implementado: por qué siguen importando las contraseñas compartidas de administrador local.

Contraseñas de cuentas de servicio y gMSA

La guía de Microsoft sobre group Managed Service Accounts es valiosa porque reduce la carga administrativa de gestionar contraseñas de cuentas de servicio y simplifica la gestión de SPN. Cuando el soporte aplicativo lo permite, pasar de cuentas de servicio basadas en usuarios tradicionales a gMSA elimina una clase de contraseñas de larga vida administradas manualmente.

Esto no es una orden universal de migración. Hay que validar soporte aplicativo, comportamiento de clústeres o granjas, dependencias de SPN y ownership operativo antes de convertir. Para las cuentas que todavía no pueden migrar a gMSA, reduzca la antigüedad de contraseña, elimine privilegios innecesarios y revise si la cuenta sigue siendo el principal correcto para el servicio.

Endurecimiento dirigido de políticas de contraseña

La guía de Microsoft sobre fine-grained password policies es útil aquí, pero solo en el ámbito correcto. Las fine-grained password policies se aplican a objetos de usuario y grupos de seguridad globales, no como sustituto universal de la gobernanza general de contraseñas. Úselas cuando necesite un tratamiento más estricto para determinadas poblaciones de cuentas administrativas o de servicio, no como sustituto de una mejor higiene global de credenciales. Para la capa adyacente de control de contraseñas, el deep dive sigue en inglés: Active Directory Password Security: Misconfigurations That Matter.

Limitar la delegación y otras rutas de escalada

La cuarta prioridad es el plano de control alrededor del propio directorio: permisos delegados, control de grupos privilegiados, administración de GPO y derechos relacionados con replicación que no deberían quedar ampliamente accesibles.

La documentación de Microsoft sobre Group Policy recuerda que una GPO no es solo «un ajuste». Tiene un componente de AD y otro de sistema de archivos, y se aplica mediante la lógica normal de alcance del directorio. Por eso los permisos de GPO y el scope de sus enlaces pertenecen al endurecimiento y no solo al troubleshooting. Si usuarios de bajo privilegio pueden influir en una GPO que alcanza sistemas privilegiados, el programa de endurecimiento tiene un hueco estructural. El artículo adyacente sigue en inglés: GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

La misma lógica aplica a los permisos vinculados con replicación. Microsoft documenta Replicating Directory Changes como una ACE presente en cada domain naming context y que puede otorgarse explícitamente a cuentas. Eso significa que el acceso con capacidad de replicación debe tratarse como acceso privilegiado y revisarse explícitamente, no asumirse como inofensivo porque no se llame «Domain Admin». El problema más amplio de las cadenas de abuso se cubre en Rutas de ataque AD: cómo las malas configuraciones se encadenan hasta Domain Admin.

Si AD CS está desplegado, debe incluirse en el mismo programa de endurecimiento. Microsoft documenta AD CS como el rol de Windows Server que emite y administra certificados usados en comunicación segura y autenticación. En otras palabras, si existe autenticación basada en certificados en el entorno, endurecer el directorio ignorando el plano de control de certificados deja una brecha material. Mantenga el alcance condicional: si AD CS no está desplegado, no hay que forzarlo dentro del programa. Si sí lo está, revise Rutas de ataque ADCS: cómo los errores de certificados se convierten en rutas de escalada en Active Directory.

Integrar logging y validación en el plan de endurecimiento

Un endurecimiento que no puede volver a medirse acaba derivando a la conjetura. Las recomendaciones de Microsoft sobre audit policy y recopilación de eventos dejan claro el punto operativo: primero hacen falta los ajustes correctos de auditoría y después la ruta correcta de recopilación y retención.

Windows Event Forwarding y Windows Event Collector pueden centralizar los eventos que decida reenviar, pero no sustituyen el diseño de la política de auditoría. La telemetría sobre cambios de objetos del directorio solo es útil cuando existen los ajustes de auditoría necesarios y la cobertura SACL correcta. Por ejemplo, Microsoft documenta que el Event 5136 se genera cuando se modifica un objeto del servicio de directorio, pero solo si el objeto tiene la entrada SACL pertinente para la acción de escritura auditada.

Eso lleva a una regla práctica para los programas de endurecimiento:

conservar exportaciones antes y después del cambio para miembros de grupos privilegiados, estado de GPO, estado de políticas LDAP y SMB, y permisos delegados
verificar que controladores de dominio y sistemas administrativos registran realmente los eventos en los que piensa basarse
tratar WEF/WEC como infraestructura de transporte y retención, no como prueba de que el diseño de auditoría está completo

Para la capa de visibilidad por eventos, use Supervisión de seguridad AD: los event IDs que realmente importan y Auditoría recurrente de Active Directory: por qué las auditorías anuales derivan y cómo volver a medir en continuo.

Matriz de prioridades de endurecimiento de Active Directory

Área de control	Por qué viene pronto	Qué validar antes de imponerlo	Qué conservar como prueba después del despliegue
Cuentas privilegiadas y hosts administrativos	La compromisión de una ruta privilegiada suele derrumbar primero el resto del modelo de directorio	Hosts administrativos dedicados, identidades admin separadas, rutas de autenticación permitidas, impacto de Protected Users y authentication silos	Inventario de hosts administrativos, alcance de cuentas privilegiadas, asignaciones de políticas, validación de rutas de inicio de sesión
LDAP signing y SMB signing	Los protocolos débiles permiten relay, manipulación y workflows administrativos inseguros	Apps legacy, appliances, scripts, servidores de archivos no Microsoft, dependencias TLS y LDAP	Estado efectivo de políticas, registro de excepciones, resultados de pruebas de compatibilidad
Secretos de admin local, DSRM y cuentas de servicio	Los secretos reutilizables aceleran movimiento lateral y persistencia	Cobertura de Windows LAPS, gestión de DSRM, soporte de gMSA, ownership de cuentas de servicio, dependencias de rotación de contraseñas	Evidencia de rotación, informes de cobertura LAPS, revisión de ACL de recuperación, registros de migración de servicios
Permisos delegados, control de GPO y acceso relacionado con replicación	El abuso del plano de control suele eludir la visión centrada en grupos admin nominales	Permisos de GPO, delegación de OU, derechos con capacidad de replicación, gobernanza de grupos privilegiados, presencia de AD CS si está desplegado	Revisión de permisos antes y después, diff de GPO, inventario de admins delegados, evidencia de aprobación
Política de auditoría y workflow de validación	Sin visibilidad, el endurecimiento no puede volver a medirse ni defenderse en el tiempo	Cobertura de auditoría, diseño de SACL, enrutamiento WEF/WEC, retención, ownership de alertas	Muestras de eventos antes y después del cambio, salud del colector, evidencia retenida para reruns

Si AD CS está presente, incluya exposición de certificate templates, configuración de la CA y enrollment endpoints en esta misma matriz como una fila condicional en lugar de tratarlos como un proyecto futuro separado.

Validación después de los cambios de endurecimiento

Un programa de endurecimiento solo está terminado cuando los controles siguen funcionando en condiciones de producción. Las evidencias útiles de validación incluyen:

Prueba de que la administración privilegiada ya solo se origina desde hosts aprobados o jump paths definidos.
Prueba de que los clientes LDAP siguen funcionando con la postura objetivo de LDAP signing y channel binding.
Prueba de que los workflows administrativos y de archivos SMB siguen funcionando con los requisitos de firma previstos.
Prueba de que Windows LAPS rota los secretos de admin local y DSRM y de que los derechos de recuperación están estrictamente limitados.
Prueba de que las migraciones de cuentas de servicio a gMSA o a una gestión más estricta no dejaron SPN rotos ni excepciones sin gestionar.
Prueba de que los permisos delegados, los derechos relacionados con replicación y las rutas de control de GPO se revisaron antes y después del cambio.
Prueba de que la política de auditoría y la cadena de recopilación capturan realmente los controles en los que piensa apoyarse.

También por eso este pillar se sitúa al lado, y no encima, del pillar de auditoría. La pregunta de hardening es «¿qué bloqueamos primero?». La pregunta de auditoría es «¿qué revisamos de forma recurrente y cómo demostramos deriva o remediación a lo largo del tiempo?». Ambas importan, pero no son el mismo workflow.

Cómo ayuda EtcSec a revisiones repetibles de endurecimiento AD

EtcSec encaja aquí como una capa de medición repetible, no como un atajo que sustituya el trabajo de endurecimiento. Un colector local de solo lectura puede ayudar a volver a medir la dispersión de cuentas privilegiadas, los permisos con capacidad de replicación, la exposición a LDAP signing, la exposición a SMB signing y la cobertura de Windows LAPS después de cada ola de cambios. Esto resulta útil cuando necesita verificar que una decisión de endurecimiento redujo realmente la exposición, en lugar de haber cambiado solo un ajuste de política sobre el papel.

Endurecimiento Active Directory: qué bloquear primero y cómo validarlo