MFA adaptatif dans l’audit NIS2 : Quand la politique est-elle valable comme preuve ?

8 Min. temps de lecture

Une MFA adaptive qui fonctionne lors de la connexion échoue pourtant lors de l’audit si personne ne peut prouver selon quelle règle elle demande le second facteur et à quel moment. C’est précisément cette lacune que NIS2 met en lumière : la directive exige non seulement qu’une authentification basée sur les risques existe, mais aussi que l’entreprise puisse évaluer l’efficacité de ses mesures. Ceux qui activent simplement Entra ID, Okta ou Duo et laissent les règles d’accès conditionnel dans la tête de l’équipe IT disposent d’une technologie, mais pas nécessairement d’une preuve documentée en cas de doute.

Les points clés en bref

La politique comme preuve : L’article 21 de NIS2 exige des mesures proportionnées aux risques et une évaluation de leur efficacité. Une MFA adaptive sera bien plus solide lors d’un audit si ses règles sont exportées, versionnées et justifiées par rapport aux besoins de protection, même si la directive n’impose pas explicitement cette forme.
Break-Glass et Number-Matching : Deux configurations déterminent si la solution tient la route en cas d’urgence : les comptes de secours, exemptés des règles bloquantes mais liés à un facteur fort et surveillés, ainsi qu’une confirmation par correspondance de chiffres, qui rend les attaques par MFA-Fatigue inefficaces.
Le mapping BSI rend vérifiable : En alignant la logique de Step-up sur le module ORP.4 de la BSI-Grundschutz, vous fournissez à l’auditeur un langage qu’il connaît, plutôt qu’une configuration d’outil qu’il doit interpréter.

En lien :La faille que seule l’IA a détectée / Le plan d’urgence que personne n’a testé

Pourquoi NIS2 audite la politique MFA, pas la fonctionnalité MFA

Qu’est-ce que la MFA adaptive ? L’authentification multifacteur (MFA) adaptive ou basée sur les risques évalue chaque connexion en fonction de signaux contextuels et ne demande le second facteur que si le risque dépasse un seuil défini. Une connexion depuis un ordinateur portable géré sur le réseau de l’entreprise passe sans encombre, tandis que la même identité depuis une nouvelle adresse IP dans un autre pays déclenche une demande de Step-up ou est bloquée. La technologie sous-jacente est disponible depuis des années dans Entra ID, Okta et Duo.

Le point sur lequel NIS2 intervient ne se limite pas à la technologie. L’article 21, paragraphe 2, de la directive exige des mesures proportionnées aux risques, conformes à l’état de l’art, ainsi que des concepts pour évaluer leur efficacité. La directive mentionne explicitement l’authentification multifacteur comme mesure appropriée, là où elle est pertinente. Pour un audit, cela déplace la question pertinente : il ne s’agit plus de savoir si une MFA est active, mais plutôt selon quelle règle le second facteur est déclenché, qui est responsable de cette règle et si le seuil correspond aux besoins de protection des systèmes concernés.

C’est ici que de nombreuses configurations, qui fonctionnent parfaitement en exploitation, échouent. Les règles existent sous forme de politique d’accès conditionnel dans le tenant, mais personne ne les a jamais exportées en tant que document, personne ne peut en montrer l’historique, et les valeurs seuils ont été reprises des paramètres par défaut sans que quiconque ne les ait justifiées par rapport aux risques propres à l’entreprise. La mesure est en place, mais la preuve de son efficacité fait défaut.

Configurer la politique comme artefact exportable

La première étape pratique est sans éclat : la politique d’authentification doit être extraite de l’outil et mise sous une forme lisible par un auditeur sans accès administrateur. Dans Entra ID, vous exportez les politiques d’accès conditionnel via Microsoft Graph au format JSON, dans Okta via l’API Policy, dans Duo via l’API Admin. Cet export doit être versionné dans le même dépôt que le reste de la documentation de sécurité.

Plus important que le format est la justification qui l’accompagne. Pour chaque condition de step-up, une phrase explique pourquoi ce seuil a été choisi. Par exemple : pour les comptes ayant accès à la comptabilité, la demande de step-up est déclenchée dès une géolocalisation inconnue, car ces systèmes sont classés comme hautement sensibles selon l’analyse des besoins de protection. Pour un wiki interne, une règle plus légère suffit. Ce lien entre le besoin de protection et la règle d’authentification est précisément ce qui rend la mesure vérifiable.

Un journal des modifications avec principe des quatre yeux est également judicieux. Quiconque assouplit une règle d’authentification, par exemple parce qu’un service se plaint de trop nombreuses demandes, ne devrait pas le faire discrètement dans le tenant. Une validation documentée protège, en cas d’incident, contre l’accusation d’avoir affaibli une mesure de protection sans justification. La responsabilité personnelle des dirigeants selon NIS2 fait de cette preuve bien plus qu’une simple formalité.

Quels signaux portent réellement le moteur de risque

Une MFA adaptative n’est aussi efficace que les signaux qu’elle analyse. En pratique, quatre catégories portent l’essentiel du poids : l’appareil et son statut de gestion, le contexte réseau et de localisation, le comportement de connexion dans le temps et les signaux de menace externes comme les adresses IP malveillantes connues. L’essentiel n’est pas d’activer le plus de signaux possible, mais de savoir quel signal apporte quelle information.

Le statut de gestion de l’appareil est le signal individuel le plus fiable. Une connexion depuis un ordinateur portable enregistré via la gestion des appareils mobiles et conforme est substantiellement plus digne de confiance que depuis un appareil inconnu, indépendamment de la localisation. Les signaux de localisation, en revanche, sont moins fiables qu’ils n’y paraissent : VPN, réseau mobile et déplacements professionnels génèrent constamment de nouvelles géolocalisations qui, en soi, ne signifient pas une attaque. Celui qui pondère trop strictement la localisation génère de la frustration sans gain de sécurité.

Passe l’audit

Conformité des appareils comme signal obligatoire pour les systèmes sensibles
Number-matching imposé contre la MFA fatigue
Politique exportée et versionnée avec référence au besoin de protection
Comptes Break-Glass surveillés avec alerte

Échoue à l’audit

Seuils par défaut sans justification documentée
Validation push par simple tapotement sans code
Comptes d’urgence sans journalisation dédiée
Modifications de règles sans validation et historique

Correspondance numérique et comptes de secours : deux leviers à fort impact audit

Deux configurations déterminent de manière disproportionnée si une MFA adaptative passe avec succès un audit. La première concerne le type de confirmation. Une simple notification push, que l’utilisateur accepte d’un simple appui, ouvre la porte aux attaques par fatigue MFA : l’attaquant déclenche des requêtes en continu jusqu’à ce qu’une personne, excédée, finisse par valider. Microsoft, Okta et Duo proposent en revanche une correspondance numérique, où l’utilisateur doit saisir ou confirmer dans l’application un chiffre affiché à l’écran de connexion. Ce mécanisme est disponible depuis longtemps chez les trois fournisseurs et devrait être imposé, et non optionnel.

Le second levier concerne les comptes de secours (Break-Glass). Toute MFA adaptative nécessite des accès d’urgence exemptés des règles de contrôle d’accès conditionnel bloquantes, afin qu’une erreur de configuration ne verrouille pas complètement l’entreprise. Exemptés ne signifie pas non protégés : ces comptes doivent rester liés à un facteur particulièrement robuste, idéalement un jeton matériel FIDO2 ou un certificat, plutôt que de contourner simplement la vérification basée sur les risques. Parce qu’ils constituent un point d’attaque privilégié et connu, ils doivent être assortis d’une journalisation spécifique et stricte, de sorte que toute utilisation déclenche immédiatement une alerte. Un compte exempté sans liaison forte et sans surveillance est une constatation récurrente lors des entretiens d’audit.

Le mapping BSI comme langage commun avec l’auditeur

La dernière étape consiste à traduire la configuration dans le langage utilisé par l’auditeur. Le catalogue IT-Grundschutz du BSI, dans le composant ORP.4 Gestion des identités et des autorisations, présente des exigences qui peuvent servir de cadre de référence pour une MFA adaptative. ORP.4 n’est pas un mapping dédié à la MFA, mais couvre l’authentification, le contrôle des autorisations et les accès d’urgence. En confrontant vos règles d’escalade, les exigences matérielles et les comptes d’urgence à ces exigences, vous ne fournissez pas des captures d’écran d’outils, mais une correspondance dans un langage que l’auditeur maîtrise.

Ce mapping n’a pas besoin d’être complexe. Un tableau mettant en regard chaque exigence du catalogue IT-Grundschutz avec la règle de politique concrète et l’emplacement de la preuve suffit dans la plupart des audits. Il déplace la discussion de la question de savoir si la mesure est conforme à l’état de l’art à celle, déjà résolue, de sa mise en œuvre. C’est précisément ce déplacement qui distingue une MFA adaptative qui fonctionne simplement d’une MFA qui sert de contrôle efficace.

Foire aux questions

Une MFA standard activée suffit-elle pour la NIS2 ?

Techniquement, elle répond à une exigence de base, mais elle ne suffit souvent pas pour une preuve solide. L’article 21 de la NIS2 exige des mesures proportionnées aux risques et une évaluation de leur efficacité. Une MFA sans politique documentée et justifiée par rapport au niveau de protection est présente, mais difficile à démontrer comme efficace. La variante adaptative, avec des règles versionnées et exportables, facilite cette démonstration.

Quelle est la différence entre une MFA adaptative et une MFA normale dans le contexte d’un audit ?

Une MFA normale exige le même second facteur à chaque connexion. Une MFA adaptative décide en fonction du contexte et peut documenter cette décision sous forme de règle. C’est précisément cette logique documentable qui la rend plus précieuse pour un audit NIS2, car elle rend visible le lien entre le risque et la mesure.

Quelle directive BSI est pertinente pour la MFA adaptative ?

Le composant ORP.4 du catalogue IT-Grundschutz, dédié à la gestion des identités et des autorisations, offre un cadre de référence adapté, même s’il ne contient pas de chapitre spécifique à la MFA adaptative. En confrontant les règles d’escalade et les comptes d’urgence aux exigences d’ORP.4, vous traduisez la configuration de l’outil dans un langage que le BSI utilise déjà lors des entretiens d’audit.

Comment éviter que la MFA adaptative ne bloque les collaborateurs ?

Grâce à un déploiement progressif et à une pondération judicieuse des signaux. Les signaux de localisation doivent être moins pondérés que le statut de gestion du terminal, car le VPN et les déplacements professionnels génèrent en permanence de nouvelles géolocalisations. Un pilote avec un groupe d’utilisateurs restreint permet d’identifier, avant un déploiement à grande échelle, les seuils trop stricts.

Pourquoi les comptes de secours sont-ils un sujet d’audit ?

Parce qu’ils sont délibérément exemptés des politiques bloquantes et représentent donc un point d’attaque privilégié. L’exemption est nécessaire, mais elle doit rester liée à un facteur particulièrement robuste, comme un jeton FIDO2. Un compte d’urgence sans liaison forte et sans journalisation stricte est une constatation typique lors des entretiens d’audit.

La politique MFA doit-elle être versionnée ?

Pour une traçabilité fiable, oui. Une politique versionnée, avec historique des modifications et validation à quatre yeux, prouve que les mesures de protection n’ont pas été affaiblies de manière incontrôlée. Compte tenu de la responsabilité personnelle des dirigeants selon NIS2, cette preuve est bien plus qu’une simple formalité.