Comptes break-glass Entra ID : un accès de secours quand tout échoue

Un tenant peut se verrouiller tout seul, sans le moindre attaquant. Si toutes les attributions Global Administrator et Privileged Role Administrator sont éligibles, que l'activation exige une approbation et qu'aucun approbateur n'est défini, personne ne peut rien approuver. Les administrateurs actifs sont les approbateurs par défaut, et il n'y en a aucun. Deux comptes break-glass cloud-only, configurés et testés à l'avance, sont la porte de sortie.

Quand vous en aurez besoin

Le guide de Microsoft sur l'accès d'urgence énumère les cas de figure. La fédération est indisponible parce que l'hôte de votre fournisseur d'identité est en panne. Tous les administrateurs ont enregistré uniquement les appels téléphoniques et les SMS comme méthode MFA, et le réseau mobile est coupé. La dernière personne disposant de l'accès Global Administrator quitte l'entreprise, et son compte est désactivé ou supprimé en local, ce qu'Entra ID n'empêche pas.

Créer les comptes

Créez au moins deux comptes. Faites-les cloud-only sur le domaine *.onmicrosoft.com, ni fédérés ni synchronisés depuis l'annuaire local. Attribuez à chacun le rôle Global Administrator.

Dans Privileged Identity Management (PIM), rendez cette attribution active permanente, et non éligible. Les administrateurs du quotidien devraient utiliser l'accès juste-à-temps, mais ces comptes ne peuvent pas dépendre d'une étape d'activation, car c'est peut-être précisément elle qui sera indisponible. PIM nécessite Microsoft Entra ID P2 ou Entra ID Governance.

Les sources ne couvrent pas les tenants sans PIM : ce passage relève donc de notre propre raisonnement. Le paramètre actif ou éligible se trouve dans PIM et ne s'applique pas dans ce cas. Les comptes doivent tout de même recevoir une attribution Global Administrator directe et permanente, pour la même raison : rien ne doit avoir à être activé.

Pour l'authentification, choisissez une méthode sans mot de passe qui satisfait l'exigence de MFA :

• Passkey (FIDO2), recommandée par Microsoft.
• Authentification par certificat, si vous exploitez déjà une PKI.

Utilisez une méthode différente de celle de vos administrateurs du quotidien. S'ils utilisent l'application Microsoft Authenticator, donnez aux comptes de secours une clé de sécurité FIDO2. Ne liez pas des comptes partagés à une personne ni à un appareil fourni par un employé, comme un téléphone. Microsoft autorise aussi des comptes de secours individuels, un par administrateur, ce qui permet de responsabiliser chacun et de les utiliser depuis des sites distants. Choisissez un modèle de façon délibérée.

Conservez les clés dans des coffres ignifugés, situés dans des lieux sécurisés et distincts, accessibles aux personnes autorisées à les utiliser. Utilisez un poste de travail sécurisé dédié, comme une Privileged Access Workstation, chaque fois que quelqu'un se connecte avec ces comptes.

Les exclure de Conditional Access

Une politique appliquée qui exige la MFA, un appareil conforme ou un autre contrôle peut rendre le compte inutilisable pendant la situation d'urgence. C'est le credential résistant au phishing qui protège le compte : excluez-le donc de toute politique qui bloque ou restreint la connexion. Conditional Access nécessite Entra ID P1.

Créez un groupe de sécurité dédié, par exemple EmergencyAccess, placez-y les deux comptes et excluez ce groupe de ces politiques. Les politiques en mode report-only ne bloquent pas l'accès et n'exigent aucune exclusion.

Un groupe seul ne suffit pas, car les nouvelles politiques sont rédigées par des personnes qui ne se souviennent peut-être pas que ces comptes existent. Ouvrez chaque politique activée et vérifiez que le groupe figure dans sa section Exclude. Revérifiez les politiques en report-only avant que quiconque ne les active. Ajoutez la question « EmergencyAccess est-il exclu ? » à la checklist de revue de chaque nouvelle politique, et testez une connexion après chaque changement important.

Alerter à chaque connexion

Ces comptes ne devraient se connecter que pour les exercices et les vraies urgences : toute connexion mérite donc une alerte. L'exemple de Microsoft repose sur Azure Monitor et suppose que vos journaux de connexion Entra soient d'abord envoyés vers un espace de travail Log Analytics.

1. Dans l'Entra admin center, avec au moins le rôle User Administrator, allez dans Entra ID > Users, ouvrez chaque compte de secours et copiez son Object ID.
2. Dans le portail Azure, avec au moins le rôle Monitoring Contributor, ouvrez Monitor > Alerts, puis sélectionnez + Create > Alert rule.
3. Dans l'onglet Scope, sélectionnez votre espace de travail Log Analytics.
4. Dans l'onglet Condition, choisissez Custom log search comme nom de signal et Aggregated logs comme type de requête.
5. Saisissez une requête contenant les deux Object ID :

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

1. Sous Measurement, sélectionnez la mesure, le type d'agrégation et la granularité d'agrégation. Sous Split by dimensions, sélectionnez la colonne Resource ID.
2. Sous Alert logic, définissez le type de seuil sur Static, l'opérateur sur Greater than et la valeur du seuil sur 0. Réglez la fréquence d'évaluation selon la rapidité avec laquelle vous voulez être prévenu.
3. Acheminez l'alerte par e-mail et par SMS vers plusieurs administrateurs, pas un seul.

Microsoft montre aussi une requête fondée sur UserPrincipalName. Nous utilisons l'Object ID par habitude : une requête écrite autour d'un nom dépend de la stabilité de ce nom. Pour chaque compte supplémentaire, ajoutez une clause or UserId == "ObjectGuid".

Si personne dans votre équipe ne surveille les alertes en dehors des heures ouvrées, un service de supervision managée peut prendre en charge cette partie.

Les tester et passer en revue chaque utilisation

Validez les comptes au moins tous les 90 jours. Un exercice doit couvrir la liste des utilisateurs autorisés, une vraie connexion avec la clé de sécurité et une tâche d'administration. Il doit confirmer que les comptes se connectent toujours avec votre configuration Conditional Access actuelle, et que chaque clé ou certificat est présent, n'a pas expiré et n'a pas été supprimé par un nettoyage automatisé.

Chaque exercice doit déclencher votre alerte. Répétez le test après toute modification de l'espace de travail ou des paramètres de diagnostic qui l'alimentent. Tenez un court journal :

Après toute utilisation réelle, organisez un post-mortem. Déterminez si l'utilisation était autorisée et si les actions menées étaient appropriées. Les organisations réglementées peuvent présenter ce compte rendu, avec les journaux et le journal des exercices, comme preuve que l'accès d'urgence est encadré. Si vous souhaitez un regard extérieur, notre équipe de conseil peut examiner votre configuration.

Par où commencer

1. Listez vos Global Administrators dans l'Entra admin center et comparez leur nombre à la recommandation de Microsoft, qui est de moins de cinq. Vérifiez si un compte est déjà destiné aux urgences.
2. Créez deux comptes cloud-only en .onmicrosoft.com avec une attribution Global Administrator active permanente, et enregistrez une clé FIDO2 différente pour chacun.
3. Créez le groupe EmergencyAccess et excluez-le de chaque politique Conditional Access qui bloque ou restreint la connexion.
4. Envoyez les journaux de connexion vers Log Analytics et créez la règle d'alerte avec un seuil supérieur à 0 sur les deux Object ID.
5. Placez les clés dans des lieux ignifugés distincts, nommez les utilisateurs autorisés et vérifiez qu'aucun credential n'expire ni n'entre dans le périmètre d'un nettoyage automatisé.
6. Connectez-vous avec chaque compte, confirmez que l'alerte se déclenche, remplissez la première ligne du journal d'exercice et inscrivez le prochain exercice au calendrier dans les 90 jours.