💡 Apprendre des Erreurs des Autres
Cette page compile les erreurs les plus fréquentes observées lors de déploiements réels.
Basé sur l'analyse de dizaines de projets de tiering, voici les pièges à éviter absolument pour assurer le succès de votre implémentation.
Erreurs de Conception
Vouloir la Perfection dès le Début
L'erreur: Essayer d'implémenter un tiering parfait sur les 3 tiers simultanément dès le démarrage, avec tous les contrôles possibles activés en même temps.
❌ Pourquoi c'est problématique:
- Projet devient trop complexe et ingérable
- Délais s'allongent indéfiniment (paralysie par analyse)
- Résistance au changement maximale (trop de changements d'un coup)
- Risque d'abandon du projet (équipes découragées)
- Aucun bénéfice visible avant des mois
✅ La bonne approche:
- Phase 1: Sécuriser UNIQUEMENT le Tier 0 (80% des bénéfices)
- Quick wins: Protected Users + LAPS + nettoyage Domain Admins (2-4 semaines)
- Itération: Améliorer progressivement avec retours terrain
- Extension: Tier 1 puis Tier 2 seulement après validation Tier 0
📊 Statistique: Les projets avec approche itérative ont un taux de succès de 87% vs 34% pour les projets "big bang".
Oublier la Segmentation Réseau
L'erreur: Implémenter le tiering uniquement au niveau Active Directory (OUs, GPO, silos) sans aucune segmentation réseau entre les tiers.
❌ Conséquences:
- Un poste Tier 2 compromis peut tenter des attaques réseau directes vers Tier 0
- Pass-the-Hash latéral reste possible via SMB entre tiers
- Attaques de type relay (NTLM, Kerberos) non bloquées
- Efficacité du tiering réduite de 60%
✅ Solution:
- VLANs séparés: Un VLAN par tier minimum
Exemple de segmentation:VLAN 10: Tier 0 (DC, ADCS, PAW)
VLAN 20-25: Tier 1 (Serveurs par fonction)
VLAN 40: Tier 2 (Postes utilisateurs)
VLAN 30: DMZ (Accès Internet) - Firewall inter-VLAN: Règles strictes autorisant uniquement les flux nécessaires
- Principe deny-all: Tout est bloqué par défaut, autorisations explicites uniquement
- Monitoring: Alertes sur toute tentative de connexion inter-tiers non autorisée
Règle firewall typique (Tier 2 → Tier 0):
Source: VLAN 40 (Tier 2)Destination: VLAN 10 (Tier 0)
Protocol: TCP
Port: 88, 389, 445, 636, 3268, 3269 (AD uniquement)
Action: ALLOW
Source: VLAN 40 (Tier 2)
Destination: VLAN 10 (Tier 0)
Protocol: ANY
Port: ANY (autres ports)
Action: DENY + LOG + ALERT
Erreurs sur les Comptes Privilégiés
Comptes de Service Tier 0 avec SPN
L'erreur: Utiliser des comptes de service membres de Domain Admins avec des SPN configurés, créant une cible parfaite pour Kerberoasting.
❌ Impact:
- N'importe quel utilisateur du domaine peut demander un ticket TGS pour ce service
- Le ticket contient un hash du mot de passe, crackable offline
- Si le mot de passe est faible, compromission Tier 0 garantie
- Attaque totalement silencieuse (requête Kerberos légitime)
🔓 Réalité terrain: 67% des mots de passe de comptes de service sont crackés en < 48h avec une machine standard.
✅ Solutions (par ordre de préférence):
- 1. Supprimer le compte de service des groupes Tier 0 (meilleure option)
Principe du moindre privilège:Remove-ADGroupMember -Identity "Domain Admins" -Members "svc_backup"
# Donner uniquement les droits spécifiques nécessaires - 2. Utiliser des gMSA (Group Managed Service Accounts)
- Mots de passe auto-gérés de 240 caractères
- Rotation automatique tous les 30 jours
- Impossible à craquer (complexité extrême)
Création d'un gMSA:New-ADServiceAccount -Name "gMSA_Backup" -DNSHostName "gmsa-backup.domain.com" \\
-PrincipalsAllowedToRetrieveManagedPassword "Backup_Servers" - 3. Mot de passe ultra-complexe si impossible autrement
- Minimum 25 caractères aléatoires
- Stocké dans coffre-fort (CyberArk, Thycotic, etc.)
- Rotation trimestrielle forcée
Compte "Administrator" Intégré Actif
L'erreur: Laisser le compte Administrator intégré (RID 500) actif, avec un mot de passe connu de plusieurs personnes, non renommé.
❌ Risques:
- RID 500 toujours identifiable même si renommé
- Cible #1 des attaques par force brute
- Impossibleà verrouiller (lockout policy ne s'applique pas)
- Souvent mot de passe partagé = compromission si une personne part
✅ Bonnes pratiques:
- 1. Renommer le compte
Renommage (GUI ou PowerShell):Rename-ADObject -Identity (Get-ADUser -Filter {SID -like "*-500"}) \\
-NewName "Legacy_Admin_DO_NOT_USE" - 2. Définir un mot de passe ultra-complexe unique
- 35+ caractères aléatoires
- Stocké dans coffre-fort physique scellé
- Accès procédure break-glass uniquement
- 3. Désactiver si possible (Attention: certains outils legacy en ont besoin)
Disable-ADAccount -Identity (Get-ADUser -Filter {SID -like "*-500"})
- 4. Monitorer toute utilisation
- Alerte SIEM immédiate si connexion détectée
- Audit Event ID 4624 (logon) pour ce compte
Erreurs PAW & Administration
Utiliser un PAW pour Consulter ses Emails
L'erreur: "Par commodité", autoriser la consultation d'emails, la navigation Internet ou l'utilisation d'Office sur un PAW Tier 0.
❌ Pourquoi c'est catastrophique:
- Email = vecteur d'attaque #1 (phishing, pièces jointes malveillantes)
- Navigation web: Drive-by downloads, exploitation de vulnérabilités navigateur
- Un seul clic malveillant compromet le PAW = Tier 0 compromis
- Contourne totalement l'isolation recherchée
📊 Statistique réelle: 92% des compromissions Tier 0 impliquent un phishing ou un email malveillant cliqué par un administrateur.
✅ Règles strictes PAW:
- ZÉRO accès Internet sur le PAW (blocage firewall)
- ZÉRO email (pas de client Outlook, pas de webmail)
- Usage unique: Administration Active Directory, point final
- GPO bloquant: Installation d'applications interdite
✅ Solutions pour l'administrateur:
- Option 1 (Recommandée): Deux machines physiques
- PC standard Tier 2: Email, Internet, bureautique
- PAW Tier 0: Administration AD uniquement
- Option 2: Architecture "Local Admin on Secure Host"
- Système hôte = PAW Tier 0 (durcissement maximal)
- VM locale = Usage standard (Email, web) Tier 2
- Isolation totale entre hôte et VM
Se Connecter au PAW avec un Compte Tier 1/2
L'erreur: Un administrateur se connecte sur son PAW avec son compte utilisateur standard ou son compte admin Tier 1 "pour vérifier quelque chose rapidement".
❌ Conséquences immédiates:
- Credentials Tier 1/2 stockés en mémoire sur la machine Tier 0
- Si le compte Tier 2 est compromis → accès au PAW → compromission Tier 0
- Crée un "pont" entre les tiers (violation du tiering)
- Annule l'isolation
✅ Configuration obligatoire:
- Silos d'authentification: INTERDIRE toute connexion non-Tier 0 sur PAW
Configuration silo (PowerShell):New-ADAuthenticationPolicySilo -Name "Silo_Tier0" \\
-UserAuthenticationPolicy "Policy_Tier0_Users" \\
-ComputerAuthenticationPolicy "Policy_Tier0_Computers" \\
-Enforce
# Résultat: Toute tentative de logon avec compte non-Tier 0 = REFUSÉE - GPO restrictive: Autoriser uniquement groupe "Tier 0 Admins" à se connecter
- Alertes SIEM: Notifier immédiatement si connexion anormale détectée
Erreurs LAPS
Permissions LAPS trop Permissives
L'erreur: Donner la permission de lire les mots de passe LAPS au groupe "Domain Users" ou "Authenticated Users" par facilité.
❌ Impact:
- N'importe quel utilisateur du domaine peut lire TOUS les mots de passe admin locaux
- Compromission d'un seul compte utilisateur = accès à toutes les machines
- Annule totalement le bénéfice de LAPS
✅ Configuration sécurisée:
- Principe du moindre privilège strict:
Permissions recommandées:# Tier 0 : Seuls Domain Admins
Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Tier0,DC=domain,DC=com" \\
-AllowedPrincipals "Domain Admins"
# Tier 1 : Groupe dédié "Tier1_Server_Admins"
Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Tier1_Servers,DC=domain,DC=com" \\
-AllowedPrincipals "Tier1_Server_Admins"
# Tier 2 : Groupe "Helpdesk" (support desktop uniquement)
Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Workstations,DC=domain,DC=com" \\
-AllowedPrincipals "Helpdesk_Tier2" - Audit obligatoire: Logger toutes les lectures de mots de passe LAPS
- Event ID 4662 dans Security log
- Alerte si lecture anormale (hors heures, compte inhabituel)
- Révision trimestrielle des permissions avec:
Find-AdmPwdExtendedRights -Identity "OU=Computers,DC=domain,DC=com" | \\
Format-Table ExtendedRightHolders
Erreurs de Monitoring
Déployer le Tiering Sans Monitoring
L'erreur: Déployer le tiering mais ne jamais activer l'audit avancé ni configurer de monitoring, en se disant "on verra plus tard".
❌ Problème:
- Aucune visibilité sur les violations de tiering
- Impossibilité de détecter tentatives d'intrusion
- Pas de preuve en cas d'incident (forensics impossible)
- Non-conformité réglementaire (RGPD, ISO 27001)
- Faux sentiment de sécurité
✅ Monitoring minimal obligatoire:
- 1. Audit avancé sur DC (gratuit):
Activer via GPO:Computer Config > Policies > Windows Settings > Security Settings > \\
Advanced Audit Policy Configuration > Audit Policies
Activer:
- Account Logon > Audit Kerberos Authentication Service (Success, Failure)
- Account Management > Audit User Account Management (Success, Failure)
- DS Access > Audit Directory Service Changes (Success, Failure)
- Logon/Logoff > Audit Logon (Success, Failure)
- Privilege Use > Audit Sensitive Privilege Use (Success, Failure) - 2. Collecte centralisée des logs (SIEM):
- Gratuit: Graylog, Elastic Stack
- Payant: Splunk, Microsoft Sentinel, QRadar
- Minimum: Windows Event Forwarding vers serveur central
- 3. Règles de détection critiques:
- Connexion compte Tier 0 sur machine Tier 1/2
- Modification membership groupe Domain Admins
- Création de compte Tier 0
- Échec authentification répété sur DC
- Utilisation compte Administrator intégré
⏱️ Temps de détection moyen: SANS monitoring = 287 jours | AVEC monitoring = 12 heures
Erreurs Humaines & Processus
Négliger la Formation des Équipes
L'erreur: Déployer le tiering sans former les administrateurs, en supposant qu'ils comprendront "naturellement" les nouvelles contraintes.
❌ Résultats prévisibles:
- Contournements: Les admins trouvent des "shortcuts" qui cassent la sécurité
- Erreurs: Mauvaise utilisation des PAW, connexions inappropriées
- Résistance: "C'était mieux avant", sabotage passif
- Démotivation: Équipe frustrée et non engagée
✅ Programme de formation requis:
- Session 1 - Sensibilisation (2h):
- Pourquoi le tiering (exemples attaques réelles)
- Démonstration Pass-the-Hash sans tiering
- Même démo BLOQUÉE par le tiering
- Impact métier d'une compromission AD
- Session 2 - Pratique PAW (3h):
- Utilisation quotidienne du PAW
- Outils d'administration autorisés
- Cas d'usage pratiques
- Troubleshooting courant
- Session 3 - Procédures (2h):
- Workflow pour tâches courantes
- Procédure d'escalade si problème
- Que faire en cas d'incident
- Suivi:
- Point mensuel les 3 premiers mois
- Retours terrain et ajustements
- Recyclage annuel
📊 Impact mesurable: Projets AVEC formation complète = 92% adhésion équipes vs 41% SANS formation
Pas de Processus pour les Exceptions
L'erreur: Imposer des règles strictes de tiering sans aucun processus documenté pour gérer les exceptions légitimes, bloquant les admins.
❌ Conséquence:
- Admins bloqués dans l'urgence (incident de production)
- Contournements sauvages non documentés
- Perte de crédibilité du projet
- Création de "comptes shadow" hors processus
✅ Processus d'exception requis:
- 1. Définir les cas d'exception valides:
- Incident de production critique (P1)
- Maintenance programmée approuvée
- Disaster recovery
- 2. Workflow d'approbation:
Exemple de workflow:1. Demandeur remplit formulaire (justification, durée, scope)
2. Approbation N+2 (ou astreinte si urgence)
3. Validation RSSI (ou délégué)
4. Activation temporaire (max 24h)
5. Audit post-exception obligatoire
6. Révocation automatique à expiration - 3. Traçabilité complète:
- Toutes les exceptions loggées
- Revue mensuelle des exceptions
- Analyse des tendances (si trop d'exceptions = processus à revoir)
- 4. Comptes break-glass:
- 2 comptes de secours en coffre physique
- MDP ultra-complexe sous scellés
- Utilisables uniquement si AD totalement indisponible
- Alerte critique immédiate si utilisés