Comptes d'Accès d'Urgence Break Glass Entra ID : Absents, Non Surveillés, Non Exclus

Qu'est-ce qu'un compte d'accès d'urgence Break Glass Entra ID

Un compte d'accès d'urgence break-glass Entra ID est un compte Global Administrator conservé en réserve pour le seul scénario que tous les autres chemins d'administration sont conçus pour éviter : le verrouillage total. Les recommandations officielles de Microsoft listent les situations pour lesquelles ces comptes existent — une panne de fédération qui bloque tous les admins synchronisés, une panne d'appareil ou de service MFA qui empêche l'activation d'un rôle, le départ du dernier Global Administrator actif, une catastrophe naturelle qui met hors service les réseaux téléphoniques, ou une impasse d'approbation du Privileged Identity Management (PIM) où chaque assignation éligible de Global Administrator ou de Privileged Role Administrator a besoin d'un approbateur et où aucun n'est actif. Pour une vue plus large de la façon dont les assignations PIM et le nombre de Global Admins permanents pilotent le risque du tenant, voir Accès Privilégié Azure : Trop d'Admins Globaux.

Aucun de ces cas n'est exotique. Ce sont les cas limites précis que « utilisez simplement le MFA » et « utilisez simplement le PIM » ne couvrent pas, car le MFA et le PIM sont justement ce qui peut tomber en panne.

La faille de gouvernance couverte par cet article n'est pas le concept lui-même — la plupart des équipes sécurité ont déjà entendu parler des comptes break-glass. C'est que le catalogue d'audit de Microsoft recense trois façons distinctes et courantes dont ce contrôle échoue dans des tenants réels :

1. Aucun compte d'accès d'urgence n'existe (PA_NO_EMERGENCY_ACCOUNTS) — le cas de base, et selon le catalogue d'EtcSec la sévérité critique par défaut : zéro couverture break-glass signifie zéro chemin de récupération si le chemin d'administration principal échoue.
2. Le compte existe mais n'est pas exclu du Conditional Access (PA_EMERGENCY_NO_EXCLUSION / CA_NO_BREAK_GLASS_EXCLUSION) — de sorte que la politique censée protéger le tenant est précisément ce qui verrouille le compte de récupération pendant l'urgence pour laquelle il a été créé.
3. Le compte existe et est exclu, mais personne ne le surveille (PA_EMERGENCY_NO_MONITORING) — de sorte qu'un événement de connexion qui devrait déclencher toutes les alarmes (un compte Global Admin hors des contrôles CA normaux vient de s'authentifier) ne génère absolument aucune alerte.

Une quatrième faille, apparentée, apparaît dans la même famille du catalogue : les identifiants obsolètes (PA_EMERGENCY_CREDENTIAL_STALE) — un compte d'urgence dont la méthode d'authentification ou l'appareil n'a pas été validé depuis si longtemps que personne ne sait vraiment s'il fonctionne encore.

Comment cette faille se produit en pratique

Les comptes break-glass sont généralement créés une seule fois, lors de la configuration initiale du tenant ou d'une mise en conformité, puis laissés de côté — ce qui est précisément le problème, car « laissé de côté » joue dans les deux sens.

Totalement absent

Les tenants plus petits, les tenants migrés depuis un fournisseur d'identité plus ancien, ou les tenants qui ont considéré que « tous nos admins ont le MFA » suffisait comme couverture, n'ont fréquemment aucun compte d'accès d'urgence dédié. Microsoft recommande de créer deux comptes ou plus uniquement dans le cloud, sur le domaine par défaut *.onmicrosoft.com du tenant — non fédérés, non synchronisés depuis l'environnement local — précisément pour qu'une panne locale ou de fédération ne mette pas hors service le chemin de récupération en même temps que tout le reste.

Non exclu du Conditional Access

C'est le mode de défaillance qui transforme un contrôle en piège. Une politique CA qui exige un appareil conforme, une méthode MFA spécifique, ou qui bloque selon la localisation, s'appliquera sans problème au compte d'urgence comme à tout autre Global Administrator — ce qui signifie que la politique censée protéger le tenant devient la raison pour laquelle le compte d'urgence ne peut pas se connecter pendant la panne ou le verrouillage pour lesquels il existe. Microsoft est explicite à ce sujet : excluez les comptes break-glass de toute politique CA qui bloque ou restreint la connexion ; les politiques en mode rapport uniquement ne bloquent pas l'accès et n'ont pas besoin de cette exclusion. C'est un cas particulier d'un schéma plus large — voir Failles d'accès conditionnel Entra ID sur la façon dont les erreurs de périmètre d'exclusion se retrouvent dans les politiques en général.

Non surveillé

Même avec un compte correctement créé et exclu, la plupart des tenants n'ont aucune alerte sur son utilisation. Un compte break-glass est conçu pour ne quasiment jamais se connecter. Cette propriété rend la surveillance peu coûteuse et très informative : toute authentification depuis ce compte est soit un exercice de validation programmé, soit un incident actif (une urgence légitime, ou un attaquant qui a trouvé et compromis le seul compte explicitement soustrait à l'application de la politique). Sans alerte permanente, ce signal reste invisible jusqu'à ce que quelqu'un consulte par hasard les journaux de connexion — ce qui, pour la plupart des tenants, est rare ou n'arrive jamais. Cet angle mort s'ajoute aux failles de signal de risque plus larges couvertes dans Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués.

Détection

Vérifiez l'état de la couverture des comptes d'accès d'urgence break-glass à l'aide de ces contrôles, associés aux entrées du catalogue :

Construire la requête d'alerte de connexion

Pour le contrôle de surveillance en particulier, l'approche documentée par Microsoft consiste en une règle d'alerte de log personnalisé Log Analytics sur la table SigninLogs, indexée sur l'Object ID du compte (disponible sous Entra ID → Users → [compte] → Object ID) :

// Alert query — any sign-in from an emergency access account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Réglez la valeur de seuil de l'alerte sur 0 (supérieur à), la sévérité sur 0 – Critique, et attachez un groupe d'actions qui envoie un e-mail et un SMS à votre équipe sécurité — car selon les recommandations de Microsoft, toute connexion depuis ce compte doit déclencher une revue, qu'il s'agisse d'un exercice programmé ou d'un incident réel.

Récupérez également les entrées du journal d'audit du compte (pas seulement le journal de connexion) — les changements d'assignation de rôle, les enregistrements d'identifiants et les changements d'appartenance à une politique CA touchant le compte sont autant d'événements qui méritent une alerte indépendamment de l'activité de connexion. Si vous construisez ce type de contrôle dans le cadre d'une revue de tenant plus large plutôt qu'en action ponctuelle, Comment auditer la sécurité Microsoft Entra ID détaille le périmètre complet de revue dans lequel ce point s'inscrit.

Remediation

1. Créez au moins deux comptes d'accès d'urgence. Cloud uniquement, domaine *.onmicrosoft.com, non fédérés ni synchronisés. Les recommandations de Microsoft préconisent deux comptes ou plus afin qu'un seul identifiant compromis ou indisponible ne supprime pas totalement la capacité de récupération.
2. Utilisez une authentification sans mot de passe résistante au phishing. La clé d'accès (FIDO2) est la méthode recommandée par Microsoft ; l'authentification par certificat est l'alternative si votre organisation exploite déjà une PKI. Ne réutilisez pas la méthode MFA utilisée par vos comptes admin habituels — si la notification push Microsoft Authenticator est standard pour les admins, placez plutôt le compte d'urgence sur une clé matérielle FIDO2, afin qu'une seule panne ou une seule classe de compromission ne mette pas hors service les deux chemins à la fois.
3. Assignez Global Administrator en mode permanent, actif — pas éligible — dans PIM. Un compte d'urgence verrouillé derrière une étape d'activation PIM perd son intérêt si le PIM lui-même fait partie de la panne.
4. Excluez les comptes de toute politique Conditional Access qui bloque ou restreint la connexion. Créez un groupe de sécurité dédié (nom d'exemple de Microsoft : EmergencyAccess) et excluez ce groupe des politiques appliquées — les politiques en rapport uniquement n'ont pas besoin de cette exclusion puisqu'elles ne peuvent pas bloquer l'accès. Revérifiez la liste d'exclusion à chaque nouvelle politique CA mise en production.
5. Mettez en place la surveillance des connexions avant d'en avoir besoin. Construisez la règle d'alerte Log Analytics ci-dessus, routez-la vers un vrai groupe d'actions (e-mail + SMS, pas une boîte mail que personne ne surveille), et réglez la sévérité sur Critique.
6. Stockez les identifiants dans un emplacement sécurisé et à accès contrôlé — un stockage physiquement séparé et ignifugé pour les jetons matériels ou les certificats CBA, accessible à plus d'une personne autorisée, non lié à l'appareil d'un seul employé.
7. Validez tous les 90 jours, et après tout changement dans l'équipe d'administration. Confirmez que le compte se connecte toujours avec succès sous la configuration CA actuelle, confirmez que l'alerte se déclenche toujours, et confirmez que la liste des utilisateurs autorisés est à jour. Les recommandations de Microsoft sont explicites : cette validation doit avoir lieu au moins tous les 90 jours et après tout changement de personnel — un compte d'accès d'urgence que personne n'a testé en conditions réelles de panne n'est pas un contrôle fonctionnel, c'est une hypothèse.
8. Effectuez un post-mortem à chaque déclenchement, exercice ou réel, pour confirmer que l'utilisation était autorisée et que les actions entreprises correspondaient à l'incident.

La couverture break-glass n'est qu'un élément d'un socle de durcissement du tenant plus large — voir Durcissement du Tenant Azure : Corriger les Configs à Risque pour les autres failles de configuration par défaut qu'il vaut la peine de corriger en parallèle.

Comment EtcSec détecte cela

L'audit Entra ID d'EtcSec vérifie les trois modes de défaillance couverts ici : PA_NO_EMERGENCY_ACCOUNTS signale les tenants sans aucun compte d'accès d'urgence qualifié, PA_EMERGENCY_NO_EXCLUSION (associé à CA_NO_BREAK_GLASS_EXCLUSION) signale les comptes encore dans le périmètre d'une politique Conditional Access appliquée, PA_EMERGENCY_NO_MONITORING signale les comptes sans configuration d'alerte de connexion correspondante, et PA_EMERGENCY_CREDENTIAL_STALE signale les comptes dont les identifiants n'ont pas été validés dans la fenêtre recommandée.