Attributs confidentiels AD : vérifier l'accès en lecture

Que sont les attributs confidentiels AD ?

Les attributs confidentiels AD sont des attributs de l'annuaire soumis à un contrôle supplémentaire de l'accès en lecture. Commencez par identifier les attributs personnalisés qui contiennent réellement des données métier sensibles, puis vérifiez qui peut les lire. Un simple rappel de classification ne démontre ni une exposition des données, ni l'absence de protection d'un attribut, ni le non-respect d'une exigence de conformité par l'organisation.

Ce guide prend un exemple précis : un attribut personnalisé approuvé pour un usage métier particulier, avec un propriétaire désigné et une liste documentée de lecteurs. Il décrit une procédure de vérification en laboratoire à l'aide de valeurs fictives. Aucun test Active Directory n'a été exécuté pour cet article, et aucun des résultats attendus ci-dessous n'est présenté comme un résultat observé.

Le livrable utile est un dossier de décision sur l'accès en lecture : classification de l'attribut, admissibilité au niveau du schéma, lecteurs effectifs, comportement attendu des applications et tout écart mesuré par rapport à cette attente. Complétez ce dossier avant de proposer une modification du schéma.

Fonctionnement du contrôle de lecture confidentielle

La définition de searchFlags dans MS-ADTS identifie fCONFIDENTIAL comme le bit 0x80 (128). Il impose un contrôle d'accès étendu. Les autres indicateurs ont des significations distinctes : il est donc essentiel de consigner la valeur existante complète.

Pour un attribut portant cet indicateur, MS-ADTS Extended Access Checks exige à la fois READ_PROPERTY et CONTROL_ACCESS. Sans les droits requis, la valeur est traitée comme absente dans les attributs retournés et dans le filtre LDAP. Une valeur absente ne suffit donc pas à distinguer une restriction d'accès d'un attribut vide.

Les recommandations Microsoft sur les attributs confidentiels excluent les attributs du schéma de base, identifiés par FLAG_SCHEMA_BASE_OBJECT (0x10) dans systemFlags. Leur exemple distingue employeeID, un attribut de base, d'un attribut admissible. Une signification métier sensible ne permet pas de passer outre cette restriction du schéma.

Ces mêmes recommandations expliquent que Full Control inclut CONTROL_ACCESS et que les autorisations génériques peuvent être plus larges que les ACE propres à un attribut. Les autorisations explicites comme les autorisations héritées comptent. Traitez la capture d'écran d'une entrée d'autorisation comme un élément de l'examen, plutôt que comme une réponse complète sur l'accès effectif.

Détection : constituer un inventaire approuvé des attributs

Étape 1 — Valider la classification et le propriétaire

Demandez au propriétaire des données quels attributs personnalisés contiennent des informations dont la lecture doit être restreinte. Consignez la classification et la finalité approuvées sans copier de valeurs de production dans le dossier d'examen. Un nom de champ comme « private » ou « confidential » ne constitue pas une classification approuvée.

Pour chaque candidat, consignez son nom d'affichage LDAP, le DN de son objet de schéma, les classes d'objets où il est utilisé, son propriétaire métier, ses lecteurs légitimes et les applications qui le consomment. Identifiez aussi qui peut autoriser une modification. Si la propriété ou la classification reste indéterminée, laissez l'attente d'accès indéterminée et transmettez cette question à l'équipe responsable.

Une petite fiche d'examen est plus utile qu'une liste exhaustive de tous les attributs :

Limitez l'inventaire aux attributs personnalisés réellement sensibles. Si l'enquête découvre des identifiants dans des notes ordinaires, suivez la procédure distincte de suppression de l'exposition des mots de passe et de rotation. Modifier un indicateur de confidentialité ne remplace pas le traitement de cette exposition.

Étape 2 — Lire le schéma avant d'envisager une modification

Utilisez un contrôleur de domaine de laboratoire désigné et un candidat connu issu de l'inventaire approuvé. Ces exemples nécessitent le module PowerShell ActiveDirectory. Remplacez le serveur et l'attribut d'exemple par leurs équivalents de laboratoire ; ne les exécutez pas en production dans le cadre de cette procédure.

La documentation de Get-ADRootDSE expose schemaNamingContext. Get-ADObject prend en charge les filtres LDAP, une base de recherche, un serveur explicite et des propriétés supplémentaires. Voici une combinaison illustrative en lecture seule de ces paramètres documentés :

$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

Consignez le DN de l'objet retourné et les valeurs complètes des indicateurs. Si la requête échoue ou n'identifie pas l'attribut prévu, arrêtez l'évaluation de ce candidat. Ne transformez pas une recherche infructueuse en conclusion « non confidentiel » ou « admissible ».

Vérifiez si le bit de confidentialité est déjà présent et si le bit du schéma de base exclut l'usage proposé. Conservez les valeurs existantes des indicateurs dans les preuves, y compris les bits sans rapport avec cet usage. À ce stade, le résultat est une évaluation d'admissibilité, et non une demande de définir à 128 chaque champ qui semble sensible.

Étape 3 — Expliquer l'accès effectif en lecture

Pour chaque lecteur approuvé et chaque identité représentative extérieure à l'ensemble des lecteurs approuvés, inspectez le descripteur de sécurité de l'objet cible et l'héritage pertinent des conteneurs parents. Incluez le contexte de groupe, les refus applicables, la portée de l'attribut ou de l'ensemble de propriétés, les ACE génériques et tout héritage désactivé. Consignez la raison de l'attente d'accès.

Vérifiez séparément READ_PROPERTY et, lorsque la confidentialité s'applique, CONTROL_ACCESS. La capacité d'un lecteur à parcourir l'objet ne détermine pas sa capacité à obtenir la valeur du candidat. De même, un rôle applicatif décrit comme limité peut recevoir un accès étendu via un autre groupe ou une entrée héritée.

Examinez particulièrement Full Control et les autorisations génériques de contrôle d'accès. La question pratique est de savoir si ces autorisations donnent déjà à une identité le droit supplémentaire, et non si une ACE contient le nom de l'attribut. Documentez l'origine de l'autorisation pour qu'un futur examinateur puisse reproduire le raisonnement.

Cet examen porte sur le contrat de lecture d'un attribut personnalisé. Pour l'enquête distincte sur les autorisations d'écriture du schéma et defaultSecurityDescriptor, utilisez l'audit des autorisations du schéma et du descripteur de sécurité par défaut.

Vérification en laboratoire : comparer deux identités de lecteurs

Étape 4 — Établir une valeur fictive connue

Préparez un objet de test isolé avec une valeur clairement artificielle dans l'attribut candidat approuvé. Demandez à l'opérateur du laboratoire de confirmer que la valeur existe, consignez son marqueur dans le dossier de test et documentez la préparation. N'utilisez pas de vraies données du personnel, de secrets opérationnels ou d'export d'un annuaire de production.

Sélectionnez une identité dont le propriétaire a approuvé la lecture de la valeur et une identité représentative qui ne doit pas la lire. Documentez leur contexte de groupe. Aucune de ces identités ne doit être remplacée silencieusement par le compte administrateur utilisé pour inspecter le schéma.

Utilisez le même point de terminaison, le même objet et le même attribut demandé pour les deux lectures. Le paramètre d'identification documenté de Get-ADObject accepte un nom de compte et demande son mot de passe. Ces commandes sont proposées pour le laboratoire ; il ne s'agit pas d'exécutions consignées :

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'

Inspectez la propriété demandée dans chaque objet retourné. Consignez si elle contient le marqueur fictif connu, si elle est absente ou vide, ou si la commande produit une erreur. Distinguez les échecs d'authentification, les erreurs de connectivité et l'absence de données de test d'une restriction d'accès.

Étape 5 — Consigner la différence sans inventer une réussite

Le tableau suivant définit les attentes à évaluer ; il ne contient aucun résultat mesuré :

Si les deux identités lisent le marqueur, examinez les autorisations effectives et l'état actuel des indicateurs. Si aucune ne le lit, vérifiez d'abord le dispositif de test, le point de terminaison, les identifiants et la propriété demandée. Si le lecteur approuvé réussit et le lecteur extérieur échoue, conservez les preuves et leur portée : cette comparaison couvre ces identités et cette configuration.

Ne généralisez pas une comparaison unique en preuve que tous les utilisateurs ou toutes les applications sont correctement restreints. Ajoutez des groupes de lecteurs représentatifs et des limites d'héritage selon l'inventaire approuvé. Consignez la date, l'opérateur, le point de terminaison, les valeurs du schéma, la requête, le contexte de l'identité, le résultat et les questions non résolues pour chaque cas.

Pour les applications utilisant un chemin de requête différent, reproduisez ce chemin séparément avec des données fictives. La spécification searchFlags indique des différences de comportement liées aux contrôles DirSync. Consignez les contrôles et le comportement du client lorsqu'ils s'appliquent ; une lecture PowerShell seule ne valide pas le contrat de synchronisation d'une application.

Remédiation : décider avant de modifier le schéma (Remediation)

Étape 6 — Choisir l'action à partir des preuves

Si la classification ou la propriété manque, obtenez d'abord cette décision. Si l'accès actuel correspond déjà au contrat approuvé, conservez les preuves et le calendrier de réexamen. Si un écart d'accès en lecture est mesuré, proposez une correction précise en indiquant les identités et les applications concernées.

Une modification proposée du schéma nécessite une décision documentée distincte. Incluez l'admissibilité de l'attribut, les valeurs initiales des indicateurs, les lecteurs requis, la portée des autorisations, le responsable de la mise en œuvre, le plan de compatibilité des consommateurs, les critères de vérification et l'approche de retour arrière. Préservez les bits de searchFlags sans rapport avec la modification dans la configuration proposée. Évitez de traiter 128 comme une valeur de remplacement universelle.

Microsoft recommande de tester les modifications d'attributs dans un laboratoire reproduisant la forêt de production. Utilisez ces tests pour valider la combinaison exacte de configuration du schéma et d'autorisations proposée. Les recommandations historiques contiennent des instructions d'outillage propres à certaines versions ; vérifiez leur pertinence pour l'environnement cible avant la mise en œuvre.

Étape 7 — Valider la compatibilité et le retour arrière

Demandez au propriétaire de chaque application consommatrice quelle opération dépend de l'attribut et sous quelle identité. Validez la fonction approuvée avec des valeurs fictives, notamment la façon dont l'application gère une propriété illisible ou manquante. Une lecture autorisée de l'annuaire et un processus métier fonctionnel constituent deux contrôles d'acceptation distincts.

Définissez le retour arrière avant l'approbation du déploiement : consignez la valeur initiale de l'indicateur du schéma, les entrées d'autorisation exactes concernées, qui peut les rétablir et comment ce rétablissement sera vérifié. Restaurer une configuration antérieure peut rouvrir la lecture ; incluez donc cette conséquence dans la décision. Ne présentez pas le retour arrière comme effaçant des données déjà lues ou copiées.

L'examen ne se clôt que lorsque trois questions ont des réponses explicites : quelles données ont une classification et un propriétaire approuvés ; si l'attribut est admissible et quels droits effectifs donnent accès ; et quels consommateurs légitimes doivent rester compatibles après une éventuelle modification. Attribuez toute réponse non résolue à un responsable plutôt que de marquer l'évaluation comme terminée.

Comment EtcSec détecte ce point

DATA_CLASSIFICATION_MISSING est un rappel informatif d'examen dans etc-collector. Au commit du collecteur 0423094759d50002457031317098417993e19510, public/internal/audit/detectors/ad/compliance/industry/data-classification.go:23 définit une fonction Detect() qui ignore à la fois data et ctx et ne consomme aucun fournisseur.

Elle retourne toujours un seul constat de sévérité Info avec un Count: 1 fixe. Son titre, sa description, ses exemples de données sensibles et ses recommandations sont statiques. Ce compte ne représente pas un nombre d'attributs exposés, de classifications manquantes ou de tests de lecture échoués.

Ce détecteur ne mesure ni la classification des données, ni la configuration des attributs confidentiels, ni les droits effectifs, ni la compatibilité des consommateurs. Son constat ne fournit aucune preuve d'exposition ou de non-conformité. Utilisez-le pour lancer l'inventaire et le dossier de décision en laboratoire décrits ci-dessus, en conservant ces observations manuelles séparément de la sortie du détecteur.

Sources techniques et implémentation du collecteur examinées le 4 octobre 2026. La comparaison en laboratoire reste une procédure que le lecteur doit exécuter avec des données fictives approuvées.