Auditer l’héritage des permissions et le droit effectif

L’héritage des permissions fait descendre un droit d’un conteneur vers tout ce qu’il contient : dossier NTFS (New Technology File System) derrière un partage SMB (Server Message Block), unité d’organisation Active Directory, site SharePoint, hiérarchie IAM (Identity and Access Management) d’un fournisseur cloud. Conséquence : la permission effective n’est écrite nulle part, elle se calcule. L’audit porte donc sur le droit effectif et sur les points où l’héritage est rompu ou court-circuité, pas sur la lecture des listes d’accès une à une.

→ Lire l’explication complète de la marmotte

Permission effective : un calcul, pas une ligne dans une liste d’accès

Une ACL (Access Control List) est la liste d’entrées attachée à un objet. Chaque entrée, ou ACE (Access Control Entry), autorise ou refuse des opérations à une identité. L’héritage ajoute une règle : une entrée posée sur un conteneur vaut aussi pour ses descendants. Le droit effectif d’une identité sur un objet dépend alors de quatre choses :

les entrées explicites de l’objet ;
les entrées de tous ses ancêtres ;
les appartenances transitives de l’identité (groupes dans des groupes, rôles endossables) ;
les règles de priorité entre refus et autorisation, propres à chaque plateforme.

Le compromis central est connu et rarement dit. L’héritage achète l’administrabilité (une décision en haut couvre cent mille objets) et se paie en localité : regarder l’objet ne dit plus qui y accède, regarder l’entrée ne dit plus où elle s’applique. Chaque rupture d’héritage rachète un peu de localité, et la facture arrive sous forme d’exceptions que personne ne maintient.

La position défendue ici tient en trois règles :

accorder haut, peu, et à des groupes plutôt qu’à des personnes ;
rompre rarement, et toujours avec un propriétaire nommé ;
quand une exception est durable et concerne un sous-arbre entier, créer un conteneur à part (autre bibliothèque, autre unité d’organisation, autre projet) plutôt que rompre l’héritage.

La question qui départage : l’exception est-elle structurelle ou ponctuelle ? Structurelle, elle mérite sa place dans la hiérarchie. Ponctuelle, elle mérite une date de fin, ce que l’accès juste-à-temps fait mieux qu’une entrée explicite oubliée.

Deux familles d’implémentation sont à distinguer :

Héritage statique (NTFS, Active Directory) : les entrées héritées sont recopiées dans le descripteur de sécurité de chaque enfant, marquées comme héritées, à la création ou lors d’une propagation. Un objet peut donc porter des entrées périmées, et une propagation interrompue laisse un arbre à moitié réécrit.
Héritage dynamique (IAM cloud) : rien n’est recopié, la hiérarchie est parcourue à chaque demande d’accès. Un changement en haut s’applique partout, erreurs comprises.

Le schéma suivant montre la descente d’un droit et les points où elle est coupée ou doublée par une autre voie. Ces points sont les seuls endroits où l’audit apprend quelque chose.

Ce modèle n’est pas le seul possible. Les pages ReBAC et Zanzibar et sécurité par capacités décrivent des approches où la relation ou le jeton porte le droit, ce qui déplace le problème du calcul sans le supprimer.

Héritage NTFS et partages SMB : indicateurs de propagation et ordre d’évaluation

Sur NTFS, la liste qui régit l’accès est la DACL (Discretionary Access Control List). Chaque ACE y est soit explicite, soit héritée. Quatre indicateurs décident de la propagation d’une entrée posée sur un dossier : héritage par les fichiers (object inherit), héritage par les sous-dossiers (container inherit), héritage seul sans effet sur le dossier lui-même (inherit only), et arrêt après un niveau (no propagate). Une entrée « ce dossier seulement » et une entrée « sous-dossiers et fichiers seulement » affichent le même groupe dans l’interface et n’ont rien en commun.

L’ordre canonique d’évaluation est le suivant : refus explicites, autorisations explicites, refus hérités, autorisations héritées. La conséquence contredit l’intuition « un refus gagne toujours » : une autorisation explicite sur l’objet l’emporte sur un refus hérité du parent. Un refus posé en haut de l’arborescence pour « verrouiller » un groupe ne verrouille rien là où quelqu’un a ajouté une autorisation directe.

Désactiver l’héritage protège la DACL contre les propagations venues du parent. Le système propose alors de convertir les entrées héritées en entrées explicites ou de les retirer. La conversion est le choix par défaut des gens pressés, et le piège : elle fige une copie. Un retrait effectué ensuite sur le parent n’atteint plus l’objet, qui garde l’ancien groupe indéfiniment.

Cinq autres voies amènent un droit là où personne ne l’a accordé :

La copie : un fichier copié prend les permissions héritées de la destination. Copier un document confidentiel dans un dossier ouvert le rend ouvert.
Le déplacement dans un même volume : le descripteur n’est pas réécrit. Les entrées explicites suivent le fichier, et les entrées marquées héritées peuvent rester celles de l’ancien parent tant qu’aucune propagation n’a été relancée.
L’identité spéciale « Creator Owner » (identifiant S-1-3-0) : cette entrée héritable est remplacée, à la création d’un objet, par l’identité du créateur. Le droit devient personnel et survit au changement de poste (voir la page auditer les comptes orphelins).
Le propriétaire : il peut par défaut réécrire la DACL, même si aucune entrée ne lui donne ce droit. Une entrée « Owner Rights » (identifiant S-1-3-4) permet de le restreindre.
Les groupes imbriqués : ce n’est pas de l’héritage au sens strict, mais l’appartenance transitive produit le même effet et se lit encore moins bien.

Partage SMB et NTFS se combinent, et le plus restrictif des deux s’applique. Un partage en « Contrôle total pour tout le monde » n’est donc pas une faute en soi : il délègue toute la décision à NTFS. La faute, c’est de ne plus savoir laquelle des deux couches décide. Le dossier « Commun » d’un serveur de fichiers l’est rarement par décision, presque toujours par sédimentation.

Héritage des ACL Active Directory : unités d’organisation, AdminSDHolder et SDProp

Dans Active Directory, chaque objet (utilisateur, groupe, ordinateur, unité d’organisation) porte un descripteur de sécurité, avec la même logique d’entrées explicites et héritées que NTFS. Une ACE posée sur une unité d’organisation descend sur les objets enfants, éventuellement filtrée par classe d’objet. C’est le mécanisme des délégations : « réinitialiser le mot de passe des utilisateurs de cette unité » est une entrée héritable limitée à la classe utilisateur. Déplacer un objet d’une unité à une autre change donc ses droits hérités, sans que personne ne touche à une permission.

L’exception majeure s’appelle AdminSDHolder. Le processus SDProp (Security Descriptor Propagator) tourne sur l’émulateur PDC (Primary Domain Controller), toutes les 60 minutes par défaut. Il réécrit la DACL des objets protégés (membres des groupes d’administration, entre autres) à partir de celle du conteneur AdminSDHolder, et y coupe l’héritage. Deux conséquences d’exploitation :

une délégation posée sur une unité d’organisation ne s’applique pas aux comptes protégés qu’elle contient, ce qui est voulu ;
un compte sorti d’un groupe protégé garde son attribut adminCount à 1 et son héritage coupé. Il échappe alors aux délégations et aux corrections posées plus haut, avec une DACL figée dans son état d’ancien administrateur.

L’héritage des GPO (Group Policy Objects) est un mécanisme distinct. L’ordre site, domaine, unité d’organisation, le blocage d’héritage et le lien « appliqué » règlent quels paramètres s’appliquent, pas qui a le droit de faire quoi sur un objet. Il est traité dans la page registre, GPO et services Windows.

Les droits qui permettent de réécrire une DACL ou de prendre possession d’un objet transforment une délégation héritée en chemin d’attaque. Ce sujet a ses propres pages : structure, délégations et chemins d’attaque et chemins d’attaque Active Directory.

Héritage SharePoint Online et OneDrive : permissions uniques et liens de partage

SharePoint Online hérite dans l’ordre site, bibliothèque, dossier, élément. Chaque rupture crée une étendue de permissions uniques. Au moment de la rupture, l’élément reçoit une copie des permissions du parent, puis diverge. Le modèle ne connaît pas d’entrée de refus : pour retrancher, il faut rompre l’héritage et retirer. Rétablir l’héritage supprime les permissions uniques de l’élément, sans retour arrière autre que les reposer à la main.

Le fait qui change tout : un lien de partage sur un fichier ou un dossier rompt l’héritage de cet élément. Chaque clic sur « Partager » est une rupture d’héritage faite par quelqu’un qui pensait envoyer un document. C’est sans doute l’outil de gestion des droits le plus utilisé de la planète, et le seul livré sans formation à la gestion des droits. OneDrive repose sur le même modèle : un espace personnel est un site dont presque tous les accès sont des permissions uniques.

Le niveau « Accès limité » apparaît sur les conteneurs parents d’un élément partagé individuellement. Il permet de traverser jusqu’à l’élément et ne donne aucun droit sur le reste du contenu. Sa présence massive dans un rapport n’est pas une fuite : c’est la trace de ruptures plus bas, donc la liste des endroits à inspecter.

Microsoft documente une limite prise en charge de 50 000 étendues de permissions uniques par liste ou bibliothèque, et recommande de rester bien en dessous (5 000). La contrainte d’architecture qui en découle : une bibliothèque où chaque dossier a ses propres droits est une erreur de conception. Un besoin de cloisonnement durable se traite par des bibliothèques ou des sites distincts.

Héritage IAM cloud : Google Cloud, Azure et AWS

Les trois grands fournisseurs emploient le même mot pour trois modèles différents.

Google Cloud : la hiérarchie est organisation, dossier, projet, ressource. Les stratégies d’autorisation sont additives : le droit effectif est l’union de ce qui est accordé à chaque niveau. Un niveau inférieur ne peut pas retirer un rôle hérité. Seules les stratégies de refus (deny policies) retranchent. Un rôle accordé au niveau de l’organisation vaut donc sur chaque projet, présent et futur, et aucun responsable de projet ne peut s’en défaire.

Azure : la hiérarchie est groupe d’administration, abonnement, groupe de ressources, ressource. Une attribution de rôle à une étendue vaut pour tout ce qui est dessous, selon le modèle RBAC (Role-Based Access Control). Les rôles de l’annuaire Entra ID forment un plan séparé, avec une passerelle à connaître : un administrateur général peut s’élever et obtenir la gestion des accès à l’étendue racine. Un droit d’annuaire devient ainsi un droit sur toutes les ressources. Le principe de cloisonnement que cette passerelle met à mal est posé dans la page séparer plan de contrôle et plan de données.

AWS (Amazon Web Services) : il n’y a pas d’héritage hiérarchique des autorisations d’identité. Les SCP (Service Control Policies) d’AWS Organizations descendent le long des unités d’organisation, mais elles ne font que borner et n’accordent rien. Un refus explicite l’emporte toujours. L’héritage y passe par trois voies latérales :

les groupes ;
l’endossement de rôles, y compris en chaîne ;
les politiques de ressource.

Deux angles morts à connaître : les SCP ne s’appliquent pas au compte de gestion de l’organisation, et elles ne bornent que les identités de l’organisation. Une politique de ressource qui ouvre un accès à un compte externe leur échappe donc ; les RCP (Resource Control Policies), autre type de politique d’AWS Organizations, existent pour borner ce côté-là, sans rien accorder non plus. La persistance par ces voies est détaillée dans la page détecter la persistance IAM dans AWS.

Le rôle de propriétaire accordé au sommet « le temps de la migration » a une espérance de vie nettement supérieure à celle de la migration. Dans un modèle additif, c’est le seul droit que personne en dessous ne peut corriger.

Kubernetes ajoute sa propre couche, avec des rôles liés à un espace de noms ou au cluster entier. Elle est traitée dans la page RBAC Kubernetes et contrôle d’admission.

Comparatif de l’héritage des permissions, terrain par terrain

Terrain	Sens de l’héritage	Comment il se rompt	Refus contre autorisation	Où lire le droit effectif
NTFS et SMB	Volume, dossier, fichier ; entrées recopiées sur l’enfant	Héritage désactivé (conversion ou retrait) ; indicateurs de propagation	Ordre canonique : l’explicite passe avant l’hérité, donc une autorisation explicite bat un refus hérité	Onglet « Accès effectif », icacls, Get-Acl, AccessChk
Active Directory	Domaine, unité d’organisation, objet ; filtrage par classe	Héritage désactivé ; AdminSDHolder et SDProp sur les objets protégés	Même ordre canonique que NTFS	dsacls, BloodHound, PingCastle, ORADAD
SharePoint Online, OneDrive	Site, bibliothèque, dossier, élément	Permissions uniques ; tout lien de partage	Pas d’entrée de refus : retrancher impose de rompre	Rapports de permissions et de partage, vérification des autorisations d’un utilisateur
Google Cloud	Organisation, dossier, projet, ressource ; union	Pas de rupture possible vers le bas	Les stratégies de refus l’emportent sur les autorisations	Policy Analyzer
Azure	Groupe d’administration, abonnement, groupe de ressources, ressource	Pas de rupture ; seule l’étendue d’attribution limite	Modèle additif ; les refus sont réservés à des cas posés par la plateforme	Liste des attributions de rôle, attributions héritées incluses
AWS	Pas d’héritage des autorisations ; les SCP descendent comme plafond	Sans objet	Le refus explicite l’emporte toujours	IAM Access Analyzer

Surface d’attaque de l’héritage des permissions

L’héritage donne à un attaquant ce qu’il donne à l’administrateur : un effet de levier. Les attaques connues exploitent toutes l’écart entre l’endroit où l’entrée est écrite et l’endroit où elle agit.

Attaque	Mécanisme	Contre-mesure
Entrée héritable posée en hauteur	Avec le droit de modifier les permissions d’un conteneur élevé (racine de domaine, unité d’organisation de premier niveau, organisation cloud), une seule entrée discrète donne la main sur tout le sous-arbre.	Surveiller les modifications de permissions sur une liste courte de conteneurs sommets ; réduire qui peut les modifier.
Persistance par AdminSDHolder	Une entrée ajoutée sur AdminSDHolder est recopiée sur tous les objets protégés à chaque passage de SDProp, y compris après un nettoyage objet par objet.	Comparer régulièrement la DACL d’AdminSDHolder à sa valeur de référence. La page détection de la persistance couvre le reste.
Déplacement d’objet	Déplacer un compte ou un ordinateur dans une unité d’organisation où l’on détient une délégation, ou un projet dans un dossier où l’on a un rôle, fait hériter des droits sans toucher à une permission.	Journaliser les déplacements au même titre que les changements de droits ; restreindre le droit de créer et de déplacer.
Imbrication de groupes	Ajouter un groupe à un groupe ne déclenche aucune alerte centrée sur les comptes et élargit l’accès de tous ses membres.	Surveiller les modifications des groupes qui apparaissent dans des entrées de haut niveau ; limiter la profondeur d’imbrication.
Propriété	Le propriétaire d’un objet récupère le contrôle de sa DACL.	Auditer les propriétaires des objets sensibles, pas seulement leurs entrées.
Lien de partage ouvert	Un lien sans destinataire nommé est un droit au porteur : il contourne toute la hiérarchie.	Restreindre les types de liens autorisés, imposer une expiration, inventorier les liens existants.
Voie latérale cloud	Le droit de modifier une stratégie d’accès, d’endosser un rôle ou de réécrire une politique de ressource vaut élévation de privilèges.	Traiter ces permissions comme des droits d’administration ; plafonner par des refus hiérarchiques.

Exemple : logique d’audit du droit effectif sur une ressource sensible

Prérequis avant de commencer :

une liste de ressources sensibles tenue par quelqu’un ; sans elle, l’audit dégénère en inventaire exhaustif que personne ne lira ;
un compte d’audit en lecture sur les descripteurs de sécurité, et en lecture des stratégies au sommet de la hiérarchie cloud ;
la journalisation des changements de permissions, activée au préalable : événement 4670 sur les objets Windows, événement 5136 sur les objets d’annuaire, journaux d’activité d’administration côté cloud (Cloud Audit Logs, journal d’activité Azure, CloudTrail). Ces journaux ne se reconstituent pas après coup.

L’audit part de la ressource et remonte, jamais l’inverse. Lire les listes d’accès de haut en bas produit des milliers de lignes exactes et aucune réponse. Le schéma décrit la séquence : calculer qui peut quoi, retrouver l’entrée qui produit chaque droit, la classer, puis décider selon la classe.

Trois règles de décision découlent de ce schéma :

Un droit hérité trop large se corrige sur le parent. Le corriger sur l’enfant par un refus ou une rupture ajoute une exception et laisse le défaut en place pour tous les autres enfants.
Une entrée explicite sur une personne est suspecte par construction. Soit elle double un groupe, soit elle signale un besoin que la hiérarchie ne sait pas exprimer.
Un droit obtenu par appartenance se traite dans la chaîne de groupes. Retirer le groupe de l’entrée casse l’accès de ses membres légitimes.

Côté outillage :

Fichiers : icacls, Get-Acl et AccessChk de Sysinternals extraient les entrées avec leur caractère explicite ou hérité.
Annuaire : dsacls lit un objet. BloodHound calcule les chemins transitifs. PingCastle et ORADAD (Outil de récupération automatique des données de l’Active Directory), publié par l’ANSSI (Agence nationale de la sécurité des systèmes d’information), donnent une vue d’ensemble des délégations anormales.
SharePoint : les rapports de permissions et de partage listent les étendues uniques.
Cloud : Policy Analyzer chez Google Cloud, la liste des attributions de rôle Azure avec les attributions héritées, et IAM Access Analyzer chez AWS répondent à la question « qui accède à quoi », chacun dans son périmètre.

Limites de l’audit du droit effectif et conditions d’exploitation

Un calcul de droit effectif ne voit que ce que son modèle contient. Il ne garantit pas :

Les privilèges système. Sous Windows, le privilège de sauvegarde et celui de prise de possession passent outre la DACL, tout comme un administrateur local du serveur. Le droit de traverser les dossiers, accordé largement par défaut, permet d’atteindre un objet par son chemin direct sans aucun droit sur ses parents.
Les sessions en cours. Les appartenances aux groupes sont figées dans le jeton ou le ticket émis à l’ouverture de session. Un retrait de groupe n’agit qu’au renouvellement (voir tickets Kerberos).
La couche voisine. Le calcul NTFS ignore le partage SMB s’il n’est pas fourni, et le calcul cloud ignore les droits internes à l’application.
Les limites de chaque analyseur. Types de stratégies non évalués, conditions, accès entre organisations : la liste de ce qu’un outil n’évalue pas est documentée, et se lit avant de signer un rapport.
La légitimité. L’outil dit qui peut, jamais qui devrait. Cette réponse vient d’un propriétaire de ressource, pas d’un tableau de bord, quelle que soit la quantité de camemberts.

En exploitation, quatre points tiennent le dispositif :

Supervision : alerter sur les changements de permissions et de propriétaire des conteneurs sommets, sur les ruptures d’héritage nouvelles et sur les déplacements d’objets. Le reste relève de la détection de dérive de configuration.
Revue périodique : repasser l’inventaire des ruptures, nettoyer les comptes à adminCount résiduel, faire expirer les liens de partage, retirer les entrées nominatives.
Sauvegarde : exporter les descripteurs de sécurité avant toute réinitialisation massive de l’héritage. Une propagation sur une grande arborescence est longue et non atomique ; interrompue, elle laisse un état mixte qu’aucune documentation ne décrit.
Reprise : une restauration de fichiers ramène les permissions de l’époque de la sauvegarde, groupes retirés depuis inclus. Le droit effectif des ressources sensibles se recalcule après restauration.

FAQ

Un refus hérité bloque-t-il toujours l’accès ?

Non sur NTFS et Active Directory : l’ordre canonique place les autorisations explicites avant les refus hérités, donc une autorisation posée directement sur l’objet passe. Oui chez AWS, où le refus explicite l’emporte toujours, et chez Google Cloud, où les stratégies de refus priment sur les autorisations. SharePoint Online n’a pas d’entrée de refus.

Faut-il désactiver l’héritage pour protéger un dossier sensible ?

Rarement. La rupture protège contre les ajouts faits plus haut, mais elle soustrait aussi l’objet aux retraits et aux corrections. Si le besoin est durable, un conteneur séparé avec ses propres droits se relit mieux et se maintient mieux. La rupture reste défendable pour un objet isolé, avec un propriétaire et une date de revue.

Pourquoi un ancien administrateur garde-t-il des permissions différentes des autres comptes ?

Parce que SDProp a remplacé sa DACL et coupé l’héritage pendant qu’il appartenait à un groupe protégé. Rien ne défait cette opération à la sortie du groupe : adminCount reste à 1 et l’héritage reste coupé. La remise en état est manuelle : réactiver l’héritage sur l’objet et remettre l’attribut à zéro.

🐝 Ce qui arrive si on s’en passe

Sans audit du droit effectif, les retraits effectués sur un conteneur passent pour des révocations alors qu’ils n’atteignent aucun objet à héritage rompu : un changement de poste ou un départ laisse des accès vivants sur les éléments qui avaient justement été jugés assez sensibles pour recevoir des droits à part. Une entrée héritable ajoutée par un intrus au sommet d’une hiérarchie reste invisible, puisque personne ne regarde le sommet et que chaque objet examiné isolément paraît normal. En cas d’incident, la question « qui pouvait lire cette ressource » n’a pas de réponse dans le délai disponible. La seule réparation restante devient la réinitialisation en masse de l’héritage, qui efface du même geste les exceptions légitimes et les illégitimes.

🦫 Explication de la marmotte 🍫

Sur un serveur ou un service en ligne, les fichiers et les objets sont rangés dans des conteneurs emboîtés : un dossier dans un dossier, un projet dans une organisation. Quand un droit est donné sur un conteneur, il s’applique automatiquement à tout ce qu’il contient. Le droit qu’une personne possède sur un fichier n’est donc écrit nulle part en entier. Il faut le calculer, en additionnant ce qui est posé sur le fichier, ce qui descend de chaque conteneur au-dessus, et ce que la personne reçoit par les groupes dont elle est membre, y compris les groupes rangés dans d’autres groupes. Selon les systèmes, une interdiction l’emporte toujours, ou seulement dans un certain ordre. On peut aussi couper la transmission sur un objet : il garde alors une copie des droits du moment, et les retraits faits plus haut ne l’atteignent plus. Vérifier les droits consiste à partir des objets sensibles, à calculer qui peut vraiment y accéder, puis à retrouver d’où vient chaque droit : posé directement, descendu d’un conteneur, ou reçu par un groupe. Un droit trop large se corrige à l’endroit où il a été posé, pas plus bas. Chaque coupure doit avoir un responsable et une raison. Si ce travail n’est pas fait, des personnes gardent des accès que plus personne ne connaît, et une modification faite tout en haut ouvre d’un coup des milliers d’objets.

Pages voisines

La citent

Auditer l'héritage des permissions et le droit effectif

Elle cite

: les deux pages se citent l’une l’autre.