Tiering d'administration - Tier 0/1/2, PAW, Enterprise Access Model

Le Tiered Administration Model (ou simplement "tiering") est l'architecture fondamentale qui empêche qu'une compromission d'un poste utilisateur devienne une compromission du domaine entier. Publié par Microsoft en 2015 et évolué en Enterprise Access Model en 2021, il repose sur un principe simple mais radical : un credential qui administre l'infrastructure critique (Tier 0) ne doit jamais être exposé sur une machine qui peut l'être (Tier 1 ou Tier 2). Sans cette ségrégation, toutes les protections AD (Protected Users, Kerberos hardening, Defender for Identity) sont largement neutralisées. Ce guide explique le modèle en profondeur : les 3 tiers, la règle non-négociable, les Privileged Access Workstations (PAW), les contrôles techniques (Authentication Policies and Silos, Protected Users, Clean Source principle), l'évolution cloud avec Entra ID, et le plan de migration pour une organisation qui part de zéro.

1. Le problème que le tiering résout

1.1 L'attaque-type sans tiering

Scénario classique dans une organisation sans tiering, en 2026 :

1. Alice est Domain Admin. Elle utilise le même compte pour son travail quotidien et pour administrer le domaine.
2. Alice se connecte à sa workstation pour ouvrir son email, son browser, Slack, Teams.
3. Alice reçoit un email avec une pièce jointe Word vérolée (spearphishing documenté, APT28, APT29, Scattered Spider).
4. Macro malveillante exécutée → malware installé en user-mode sur sa workstation.
5. Alice lance plus tard une connexion RDP vers un DC pour une tâche admin.
6. Le malware observe le process, dump LSASS, récupère le hash NTLM ou le TGT Alice.
7. L'attaquant a maintenant un TGT Domain Admin.
8. Via DCSync, il récupère le hash krbtgt → Golden Ticket → persistance indéfinie.
9. Ransomware déployé via GPO, chiffrement total en quelques heures.

Cette chaîne de compromission est quasi-automatisable. NotPetya/Maersk 2017, Colonial Pipeline 2021, Uber 2022, CDK Global 2024 contiennent toutes ce motif (adapté).

1.2 Ce que le tiering empêche

Le tiering interrompt la chaîne en étape 6 : le credential Domain Admin n'existe pas sur la workstation d'Alice au moment où le malware tourne. Alice administre le domaine depuis une PAW dédiée, isolée, durcie. Le malware sur sa workstation standard n'a jamais accès à ses credentials de Tier 0.

C'est une défense architecturale : elle ne dépend pas du comportement d'Alice, de la vigilance anti-phishing, ou du succès de l'EDR. Elle fonctionne même si Alice se fait piéger, parce que le credential dangereux n'est pas là.

1.3 L'équation du tiering

• Sans tiering : un email piégé peut mener à Domain Admin en quelques heures.
• Avec tiering : un email piégé ne compromet que l'utilisateur individuel. Pas de pivot Tier 0.

Ce différentiel est massif. Le tiering est la mesure technique avec le plus grand ratio coût/impact dans l'écosystème AD.

2. Origine et évolution du modèle

2.1 Publication initiale (2015)

Microsoft publie le Tier model dans le cadre du "Securing Privileged Access" whitepaper. Contexte : multiplication des compromissions AD entreprise, émergence de Mimikatz (2011) rendant les attaques de credential theft triviales.

Le modèle original prescrit 3 tiers stricts et une série de mesures techniques pour les appliquer.

2.2 Enterprise Access Model (2021)

Microsoft publie le Enterprise Access Model qui évolue le tiering pour intégrer :

• Cloud (Microsoft 365, Entra ID, Azure).
• Applications métier critiques.
• Data plane (bases, stockage) distinct du control plane.

Le modèle devient moins strictement vertical et plus logique par plan de contrôle.

2.3 Disparition de l'ancien ESAE / Red Forest

Enhanced Security Administrative Environment (ESAE) ou "Red Forest" était une architecture Microsoft recommandée (2012-2020) consistant à créer une forêt AD dédiée pour l'administration. Microsoft a déprécié ESAE en 2021 au profit de l'Enterprise Access Model, plus léger.

Les organisations qui ont investi dans ESAE continuent à l'exploiter, mais les nouvelles implémentations ne suivent plus cette voie.

3. Les 3 tiers - définitions précises

3.1 Tier 0 - Forest Control Plane

Contient les ressources qui contrôlent l'identité et l'autorisation du domaine entier. Si un Tier 0 tombe, tout tombe.

Appartiennent au Tier 0 :

• Contrôleurs de domaine (DCs) : détiennent la base AD et les clés.
• Comptes admin du domaine : Enterprise Admins, Domain Admins, Schema Admins, Account Operators, Server Operators, Print Operators, Backup Operators.
• Compte krbtgt : clé de signature des TGTs Kerberos.
• CA racines d'une PKI AD CS qui émet des certificats pour authentification.
• Serveurs d'admin ATP / Defender for Identity / SCCM / SCOM qui ont des droits Tier 0.
• Systèmes de backup AD (si compromis, restauration d'un DC peut être détournée).
• PAW (Privileged Access Workstations) utilisées par les admins Tier 0.
• Solutions d'Identity Governance (SailPoint, Saviynt) avec droits AD.

Principe : peu d'actifs Tier 0, fortement protégés.

3.2 Tier 1 - Enterprise Servers

Contient les serveurs d'application et d'infrastructure : bases de données, serveurs de fichiers, applications métier, Exchange, SharePoint, middleware.

Appartiennent au Tier 1 :

• Serveurs de production (Windows Server).
• Admins Tier 1 : équipes opérationnelles qui administrent ces serveurs.
• Middleware et bases de données.
• Systèmes d'applications critiques sans droits AD Tier 0.

Les admins Tier 1 n'ont pas de droits sur le Tier 0 (pas Domain Admin).

3.3 Tier 2 - User Workstations

Contient les postes utilisateurs finaux : laptops, desktops, devices mobiles, applications bureautique, browsers, emails.

Appartiennent au Tier 2 :

• Workstations Windows 10/11 utilisateurs.
• Helpdesk accounts qui gèrent les users et leurs postes.
• Applications de productivité.

Les admins Tier 2 (helpdesk) n'ont pas de droits Tier 1 ou Tier 0.

3.4 Représentation schématique

        ╔══════════════════════════════════════╗
        ║  Tier 0 - Forest Control Plane       ║
        ║  DCs, krbtgt, DA, EA, PKI, PAW       ║
        ║  ─ Peu d'actifs, forte protection   ─ ║
        ╚══════════════════════════════════════╝
                        │
                        │ Trust unilatéral descendant
                        ▼
        ╔══════════════════════════════════════╗
        ║  Tier 1 - Enterprise Servers         ║
        ║  Serveurs d'app, middleware, DBs     ║
        ║  ─ Admins Tier 1 sans DA            ─ ║
        ╚══════════════════════════════════════╝
                        │
                        │
                        ▼
        ╔══════════════════════════════════════╗
        ║  Tier 2 - User Workstations          ║
        ║  Postes user, helpdesk, email        ║
        ║  ─ Admins locaux, pas de Tier 1/0   ─ ║
        ╚══════════════════════════════════════╝

4. La règle fondamentale

4.1 Formulation

Un credential Tier 0 ne doit JAMAIS être saisi, cached, ou exposé sur un système Tier 1 ou Tier 2. Un credential Tier 1 ne doit JAMAIS être saisi, cached, ou exposé sur un système Tier 2.

Directionnel : on peut monter (T2 vers T1 vers T0 via mécanismes contrôlés), jamais descendre.

4.2 Ce que "saisi sur" veut dire

• Ne pas logger en RDP / SSH / console sur un système de tier inférieur avec ce credential.
• Ne pas runner (RunAs) ce credential sur un système de tier inférieur.
• Ne pas cacher automatiquement ce credential (cached credentials, stored creds).
• Ne pas utiliser Kerberos delegation qui exposerait un TGT Tier 0 sur une machine Tier 1.

4.3 Pourquoi c'est si strict

Chaque fois qu'un credential est exposé sur une machine :

• Malware présent peut le dumper (Mimikatz, Rubeus).
• Process legitimately compromised peut être hijacké.
• Session token peut être volé (Pass-the-Ticket).
• Memory dump peut l'extraire.

Il suffit d'une seule exposition sur une machine compromise pour avoir la compromission complète.

4.4 Conséquence pratique

Un Domain Admin ne se connecte pas à sa workstation standard avec son compte DA. Il a deux comptes distincts :

• alice@example.com : compte user classique pour email, browser, Teams, etc.
• adm-alice@example.com : compte DA utilisé uniquement depuis une PAW dédiée pour administrer les DCs.

Cette séparation est non négociable dans un modèle tiered sérieux.

5. Privileged Access Workstation (PAW)

5.1 Définition

Une PAW est un poste de travail dédié exclusivement à l'administration Tier 0 (ou Tier 1 pour variantes). Caractéristiques :

• Hardware séparé du poste standard de l'administrateur.
• OS fortement durci (Windows 11 Enterprise, avec baseline sécurité).
• Nombre minimal d'applications autorisées (10-15 max : PowerShell, MMC, RSAT, RDP, Vault client, Teams optionnel).
• Pas de web browsing, pas d'email, pas de productivity suite.
• Isolation réseau : communication uniquement vers les DCs et les ressources Tier 0.
• Pas de local admin sur la PAW (le compte AD dédié T0 gère via delegation contrôlée).

5.2 Coût

• Hardware : 1500-3000 EUR par PAW selon gamme (laptop business durci ou desktop dédié).
• Software : Windows 11 Enterprise + Defender suite (inclus typiquement en licences entreprise).
• Ops : effort initial (setup, durcissement), maintenance régulière (patches, review).

Pour une organisation avec 10 admins Tier 0 : environ 25 000 EUR d'investissement initial + 10 000 EUR/an ongoing.

Impact sécuritaire : énorme. Le ratio coût/impact est imbattable.

5.3 Configuration PAW recommandée 2026

Hardware :

• TPM 2.0 obligatoire.
• Secure Boot activé.
• BitLocker pour chiffrement disque.
• Pas de périphériques USB non autorisés (whitelisting via GPO).

OS :

• Windows 11 Enterprise (pour Credential Guard, HVCI, Application Guard).
• Baseline Microsoft Security Baseline appliquée via GPO.
• Credential Guard activé (isole LSASS).
• HVCI (Hypervisor-protected Code Integrity) activé.
• Windows Defender avec cloud protection.
• AppLocker ou WDAC (Windows Defender Application Control) qui restreint les binaires exécutables à une allowlist signée.

Applications autorisées :

• Microsoft Remote Desktop.
• PowerShell 7.x signé.
• MMC avec snap-ins AD Users and Computers, DNS, DHCP, GPMC.
• RSAT (Remote Server Administration Tools).
• PAM client (CyberArk PACLI, Teleport CLI, etc.).
• Outils d'audit AD (PingCastle, ADRecon).
• Teams admin si autorisé (controversé).

Réseau :

• Accès uniquement vers DCs et ressources Tier 0 via ACLs réseau strictes.
• Pas d'accès internet direct.
• Mises à jour Windows via WSUS dédié Tier 0 ou proxy restreint.

5.4 Alternatives modernes

Pour organisations qui ne peuvent pas déployer des PAW physiques :

• Windows 365 Cloud PC dédié admin avec politique Zero Trust.
• Azure Virtual Desktop (AVD) configuré avec conditional access strict.
• Jump server durci accessible via bastion moderne (Teleport, Azure Bastion).
• Dedicated VM sur hyperviseur Tier 0 avec network isolation.

Moins isolé qu'une PAW physique, acceptable pour beaucoup d'organisations.

6. Contrôles techniques supportant le tiering

6.1 Comptes dédiés par tier

Chaque admin a autant de comptes que de tiers qu'il administre :

• alice : compte standard Tier 2.
• adm-alice-t1 : compte Tier 1 (si elle administre des serveurs).
• adm-alice-t0 : compte Tier 0 (si elle administre les DCs).

Les 3 comptes ont des passwords distincts (ou mieux, FIDO2 hardware tokens distincts).

6.2 Protected Users group

Windows Server 2012 R2+ propose le groupe Protected Users qui applique des restrictions fortes :

• Aucune NTLM authentication.
• Aucun cached credential.
• Aucun RC4 ou DES Kerberos (AES seulement).
• TGT réduit à 4 heures (vs 10 par défaut).
• Aucune Unconstrained Delegation possible.
• Aucune CredSSP delegation.

Tous les comptes admin Tier 0 doivent être membres. Souvent aussi les admins Tier 1 sensibles.

Attention compatibilité : certains outils legacy peuvent casser. Tester avant déploiement large.

6.3 Authentication Policies and Silos

Windows Server 2012 R2+ permet de définir des policies qui restreignent où un user peut s'authentifier et quels services il peut utiliser.

Exemple : un compte adm-alice-t0 ne peut se loguer QUE sur :

• Les DCs du domaine.
• Les PAW dédiées Tier 0.

Et NE PEUT PAS se loguer sur les workstations standard ou les serveurs Tier 1.

Configuration :

# Créer le silo Tier 0
$silo = New-ADAuthenticationPolicySilo -Name "T0-Silo" -Enforce
 
# Créer la policy
$policy = New-ADAuthenticationPolicy -Name "T0-Policy" `
  -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(Member_of_any {SID(...)}))" `
  -Enforce
 
# Associer la policy au silo
Set-ADAuthenticationPolicySilo -Identity $silo -UserAuthenticationPolicy $policy
 
# Ajouter les users et computers
Grant-ADAuthenticationPolicySiloAccess -Identity $silo -Account "adm-alice-t0"
Grant-ADAuthenticationPolicySiloAccess -Identity $silo -Account "PAW-01$"
Grant-ADAuthenticationPolicySiloAccess -Identity $silo -Account "DC-01$"

Les Silos sont l'outil le plus puissant pour enforcer le tiering au niveau AD.

6.4 Logon Restrictions via GPO

GPO User Rights Assignment qui restreint qui peut se loguer sur quelles machines :

• Deny log on locally sur les workstations standards pour les admins Tier 0.
• Deny log on through Remote Desktop Services idem.
• Deny log on as a batch job / Deny log on as a service pour prévenir abus.

Configuration via GPO appliqué par OU de machines selon leur tier.

6.5 Clean Source principle

Un système à un tier donné ne doit dépendre que de ressources du même tier ou supérieur. Exemple :

• Un DC (Tier 0) ne doit pas dépendre d'un serveur middleware Tier 1 pour son fonctionnement.
• Un serveur Tier 1 ne doit pas faire confiance à une workstation Tier 2 pour l'intégrité de son installation.

Conséquence pratique :

• Source de boot OS : les DC doivent être installés depuis des images signées Microsoft, pas depuis un partage Tier 2.
• Build pipelines : une CI/CD qui produit un binaire déployé sur Tier 0 doit elle-même être Tier 0.
• Monitoring tools : un SIEM qui reçoit des logs de DCs doit être traité comme Tier 0 (a potentiellement des informations sensibles + droits RPC).

6.6 Just-in-Time access

Idéalement, les droits d'admin ne sont pas permanents. Un admin active son rôle T0 à la demande, pour une durée limitée (1-8 heures), avec justification.

Outils :

• Azure PIM (Privileged Identity Management) pour Entra ID.
• Microsoft Entra Privileged Access Management pour AD on-prem (moins mature).
• Teleport pour infrastructure.
• CyberArk / BeyondTrust pour PAM enterprise.

Voir sécurité des comptes privilégiés pour le détail PAM / JIT.

6.7 MFA phishing-resistant

Tous les comptes admin :

• MFA obligatoire.
• FIDO2 hardware key (YubiKey, Google Titan, Feitian) préférée sur authenticator app.
• SMS / email OTP interdits (vulnérables SIM swap et phishing).

7. Enterprise Access Model (2021) - l'évolution

7.1 Pourquoi le modèle a évolué

Le modèle 3-tier pur était adapté à l'ère AD-centric. Avec le cloud, SaaS, applications métier modernes :

• Beaucoup de ressources critiques ne sont plus dans AD (Microsoft 365 tenant, AWS account, SaaS apps).
• Le control plane devient multi-cloud (Entra ID + AWS IAM + GCP IAM + SaaS).
• La data plane (données métier) est distincte du control plane.

7.2 Les "planes" de l'Enterprise Access Model

Au lieu de tiers verticaux, le modèle 2021 structure par plans de contrôle :

• Privileged Access : admins avec privilèges élevés (ex-Tier 0/1).
• Control Plane : contrôle des ressources (Entra ID, AD, Azure subscriptions).
• Management Plane : gestion des workloads (orchestration, déploiement).
• Data Plane : accès aux données métier.
• App Plane : accès aux applications.
• User Access : accès utilisateur standard.

Chaque plan a ses propres contrôles, et les accès entre plans sont contrôlés.

7.3 Mapping avec le Tier Model classique

Le modèle 2021 est plus précis mais repose sur les mêmes principes : séparation stricte, pas d'exposition cross-plan descendante.

8. Tiering dans le cloud et hybride

8.1 Entra ID et rôles cloud

Entra ID a ses propres rôles privilégiés :

• Global Administrator : équivalent cloud de Domain Admin. Microsoft recommande maximum 5 par tenant.
• Privileged Authentication Administrator.
• Security Administrator.
• Conditional Access Administrator.
• User Access Administrator sur Azure subscriptions.

Ces comptes sont Tier 0 cloud et méritent les mêmes protections :

• Comptes dédiés (gadm-alice@example.com).
• Azure PIM pour activation JIT.
• MFA FIDO2 obligatoire.
• Activation depuis une PAW ou Cloud PC dédié.
• Break-glass accounts (2 comptes hors PIM, credentials en coffre).

8.2 Articulation on-prem + cloud

Avec un environnement hybride (AD + Entra ID synchronisé via Entra Connect) :

• Un admin Domain Admin on-prem N'EST PAS automatiquement Global Admin cloud.
• Entra Connect peut synchroniser les comptes mais les rôles cloud sont indépendants.
• Certaines orgs créent des compartiments séparés : comptes cloud-native pour admin cloud, comptes on-prem pour admin AD.

8.3 Les nouveaux risques cloud

• Compromission tenant via phishing OAuth, consent phishing.
• Compromission Entra Connect → synchronisation bidirectionnelle potentielle.
• Tokens OAuth volés via infostealer → accès sans MFA.

Mitigations :

• Conditional Access avec device compliance.
• ITDR cloud (Microsoft Defender for Identity + XDR Azure).
• Protection OAuth apps.
• Monitoring Entra Audit Logs.

9. Pièges et erreurs fréquentes

9.1 Tiering "sur le papier" mais pas appliqué

Organisation qui documente le modèle mais où les admins continuent à se connecter aux DCs depuis leur poste standard "pour les urgences". Tiering faux = pas de bénéfice réel.

Mitigation : enforcement technique via Authentication Policies and Silos, pas juste policy documentaire.

9.2 Confusion Tier 0 / Tier 1

"On traite ce serveur de backup comme Tier 1." Mais ce serveur a les droits pour restaurer les DCs → il est en réalité Tier 0.

Mitigation : audit rigoureux des droits et capabilities avant classification.

9.3 Admins Tier 0 qui ont besoin de surfer le web

"Alice doit consulter la doc Microsoft pour résoudre un problème Kerberos." Mais la PAW n'a pas de browser.

Mitigation :

• Pattern : la doc est consultée depuis le poste standard, la commande est exécutée depuis la PAW.
• Outils : privileged access bastions (Teleport) qui permettent des sessions avec contexte limité.

9.4 Outils d'admin qui dépendent du Tier 2

SCCM, outils de monitoring, Ansible Tower, Chef, Puppet qui ont des agents sur les DCs et qui sont eux-mêmes installés sur des serveurs Tier 1 ou Tier 2 → le serveur d'outils devient implicitement Tier 0.

Mitigation :

• Soit le serveur d'outils est Tier 0 (traité comme tel).
• Soit il est séparé (instance dédiée T0 + instance dédiée T1/T2).

9.5 ESAE legacy non maintenu

Organisations qui ont déployé ESAE (Red Forest) entre 2014 et 2020 et continuent à l'exploiter. Microsoft a déprécié ESAE en 2021.

Mitigation :

• Maintenir ESAE tant qu'il fonctionne, pas d'urgence à démanteler.
• Pour nouvelles implémentations : Enterprise Access Model plus léger.

9.6 Trop peu de comptes, trop de droits

Alice est Domain Admin. Elle utilise ce compte pour administrer les DCs, les serveurs, les workstations, consulter les logs. Elle a 50 droits cumulés.

Mitigation : principe du moindre privilège par activité. Alice DOIT avoir plusieurs comptes, chacun avec un scope minimal.

9.7 Break-glass accounts mal gérés

Le modèle exige des break-glass accounts pour cas d'urgence (IdP down, PIM indisponible). Mais beaucoup d'organisations :

• N'en créent pas.
• Ne les testent jamais.
• Les utilisent en routine "parce que plus facile".

Mitigation :

• 2-3 break-glass Tier 0.
• Credentials en coffre physique, scellés.
• Monitoring alerting immédiat en cas d'usage.
• Drill annuel de validation.

10. Plan de migration - démarrer d'un AD sans tiering

10.1 Mois 1-3 - Préparation et baseline

• Audit : PingCastle, Purple Knight pour identifier les violations actuelles du tiering.
• Inventory des comptes admin, des serveurs, des workstations.
• Classification : chaque machine est Tier 0, 1 ou 2 ?
• Design : plan de comptes par admin (1 compte par tier administré).
• PAW : commande hardware, setup initial.

10.2 Mois 4-6 - Tier 0 en priorité

• Création des comptes adm-*-t0 pour chaque admin.
• Migration des comptes DA existants : retrait du privilège quotidien, usage via adm-t0 uniquement.
• Déploiement des PAWs.
• Protected Users group : ajout des comptes T0.
• Authentication Policies et Silos T0 créés et appliqués.
• GPOs de Deny log on pour T0 sur workstations standard.
• Break-glass accounts créés et testés.

10.3 Mois 7-9 - Tier 1 déploiement

• Création des comptes adm-*-t1 pour les admins d'infrastructure serveurs.
• Silos Tier 1 avec restriction d'auth.
• Retrait des droits Domain Admin des équipes ops qui n'en ont pas besoin.
• Jump servers ou bastion pour accès T1 depuis postes standard.

10.4 Mois 10-12 - Refinements et cloud

• Alignement avec Entra ID si environnement hybride.
• Break-glass accounts Entra ID.
• Azure PIM activé pour rôles cloud sensibles.
• Formation équipes : processus quotidien avec tiering.
• Runbooks d'incident response adaptés au tiering (comment agir en urgence sans casser le modèle).

10.5 Mois 12+ - Maintien

• Audit trimestriel PingCastle / Purple Knight.
• Red team exercises pour valider.
• Revue des comptes privilégiés.
• Rotation PAW hardware tous les 3-5 ans.
• Formation continue.

11. Mesurer la maturité du tiering

11.1 Indicateurs clés

11.2 Outils d'audit

• PingCastle (gratuit, Vincent Le Toux) : audit AD avec scores de maturité incluant le tiering.
• Purple Knight (Semperis) : misconfigurations AD y compris tiering.
• Semperis DSP : monitoring runtime.
• BloodHound : cartographie des chemins d'attaque, révèle les violations de tiering implicites.
• Microsoft Assessment Planning Toolkit.

11.3 Red team validation

Exercice red team avec objectif : "Depuis un user standard phishé, atteindre Domain Admin en moins de X heures". Un tiering mature allonge drastiquement ce délai ou le rend impossible sans compromission physique.

12. Checklist tiering

Architecture

• Les 3 tiers (ou planes 2021) formellement définis
• Chaque serveur et machine classifiée dans son tier
• ESAE retiré ou maintenu selon contexte

Comptes

• Comptes dédiés par tier pour chaque admin
• Nombre de Domain Admin réduit au strict minimum
• Break-glass accounts configurés et testés

Protections techniques

• Protected Users group avec tous admins T0
• Authentication Policies et Silos déployés
• GPOs Deny log on pour empêcher cross-tier
• NTLM désactivé pour admins T0
• FIDO2 pour admins T0

Privileged Access Workstations

• PAW physique ou Cloud PC par admin T0
• AppLocker / WDAC strict
• Credential Guard + HVCI activés
• Isolation réseau vers T0 uniquement
• Browser et email absents

Cloud et hybride

• Entra ID rôles classifiés
• Azure PIM pour activation JIT
• Conditional Access avec device compliance
• Break-glass Entra ID

Monitoring

• Defender for Identity sur DCs
• Sysmon avec forwarding SIEM
• Audit PingCastle trimestriel
• Alertes sur violations du tiering
• Red team annuel

Processus

• Runbooks incidents adaptés au tiering
• Formation admins sur tiering quotidien
• Rotation PAW planifiée
• Revue access trimestrielle

13. Verdict et posture Zeroday

Le tiering d'administration est la mesure architecturale la plus efficace pour protéger un environnement Active Directory. Son absence rend stérile tous les autres investissements (Kerberos hardening, Defender for Identity, patching). Sa présence architecturale fait la différence entre "compromission évitable" et "compromission quasi-certaine" lors d'une campagne ransomware ou APT.

Pour un administrateur AD : le tiering demande discipline (utiliser le bon compte au bon moment) et investissement initial (PAW, configurations, migration). Les gains sécuritaires sont proportionnels à la rigueur d'application.

Pour un RSSI : l'investissement tiering est l'un des plus rentables du budget AD. Le ROI se mesure en compromissions évitées - difficile à quantifier mais massif quand on le compare aux coûts de recovery post-incident NotPetya-style.

Pour une organisation sans tiering : démarrer la migration maintenant, par le Tier 0 en priorité. Chaque mois de retard augmente la probabilité d'une compromission qui aurait pu être évitée.

Pour approfondir : Kerberos expliqué pour les attaques que le tiering bloque, sécurité des comptes privilégiés pour l'articulation avec PAM/JIT, least privilege en pratique pour le principe de moindre privilège, pourquoi l'identité est centrale en cybersécurité pour le contexte stratégique, qu'est-ce qu'un spécialiste Active Directory Security pour le parcours métier qui porte ces chantiers.