Mettre en place un accès JIT AWS pour comptes à privilèges

Mettre en place un accès JIT AWS pour comptes à privilèges

L’accès JIT (Just-In-Time, juste-à-temps) retire les privilèges permanents et ne les accorde que pour une fenêtre limitée, justifiée et tracée. Le compromis est net : on réduit drastiquement la durée exploitable d’un compte compromis, mais on paie par un workflow d’élévation qui doit rester disponible, auditable et difficile à contourner.

Explication de la marmotte

Un accès temporaire ressemble à la remise d’un passe-partout à l’accueil d’un immeuble : il permet d’ouvrir certaines portes pendant un temps donné, puis cesse de fonctionner. Le but est d’éviter que chaque personne conserve indéfiniment une clé qui ouvre la salle des machines.

→ Lire l’explication complète de la marmotte

Architecture JIT AWS et prérequis de plateforme

Ce guide cible AWS (Amazon Web Services) avec IAM (Identity and Access Management) Identity Center comme point d’entrée humain. Le modèle retenu sépare trois identités :

1. un groupe permanent Cloud-Users, sans privilège d’administration ;
2. un groupe temporaire JIT-Administrators, auquel aucun humain n’est affecté par défaut ;
3. un permission set JIT-Administrator, affecté au groupe temporaire et limité dans le temps.

Le permission set est un modèle de droits distribué par IAM Identity Center dans chaque compte AWS cible. AWS crée alors un rôle IAM fédéré du type AWSReservedSSO_JIT-Administrator_*. Ce rôle doit être distinct des rôles usuels d’exploitation. Mélanger le rôle permanent et le rôle JIT revient à installer une serrure sur une porte déjà ouverte. Le diagramme de slide reste élégant, le contrôle ne sert plus à grand-chose.

Prévoir avant toute configuration :

• IAM Identity Center activé dans la région choisie ;
• un fournisseur d’identité fédéré avec authentification multifacteur, ou MFA (Multi-Factor Authentication), obligatoire pour les comptes humains ;
• AWS Organizations et, idéalement, une unité organisationnelle dédiée aux comptes de production ;
• CloudTrail organisationnel activé dans toutes les régions, avec journalisation des événements de gestion ;
• AWS Config activé pour détecter les modifications de rôles, politiques et permission sets ;
• un compte de sécurité distinct, avec accès en lecture aux journaux ;
• une source d’heure fiable : les corrélations entre demande, approbation, attribution et action reposent sur l’horodatage.

Le rôle JIT ne doit pas recevoir AdministratorAccess par réflexe. Pour les opérations d’urgence, une politique d’administration contrôlée peut être admise, mais seulement dans des comptes explicitement désignés et avec une durée maximale d’une heure. Pour l’exploitation courante, créer des permission sets spécialisés : administration Kubernetes, gestion réseau, réponse à incident, lecture de journaux. Le principe du moindre privilège ne devient pas facultatif parce que le privilège expire.

La gestion des identités et la détection de persistance décrite dans l’analyse IAM AWS restent nécessaires. Le JIT limite une session valide, il ne corrige ni une politique de confiance permissive ni un rôle capable de créer son propre successeur.

Créer le rôle temporaire IAM Identity Center

Commencer par récupérer les identifiants de l’instance IAM Identity Center et du compte cible. La commande suivante crée un permission set administratif temporaire avec une session maximale d’une heure. Elle suppose AWS CLI (Command Line Interface) version 2, un profil disposant de droits d’administration IAM Identity Center, et une politique gérée AWS déjà évaluée.

# Identifier l'instance IAM Identity Center active.
aws sso-admin list-instances \
  --query 'Instances[0].[InstanceArn,IdentityStoreId]' \
  --output text

# Créer un permission set JIT limité à une heure.
aws sso-admin create-permission-set \
  --instance-arn "arn:aws:sso:::instance/ssoins-EXEMPLE" \
  --name "JIT-Administrator" \
  --description "Élévation temporaire approuvée, journalisée et limitée" \
  --session-duration "PT1H"

# Attacher la politique AWS d'administration.
# À réserver aux comptes explicitement classés comme sensibles.
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn "arn:aws:sso:::instance/ssoins-EXEMPLE" \
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-EXEMPLE/ps-EXEMPLE" \
  --managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"

# Affecter le groupe temporaire au compte AWS de production.
aws sso-admin create-account-assignment \
  --instance-arn "arn:aws:sso:::instance/ssoins-EXEMPLE" \
  --target-id "123456789012" \
  --target-type AWS_ACCOUNT \
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-EXEMPLE/ps-EXEMPLE" \
  --principal-type GROUP \
  --principal-id "GROUP_ID_JIT_ADMINISTRATORS"

L’affectation du groupe au compte peut rester permanente : ce sont les membres du groupe qui doivent être éphémères. Cette structure réduit la propagation à chaque demande et évite de modifier le catalogue de permission sets à la volée. En revanche, elle impose une règle dure : aucun mécanisme permanent ne doit pouvoir ajouter un membre à JIT-Administrators sans produire une demande, une approbation et une échéance.

Configurer également MaxSessionDuration à une heure sur le rôle IAM provisionné si AWS autorise cette modification dans le modèle retenu. La durée du permission set contrôle la session fédérée, mais la session STS (Security Token Service) réellement obtenue doit être vérifiée. Une durée déclarée dans un portail et une durée constatée dans un jeton sont deux choses différentes. L’une rassure, l’autre protège.

Workflow d’approbation et révocation automatique

IAM Identity Center ne fournit pas, à lui seul, un moteur d’approbation métier complet. Laisser croire l’inverse produit souvent un formulaire de ticket décoratif et une adhésion manuelle au groupe. Cette dernière contourne le contrôle exactement au moment où celui-ci devrait exister.

Déployer un workflow avec les composants suivants :

1. une API (Application Programming Interface) interne de demande, protégée par l’identité fédérée ;
2. une table DynamoDB contenant demandeur, justification, compte, permission set, approbateur, date d’expiration et identifiant de corrélation ;
3. une machine d’état AWS Step Functions pour appliquer les transitions REQUESTED, APPROVED, ACTIVE, EXPIRED et REVOKED ;
4. une fonction Lambda exécutant l’ajout et le retrait du membre dans le groupe temporaire ;
5. Amazon EventBridge Scheduler planifiant la révocation à l’heure exacte ;
6. une notification vers le canal d’astreinte ou l’outil de gestion des demandes.

L’approbateur doit être distinct du demandeur. Pour les privilèges permettant de modifier IAM, les politiques de contrôle de service, ou SCP (Service Control Policy), imposer une double approbation ou un groupe d’approbateurs indépendant de l’équipe opératrice. Un rôle qui peut créer des clés d’accès, modifier une politique de confiance ou appeler iam:PassRole peut souvent reconstruire une persistance. L’élévation JIT réduit la fenêtre, elle ne transforme pas ces actions en chocolat inoffensif.

L’action Lambda d’activation ajoute le principal au groupe temporaire, consigne l’identifiant de demande dans DynamoDB, puis crée immédiatement une planification de retrait. L’action de révocation retire le principal, annule la planification, enregistre le résultat et alerte si l’opération échoue. Prévoir trois tentatives avec temporisation exponentielle, puis une alarme humaine. Une révocation en échec ne doit jamais finir dans une file morte silencieuse, cet endroit où les incidents vont prendre leur retraite.

La révocation d’appartenance ne tue pas les sessions AWS déjà émises. C’est la limite structurante du mécanisme : l’accès aux nouvelles sessions est bloqué, mais un jeton STS existant reste valable jusqu’à son expiration. Fixer une session maximale courte est donc obligatoire. Pour des privilèges d’administration, une heure est un plafond raisonnable ; quinze à trente minutes conviennent mieux aux opérations ciblées.

Vérifier l’expiration et l’audit CloudTrail

Tester le flux de bout en bout avant d’accorder le moindre privilège réel. Créer une demande avec une durée de cinq minutes dans un compte de test, l’approuver, ouvrir une session, exécuter une action de lecture, attendre l’échéance, puis vérifier deux propriétés distinctes :

1. le groupe temporaire ne contient plus le demandeur ;
2. la session déjà ouverte cesse d’autoriser les appels au plus tard à l’expiration configurée.

Tester aussi les échecs : refus d’approbation, Lambda indisponible, planification EventBridge supprimée, suppression manuelle du groupe, tentative de prolongation concurrente. Un contrôle de sécurité qui ne survit qu’au chemin heureux appartient aux démonstrations commerciales, avec les plantes vertes et les graphiques sans axes.

CloudTrail doit conserver au minimum les événements suivants :

• CreateAccountAssignment, DeleteAccountAssignment et appels IAM Identity Center associés ;
• AddMemberToGroup et RemoveMemberFromGroup côté Identity Store ;
• AssumeRole et Federate pour l’obtention effective des droits ;
• les appels sensibles réalisés avec le rôle JIT, notamment modifications IAM, réseau, chiffrement ou journalisation.

Ajouter dans chaque demande un identifiant immuable, transmis dans les journaux applicatifs du workflow et dans les événements de notification. CloudTrail ne stocke pas nativement la justification métier dans chaque appel AWS exécuté après élévation. La revue doit donc corréler l’identité fédérée, l’heure, le rôle assumé et l’identifiant de demande conservé par le workflow.

Protéger les journaux contre l’altération : compte de journalisation séparé, chiffrement, rétention définie, validation d’intégrité CloudTrail, alertes sur StopLogging, DeleteTrail, modification de destination ou suppression de règles EventBridge. L’accès JIT ne garantit pas qu’un administrateur temporaire n’efface pas les traces si les droits le permettent. Cette garantie doit venir de la séparation des comptes, des SCP et de contrôles de détection indépendants.

🐝 Ce qui arrive si on s’en passe

Sans élévation temporaire, les privilèges d’administration restent attachés en permanence à des identités humaines : un vol d’identifiants ou un détournement de session ouvre une fenêtre d’exploitation qui ne se referme qu’au moment où quelqu’un s’en aperçoit. Les départs, changements de poste et missions ponctuelles laissent des droits résiduels que plus aucune échéance ne retire. Côté détection, l’activité administrative devient un bruit de fond constant : il n’existe plus de signal distinguant une opération exceptionnelle d’une routine, et aucun identifiant de demande ne permet de rattacher un appel sensible à une justification et à un approbateur. Lors d’une investigation, délimiter la portée d’une compromission suppose alors de reconstituer manuellement qui disposait de quoi, à quelle date, sans borne temporelle fiable. La revue périodique se réduit à un inventaire de comptes privilégiés permanents, sans preuve d’usage légitime.

🦫 Explication de la marmotte 🍫

L’accès temporaire commence avec un compte normal, qui ne possède pas les droits les plus dangereux. Lorsqu’une opération exceptionnelle est nécessaire, la personne envoie une demande indiquant le compte concerné, la raison et la durée voulue. Une autre personne autorisée examine cette demande. Si elle est refusée, aucun droit supplémentaire n’est donné.

Si elle est acceptée, un programme ajoute temporairement la personne à un groupe spécial. Ce groupe donne accès à un rôle contenant les droits demandés. La personne ouvre alors une nouvelle session pour utiliser ces droits. Cette session possède une heure de fin définie à l’avance.

Au même moment, le système programme le retrait automatique de la personne du groupe spécial. À l’heure prévue, le retrait est exécuté même si personne ne pense à le faire. Si cette opération échoue, une alerte doit prévenir une équipe capable de corriger le problème.

Le retrait du groupe bloque les nouvelles connexions avec ces droits. Une connexion déjà ouverte peut toutefois rester active jusqu’à son heure de fin. C’est pourquoi sa durée doit être courte.

Chaque demande, approbation, ajout au groupe, retrait et action réalisée est enregistrée dans les journaux du fournisseur cloud. Une revue peut alors vérifier qui a obtenu des droits élevés, pendant combien de temps, pour quelle raison et quelles actions ont été exécutées.

À lire aussi

• Configurer GitHub Actions OIDC vers AWS sans clé statiqueGuide pratique pour fédérer une identité GitHub Actions vers AWS avec OpenID Connect et des rôles temporaires strictement limités à un dépôt et une branche.
• Détecter la persistance IAM dans AWSCatalogue de détection des techniques de persistance IAM dans AWS, incluant rôles de confiance, clés d'accès dormantes et fonctions déclenchées à intervalle.
• PAM, JIT et comptes break-glass sécurisésConcevoir une gestion des privilèges moderne avec coffre-fort de secrets, accès juste-à-temps, sessions enregistrées, comptes de secours et séparation des plans de contrôle.
• Auditer les comptes orphelins Active DirectoryMéthode pas-à-pas pour détecter, qualifier et traiter les comptes orphelins et les droits excessifs dans un annuaire d’entreprise.

Pages voisines

La citent

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

Mettre en place un accès JIT AWS pour comptes à privilèges

Elle cite

• ⇄Lien dans les deux sens :Comment automatiser la recertification des accès sensibles
• ⇄Lien dans les deux sens :Configurer le moindre privilège sur un compte cloud existant
• Accès juste-à-temps et privilèges temporaires

⇄ : les deux pages se citent l’une l’autre.