Les privilèges racontent toujours une histoire
Un audit Active Directory qui commence par la question « qui est Domain Admin ? » passe à côté de l'essentiel. Les privilèges qui posent réellement problème dans un système d'information vivant ne se trouvent presque jamais là où on les cherche en premier.
Un audit qui commence par le mauvais périmètre
Un client nous demande un audit de sécurité Active Directory. La commande est claire, presque rassurante : identifier les comptes à supprimer, réduire le nombre de Domain Admins, corriger les grosses anomalies. Les premières questions posées par les équipes le confirment. Qui est Domain Admin ? Qui possède les privilèges élevés ? Quels comptes faut-il désactiver ?
Au début de la mission, tout le monde regarde dans la même direction. Les privilèges sensibles seraient concentrés dans quelques groupes d'administration bien identifiés. Il suffirait de faire le ménage et de rendre un rapport.
Au bout de quelques ateliers, une autre réalité apparaît. Les privilèges ne résident pas uniquement dans les comptes administrateurs. Ils circulent partout dans le système d'information. Dans un compte de service. Dans une délégation posée sur une OU. Dans une relation de confiance entre forêts. Dans une clé API. Dans un certificat émis par une autorité interne. Dans une tâche planifiée qui tourne depuis plusieurs années. Dans un groupe imbriqué que personne n'a plus ouvert. Dans la synchronisation entre Active Directory et Entra ID. Dans une application métier oubliée qui a conservé ses droits.
L'équipe cesse alors de chercher des administrateurs. Elle commence à cartographier les privilèges. La nature du travail change. Nous ne demandons plus qui est puissant. Nous demandons pourquoi les privilèges existent, comment ils sont attribués, et par quels chemins il est possible de les obtenir.
Chaque privilège a été créé un jour par quelqu'un
Les privilèges racontent toujours une histoire. Chaque délégation, chaque groupe, chaque rôle, chaque compte de service, chaque secret, chaque certificat existe parce qu'à un moment donné, quelqu'un a pris une décision. Cette décision avait une raison — un projet, une contrainte technique, une urgence opérationnelle, une exception accordée pour deux semaines et jamais retirée.
Notre travail consiste à reconstruire cette histoire. Pourquoi ce groupe existe-t-il ? Pourquoi cette délégation a-t-elle été créée ? Pourquoi cette application dispose-t-elle encore de ces droits ? Pourquoi ce compte technique est-il toujours actif alors que le service qu'il portait a été décommissionné il y a trois ans ?
Très souvent, personne ne connaît plus la réponse. Le privilège est resté ; le contexte a disparu. Nous appelons ça la mémoire des privilèges. Elle survit aux projets, aux personnes, aux migrations et aux réorganisations. Ce n'est pas une anomalie, c'est une caractéristique normale d'un système d'information qui a vécu.
Quelques scènes revenues d'un audit à l'autre
Quatre situations rencontrées récemment, sous des formes voisines, dans plusieurs environnements. Chacune paraît locale ; toutes racontent la même chose sur la manière dont les privilèges se sédimentent.
- 01
Un compte technique plus puissant que les administrateurs
Une équipe découvre qu'un compte de service possède davantage de privilèges que les administrateurs eux-mêmes. Le compte a été créé, dix ans plus tôt, pour supporter un outil de sauvegarde, ou une solution de supervision, ou une brique d'automatisation — les histoires varient, la structure est la même. Personne n'ose modifier son mot de passe. Plus personne ne sait précisément quelles applications en dépendent. Il est devenu, de fait, un standing privilege permanent que plus aucune procédure ne mentionne.
- 02
Des délégations qui ont survécu à leur projet
Un ancien projet de migration a créé plusieurs délégations Active Directory sur des OU sensibles pour permettre le basculement en temps voulu. Le projet est terminé depuis plusieurs années. L'équipe qui l'a menée n'existe plus sous la même forme. Les délégations, elles, sont toujours en place. Chacune est un attack path potentiel, et personne dans l'organisation n'a d'intérêt clair à les retirer, parce que personne n'a de mémoire précise de ce qu'elles autorisent.
- 03
Groupes techniques et profils métier qui ne se parlent pas
Une application métier synchronise automatiquement des groupes Active Directory avec ses propres rôles applicatifs. Les administrateurs AD connaissent les groupes. Les responsables métiers connaissent les profils. Ni les uns ni les autres ne savent décrire précisément le lien entre les deux, encore moins qui l'a défini. Le résultat est un entitlement métier dont la portée technique réelle n'est plus lisible par ceux qui l'accordent.
- 04
Aucun Domain Admin direct, plusieurs chemins indirects
Un audit révèle qu'aucun utilisateur nommé n'appartient directement au groupe Domain Admins. Sur le papier, le sujet est réglé. En pratique, quelques chemins de délégation imbriqués entre plusieurs groupes et deux forêts permettent à un compte parfaitement ordinaire d'obtenir indirectement les mêmes privilèges. Le sujet n'est plus le groupe Domain Admin. Le sujet est la manière dont les privilèges circulent dans l'access graph. Les shadow administrators ne sont presque jamais annoncés dans un annuaire.
Aucune de ces situations n'apparaît dans un tableau de bord de conformité classique. Elles n'apparaissent qu'en observant les relations entre les objets — les identity relationships — plutôt qu'en énumérant les objets eux-mêmes.
Les outils, quand ils deviennent utiles
Les produits ne sont jamais le sujet principal de nos missions. Ils apparaissent lorsqu'ils permettent de répondre à une question déjà posée. Voici, brièvement, la manière dont nous les mobilisons dans ce contexte.
- Netwrix Auditor
- Nous l'utilisons pour reconstituer l'historique. Qui a créé cette délégation, quand, dans quel contexte. Quelles activités privilégiées se sont produites sur les objets sensibles ces derniers mois. C'est un outil de mémoire — la mémoire que l'organisation a souvent perdue.
- Netwrix Access Analyzer
- Nous nous en servons pour reconstruire les chemins d'accès vers les ressources sensibles. Le point de bascule d'un audit se fait à ce moment-là. Nous cessons de nous demander qui est administrateur et nous commençons à nous demander qui pourrait, via quels chemins, obtenir des privilèges équivalents. C'est la lecture par attack path, pas par annuaire.
- Netwrix Directory Manager
- Une fois le nettoyage engagé, la question devient : comment évite-t-on que la situation ne se reconstitue en trois ans ? Directory Manager remet un cadre autour des délégations quotidiennes. Les demandes deviennent traçables, les approbations sont documentées, les extensions temporaires sont effectivement temporaires.
- Microsoft Entra ID
- Les privilèges ne s'arrêtent plus à Active Directory. Ils circulent entre plusieurs annuaires, plusieurs plateformes SaaS et plusieurs tenants. Une identité peut être ordinaire dans AD, puis très puissante dans Entra ID via un rôle applicatif ou une permission déléguée sur une API. Nous cartographions les deux côtés, parce qu'un attack path moderne les traverse tous les deux.
- Keeper PAM
- Le coffre-fort protège les secrets techniques : mots de passe de comptes de service, clés d'accès, secrets d'automatisation. Mais avant de protéger un secret, il faut savoir pourquoi il existe et qui l'utilise réellement. La partie visible — le coffre — n'a d'utilité que si la partie invisible — le pourquoi — a été instruite au préalable.
Ce que nous voulons que le RSSI retienne
Les privilèges ont une mémoire. Ils survivent aux projets. Ils survivent parfois aux personnes qui les ont créés. Ils traversent les migrations, les changements d'organisation, les évolutions applicatives, les fusions et les rachats. Un audit sérieux commence par accepter cette réalité : la moitié du travail consiste à retrouver l'intention initiale.
Cette mémoire raconte aussi quelque chose de l'organisation. Elle indique où les décisions ont été prises dans l'urgence, où les projets ont été livrés à moitié, où les exceptions se sont pérennisées, où les responsabilités se sont diluées. Un annuaire est une forme d'archéologie.
Un audit Identity Security ne consiste donc pas à traquer quelques comptes administrateurs. Il consiste à comprendre comment les privilèges se sont construits, à quels projets ils sont attachés, à quelles applications ils profitent encore, et par quels chemins ils peuvent être obtenus. Lorsque cette histoire a été reconstituée, la remédiation devient cohérente. Lorsqu'elle ne l'a pas été, la remédiation se contente de déplacer l'identity attack surface d'un endroit à un autre.
Comprendre les relations avant de traiter les objets
La sécurité des identités ne se limite pas à la protection de quelques comptes sensibles. Elle consiste à comprendre les relations qui unissent les identités, les groupes, les applications, les délégations, les comptes techniques et les secrets. C'est cet ensemble de relations, bien plus qu'une liste d'objets, qui définit l'identity attack surface réelle d'une organisation.
Nous cherchons à comprendre ces relations avant d'engager la moindre action de remédiation. C'est cette compréhension qui permet ensuite aux plateformes — Netwrix Auditor, Access Analyzer et Directory Manager, Microsoft Entra ID, Keeper PAM — de produire pleinement leur valeur. Sans elle, un audit reste un inventaire. Avec elle, il devient une décision.