Vault PAM et enregistrement des sessions admin

Un PAM (Privileged Access Management, gestion des accès privilégiés) retire les identifiants d’administration des mains humaines et place un intermédiaire contrôlé entre l’opérateur et la cible. Le compromis est net : on gagne en révocation, traçabilité et rotation, mais on concentre une puissance extrême dans le vault et dans ses mécanismes d’exploitation.

→ Lire l’explication complète de la marmotte

Vault PAM : le secret ne doit pas devenir une information humaine

Un vault PAM stocke les identifiants à privilèges, comptes locaux, comptes de domaine, clés privées, jetons d’interface de programmation et certificats d’administration. Sa fonction déterminante n’est pas de chiffrer une base de mots de passe. Un chiffrement au repos sans contrôle d’usage produit seulement une boîte noire très coûteuse à ouvrir après compromission.

Le modèle à retenir est celui de l’injection : l’opérateur s’authentifie au PAM avec son identité nominative, reçoit une autorisation limitée, puis le broker PAM établit la session vers la cible avec le secret. Le mot de passe ou la clé privée n’est pas affiché, copié dans un presse-papiers ni transmis dans un ticket. L’opérateur reçoit une session, pas une connaissance réutilisable.

Cette distinction change la réponse à un départ, à une compromission de poste ou à une révocation urgente. Désactiver l’identité nominative coupe les nouvelles ouvertures de session sans devoir retrouver toutes les copies du secret, parce qu’il ne devrait pas en exister. C’est la frontière qui sépare un PAM d’un gestionnaire de mots de passe d’équipe.

Un gestionnaire d’équipe distribue un secret partagé à plusieurs personnes. Même avec authentification multifacteur, ou MFA (Multi-Factor Authentication), chaque consultation crée une possibilité de copie : navigateur compromis, extension hostile, presse-papiers, historique, mémoire du processus ou photographie très analogique d’un écran très numérique. Une rotation ultérieure invalide le secret, mais ne retire pas ce qui a déjà été lu.

Le vault PAM doit préférer les identifiants éphémères quand la cible le permet : certificat Secure Shell, ou SSH (Secure Shell), de courte durée, jeton à durée de vie limitée, ou compte créé pour une demande donnée. Lorsqu’un compte statique est imposé par un équipement ancien, la rotation après usage devient obligatoire. Elle ne doit toutefois démarrer qu’après fermeture vérifiée de la session. Modifier le mot de passe pendant qu’un processus de sauvegarde l’utilise reste un excellent moyen de découvrir qu’une restauration dépendait d’un compte oublié. L’infrastructure adore ce genre de poésie.

La rotation automatique dépend de trois faits souvent cachés dans les démonstrations : le connecteur doit connaître la procédure de changement propre à la cible, le compte utilisé pour effectuer ce changement doit rester disponible, et les dépendances applicatives doivent être recensées. Un mot de passe de service changé sans mise à jour de son consommateur transforme une mesure de sécurité en incident de disponibilité. La rotation n’est donc pas une case dans une console, c’est un contrat d’intégration.

Les politiques d’accès doivent combiner identité nominative, rôle, cible, créneau temporel, justification et éventuellement approbation. Une approbation n’est pas une preuve de nécessité, seulement la preuve qu’une personne a cliqué. Pour les comptes de rupture, l’accès doit être exceptionnel, horodaté, enregistré et suivi d’une rotation immédiate.

Les contrôles d’identité du PAM prolongent les mécanismes décrits dans la section identités et accès. Un vault ne corrige ni une fédération permissive ni un annuaire exposant des comptes techniques sans gouvernance.

Exemple : accès SSH injecté par un bastion PAM

L’exemple suivant configure un client SSH pour joindre une cible via un bastion PAM. Le secret de la cible reste géré par le bastion : la station de travail ne reçoit ni mot de passe ni clé privée de l’administrateur cible. La configuration est reproductible dès lors que le bastion accepte l’authentification nominative et que la cible est déclarée dans sa politique.

# Le compte local de l'opérateur s'authentifie sur le bastion PAM.
Host pam-bastion
    HostName pam-gateway.infra.example
    User alice.admin
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_ed25519_alice

# La cible n'est jamais atteinte directement depuis le poste.
# Le bastion ouvre la connexion cible et injecte le secret autorisé.
Host prod-db-01
    HostName prod-db-01.infra.example
    User root
    ProxyJump pam-bastion
    RequestTTY force

L’ouverture avec ssh prod-db-01 doit déclencher une vérification de politique côté bastion. En production, l’identité alice.admin ne doit pas être un compte générique, et la clé locale doit idéalement être protégée par un jeton matériel ou un certificat court. Le fichier de configuration n’est pas un contrôle de sécurité : il indique un chemin réseau. Le bastion doit refuser toute connexion directe qui contourne ce chemin, au moyen de règles réseau et de comptes cibles non utilisables depuis les sous-réseaux utilisateurs.

Un proxy SSH ne peut pas injecter une clé privée si la cible exige que cette clé soit présente sur le poste opérateur. Dans ce cas, il faut revoir le modèle d’authentification, par exemple avec des certificats SSH signés par une autorité interne. Transporter la clé du compte root vers les postes au nom de la compatibilité est une dette qui finit toujours par produire des intérêts composés.

Enregistrement de session : preuve partielle, pas machine à remonter le temps

Le PAM peut journaliser les frappes clavier, les commandes interprétées et le flux vidéo d’une session distante. Le keystroke logging enregistre les entrées envoyées au terminal, avec horodatage et identité. Le replay vidéo conserve l’affichage de protocoles graphiques, notamment Remote Desktop Protocol, ou RDP. Ces deux sources ne répondent pas à la même question.

Les frappes permettent de rechercher une commande, de reconstruire une séquence et d’alimenter une détection : création d’un compte, modification d’un fichier sensible, extraction d’archive, désactivation d’un agent. Elles ne prouvent pas toujours l’effet réel. Une commande peut échouer, être modifiée par un alias, lancer un script distant ou produire une sortie tronquée.

Le replay vidéo montre le contexte affiché, les fenêtres ouvertes et les interactions graphiques. Il coûte davantage en stockage, complique l’indexation et peut capturer des données personnelles, des mots de passe affichés ou des informations commerciales. Filmer tout sans politique de conservation produit un deuxième problème de sécurité, avec un budget disque en prime.

L’enregistrement exige que le PAM termine effectivement la session. Un tunnel chiffré de bout en bout entre le poste et la cible, par exemple une connexion TLS (Transport Layer Security) que le bastion ne termine pas, empêche le bastion d’inspecter le contenu. Il pourra enregistrer les métadonnées de connexion, pas les commandes ni l’écran. Ce n’est pas un défaut du produit : déchiffrer sans posséder le point de terminaison relèverait davantage de la séance de spiritisme que de l’architecture réseau.

Le même problème apparaît avec un terminal local non enregistré. Si un administrateur ouvre une console physique, utilise une interface hors bande, récupère une clé depuis un cache local ou accède à un compte déjà ouvert, le replay PAM ne voit rien. Les journaux du système cible, les traces de l’hyperviseur, la supervision réseau et les journaux de l’outil d’administration restent nécessaires. Un enregistrement PAM complète la journalisation, il ne la remplace pas.

La confidentialité interne doit être traitée avant l’activation généralisée : périmètres enregistrés, motifs d’accès, rôles autorisés à consulter les replays, chiffrement, durée de rétention et journal d’accès aux enregistrements. L’équipe de sécurité ne doit pas pouvoir parcourir les sessions comme une vidéothèque. L’accès aux preuves nécessite un motif d’investigation et une séparation des rôles entre administration du PAM, approbation et consultation.

Vault compromis : scénario catastrophe et contre-mesures

La compromission d’un vault peut livrer la capacité de devenir administrateur partout, parfois sans générer de nouvelle alerte visible. Un attaquant qui contrôle le plan d’administration peut modifier les politiques, créer une identité de secours, extraire les secrets, falsifier les journaux ou attendre la prochaine rotation. Le vault n’est pas un coffre parmi d’autres : c’est souvent la serrure centrale du système d’information.

Les secrets doivent être chiffrés avec des clés de données, ou DEK (Data Encryption Key), elles-mêmes protégées par une clé de chiffrement de clés, ou KEK (Key Encryption Key). La KEK doit résider dans un HSM (Hardware Security Module), module matériel qui exécute les opérations cryptographiques sans exporter la clé maîtresse. Le HSM ne rend pas le vault invincible. Il réduit l’impact d’un vol de base ou d’un dump mémoire, ce qui est déjà un progrès moins glamour qu’une slide de zero trust, mais nettement plus concret.

Le scellement matériel doit empêcher le démarrage automatique du vault après vol ou duplication de ses données. Un mécanisme de déverrouillage par quorum impose plusieurs fragments ou approbations indépendantes pour libérer la capacité cryptographique. Le quorum doit réunir des rôles distincts, pas trois comptes appartenant à la même équipe d’exploitation. Sinon, l’effet obtenu est surtout décoratif, comme un cadenas sur une porte ouverte.

La séparation des privilèges doit être stricte :

l’administrateur de plateforme maintient le service sans lire les secrets ;
l’administrateur de sécurité définit les politiques sans extraire les données ;
l’approbateur autorise un accès sans administrer le vault ;
l’auditeur consulte des traces sans modifier leur rétention.

Les sauvegardes doivent contenir les données chiffrées, les politiques, les configurations de connecteurs, les clés publiques, les paramètres de scellement et la documentation de reprise. Une sauvegarde du stockage sans moyens de déverrouillage est un presse-papier chiffré. Inversement, sauvegarder les fragments de déverrouillage dans le même domaine de sécurité annule le mécanisme.

La reprise doit être testée sur un environnement isolé : restauration, déverrouillage par quorum, connexion à une cible non critique, vérification des journaux et rotation des comptes restaurés. Après restauration d’un vault, supposer que les secrets contenus dans la copie peuvent avoir été exposés pendant l’incident. La rotation post-reprise est une condition de retour au service, pas une amélioration à planifier un trimestre plus tard.

Le scellement matériel s’appuie sur les fondations cryptographiques détaillées dans les modules matériels et PKCS#11. Le réseau du vault mérite également une segmentation dédiée : interfaces d’administration, cibles gérées, service de journalisation et HSM ne doivent pas partager le même chemin que les postes bureautiques.

🐝 Ce qui arrive si on s’en passe

Sans coffre ni injection, les identifiants d’administration circulent sous leur forme réutilisable : fichiers de configuration, scripts de déploiement, tickets, feuilles de reprise d’astreinte. Ils survivent aux départs, aux changements de prestataire et aux postes réformés, puisqu’aucun inventaire ne dit qui les détient. L’action passe alors par des comptes partagés (root, administrateur local, compte de service), ce qui casse l’attribution : une modification constatée sur une cible ne se rattache plus à une personne, seulement à un mot de passe connu de plusieurs. Sans enregistrement de session, le périmètre d’un incident se reconstruit à partir des seules traces laissées par la cible, souvent partielles ou effaçables par le compte utilisé. La question devient donc non pas ce qui a été fait, mais tout ce qu’il faut reconstruire par précaution, faute de preuve exploitable.

🦫 Explication de la marmotte 🍫

Un système de gestion des accès privilégiés garde les mots de passe, clés et autres preuves d’accès utilisées pour administrer des serveurs. Une personne commence par se connecter avec son propre compte. Le système vérifie ensuite si cette personne a le droit d’atteindre une machine précise, pendant une période donnée et pour une raison acceptée.

Si l’accès est autorisé, le système ouvre la connexion vers la machine cible et fournit lui-même le secret nécessaire. La personne obtient un terminal ou un écran d’administration, mais ne lit pas le mot de passe. Après la session, le système peut changer automatiquement ce mot de passe. Cette étape échoue si la machine cible ne permet pas le changement, si un programme utilise encore l’ancien mot de passe ou si les réglages du programme ne sont pas mis à jour.

Le système peut aussi enregistrer les touches saisies et l’écran affiché. Cela aide à comprendre une action après un incident. Il ne voit toutefois pas une session qui passe directement entre un poste et une machine, ni une console locale. Les journaux de la machine et du réseau restent donc nécessaires.

Le coffre qui garde tous les secrets est une cible majeure. S’il est contrôlé par un attaquant, beaucoup de machines peuvent être contrôlées à leur tour. Il faut chiffrer ses données, protéger ses clés dans du matériel dédié, exiger plusieurs personnes pour le déverrouiller, limiter les droits et tester la restauration des sauvegardes.

Pages voisines

La citent

Vault PAM et enregistrement des sessions admin

Elle cite

Vault PAM et enregistrement des sessions admin

Vault PAM et enregistrement des sessions admin

Vault PAM : le secret ne doit pas devenir une information humaine

Exemple : accès SSH injecté par un bastion PAM

Enregistrement de session : preuve partielle, pas machine à remonter le temps

Vault compromis : scénario catastrophe et contre-mesures

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines