Tiering Active Directory en 2026 : construire des frontières de confiance vérifiables

Comprendre le Tiering AD : ce que protègent les niveaux 0, 1 et 2

Le modèle Tier 0/1/2 sépare traditionnellement l'administration des infrastructures d'identité, celle des serveurs et applications, et celle des postes utilisateurs. Cette séparation répond à un principe précis : une compromission dans un environnement de moindre confiance ne doit pas permettre d'exercer une capacité d'administration dans un environnement de confiance supérieure.

Cette classification ne doit pas être confondue avec une échelle de criticité métier. Un serveur contenant des données financières particulièrement sensibles peut relever du Tier 1, tandis qu'une console technique moins visible doit être protégée au niveau Tier 0 si elle peut exécuter des commandes privilégiées sur un contrôleur de domaine.

Le périmètre Tier 0 inclut ainsi les chemins de contrôle indirects. Une autorité de certification AD CS, un mécanisme de synchronisation d'identités, un hyperviseur hébergeant des contrôleurs de domaine ou un système de sauvegarde capable d'en restaurer les données doivent être analysés selon les pouvoirs réels qu'ils confèrent. L'objectif est de maintenir une surface Tier 0 aussi limitée que possible sans ignorer ses dépendances.

Tiering classique et Enterprise Access Model : deux modèles complémentaires

Microsoft continue de documenter en 2026 le modèle de Tiering AD DS. L'Enterprise Access Model, ou EAM, en étend le raisonnement aux systèmes hybrides, aux environnements cloud, aux applications et aux nouveaux parcours d'accès.

L'EAM distingue notamment le Control Plane, qui gouverne les identités et les mécanismes de contrôle d'accès, le Management Plane, qui administre les systèmes, et le Data/Workload Plane, qui porte les applications et les données métiers. Il prend également en compte les chemins d'accès utilisateurs et applicatifs, notamment les API et les identités non humaines.

Pour une organisation exploitant Active Directory et Microsoft Entra ID, ces deux représentations sont utiles. Le Tiering AD DS structure la protection de l'annuaire local et de ses dépendances, tandis que l'EAM permet d'étudier les relations de contrôle entre identité locale, administration cloud, outils de gestion et applications.

Il ne s'agit pas de remplacer automatiquement les Tiers par de nouveaux noms. Il s'agit d'étendre l'analyse à toutes les capacités permettant de modifier une identité, une politique d'accès ou les systèmes qui les contrôlent.

Une méthode de déploiement en quatre phases

Phase 1 — Cartographier les capacités de contrôle et les chemins d'attaque

La première étape consiste à identifier les composants qui disposent effectivement du pouvoir de contrôler Active Directory. L'analyse porte sur les groupes privilégiés, les délégations, les ACL, les GPO, les comptes techniques, les systèmes de certification, les outils de gestion et les infrastructures qui administrent les contrôleurs de domaine.

Un inventaire d'actifs ne suffit pas à produire cette cartographie. Il faut pouvoir expliquer comment une identité ou un système pourrait agir sur une ressource de confiance supérieure. Une console de déploiement capable de modifier un service exécuté sur un contrôleur de domaine représente par exemple un chemin de contrôle à qualifier, même si son équipe d'exploitation n'appartient pas à l'équipe Active Directory.

Le livrable attendu est une cartographie argumentée des ressources de confiance, des dépendances techniques et des chemins d'attaque identifiés. Elle doit distinguer les capacités confirmées, les risques potentiels nécessitant investigation et les dépendances acceptées.

Phase 2 — Construire une frontière Tier 0 réellement opposable

L'isolation du Tier 0 commence par la séparation des comptes administratifs et bureautiques, la réduction des droits permanents et le choix d'environnements d'administration de confiance. Les comptes Tier 0 ne doivent pas être utilisés pour administrer des serveurs Tier 1 ou des postes Tier 2.

Les postes d'administration privilégiés, ou PAW, répondent à cette exigence en séparant les tâches sensibles des usages exposés comme la navigation Internet et la messagerie. Les intermédiaires d'administration doivent préserver ce niveau de confiance : un bastion permettant d'administrer un contrôleur de domaine devient lui-même une dépendance Tier 0.

Les restrictions de connexion, les politiques Windows, les mécanismes de protection des secrets et le filtrage réseau permettent de rendre la séparation effective. Leur déploiement exige des tests progressifs pour préserver les flux légitimes nécessaires au fonctionnement d'Active Directory, notamment l'authentification et les services d'annuaire.

Phase 3 — Étendre le modèle aux serveurs, applications et identités techniques

La séparation Tier 0 ne résout pas automatiquement les dépendances entre les serveurs, les applications et les postes utilisateurs. Il faut identifier les comptes de maintenance, les automatisations, les outils transverses et les accès de prestataires qui pourraient réintroduire des privilèges de niveau supérieur dans des environnements moins fiables.

Cette phase examine notamment les comptes locaux, les comptes de service, les secrets techniques, les chaînes de déploiement et les consoles mutualisées. Les mécanismes de moindre privilège, d'administration juste suffisante et d'activation temporaire des droits peuvent réduire l'exposition lorsque les contraintes techniques le permettent.

Le modèle doit rester exploitable pour les administrateurs. Une architecture théoriquement étanche mais contournée pour réaliser les opérations courantes n'atteint pas son objectif de sécurité.

Phase 4 — Tester les frontières et maintenir leur efficacité

Une architecture de Tiering doit être soumise à des vérifications fonctionnelles et techniques. Des tentatives de connexion contrôlées, des analyses de privilèges et des tests de chemins d'administration permettent de constater si les interdictions prévues sont réellement appliquées.

Les résultats sont documentés avec les exceptions, les corrections nécessaires et les risques résiduels. Les évolutions de l'Active Directory, les nouveaux agents installés sur les contrôleurs de domaine et les changements de plateformes d'administration doivent ensuite déclencher de nouvelles vérifications.

Pour les organisations souhaitant inscrire ces travaux dans un programme de sécurisation AD plus large, notre méthode de sécurisation Active Directory en 90 jours détaille une démarche complémentaire de priorisation, remédiation, détection et production de preuves.

Le défi des comptes de service et des applications historiques

Les comptes de service constituent une difficulté particulière dans un projet de Tiering. Ils exécutent des tâches sans intervention humaine, disposent parfois de privilèges historiques et peuvent être utilisés par plusieurs applications ou serveurs. Leur appartenance à un groupe sensible ou leur capacité à modifier une ressource Tier 0 peut créer un chemin d'attaque que la séparation des comptes administrateurs humains ne traite pas.

Les gMSA peuvent faciliter la gestion et la rotation des secrets dans certains environnements Windows. Ils ne dispensent cependant pas de contrôler les machines autorisées à utiliser ces comptes, leurs permissions et les ressources auxquelles ils donnent accès.

Les applications historiques imposent parfois des protocoles, comptes partagés ou mécanismes d'automatisation difficiles à faire évoluer. Plutôt que de supprimer brutalement ces usages, une démarche de Tiering doit les inventorier, identifier leur propriétaire, qualifier les privilèges réellement nécessaires et définir une trajectoire de correction compatible avec l'exploitation.

Lorsqu'une exception ne peut pas être supprimée immédiatement, elle doit disposer d'un responsable, d'une justification, de contrôles compensatoires, d'une date de révision et de conditions de sortie. Une exception laissée sans gouvernance devient progressivement une caractéristique permanente de l'architecture.

Forêt d'administration, bastion et PAM : choisir selon les chemins réels

La construction d'une forêt d'administration distincte, parfois désignée par les termes Red Forest ou ESAE, ne constitue pas un prérequis universel de sécurisation d'Active Directory. Le guide ANSSI-PA-099 recommande d'éviter son déploiement, sauf besoin suffisamment important de mutualisation de l'administration Tier 0 de plusieurs forêts, avec une analyse préalable des contraintes et risques introduits.

Le bastion et le PAM constituent des outils possibles de contrôle des accès privilégiés, sans remplacer la séparation des identités, la sécurisation des postes de départ et la maîtrise des dépendances. Un coffre-fort peut protéger un secret sans empêcher qu'une session privilégiée soit détournée depuis un poste source compromis.

La bonne architecture dépend donc du chemin complet : appareil de départ, identité utilisée, mécanisme d'authentification, intermédiaires, autorisation, cible et supervision. L'enregistrement d'une session améliore la traçabilité, mais ne constitue pas une preuve que cette session ne pouvait pas être détournée.

Comment démontrer que le Tiering est réellement efficace ?

Un projet de Tiering doit produire des preuves vérifiables, et pas seulement une documentation d'architecture. Les critères de réception doivent correspondre aux risques identifiés au démarrage et pouvoir être rejoués après chaque évolution significative.

La mesure pertinente ne consiste pas à déclarer que 100 % des serveurs sont associés à un Tier. Elle consiste à démontrer quels chemins d'attaque connus ont été neutralisés, quelles capacités de contrôle subsistent et pourquoi les exceptions restantes sont acceptées.

Un score d'audit de sécurité reste un indicateur utile de posture. Il ne remplace ni l'analyse des permissions et dépendances, ni les tests permettant de vérifier les frontières de confiance.

Du Tiering théorique à la remédiation opérationnelle

Les projets de Tiering rencontrent souvent une difficulté qui dépasse le paramétrage technique : plusieurs équipes administrent des composants interdépendants sans disposer d'une représentation commune de leurs responsabilités et des risques. La sécurité de l'annuaire dépend pourtant autant de l'équipe qui administre une plateforme de sauvegarde ou une console de déploiement que de celle qui gère les comptes Domain Admins.

Dans une mission auprès d'une organisation du secteur du transport, Ariovis a accompagné la reprise d'un programme PAM dont les fondations manquaient de structuration, notamment en matière de Tiering AD et de méthode d'embarquement applicatif. L'intervention a porté sur la clarification du modèle, la définition du Tiering, le durcissement des serveurs et l'industrialisation des intégrations. Cette expérience illustre l'importance de traiter ensemble l'architecture, les usages et l'exploitation, sans prétendre qu'un modèle théorique ou l'installation d'un outil suffisent.

Un accompagnement opérationnel doit laisser des éléments réutilisables par les équipes : cartographie des dépendances, politique de Tiering, règles de connexion, matrice d'exceptions, tests de recette, responsabilités d'exploitation et plan de contrôle récurrent. C'est sur ces résultats que doit être évaluée la progression de la sécurité Active Directory.

Références techniques

Microsoft Learn — Tier model for Active Directory Domain Services. Documentation du modèle AD DS Tier 0/1/2, de ses frontières de confiance et de son articulation avec l'Enterprise Access Model.

Microsoft Learn — Enterprise Access Model. Présentation des plans de contrôle, de gestion et de données, ainsi que des parcours d'accès utilisateurs et applicatifs.

ANSSI — Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. Guide ANSSI-PA-099, version du 2 octobre 2023. Les recommandations R5 à R8 concernent notamment l'analyse des chemins et le cloisonnement ; R80 traite des postes d'administration Tier 0 et R85 à R86 des forêts d'administration.