Accès d'urgence : contrôler sans bloquer l'opération

Cybersécurité · 3 min

Les comptes d'urgence aident à récupérer des services, mais peuvent aussi créer de sérieux risques. Découvrez comment gouverner les accès *break-glass* avec contrôle et traçabilité.

Accès d'urgence : contrôler sans bloquer l'opération

TL;DR

L'accès d'urgence doit être une exception, pas un raccourci opérationnel.
Les comptes break-glass nécessitent un propriétaire, un périmètre, une authentification et un enregistrement.
Le risque augmente lorsque les comptes privilégiés deviennent permanents et peu surveillés.
Des tests périodiques aident à confirmer que l'accès fonctionne en cas de besoin.
La revue post-utilisation est aussi importante que l'autorisation initiale.

La bonne question n'est pas de savoir si un accès d'urgence doit exister

Dans les environnements d'entreprise, il existe des scénarios où l'accès normal peut échouer : indisponibilité du fournisseur d'identité, erreur de configuration, perte de connectivité, incident de sécurité ou défaillance d'une intégration critique. Dans ces moments, un compte d'urgence, souvent appelé break-glass, peut permettre de reprendre le contrôle. La question pertinente n'est pas de savoir si ces comptes doivent exister, mais comment éviter qu'ils ne se transforment en une porte privilégiée permanente, peu surveillée et en dehors des processus de gouvernance normaux.

Le risque réside dans le privilège sans contexte

Un compte d'urgence concentre généralement des autorisations élevées et des mécanismes d'authentification indépendants des flux habituels. Cela est utile lorsque le système d'identité est indisponible, mais crée également une exposition si le compte est partagé, réutilisé ou oublié. La gestion doit commencer par définir l'objectif, le périmètre technique, les systèmes couverts, les responsables de la garde et les conditions d'utilisation. Cette discipline complète les pratiques de détection des risques liés à l'identité, telles que celles abordées dans [ITDR et risques d'identité](/pt/blog/itdr-detetar-riscos-de-identidade-antes-do-incidente).

Séparer l'accès de routine de l'accès exceptionnel

L'erreur la plus courante est d'utiliser des comptes d'urgence pour des tâches administratives fréquentes. Lorsque cela se produit, il n'y a plus de distinction entre l'opération normale et l'exception. Une bonne pratique consiste à maintenir les accès quotidiens soumis aux rôles, à l'approbation, à l'authentification forte et à la traçabilité, en réservant le mécanisme break-glass aux situations documentées. Dans les architectures d'accès modernes, cette séparation doit coexister avec les principes de [Zero Trust et ZTNA](/pt/solucoes/zero-trust-ztna), sans présumer que l'urgence justifie l'absence de contrôle.

Définir la garde, l'authentification et l'enregistrement

Chaque compte d'urgence doit avoir un propriétaire fonctionnel et technique. Les identifiants doivent être conservés de manière contrôlée, avec un accès limité et un processus d'accès documenté. Les comptes d'urgence doivent utiliser des mécanismes d'authentification forte adaptés au scénario de contingence, en évitant les dépendances qui pourraient empêcher l'accès lors d'une panne. Des alertes automatiques et un enregistrement détaillé de leur utilisation doivent également exister. Si le compte doit contourner des dépendances spécifiques, cette exception doit être explicite et justifiée. L'intégration avec les pratiques de [gestion d'infrastructure](/pt/servicos/gestao-infraestrutura) aide à maintenir l'inventaire, les responsabilités et les procédures alignés.

Tester sans banaliser

Un compte qui n'est jamais testé peut échouer précisément quand il est nécessaire. Mais des tests trop fréquents ou mal encadrés peuvent normaliser l'utilisation de privilèges élevés. L'équilibre passe par des exercices périodiques, avec une fenêtre définie, une approbation préalable, des objectifs clairs et une validation des preuves. Le test doit confirmer que l'identifiant est accessible, que l'accès fonctionne, que les alertes se déclenchent et que l'activité est enregistrée. Si l'un de ces points échoue, le processus doit être corrigé avant d'être considéré comme fiable.

Réviser après chaque utilisation

Le moment post-utilisation est décisif. Il convient de confirmer qui a accédé, pourquoi, pendant combien de temps, quelles modifications ont été apportées et si les identifiants doivent être renouvelés. Lorsque l'utilisation a eu lieu pendant un incident, la revue doit être liée aux procédures de réponse et aux [runbooks opérationnels](/pt/blog/runbooks-automatizacao-resposta-incidentes) correspondants. L'objectif n'est pas de bureaucratiser la récupération, mais de s'assurer que l'exception était nécessaire, proportionnelle et auditable. Un accès d'urgence bien gouverné réduit l'improvisation sans éliminer la responsabilité.