8 Min. temps de lecture<\/p>\n
Une MFA adaptive qui fonctionne lors de la connexion \u00e9choue pourtant lors de l’audit si personne ne peut prouver selon quelle r\u00e8gle elle demande le second facteur et \u00e0 quel moment.<\/strong> C’est pr\u00e9cis\u00e9ment cette lacune que NIS2 met en lumi\u00e8re : la directive exige non seulement qu’une authentification bas\u00e9e sur les risques existe, mais aussi que l’entreprise puisse \u00e9valuer l’efficacit\u00e9 de ses mesures. Ceux qui activent simplement Entra ID, Okta ou Duo et laissent les r\u00e8gles d’acc\u00e8s conditionnel dans la t\u00eate de l’\u00e9quipe IT disposent d’une technologie, mais pas n\u00e9cessairement d’une preuve document\u00e9e en cas de doute.<\/p>\n Les points cl\u00e9s en bref<\/p>\n En lien :<\/span>La faille que seule l’IA a d\u00e9tect\u00e9e<\/a> \/<\/span> Le plan d’urgence que personne n’a test\u00e9<\/a><\/p>\n Qu’est-ce que la MFA adaptive ?<\/strong> L’authentification multifacteur (MFA) adaptive ou bas\u00e9e sur les risques \u00e9value chaque connexion en fonction de signaux contextuels et ne demande le second facteur que si le risque d\u00e9passe un seuil d\u00e9fini. Une connexion depuis un ordinateur portable g\u00e9r\u00e9 sur le r\u00e9seau de l’entreprise passe sans encombre, tandis que la m\u00eame identit\u00e9 depuis une nouvelle adresse IP dans un autre pays d\u00e9clenche une demande de Step-up ou est bloqu\u00e9e. La technologie sous-jacente est disponible depuis des ann\u00e9es dans Entra ID, Okta et Duo.<\/p>\n Le point sur lequel NIS2 intervient ne se limite pas \u00e0 la technologie. L’article 21, paragraphe 2, de la directive exige des mesures proportionn\u00e9es aux risques, conformes \u00e0 l’\u00e9tat de l’art, ainsi que des concepts pour \u00e9valuer leur efficacit\u00e9. La directive mentionne explicitement l’authentification multifacteur comme mesure appropri\u00e9e, l\u00e0 o\u00f9 elle est pertinente. Pour un audit, cela d\u00e9place la question pertinente : il ne s’agit plus de savoir si une MFA est active, mais plut\u00f4t selon quelle r\u00e8gle le second facteur est d\u00e9clench\u00e9, qui est responsable de cette r\u00e8gle et si le seuil correspond aux besoins de protection des syst\u00e8mes concern\u00e9s.<\/p>\n C’est ici que de nombreuses configurations, qui fonctionnent parfaitement en exploitation, \u00e9chouent. Les r\u00e8gles existent sous forme de politique d’acc\u00e8s conditionnel dans le tenant, mais personne ne les a jamais export\u00e9es en tant que document, personne ne peut en montrer l’historique, et les valeurs seuils ont \u00e9t\u00e9 reprises des param\u00e8tres par d\u00e9faut sans que quiconque ne les ait justifi\u00e9es par rapport aux risques propres \u00e0 l’entreprise. La mesure est en place, mais la preuve de son efficacit\u00e9 fait d\u00e9faut.<\/p>\n La premi\u00e8re \u00e9tape pratique est sans \u00e9clat : la politique d’authentification doit \u00eatre extraite de l’outil et mise sous une forme lisible par un auditeur sans acc\u00e8s administrateur. Dans Entra ID, vous exportez les politiques d’acc\u00e8s conditionnel via Microsoft Graph au format JSON, dans Okta via l’API Policy, dans Duo via l’API Admin. Cet export doit \u00eatre versionn\u00e9 dans le m\u00eame d\u00e9p\u00f4t que le reste de la documentation de s\u00e9curit\u00e9.<\/p>\n Plus important que le format est la justification qui l’accompagne. Pour chaque condition de step-up, une phrase explique pourquoi ce seuil a \u00e9t\u00e9 choisi. Par exemple : pour les comptes ayant acc\u00e8s \u00e0 la comptabilit\u00e9, la demande de step-up est d\u00e9clench\u00e9e d\u00e8s une g\u00e9olocalisation inconnue, car ces syst\u00e8mes sont class\u00e9s comme hautement sensibles selon l’analyse des besoins de protection. Pour un wiki interne, une r\u00e8gle plus l\u00e9g\u00e8re suffit. Ce lien entre le besoin de protection et la r\u00e8gle d’authentification est pr\u00e9cis\u00e9ment ce qui rend la mesure v\u00e9rifiable.<\/p>\n Un journal des modifications avec principe des quatre yeux est \u00e9galement judicieux. Quiconque assouplit une r\u00e8gle d’authentification, par exemple parce qu’un service se plaint de trop nombreuses demandes, ne devrait pas le faire discr\u00e8tement dans le tenant. Une validation document\u00e9e prot\u00e8ge, en cas d’incident, contre l’accusation d’avoir affaibli une mesure de protection sans justification. La responsabilit\u00e9 personnelle des dirigeants selon NIS2 fait de cette preuve bien plus qu’une simple formalit\u00e9.<\/p>\n Une MFA adaptative n’est aussi efficace que les signaux qu’elle analyse. En pratique, quatre cat\u00e9gories portent l’essentiel du poids : l’appareil et son statut de gestion, le contexte r\u00e9seau 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.<\/p>\n Le statut de gestion de l’appareil est le signal individuel le plus fiable. Une connexion depuis un ordinateur portable enregistr\u00e9 via la gestion des appareils mobiles et conforme est substantiellement plus digne de confiance que depuis un appareil inconnu, ind\u00e9pendamment de la localisation. Les signaux de localisation, en revanche, sont moins fiables qu’ils n’y paraissent : VPN, r\u00e9seau mobile et d\u00e9placements professionnels g\u00e9n\u00e8rent constamment de nouvelles g\u00e9olocalisations qui, en soi, ne signifient pas une attaque. Celui qui pond\u00e8re trop strictement la localisation g\u00e9n\u00e8re de la frustration sans gain de s\u00e9curit\u00e9.<\/p>\n Passe l’audit<\/p>\n \u00c9choue \u00e0 l’audit<\/p>\n Deux configurations d\u00e9terminent de mani\u00e8re disproportionn\u00e9e si une MFA adaptative passe avec succ\u00e8s un audit. La premi\u00e8re 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\u00e9clenche des requ\u00eates en continu jusqu’\u00e0 ce qu’une personne, exc\u00e9d\u00e9e, finisse par valider. Microsoft, Okta et Duo proposent en revanche une correspondance num\u00e9rique, o\u00f9 l’utilisateur doit saisir ou confirmer dans l’application un chiffre affich\u00e9 \u00e0 l’\u00e9cran de connexion. Ce m\u00e9canisme est disponible depuis longtemps chez les trois fournisseurs et devrait \u00eatre impos\u00e9, et non optionnel.<\/p>\n Le second levier concerne les comptes de secours (Break-Glass). Toute MFA adaptative n\u00e9cessite des acc\u00e8s d’urgence exempt\u00e9s des r\u00e8gles de contr\u00f4le d’acc\u00e8s conditionnel bloquantes, afin qu’une erreur de configuration ne verrouille pas compl\u00e8tement l’entreprise. Exempt\u00e9s ne signifie pas non prot\u00e9g\u00e9s : ces comptes doivent rester li\u00e9s \u00e0 un facteur particuli\u00e8rement robuste, id\u00e9alement un jeton mat\u00e9riel FIDO2 ou un certificat, plut\u00f4t que de contourner simplement la v\u00e9rification bas\u00e9e sur les risques. Parce qu’ils constituent un point d’attaque privil\u00e9gi\u00e9 et connu, ils doivent \u00eatre assortis d’une journalisation sp\u00e9cifique et stricte, de sorte que toute utilisation d\u00e9clenche imm\u00e9diatement une alerte. Un compte exempt\u00e9 sans liaison forte et sans surveillance est une constatation r\u00e9currente lors des entretiens d’audit.<\/p>\n La derni\u00e8re \u00e9tape consiste \u00e0 traduire la configuration dans le langage utilis\u00e9 par l’auditeur. Le catalogue IT-Grundschutz du BSI, dans le composant ORP.4 Gestion des identit\u00e9s et des autorisations, pr\u00e9sente des exigences qui peuvent servir de cadre de r\u00e9f\u00e9rence pour une MFA adaptative. ORP.4 n’est pas un mapping d\u00e9di\u00e9 \u00e0 la MFA, mais couvre l’authentification, le contr\u00f4le des autorisations et les acc\u00e8s d’urgence. En confrontant vos r\u00e8gles d’escalade, les exigences mat\u00e9rielles et les comptes d’urgence \u00e0 ces exigences, vous ne fournissez pas des captures d’\u00e9cran d’outils, mais une correspondance dans un langage que l’auditeur ma\u00eetrise.<\/p>\n Ce mapping n’a pas besoin d’\u00eatre complexe. Un tableau mettant en regard chaque exigence du catalogue IT-Grundschutz avec la r\u00e8gle de politique concr\u00e8te et l’emplacement de la preuve suffit dans la plupart des audits. Il d\u00e9place la discussion de la question de savoir si la mesure est conforme \u00e0 l’\u00e9tat de l’art \u00e0 celle, d\u00e9j\u00e0 r\u00e9solue, de sa mise en \u0153uvre. C’est pr\u00e9cis\u00e9ment ce d\u00e9placement qui distingue une MFA adaptative qui fonctionne simplement d’une MFA qui sert de contr\u00f4le efficace.<\/p>\n Techniquement, elle r\u00e9pond \u00e0 une exigence de base, mais elle ne suffit souvent pas pour une preuve solide. L’article 21 de la NIS2 exige des mesures proportionn\u00e9es aux risques et une \u00e9valuation de leur efficacit\u00e9. Une MFA sans politique document\u00e9e et justifi\u00e9e par rapport au niveau de protection est pr\u00e9sente, mais difficile \u00e0 d\u00e9montrer comme efficace. La variante adaptative, avec des r\u00e8gles versionn\u00e9es et exportables, facilite cette d\u00e9monstration.<\/p>\n Une MFA normale exige le m\u00eame second facteur \u00e0 chaque connexion. Une MFA adaptative d\u00e9cide en fonction du contexte et peut documenter cette d\u00e9cision sous forme de r\u00e8gle. C’est pr\u00e9cis\u00e9ment cette logique documentable qui la rend plus pr\u00e9cieuse pour un audit NIS2, car elle rend visible le lien entre le risque et la mesure.<\/p>\n Le composant ORP.4 du catalogue IT-Grundschutz, d\u00e9di\u00e9 \u00e0 la gestion des identit\u00e9s et des autorisations, offre un cadre de r\u00e9f\u00e9rence adapt\u00e9, m\u00eame s’il ne contient pas de chapitre sp\u00e9cifique \u00e0 la MFA adaptative. En confrontant les r\u00e8gles 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\u00e9j\u00e0 lors des entretiens d’audit.<\/p>\n Gr\u00e2ce \u00e0 un d\u00e9ploiement progressif et \u00e0 une pond\u00e9ration judicieuse des signaux. Les signaux de localisation doivent \u00eatre moins pond\u00e9r\u00e9s que le statut de gestion du terminal, car le VPN et les d\u00e9placements professionnels g\u00e9n\u00e8rent en permanence de nouvelles g\u00e9olocalisations. Un pilote avec un groupe d’utilisateurs restreint permet d’identifier, avant un d\u00e9ploiement \u00e0 grande \u00e9chelle, les seuils trop stricts.<\/p>\n Parce qu’ils sont d\u00e9lib\u00e9r\u00e9ment exempt\u00e9s des politiques bloquantes et repr\u00e9sentent donc un point d’attaque privil\u00e9gi\u00e9. L’exemption est n\u00e9cessaire, mais elle doit rester li\u00e9e \u00e0 un facteur particuli\u00e8rement 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.<\/p>\n Pour une tra\u00e7abilit\u00e9 fiable, oui. Une politique versionn\u00e9e, avec historique des modifications et validation \u00e0 quatre yeux, prouve que les mesures de protection n’ont pas \u00e9t\u00e9 affaiblies de mani\u00e8re incontr\u00f4l\u00e9e. Compte tenu de la responsabilit\u00e9 personnelle des dirigeants selon NIS2, cette preuve est bien plus qu’une simple formalit\u00e9.<\/p>\n Plus d’articles du r\u00e9seau MBF Media<\/p>\n\n
Pourquoi NIS2 audite la politique MFA, pas la fonctionnalit\u00e9 MFA<\/h2>\n
Configurer la politique comme artefact exportable<\/h2>\n
Quels signaux portent r\u00e9ellement le moteur de risque<\/h2>\n
\n
\n
Correspondance num\u00e9rique et comptes de secours : deux leviers \u00e0 fort impact audit<\/h2>\n
Le mapping BSI comme langage commun avec l’auditeur<\/h2>\n
Foire aux questions<\/h2>\n
Une MFA standard activ\u00e9e suffit-elle pour la NIS2 ?<\/h3>\n
Quelle est la diff\u00e9rence entre une MFA adaptative et une MFA normale dans le contexte d’un audit ?<\/h3>\n
Quelle directive BSI est pertinente pour la MFA adaptative ?<\/h3>\n
Comment \u00e9viter que la MFA adaptative ne bloque les collaborateurs ?<\/h3>\n
Pourquoi les comptes de secours sont-ils un sujet d’audit ?<\/h3>\n
La politique MFA doit-elle \u00eatre versionn\u00e9e ?<\/h3>\n
Lectures recommand\u00e9es par la r\u00e9daction<\/h3>\n
\n