Break-glass : compte d'accès d'urgence
Sécurité
Break-glass : « briser la vitre ». Compte ou procédure d'accès d'urgence, utilisé seulement quand le chemin normal d'administration est tombé, par analogie avec le marteau rouge derrière la vitre du bus : tout le monde sait où il est, personne ne s'en sert pour aller acheter du pain.
Quand : Panne du fournisseur d'identité, politique d'accès conditionnel qui verrouille tout le monde dehors, PAM indisponible, perte du second facteur des administrateurs. Le compte break-glass existe parce qu'un système d'administration sans voie de récupération devient inaccessible exactement au moment où il faut le réparer.
Comment : Des comptes rares, exclus des synchronisations et des règles qui pourraient les bloquer, protégés par un facteur matériel distinct et conservés sous double contrôle. Leurs moyens d'accès ne doivent pas dépendre du système qu'ils servent à réparer : ranger le seul second facteur dans le coffre que la panne rend inaccessible est une idée qui ne fonctionne qu'une fois.
Surveillance : Chaque connexion d'un compte break-glass déclenche une alerte immédiate, par un canal qui ne dépend pas non plus du système en panne. Après usage, les secrets sont renouvelés et l'intervention est documentée.
Tester : Un compte jamais testé n'est pas un mécanisme de reprise. Le test vérifie la connexion, l'accès au plan de contrôle, une action limitée et réversible, la production des journaux et le déclenchement de l'alerte.
Ce qui arrive si on s'en passe
Sans accès d'urgence préparé, une panne du fournisseur d'identité ou une règle d'accès mal écrite peut verrouiller tous les administrateurs dehors, et la réparation attend alors l'intervention du support d'un éditeur, parfois pendant des heures. Sous cette pression, les équipes improvisent : mot de passe partagé noté quelque part, désactivation globale de l'authentification multifacteur, compte créé en urgence et jamais supprimé. À l'inverse, un compte de secours mal gardé devient une porte dérobée : privilégié, exclu des contrôles habituels, rarement surveillé, il intéresse beaucoup un attaquant. Et un compte de secours jamais testé échoue souvent le jour venu, mot de passe expiré ou second facteur introuvable. Des comptes rares, protégés par un facteur matériel, surveillés à chaque connexion et testés à intervalles réguliers évitent les deux écueils.
Explication de la marmotte
Dans un immeuble, il y a une clé de secours dans une petite boîte vitrée, pour les pompiers. On ne s'en sert pas tous les jours : seulement quand la porte normale ne s'ouvre plus. En informatique, c'est pareil : on prévoit un compte spécial pour réparer les systèmes si le moyen de connexion habituel tombe en panne. Ce compte est très puissant, alors il est bien caché, une alarme sonne dès qu'on l'utilise, et on vérifie régulièrement qu'il marche encore, pour ne pas découvrir le jour de la panne que la clé ne rentre plus dans la serrure.
Où ce terme est utilisé
- PAM, JIT et comptes break-glass sécurisés (4 occurrences)
- RDP exposé sur Internet : risques, durcissement et détection (3 occurrences)
- Accès juste-à-temps et privilèges temporaires (2 occurrences)
- Réconcilier inventaire IaC et cloud réel (2 occurrences)
- Comment organiser une astreinte cybersécurité durable (1 occurrence)
- Hyperviseur Type 1 ou Type 2 : lequel choisir (1 occurrence)
- La récupération de compte, maillon faible (1 occurrence)
- Mot de passe partagé en équipe et risques réels (1 occurrence)
- Pourquoi le moindre privilège échoue en production (1 occurrence)
- Sécuriser les postes développeurs avec secrets de production (1 occurrence)