Accès juste-à-temps — comment éliminer les privilèges permanents en entreprise
La plupart des incidents de sécurité en entreprise impliquant des accès à privilèges ont une cause fondamentale commune : le compte compromis disposait d'un accès dont il n'avait pas besoin, à des systèmes qu'il n'avait pas touchés depuis des semaines, avec des identifiants valides depuis des mois. L'attaquant n'a pas escaladé les privilèges — les privilèges étaient déjà là, permanents, en attente. C'est le problème des privilèges permanents, et l'accès juste-à-temps est conçu précisément pour combler cette lacune.
Qu'est-ce que l'accès juste-à-temps — et en quoi diffère-t-il du PAM traditionnel
Le PAM traditionnel fonctionne selon le modèle coffre-fort et extraction. Les identifiants à privilèges sont stockés dans un coffre-fort. Lorsqu'un administrateur système a besoin d'accès, il extrait les identifiants, se connecte au système cible et retourne les identifiants une fois terminé. C'est mieux que les tableurs partagés et les post-its, mais cela présente toujours un problème structurel fondamental : le compte à privilèges lui-même existe en permanence dans le système cible. Le compte Administrator sur un serveur Windows, le compte root sur un hôte Linux, le compte sa dans la base de données — ces comptes sont toujours présents, toujours actifs, toujours une cible.
L'accès juste-à-temps (JIT) adopte une approche différente : éliminer complètement le compte permanent ou au moins s'assurer que le compte est désactivé et les identifiants sont alternés immédiatement avant et après chaque utilisation. L'accès est accordé à la demande pour un utilisateur spécifique, une cible spécifique et une fenêtre de temps spécifique. Lorsque la fenêtre expire, l'accès est automatiquement révoqué — pas remis dans le coffre-fort, mais supprimé.
Le principe Zero Standing Privileges (ZSP) va plus loin : aucun compte à privilèges ne devrait avoir un accès permanent à un système de production. Chaque session à privilèges est une attribution temporaire avec un début défini, une fin définie et un journal d'audit complet. Lorsqu'aucune session n'est active, aucun accès à privilèges n'existe.
La différence pratique entre le PAM traditionnel et JIT/ZSP :
- PAM traditionnel : Le groupe
Domain Adminsa 15 membres. Les identifiants sont dans le coffre-fort. Les membres extraient les identifiants en cas de besoin. Les comptes existent 24h/24 sur chaque serveur joint au domaine. - PAM JIT : Pas d'appartenance permanente à
Domain Admins. Lorsqu'un administrateur système a besoin d'un accès élevé, il soumet une demande : « J'ai besoin d'un accès administrateur RDP à prod-db-03 pour 4 heures pour appliquer le correctif trimestriel. » La demande est examinée par son manager et un membre de l'équipe de sécurité via un workflow d'approbation Slack. Une fois approuvé, le système alloue un identifiant temporaire limité à ce serveur spécifique. La session est automatiquement enregistrée du début à la fin. Après 4 heures, l'accès est révoqué et l'identifiant est alternée.
La surface d'attaque dans le modèle traditionnel est chaque moment où le compte existe, par rapport à chaque système qu'il peut atteindre. La surface d'attaque dans le modèle JIT est la durée de la session approuvée, par rapport à la cible approuvée spécifique.
Avant JIT vs après JIT — un scénario concret
Avant JIT : Un administrateur système senior dans une entreprise de 500 personnes travaille dans l'équipe depuis quatre ans. Il est membre permanent du groupe Domain Admins et dispose d'un accès administrateur RDP permanent à environ 200 serveurs — développement, staging et production. Il utilise activement cet accès pour peut-être 20 serveurs régulièrement. Les 180 autres sont des infrastructures qu'il a configurées lors d'une migration et n'a pas touchées depuis. Ses identifiants sont dans le SSO d'entreprise, son compte n'a jamais été revu pour réduction de périmètre, et son accès n'a pas changé depuis son arrivée.
Lorsque son laptop est compromis par une attaque de phishing ciblée, l'attaquant dispose d'un accès immédiat, permanent et incontesté à tous les 200 serveurs. Le rayon d'impact est l'ensemble de l'infrastructure.
Après JIT : Le même administrateur n'a pas d'accès à privilèges permanent. Lorsqu'il doit effectuer une maintenance sur un serveur de production spécifique, il soumet une demande. La demande est examinée par son manager et un membre de l'équipe de sécurité. Après approbation, le système alloue un identifiant temporaire limité à ce serveur spécifique. La session est automatiquement enregistrée du début à la fin. Après 4 heures, l'accès est révoqué et l'identifiant est alternée.
Lorsque son laptop est compromis, l'attaquant a accès à toutes les sessions actives qui existent à ce moment. Si aucune session n'est actuellement approuvée et active, l'attaquant n'a aucun accès à privilèges à un système de production. Le rayon d'impact est limité par ce qui était approuvé et actif au moment de la compromission — pas l'ensemble de la surface d'accès historique de la carrière de l'administrateur.
Accès JIT et conformité — comment ZSP s'applique à NIS2, SOC 2 et ISO 27001
L'accès JIT et les Zero Standing Privileges ne sont pas seulement de bonnes pratiques de sécurité — ils deviennent des exigences de plus en plus explicites dans les frameworks de conformité que les entreprises d'Europe centrale et d'Europe doivent respecter.
NIS2 Art. 21 — principe du moindre privilège : NIS2 exige que les entités essentielles mettent en œuvre un contrôle d'accès basé sur le principe du moindre privilège. « Moindre privilège » dans le contexte NIS2 signifie que l'accès ne doit être accordé que dans la mesure nécessaire pour accomplir une tâche spécifique. L'accès administrateur permanent à 200 serveurs ne satisfait pas ce critère par définition — un administrateur qui utilise régulièrement 20 de ces serveurs dispose d'un accès permanent aux 180 dont il n'a pas besoin. L'accès JIT applique structurellement le principe du moindre privilège : l'accès est toujours limité à un système spécifique et à une fenêtre de temps correspondant au besoin réel.
SOC 2 CC6.3 — révocation des accès : Les Trust Service Criteria SOC 2 exigent que l'accès soit supprimé rapidement lorsqu'il n'est plus requis. CC6.3 couvre spécifiquement la révocation des accès lors de fins de contrat, de changements de rôle et de fins de projet. L'accès JIT satisfait automatiquement CC6.3 : l'accès expire à la fin de la fenêtre de temps approuvée sans aucune étape manuelle de révocation. La question de l'auditeur — « Comment assurez-vous que l'accès est supprimé lorsqu'il n'est plus nécessaire ? » — a une réponse déterministe : « Il expire automatiquement ; voici le journal d'audit de chaque expiration de session. »
ISO 27001 Annexe A.9.2 — attribution des accès : ISO 27001 A.9.2.2 exige un processus formel d'attribution des accès, et A.9.2.3 exige que les droits d'accès à privilèges soient accordés sur la base du « besoin d'utilisation ». « Besoin d'utilisation » est la formulation ISO 27001 pour le principe du moindre privilège et correspond directement au JIT : l'accès devrait exister lorsqu'il est nécessaire et ne pas exister lorsqu'il ne l'est pas. A.9.2.5 exige des révisions périodiques des droits d'accès des utilisateurs — avec l'accès JIT, la révision est continue plutôt que périodique, car l'accès est réattribué à partir de zéro pour chaque session.
L'argument de conformité pour le JIT est simple : les privilèges permanents sont structurellement incompatibles avec le principe du moindre privilège que NIS2, SOC 2 CC6.3 et ISO 27001 A.9.2 exigent. Le JIT est le modèle d'implémentation qui rend le principe du moindre privilège opérationnellement viable à grande échelle.
Comment VaultPAM implémente l'accès JIT
VaultPAM implémente l'accès JIT grâce à quatre mécanismes intégrés :
Workflows d'approbation : Lorsqu'un utilisateur demande un accès à privilèges à un système cible, VaultPAM achemine la demande vers l'approbateur approprié — manager, équipe de sécurité ou les deux, selon le niveau d'accès et la sensibilité du système. Les approbations peuvent être effectuées via l'interface web VaultPAM ou des canaux de notification intégrés. La demande contient le système cible, la durée demandée et la justification, donnant à l'approbateur le contexte pour prendre une décision éclairée.
Sessions à durée limitée : Chaque attribution d'accès approuvée contient une date d'expiration ferme. La fenêtre de session est définie au moment de l'approbation — 1 heure, 4 heures, 8 heures ou une durée personnalisée jusqu'au maximum de la politique. Lorsque la fenêtre de session expire, VaultPAM révoque automatiquement l'accès. Il n'y a pas d'étape manuelle, pas d'e-mail de rappel, pas de dépendance vis-à-vis de la déconnexion de l'utilisateur. L'accès cesse simplement d'exister.
Expiration automatique et rotation des identifiants : Pour les sessions RDP et SSH, VaultPAM alloue un identifiant spécifique à la session au début de la fenêtre approuvée et le fait pivoter à l'expiration. L'identifiant qui existait pour la session approuvée ne fonctionne plus après l'expiration. Un attaquant qui intercepte des identifiants pendant une session ne peut pas les réutiliser après la fermeture de la fenêtre.
Journal d'audit : Chaque demande JIT — soumission, approbation ou refus, début de session, durée de session, enregistrement de session et expiration — est enregistrée dans le journal d'audit immuable de VaultPAM. Le journal d'audit contient l'identité de l'approbateur, l'horodatage de l'approbation, le texte de justification et l'enregistrement complet de l'activité de session. C'est le pack de preuves qui répond aux exigences d'audit NIS2, à l'échantillonnage des auditeurs SOC 2 et aux contrôles par sondage ISO 27001.