Tiering Model : renforcer la sécurité de vos administrateurs Active Directory

L’Active Directory (AD) est le cœur battant de la plupart des infrastructures d’entreprise. Il orchestre les identités, les accès, les politiques et les ressources. Mais cette centralisation fait aussi de lui une cible privilégiée pour les attaquants : une seule compromission d’un compte à privilèges, et c’est tout l’écosystème qui est à risque.

Pour réduire cette surface d’attaque, un principe s’impose : le modèle de Tiering.

Son objectif ? Segmenter et isoler les accès administratifs selon leur niveau de criticité, pour limiter les rebonds et cloisonner les privilèges.

Les limites d’un modèle traditionnel et natif

Dans de nombreux environnements, les administrateurs utilisent les mêmes comptes pour gérer indifféremment postes utilisateurs, serveurs applicatifs ou contrôleurs de domaine.

Résultat : un simple rebond suffit à exposer des droits étendus à des environnements moins sûrs.

Cette approche “tout-en-un” simplifie certes la vie des équipes IT, mais elle ouvre aussi grand la porte aux mouvements latéraux des attaquants.

Une compromission simplifiée

Pour illustrer le cas d’un mouvement latéral, prenons un exemple concret :

À la suite d’une infiltration réussie, un pirate désactive volontairement la carte son d’un poste utilisateur et infecte la machine. L’incident semble bénin, mais il nécessite l’intervention du support informatique, souvent à l’aide d’un compte doté de droits d’administration.

L’admin se connecte, le malware capture ses identifiants, et en quelques minutes, l’attaquant se retrouve en possession d’accès critiques au SI.

Derrière ce scénario anodin se cache une réalité bien connue des attaquants : le rebond via les sessions d’administration.

Lorsqu’un compte à privilèges s’authentifie sur une machine compromise, les informations d’identification (tickets Kerberos, hash NTLM ou jetons d’accès) peuvent être récupérées en mémoire à l’aide d’outils tels que Mimikatz ou Rubeus.

Une fois ces accès obtenus, l’adversaire peut se déplacer latéralement, créer des comptes persistants, désactiver les journaux d’audit… et, in fine, prendre le contrôle du domaine.

Ce type de violation peut démarrer à partir d’un incident mineur en apparence, comme un email de phishing.

Sans segmentation des privilèges ni postes d’administration dédiés, une seule erreur humaine suffit à ouvrir la voie à une prise de contrôle massive.

Comment configurer ses comptes administrateurs ?

Avant toute mise en place d’un modèle de Tiering, une gestion rigoureuse des comptes à privilèges est indispensable

L’objectif : que chaque compte ait un périmètre d’action clair, limité et maîtrisé.

Deux grandes familles coexistent dans un environnement Active Directory :

• Les comptes de domaine, qui disposent d’autorisations AD centralisées et permettent d’administrer des ressources distantes (serveurs, postes, etc.).
• Les comptes locaux, spécifiques à chaque machine, qui conservent des privilèges limités à ce périmètre.

LAPS : sécuriser les comptes locaux

LAPS (Local Administrator Password Solution) est la solution native de Microsoft pour gérer automatiquement les mots de passe des comptes administrateurs locaux.

Chaque machine dispose ainsi d’un mot de passe unique, régulièrement renouvelé. Cette rotation automatique empêche toute réutilisation d’un même mot de passe sur plusieurs postes, réduisant fortement le risque de propagation latérale.

LAPS est idéal pour les environnements où aucun droit Active Directory n’est requis, comme les stations de travail ou certains serveurs applicatifs. En revanche, il ne doit jamais être appliqué aux contrôleurs de domaine, qui relèvent du périmètre Tier 0.

Comptes de domaine : un usage à contrôler

Les comptes de domaine sont indispensables pour administrer un environnement Active Directory.

Ils sont utilisés pour gérer les serveurs, réaliser des migrations ou des déploiements, et intervenir sur des composants critiques.

Ces comptes ne devraient jamais être utilisés sur les postes utilisateurs.

Chaque action réalisée avec un compte de domaine doit être suivie et tracée : connexion, modification, changement de privilège.

Cible	Compte de domaine	Compte LAPS
Contrôleurs de domaine	✅	⛔
Serveurs	⚠️	✅
Stations de travail	⚠️	✅

Les recommandations de l’ANSSI

L’ANSSI préconise de séparer strictement les comptes selon leurs usages et leurs niveaux de privilèges.

Concrètement :

• Un compte par périmètre (poste de travail, serveurs, annuaire AD, etc.)
• Aucune connexion croisée entre les niveaux
• Des postes d’administration dédiés (PAW) pour limiter les risques d’exposition
• Et une traçabilité renforcée sur les actions menées par les comptes à privilèges

Plus de détails dans le guide de l’ANSSI.

Découpage des ressources dans un modèle de Tiering

Le modèle de Tiering repose sur une segmentation stricte des ressources et des comptes administratifs.

Chaque niveau (ou “Tier”) correspond à un périmètre d’administration et de sécurité bien défini :

Niveau	Ressources concernées	Exemple
Tier 0	Infrastructures critiques	Contrôleurs de domaine, serveurs AD, services d’authentification
Tier 1	Ressources métiers	Serveurs applicatifs, bases de données, outils de production
Tier 2	Environnements utilisateurs	Postes clients, imprimantes, périphériques

Cette hiérarchisation des privilèges empêche les comptes les plus puissants (Tier 0) d’intervenir sur des environnements moins sécurisés (Tier 1 ou 2), bloquant ainsi tout mouvement latéral ascendant.

Déployez sereinement un Tiering AD

Chez SNS Security, nous avons une maîtrise forte des environnements AD et des déploiements de Tiering Model.

Notre accompagnement se déroule en 4 temps forts :

1. Conception : Lors d’ateliers collaboratifs, nous définissons le modèle de Tiering adapté à votre organisation et préparons l’ensemble de la documentation technique.
2. Préparation : Nous déployons le modèle conçu et initions la restructuration de l’annuaire AD. Cela se fait sans impact : votre infrastructure existante reste intacte.
3. Pilote : À l’aide du cahier de recette, nous validons l’application du modèle de Tiering sur un périmètre restreint de votre environnement.
4. Migration : Suite à la validation du pilote, nous migrons le reste des ressources vers le modèle de Tiering, ressource par ressource.

Vous souhaitez commencer par un simple état des lieux de votre Active Directory ?

Nos équipes peuvent réaliser une cartographie complète des risques : vulnérabilités, configurations obsolètes ou mauvaises pratiques.