Le mode break-glass en production : automatiser l’exception sans contourner la sécurité
Mettre en place un accès break-glass traçable et temporaire pour intervenir en production sans créer de contournement permanent.
Un accès break-glass doit fournir une voie d’urgence vers la production sans devenir un passe-droit permanent. Utilisez une élévation nominative, limitée dans le temps et au périmètre nécessaire, journalisée indépendamment et revue après chaque usage.
L’absence de voie d’urgence est aussi risquée : une panne d’identité, une erreur de politique IAM ou l’indisponibilité du pipeline de déploiement peuvent empêcher les opérateurs légitimes de restaurer le service. Le dispositif doit donc permettre une dérogation, mais en vérifiant quatre points : identité, durée, périmètre et preuve.
Définir les usages et les règles minimales
Définissez les scénarios couverts : perte d’accès à l’outil d’identité, indisponibilité du déploiement, incident de sécurité exigeant une révocation immédiate ou panne imposant une action hors automatisation. « Accès admin en cas de besoin » n’est pas un scénario suffisant.
- Accès nominatif : l’opérateur utilise son identité habituelle avec une élévation temporaire ; évitez les comptes administrateur partagés.
- Expiration automatique : le privilège expire sans action manuelle, et toute prolongation exige une nouvelle demande.
- Périmètre limité : préférez un rôle d’urgence par environnement ou service à une administration globale.
- Motif obligatoire : associez à chaque élévation un incident, un ticket ou une référence d’astreinte.
- Traces indépendantes : conservez les événements d’authentification, d’attribution et d’administration hors du système potentiellement affecté.
Séparez le chemin d’urgence du chemin normal. Le mécanisme habituel peut passer par GitOps, la CI/CD et une validation de changement ; le break-glass peut autoriser une action directe, sans dépendre des mêmes secrets statiques ni d’un unique composant susceptible d’être en panne.
Réservez-le à la restauration ou à la sécurisation du service, et non à la livraison d’une fonctionnalité urgente. Après le rétablissement, réconciliez les changements manuels dans le dépôt d’infrastructure ou la configuration déclarative afin que l’automatisation ne les écrase pas.
Automatiser l’élévation et la traçabilité
Lorsque votre fournisseur d’identité et votre plateforme le permettent, utilisez une élévation juste-à-temps plutôt qu’un groupe d’administrateurs permanent. Microsoft Entra Privileged Identity Management permet d’activer des rôles éligibles pour une durée configurée ; côté AWS, IAM s’appuie sur des rôles et des sessions temporaires.
Le workflow peut être déclenché depuis l’outil d’astreinte ou de tickets : il exige une authentification forte, attribue le rôle, associe la référence d’incident dans les métadonnées disponibles, puis programme l’expiration. Pour les scénarios critiques, une auto-approbation encadrée peut éviter un blocage irréaliste la nuit, à condition d’alerter immédiatement l’équipe sécurité ou plateforme et d’imposer une revue après coup.
Les journaux doivent permettre d’établir qui a activé l’accès, quand, pour quel motif et quelles actions ont été réalisées. Centralisez au minimum les journaux du fournisseur d’identité, les événements d’audit cloud et les traces d’administration dans votre SIEM ou votre plateforme de logs.
Si un secret reste nécessaire, stockez-le dans un coffre tel que HashiCorp Vault et privilégiez les identifiants dynamiques ou les jetons à durée de vie limitée lorsque c’est possible. Ne copiez pas de secret d’urgence dans un wiki, une variable CI générique ou un canal de discussion.
Tester et revoir le dispositif
Testez le break-glass comme un mécanisme de reprise, sur un environnement représentatif. Simulez par exemple une indisponibilité du SSO, un échec de déploiement critique ou la révocation accidentelle d’un rôle nécessaire.
- Mesurez le temps nécessaire pour obtenir l’élévation et exécuter l’action autorisée.
- Vérifiez l’expiration réelle de l’accès et l’absence de jeton ou de groupe persistant.
- Contrôlez que les journaux permettent de reconstituer l’intervention.
- Vérifiez qu’une autre personne peut suivre la procédure sans connaissance implicite.
- Documentez les dépendances : DNS, MFA, fournisseur d’identité, coffre de secrets, réseau et postes d’administration.
Suivez la fréquence et le motif des activations, et désignez un propriétaire pour chaque rôle break-glass. Des activations répétées sur un même service signalent un défaut d’outillage, de droits ou de fiabilité à corriger dans le chemin normal.