Active Directory : le composant que votre cartographie devrait traiter comme une infrastructure critique

Une entreprise dispose d’un PRA documenté. Ses applications critiques sont identifiées, les serveurs sont sauvegardés et les procédures de restauration ont été testées.

Puis Active Directory est compromis.

À cet instant, une question apparaît : peut-on réellement reconstruire le système d’information dans l’ordre prévu par le PRA ?

Restaurer un serveur ne signifie pas nécessairement pouvoir l’exploiter. Une application restaurée peut encore dépendre d’un compte de service, d’un groupe Active Directory, du DNS, d’une authentification centralisée ou d’un compte d’administration.

Active Directory n’est donc pas seulement un annuaire. Dans de nombreuses architectures, il constitue une dépendance transverse du système d’information. L’ANSSI le décrit comme un élément critique centralisant les permissions d’un parc Windows et indique que sa compromission peut conduire à une prise de contrôle complète du SI.4

Pour la cartographie, la conséquence est importante : il ne suffit pas de savoir où se trouve Active Directory. Il faut savoir ce qui dépend de lui.

Une cartographie classique montre mal les dépendances d’identité

Une cartographie d’infrastructure représente généralement :

site → réseau → serveur → application → base de données

Mais une autre architecture traverse ces couches :

identité → authentification → autorisation → administration → service

Une application métier peut être correctement reliée à son serveur, sa base, son réseau et ses flux tout en dépendant aussi d’un domaine Active Directory, de groupes de sécurité, d’un compte de service, d’une résolution DNS intégrée ou d’un compte d’administration.

En fonctionnement normal, ces relations peuvent sembler secondaires. Après une compromission, elles deviennent déterminantes.

Active Directory peut appartenir au cœur de confiance du SI

Dans de nombreux systèmes bureautiques, le cœur de confiance est centré autour d’Active Directory. Si un attaquant obtient suffisamment de privilèges sur l’annuaire, il peut potentiellement agir sur un très grand nombre de composants qui lui font confiance.

Le problème n’est donc plus simplement « notre Active Directory est compromis », mais « quels composants du SI pouvons-nous encore considérer comme dignes de confiance ? »

Le Tier 0 change la manière de regarder l’architecture

Le Tier 0 regroupe les composants et identités disposant du plus haut niveau de privilège. Il ne faut pas le réduire aux seuls contrôleurs de domaine : le raisonnement porte sur ce qui peut contrôler directement ou indirectement le cœur de confiance.

L’ANSSI consacre un guide spécifique à la remédiation du Tier 0 Active Directory et à la reconstruction de ce socle de confiance.1

Cela introduit une différence entre deux cartographies : la première décrit ce qui communique avec quoi ; la seconde doit aussi permettre de comprendre ce qui peut administrer quoi.

Un flux réseau et une relation de confiance ne racontent pas la même chose

Une cartographie de sécurité devrait pouvoir distinguer plusieurs relations :

A communique avec B

A s’authentifie auprès de B

A administre B

A fournit une identité à B

A autorise l’accès à B

A peut modifier la configuration de B

Un flux indique un chemin technique. Une relation d’administration indique potentiellement un chemin de prise de contrôle.

Le PRA peut contenir un ordre de reprise techniquement impossible

Imaginons un PRA prévoyant la restauration de l’infrastructure, puis des bases, des applications critiques et enfin la réouverture des accès.

Mais supposons que l’hyperviseur utilise une authentification liée à l’AD, que les administrateurs utilisent des comptes du domaine, que les applications reposent sur des comptes de service AD, que le DNS dépende de l’infrastructure Active Directory et que les consoles de sauvegarde utilisent elles aussi des comptes du domaine.

L’ordre réel change. Avant de restaurer les applications, il faut reconstruire un socle de confiance permettant de les administrer sans réintroduire la compromission. C’est l’un des enjeux centraux de la remédiation.2

Sauvegarder Active Directory ne suffit pas nécessairement

Après une compromission majeure, la question n’est pas seulement de savoir si une sauvegarde existe. Il faut déterminer quand l’environnement a été compromis, quelles identités ont été utilisées, quelles modifications ont été effectuées, quels mécanismes de persistance ont pu être introduits et quels composants peuvent encore être considérés comme fiables.

Restaurer un état contenant déjà une compromission peut restaurer le problème en même temps que le service. Les travaux de l’ANSSI sur l’investigation et la qualification des incidents, publiés le 16 septembre 2026, rappellent l’importance de comprendre précisément l’incident pour orienter la réponse.5

La reconstruction n’est donc pas simplement une opération de restauration. C’est une reconstruction de confiance.

La cartographie peut aider à définir l’ordre de reconstruction

Une représentation utile après compromission pourrait partir du cœur de confiance :

Tier 0 → identité → administration → infrastructure → application → service métier

Prenons un environnement composé d’un Active Directory, d’une plateforme de virtualisation, d’un outil de sauvegarde, de serveurs SQL, d’un ERP et d’une application RH.

La cartographie classique montre par exemple :

hyperviseur → VM → SQL → ERP

La cartographie des dépendances de confiance peut révéler :

Active Directory → compte administrateur → hyperviseur

Active Directory → compte de service → SQL

Active Directory → authentification → ERP

Active Directory → DNS → applications

Active Directory → compte administrateur → sauvegarde

L’ordre de reconstruction ne peut donc plus être déterminé uniquement à partir des dépendances applicatives.

Les comptes de service sont souvent une dépendance invisible

Une application peut sembler autonome tout en utilisant une identité Active Directory pour accéder à une base, lancer un service Windows, accéder à un partage, appeler une API ou exécuter une tâche planifiée.

La relation utile à documenter devient :

application → service → identité technique → droits → ressource

Elle permet de répondre à deux questions : que peut contrôler cette identité si elle est compromise ? et qu’est-ce qui cesse de fonctionner si nous la réinitialisons ?

Les dépendances d’administration dépassent Active Directory

Dans un environnement hybride ou cloud, il peut aussi exister un fournisseur d’identité cloud, des comptes d’administration SaaS, des comptes privilégiés cloud, des secrets d’automatisation, des bastions, des outils PAM et des consoles d’administration centralisées.

La question générale devient alors : quels composants disposent du pouvoir de contrôler les autres composants du SI ?

Ajouter une vue « confiance et administration »

Une cartographie de SI possède traditionnellement des vues métier, applicatives, infrastructure ou réseau. Pour les environnements sensibles, une vue supplémentaire peut être utile : la vue des dépendances de confiance et d’administration.

Elle peut représenter annuaires, fournisseurs d’identité, comptes privilégiés, comptes de service critiques, bastions, PAM, postes d’administration, hyperviseurs, consoles cloud, outils de sauvegarde, outils de sécurité et systèmes administrés.

L’objectif n’est pas d’inventorier tous les comptes utilisateurs. Il s’agit d’identifier les relations capables de modifier profondément le SI.

Pour les organisations qui souhaitent structurer ce type de dépendances dans un référentiel de cartographie du SI, Cartographit — solution éditée par Nixial, également éditeur de Cybercoria — permet de relier les objets du SI, leurs infrastructures et leurs flux dans un même modèle. Ce lien est proposé comme ressource complémentaire ; il ne constitue ni une recommandation de l’ANSSI ni une preuve de conformité.

Le test de compromission

Une méthode simple consiste à sélectionner un composant du cœur de confiance et à demander : « Si ce composant est totalement compromis, que devons-nous considérer comme potentiellement compromis avec lui ? »

Pour Active Directory :

AD compromis → comptes privilégiés → systèmes administrés → applications → services métier

Pour un hyperviseur :

hyperviseur compromis → machines virtuelles → applications → données

Pour une console cloud :

compte privilégié compromis → ressources cloud → données → services

Pour une plateforme de sauvegarde :

administration compromise → sauvegardes → capacité de restauration

On obtient alors une cartographie des rayons de compromission, utilisable pour préparer la crise.

Sept questions à poser à sa cartographie avant une compromission AD

1. Savons-nous quelles applications dépendent d’Active Directory pour fonctionner ?
2. Savons-nous quels comptes de service sont utilisés par les applications critiques ?
3. Savons-nous quels composants peuvent administrer notre Active Directory ?
4. Savons-nous quels composants Active Directory peut indirectement contrôler ?
5. Notre PRA distingue-t-il restauration et reconstruction de confiance ?
6. Connaissons-nous l’ordre de reconstruction après compromission du Tier 0 ?
7. Pouvons-nous visualiser le rayon de compromission d’une identité privilégiée ?

Cartographier le pouvoir, pas seulement les composants

La cartographie des systèmes d’information cherche traditionnellement à répondre à des questions comme : où se trouve cette application ? Sur quel serveur fonctionne-t-elle ? Avec quoi communique-t-elle ?

Dans une logique de résilience cyber, une autre question devient indispensable : qui peut la contrôler ?

Active Directory illustre parfaitement cette différence. Un annuaire peut n’occuper que quelques composants dans une cartographie d’infrastructure tout en disposant d’un rayon de dépendance immense dans le système d’information.

Préparer la remédiation d’un incident ne consiste donc pas uniquement à disposer de sauvegardes. Il faut aussi savoir dans quel ordre reconstruire la confiance — et pour connaître cet ordre, il faut avoir cartographié les dépendances avant l’incident.