PAM

01 — DéfinitionQu'est-ce que le PAM ?

Le PAM (Privileged Access Management) est une discipline de cybersécurité qui regroupe les outils et processus permettant de contrôler, surveiller et sécuriser les accès des comptes à hauts privilèges aux systèmes et données critiques d'une organisation.

Les comptes à privilèges sont les « clés du royaume » : une fois compromis, ils donnent accès à tout ou presque. Ils sont la cible principale des attaques sophistiquées, qu'elles soient criminelles (ransomware) ou étatiques. Les grands incidents cyber des années 2020-2024 — SolarWinds, Kaseya, MGM Resorts, Okta, Microsoft Midnight Blizzard, Change Healthcare — ont tous en commun la compromission d'un ou plusieurs comptes à privilèges.

Le PAM répond à ce risque par une combinaison de principes :

• Moindre privilège : chaque compte ne doit avoir que les droits strictement nécessaires, pas plus.
• Temporalité : les privilèges élevés ne sont accordés que quand c'est nécessaire, pour une durée limitée.
• Isolation : les comptes à privilèges sont séparés des comptes utilisateurs normaux, avec leurs propres postes, leur propre MFA.
• Traçabilité : toutes les actions privilégiées sont enregistrées et auditables.
• Rotation : les mots de passe et clés privilégiés changent automatiquement et régulièrement.

Le PAM n'est pas qu'un outil : c'est une démarche qui combine technologie, processus et organisation. Une solution technique déployée sans gouvernance ni processus produit peu de valeur. À l'inverse, des processus sans outillage sont impossibles à appliquer à grande échelle.

Dans les statistiques post-incident, 80 à 90% des compromissions majeures impliquent l'abus d'un compte à privilèges. Le PAM est devenu l'un des investissements cyber à plus fort retour sur investissement face aux menaces modernes.

02 — ComptesLes populations de comptes à privilèges

Administrateurs humains

Les plus évidents. Administrateurs Windows (Domain Admins, Enterprise Admins), administrateurs Linux/Unix (comptes root, sudo), administrateurs de bases de données (SQL Server, Oracle, PostgreSQL), administrateurs cloud (AWS root accounts, Azure Global Administrators, GCP Organization Admins), administrateurs applicatifs (SAP, Salesforce, plateformes internes).

Comptes de service

Comptes utilisés par des applications ou scripts pour fonctionner. Exemples : compte qui lance le service SQL Server, compte qui exécute une tâche planifiée, compte utilisé par une intégration entre deux applications. Souvent :

• Mot de passe inchangé depuis des années (parfois décennies).
• Mot de passe codé en dur dans des scripts ou fichiers de configuration.
• Privilèges excessifs pour simplifier l'installation initiale.
• Présent sur de nombreuses machines.
• Documentation lacunaire ou inexistante.

Les comptes de service sont la cible privilégiée des ransomwares car leur compromission est souvent silencieuse (personne ne remarque que leur mot de passe a été volé) et leurs droits étendus.

Comptes techniques et d'intégration

Comptes utilisés pour des intégrations techniques : sauvegardes, supervision, ordonnanceurs, outils de déploiement, outils d'administration (antivirus, EDR, MDR). Ces comptes ont souvent besoin d'accès larges pour fonctionner — d'où une vulnérabilité particulière.

Comptes d'urgence (break-glass)

Comptes conservés pour les situations de crise : panne de l'IAM, perte d'accès aux comptes normaux, reprise après incident majeur. Ces comptes doivent être : documentés, protégés physiquement (coffre-fort physique), rarement utilisés, testés périodiquement, avec alertes automatiques à chaque usage.

Comptes prestataires

Comptes créés pour des prestataires externes (infogérance, audit, éditeurs, consultants). Problématiques : maintien une fois les missions terminées, partage entre plusieurs personnes chez le prestataire, traçabilité réduite, connexions depuis des environnements non maîtrisés.

Comptes cloud et DevOps

Catégorie émergente et massive. Clés d'API, tokens, secrets utilisés par les pipelines CI/CD, les infrastructures Terraform, les conteneurs Kubernetes, les fonctions serverless. Très difficiles à inventorier : ils peuvent être partout (code source, variables d'environnement, secrets Kubernetes). Les PAM modernes intègrent une dimension Secrets Management pour ces comptes.

Ratio compte à privilèges / utilisateurs

Dans une organisation, la règle empirique est d'environ 2 à 4 fois plus de comptes à privilèges que d'utilisateurs humains. Une ETI de 1 000 collaborateurs gère typiquement 2 000 à 5 000 comptes à privilèges (humains + services + techniques + cloud). Le premier choc d'un inventaire PAM est souvent la découverte de cette volumétrie.

03 — ComposantsLes briques d'une solution PAM

Coffre-fort de mots de passe (vault)

Composant central. Un coffre-fort chiffré qui stocke les secrets : mots de passe, clés SSH, certificats, tokens, clés d'API. Accessible uniquement après authentification forte, avec contrôles d'accès stricts. Fonctions clés :

• Rotation automatique des mots de passe (quotidienne, hebdomadaire, à chaque usage).
• Récupération programmatique via API pour les applications.
• Chiffrement au repos et en transit (AES-256, HSM).
• Séparation des rôles (celui qui consulte un secret ne peut pas le modifier).
• Approbation par workflow pour les secrets les plus sensibles.

Bastion d'administration (PSM — Privileged Session Management)

Serveur intermédiaire par lequel transitent toutes les sessions administratives. L'administrateur ne se connecte jamais directement aux serveurs cibles : il se connecte au bastion, qui se connecte à sa place en utilisant le secret stocké dans le coffre. Bénéfices :

• Les mots de passe ne sont jamais manipulés par l'administrateur.
• Toutes les sessions sont enregistrées (vidéo ou keylogger).
• Les commandes sensibles peuvent être bloquées en temps réel.
• Un seul point de contrôle pour appliquer les politiques.

Enregistrement et supervision de session

Chaque session privilégiée est enregistrée :

• Vidéo : capture d'écran continue de ce que voit l'administrateur.
• Audit des commandes : liste des commandes shell, SQL, etc. exécutées.
• Métadonnées : qui, quand, où, avec quel compte, pour quelle durée.

Les enregistrements sont horodatés, signés, stockés de manière inaltérable, accessibles uniquement sur autorisation. Ils permettent l'audit, l'investigation post-incident, la conformité et la dissuasion (savoir qu'on est filmé modifie les comportements).

Détection comportementale (PBM — Privileged Behavior Monitoring)

Analyse en temps réel des actions privilégiées pour détecter les comportements anormaux : commandes inhabituelles, accès atypiques, horaires décalés, schémas suspects. Utilise de plus en plus de ML pour établir des baselines par utilisateur. Génère des alertes vers le SOC ou le SIEM.

Gestion des secrets pour applications

Extension moderne du PAM : fournir aux applications, scripts et pipelines CI/CD des secrets à la volée, sans qu'ils soient codés en dur. Remplace les mots de passe dans les fichiers de configuration par des appels API vers le coffre. Les CI/CD récupèrent leurs secrets à l'exécution plutôt que de les stocker dans GitHub/GitLab.

Découverte et inventaire

Scanner régulier qui identifie :

• Les comptes à privilèges non encore mis en coffre.
• Les comptes orphelins (sans propriétaire identifié).
• Les comptes non utilisés depuis longtemps.
• Les comptes locaux sur les postes et serveurs.
• Les secrets dans le code source et les fichiers de configuration.

Phase indispensable au démarrage — on ne peut pas protéger ce qu'on ne connaît pas.

Intégration MFA et authentification forte

L'accès au PAM exige systématiquement MFA, idéalement FIDO2 ou carte à puce. Pour les actions les plus critiques, authentification renforcée (step-up MFA avec validation supplémentaire).

Workflows d'approbation

Pour les accès à très forte criticité : demande d'accès, validation par un manager ou un pair, notification en cas d'accès, possibilité de révoquer en cours de session. Ces workflows sont essentiels pour les comptes les plus sensibles (root d'un serveur de production critique, accès à des données réglementées).

04 — JITL'accès just-in-time

Principe

L'accès just-in-time (JIT) est un des concepts les plus structurants du PAM moderne. Au lieu qu'un administrateur dispose en permanence de ses privilèges, il les demande quand il en a besoin, pour une durée limitée, avec justification.

Flux typique

1. Un administrateur a besoin d'intervenir sur un serveur de production.
2. Il fait une demande d'accès via le portail PAM : cible, compte à utiliser, raison, durée.
3. Le PAM déclenche la validation selon les politiques : auto-approbation pour certains cas, workflow manager sinon, parfois validation multiple pour les cibles critiques.
4. Une fois validé, les droits sont activés temporairement (souvent 2 à 4 heures).
5. L'administrateur effectue sa session via le bastion, tout est enregistré.
6. À la fin de la durée, les droits sont automatiquement révoqués.

Réduction de la surface d'attaque

Le JIT change radicalement le profil de risque :

• Un compte volé hors période d'accès n'a aucun privilège actif.
• Le vol d'identifiants (phishing, malware infostealer) ne donne accès qu'à un compte sans privilèges permanents.
• La fenêtre d'opportunité pour un attaquant se réduit à la durée d'activation.
• Les tentatives d'usage hors contexte sont détectées immédiatement.

Approches techniques

Plusieurs implémentations coexistent :

• Ajout/retrait dans les groupes Active Directory : l'utilisateur est ajouté au groupe « Domain Admins » pour 2h puis retiré.
• Création/suppression de comptes temporaires : un compte dédié est créé pour la session puis supprimé.
• Activation de rôles cloud : Azure PIM (Privileged Identity Management) active un rôle pour une durée définie.
• Approvisionnement SSH/SUDO à la demande : ajout d'une clé SSH ou d'une règle sudo pour la durée de la session.

Azure Privileged Identity Management (PIM)

Le PIM de Microsoft est un exemple emblématique de JIT. Il permet de rendre « éligibles » aux rôles plutôt que « actifs » de manière permanente. Un utilisateur éligible au rôle Global Administrator doit activer ce rôle quand il en a besoin, avec MFA, justification et durée. Microsoft rapporte que le déploiement du PIM sur les clients Azure réduit de plus de 90% le nombre de comptes à privilèges actifs à un instant donné.

Limites du JIT

• Friction opérationnelle : chaque intervention demande un passage par le portail, ce qui ralentit légèrement le travail quotidien.
• Compatibilité applicative : certaines applications historiques fonctionnent mal avec des droits qui changent.
• Cas d'urgence : besoin de procédures d'exception pour les interventions critiques hors workflow normal.
• Adoption culturelle : les administrateurs habitués à « tout avoir tout le temps » peuvent résister.

05 — MarchéActeurs et solutions

Leaders historiques

• CyberArk : pionnier et leader mondial du marché, référence pour les grandes entreprises et secteurs régulés.
• Delinea (fusion Thycotic + Centrify en 2021) : second acteur majeur, positionnement mid-market et grandes entreprises.
• BeyondTrust : historiquement fort sur la gestion des endpoints et des sessions.
• One Identity (Safeguard) : du groupe Quest Software, offre complète.

Acteurs cloud-native et DevOps

• HashiCorp Vault : référence open source et entreprise pour les secrets, particulièrement populaire dans les équipes DevOps.
• AWS Secrets Manager, Azure Key Vault, Google Secret Manager : offres natives des hyperscalers pour les secrets applicatifs.
• Doppler, 1Password Secrets Automation : plateformes modernes orientées développeurs.

Offres Microsoft et Google

• Microsoft Entra Privileged Identity Management (PIM) : JIT natif pour les rôles Azure et Microsoft 365.
• Microsoft LAPS : gestion des mots de passe administrateurs locaux Windows, gratuit.
• Google Cloud Privileged Access Manager : offre PAM cloud pour GCP.

Acteurs spécialisés et challengers

• Arcon : acteur indien en croissance internationale.
• ManageEngine PAM360 : offre intégrée du groupe Zoho, rapport qualité/prix compétitif.
• Senhasegura : acteur brésilien présent en Europe.
• Teleport : approche moderne cloud-native pour les accès SSH/Kubernetes.
• StrongDM : proxy moderne pour accès bases de données et infrastructure.

Acteurs français et européens

• WALLIX : pure-player français du PAM, certifié SecNumCloud, présent sur les grands comptes et les secteurs souverains.
• Systancia (Systancia Cleanroom) : éditeur français, positionnement bastion et postes d'administration durcis.
• Ilex International (Sign&go) : offre française historique.
• Atos/Eviden : services d'intégration et d'exploitation PAM.

Critères de sélection

• Couverture des types de comptes (humains, services, applications, cloud, DevOps).
• Support des protocoles à administrer (RDP, SSH, base de données, plateformes cloud, applications web).
• Qualité du JIT et des workflows d'approbation.
• Capacités d'enregistrement et de détection comportementale.
• Facilité d'intégration (IAM, SIEM, ITSM, annuaires).
• Haute disponibilité (le PAM devient critique — si indisponible, impossible de se connecter).
• Certifications et souveraineté si pertinent (SecNumCloud, Common Criteria).
• Modèle tarifaire (par compte géré, par utilisateur, par session).

06 — DéploiementDémarche progressive

07 — PiègesErreurs classiques à éviter

Sous-estimer la phase de découverte

L'erreur la plus fréquente. Partir avec un inventaire approximatif et découvrir en cours de projet des centaines de comptes non identifiés bloque le déploiement et crée des angles morts. La découverte doit être exhaustive et automatisée, avec validation humaine.

Oublier les comptes de service

Beaucoup de projets PAM s'arrêtent aux administrateurs humains et laissent les comptes de service sans protection. Or, ce sont justement ceux que les ransomwares compromettent le plus souvent. Le PAM doit inclure une démarche structurée sur les comptes de service, même si elle est plus longue.

Négliger la haute disponibilité

Une fois déployé, le PAM devient critique : s'il est indisponible, plus personne ne peut se connecter aux systèmes. Prévoir dès le départ une architecture redondée, des tests de bascule, un plan de continuité. Un PAM mono-instance est une bombe à retardement.

Absence de comptes break-glass

Les comptes d'urgence (break-glass) permettent de garder un accès même si le PAM est indisponible. Ils doivent exister, être protégés physiquement, et leur utilisation doit être alertée. Trop d'organisations se retrouvent coincées lors d'incidents car elles n'ont pas prévu ces garde-fous.

Mal calibrer les workflows d'approbation

Trop stricts : les équipes opérationnelles contournent (comptes parallèles, brouillons de process). Trop laxistes : le PAM perd son sens. Calibrage à affiner dans le temps avec retours des équipes.

Ignorer les administrateurs cloud

Les comptes à privilèges cloud (AWS, Azure, GCP) demandent souvent une approche spécifique, complémentaire au PAM traditionnel. Les offres natives (PIM, IAM) doivent être intégrées au dispositif global plutôt que traitées séparément.

Manquer d'accompagnement du changement

Le PAM modifie profondément les habitudes des administrateurs. Sans accompagnement (formation, communication, support), rejets et contournements sont garantis. Prévoir un plan de conduite du changement aussi substantiel que le plan technique.

Oublier les revues régulières

Les comptes à privilèges prolifèrent spontanément : nouveaux projets, nouveaux prestataires, nouvelles technologies. Sans revue trimestrielle ou semestrielle, le périmètre dérive et des comptes non protégés réapparaissent. La revue régulière est aussi importante que le déploiement initial.

08 — FAQQuestions fréquentes

Le PAM est-il obligatoire réglementairement ?

Pas explicitement par nom. Mais les exigences concrètes de NIS2, DORA, PCI DSS, HDS, ISO 27001, RGPD article 32 imposent toutes des mesures qui, en pratique, impliquent un PAM : traçabilité des accès privilégiés, principe du moindre privilège, rotation des mots de passe, enregistrement des sessions critiques. Les auditeurs recherchent désormais systématiquement l'existence d'une démarche PAM.

Un PAM open source peut-il suffire ?

HashiCorp Vault (version OSS) couvre bien la gestion des secrets applicatifs et la partie coffre-fort. Pour la gestion des sessions humaines (bastion, enregistrement, JIT), les options open source sont plus limitées : Teleport OSS, JumpServer sont des débuts mais n'égalent pas les fonctionnalités des offres commerciales. Pour une PME avec un périmètre limité, une combinaison open source peut fonctionner. Pour une ETI ou grande entreprise avec des exigences de conformité, les offres commerciales restent la norme.

PAM et Zero Trust sont-ils liés ?

Fortement. Le Zero Trust pose le principe « ne jamais faire confiance, toujours vérifier ». Le PAM l'applique concrètement aux comptes les plus sensibles : vérification permanente de l'identité et du contexte, accès temporaires, traçabilité, moindre privilège. Un programme Zero Trust mature inclut systématiquement un volet PAM fort. À l'inverse, un PAM sans une démarche globale Zero Trust reste un silo qui produit moins de valeur.

Comment les administrateurs perçoivent-ils le PAM ?

Généralement mal à l'annonce, mieux après quelques mois d'usage si le déploiement est bien fait. Les craintes principales : lourdeur opérationnelle, surveillance, perte de flexibilité. Les arguments qui fonctionnent : protection personnelle (traçabilité qui dédouane l'administrateur en cas d'incident), professionnalisation du métier, alignement avec les standards de l'industrie, meilleures conditions de travail sur le long terme.

Quelle articulation avec les prestataires d'infogérance ?

Les prestataires externes sont un cas critique du PAM. Ils ont souvent des comptes avec de larges privilèges, des accès depuis leurs propres environnements, du turn-over élevé dans leurs équipes. Les bonnes pratiques : accès via le PAM du client (pas leurs outils internes), sessions enregistrées systématiquement, accès JIT avec approbation manager interne, clauses contractuelles sur la révocation, audits réguliers. Certains grands comptes imposent désormais leur PAM à leurs prestataires, avec licences dédiées.