Comptes d’urgence Microsoft Entra ID : créer, protéger et surveiller les comptes break-glass

Un compte break-glass sert lorsque les contrôles normaux échouent

Un compte d’urgence Microsoft Entra ID n’est pas un administrateur de rechange pour les tâches quotidiennes. Il existe pour les rares situations où les comptes habituels sont bloqués : erreur Conditional Access, panne du fournisseur d’identité, perte des facteurs MFA, problème PIM ou indisponibilité des postes d’administration.

Microsoft recommande au moins deux comptes d’urgence infonuagiques avec le rôle Administrateur général attribué de façon active et permanente. Cette redondance couvre la perte d’un moyen d’authentification, une erreur de configuration ou l’indisponibilité physique d’un emplacement.

• Microsoft — Gérer les comptes d’accès d’urgence ↗
• Guide connexe — Vol de jetons Microsoft 365 →

Architecture recommandée

Les comptes ne devraient pas être liés à une personne, un téléphone personnel, une boîte aux lettres ou un processus automatisé. Utilisez des noms reconnaissables par l’équipe, mais difficiles à deviner publiquement, et documentez les Object ID pour les alertes.

Créer les comptes sans dépendance hybride

Créez les identités directement dans Entra avec le domaine onmicrosoft.com. Ne les synchronisez pas depuis Active Directory et ne les fédérez pas : une panne locale ou une règle de synchronisation ne doit pas empêcher l’accès d’urgence.

Attribuez Administrateur général de façon permanente et active. N’ajoutez aucune licence ou application inutile. Bloquez les usages non nécessaires dans la procédure opérationnelle, puis surveillez toute activité plutôt que de multiplier les dépendances techniques qui pourraient empêcher la connexion.

Connect-MgGraph -Scopes 'User.Read.All','RoleManagement.Read.Directory'

$accounts = @('ea-admin-01@contoso.onmicrosoft.com',
              'ea-admin-02@contoso.onmicrosoft.com')

foreach ($upn in $accounts) {
  Get-MgUser -UserId $upn -Property Id,DisplayName,UserPrincipalName,
    AccountEnabled,CreatedDateTime |
    Select-Object Id,DisplayName,UserPrincipalName,AccountEnabled,CreatedDateTime
}

• Microsoft — Bonnes pratiques pour les rôles Entra ↗

Choisir une authentification résistante et indépendante

Une passkey FIDO2 sur clé de sécurité est le choix le plus simple pour de nombreux environnements. Utilisez deux clés distinctes par compte lorsque votre processus le permet, identifiées sans révéler le compte associé. L’authentification par certificat convient si votre PKI peut rester disponible pendant le scénario de panne étudié.

N’utilisez pas le même facteur que les administrateurs réguliers. Un compte d’urgence dépendant du même téléphone, de la même application Authenticator ou du même fournisseur fédéré ne couvre pas la panne. Les moyens d’authentification ne doivent pas expirer ni être supprimés automatiquement pour inactivité.

• Guide connexe — Déployer les passkeys avec Entra ID →

Exclure avec précision de Conditional Access

Créez un groupe dédié, par exemple EmergencyAccess, et excluez-le de chaque politique Conditional Access capable de bloquer ou de restreindre la connexion. Cela comprend les exigences MFA, appareil conforme, emplacement, authentification forte, conditions de risque et conditions d’utilisation. Les politiques en Report-only ne bloquent pas et n’exigent pas d’exclusion.

Une exclusion n’est pas une dispense de sécurité : la protection repose sur une méthode résistante à l’hameçonnage, le stockage physique, la surveillance et l’usage exceptionnel. À chaque nouvelle politique, ajoutez la vérification du groupe d’urgence à la revue de changement.

• Utiliser un groupe statique dédié.
• Exclure ce groupe de toutes les politiques bloquantes existantes.
• Ajouter l’exclusion avant d’activer une nouvelle politique.
• Vérifier avec What If et un test réel contrôlé.
• Alerter si la composition du groupe change.

Alerter sur chaque connexion et chaque modification

Une connexion réussie, une tentative échouée, une modification des méthodes d’authentification ou un changement de rôle doit déclencher une alerte. Envoyez les journaux Entra vers Log Analytics ou Microsoft Sentinel et utilisez les Object ID plutôt que les noms affichés.

L’alerte ne doit pas dépendre du compte d’urgence lui-même. Acheminez-la vers plusieurs administrateurs et votre canal d’incident. Conservez le contexte : adresse IP, pays, appareil, application, Conditional Access, résultat et corrélation.

let EmergencyAccounts = dynamic([
  "00000000-0000-0000-0000-000000000001",
  "00000000-0000-0000-0000-000000000002"
]);
SigninLogs
| where UserId in (EmergencyAccounts)
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription,
          IPAddress, Location, AppDisplayName, ConditionalAccessStatus,
          CorrelationId
| order by TimeGenerated desc

let EmergencyUPNs = dynamic([
  "ea-admin-01@contoso.onmicrosoft.com",
  "ea-admin-02@contoso.onmicrosoft.com"
]);
AuditLogs
| where tostring(TargetResources) has_any (EmergencyUPNs)
| project TimeGenerated, OperationName, Result, InitiatedBy, TargetResources,
          CorrelationId
| order by TimeGenerated desc

• Microsoft — Schéma SigninLogs ↗

Conserver les clés avec un contrôle opérationnel

Placez les clés et la procédure dans des coffres physiques distincts, résistants au feu, accessibles à des personnes autorisées. Un contrôle à deux personnes réduit le risque d’usage discret, mais il doit rester praticable pendant une vraie panne. Documentez qui peut autoriser l’ouverture, qui accompagne l’intervention et comment consigner les actions.

Ne stockez pas le seul exemplaire du mot de passe, du NIP ou de la procédure dans Microsoft 365. Conservez une copie hors ligne avec les coordonnées du soutien Microsoft, les identifiants du tenant et les étapes de connexion depuis le poste sécurisé.

Tester tous les 90 jours

Microsoft recommande de valider les comptes au moins tous les 90 jours. Le test doit aller au-delà de la saisie du mot de passe : récupérer la clé, ouvrir une session depuis le poste prévu, accéder au centre d’administration, confirmer le rôle et vérifier que l’alerte arrive.

Effectuez le test comme un changement planifié. N’utilisez pas le compte pour corriger autre chose pendant l’exercice. Après le test, examinez les journaux, replacez les clés, fermez les sessions et consignez le résultat.

Procédure d’utilisation pendant un incident

• Déclarer l’incident et obtenir l’autorisation prévue.
• Récupérer une clé sous contrôle partagé.
• Utiliser le poste d’administration sécurisé désigné.
• Ouvrir une seule session et confirmer que le problème touche les comptes normaux.
• Effectuer uniquement les actions nécessaires pour rétablir l’administration.
• Consigner les changements, heures et identités impliquées.
• Fermer les sessions, sécuriser de nouveau la clé et effectuer une revue après incident.
• Faire pivoter ou remplacer la méthode si son secret ou sa chaîne de garde a pu être exposé.

Erreurs fréquentes à éviter

Deux comptes bien conçus coûtent peu, mais ils doivent être traités comme un véritable contrôle de continuité. La qualité du dispositif se mesure à sa capacité de fonctionner pendant une panne tout en rendant toute utilisation immédiatement visible.

• Service — Audit de sécurité Microsoft 365 →
• Guide connexe — Sécuriser les administrateurs Microsoft 365 →