Sécurité des comptes privilégiés - PAM, JIT, break-glass

Les comptes privilégiés sont les clés du royaume : Domain Admin, root production, super-admin cloud, DBA, super-utilisateur applicatif. Leur compromission équivaut à la compromission totale du système qu'ils contrôlent. La majorité des incidents cyber majeurs des 10 dernières années - NotPetya, Maersk, SolarWinds, Colonial Pipeline, Uber - impliquent la compromission d'un compte privilégié à un moment ou un autre de la chaîne d'attaque. Ce guide détaille les typologies, les risques spécifiques, les contre-mesures (PAM, JIT, PAW, Tiered Admin), les outils du marché en 2026 et un plan d'implémentation réaliste.

1. Qu'est-ce qu'un compte privilégié

1.1 Définition

Un compte privilégié est une identité dotée de droits étendus, critiques ou destructifs sur un système, permettant d'effectuer des actions qu'un utilisateur standard ne peut pas réaliser :

• Modifier la configuration système.
• Accéder en lecture/écriture à l'ensemble des données.
• Créer, modifier, supprimer d'autres identités.
• Désactiver des contrôles de sécurité (logs, alertes).
• Déployer du code en production.
• Accéder à des données réglementées (PII, santé, financier).

1.2 Taxonomie

Dans une grande entreprise typique, on compte :

• 10 à 50 comptes Domain Admin / Enterprise Admin (souvent trop).
• 500 à 5 000 comptes Local Admin (workstations, serveurs).
• Dizaines à centaines de comptes cloud root/owner.
• Centaines à milliers de comptes DBA et application admin.
• Des milliers de service accounts avec permissions élevées.

1.3 Pourquoi ils sont ciblés

• ROI attaquant maximal : un Domain Admin compromis = contrôle de milliers de machines, des données, des emails.
• Persistence facile : l'attaquant peut créer d'autres comptes privilégiés pour rester.
• Camouflage : les actions admin passent souvent inaperçues parmi le bruit légitime.
• Blocage des défenses : l'attaquant peut désactiver logs, EDR, MFA pour d'autres comptes.

Ransomware opérateurs, espionnage étatique, fraude financière : tous ciblent en priorité les privilèges.

2. Quelques incidents emblématiques

2.1 NotPetya / Maersk (juin 2017)

Propagation via EternalBlue et Mimikatz sur un réseau AD avec de nombreux Domain Admins mal cloisonnés. En quelques heures, tous les serveurs Maersk dans le monde sont chiffrés. Reconstruction complète de l'AD en 10 jours grâce à un seul serveur survivant en Afrique qui avait été offline pendant l'attaque. Coût estimé : 300 millions de dollars.

Leçon : un AD mal segmenté avec des comptes Domain Admin réutilisés partout est une catastrophe en gestation.

2.2 SolarWinds / SUNBURST (2020)

L'attaquant compromet le processus de build de SolarWinds Orion. Dans les environnements victimes, il utilise la technique Golden SAML : vol du certificat de signature SAML de l'IdP (un compte/composant hautement privilégié), permettant de forger des tokens SAML pour n'importe quel utilisateur sur n'importe quel SP fédéré.

Le logiciel malveillant est le vecteur initial ; le vrai pouvoir vient de la compromission d'identités privilégiées.

2.3 Colonial Pipeline (2021)

Un compte VPN admin d'ancien employé, sans MFA, avec un mot de passe apparaissant dans un dump public. Point d'entrée du ransomware DarkSide. Mitigation qui aurait évité : PAM avec rotation + MFA sur les comptes VPN admin + révocation immédiate au départ.

2.4 Uber (septembre 2022)

Contractor avec credential compromis, MFA fatigue acceptée. L'attaquant trouve ensuite un script PowerShell sur un file share contenant un credential admin du PAM Thycotic. De là : AWS, GCP, HackerOne, Slack compromis. Une ligne de code dans un script avec le secret du coffre qui devait protéger tous les secrets.

2.5 Midnight Blizzard / Microsoft (janvier 2024)

Accès à un test tenant Microsoft sans MFA, compte de test avec privilèges plus larges que nécessaire. De là, l'attaquant (APT29) pivote vers les mailboxes de cadres Microsoft via une OAuth app malveillante. Plusieurs mois d'accès avant détection.

2.6 CDK Global (juin 2024)

Attaque ransomware sur ce fournisseur de logiciels pour concessionnaires auto. Compromission via compte admin qui remontait progressivement. 15 000 concessionnaires paralysés plusieurs semaines, rançon payée plusieurs dizaines de millions USD.

2.7 Schéma récurrent

Dans les 6 cas : pas d'exploit 0-day magique. Un compte privilégié mal protégé ou une rotation/déprovisioning mal fait. L'adversaire exploite le maillon faible humain et organisationnel, pas la technique.

3. PAM - Privileged Access Management

3.1 Définition

Le PAM (Privileged Access Management) regroupe l'ensemble des outils, processus et disciplines visant à :

• Découvrir les comptes privilégiés dans l'environnement.
• Centraliser leurs credentials dans un coffre.
• Contrôler l'accès à ces credentials (qui, quand, combien de temps).
• Surveiller et enregistrer leur usage.
• Alerter en cas d'anomalie.

3.2 Les 4 piliers d'un PAM

1. Discovery & inventaire : scan continu pour identifier nouveaux comptes privilégiés créés.
2. Credential vaulting : stockage chiffré, rotation automatique, injection juste-à-temps sans exposer à l'utilisateur.
3. Session management : bastion entre l'utilisateur et la cible, enregistrement vidéo et clavier, cut-off instantané possible.
4. Analytics & ITDR : détection comportementale, alertes sur usage anormal.

3.3 Comparaison avec gestionnaires de mots de passe classiques

Un gestionnaire comme 1Password ou LastPass n'est pas un PAM :

• Pas de rotation automatique des credentials dans les systèmes cibles.
• Pas de session recording.
• Pas de workflow d'approbation.
• Pas de discovery automatique.
• Pas d'injection sans exposition.

Le PAM est une catégorie distincte, plus lourde et plus chère, mais indispensable pour les comptes réellement privilégiés.

3.4 Leaders du marché 2026

Choix critères :

• Workforce AD/Windows classique : CyberArk, BeyondTrust, Delinea restent les références.
• Cloud-first, DevOps, Kubernetes : Teleport, HashiCorp Boundary, StrongDM sont plus adaptés.
• Écosystème Microsoft/Azure : Entra PIM + Privileged Access Management pour Microsoft 365 suffit souvent.
• Budget contraint : Vault + Teleport open source offrent beaucoup pour peu.

4. Just-in-Time (JIT) access - le changement de paradigme

4.1 Principe

Au lieu de maintenir des privilèges permanents sur les comptes, accorder les privilèges à la demande, pour une durée limitée, avec justification.

Comparaison :

• Avant JIT : un admin a le rôle Domain Admin attaché à son compte 24/7/365. Toute compromission de son compte = Domain Admin immédiatement.
• Avec JIT : l'admin demande l'activation du rôle Domain Admin quand nécessaire (durée 1h, 4h, 8h max), avec MFA + justification ticket. Le reste du temps, son compte n'a aucun privilège spécial.

Résultat : la fenêtre d'exploitation d'un credential compromis passe de 24/7 à quelques heures par mois maximum. Impact attaquant réduit de 95 % ou plus.

4.2 Implémentations concrètes

• Azure PIM (Privileged Identity Management) : activation de rôles Azure AD et Azure Resources avec MFA + justification + expiration.
• AWS IAM Identity Center avec session policies : sessions temporaires avec scope réduit.
• Okta Advanced Identity Governance : workflows d'élévation.
• Teleport : accès aux ressources avec TTL et approbation.
• HashiCorp Boundary + Vault : dynamic credentials + session brokering.
• BloodHound Enterprise (SpecterOps) : pas un PAM classique mais propose attack path management + JIT associé.

4.3 Just-Enough Access (JEA)

Concept complémentaire Microsoft : au lieu d'activer un shell admin complet, donner uniquement les cmdlets nécessaires pour la tâche. Implémenté en PowerShell via JEA role capabilities.

Exemple : un opérateur helpdesk n'a pas de shell Windows admin, juste accès aux cmdlets Reset-ADPassword et Unlock-ADAccount.

4.4 L'importance de break-glass

Avec le JIT, les privilèges permanents disparaissent. Que se passe-t-il si l'IdP tombe ou si le PAM est compromis ? Il faut pouvoir reprendre la main.

D'où la nécessité de break-glass accounts :

• 2-3 comptes d'urgence avec privilèges élevés.
• Credentials stockés physiquement (coffre-fort, HSM), pas dans le PAM.
• Hors IdP (pour survivre à une compromission de l'IdP).
• Usage journalisé avec alerte immédiate SIEM.
• Drill annuel obligatoire.
• Rotation après chaque usage.

Sans break-glass, paradoxe : les équipes gardent des privilèges permanents "au cas où", annulant le bénéfice JIT.

5. Tiered Administration Model (Microsoft)

5.1 Le modèle

Modèle publié par Microsoft en 2015, affiné depuis, applicable bien au-delà du monde AD :

• Tier 0 : ressources qui contrôlent l'identité et l'autorisation elles-mêmes - contrôleurs de domaine AD, comptes Enterprise Admin, Domain Admins, PKI racine, IdP central. Si un Tier 0 tombe, tout tombe.
• Tier 1 : serveurs d'application, middlewares, bases de données, systèmes backoffice.
• Tier 2 : workstations utilisateurs.

5.2 La règle non négociable

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

Conséquences opérationnelles :

• Un Domain Admin qui se connecte en RDP sur un serveur applicatif compromis = Golden Ticket possible.
• Un Domain Admin qui saisit son mot de passe sur sa workstation (Tier 2) exposée au web = interceptable.

Mitigation : séparation stricte, Privileged Access Workstations dédiées.

5.3 Privileged Access Workstation (PAW)

Poste de travail dédié à l'administration Tier 0 :

• Hardware séparé du poste utilisateur standard.
• OS fortement durci (AppLocker, Credential Guard, HVCI, moins de 10 applications autorisées).
• Pas de navigation web, pas d'email, pas de productivité office.
• Uniquement les outils d'admin (MMC, PowerShell ISE, RSAT, outils PAM).
• Isolation réseau : communication uniquement avec les DCs et le PAM.
• Accès Internet pour mises à jour uniquement via proxy restreint.

La PAW est l'application physique et organisationnelle du principe Tiered Admin. Coût : environ 2-3 k€ de hardware + effort de configuration. Impact sécuritaire : énorme.

5.4 Alternative moderne - Jump boxes sécurisées

Pour orgs qui ne peuvent pas déployer des PAWs physiques :

• Windows 365 Cloud PC ou AVD (Azure Virtual Desktop) configuré durci, dédié admin.
• Dedicated VM (Azure, AWS) utilisée uniquement pour admin, accessible via bastion.
• Teleport Desktop Access pour sessions RDP/SSH enregistrées.

Moins isolé qu'une PAW physique mais acceptable pour de nombreuses organisations.

6. Comptes privilégiés dans le cloud

6.1 AWS - les pires à protéger

• Root user : compte racine du compte AWS. Ne devrait jamais être utilisé au quotidien. MFA hardware obligatoire.
• AdministratorAccess : politique AWS managed qui donne toutes les permissions. À limiter drastiquement.
• IAM users avec access keys statiques : hérités des pratiques anciennes, à supprimer au maximum.
• Cross-account admin roles : rôles assumables entre comptes, source majeure d'escalade.

Bonnes pratiques :

• Root user : MFA hardware FIDO2, credentials physiques en coffre, utilisation uniquement pour les quelques opérations exclusives.
• Admins quotidiens : via AWS IAM Identity Center (ex-SSO) avec fédération OIDC/SAML, rôles temporaires.
• JIT via permission sets avec durée limitée.
• MFA obligatoire sur toutes les sessions admin.
• SCPs (Service Control Policies) au niveau Organization pour verrouiller les comptes enfants (interdire disable CloudTrail, disable GuardDuty, etc.).

6.2 Azure / Entra ID

• Global Administrator : équivalent Domain Admin pour Entra. Microsoft recommande au maximum 5 dans un tenant.
• Privileged Authentication Administrator, Security Administrator, User Access Administrator : rôles sensibles.
• Owner sur une subscription Azure : contrôle total des ressources.

Bonnes pratiques :

• Entra PIM pour activer ces rôles JIT, avec MFA phishing-resistant.
• Break-glass accounts hors PIM (2 comptes, MFA non-PIM, credentials en coffre).
• Conditional Access qui exige device compliant pour sessions admin.
• Privileged Access groups avec review trimestrielle.

6.3 GCP

• Organization Admin : sommet de la hiérarchie.
• Owner / Editor : rôles larges.
• Service account avec iam.serviceAccountAdmin : peut créer d'autres SAs, escalade possible.

Bonnes pratiques :

• Migration vers custom roles plutôt que Owner et Editor.
• Workforce Identity Federation pour workforce.
• IAM Recommender pour identifier les over-privileged.
• Just-in-time via Organization Policies et workflows custom.

6.4 Comptes privilégiés SaaS

Chaque SaaS a ses comptes à privilèges élevés :

• Okta Super Admin : contrôle total de l'IdP, incluant MFA policies, apps, users.
• Google Workspace Super Admin : contrôle total.
• Microsoft 365 Global Admin : idem.
• Salesforce System Administrator : contrôle organisationnel et données.
• GitHub Enterprise Owner : contrôle repos, teams, secrets.

Règle : traiter ces comptes avec le même niveau que les Domain Admin on-prem. Pas moins.

7. Session recording et audit

7.1 Objectif

Enregistrer les actions réalisées par les comptes privilégiés pour :

• Enquête post-incident : reconstituer ce qui s'est passé.
• Dissuasion : les opérateurs savent qu'ils sont enregistrés.
• Conformité : exigée par SOC 2, ISO 27001, PCI-DSS.
• Formation : réutilisation des sessions pour former les nouveaux.

7.2 Ce que recorder

• Sessions SSH : commandes, output, timing.
• Sessions RDP : vidéo + metadata.
• Sessions base de données : requêtes SQL avec metadata utilisateur.
• Actions dans consoles cloud : via CloudTrail / Cloud Audit Logs (déjà natif).
• Actions via APIs admin : logs applicatifs détaillés.

7.3 Défis

• Volume de stockage : heures de vidéo RDP pour des dizaines d'admins = téraoctets par mois.
• Protection des credentials dans les sessions : ne pas enregistrer les mots de passe saisis par erreur en clair.
• Performance : ajouter un bastion ralentit les sessions.
• Privacy : rétention et accès aux enregistrements encadrés.

7.4 Outils

• CyberArk PSM (Privileged Session Manager) : enregistrement complet, indexation full-text.
• BeyondTrust Privileged Remote Access.
• Teleport Session Recording : sessions SSH, K8s exec, DB sessions.
• Azure Bastion + Azure Monitor : sessions RDP/SSH avec logs.
• AWS Systems Manager Session Manager : sessions EC2 avec CloudTrail.
• Open source : OSSEC, EnvoyProxy + observability stack.

8. Détection d'anomalies - ITDR privilégié

8.1 Signaux à surveiller

• Login Domain Admin en dehors des PAWs.
• Activation de rôle privilégié en dehors des heures ouvrées sans justification.
• Création de nouveau Domain Admin.
• Modification d'une stratégie de groupe (GPO) sensible.
• Dump mémoire de lsass.exe (signature Mimikatz).
• DCSync détecté (synchronisation malveillante avec contrôleur de domaine).
• Utilisation de break-glass hors drill programmé.
• Pattern de connexions par compte admin vers nombreuses machines en séquence (mouvement latéral).

8.2 Outils ITDR modernes

• Microsoft Defender for Identity : détection attaque AD (Golden Ticket, Pass-the-Hash, Kerberoasting).
• CrowdStrike Falcon Identity Protection : détection + response sur identités.
• Okta ITP (Identity Threat Protection) : anomalies sur sessions Okta.
• Silverfort : couverture large multi-plateformes.
• SpecterOps BloodHound Enterprise : attack path management + détection pré-incident.
• Semperis Directory Services Protector : spécialisé AD, détection misconfiguration.

8.3 Intégration SIEM

Tous les signaux ci-dessus doivent remonter vers le SIEM avec corrélation par identité. Use cases classiques :

• "Domain Admin s'est connecté à 23 machines en 10 minutes" → alerte critique.
• "Break-glass account utilisé" → alerte immédiate au CISO.
• "GPO critique modifiée" → alerte équipe sécurité.
• "Nouvelle OAuth app avec scope admin consentie" → alerte et investigation.

9. Metrics de maturité PAM

10. Erreurs classiques

10.1 PAM acheté mais pas adopté

Millions dépensés en CyberArk ou BeyondTrust, mais l'équipe IT utilise toujours des credentials locaux en parallèle. Résultat : complexité ajoutée, bénéfice sécurité nul. Mitigation : enforcement strict, retrait des credentials hors PAM.

10.2 Trop de Domain Admins

Observations récurrentes : 30-100 Domain Admins dans des entreprises qui en justifient techniquement 3-5. Héritage historique, "au cas où", pas de revue. Mitigation : access review trimestrielle, JIT pour tous sauf break-glass.

10.3 Admin = utilisateur quotidien

L'admin utilise le même compte pour son travail admin et son mail, navigation, documents. Mitigation : comptes séparés, dédiés uniquement à l'administration.

10.4 Mots de passe partagés dans wikis

Credentials admin stockés dans Notion, Confluence, shared drives "pour que l'équipe y accède". Mitigation : tout en PAM, aucun secret admin hors vault.

10.5 Pas de break-glass testé

L'équipe compte sur le PAM/IdP sans jamais avoir essayé les comptes d'urgence. Le jour de l'incident, mot de passe perdu ou compte périmé. Mitigation : drill annuel obligatoire, résultat rapporté au CISO.

10.6 Rotation désactivée "parce que ça casse les pipelines"

Les pipelines CI/CD utilisent des credentials admin statiques. Mitigation : migrer vers OIDC (voir service accounts : risques et bonnes pratiques).

10.7 Pas de supervision du PAM lui-même

Le PAM devient lui-même un compte privilégié. Compromission du PAM = compromission des clés du royaume. Cas Uber 2022 illustre. Mitigation : MFA phishing-resistant sur PAM, monitoring renforcé, break-glass hors PAM.

11. Plan d'implémentation PAM - 12 mois

Mois 1-2 - discovery et cartographie

• Inventaire des comptes privilégiés existants (AD, cloud, SaaS, DBA, applicatif).
• Classification par criticité.
• Owners identifiés.
• Baseline des risques (combien de DA, comptes orphelins, credentials partagés).

Mois 3-4 - vaulting de base

• Choix et déploiement du PAM (CyberArk, BeyondTrust, Delinea, Vault+Boundary, Teleport).
• Migration des 50 comptes les plus critiques vers le vault.
• MFA phishing-resistant configurée pour accès PAM.
• Rotation automatique activée.

Mois 5-7 - JIT et bastion

• Déploiement Azure PIM / équivalent pour rôles cloud.
• Bastion avec session recording pour accès SSH/RDP/DB.
• Migration des admins vers accès via bastion obligatoire.
• Retrait des privilèges permanents pour les rôles intégrés au JIT.

Mois 8-9 - PAW et Tiered Admin

• Déploiement PAWs pour admins Tier 0.
• Application stricte de la règle "credential T0 jamais sur T1/T2".
• Revue des GPOs et politiques AD pour segmentation.

Mois 10-11 - detection & response

• Déploiement ITDR (Defender for Identity, CrowdStrike, Silverfort).
• Corrélation SIEM pour événements privilégiés.
• Runbook incident response privilégié.
• Drill break-glass.

Mois 12 - maturité et audit

• Access reviews trimestrielles institutionnalisées.
• Purge des comptes privilégiés orphelins.
• Métriques dashboard CISO.
• Red team exercise orienté escalade de privilèges.

12. PAM et Zero Trust - articulation

Le PAM est une brique essentielle de Zero Trust, mais pas suffisante seule. Il s'articule avec :

• IdP + SSO : authentification centrale.
• Conditional Access : contexte dynamique (device, IP, risk).
• MFA phishing-resistant : FIDO2 obligatoire pour admins.
• ITDR : détection continue.
• Micro-segmentation réseau : limiter la portée d'un compromis.
• Detection applicative : logs applicatifs fins.

Un PAM mature sans ces autres briques produit une fausse sécurité. À l'inverse, Zero Trust sans PAM laisse la porte ouverte aux comptes privilégiés.

13. Verdict et posture Zeroday

Les comptes privilégiés restent la cible numéro 1 des attaquants sophistiqués et opportunistes. Sans PAM + JIT + session recording + PAW pour les Tier 0 + break-glass testés, aucune organisation ne peut prétendre avoir une sécurité sérieuse en 2026.

L'investissement PAM est lourd (financier et organisationnel), mais produit le retour sécurité le plus élevé après la centralisation de l'authentification via SSO + MFA. Les 5 pires incidents cyber des 10 dernières années auraient tous été atténués ou évités avec un PAM mature.

Pour un ingénieur : maîtriser CyberArk ou Delinea ou Teleport ouvre un segment de marché très bien rémunéré. Les profils PAM seniors sont rares, recherchés, et structurants pour toute transformation cyber.

Pour une organisation : si budget limité, prioriser JIT natif (Entra PIM gratuit inclus en licence P2) + bastion session recording (Teleport open source) + PAWs pour les 5-10 admins Tier 0 (quelques milliers d'euros). Cela couvre 80 % du risque pour 20 % du budget d'un PAM enterprise complet.

Pour approfondir : pourquoi l'identité est centrale en cybersécurité pour le contexte, least privilege en pratique pour les permissions, service accounts : risques et bonnes pratiques pour les identités machine privilégiées, qu'est-ce qu'un spécialiste Active Directory Security pour le focus métier AD.