Une authentification multifacteur indisponible pour un compte ne doit pas disparaître dans une liste de « cas particuliers ». L’équipe doit savoir quel accès reste ouvert, pourquoi la mesure normale ne peut pas être appliquée aujourd’hui, ce qui limite temporairement l’exposition, qui accepte le risque et à quelle date l’exception prend fin. Cette fiche est une décision de sécurité limitée, pas une dispense permanente de MFA. La politique de sécurité des systèmes d’information établit le principe ; la présente méthode traite uniquement la preuve et la fin d’un écart identifié.
Une indisponibilité technique, un appareil incompatible, une intervention d’urgence ou une dépendance à un prestataire exigent des réponses différentes. L’absence de téléphone personnel ne signifie pas que seul le retrait de MFA soit possible : une clé matérielle, un autre mode d’authentification ou un poste dédié peuvent être étudiés. À l’inverse, une solution alternative qui dépend du même fournisseur d’identité en panne ne résout pas un scénario de secours. Le guide Microsoft sur les comptes d’accès d’urgence distingue précisément les comptes de secours des usages ordinaires et insiste sur l’authentification forte, la surveillance et les essais réguliers. Ces prescriptions concernent sa plateforme ; la logique de dépendance et de vérification est transposable comme méthode, sans en faire une règle légale universelle.
Décider d’abord si une exception est recevable
Avant d’ouvrir la fiche, vérifiez le besoin réel. Le compte est-il humain, technique, partagé ou dédié à une urgence ? Quel service, rôle et environnement peut-il atteindre ? Une application qui ne sait pas demander un second facteur peut parfois être placée derrière un proxy d’accès, un bastion ou une fédération. Un compte technique peut être remplacé par une identité de charge de travail avec secret court, sans assimiler ce secret à la MFA d’une personne. La politique de mots de passe inspirée des recommandations ANSSI apporte le cadre des secrets, mais ne suffit pas à démontrer qu’une exception MFA est sûre.
Demandez au demandeur la contrainte vérifiable : version de l’application, journal d’essai, impossibilité de déployer une clé physique dans le délai, ou nécessité de préserver un accès de récupération. Une préférence d’utilisateur ou une économie non chiffrée ne décrit pas une impossibilité. Consignez les options rejetées et pourquoi : coût disproportionné pour une fenêtre de quelques jours, incompatibilité testée, dépendance au même point de défaillance. Cette comparaison évite que « impossible » devienne une étiquette irréfutable.
Séparez également l’accès à maintenir de la personne qui demande la dérogation. Un prestataire qui doit intervenir sur un seul serveur n’a pas nécessairement besoin d’un compte permanent sur toute l’administration. Réduire le périmètre peut être la première mesure, avant même de chercher un facteur alternatif. Si une règle contractuelle ou sectorielle applicable exige un contrôle précis, identifiez-la ; une fiche interne ne peut pas la neutraliser par simple signature.
La fiche de décision, champ par champ
La fiche doit être lisible sans entretien avec son auteur. Utilisez un identifiant stable, reliez-le au compte et au ticket de changement, mais évitez de placer un secret ou un code de secours dans le document. Le tableau suivant est un modèle éditorial, à adapter à l’organisation ; il n’est pas un formulaire imposé par un texte réglementaire.
| Champ | Question à renseigner | Preuve attendue |
|---|---|---|
| Service et compte | Quel identifiant, rôle, application et environnement ? | Inventaire ou demande d’accès datée |
| Contrainte | Qu’est-ce qui empêche la MFA normale ? | Essai, incident ou limite technique vérifiée |
| Scénario d’attaque | Que pourrait faire un acteur avec le premier facteur seul ? | Chemin d’accès et privilèges décrits |
| Mesure alternative | Qu’est-ce qui réduit cet accès précis ? | Configuration, essai et responsable |
| Fenêtre | Quand commence et finit l’écart ? | Date, événement de fin et alerte |
| Décision | Qui approuve quel risque résiduel ? | Nom, rôle, date et réserves |
| Sortie | Comment rétablir le contrôle normal ? | Responsable, jalon, preuve de fermeture |
La description du scénario doit aller au-delà de « risque élevé ». Écrivez par exemple : un mot de passe compromis depuis l’internet permettrait d’ouvrir le portail d’administration et de modifier les comptes ; l’attaque n’exige pas d’accès préalable au réseau. Si le compte est déjà limité à un bastion interne, dites ce qui protège le bastion et qui peut modifier sa politique. La sécurité des données avec SSO explique une partie de l’architecture d’identité, sans prouver la protection de chaque chemin de secours.
Choisir des contrôles réellement compensatoires
Une mesure est compensatoire si elle agit sur le scénario rendu possible par l’absence de MFA et si l’on peut constater son fonctionnement. Autoriser seulement un poste administré réduit l’exposition d’un mot de passe volé, mais ne protège pas si le poste lui-même est compromis. Limiter les horaires d’accès peut aider à détecter un usage anormal ; cette limite ne prouve pas l’identité. Une approbation humaine avant élévation de privilège peut réduire la portée, à condition qu’elle soit effectivement obligatoire et que l’approbateur ne dépende pas du même compte. Une liste d’adresses IP n’est utile que si les adresses de sortie sont maîtrisées et surveillées.
Associez prévention, détection et réaction. Par exemple, le compte ne peut se connecter qu’au bastion, ses privilèges ne sont activés que pour une intervention annoncée, chaque connexion déclenche une alerte vers une personne distincte, et l’activité est revue au lendemain de l’intervention. Définissez le destinataire, la fenêtre de surveillance et la procédure si l’alerte survient hors créneau. Une notification envoyée à une boîte que personne ne lit n’est pas une mesure opérationnelle.
Ne qualifiez pas de « MFA équivalente » n’importe quelle combinaison de restriction réseau et de journalisation. L’authentification multifacteur vérifie plusieurs facteurs au moment de l’accès ; des mesures périphériques peuvent réduire le risque sans offrir la même propriété. L’évaluation de contrôles NIST SP 800-53A aide à distinguer le contrôle annoncé, l’élément observé et l’essai qui montre son effet. Elle n’impose ni ce tableau ni un seuil universel de compensation à toutes les entreprises françaises.
Conservez les éléments de configuration utiles sous contrôle d’accès : règle du bastion, liste d’autorisation, alerte active, journal d’un essai sans divulguer les secrets. Si la preuve contient des adresses personnelles ou des données sensibles, indiquez son emplacement sécurisé et son propriétaire plutôt que d’en recopier tout le contenu dans la fiche. La qualité de la décision tient à la traçabilité de la vérification, pas au volume de captures d’écran.
Exemple suivi : application de maintenance incompatible
Une entreprise fictive exploite une console de maintenance héritée. La version actuelle accepte un mot de passe mais pas la MFA. Trois techniciens y interviennent lors d’incidents sur une installation industrielle. La demande initiale propose d’exclure définitivement tous les techniciens de la politique MFA. L’équipe sécurité refuse ce périmètre : la contrainte concerne seulement cette console, non leurs autres accès. Elle crée des identifiants nominatifs dédiés, interdit l’accès direct depuis l’internet et impose un passage par un bastion qui, lui, demande une authentification forte.
Le scénario restant est le vol du mot de passe de la console depuis un poste autorisé ou un abus lors d’une session déjà ouverte. Les droits de chaque technicien sont réduits à l’installation concernée. La connexion au bastion est journalisée, l’ouverture de la console déclenche une alerte au responsable d’astreinte et une revue quotidienne des sessions a lieu pendant la période d’exception. Un test démontre qu’une connexion directe depuis un autre réseau échoue et que l’alerte arrive au bon destinataire. Ces observations ne rendent pas la console équivalente à une application MFA ; elles expliquent pourquoi l’exposition provisoire peut être acceptée.
La fiche porte une date de début, une date de fin choisie en fonction du calendrier de remplacement, et un jalon intermédiaire de vérification. La responsable du système confirme le besoin métier, le responsable sécurité décrit le risque résiduel et le décideur habilité accepte l’accès jusqu’au jalon. Si le remplacement est retardé, l’exception ne se prolonge pas silencieusement : le demandeur présente l’état des travaux, les alertes, les incidents et les options nouvelles. Une extension est une nouvelle décision datée, avec possibilité de refuser ou de réduire les accès.
Supposons qu’un technicien quitte l’équipe avant la fin. La révocation de son identifiant est un événement immédiat ; attendre la date d’expiration globale serait incohérent. Si le bastion subit un incident ou si les alertes cessent, la mesure compensatoire n’est plus démontrée. La fiche doit alors être réévaluée, même si l’application n’a pas changé. Ce caractère conditionnel est la différence entre une décision vivante et une simple exception enregistrée.
Distinguer les comptes d’urgence des dispenses ordinaires
Un accès de secours destiné à reprendre l’administration lorsque l’identité habituelle est indisponible n’a pas le même objectif qu’un compte de maintenance régulier. Pour Microsoft Entra, la documentation recommande des comptes d’urgence indépendants de l’identité fédérée, protégés par des méthodes résistantes au hameçonnage, surveillés et validés périodiquement. Elle indique aussi qu’une politique d’accès conditionnel bloquante peut rendre cet accès inutilisable pendant l’incident. En pratique, « compte exclu d’une politique conditionnelle » ne veut pas dire « compte sans authentification forte ». La méthode retenue doit être testée dans le scénario où les services habituels sont indisponibles.
La fiche de secours indique qui détient les moyens d’accès, comment une utilisation est autorisée ou constatée, qui reçoit l’alerte, et ce que l’équipe vérifie après usage. Les clés et mots de passe ne sont pas consignés en clair dans le registre d’exception. Faites un exercice contrôlé, puis examinez si l’essai a produit les journaux attendus. Documentez séparément la fréquence de vos essais et la justification locale ; une cadence propre à un fournisseur ne devient pas mécaniquement une exigence de tout système.
Si l’urgence devient une routine, le dispositif est mal qualifié. Les interventions prévisibles doivent retrouver un compte normal et une procédure d’accès forte. Le guide d’homologation de sécurité situe la décision de risque à un niveau plus large ; il ne remplace pas la fiche par compte et par fenêtre d’accès. Cette distinction aide l’auditeur à comprendre pourquoi le décideur a accepté une exposition limitée, plutôt qu’une baisse générale du niveau de sécurité.
Approuver sans confondre demande, expertise et acceptation
Le responsable métier confirme que l’accès est nécessaire et quelles conséquences aurait son indisponibilité. L’équipe identité établit les possibilités techniques et prouve la configuration alternative. La sécurité décrit le scénario, les limites de la compensation et les conditions de surveillance. Enfin, une personne dotée de la délégation appropriée prend la décision résiduelle. Ces rôles peuvent être adaptés à la taille de l’entreprise, mais une même personne ne devrait pas simplement s’autoaccorder un accès puissant sans examen distinct.
La décision écrite doit être précise : « accès à telle console pour tels comptes jusqu’à telle date, sous réserve que le bastion et l’alerte restent actifs ». Le refus est également une décision utile lorsqu’aucune mesure disponible ne réduit suffisamment l’exposition. Un approbateur ne doit pas signer un risque qu’il ne comprend pas : indiquez les conséquences métiers plausibles et ce qui reste incertain. Si une donnée décisive manque, décidez éventuellement d’un périmètre plus réduit, avec une date de collecte, au lieu de qualifier la mesure inconnue d’efficace.
Une exception qui touche des données personnelles ou un service soumis à des obligations sectorielles peut nécessiter un examen supplémentaire. Il faut vérifier les textes et contrats applicables au système concerné, pas inscrire automatiquement « conforme » après approbation interne. Cette page propose une méthode de décision et de preuve ; elle ne crée pas de dérogation à une obligation externe. L’exposition décrite dans la fiche doit rester compatible avec la décision de sécurité plus générale de l’organisation.
Surveiller l’échéance et fermer l’exception
Inscrivez une échéance fixe et un déclencheur anticipé : mise à jour de l’application, changement de prestataire, augmentation des privilèges, échec d’une alerte, incident, départ du titulaire ou disponibilité d’une solution MFA. Le propriétaire reçoit une alerte suffisamment tôt pour installer la solution, la tester et demander une nouvelle décision si nécessaire. Un tableau qui ne signale l’expiration qu’après la date laisse survivre l’écart sans approbation valide.
La fermeture exige plus qu’un statut « résolu ». Vérifiez que la MFA fonctionne pour les comptes concernés, que l’exclusion a été retirée, que l’ancien chemin d’accès n’est plus disponible et que les journaux montrent un essai concluant. Pour un compte supprimé, prouvez la révocation et l’absence de dépendance métier restante. Associez cette preuve à la décision d’origine et indiquez la date de clôture. Si l’accès a été remplacé par une autre architecture, décrivez la nouvelle frontière de contrôle plutôt que de conserver une exception périmée.
Lors d’une revue périodique, posez cinq questions : la contrainte subsiste-t-elle ; le périmètre a-t-il changé ; les mesures alternatives ont-elles fonctionné ; des alertes ou incidents ont-ils révélé un écart ; la date de fin est-elle encore défendable ? La gestion des écarts et du plan d’actions peut aider à relier la mesure provisoire à un essai de correction. Ne faites pas d’une fiche d’exception un substitut à la correction planifiée.
Contrôle final de la fiche
Un lecteur extérieur doit pouvoir retrouver le compte, la contrainte démontrée, le scénario d’attaque, les options écartées, chaque mesure et son essai, le décideur, la durée et la fermeture attendue. Il doit aussi voir qui réagit si la mesure compensatoire tombe avant l’échéance. Si l’un de ces éléments manque, la fiche ne permet pas de distinguer une réduction de risque réelle d’un simple accord administratif. Une exception courte, étroite et vérifiable peut être gouvernée ; une exemption générale et tacitement renouvelée ne le peut pas.