Auditar Active Directory en entorno air-gapped

Como auditar Active Directory en un entorno air-gapped sin falsa confianza

Si necesita saber como auditar Active Directory en un entorno air-gapped, empiece por una pregunta de alcance, no por una pregunta de herramienta. Muchas organizaciones dicen « air-gapped » cuando en realidad quieren decir « sin acceso directo a Internet », « aislado logicamente » o « fuertemente segmentado ». Esa distincion importa porque el metodo de auditoria, la cadena de evidencia y los controles aceptables cambian segun el modelo real de conectividad.

La guia de implementacion de CISA para la directiva BOD 23-01 deja claro ese limite: muchos entornos descritos como air-gapped en realidad solo estan aislados logicamente, y cualquier sistema conectado directamente al entorno operativo, o conectado a otro sistema que a su vez este conectado a ese entorno, no se trata como fisicamente air-gapped en esa guia. Para una auditoria de Active Directory, esta es una regla operativa util: no asuma aislamiento solo porque una red no tenga navegacion web directa.

Este articulo usa terminos practicos de auditoria en lugar de afirmar una taxonomia universal de proveedor:

Modelo de aislamiento	Significado practico para una auditoria de AD	Consecuencia para la auditoria
Sin Internet	El entorno no tiene acceso saliente directo a Internet, pero sigue existiendo enrutamiento interno local.	Una auditoria local es sencilla, pero los flujos gestionados desde la nube pueden no ser viables.
Aislado logicamente	El acceso esta restringido mediante gateways, jump hosts, brokers o rutas de transferencia controladas.	El alcance y la transferencia de evidencias importan tanto como la auditoria misma.
Segmentado	El entorno es enrutable, pero esta limitado por firewalls, VLAN o ACL.	Debe tratarse como conectado en lo relativo a riesgos de privilegios y protocolos.
Fisicamente air-gapped	No existe ningun camino de red hacia Internet ni hacia el entorno operativo mas amplio.	La recopilacion, la revision y la exportacion deben funcionar completamente en local.

El punto no es semantico. El punto es evitar una falsa sensacion de seguridad. Un bosque de Active Directory aislado puede seguir teniendo deriva de privilegios, delegacion insegura, configuraciones de protocolo debiles, cuentas privilegiadas obsoletas, rutas GPO escribibles, plantillas de certificados expuestas o una politica de auditoria debil. Si el directorio cambia, sigue necesitando medirse.

Por que el aislamiento no elimina el riesgo de AD

El aislamiento reduce algunas rutas de ataque externas, pero no elimina el riesgo de identidad dentro del perimetro que aun debe defender. Active Directory sigue conteniendo grupos privilegiados, configuraciones Kerberos, relaciones de confianza, delegacion, ACL, Group Policy y, con frecuencia, servicios de certificados. Esos planos de control siguen siendo criticos para la seguridad aunque el entorno no toque nunca un servicio SaaS publico.

Por eso un entorno aislado sigue necesitando la misma disciplina basica de revision descrita en Cómo auditar la seguridad de Active Directory: checklist práctica. Los grupos privilegiados siguen acumulando excepciones, las cuentas de servicio antiguas sobreviven a las migraciones y los permisos del directorio siguen derivando entre una limpieza y la siguiente. Si ya ejecuta revisiones periodicas, la misma leccion explicada en Auditoría recurrente de Active Directory: por qué las auditorías anuales se quedan obsoletas y cómo monitorizar la postura de forma continua aplica aun con mas fuerza en redes aisladas: una limpieza puntual no se mantiene correcta por si sola.

La guia ANSSI de 2023 para la administracion segura de sistemas que dependen de Active Directory es util aqui porque no trata AD como un directorio estatico. Lo trata como un plano de administracion que debe compartimentarse, monitorizarse y gobernarse con disciplina. En la practica, eso significa que un AD air-gapped o aislado debe evaluarse igualmente como un plano de control vivo, no como una isla heredada que seria mas segura solo porque es mas dificil de alcanzar desde Internet.

Que puede auditar sin acceso a Internet

Una revision offline bien delimitada puede cubrir la mayor parte de la superficie de control que realmente importa en un entorno AD:

Estructura de identidad y privilegios: grupos privilegiados, grupos anidados, derechos delegados, principals con capacidad de DCSync, administradores obsoletos, cuentas de servicio y anomalias de propiedad.
Configuracion de seguridad del directorio: LDAP signing, channel binding, exposicion NTLM, SMB signing, SMBv1, cached logons, politica Kerberos, despliegue de LAPS y configuracion de trusts.
Integridad de Group Policy y SYSVOL: enlaces de GPO, security filtering, herencia de permisos, exposicion de contraseñas en SYSVOL y hardened UNC paths.
Visibilidad de cambios: comprobar si la politica de auditoria, el diseño de recoleccion de eventos y el modelo de retencion bastan realmente para detectar cambios criticos de AD dentro del entorno aislado.
AD CS, si existe: exposicion del rol de CA, riesgo de certificate templates, superficies de enrollment y problemas de strong certificate binding.

Por eso la auditoria offline de Active Directory no solo es posible; a menudo es mas solida de lo que los equipos esperan. Microsoft documenta que los datos de AD son accesibles a traves de los protocolos de directorio y que Group Policy se divide entre metadatos en el directorio y contenido basado en archivos dentro de SYSVOL. Eso significa que una auditoria offline seria no se limita a capturas de pantalla o entrevistas puntuales con administradores. Puede recopilar evidencia directamente del directorio y de sus recursos compartidos de archivos asociados.

Fuentes de datos que conviene recopilar localmente

La auditoria offline mas fiable usa varias fuentes de datos locales porque ninguna fuente unica responde a todas las preguntas.

Fuente de datos	Que le aporta	Por que importa offline
LDAP o LDAPS	Usuarios, grupos, equipos, atributos relevantes para ACL, configuraciones de delegacion, trusts, politica de contraseñas y Kerberos, metadatos de certificate templates	El inventario principal y el analisis de malas configuraciones salen del propio directorio.
SYSVOL por SMB	Archivos GPO, scripts, configuraciones de policy, artefactos de preferences, pistas sobre coherencia de replicacion	La seguridad de GPO no puede revisarse correctamente solo desde LDAP.
Logs de eventos de seguridad	Cambios en el directorio, cambios en la politica de auditoria, accesos a objetos, inicios de sesion privilegiados, cambios de pertenencia a grupos	Necesita evidencia local para la deriva y para validar la remediacion.
Topologia WEF/WEC, si se usa	Confirmacion de que los eventos se centralizan realmente dentro del perimetro aislado	El diseño de la recoleccion local importa cuando no existe camino hacia un SIEM cloud.
Logs de CA y certificados, si existe AD CS	Enrollment, actividad de templates, eventos de emision y exposicion del rol	El abuso de certificados sigue siendo relevante en entornos Windows aislados.
Metadatos del snapshot	Fecha de auditoria, alcance de los DC, dominios excluidos, hosts inalcanzables, permisos utilizados	Sin esto, los reruns son dificiles de comparar y los hallazgos son dificiles de defender.

Hay dos detalles que suelen pasarse por alto.

Primero, la documentacion de Microsoft sobre Group Policy es importante porque cada GPO tiene tanto datos en el directorio como un componente de sistema de archivos en SYSVOL. Si solo consulta LDAP, pierde parte de la superficie de policy. Esa es una de las razones por las que las auditorias offline suelen infravalorar el riesgo asociado a scripts, archivos de preferences o integridad de rutas de policy.

Segundo, use LDAPS en lugar de asumir que el LDAP en claro es aceptable por tratarse de un entorno interno. La documentacion actual del collector de EtcSec es explicita en este punto para el modo standalone: ldaps:// es la via soportada y recomendada para la recoleccion de AD, mientras que LDAP sin cifrar no es la base soportada para produccion.

Como construir un workflow de auditoria offline seguro

Un workflow offline defendible depende sobre todo de la repetibilidad.

1. Definir exactamente el limite de confianza

Documente si el entorno es fisicamente air-gapped, logicamente aislado o simplemente desconectado del Internet publico. Si la exportacion de datos es posible mediante un jump host, un broker o un proceso manual de transferencia, dejelo por escrito. El informe de auditoria debe explicar el modelo de conectividad porque las hipotesis de la revision dependen de ello.

2. Recopilar desde un host local de confianza

Ejecute el motor de auditoria desde un host dentro del mismo limite de confianza que el directorio que esta revisando. Evite portatiles administrativos improvisados. Use un host de revision dedicado cuando sea posible y mantenga bajo control de cambios la configuracion del collector y sus salidas.

3. Recopilar conjuntamente evidencia del directorio y de SYSVOL

No separe la revision de identidad de la revision de GPO. En un AD aislado, parte de la deriva mas peligrosa a nivel operativo vive en la relacion entre objetos del directorio y contenido de policy respaldado por archivos. Por eso articulos como Ataques NTLM relay en Active Directory y SMB signing disabled: why it still enables NTLM relay siguen siendo relevantes en entornos « offline »: la exposicion subyacente de protocolos y rutas de archivos es local, no dependiente de Internet.

4. Conservar un snapshot comparable

Guarde la fecha de la auditoria, el conjunto de domain controllers alcanzados, si se incluyeron todos los dominios esperados y si AD CS o los trusts estaban dentro del alcance. Un informe sin contexto de recoleccion es dificil de comparar despues. Si quiere que las remediaciones se mantengan, necesita una baseline limpia antes/despues y no un PDF exportado una sola vez sin metadatos de recogida.

5. Volver a medir despues de la limpieza

Una vez corregidos los hallazgos, vuelva a ejecutar exactamente el mismo alcance y compare las mismas clases de evidencia. Esa es la unica manera fiable de demostrar que la deriva de privilegios, el hardening de protocolos o la limpieza de policy se mantuvieron realmente despues de la ventana de cambio.

Registro de eventos y deteccion en AD aislado

Offline no significa invisible. Significa que la visibilidad debe diseñarse localmente.

La documentacion de Microsoft sobre Windows Event Forwarding es util aqui porque explica lo que WEF hace realmente y lo que no hace. WEF puede reenviar eventos desde los origenes a un collector, pero es pasivo respecto a la generacion de eventos. No activa por usted las subcategorias correctas de auditoria y no redimensiona los logs por usted. Si los domain controllers no registran los eventos adecuados, un Windows Event Collector local solo centralizara evidencia incompleta con mayor rapidez.

Por eso la configuracion de advanced audit policy debe formar parte de la propia revision. Microsoft tambien recomienda planificar y validar en piloto antes de un despliegue amplio, porque las preguntas reales son el volumen de eventos, su utilidad operativa y si los equipos pueden entender los eventos que estan recopilando.

Para una revision de AD aislado, empiece con una baseline local de deteccion acotada:

Objetivo	Evidencia local que conviene verificar
Integridad de la politica de auditoria	Cambios de politica de auditoria como el Event ID 4719 y prueba de que las subcategorias criticas estan habilitadas en los DC
Visibilidad de cambios en directorio	Cobertura de Directory Service Changes, incluido el Event ID 5136 cuando corresponda
Acceso a objetos sensibles	Auditoria de acceso a objetos como el Event ID 4662 cuando se haya configurado intencionadamente sobre objetos de alto valor
Seguimiento de cambios privilegiados	Cambios en pertenencia a grupos, uso de cuentas admin y patrones de logon privilegiado
Centralizacion dentro del limite aislado	Suscripciones WEF/WEC, salud del collector local, retencion y procedimiento de exportacion

No son detecciones de un unico evento. Son clases de evidencia que debe correlacionar con su inventario y con la baseline esperada. Si su policy indica que nadie deberia obtener derechos equivalentes a DCSync y que ningun grupo privilegiado deberia cambiar fuera de una ventana controlada, sus logs deben poder sostener esa afirmacion localmente.

Si necesita un mapa mas detallado evento por evento, Monitorización de seguridad de AD: Event IDs que importan profundiza mucho mas en la parte de logging de seguridad de Windows.

Hallazgos que conviene priorizar en un AD air-gapped

Un entorno aislado no deberia cambiar demasiado el orden de sus prioridades. Lo que deberia cambiar es el metodo de recopilacion.

Deriva de privilegios y caminos administrativos obsoletos

Empiece por las mismas preguntas planteadas en Deriva del acceso privilegiado en Active Directory: cómo vuelven los derechos de administrador tras las auditorías y Cuentas obsoletas y sobreprivilegiadas en AD: quien tiene privilegios efectivos hoy, como obtuvo ese acceso y si seguiria estando aprobado si se revisara ahora mismo.

Eso incluye:

membresia directa y anidada en grupos privilegiados
cuentas con capacidad de DCSync
derechos delegados que conceden GenericAll, WriteDACL, WriteOwner o rutas equivalentes de escalada
deriva relacionada con AdminSDHolder
cuentas deshabilitadas o inactivas que siguen conservando membresia en grupos privilegiados

Hardening de protocolos y superficie de relay

Despues, priorice las configuraciones de protocolo que siguen siendo peligrosas incluso dentro de redes aisladas:

LDAP signing y channel binding
SMB signing
exposicion a SMBv1
configuracion NTLM y fallback innecesario
weak certificate mapping o emision insegura de certificados si existe AD CS

Los entornos offline suelen conservar configuraciones legacy durante mas tiempo porque las ventanas de cambio son mas dificiles y las pruebas de interoperabilidad son mas lentas. Eso no hace que la exposicion sea menos real.

Higiene de contraseñas de administradores locales

Las contraseñas compartidas de administrador local siguen siendo un problema de movimiento lateral en entornos Windows aislados. Windows LAPS no implementado: por qué siguen importando las contraseñas compartidas de administrador local sigue siendo relevante aqui porque el riesgo es la reutilizacion local de credenciales entre sistemas, no la conectividad a Internet.

Kerberos, cuentas de servicio y delegacion

Las cuentas de servicio, los SPN antiguos, la delegacion restringida o no restringida y una postura de cifrado debil siguen siendo comprobaciones prioritarias en un AD aislado. Si el entorno contiene servidores legacy de negocio, la probabilidad de encontrar patrones antiguos de cuentas de servicio suele ser mas alta, no mas baja.

Remediacion y validacion sin dependencia cloud

En un AD air-gapped, la remediacion debe ejecutarse igual que cualquier otro cambio de identidad Windows de alto riesgo: corregir la condicion peligrosa, volver a recopilar la misma evidencia y demostrar el resultado dentro del mismo limite de confianza.

⚠️ Advertencia: no trate los informes exportables como prueba por si mismos. Un informe solo es defendible si el alcance de recopilacion, los permisos usados y el metodo de rerun son lo bastante estables como para compararse a lo largo del tiempo.

Una secuencia practica es la siguiente:

Elimine o reduzca primero las rutas de privilegio de mayor riesgo: cuentas privilegiadas obsoletas, ACL inseguras, derechos DCSync innecesarios, delegacion insegura y configuraciones de protocolo debiles.
Revise de nuevo la integridad de GPO y SYSVOL despues de cada cambio de protocolo o policy, especialmente si ha tocado SMB, hardened UNC paths o administrative templates.
Valide que la politica de auditoria local sigue cubriendo los cambios que le interesan y que su diseño WEF/WEC sigue capturandolos cuando corresponda.
Vuelva a ejecutar exactamente el mismo alcance de auditoria y compare los hallazgos antes/despues en lugar de confiar en comprobaciones manuales puntuales.
Documente lo que sigue aceptado intencionadamente por restricciones operativas, especialmente en entornos legacy aislados donde el trabajo de compatibilidad tarda mas.

Ese ultimo punto importa. En entornos aislados, las excepciones suelen justificarse como temporales. Si no se documentan con un owner y una fecha de revision, acaban convirtiendose en arquitectura permanente.

Como EtcSec da soporte a auditorias AD air-gapped

Para este caso de uso, el limite de producto importante es sencillo: el modo standalone del collector de EtcSec no requiere dependencia SaaS. La documentacion local describe un modo servidor standalone en el que el collector se ejecuta dentro de su entorno y se comunica localmente con Active Directory, incluido LDAP o LDAPS para los datos del directorio y acceso SMB a SYSVOL para revisar Group Policy.

Eso importa en entornos aislados porque la auditoria puede mantenerse dentro del mismo limite de confianza que el directorio evaluado. Para una evaluacion solo de AD, puede mantener el alcance local sin asumir acceso saliente a servicios cloud.

Cuando el entorno esta listo para una medicion de postura, los checks de EtcSec mas utiles en este contexto son los que prueban la salud de los controles locales, no una exposicion generica a Internet. Algunos ejemplos son LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, DCSYNC_CAPABLE, ACL_GENERICALL, KERBEROASTING_RISK y ADMIN_SD_HOLDER_MODIFIED.

La idea clave no es que un AD air-gapped necesite un estandar de revision distinto. La idea clave es que el flujo de recopilacion y validacion debe poder ejecutarse localmente, volver a ejecutarse localmente y compararse localmente.

Controles relacionados

rutas de administracion dedicadas e higiene de estaciones de trabajo privilegiadas
enforcement de LDAP signing, channel binding y SMB signing
despliegue de Windows LAPS y rotacion de contraseñas de administradores locales
revision de accesos privilegiados y eliminacion de rutas administrativas obsoletas
diseño WEF/WEC junto con advanced audit policy validada en DC
revision de integridad de GPO y SYSVOL
revision de AD CS cuando existan servicios de certificados
nueva medicion recurrente en lugar de limpieza puntual

Cómo auditar Active Directory en un entorno air-gapped