Tiering AD : séparer les comptes admin simplement

Le vrai risque : un compte admin utilisé partout

Dans beaucoup de PME, le même compte administrateur sert à gérer un serveur, se connecter à un poste utilisateur, ouvrir une session bureautique et parfois lire ses emails. C’est pratique, mais dangereux : si ce compte est compromis, l’attaquant peut rapidement prendre le contrôle du domaine.

Ce que les compromissions récentes révèlent

Une analyse de 47 compromissions majeures d’entreprises en 2025 montre que les identifiants à privilèges jouent un rôle central dans 89 % des cas. Le rapport Verizon 2025 sur les violations de données confirme cette tendance : le vol d’identifiants et l’abus de privilèges figurent parmi les premiers facteurs de compromission, responsables d’environ 22 % des violations confirmées à eux seuls comme vecteur d’accès initial.

Indicateur	Donnée observée
Compromissions majeures impliquant des identifiants à privilèges (analyse 2025)	89 %
Violations confirmées liées au vol d’identifiants comme vecteur initial	environ 22 %
Incidents impliquant des utilisateurs internes disposant de droits excessifs	45 %
Incidents impliquant des tiers avec un accès privilégié excessif	34 %

Le schéma d’attaque le plus destructeur suit généralement une chaîne reconnaissable : accès initial par phishing, élévation de privilèges locale sur le premier poste compromis, collecte d’identifiants, mouvement latéral vers des systèmes à plus forte valeur, puis élévation de privilèges au niveau du domaine une fois un identifiant administrateur obtenu. Avec l’IA générative, cette chaîne se déroule désormais en quelques heures plutôt qu’en plusieurs semaines.

Le tiering Active Directory consiste à séparer les niveaux d’administration pour limiter précisément ce mouvement latéral. L’idée est simple : un compte qui administre le domaine ne doit pas être utilisé sur un poste utilisateur ordinaire.

Une version pragmatique pour PME

Pas besoin de construire une architecture trop lourde dès le premier jour. Commencez par trois règles :

• un compte nominatif standard pour le travail quotidien ;
• un compte administrateur séparé pour les serveurs et services ;
• un compte très privilégié, rarement utilisé, pour Active Directory et les opérations critiques.

Ajoutez ensuite des postes ou sessions d’administration dédiés, du MFA, des mots de passe robustes, une journalisation claire et une revue régulière des groupes à privilèges.

Les priorités

• Supprimer les comptes administrateurs partagés.
• Retirer les droits Domain Admin inutiles, sachant que 45 % des incidents impliquent des utilisateurs internes disposant de droits excessifs à leur fonction réelle.
• Interdire l’usage des comptes admin pour la messagerie et le web.
• Créer des comptes séparés par niveau de privilège.
• Protéger les comptes admin avec MFA lorsque c’est possible.
• Surveiller les connexions et changements de groupes sensibles.
• Documenter les comptes de service et leurs droits, en portant une attention particulière aux accès tiers, impliqués dans 34 % des incidents à privilèges excessifs.

Ce qu’il faut éviter

Le risque est de rendre l’administration tellement complexe que les équipes contournent les règles. Le bon niveau de sécurité est celui qui réduit fortement le risque tout en restant utilisable. Pour une PME, une séparation claire des comptes et des usages apporte déjà un gain énorme.

Le tiering doit aussi s’accompagner d’un nettoyage : comptes dormants, anciens prestataires, groupes trop larges, scripts avec mots de passe, services exécutés avec trop de privilèges.

Le modèle à trois niveaux, expliqué simplement

Le modèle de tiering formalisé par Microsoft distingue trois niveaux de sensibilité, une logique transposable même dans une version allégée pour PME :

• Tier 0 (le plus critique) : contrôleurs de domaine, infrastructure PKI, et tout système capable d’administrer directement l’ensemble du domaine. Un compte Tier 0 ne doit jamais se connecter ailleurs que sur ces systèmes.
• Tier 1 (intermédiaire) : serveurs applicatifs, serveurs de fichiers, infrastructures métier. Les comptes de ce niveau administrent des serveurs mais n’ont pas de droits sur l’annuaire lui-même.
• Tier 2 (le plus courant) : postes de travail des utilisateurs et applications bureautiques. C’est le niveau où opère le compte nominatif standard du quotidien.

La règle absolue qui rend ce modèle efficace : un compte d’un niveau donné ne doit jamais s’authentifier sur un système d’un niveau plus sensible que le sien. C’est précisément cette règle, violée en permanence par l’usage d’un compte admin unique partout, qui permet à un attaquant de remonter d’un poste utilisateur compromis jusqu’au contrôle total du domaine.

Exemple de progression sur 3 mois

Une mise en place réaliste pour une PME suit généralement ce rythme : le premier mois pour l’inventaire des comptes à privilèges et la suppression des comptes partagés ou dormants, le deuxième mois pour la création des comptes séparés par niveau et l’activation du MFA sur les comptes sensibles, le troisième mois pour la mise en place de la journalisation et la première revue régulière des groupes à privilèges. Cette progression évite de bloquer les équipes du jour au lendemain tout en réduisant rapidement les risques les plus critiques.

L’audit comme point de départ

Un audit Active Directory permet d’identifier les comptes à risque, les délégations dangereuses et les chemins d’attaque probables. Il permet ensuite de mettre en place un modèle réaliste, adapté à l’équipe et aux contraintes métier.

MFA et tiering ne se remplacent pas

Une confusion fréquente consiste à croire que le MFA rend le tiering inutile. Les deux protègent en réalité contre des choses différentes. Le MFA complique la compromission initiale d’un compte : même avec le mot de passe, l’attaquant bute sur le second facteur. Le tiering, lui, limite les dégâts une fois qu’un compte est tombé, en empêchant de rebondir d’un poste ordinaire vers le cœur du domaine. L’un ferme la porte d’entrée, l’autre cloisonne la maison.

C’est leur combinaison qui protège. Un compte administrateur protégé par MFA mais utilisé au quotidien pour la messagerie reste exposé au phishing avancé et aux attaques de session : le second facteur ne sert plus à rien si l’attaquant détourne une session déjà ouverte. Séparer les usages reste donc indispensable, MFA ou pas.

Le maillon oublié des comptes de service

Les comptes de service, ceux qui font tourner les applications et les tâches automatisées, sont l’angle mort classique du tiering. Ils ne peuvent généralement pas utiliser de MFA, disposent souvent de droits élevés hérités d’une installation ancienne, et leur mot de passe, une fois défini, n’est presque jamais changé. Un attaquant qui cherche à contourner les protections déployées sur les comptes humains se tourne précisément vers eux.

Les traiter correctement ne demande pas de technologie sophistiquée, mais de la rigueur : documenter chaque compte de service, son usage réel et son périmètre, lui retirer les droits superflus, utiliser un mot de passe long et unique, restreindre son accès réseau au strict nécessaire et surveiller son activité. Un compte de service oublié avec des droits d’administration du domaine est une porte dérobée qui ne dit pas son nom.

Commencer petit, mais commencer

Le tiering a mauvaise réputation, celle d’une usine à gaz réservée aux grandes organisations. C’est un malentendu : sa version pragmatique, trois niveaux de comptes et une règle simple, apporte déjà l’essentiel du bénéfice à une PME, sans complexité excessive. Le vrai risque n’est pas d’en faire trop, mais de ne rien faire et de continuer à utiliser un compte tout-puissant partout, en offrant à un attaquant le chemin le plus court vers le contrôle total du domaine.

Un audit Active Directory reste le meilleur point de départ : il révèle les comptes à risque et les chemins d’attaque, puis permet de bâtir un modèle réaliste. Notre forfait Audit & Sécurité aide ensuite à prioriser ces corrections.

Sources : OmniPriv, The Anatomy of a Privileged Account Compromise, 2025’s Biggest Breaches · Microsoft Security Blog, Containing a domain compromise · Microsoft Learn, Enterprise access model