RSE

Le Tiering Model Active Directory : La barrière qui sépare une compromission locale d’une catastrophe totale

Aujourd’hui la sécurité repose grandement sur les identités. Dans 95 % des cyberattaques ciblant les entreprises, l’Active Directory est la cible finale. Une fois maître de l’annuaire, l’attaquant obtient les clés du royaume : il peut se déplacer latéralement, extraire des secrets, déployer des ransomwares et effacer les traces. Pourtant, la très grande majorité de ces compromissions ne repose pas sur une faille zero-day sophistiquée, mais sur une erreur d’architecture élémentaire et évitable : l’absence totale ou le manque de cloisonnement de l’Active Directory.

C’est précisément là qu’intervient le Tiering Model (modèle en couches). Bien plus qu’une simple configuration technique, c’est une approche de sécurité défensive qui empêche la compromission totale à partir d’un poste de travail infecté ou d’un serveur compromis.

 

Qu’est-ce que le tiering?

Le Tiering repose sur une règle d’or absolue, théorisée par Microsoft et fortement recommandée par l’ANSSI :

Un compte à privilège élevé ne doit jamais exposer ses identifiants (mot de passe, hash NTLM, ticket Kerberos) sur une machine de niveau de confiance inférieur.

En clair : l’administrateur du domaine (le plus haut privilège) ne se connecte jamais sur un poste de travail standard ou sur un serveur applicatif. S’il le fait, même une seule fois, tout l’Active Directory peut tomber en quelques minutes via un simple credential dumping (Mimikatz, Rubeus, etc.).

 

L’utilité concrète : ce que le Tiering empêche vraiment

Sans Tiering, le scénario d’attaque le plus courant (LockBit, Conti, Ryuk, BlackCat…) se déroule en 4 étapes :

  1. Un utilisateur ouvre une pièce jointe piégée → son poste (Tier 2) est infecté.
  2. Un administrateur du domaine (Tier 0) se connecte sur ce poste pour « réparer » ou installer un logiciel.
  3. Le malware présent sur le poste aspire la mémoire LSASS → il vole le hash NTLM ou le ticket Kerberos de l’administrateur.
  4. L’attaquant réinjecte ce ticket sur un contrôleur de domaine → il possède l’Active Directory entier.

 

Avec le Tiering correctement implémenté, l’étape 2 est impossible: Le compte Admin Tier 0 est techniquement interdit de connexion sur le poste infecté. Même si le malware est présent, il n’obtient jamais les privilèges suprêmes.

Résultat : l’attaquant reste bloqué au niveau 2. Il peut voler des données locales, mais pas escalader vers le domaine entier.

 

Le modèle en détail : les trois tiers et leurs règles 

La règle est simple et implacable :

  • Un compte Tier N ne se connecte QUE sur des machines de niveau N ou inférieur
  • Un compte Tier 0 ne touche jamais un poste Tier 2, même pour « aider un utilisateur ».

Tier 0 – Administration de l’identité

Zone critique absolue. Sa compromission signifie compromission totale du SI.

  • Actifs : DCs, PKI, ADFS, Entra ID Connect, serveurs de backup AD.
  • Comptes : Domain Admins, Enterprise Admins, Schema Admins, Key Admins, etc. – Règle absolue : ces comptes ne se connectent QUE sur des machines Tier 0 (PAW ou jump servers sécurisés).

 

Tier 1 – Serveurs applicatifs

Zone de production sensible.

  • Actifs : serveurs SQL, Exchange, ERP, fichiers, web.
  • Comptes : administrateurs serveurs, comptes de service critiques.
  • Règle : un compte Tier 1 n’a aucun droit sur les DCs (Tier 0) et ne se connecte pas sur les postes utilisateurs (Tier 2). Ce tier peut contenir des silos isolant la data du processing de l’infrastructure etc.

 

Tier 2 – Postes de travail et zone exposée

Zone « à haute entropie » et exposée →  Internet, e-mails, USB, phishing.

  • Actifs : Windows 10/11, imprimantes, terminaux mobiles.
  • Comptes : helpdesk, support de proximité, utilisateurs standards.
  • Règle : un compte Tier 2 peut prendre la main sur un poste, mais jamais sur un serveur ou un DC.

Mise en œuvre pratique : les étapes incontournables

La mise en place du  tiering repose sur 4 grandes étapes

1. Séparer les comptes et les machines en 3 zones protégées. Prenons l’analogie d’une pyramide avec 3 étages bien cloisonnés :

  • Haut de la pyramide (Tier 0) : les « super-administrateurs » et les machines les plus critiques (contrôleurs de domaine, PKI, Entra ID Connect…).
  • Milieu (Tier 1) : les serveurs importants (SQL, ERP, fichiers…).
  • Bas (Tier 2) : les ordinateurs de tous les jours (PC, imprimantes…).

Objectif : personne du haut ne descend jamais au bas de la pyramide.

 

2. Mettre à dispositionde chaque personne deux (voire trois) comptes

  • Un compte « utilisateur » pour les accès standards
  • Un compte « administrateur» uniquement pour administrer les serveurs et l’AD, sur la base du « least privilege »
  • (Idéalement) Un compte  « super administrateur » pour les tâches les plus critiques (ex. : ajout d’un contrôleur de domaine).

C’est comme avoir une clé de maison et une clé de coffre-fort : on ne mélange jamais les deux.

 

3. Bloquer les connexions interdites (la règle qui sauve tout) On utilise des règles simples (des « interdits automatiques ») pour empêcher :

  • Un super-administrateur de se connecter sur un PC normal.
  • Un administrateur serveur de se connecter sur un contrôleur de domaine.

Résultat : même si un virus infecte un PC, il ne peut pas voler les clés du haut de la pyramide.

 

4. Créer une « tour de contrôle » sécurisée (la PAW/rebond durci). Pour que les super-administrateurs puissent travailler sans risque, on leur met à disposition un poste dédié :

  • Pas connecté à Internet.
  • Pas de Word, Excel ou navigateur.
  • Seulement les outils pour gérer l’AD.
  • Protégé par une double authentification forte (clé USB Fido2 ou carte).

C’est comme un cockpit d’avion : on n’y entre que pour piloter, pour des opérations sensibles et uniquement celles-ci, et non pour des actions courantes.

 

Conclusion

Le Tiering n’est pas une option technique parmi d’autres. C’est la seule barrière efficace contre la compromission totale à partir d’un poste de travail compromis.

Le Tiering Model n’est pas une alternative au Zero Trust : c’est l’application la plus mature et la plus efficace du Zero Trust sur le plan de contrôle des identités et des privilèges.

Il transforme le principe abstrait « Never trust, always verify » en une règle technique concrète et vérifiable : aucun compte critique ne doit jamais s’exposer sur une zone de confiance inférieure.

Sa mise en œuvre demande du temps, de la rigueur et un accompagnement adapté.

Mais le retour sur investissement en résilience est inestimable : on passe d’un risque de « tout perdre en 30 minutes » à un risque contenu et maîtrisable.

Cet article s’appuie sur les recommandations de l’ANSSI (Recommandations de sécurité relatives à l’Active Directory – 2023) et sur le cadre « Securing Privileged Access » de Microsoft.

DERNIÈRES PUBLICATIONS

Le Tiering Model Active Directory : La barrière qui sépare une compromission locale d’une catastrophe totale

Aujourd’hui la sécurité repose grandement sur les identités. Dans 95 ...

Les coulisses d’un test d’intrusion matériel : Le rapport d’audit et la communication des résultats

Billet de blog 2 #5 Chaque campagne d’audit matériel se ...

Développer son propre BIOS UEFI sécurisé ? Oui c’est possible aujourd’hui !

Introduction Le BIOS est une interface relativement connue. Ce fameux ...