Un compte d’urgence Entra n’est utile que si des personnes autorisées peuvent l’utiliser lorsque l’administration habituelle échoue. Son existence dans une liste ne prouve ni l’accès aux moyens d’authentification, ni la possibilité de se connecter, ni l’arrivée d’une alerte à l’équipe de surveillance. Un exercice limité, annoncé et documenté permet de vérifier ces points sans simuler une panne sur un système de production.
Cette page fournit un script d’exercice et un compte rendu à adapter. La politique de mots de passe traite le cadre général d’authentification ; le dossier de revue des accès privilégiés examine les droits. Ici, l’objet est la capacité de secours et la preuve d’un test sûr. La documentation Microsoft Entra sur les comptes d’urgence, mise à jour en 2026, recommande notamment deux comptes ou plus, des identités cloud non fédérées, une authentification résistante à l’hameçonnage, la surveillance de toute connexion et des validations au moins tous les 90 jours. Ce sont des consignes produit, pas une cadence légale universelle.
Définir ce que l’exercice doit démontrer
Écrivez une hypothèse courte : « si les comptes d’administration ordinaires ne sont pas utilisables, l’équipe désignée peut accéder au tenant, effectuer une opération administrative sans effet métier et déclencher une alerte ». Ne vous contentez pas de « le compte fonctionne ». Le résultat attendu comprend l’identité de l’opérateur, la méthode d’accès, l’environnement client, la réussite d’une tâche bénigne, les journaux et la revue après usage.
Un exercice peut tester la disponibilité des comptes sans provoquer la panne contre laquelle ils sont prévus. Il ne faut pas désactiver l’annuaire fédéré, modifier massivement des règles d’accès conditionnel ou révoquer les administrateurs pour rendre la simulation « réaliste ». Définissez ce qui sera observé directement et ce qui restera une hypothèse. L’objectif est une assurance proportionnée, pas un risque opérationnel supplémentaire.
Reliez la capacité de secours au plan de continuité : qui déclare l’incident, qui autorise l’usage, qui contacte le support et qui décide du retour à l’administration normale ? Le compte d’urgence résout un accès au tenant ; il ne restaure pas à lui seul toutes les applications ni les réseaux dépendants.
Vérifier les prérequis avant d’ouvrir le compte
Confirmez le périmètre du tenant et les identifiants des comptes de secours sans recopier les secrets dans le document d’exercice. Vérifiez que les opérateurs autorisés sont disponibles, que le poste d’administration désigné fonctionne et que les moyens d’authentification peuvent être récupérés selon la procédure. Un compte cloud dont le facteur dépend du même téléphone, du même système fédéré ou d’un coffre inaccessible pendant l’incident perd une partie de son intérêt.
La recommandation Microsoft actuelle privilégie les comptes cloud utilisant le domaine .onmicrosoft.com, non synchronisés depuis un annuaire local, avec un rôle Global Administrator actif et permanent dans son scénario. Elle indique des passkeys FIDO2 ou l’authentification par certificat, ainsi que l’exclusion des politiques d’accès conditionnel qui bloqueraient la connexion. Ne transformez pas cette dernière recommandation en exemption générale de toute authentification forte. Examinez votre configuration et les exigences Microsoft réellement applicables avant un changement.
Vérifiez aussi la surveillance : une connexion prévue doit générer un événement exploitable et une notification à des destinataires qui ne sont pas seulement l’opérateur du test. Prévenez l’équipe de sécurité de la fenêtre et des identités concernées, mais ne désactivez pas l’alerte pour éviter un faux positif. L’exercice doit précisément prouver qu’elle atteint la bonne personne.
Attribuer les rôles pendant l’essai
Le responsable de l’exercice autorise le scénario et peut l’interrompre. L’opérateur réalise les étapes permises depuis un poste sûr. L’observateur consigne les horaires et résultats sans manipuler les secrets. L’équipe de surveillance confirme la réception des alertes. Un responsable indépendant examine ensuite la justification et les actions exécutées. Dans une petite organisation, certaines fonctions peuvent être réunies, mais le compte rendu doit dire qui a fait quoi.
Prévoyez un suppléant. Un plan de secours qui dépend d’une seule personne disponible et du seul emplacement où se trouve la clé physique reste fragile. Vérifiez les conditions d’accès au coffre ou aux équipements sans publier leur localisation détaillée dans un article ou un dossier accessible à tous. Le protocole de test peut référencer un document opérationnel plus restreint.
La PSSI fixe les responsabilités générales. Le script ci-dessous les transforme en observations limitées à une fenêtre contrôlée. Il ne remplace pas la procédure d’urgence complète ni la formation des personnes habilitées.
Définir les critères d’arrêt avant de commencer
Un exercice de secours doit s’arrêter si un incident réel survient, si une action imprévue touche la production, si l’opérateur ne peut plus distinguer l’objet de test d’un objet métier ou si l’équipe de surveillance constate un usage suspect concurrent. Désignez la personne qui peut ordonner l’arrêt et le canal par lequel elle le fait. Cette précaution évite que le déroulement d’un script soit poursuivi par inertie alors que ses hypothèses ne tiennent plus.
Prévoyez aussi une règle pour un échec de connexion. N’enchaînez pas des essais improvisés ou des modifications de politique afin d’obtenir un résultat vert avant la fin de la fenêtre. Notez le message, l’heure, la méthode et le contexte, puis interrompez ou poursuivez uniquement les observations encore sûres. L’analyse ultérieure identifiera la dépendance fautive et fixera un nouveau test. Un échec bien documenté est souvent plus utile qu’une réussite obtenue grâce à un contournement non approuvé.
Script d’exercice à remplir
| Phase | Action autorisée | Résultat et trace attendus |
|---|---|---|
| Autorisation | Valider tenant, fenêtre, opérateur, objectif | Décision datée et personnes informées |
| Préparation | Vérifier poste et moyen d’accès sans exposer le secret | Disponibilité constatée, dépendances notées |
| Connexion | Utiliser un compte d’urgence selon la procédure | Heure, résultat, méthode et éventuel refus |
| Tâche bénigne | Lire une configuration ou effectuer une opération sans effet métier | Autorisation suffisante et action tracée |
| Surveillance | Constater l’alerte de connexion et les journaux | Réception indépendante, délai observé |
| Fermeture | Se déconnecter et sécuriser le moyen d’accès | Sessions, état du compte et pièces vérifiés |
| Revue | Examiner usage, anomalies et mesures à prendre | Décision, propriétaire, échéance et prochain test |
Ce tableau est un modèle d’observation. Le choix d’une tâche bénigne dépend des permissions disponibles. Lire une configuration peut suffire à prouver l’accès administratif si le rôle et l’interface sont vérifiés ; une opération de modification en production n’est pas nécessaire pour tous les exercices. Si vous devez vérifier un pouvoir de changement, choisissez un objet de test isolé et un retour arrière approuvé.
Éviter que le test ne masque une faiblesse
L’équipe peut involontairement faciliter l’exercice en ouvrant un coffre normalement indisponible, en fournissant un poste spécial non prévu ou en guidant l’opérateur étape par étape. Notez ces aides. Elles peuvent être légitimes pendant un essai initial, mais la conclusion doit alors rester limitée : le processus n’a pas démontré qu’il fonctionnerait seul pendant une panne. Répétez ultérieurement un parcours plus autonome si le risque le justifie.
La connexion réussie ne prouve pas que tous les comptes de secours fonctionnent. Microsoft recommande au moins deux comptes pour la redondance ; vérifiez chacun selon un plan adapté. Des clés stockées au même endroit ou deux comptes soumis à la même dépendance ne forment pas une redondance solide. Le compte rendu identifie la dépendance commune et propose une correction.
La revue des accès privilégiés examine aussi les droits permanents et les cas où l’absence d’usage est normale. Un compte de secours rarement utilisé n’est pas nécessairement inutile. Sa justification est la continuité ; son usage non planifié, en revanche, doit déclencher une analyse immédiate.
Mesurer les alertes sans inventer un délai légal
Consignez l’heure de connexion, l’heure d’inscription dans les journaux, la création de l’alerte, la réception par l’astreinte et sa reconnaissance. Ces écarts révèlent des problèmes différents : retard de collecte, règle de détection absente, canal de notification inadapté ou destinataire indisponible. Fixez un objectif interne selon le risque et les capacités ; ne présentez pas un nombre de minutes comme une obligation générale du RGPD ou de Microsoft.
Testez également la qualité du message. Identifie-t-il le tenant, le compte, l’heure et le type d’événement sans divulguer un secret ? Le destinataire sait-il que l’essai était autorisé et comment distinguer un usage non annoncé ? L’annonce préalable au SOC doit permettre de reconnaître le test, non de supprimer la surveillance pendant la fenêtre.
La journalisation des événements de sécurité apporte le contexte des traces ; la durée et les champs disponibles dépendent du paramétrage. Conservez pour le dossier les références nécessaires, pas un export massif de journaux contenant d’autres données sensibles.
Rechercher les dépendances cachées
Un compte non fédéré peut encore dépendre d’un facteur, d’un poste, d’une connexion Internet, d’une équipe ou d’une politique d’accès. Listez ces dépendances avant le test puis confirmez ce qui a été observé. Une réussite depuis le bureau principal ne démontre pas que l’opérateur pourra agir depuis le site de secours. Une réussite avec le responsable habituel présent ne démontre pas la capacité de son suppléant.
Pour chaque dépendance, choisissez une vérification raisonnable. Le coffre physique peut faire l’objet d’un contrôle d’accès et d’un essai de récupération ; le poste peut être démarré et mis à jour ; la méthode d’authentification peut être utilisée pendant la fenêtre. N’écrivez pas le code de récupération ou la clé privée dans le compte rendu. L’objectif est de prouver que le chemin existe, sans le rendre exploitable par une personne non autorisée.
Le guide SSO décrit l’intérêt d’une identité centralisée. Le compte de secours répond à l’autre versant : que fait l’équipe lorsque les moyens centralisés de gestion ou de fédération ne suffisent plus ? Il doit être conçu pour ce scénario précis, pas servir d’identité d’administration quotidienne.
Exemple d’exercice et de réserve
Dans un exemple fictif, deux comptes d’urgence sont inscrits dans le registre. L’équipe teste le premier à 10 h 00. L’opérateur récupère le moyen d’authentification selon la procédure, se connecte depuis le poste désigné et consulte une page administrative. Le journal enregistre la connexion. L’alerte attendue n’arrive pas au téléphone d’astreinte : elle a été envoyée à une boîte de messagerie dont l’abonnement a expiré.
Le compte n’est pas déclaré « inutilisable » : l’accès administratif a fonctionné. Mais le contrôle de surveillance a échoué. L’équipe crée une action pour corriger le destinataire, teste l’alerte sans ouvrir de nouveau droit et inscrit la preuve de réception. Le second compte n’a pas été testé ce jour-là ; le rapport ne laisse pas entendre qu’il l’a été. Il prévoit un créneau distinct et vérifie la disponibilité de sa clé dans un lieu séparé.
Le résultat final distingue capacité d’accès, capacité de détection et couverture de la redondance. Il identifie le responsable de chaque correction et la date de vérification. Un pourcentage global « 80 % conforme » aurait masqué l’élément le plus important : une connexion d’urgence non signalée à l’astreinte.
Examiner chaque usage après l’exercice
La documentation Microsoft prévoit une revue après utilisation pour déterminer si l’emploi du compte était prévu, lié à une urgence réelle ou non autorisé, puis examiner les actions effectuées. Après un exercice, cette revue confirme les étapes, les horaires, les opérations et les écarts. Elle cherche aussi des effets involontaires : session restée ouverte, clé mal rangée, rôle modifié, notification ignorée. Une simple ligne « test réussi » ne suffit pas.
Si l’opérateur a eu besoin d’aide, indiquez laquelle. Si une politique d’accès conditionnel a bloqué la connexion, ne la modifiez pas à la volée sans analyse ; établissez le réglage et le chemin de correction dans une fenêtre autorisée. Si un secret semble exposé, appliquez la procédure de compromission appropriée. Le protocole d’exercice ne justifie pas une exception permanente non revue.
Le NIST SP 800-53A permet de structurer examen de procédure, entretien des acteurs et test technique. Ces méthodes sont adaptables ; la fréquence recommandée par Microsoft pour Entra ne devient pas, par cette citation, une obligation européenne pour tous les systèmes.
Conserver un dossier de preuve utilisable
Le dossier peut contenir l’autorisation de l’exercice, les identifiants non secrets des comptes, les horaires, le résultat de la tâche bénigne, les références de journaux et l’accusé de réception de l’alerte. Ajoutez la revue après usage, la décision sur chaque anomalie et la date du prochain essai. Une autre personne doit pouvoir distinguer ce qui a réellement été testé de ce qui a seulement été vérifié sur le papier.
Les journaux et captures peuvent révéler des adresses, identités ou détails de configuration. Conservez-les dans un espace protégé et limitez la diffusion du compte rendu aux faits nécessaires aux décideurs. Ne joignez ni clé, ni certificat privé, ni code de récupération. La preuve recherchée est la capacité du processus et son contrôle, non la publication des moyens d’accès d’urgence.
Planifier la prochaine validation et le retour d’expérience
Le compte rendu se termine par les résultats observés, les limites, les corrections et le prochain rendez-vous. Microsoft recommande une validation au moins tous les 90 jours pour ces comptes Entra, avec vérification de l’accès et des alertes. Vérifiez la version actuelle de cette documentation et la pertinence pour votre configuration. Une obligation sectorielle ou contractuelle peut demander davantage ; elle doit être citée séparément.
Le prochain exercice ne doit pas recopier exactement le scénario si le principal échec venait d’une dépendance spécifique. Il peut vérifier un autre compte, le suppléant, un autre poste ou la réception de l’alerte hors horaires. Conservez une comparaison : qu’a-t-on corrigé depuis la dernière fois, quelle réserve demeure et qui accepte le risque résiduel ? Un exercice réussi est utile lorsqu’il améliore la capacité de secours réelle, pas seulement lorsqu’il produit une attestation de plus.