Cómo leer un entorno de Active Directory

Piensa en Active Directory como el directorio de identidades de una organización, no como una lista de contraseñas. Registra usuarios, equipos, grupos y relaciones que muchos servicios utilizan al decidir el acceso. Una revisión de seguridad útil comienza por entender esa estructura.

La enumeración identifica objetos y relaciones dentro de un alcance definido. Aquí buscamos un inventario que se pueda justificar: qué existe, quién lo gestiona, de qué depende y qué preguntas siguen abiertas.

Conoce los objetos antes de dibujar flechas

Una cuenta de usuario representa una identidad. Una cuenta de equipo también tiene identidad; no es solo un nombre de host. Los grupos de seguridad reúnen identidades para asignar acceso de forma coherente. Pueden contener otros grupos, por lo que importa la pertenencia indirecta.

Una unidad organizativa, u OU, organiza objetos, permite delegar administración y delimita directivas de grupo. Mover una cuenta a una OU no la añade por sí mismo a un grupo ni le concede acceso a una carpeta. Mantén separadas las relaciones “ubicado en”, “miembro de” y “autorizado a modificar”.

Leer requiere su propio permiso

LDAP es uno de los protocolos de acceso al directorio. Una consulta autenticada correcta no implica acceso ilimitado. Los permisos de los objetos y la protección de atributos influyen en lo que la identidad puede leer o cambiar.

Parte de la información es legible de forma prevista por usuarios autenticados porque las aplicaciones la necesitan. Otra parte está más restringida. Del mismo modo, pueden existir metadatos básicos rootDSE accesibles anónimamente sin exponer todos los usuarios. Evalúa los datos reales y la política prevista, en lugar de considerar vulnerable cualquier respuesta.

La protección del transporte es otra cuestión. Proteger la confidencialidad o integridad de una conexión no determina a qué objetos puede acceder la cuenta.

Un mapa necesita más de una fuente

Una exportación del directorio puede mostrar pertenencias a grupos, pero omitir grupos locales de un servidor, roles de aplicaciones, sesiones activas o permisos de la nube. Un organigrama no es un modelo completo del control de acceso.

Supón que un grupo ficticio se llama Editores de Finanzas. El nombre sugiere un propósito; no demuestra qué archivos puede editar. Necesitas los permisos de los recursos y un responsable. Si falta el propietario en la exportación, registra “propietario no indicado en esta fuente”, no “nadie es responsable”.

La recogida también puede ser incompleta porque cubrió un solo dominio o contenedor, omitió atributos, encontró restricciones o utilizó datos antiguos. La información replicada puede diferir brevemente entre controladores de dominio. Registra la fuente y la fecha.

Convierte observaciones en pruebas

Para cada relación importante, registra cuatro elementos: la identidad estable del objeto, la relación observada, la cuenta y fuente utilizadas y el momento de recogida. Es preferible un inventario limitado que responda a una pregunta aprobada a copiar datos personales innecesarios.

Separa una observación de una inferencia. “La cuenta pertenece a este grupo” puede estar respaldado por una exportación. “Puede modificar el servicio de nóminas” es otra conclusión que necesita pruebas de los controles de acceso del servicio.

Haz que el inventario se pueda mantener

Un mapa útil identifica responsables, acceso previsto, excepciones y fechas de revisión. Ayuda a retirar cuentas antiguas, explicar grupos anidados y reducir privilegios innecesarios sin interrumpir trabajo legítimo.

La siguiente lección utiliza este mapa para razonar sobre rutas de acceso. Su primera regla deriva de esta: una flecha solo es tan fiable como las pruebas y condiciones que la respaldan.