PAM : qu'est-ce que c'est et à quoi ça sert en 2026 ?

Le PAM (Privileged Access Management) est la discipline et la catégorie d'outils dédiée à la gestion, au contrôle et à l'audit des comptes privilégiés d'une organisation : administrateurs systèmes, comptes root, comptes de service IT avec droits étendus, comptes break-glass d'urgence, accès privilégiés au cloud (AWS root account, Azure Global Admin, GCP Organization Admin). Sous-discipline spécialisée de l'IAM, le PAM ajoute des contrôles que l'IAM standard ne fournit pas : vault sécurisé de credentials avec rotation automatique, session brokering (utilisateur ne voit jamais le mot de passe), session recording vidéo pour audit, just-in-time elevation (comptes privilégiés inactifs hors fenêtre approuvée), MFA renforcée et conditionnelle. En 2026, le marché PAM se divise en solutions commerciales traditionnelles (CyberArk Privileged Access Manager, BeyondTrust, Delinea ex-Thycotic) dominantes en grandes entreprises hybrides, et solutions cloud-native modernes (HashiCorp Boundary, Teleport, StrongDM, Pomerium) qui excellent dans les environnements DevOps Kubernetes / cloud. Cet article détaille la définition formelle, la taxonomie Gartner (PASM, PSM, PEDM), les composants d'une solution PAM, les cas d'usage par environnement, le pattern hybride 2026, le hardening obligatoire et les pièges fréquents.

Définition formelle et taxonomie

Le terme PAM a émergé dans les années 2000 chez les pionniers (Cyber-Ark Software fondé en 1999, Lieberman Software, Thycotic). Gartner formalise la catégorie dans son Magic Quadrant for Privileged Access Management (publication annuelle depuis 2017).

Trois sous-catégories Gartner

En 2026, la majorité des solutions commerciales (CyberArk, BeyondTrust, Delinea) couvrent les trois catégories simultanément. Les solutions cloud-native (Boundary, Teleport) se concentrent principalement sur PASM et PSM avec une approche infrastructure-centric.

Les 4 piliers d'un PAM moderne

Pourquoi le PAM est devenu critique

Trois forces convergentes en 2024-2026.

Force 1 — Comptes privilégiés = cible numéro un

Selon le Verizon Data Breach Investigations Report 2024, environ 70 % des intrusions majeures impliquent l'abus de credentials valides à un moment de la kill chain. Une fraction significative concerne des credentials privilégiés (admin AD, root serveurs, comptes service avec droits étendus). Le pattern récurrent : compromission initiale d'un compte standard via phishing, latéralisation vers compte privilégié non protégé, exfiltration ou ransomware.

Force 2 — Exigences réglementaires accrues

• NIS2 (article 21) : mesures techniques et organisationnelles pour la gestion des accès privilégiés. Transposition France octobre 2024, applicable aux entités essentielles et importantes.
• DORA (article 9) : gestion des accès aux ressources TIC critiques pour les institutions financières. Applicable janvier 2025.
• PCI-DSS v4.0 (req 7 et 8) : restriction de l'accès aux données de cartes par need-to-know, identification utilisateur unique, MFA pour les accès admin.
• ISO 27001:2022 (A.5.18) : gestion des accès privilégiés.
• HDS : audit privilégié obligatoire pour hébergement données de santé.

Force 3 — Multiplication des comptes privilégiés

Un environnement moderne typique combine :

• Active Directory (Domain Admins, Enterprise Admins, Schema Admins).
• Cloud providers (AWS IAM admins, Azure Global Admins, GCP Organization Admins).
• Kubernetes (cluster-admin RBAC).
• Bases de données (postgres superuser, MySQL root, MongoDB userAdminAnyDatabase).
• Outils SaaS (admin Salesforce, admin Microsoft 365, admin Workspace).
• Réseau (admin firewalls, switches, routeurs).
• Hyperviseurs (admin VMware vCenter, root Proxmox).

Une ETI typique gère plusieurs centaines voire milliers de comptes privilégiés. Sans tooling, gestion manuelle impossible et insécure.

Composants d'une solution PAM moderne

Six composants types présents dans les solutions PAM 2026.

1. Discovery et inventaire

Scanner l'infrastructure pour identifier les comptes privilégiés existants : AD, AWS IAM, Azure RBAC, GCP IAM, comptes locaux Windows/Linux, bases de données, réseau.

# Exemple : inventaire AWS IAM via AWS CLI
aws iam list-users --output json | \
  jq '.Users[] | {UserName, CreateDate, PasswordLastUsed}'
 
aws iam list-roles --output json | \
  jq '.Roles[] | select(.AssumeRolePolicyDocument | tostring | contains("AdministratorAccess"))'
 
# Pour AD
Get-ADGroupMember "Domain Admins" -Recursive | Select Name, SamAccountName
Get-ADGroupMember "Enterprise Admins" -Recursive
Get-ADGroupMember "Schema Admins" -Recursive

Les solutions PAM commerciales (CyberArk Discovery and Audit) automatisent cet inventaire en continu et alertent sur les nouveaux comptes privilégiés non managés.

2. Vault de credentials

Coffre chiffré centralisé qui stocke les mots de passe, clés SSH, certificats privilégiés. Caractéristiques essentielles :

• Chiffrement at rest AES-256 minimum, idéalement avec HSM.
• Authentification multi-facteurs obligatoire pour accès au vault.
• Audit complet (qui a checked-out quel credential, quand, pour quelle durée).
• HA et backup avec restauration testée régulièrement.
• Politiques de rotation automatique (par exemple : rotation du mot de passe Domain Admin tous les 30 jours).

3. Session brokering / proxying

L'utilisateur n'obtient jamais le credential en clair. Le PAM établit la connexion proxy à sa place. Patterns techniques :

• SSH : PAM se connecte au serveur cible avec le credential vault, ouvre un canal SSH proxifié vers l'utilisateur. Implémentations : CyberArk PSM SSH proxy, Teleport SSH proxy, HashiCorp Boundary, Apache Guacamole pour HTML5.
• RDP : Pattern similaire avec RDP. Implémentations : CyberArk PSM RDP, Apache Guacamole.
• Database : connexion DB tunnélée via PAM. Teleport et StrongDM excellent ici.
• HTTP/Web admin consoles : injection automatique de credentials dans navigateur sans révélation.

4. Session recording

Enregistrement vidéo et/ou textuel des sessions privilégiées :

• Vidéo : capture de l'écran utilisateur pendant toute la session. Conservée 90 jours à 7 ans selon compliance.
• Texte : capture des commandes (shell history exhaustif), exportable JSON pour analyse.
• Recherche : indexation pour recherche par commande, fichier modifié, date.
• Forensics : usage post-incident pour reconstituer ce qu'un admin a fait.

5. Just-In-Time access (JIT)

Suppression des accès permanents au profit d'élevations temporaires.

Workflow JIT type 2026 :
1. User n'a pas de droits admin par défaut sur la cible.
2. User demande accès admin via portail PAM (par exemple : 4 heures sur SERVER-PROD-01).
3. Approval workflow : auto-approve sur règle (heures ouvrées + IP corporate)
   ou approval manuel par manager pour cas sensibles.
4. PAM provisionne l'accès temporaire :
   - Crée un compte temporaire ou ajoute le user au groupe admin pour la durée.
   - Le compte est automatiquement supprimé à expiration.
5. Pendant la fenêtre, MFA renforcée + session recording obligatoires.
6. À la fin : tous les credentials utilisés sont rotés automatiquement.

6. Privileged user analytics

Détection comportementale des sessions admin :

• Anomalies temporelles (admin se connecte hors heures habituelles).
• Anomalies géographiques (IP inhabituelle).
• Anomalies de commandes (lancement de commandes jamais utilisées par cet admin).
• Combinaisons à risque (accès massif à fichiers sensibles + tentative de désactivation logs).

Intégration SIEM obligatoire pour corrélation avec autres signaux.

Solutions du marché 2026

Solutions commerciales traditionnelles

Solutions cloud-native modernes

Open source

PAM vs IAM : positionnement précis

Confusion fréquente. PAM est une sous-discipline IAM avec contrôles spécifiques aux comptes privilégiés.

En 2026, les frontières s'estompent : Microsoft Entra ID inclut Privileged Identity Management (PIM), AWS IAM Identity Center supporte temporary credentials avec approbation, Okta acquiert Auth0 et étend vers le PAM. Mais les outils PAM purs restent dominants pour les contrôles approfondis.

Architecture de déploiement type

Trois patterns observés.

Pattern 1 — PAM commercial centralisé (grands groupes)

┌─────────────────────────────────────────────────┐
│ User (admin) → MFA → CyberArk Portal            │
└─────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────┐
│ CyberArk Vault (HA cluster, 3+ nodes)           │
│ - Encrypted credential storage                  │
│ - Authentication and authorization              │
│ - Audit logging                                 │
└─────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────┐
│ CyberArk PSM (Privileged Session Management)    │
│ - SSH proxy / RDP proxy                         │
│ - Session recording                             │
│ - Real-time monitoring                          │
└─────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────┐
│ Cibles : serveurs, BDD, réseau, cloud, AD      │
└─────────────────────────────────────────────────┘

Pattern 2 — PAM cloud-native pour DevOps

┌─────────────────────────────────────────────────┐
│ Developer → OIDC SSO → Teleport Web UI          │
└─────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────┐
│ Teleport Auth Server                            │
│ - Validates OIDC token                          │
│ - Issues short-lived SSH/K8s certificates       │
│ - Per-session role assignment                   │
└─────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────┐
│ Teleport Proxy                                  │
│ - SSH session brokering                         │
│ - Kubernetes API proxy                          │
│ - Database connection proxy                     │
│ - Session recording                             │
└─────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────┐
│ Cibles : K8s clusters, EC2, RDS, Linux servers │
└─────────────────────────────────────────────────┘

Pattern 3 — Hybride (réalité 2026)

Combinaison des deux : CyberArk pour le legacy (mainframes, AD on-prem, datacenters), Teleport ou Boundary pour le cloud-native (Kubernetes, AWS, microservices). Convergence progressive selon la maturité de chaque vendor.

Cas d'usage prioritaires

Six cas d'usage à couvrir en priorité par tout déploiement PAM.

1. Comptes Domain Admin Active Directory

Le compte le plus critique d'une infrastructure Windows. Doit être :

• Dans le vault PAM avec rotation tous les 7 à 30 jours.
• Utilisé uniquement via session brokering (jamais de connexion RDP directe avec credential connu).
• MFA renforcée obligatoire à chaque check-out.
• Recording session systématique.
• Just-In-Time : pas de membre permanent de Domain Admins, élévation à la demande pour fenêtre de 4 heures max.

2. Comptes root serveurs Linux

Pattern type :

• SSH avec clés privées dans le vault, jamais sur les postes utilisateurs.
• Session brokering via Teleport, CyberArk PSM SSH, ou Apache Guacamole.
• Logging de toutes les commandes exécutées (intégration auditd + SIEM).
• Sudo configuré pour ne pas requérir le mot de passe root local quand session vient du PAM.

3. AWS root account et comptes admin cloud

• AWS root account : MFA hardware obligatoire (YubiKey), credentials dans vault PAM, utilisation extrêmement rare (création initiale + cas d'urgence). Idéalement break-glass uniquement.
• AWS IAM Identity Center pour les accès admin quotidiens : federation OIDC depuis IdP central, temporary credentials short-lived (15 minutes à 1 heure).

4. Comptes de service avec droits étendus

Comptes utilisés par des applications ou scripts pour accéder à des ressources privilégiées : compte de backup, compte de monitoring, compte d'orchestration CI/CD.

• Vault avec rotation automatique compatible avec l'application consommatrice.
• API check-out / check-in du credential par l'application.
• Pattern moderne 2026 : remplacement par OIDC federation (CI vers cloud) plutôt que credential statique géré par PAM.

5. Accès vendor / sous-traitants externes

Quand un fournisseur externe doit accéder aux systèmes (par exemple : intervention support technique CyberArk eux-mêmes) :

• Session PAM avec approbation workflow obligatoire.
• Time-limited (par exemple : 4 heures, étendable sur nouvelle approbation).
• Session recording obligatoire conservée 1 an minimum.
• IP allowlist du fournisseur.

6. Break-glass accounts

Comptes d'urgence ultra-privilégiés à utiliser uniquement quand le PAM lui-même est down ou en cas de crise majeure :

• Credentials scellés (enveloppe physique chez CISO + DPO + DSI).
• Procédure d'utilisation extrêmement encadrée (approbation board, alerting massive).
• Audit ultra-rigoureux post-utilisation.
• Test d'utilisation au moins une fois par an.

Hardening et bonnes pratiques

Sept pratiques cumulatives observées dans les déploiements matures.

1. Discovery exhaustive en démarrage

Avant tout déploiement, inventaire complet des comptes privilégiés existants. Pattern fréquent : un déploiement PAM démarre en pensant gérer 50 comptes, en découvre 500 lors du discovery initial.

2. Rotation automatique systématique

Tous les credentials dans le vault doivent avoir une politique de rotation :

• Mots de passe Domain Admin : rotation tous les 7 à 30 jours.
• Mots de passe root serveurs : rotation tous les 30 à 90 jours.
• Clés SSH : rotation tous les 90 à 365 jours.
• API keys / service accounts : rotation tous les 30 à 90 jours selon sensibilité.

3. MFA obligatoire et conditionnelle

MFA pour TOUT accès au vault PAM. MFA renforcée (FIDO2 / hardware token) pour les opérations à très haut risque (check-out compte Domain Admin, accès break-glass).

4. Just-In-Time pour les comptes les plus sensibles

Privileged Identity Management Microsoft Entra ID, AWS IAM Identity Center, ou capability équivalente du PAM choisi. Aucun membre permanent de Domain Admins, Enterprise Admins, Cloud Admin Global.

5. Session recording avec rétention adaptée

• Sessions admin standard : recording 90 jours.
• Sessions admin sur systèmes critiques : recording 1 an.
• Sessions break-glass : recording 7 ans (compliance forensique).

6. Intégration SIEM obligatoire

Tous les events PAM (login, check-out, session start/end, anomalies) doivent être ingérés dans le SIEM pour corrélation avec autres signaux sécurité.

7. Test annuel disaster recovery

Le PAM est devenu critique : sa panne signifie impossibilité d'administrer l'infrastructure. Test annuel obligatoire :

• Restauration vault depuis backup.
• Procédure break-glass (utilisation effective des comptes scellés).
• Failover vers HA replica.

Pièges fréquents

Cinq écueils observés sur les déploiements PAM en France 2024-2026.

Adoption non priorisée. Tentative d'onboarder tous les comptes privilégiés en une fois. Échec garanti par complexité opérationnelle. Solution : phasage par criticité (Domain Admin et root serveurs prod en phase 1, autres comptes en phases successives).

Résistance utilisateur. Les admins habitués à connaître les mots de passe résistent au session brokering qui leur masque les credentials. Solution : embarquer les équipes IT dès le design, expliquer le pourquoi (sécurité ET conformité), former intensivement.

Pas de rotation effective. Vault déployé mais rotation jamais activée car peur de casser des intégrations. Solution : démarrer rotation sur compte test, valider, étendre progressivement. Documentation des intégrations (qui consomme quel credential) avant d'activer.

Session recording stocké sans audit. Recordings générés mais jamais consultés ni audités. Faux sentiment de sécurité. Solution : audit aléatoire mensuel d'un échantillon, alerting sur patterns suspects via outils analytiques.

PAM exposé à Internet. Portail PAM accessible publiquement au lieu de derrière VPN ou IP allowlist. Surface d'attaque dramatique : compromission PAM = compromission complète. Solution : portail PAM strictement privé, accès uniquement via VPN avec MFA forte ou bastion intermédiaire.

Points clés à retenir

• Le PAM (Privileged Access Management) est la sous-discipline IAM dédiée aux comptes privilégiés (admin, root, services à droits étendus). Ajoute vault, brokering, session recording, just-in-time access que l'IAM standard ne fournit pas.
• 70 % des intrusions majeures impliquent l'abus de credentials valides (Verizon DBIR 2024). Les comptes privilégiés sont la cible prioritaire des attaquants. NIS2, DORA, PCI-DSS, ISO 27001 imposent des contrôles PAM.
• Trois sous-catégories Gartner : PASM (vault + brokering), PSM (recording sessions), PEDM (élévation endpoint). Solutions modernes couvrent les trois.
• Solutions 2026 : commerciales traditionnelles (CyberArk, BeyondTrust, Delinea) pour les grands groupes hybrides, cloud-native (HashiCorp Boundary, Teleport, StrongDM) pour les environnements DevOps modernes. Pattern hybride dominant.
• Just-In-Time access (PIM Entra ID, AWS Identity Center temporary credentials) supprime les accès permanents privilégiés. Adoption recommandée comme objectif cible 2026.

Pour aller plus loin

• Qu'est-ce que l'IAM - définition fondamentale IAM dont PAM est une sous-discipline.
• Qu'est-ce que Keycloak - IdP open source qui peut être complété par PAM dédié.
• RBAC vs ABAC - modèles d'autorisation appliqués au PAM.
• Pourquoi l'identité est centrale en cybersécurité - pillar IAM moderne.