Atributos confidenciales AD: verificar el acceso de lectura

¿Qué son los atributos confidenciales AD?

Los atributos confidenciales AD son atributos del directorio sujetos a una comprobación adicional del acceso de lectura. Empiece por identificar qué atributos personalizados contienen realmente datos empresariales sensibles y después verifique quién puede leerlos. Un recordatorio de clasificación por sí solo no demuestra que los datos estén expuestos, que un atributo carezca de protección o que la organización incumpla un requisito de conformidad.

Esta guía utiliza un ejemplo delimitado: un atributo personalizado aprobado para un fin empresarial concreto, con un responsable designado y una lista documentada de lectores. Describe un procedimiento de verificación en laboratorio con valores ficticios. No se ejecutó ninguna prueba de Active Directory para este artículo y ninguno de los resultados esperados que se presentan a continuación se ofrece como un resultado observado.

El entregable útil es un registro de decisiones sobre el acceso de lectura: la clasificación del atributo, su elegibilidad en el esquema, los lectores efectivos, el comportamiento esperado de las aplicaciones y cualquier diferencia medida respecto a esa expectativa. Complete ese registro antes de proponer un cambio en el esquema.

Cómo funciona la comprobación de lectura confidencial

La definición de searchFlags de MS-ADTS identifica fCONFIDENTIAL como el bit 0x80 (128). Exige una comprobación de acceso extendida. Los demás indicadores tienen significados distintos, por lo que es importante registrar el valor existente completo.

Para un atributo que lleve ese indicador, MS-ADTS Extended Access Checks exige tanto READ_PROPERTY como CONTROL_ACCESS. Sin los derechos necesarios, el valor se trata como ausente en los atributos devueltos y en el filtro LDAP. Por tanto, un valor ausente no basta para distinguir una restricción de acceso de un atributo vacío.

La guía de Microsoft sobre atributos confidenciales excluye los atributos del esquema base, identificados por FLAG_SCHEMA_BASE_OBJECT (0x10) en systemFlags. Su ejemplo distingue employeeID, un atributo base, de un atributo elegible. Un significado empresarial sensible no anula esa restricción del esquema.

La misma guía explica que Full Control incluye CONTROL_ACCESS y que las concesiones genéricas pueden ser más amplias que las ACE específicas de un atributo. Importan tanto las concesiones explícitas como las heredadas. Considere una captura de pantalla de una entrada de permisos como un elemento para la revisión, no como una respuesta completa sobre el acceso efectivo.

Detección: elaborar un inventario aprobado de atributos

Paso 1 — Acordar la clasificación y el responsable

Pregunte al responsable de los datos qué atributos personalizados contienen información cuya lectura debe restringirse. Registre la clasificación y la finalidad aprobadas sin copiar valores de producción en la revisión. Un nombre de campo como «private» o «confidential» no constituye una clasificación aprobada.

Para cada candidato, registre su nombre para mostrar de LDAP, el DN de su objeto de esquema, las clases de objetos en las que se utiliza, su responsable empresarial, sus lectores legítimos y las aplicaciones que lo consumen. Identifique también quién puede autorizar un cambio. Si la responsabilidad o la clasificación no está resuelta, deje sin resolver la expectativa de acceso y remita esa pregunta al equipo responsable.

Una pequeña hoja de revisión es más útil que una lista general de todos los atributos:

Limite el inventario a los atributos personalizados que sean realmente sensibles. Si la investigación descubre credenciales en notas ordinarias, siga el procedimiento separado de eliminación de la exposición de contraseñas y rotación. Cambiar un indicador de confidencialidad no sustituye el tratamiento de esa exposición.

Paso 2 — Leer el esquema antes de considerar un cambio

Utilice un controlador de dominio de laboratorio designado y un candidato conocido del inventario aprobado. Estos ejemplos requieren el módulo PowerShell ActiveDirectory. Sustituya el servidor y el atributo de ejemplo por sus equivalentes de laboratorio; no los ejecute en producción como parte de este procedimiento.

La documentación de Get-ADRootDSE expone schemaNamingContext. Get-ADObject admite filtros LDAP, una base de búsqueda, un servidor explícito y propiedades adicionales. Lo siguiente es una combinación ilustrativa de solo lectura de esos parámetros documentados:

$dc = 'dc01.lab.example'
$schema = (Get-ADRootDSE -Server $dc).schemaNamingContext
Get-ADObject -Server $dc -SearchBase $schema -LDAPFilter '(lDAPDisplayName=labSensitiveReference)' -Properties lDAPDisplayName,searchFlags,systemFlags,schemaIDGUID,attributeSecurityGUID

Registre el DN del objeto devuelto y los valores completos de los indicadores. Si la consulta falla o no identifica el atributo previsto, detenga la evaluación de ese candidato. No convierta una búsqueda infructuosa en «no confidencial» o «elegible».

Revise si el bit de confidencialidad ya está presente y si el bit del esquema base excluye el uso propuesto. Conserve los valores existentes de los indicadores en las evidencias, incluidos los bits no relacionados. En esta fase, el resultado es una evaluación de elegibilidad, no una petición de establecer en 128 todos los campos que parezcan sensibles.

Paso 3 — Explicar el acceso efectivo de lectura

Para cada lector aprobado y cada identidad representativa ajena al conjunto de lectores aprobados, inspeccione el descriptor de seguridad del objeto de destino y la herencia pertinente de los contenedores superiores. Incluya el contexto de grupo, las denegaciones aplicables, el ámbito del atributo o conjunto de propiedades, las ACE genéricas y cualquier herencia deshabilitada. Registre el motivo de la expectativa de acceso.

Compruebe por separado READ_PROPERTY y, cuando se aplique la confidencialidad, CONTROL_ACCESS. La capacidad de un lector para explorar el objeto no determina su capacidad para obtener el valor del candidato. Del mismo modo, un rol de aplicación descrito como limitado puede seguir recibiendo un acceso amplio a través de otro grupo o de una entrada heredada.

Preste especial atención a Full Control y a las concesiones genéricas de control de acceso. La cuestión práctica es si esas concesiones ya otorgan a una identidad el derecho adicional, no si una ACE contiene el nombre del atributo. Documente el origen de la concesión para que una futura revisión pueda reproducir el razonamiento.

Esta revisión trata del contrato para leer un atributo personalizado. Para investigar por separado los permisos de escritura del esquema y defaultSecurityDescriptor, utilice la auditoría de permisos del esquema y del descriptor de seguridad predeterminado.

Verificación en laboratorio: comparar dos identidades de lectores

Paso 4 — Establecer un valor ficticio conocido

Prepare un objeto de prueba aislado con un valor claramente artificial en el atributo candidato aprobado. Pida al operador del laboratorio que confirme que el valor existe, registre su marcador en el expediente de prueba y documente la preparación. No utilice datos reales del personal, secretos operativos ni una exportación de un directorio de producción.

Seleccione una identidad que el responsable haya aprobado para leer el valor y una identidad representativa que no deba leerlo. Documente su contexto de grupo. Ninguna de las dos identidades debe sustituirse silenciosamente por la cuenta de administrador utilizada para inspeccionar el esquema.

Utilice el mismo punto de conexión, objeto y atributo solicitado para ambas lecturas. El parámetro de credenciales documentado de Get-ADObject acepta un nombre de cuenta y solicita su contraseña. Estos son comandos propuestos para el laboratorio, no ejecuciones registradas:

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\ApprovedReader'

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\OutsideReader'

Inspeccione la propiedad solicitada en cada objeto devuelto. Registre si contiene el marcador ficticio conocido, si está ausente o vacía, o si el comando produce un error. Distinga los fallos de autenticación, los errores de conectividad y la falta de datos de prueba de una restricción de acceso.

Paso 5 — Registrar la diferencia sin inventar una prueba superada

La tabla siguiente especifica las expectativas que deben evaluarse; no contiene ningún resultado medido:

Si ambas identidades leen el marcador, investigue las concesiones efectivas y el estado actual de los indicadores. Si ninguna lo lee, verifique primero la preparación de la prueba, el punto de conexión, las credenciales y la propiedad solicitada. Si el lector aprobado tiene éxito y el lector externo no, conserve las evidencias y su alcance: esa comparación cubre esas identidades y esa configuración.

No generalice una sola comparación como prueba de que todos los usuarios o aplicaciones tienen restricciones correctas. Añada grupos de lectores representativos y límites de herencia según el inventario aprobado. Registre la fecha, el operador, el punto de conexión, los valores del esquema, la consulta, el contexto de la identidad, el resultado y las preguntas sin resolver para cada caso.

Para las aplicaciones que utilicen una ruta de consulta diferente, reproduzca esa ruta por separado con datos ficticios. La especificación de searchFlags señala diferencias de comportamiento relacionadas con los controles DirSync. Registre los controles y el comportamiento del cliente cuando corresponda; una lectura de PowerShell por sí sola no valida el contrato de sincronización de una aplicación.

Remediación: decidir antes de cambiar el esquema (Remediation)

Paso 6 — Seleccionar la acción a partir de las evidencias

Si falta la clasificación o la asignación de un responsable, obtenga primero esa decisión. Si el acceso actual ya coincide con el contrato aprobado, conserve las evidencias y el calendario de revisión. Si se mide una discrepancia en el acceso de lectura, proponga una corrección específica con las identidades y aplicaciones afectadas.

Una modificación propuesta del esquema necesita una decisión documentada por separado. Incluya la elegibilidad del atributo, los valores originales de los indicadores, los lectores necesarios, el ámbito de las concesiones, el responsable de implementación, el plan de compatibilidad de los consumidores, los criterios de verificación y el método de reversión. Preserve los bits de searchFlags no relacionados en la configuración propuesta. Evite tratar 128 como un valor de sustitución universal.

Microsoft recomienda probar los cambios de atributos en un laboratorio que reproduzca el bosque de producción. Utilice esas pruebas para validar la combinación exacta propuesta de configuración del esquema y permisos. La guía histórica contiene instrucciones de herramientas específicas de ciertas versiones; revise su idoneidad para el entorno de destino antes de implementarlas.

Paso 7 — Validar la compatibilidad y la reversión

Pregunte al responsable de cada aplicación consumidora qué operación depende del atributo y bajo qué identidad. Valide la función aprobada con valores ficticios, incluida la forma en que la aplicación gestiona una propiedad ilegible o ausente. Una lectura autorizada del directorio y un flujo de trabajo empresarial que funcione son comprobaciones de aceptación independientes.

Defina la reversión antes de aprobar el despliegue: registre el valor original del indicador del esquema, las entradas de permisos exactas implicadas, quién puede restaurarlas y cómo se verificaría la restauración. Restaurar una configuración anterior puede volver a permitir la lectura, así que incluya esa consecuencia en la decisión. No describa una reversión como si borrara datos leídos o copiados previamente.

La revisión solo se cierra cuando tres preguntas tienen respuestas explícitas: qué datos tienen una clasificación y un responsable aprobados; si el atributo es elegible y qué derechos efectivos dan acceso; y qué consumidores legítimos deben seguir siendo compatibles tras un posible cambio. Asigne cualquier respuesta sin resolver a un responsable en vez de marcar la evaluación como completa.

Cómo detecta esto EtcSec

DATA_CLASSIFICATION_MISSING es un recordatorio informativo de revisión en etc-collector. En el commit del colector 0423094759d50002457031317098417993e19510, public/internal/audit/detectors/ad/compliance/industry/data-classification.go:23 define un Detect() que ignora tanto data como ctx y no consume ningún proveedor.

Siempre devuelve un hallazgo con severidad Info y un Count: 1 fijo. Su título, descripción, ejemplos de datos sensibles y recomendaciones son estáticos. El recuento no es un número de atributos expuestos, clasificaciones ausentes ni pruebas de lectura fallidas.

Este detector no mide la clasificación de datos, la configuración de atributos confidenciales, los derechos efectivos ni la compatibilidad de los consumidores. Su hallazgo no aporta evidencias de exposición ni de incumplimiento. Utilícelo para iniciar el inventario y el registro de decisiones de laboratorio descritos anteriormente, y mantenga esas observaciones manuales separadas de la salida del detector.

Fuentes técnicas e implementación del colector revisadas el 4 de octubre de 2026. La comparación en laboratorio sigue siendo un procedimiento que el lector debe ejecutar con datos ficticios aprobados.