Qu’est-ce qu’un compte d’accès d’urgence Entra ?

C’est un compte d’administration exceptionnel, conçu pour rester utilisable quand les chemins d’accès normaux échouent.

Le compte d’urgence, parfois appelé « break glass », n’est ni un compte de support quotidien ni un raccourci pour éviter les contrôles. Il sert uniquement à reprendre la main sur le tenant lorsqu’une panne d’identité, une politique mal configurée, la perte des moyens MFA ou une erreur de gouvernance bloque tous les administrateurs habituels. Son privilège est élevé parce qu’il doit pouvoir corriger l’incident ; son usage doit donc être rare, visible et immédiatement réexaminé.

Microsoft recommande deux comptes ou davantage, cloud-only et basés sur le domaine .onmicrosoft.com, sans dépendance à la fédération locale. La documentation Microsoft, mise à jour le 5 juin 2026, précise aussi que ces comptes doivent être réservés aux urgences, surveillés et validés régulièrement. La redondance est essentielle : une seule clé perdue, un compte désactivé ou une erreur de configuration ne peut pas condamner le dernier chemin de récupération.

Pour une organisation belge, le sujet dépasse la technique. Il faut décider qui peut autoriser l’ouverture du dispositif, où les moyens d’authentification sont gardés, comment une équipe multi-sites y accède en cas d’indisponibilité d’un bâtiment et quelles preuves sont conservées. La sécurisation des identités avec Microsoft Entra doit intégrer cette continuité dès la conception, plutôt que l’ajouter après un verrouillage.

Dans quels scénarios ce compte doit-il fonctionner ?

Le bon modèle part de scénarios de panne concrets et de dépendances réellement indépendantes.

Premier scénario : la fédération ou l’annuaire local ne répond plus. Un compte synchronisé depuis Active Directory peut alors être inutilisable au moment précis où il faut modifier la configuration cloud. Un compte cloud-only réduit cette dépendance. Deuxième scénario : la méthode MFA habituelle devient indisponible, par exemple à cause d’une panne mobile, d’un service tiers ou de smartphones perdus. Le mécanisme d’urgence ne doit pas partager le même mode de défaillance.

Troisième scénario : une politique d’accès conditionnel bloque par erreur tous les administrateurs. Une règle exigeant un appareil conforme, une localisation nommée ou une force d’authentification mal déployée peut créer un verrouillage collectif. Quatrième scénario : tous les détenteurs de rôles privilégiés doivent activer PIM, mais aucun approbateur actif ne reste disponible. Cinquième scénario : un incident cyber impose de révoquer des sessions ou de corriger une configuration alors que les comptes normaux sont soupçonnés d’être compromis.

Transformez chaque scénario en test d’acceptation : depuis quel poste se connecter, avec quelle clé, par quel accès internet, pour exécuter quelle action minimale ? Évitez les scénarios vagues du type « panne de Microsoft ». L’objectif est de repérer les dépendances communes : même téléphone, même coffre numérique, même fournisseur d’identité, même réseau, même personne ou même bâtiment. Une architecture d’urgence n’est résiliente que si elle traverse au moins une rupture plausible de chacun de ces éléments.

Comment concevoir une architecture d’urgence fiable ?

Créez deux comptes cloud-only distincts, séparez leurs moyens d’authentification et documentez un chemin d’usage minimal.

Attribuez à chaque compte une identité non personnelle et non évidente, conservez son identifiant d’objet dans le registre de sécurité et placez-le dans un groupe dédié aux exclusions contrôlées. Microsoft demande que le rôle Administrateur général soit actif de manière permanente pour ces comptes, contrairement aux comptes humains ordinaires qui gagnent à utiliser PIM et le moindre privilège. Cette exception doit rester limitée à ces identités d’urgence.

Utilisez une méthode résistante au phishing. Microsoft recommande les passkeys FIDO2 et accepte l’authentification par certificat lorsqu’une PKI suffisamment indépendante existe. Une clé matérielle n’est pas magique : il faut enregistrer, étiqueter, sceller, stocker et tester chaque exemplaire. Prévoyez un moyen principal et un exemplaire de réserve sans lier le compte au téléphone privé d’un collaborateur. Vérifiez aussi l’absence d’expiration ou de nettoyage automatique pour inactivité.

Réservez un poste d’administration sécurisé ou un environnement équivalent. Le navigateur, les extensions, les comptes connectés et le réseau doivent être maîtrisés. Le poste ne doit pas devenir un ordinateur partagé utilisé au quotidien. Définissez l’action minimale autorisée : rétablir une politique, activer un administrateur nommé, révoquer une compromission ou restaurer une chaîne d’approbation. Après cela, l’utilisateur quitte le compte d’urgence et poursuit sous une identité nominative traçable.

Compte normal, PIM ou compte d’urgence : quelle différence ?

Ces trois mécanismes sont complémentaires : le compte humain gère le quotidien, PIM limite la durée du privilège et le compte d’urgence traite le verrouillage global.

Confondre ces rôles conduit à deux excès opposés. Si l’équipe utilise le compte d’urgence pour gagner du temps, elle perd l’attribution individuelle, banalise un privilège permanent et masque les problèmes de gouvernance. Si elle exige au contraire les mêmes dépendances que pour un compte normal, le dispositif peut être bloqué avec le reste du tenant. Le tableau distingue l’usage, le contrôle et la limite de chaque option.

Les bonnes pratiques Microsoft Entra RBAC, mises à jour le 1er juin 2026, recommandent le moindre privilège, PIM pour l’accès juste-à-temps et deux comptes cloud-only d’urgence affectés en permanence au rôle Administrateur général. La nuance est importante : le privilège permanent est une exception de continuité, pas un modèle à reproduire pour tous les administrateurs.

Comment traiter les exclusions d’accès conditionnel ?

Excluez les comptes d’urgence des politiques susceptibles de bloquer la connexion, puis compensez cette exception par une authentification forte, une surveillance totale et des tests.

Une exclusion n’est pas un laisser-passer général. Elle sert à éviter qu’une exigence de périphérique conforme, de localisation, de méthode indisponible ou de service externe empêche l’accès de secours. Utilisez un groupe dédié et contrôlez explicitement son appartenance. Les politiques en mode rapport seul n’ont pas besoin de cette exclusion, puisqu’elles n’empêchent pas la connexion. Documentez chaque politique qui exclut le groupe et la raison de cette décision.

L’authentification du compte doit rester résistante au phishing même sans dépendre d’une politique bloquante. Les forces d’authentification Microsoft Entra expliquent comment distinguer les combinaisons de méthodes. Dans le dispositif d’urgence, la protection vient surtout de la possession contrôlée de la clé ou du certificat, du poste sécurisé, de l’alerte immédiate et de la procédure à deux personnes.

Avant toute modification majeure d’accès conditionnel, utilisez le mode rapport seul, les outils d’évaluation et un déploiement progressif. Vérifiez spécifiquement les comptes d’urgence avant de basculer la politique en production. Après chaque changement, réalisez une connexion contrôlée avec au moins un compte puis confirmez que l’autre conserve un chemin indépendant. Une exclusion non retestée est une hypothèse, pas une garantie.

Où conserver les clés, secrets et instructions ?

Séparez les moyens d’authentification, les instructions et les lieux de garde afin qu’une personne ou une panne unique ne contrôle pas tout.

Les clés FIDO2 et les éventuels codes de récupération doivent être placés dans des emplacements physiques sûrs, distincts et accessibles aux personnes autorisées. Microsoft évoque des coffres sécurisés et résistants au feu dans des lieux séparés. Pour une organisation multi-sites, cela peut signifier un moyen principal au siège et un second dans un autre site contrôlé. L’inventaire doit mentionner le numéro de série, le compte associé, le scellé, le lieu, les détenteurs et la date de vérification, sans exposer de secret dans un ticket ordinaire.

La procédure doit rester disponible quand Microsoft 365, le VPN ou le réseau du siège ne fonctionne plus. Une copie papier scellée ou un dépôt hors dépendance principale peut compléter la version gouvernée. Indiquez l’URL de connexion, le poste autorisé, la méthode, les contacts, le circuit d’autorisation, les actions permises et le plan de retour à la normale. N’incluez pas un mot de passe en clair dans la même enveloppe que tous les autres éléments si une séparation de garde est possible.

Comment surveiller chaque utilisation ?

Toute tentative de connexion du compte d’urgence, réussie ou non, doit devenir un événement visible et traité.

Envoyez les journaux de connexion Entra vers l’outil de surveillance retenu, puis créez une règle ciblant les identifiants d’objet des comptes d’urgence. La procédure officielle Microsoft fournit un exemple avec Azure Monitor, une requête sur SigninLogs, un seuil supérieur à zéro et un groupe d’action. Microsoft Sentinel ou un autre SIEM peut appliquer la même logique. Surveillez aussi les modifications de rôle, de méthode d’authentification, de groupe d’exclusion et de statut du compte.

L’alerte doit atteindre plusieurs personnes par un canal qui ne dépend pas uniquement du tenant concerné. Elle contient au minimum l’heure, le compte, le résultat, l’adresse IP, le contexte connu et le numéro du test ou de l’incident. Ne placez pas d’information sensible inutile dans un SMS. La personne d’astreinte vérifie immédiatement si l’usage correspond à un exercice planifié, une urgence déclarée ou un comportement non autorisé.

Le déploiement d’une MFA adaptée aux comptes privilégiés doit inclure la surveillance des méthodes enregistrées et leur cycle de vie. GVISION peut aider à aligner authentification, journaux, accès conditionnel et procédure opérationnelle, sans présenter le simple fait de posséder une clé comme une garantie suffisante.

Comment mener un test trimestriel sans créer de risque ?

Testez la chaîne complète dans une fenêtre préparée : autorisation, accès, alerte, action bénigne, fermeture et revue.

Annoncez l’exercice à l’équipe de supervision sans dévoiler tous les détails à l’avance. Vérifiez le scellé et l’inventaire, récupérez le matériel à deux personnes, utilisez le poste sécurisé et un réseau prévu. Connectez-vous, confirmez la réception de l’alerte et exécutez une action administrative non destructive définie à l’avance, par exemple consulter un paramètre ou valider la capacité à accéder à la page de rôle sans modifier une affectation.

Contrôlez séparément chacun des deux comptes. Un succès du premier ne prouve rien sur le second. Testez également un chemin réseau alternatif lorsque le plan le prévoit. Relevez les délais : obtenir l’autorisation, accéder au matériel, se connecter, recevoir l’alerte et clôturer. Ces mesures servent à améliorer le processus, pas à fabriquer un SLA universel. Documentez tout écart, comme une batterie déchargée, une clé non reconnue, un poste trop ancien ou un contact obsolète.

Microsoft demande une validation au moins tous les 90 jours et après les changements clés, notamment un mouvement dans l’équipe IT ou une évolution d’abonnement. À la fin, fermez la session, remettez le matériel sous scellé, préservez les journaux et faites approuver le compte rendu. Si le test révèle un défaut grave, ouvrez une action corrective avec responsable et échéance, puis réalisez un nouveau test ciblé après correction.

Quelles preuves conserver dans une organisation belge ?

Conservez des preuves proportionnées montrant que le dispositif existe, reste contrôlé et a été testé, sans transformer l’article en certification.

Le registre utile comprend la décision de création, les propriétaires du processus, les comptes et identifiants d’objet, les rôles, les méthodes d’authentification, les emplacements de garde, les exclusions justifiées, la règle d’alerte et les résultats des exercices. Ajoutez les changements d’autorisation, les incidents réels et les actions post-mortem. Limitez l’accès à ces éléments : une documentation de sécurité trop largement diffusée peut faciliter l’abus.

Pour les organisations soumises à NIS2, à des exigences sectorielles, au RGPD ou à ISO 27001, ce dossier peut soutenir la continuité, le contrôle des accès privilégiés et la traçabilité. Il ne prouve pas à lui seul la conformité et ne remplace ni une évaluation globale ni un test d’intrusion. L’objectif est de produire une chaîne de décision et d’exécution vérifiable : qui a autorisé, qui a utilisé, pourquoi, quelles actions ont été menées et comment la situation a été normalisée.

Adaptez la gouvernance à la taille et au fonctionnement réel de l’organisation. Une école, une ASBL ou un cabinet avec une petite équipe aura besoin d’une procédure courte et de suppléants externes clairement mandatés. Un groupe multi-sites ou un établissement de santé devra intégrer l’astreinte, les rôles locaux, la disponibilité hors heures et les dépendances critiques. Le principe reste identique : l’urgence ne dispense jamais de responsabilité.

Quelles erreurs rendent le dispositif dangereux ou inutilisable ?

Les échecs les plus fréquents viennent d’une dépendance partagée, d’un usage quotidien ou d’un compte jamais testé.

Évitez un seul compte, une identité synchronisée, une méthode liée au smartphone d’une personne, une clé conservée près du poste ou une procédure disponible uniquement dans SharePoint. Chaque usage inutile augmente l’exposition et brouille la finalité du dispositif.

Ne créez pas d’exclusion d’accès conditionnel sans inventaire ni surveillance et ne modifiez jamais les deux chemins de récupération simultanément. Un test ne s’arrête pas à la connexion : l’alerte, l’action bénigne, la fermeture de session, la remise sous scellé et le compte rendu prouvent ensemble la capacité réelle.