La compromission d’un compte à privilèges reste, en 2026, le scénario de sinistre le plus fréquemment documenté dans les rapports post-incident. Selon l’ENISA Threat Landscape 2024, les attaques ciblant les identités et les accès figurent parmi les cinq vecteurs dominants affectant les organisations européennes. Pourtant, de nombreux programmes de sécurité traitent encore IAM et PAM comme deux initiatives distinctes, pilotées par des équipes différentes, avec des outils sans interconnexion. Ce cloisonnement est lui-même un vecteur de risque. Cet article propose un cadre d’analyse structuré à destination des DSI et RSSI pour unifier ces deux disciplines et réduire concrètement la surface d’attaque liée aux identités.
IAM et PAM : périmètres et articulation
IAM (Identity and Access Management) désigne l’ensemble des processus et technologies qui gouvernent le cycle de vie des identités numériques : création de comptes, authentification, autorisation, fédération et révocation. Son périmètre couvre les utilisateurs finaux, les comptes applicatifs, les identités machine (workloads, pipelines CI/CD) et les partenaires externes (fournisseurs, prestataires).
PAM (Privileged Access Management) est un sous-ensemble spécialisé d’IAM qui se concentre sur les comptes disposant de droits élevés. La définition opérationnelle inclut :
- Les comptes d’administration locale et de domaine (Domain Admins, Enterprise Admins, root)
- Les comptes de service applicatifs avec accès à des bases de données ou des API critiques
- Les comptes d’urgence (break-glass accounts)
- Les accès administrateurs aux hyperviseurs, équipements réseau et solutions cloud (rôles Owner/Contributor sur Azure, AdministratorAccess sur AWS)
- Les identités non-humaines disposant de secrets d’accès : tokens, clés API, certificats
L’ANSSI, dans ses recommandations relatives à l’administration sécurisée des systèmes d’information, distingue explicitement le plan d’administration du plan utilisateur et recommande une séparation physique ou logique forte entre les deux flux. Cette séparation est un prérequis opérationnel avant tout déploiement PAM : sans elle, un compte compromis sur le plan utilisateur peut rebondir vers les systèmes d’administration.
Modèles de contrôle des accès et principe de moindre privilège
Trois modèles structurent les implémentations d’entreprise :
| Modèle | Principe | Usage typique | Limite principale |
|---|---|---|---|
| RBAC (Role-Based) | Droits attribués via des rôles prédéfinis | Active Directory, ERP, SaaS B2B | Prolifération des rôles, droits dormants |
| ABAC (Attribute-Based) | Droits calculés dynamiquement selon des attributs contextuels | Zero Trust, cloud natif | Complexité de la politique, latence d’évaluation |
| PBAC (Policy-Based) | Combinaison de règles métier et de contexte | Environnements hybrides complexes | Maintenabilité des politiques |
Le principe de moindre privilège (POLP), défini par le NIST SP 800-53 Rev. 5 (contrôle AC-6), impose d’octroyer uniquement les droits strictement nécessaires à l’exécution d’une tâche, pour la durée minimale requise. Son application concrète suppose un inventaire exhaustif des droits existants, une revue périodique des accès (access review) et la suppression systématique des droits dormants.
Un écueil fréquent : les droits accumulés par sédimentation (accumulation of privileges), où un utilisateur conserve l’ensemble des accès acquis au fil de ses mobilités internes. Ce phénomène est particulièrement critique dans les organisations sans processus de désapprovisionnement automatisé lié au SIRH. Le pilotage par les données (exports SIRH vers IAM) est la correction durable : toute fin de contrat ou mutation déclenche automatiquement la révision des droits associés.
Just-In-Time access et sessions éphémères
Le modèle d’accès permanent (standing access) constitue une vulnérabilité structurelle : un compte admin actif en permanence est exploitable à n’importe quel moment, y compris en dehors des heures ouvrées. Le Just-In-Time (JIT) access inverse cette logique : les droits élevés n’existent que le temps de la tâche qui les justifie.
L’implémentation repose sur trois mécanismes :
- Suppression des adhésions permanentes aux groupes à privilèges (retrait de Domain Admins comme groupe permanent sous Active Directory)
- Workflow de demande et d’approbation avec durée bornée (généralement 1 à 4 heures selon la criticité)
- Révocation automatique à l’expiration, sans intervention humaine requise
Pour les environnements cloud, les mécanismes natifs sont disponibles : AWS STS (Security Token Service) avec AssumeRole et SessionDuration, Microsoft Entra PIM (anciennement Azure AD PIM) avec activation sur demande, et Google Cloud IAM avec les conditions basées sur la durée. Ces approches s’inscrivent directement dans les recommandations du NIST SP 800-207 sur l’architecture Zero Trust, qui stipule que l’accès doit être accordé transaction par transaction avec vérification continue.
Un point de vigilance opérationnel : le JIT ne supprime pas le risque de compromission du compte demandeur. Si le compte utilisateur standard est compromis avant la demande d’élévation, le mécanisme JIT sera détourné. La MFA résistante au phishing (clés FIDO2) sur les comptes de demande reste une condition préalable à l’efficacité réelle du JIT.
Supervision et détection : l’audit trail comme exigence non négociable
Une solution PAM sans enregistrement de sessions et sans corrélation avec un SIEM n’est qu’un coffre-fort de mots de passe. La valeur opérationnelle d’un programme PAM mature repose sur quatre piliers :
- L’enregistrement des sessions privilégiées (keylogging, screen recording) pour les accès aux systèmes critiques
- L’alerte comportementale sur les anomalies : connexion hors plage horaire habituelle, volume inhabituel de requêtes, accès à des ressources hors périmètre habituel
- La corrélation SIEM des événements PAM avec les autres sources de log (Active Directory, VPN, EDR)
- L’intégration avec les outils de ticketing (ServiceNow, Jira) pour valider que chaque session privilégiée est associée à un ticket de changement approuvé
MITRE ATT&CK recense la tactique TA0004 (Privilege Escalation) comme présente dans la grande majorité des chaînes d’attaque documentées. Les techniques T1078 (Valid Accounts) et T1548 (Abuse Elevation Control Mechanism) apparaissent systématiquement dans les rapports post-incident ransomware. La détection précoce d’une élévation de privilèges non autorisée dépend directement de la qualité de la supervision des comptes à privilèges.
Identités non-humaines : le point aveugle des programmes IAM
La prolifération des architectures cloud-native, des pipelines DevSecOps et des intégrations API a créé une catégorie d’identités souvent négligée : les identités non-humaines (non-human identities, NHI). Il s’agit des comptes de service, secrets d’application, tokens OAuth, clés SSH et certificats utilisés par les workloads automatisés.
Ces identités présentent des risques spécifiques :
| Risque | Manifestation courante |
|---|---|
| Secrets hardcodés | Clés API embarquées dans le code source, exposées via dépôts publics |
| Rotation absente | Tokens valables indéfiniment, jamais révoqués |
| Sur-provisionnement | Compte de service avec droits admin complets sur l’infrastructure |
| Absence d’inventaire | Secrets créés ad hoc, non documentés, non supervisés |
Les solutions de gestion de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) permettent de centraliser la rotation et l’audit. La CISA, dans ses recommandations publiées en 2022 sur les meilleures pratiques IAM pour les administrateurs, recommande explicitement l’extension des contrôles PAM aux comptes non-humains et l’adoption de mécanismes d’authentification par workload identity. Pour les environnements Kubernetes, le standard SPIFFE/SPIRE, soutenu par la CNCF, fournit un cadre d’identité cryptographique par workload sans dépendance aux secrets statiques.
IAM, PAM et conformité réglementaire
La directive NIS2 (2022/2555, Article 21) impose aux entités essentielles et importantes des mesures de contrôle des accès et de gestion des identités comme exigences minimales. DORA (règlement UE 2022/2554) requiert pour les entités financières des politiques de gestion des accès à privilèges documentées, auditables et testées régulièrement. Les deux textes partagent une exigence commune : la démonstration opérationnelle, pas seulement documentaire.
En France, l’ANSSI encadre ces exigences via ses guides de sécurisation des systèmes d’information et les critères de qualification des solutions PAM. Une solution PAM qualifiée ANSSI ou certifiée selon les Critères Communs constitue un argument lors des audits de conformité dans les secteurs régulés (banque, assurance, santé, OIV/OSE). La qualification impose notamment la démonstration de la journalisation des sessions, de la rotation des secrets et de la séparation des flux d’administration.
L’intégration de l’IAM et du PAM dans une architecture Zero Trust ferme les vecteurs d’attaque les plus exploités. Pour approfondir la démarche, notre analyse Zero Trust : architecture en 5 étapes détaille les prérequis d’implémentation. Un panorama complet de la cybersécurité en entreprise situe ces enjeux dans le cadre plus large de la gestion des risques opérationnels.
La maîtrise des identités et des accès à privilèges n’est pas un projet ponctuel mais un programme continu : inventaire permanent des comptes, revue régulière des droits, automatisation des cycles de vie et supervision des sessions privilégiées forment le socle sur lequel repose la résilience opérationnelle face aux menaces actuelles.