PAM, JIT et comptes break-glass sécurisés

Un accès administrateur permanent est une dette de sécurité qui porte intérêt chaque minute. La recommandation est nette : supprimer les privilèges permanents des identités humaines, élever temporairement les droits via un PAM (Privileged Access Management), et traiter les comptes de secours comme des mécanismes de reprise testés, pas comme des reliques sous verre.

→ Lire l’explication complète de la marmotte

PAM moderne : le privilège doit être éphémère

Un PAM (Privileged Access Management) contrôle l’obtention, l’usage et la traçabilité des accès administratifs. Sa fonction utile n’est pas de stocker des mots de passe dans une jolie interface. Un coffre-fort sans élévation temporaire, sans journal inviolable et sans révocation exploitable reste un gestionnaire de secrets coûteux. Le secteur sait emballer cela dans des slides avec des cadenas bleus, ce qui n’a jamais empêché un compte admin de vivre dix ans.

Le compromis central est brutal : le JIT (Just-In-Time), c’est-à-dire l’attribution temporaire de privilèges, réduit la fenêtre exploitable et complique la persistance adverse ; il introduit une dépendance opérationnelle au système d’identité, au moteur d’approbation et aux flux de délivrance. Ce coût est acceptable pour les accès humains à fort impact. Il ne l’est pas forcément pour un service automatisé qui doit fonctionner sans présence humaine et dont l’identité doit être conçue autrement.

Une élévation JIT doit produire un jeton, un certificat ou une appartenance de groupe à durée bornée. La durée ne doit pas être une donnée décorative : le composant qui évalue l’autorisation doit la faire respecter. Ajouter une date d’expiration dans un ticket sans expiration de session côté cible revient à écrire « ne pas entrer » sur une porte déjà ouverte.

La demande d’élévation doit contenir au minimum :

l’identité source authentifiée avec MFA (Multi-Factor Authentication) résistant au hameçonnage ;
le rôle demandé, défini par des permissions concrètes et non par un vague niveau « administrateur » ;
la ressource ou le périmètre visé ;
une durée maximale courte, généralement entre 15 et 120 minutes selon la tâche ;
un motif structuré, lié à un incident, un changement ou une opération ;
une approbation lorsque le risque le justifie, sans approbation automatique par un groupe dont tous les membres peuvent aussi s’élever.

Le modèle robuste sépare identité permanente et privilège. Une identité humaine nominale ne possède aucun rôle d’administration direct. Elle peut demander un rôle temporaire, sous réserve de politiques d’accès. Cette séparation limite l’effet d’un vol de session et simplifie les revues : on examine les capacités d’élévation, pas une forêt de droits hérités dont personne ne sait pourquoi ils existent.

Les fondations de l’identité doivent précéder le PAM : annuaire fiable, identités nominatives, authentification multifacteur, synchronisation horaire et désactivation rapide des départs. Installer un coffre-fort au-dessus d’identités partagées ne transforme pas les comptes partagés en personnes. Cela ajoute seulement un journal indiquant qu’un fantôme a fait quelque chose.

Coffre-fort de secrets et enregistrement de session

Le coffre-fort stocke des secrets statiques : mots de passe de comptes locaux, clés privées, jetons d’interface de programmation, clés de récupération et secrets d’équipements anciens. Chaque secret doit avoir un propriétaire technique, une finalité, un périmètre, une date de rotation et une procédure de rupture. Sans ces métadonnées, le coffre devient une cave numérique dont les bouteilles n’ont pas d’étiquette.

Le PAM doit privilégier l’injection de secret dans une session proxifiée plutôt que la révélation du secret à l’opérateur. Pour SSH (Secure Shell), le PAM peut émettre un certificat utilisateur court ou ouvrir un relais authentifié. Pour RDP (Remote Desktop Protocol), il peut fournir une session distante sans afficher le mot de passe de la cible. Révéler un secret reste parfois nécessaire pour un équipement non intégrable ; cette exception doit déclencher une rotation immédiate après usage.

L’enregistrement de session fournit une preuve technique, pas une vérité magique. Une capture de terminal ou d’écran ne capture ni une action effectuée par une API (Application Programming Interface) depuis un autre jeton, ni une décision prise dans une console de fournisseur, ni une commande qui a échoué avant d’atteindre la cible. Il faut corréler l’enregistrement avec les journaux de la cible, les événements d’identité et les traces réseau.

Les enregistrements doivent être chiffrés, horodatés avec une source de temps fiable, indexés par identité et ressource, puis exportés vers un stockage à rétention indépendante. Un SIEM (Security Information and Event Management) peut indexer les événements, mais il ne doit pas être le seul dépositaire des preuves : un administrateur compromis capable d’effacer les traces du SIEM peut transformer la supervision en décoration murale.

La séparation des fonctions est non négociable. L’équipe qui administre une cible ne doit pas pouvoir modifier la politique de session, supprimer les enregistrements ou désactiver l’alerte sur cette même cible. Le compte capable d’administrer le PAM doit être distinct de celui qui approuve les élévations, et les journaux du PAM doivent sortir de son domaine d’administration direct.

Accès JIT : exemple d’élévation temporaire

L’exemple suivant obtient des identifiants temporaires auprès d’AWS Security Token Service pour un rôle d’administration limité. Le rôle cible doit déjà imposer la MFA dans sa politique de confiance, limiter les actions autorisées et refuser les sessions longues. La commande ne remplace pas ces politiques : un jeton temporaire doté de AdministratorAccess reste une tronçonneuse temporaire.

# Obtenir une session temporaire de 15 minutes pour un rôle précis.
# AWS CLI doit être configuré avec une identité source soumise à MFA.
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/JIT-Production-ReadOnly \
  --role-session-name incident-INC-4242 \
  --serial-number arn:aws:iam::123456789012:mfa/identite.nominale \
  --token-code 123456 \
  --duration-seconds 900 \
  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
  --output text > /tmp/jit-creds

# Charger les trois valeurs dans le processus courant, jamais dans un profil persistant.
read AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN < /tmp/jit-creds
export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
rm -f /tmp/jit-creds

# Vérifier l'identité effective avant toute action.
aws sts get-caller-identity

Le fichier temporaire constitue ici un compromis pédagogique. En exploitation, un agent de session doit éviter l’écriture sur disque lorsque c’est possible et nettoyer toute variable d’environnement à la fermeture. Les variables d’environnement sont lisibles par certains processus locaux, outils de diagnostic ou collecteurs mal configurés. Le secret le plus discret du monde devient bavard dès qu’il arrive dans un dump mémoire.

La révocation mérite une attention particulière. Supprimer une appartenance de groupe ou désactiver l’identité source n’annule pas forcément les sessions déjà émises. Les jetons à durée courte réduisent ce délai, mais une action destructive peut être réalisée en quelques secondes. Pour les opérations critiques, prévoir une révocation côté fournisseur, une désactivation de la cible et des limites de permissions qui empêchent la création de nouvelles identités persistantes.

Les politiques d’élévation doivent interdire les capacités qui permettent de contourner le mécanisme lui-même : création de nouvelles clés d’accès, modification de politiques d’approbation, attachement de rôles plus puissants, modification de la journalisation, désactivation des alertes et changement de configuration réseau ouvrant une voie de retour. Les attaques de persistance IAM (Identity and Access Management) se logent précisément dans ces permissions de second ordre. La page architecture cyber complète cette analyse avec les dépendances de sécurité transverses.

Comptes break-glass : secours, pas porte dérobée

Un compte break-glass est un compte de secours utilisé lorsque le chemin nominal est indisponible : panne du fournisseur d’identité, erreur de politique globale, indisponibilité du PAM ou incident empêchant l’authentification habituelle. Il existe parce qu’un système d’administration sans voie de récupération peut devenir indisponible exactement quand une correction urgente est requise.

Ce compte doit être rare, nominativement attribué ou détenu sous double contrôle, protégé par MFA matériel distinct, exclu des synchronisations destructrices et surveillé en temps réel. Ses identifiants ne doivent pas dépendre exclusivement du système qu’il sert à réparer. Conserver le seul second facteur dans le coffre-fort rendu inaccessible par la panne, c’est une procédure de secours écrite au dos d’un extincteur en feu.

Tester un compte break-glass ne signifie pas seulement vérifier qu’il peut se connecter. Le test doit confirmer qu’il peut atteindre le plan de contrôle, effectuer une action limitée, générer des journaux, déclencher une alerte et quitter sans laisser de privilège persistant. Après chaque test, faire tourner les secrets utilisés, vérifier les événements produits et documenter les dépendances rencontrées.

Le test ne doit jamais utiliser le compte dans son mode maximal si une variante contrôlée est possible. Prévoir un environnement isolé ou une action réversible, par exemple la lecture d’une configuration non sensible ou la création puis suppression d’une ressource de test. Si seul le périmètre de production permet de vérifier la récupération, limiter l’opération, obtenir l’approbation prévue et observer les alertes en direct.

Un compte jamais testé n’est pas un mécanisme de reprise. C’est une hypothèse religieuse munie d’un mot de passe expiré.

Plans de contrôle et plans de données

Le plan de contrôle modifie les règles, identités, configurations et ressources : politiques d’accès, comptes, clés, réseau, orchestration et journalisation. Le plan de données transporte ou traite le contenu métier : flux applicatifs, bases de données, objets stockés et messages. Un administrateur du plan de contrôle peut souvent atteindre le plan de données indirectement ; cette capacité doit être réduite, journalisée et justifiée.

La séparation doit être technique, pas seulement organisationnelle. Utiliser des comptes, réseaux d’administration, postes dédiés, rôles et journaux distincts. Un administrateur de cluster ne doit pas automatiquement lire les secrets applicatifs, monter les volumes de production ou ouvrir des shells dans tous les conteneurs. De même, un administrateur de base de données ne doit pas pouvoir modifier la fédération d’identité qui attribue son rôle.

Cette limite réduit le rayon d’explosion d’une compromission : le vol d’un compte d’administration d’infrastructure ne doit pas donner simultanément la capacité de lire les données, de couper les alarmes et de créer une persistance identitaire. Aucun produit ne fournit cette propriété par défaut. Les permissions héritées, les rôles génériques et les comptes de service omnipotents la détruisent avec une efficacité presque artistique.

La supervision doit détecter les franchissements entre plans : création de nouveaux principaux, export de secrets, modification de règles réseau, changement de rétention des journaux, désactivation de chiffrement et accès inhabituel aux données depuis une identité d’administration. Les mécanismes cryptographiques et les limites de clés restent nécessaires, comme décrit dans la section cryptographie : le PAM contrôle qui demande l’accès, il ne remplace ni le chiffrement des données ni la gestion correcte de leurs clés.

🐝 Ce qui arrive si on s’en passe

Sans privilège éphémère ni médiation de session, l’analyse post-incident perd sa borne temporelle : rien ne distingue une action légitime d’une action adverse, puisque le droit existe en permanence et que le journal de la cible ne porte ni motif, ni ticket, ni fenêtre d’usage. Le périmètre d’un incident ne peut plus être réduit, il faut supposer toute la durée de vie du compte compromise et reconstruire large. Les secrets statiques, jamais interceptés par un relais, circulent sur les postes et survivent aux départs, ce qui rend la rotation impossible à déclencher faute de savoir qui les détient. Sans compte de secours éprouvé, une erreur de politique globale ou une panne du fournisseur d’identité supprime toute voie de correction, et la remise en service dépend d’un recours externe au délai non maîtrisé.

🦫 Explication de la marmotte 🍫

Les personnes qui administrent des systèmes ont parfois le pouvoir de modifier les règles, lire des données ou arrêter des services. Garder ce pouvoir en permanence augmente le risque : si le compte ou l’ordinateur de cette personne est compromis, l’attaquant peut agir tout de suite et longtemps.

Le système de gestion des accès sensibles fonctionne en plusieurs temps. Une personne s’identifie avec plusieurs preuves d’identité, puis demande un droit précis pour une durée limitée. Le système vérifie les règles, demande parfois une validation, puis délivre un accès temporaire. Cet accès expire automatiquement. Les actions réalisées pendant la session sont enregistrées et leurs traces sont envoyées dans un espace que l’administrateur de la cible ne peut pas facilement modifier.

Les mots de passe et clés techniques sont conservés dans un espace protégé. Ils sont transmis au système cible sans être affichés lorsque cela est possible. Après une utilisation exceptionnelle, ils doivent être remplacés.

Un compte de secours existe pour réparer le système lorsque le chemin habituel tombe en panne. Il doit être testé régulièrement avec une action limitée, car un compte non testé peut être bloqué, expiré ou privé du second moyen de connexion au moment de l’incident.

Enfin, les personnes qui modifient les règles d’administration ne doivent pas pouvoir automatiquement lire toutes les données. Cette séparation limite ce qu’un compte compromis peut détruire ou voler.

Pages voisines

La citent

PAM, JIT et comptes break-glass sécurisés

Elle cite

PAM, JIT et comptes break-glass sécurisés

PAM, JIT et comptes break-glass sécurisés

PAM moderne : le privilège doit être éphémère

Coffre-fort de secrets et enregistrement de session

Accès JIT : exemple d’élévation temporaire

Comptes break-glass : secours, pas porte dérobée

Plans de contrôle et plans de données

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines