Gouvernance de Microsoft Entra Conditional Access en 2026

Il est 09 h 12 un mardi lorsque Maria, RSSI d’une fintech européenne en forte croissance, ouvre un rapport de préparation à DORA qui aurait dû être routinier. Son tableau de bord Microsoft Entra Conditional Access paraît robuste. L’authentification multifacteur est imposée aux administrateurs. L’authentification héritée est bloquée. Les connexions à haut risque font l’objet d’une exigence supplémentaire ou sont refusées. Les applications financières sensibles exigent des appareils conformes. L’accès par navigateur depuis des terminaux non gérés est restreint.

Puis elle lit le constat de l’auditeur.

« Vos règles Conditional Access sont techniquement solides, mais elles existent hors de tout cadre de gouvernance. Montrez-nous la politique approuvée par le conseil d’administration qui impose ces paramètres. Montrez-nous l’enregistrement de changement relatif à la règle modifiée le mois dernier. Montrez-nous comment la politique de connexion à haut risque était active pendant l’attaque présumée par bourrage d’identifiants. Montrez-nous comment ces éléments probants soutiennent ISO 27001, DORA, NIS2 et GDPR. »

L’équipe identité peut exporter la configuration. Le SOC peut présenter les journaux de connexion. Le responsable de la conformité peut renvoyer vers un dossier de politiques. Mais personne ne peut produire une chaîne de traçabilité probante et gouvernée reliant risque, politique, approbation, configuration, exceptions, surveillance, réponse aux incidents, obligations de protection de la vie privée et revue de direction.

C’est le problème de gouvernance de Conditional Access en 2026.

Microsoft Entra Conditional Access n’est plus un simple paramètre d’identité. C’est un système de contrôle relevant du conseil d’administration, qui détermine qui peut accéder aux services cloud, dans quelles conditions, depuis quels appareils, avec quel niveau de robustesse d’authentification et avec quelles restrictions de session. Pour les organisations réglementées, ces décisions doivent être explicables, défendables et cartographiées avec les obligations prévues par ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST et COBIT 2019.

Conditional Access est désormais un système de contrôle auditable

Conditional Access se situe à l’intersection de l’identité, de la posture de sécurité des terminaux, de la sensibilité des applications, de la localisation, du risque de connexion, du risque utilisateur, du comportement de session et de la journalisation. Une seule politique peut exiger l’authentification multifacteur, imposer un appareil conforme, bloquer l’accès depuis une localisation risquée, restreindre les téléchargements depuis des navigateurs non gérés ou forcer une réauthentification lorsque le niveau de risque change.

Cela en fait l’un des points d’application Zero Trust les plus puissants dans les environnements cloud Microsoft. Cela le rend aussi fortement auditable.

Selon ISO/IEC 27001:2022, un contrôle n’est pas mature simplement parce qu’il existe dans un portail. L’organisation doit comprendre son contexte, apprécier les risques de sécurité de l’information, sélectionner les traitements des risques, documenter la Déclaration d’applicabilité, exploiter les contrôles, surveiller leur efficacité et s’améliorer dans le temps. Les clauses pertinentes comprennent la Clause 6.1.2 pour l’appréciation des risques, la Clause 6.1.3 pour le traitement des risques, la Clause 7.5 pour les informations documentées, la Clause 8.1 pour la planification et le contrôle opérationnels, la Clause 9.1 pour la surveillance et la Clause 9.3 pour la revue de direction.

L’Annexe A, alignée sur ISO/IEC 27002:2022, fournit le langage opérationnel des contrôles que les auditeurs reconnaîtront. Conditional Access soutient couramment :

• 5.15 Contrôle d’accès
• 5.16 Gestion des identités
• 5.17 Informations d’authentification
• 5.18 Droits d’accès
• 8.1 Terminaux utilisateurs
• 8.2 Droits d’accès privilégiés
• 8.3 Restriction d’accès aux informations
• 8.5 Authentification sécurisée
• 8.15 Journalisation
• 8.16 Activités de surveillance

Pour les organisations réglementées dans l’UE, l’exigence de gouvernance est encore plus explicite. NIS2 Article 20 confie aux organes de direction la responsabilité d’approuver et de superviser les mesures de gestion des risques de cybersécurité. NIS2 Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment le contrôle d’accès, la gestion des actifs, l’hygiène cyber, la gestion des incidents, la sécurité de la chaîne d’approvisionnement, l’évaluation de l’efficacité et l’authentification multifacteur ou l’authentification continue lorsque cela est approprié. NIS2 Article 23 introduit une notification échelonnée des incidents significatifs, avec une alerte précoce dans les 24 heures, une notification d’incident dans les 72 heures et un rapport final dans un délai d’un mois.

DORA établit des attentes similaires pour les entités financières. Article 5 exige un cadre interne de gouvernance et de contrôle. Article 6 exige un cadre de gestion des risques liés aux TIC. Article 9 couvre la protection et la prévention, notamment les restrictions d’accès et les pratiques de gestion des identités. Articles 10, 11, 17, 18 et 19 relient la détection, la réponse, le rétablissement, la gestion des incidents liés aux TIC, la classification et la notification. DORA étant applicable depuis le 17 janvier 2025, les entités financières doivent considérer Conditional Access comme faisant partie des éléments probants de résilience opérationnelle, et non comme un simple durcissement de l’identité.

GDPR ajoute l’angle de la protection des données. Si Conditional Access protège des systèmes qui traitent des données à caractère personnel, il soutient les principes de responsabilité de Article 5, la responsabilité du responsable du traitement de Article 24, la protection des données dès la conception de Article 25 et la sécurité du traitement de Article 32. Si un accès non autorisé est suspecté, les journaux Conditional Access peuvent devenir des éléments probants pour l’évaluation et la notification d’une violation.

L’erreur consiste à traiter ces demandes comme des sollicitations d’audit distinctes. L’approche mature consiste à établir un modèle unique de gouvernance de Conditional Access pouvant être présenté par référentiel, autorité de régulation, client ou audience du conseil d’administration.

La configuration n’est pas la gouvernance

La plupart des organisations peuvent répondre à la question : « Qu’est-ce qui est configuré ? » Moins nombreuses sont celles qui peuvent répondre aux questions plus difficiles :

• Pourquoi cette politique Conditional Access est-elle configurée ainsi ?
• Quel scénario de risque traite-t-elle ?
• Quelle clause de politique l’exige ?
• Qui a approuvé le changement ?
• Quels utilisateurs, applications et appareils sont exclus ?
• Comment est-elle testée ?
• Quels journaux prouvent qu’elle a fonctionné ?
• À quelle fréquence est-elle revue ?
• Que se passe-t-il lorsqu’elle échoue ?

C’est généralement là que les constats d’audit apparaissent. Les politiques existent, mais elles ne sont pas reliées aux paramètres Microsoft Entra. La conformité des appareils relève de l’exploitation informatique, mais n’est pas cartographiée avec le risque de contrôle d’accès. Les politiques de risque de connexion sont activées sans seuils documentés ni règles d’escalade. Les restrictions de session sont configurées, mais jamais testées depuis des appareils non gérés. Les journaux sont conservés, mais ne sont pas structurés en éléments probants d’audit.

Clarysec traite ce sujet comme un problème de traçabilité. Chaque décision Conditional Access doit relier politique, risque, contrôle, configuration, éléments probants et revue.

La Politique d’utilisation du cloud pour PME indique :

Authentification multifacteur pour les comptes administratifs et les comptes utilisateurs

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.2.

Cette clause constitue le mandat. La règle Conditional Access en est la mise en application. Le journal de connexion en est l’élément probant. L’enregistrement de revue prouve la supervision.

La Politique de sécurité réseau pour PME ajoute l’exigence relative à la posture de sécurité des terminaux :

Les systèmes sans antivirus à jour, sans correctifs à jour ou sans posture de sécurité acceptable du terminal doivent être bloqués ou mis en quarantaine

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.3.

En termes Microsoft Entra, cela peut devenir « exiger un appareil conforme », « bloquer les plateformes non prises en charge », « restreindre les sessions de navigateur non gérées » ou « refuser l’accès à des applications à haut risque depuis des appareils inconnus ». Mais le contrôle n’est complet que lorsque l’organisation peut prouver le périmètre, l’approbation, les tests, les exceptions et la surveillance.

Établir le socle de gouvernance avant l’ensemble de règles

Un programme Conditional Access robuste commence en dehors du portail Entra. Il commence avec le SMSI, le registre des risques, la Politique de contrôle d’accès, la Politique d’utilisation du cloud, la SoA et le modèle d’éléments probants.

Le Zenith Blueprint de Clarysec : feuille de route en 30 étapes pour auditeurs fournit une séquence pratique. Dans la phase de gestion des risques, étape 13, planification du traitement des risques et Déclaration d’applicabilité, il demande aux organisations de relier les contrôles aux risques et aux facteurs réglementaires :

Renvoyer aux réglementations : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez le noter soit dans le registre des risques, dans le cadre de la justification de l’impact du risque, soit dans les notes de la SoA.

Pour Conditional Access, cela change la chaîne probante. Au lieu de dire « Nous avons activé l’authentification multifacteur », l’organisation peut dire :

• Scénario de risque : des identifiants utilisateurs compromis permettent un accès non autorisé aux données clients dans Microsoft 365 et dans les services SaaS financiers.
• Propriétaire du risque : responsable de la sécurité informatique.
• Traitement : Entra Conditional Access exige une authentification multifacteur forte pour les rôles à privilèges, l’authentification multifacteur pour les utilisateurs, le blocage fondé sur le risque de connexion, des appareils conformes pour les applications sensibles et des restrictions de session pour les terminaux non gérés.
• Cartographie ISO/IEC 27002:2022 : 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 et 8.16.
• Cartographie réglementaire : NIS2 Articles 20, 21 et 23, DORA Articles 5, 6, 9, 10, 17 et 18, GDPR Articles 24, 25, 32 et 33.
• Éléments probants : approbation de la politique, export Conditional Access, ticket de changement, résultats de tests, journaux de connexion, rapports de conformité des appareils, registre des exceptions, tickets SOC et comptes rendus de revue de direction.

Le Zenith Blueprint explique également dans la phase des contrôles en action, étape 19, pourquoi la posture de sécurité des terminaux doit faire partie de la décision d’accès :

L’accès à l’information via les terminaux doit être contextuel. Par exemple, l’appareil respecte-t-il les normes de sécurité minimales avant d’accéder aux ressources de l’entreprise ? A-t-il récemment réussi une analyse antimalware ? Se connecte-t-il depuis un emplacement ou un réseau inhabituel ? En s’intégrant aux principes Zero Trust, la posture de sécurité du terminal peut alimenter l’accès conditionnel, en refusant l’entrée tant que l’appareil n’a pas prouvé qu’il est sûr.

C’est le principe central de gouvernance. Conditional Access doit être fondé sur les risques, contextuel et producteur d’éléments probants.

Cartographier les décisions Conditional Access avec les objectifs de contrôle

Un programme mature définit des décisions d’accès standard, puis cartographie chacune d’elles avec l’intention de gouvernance et les éléments probants. Cela évite la prolifération des politiques et simplifie les échanges avec les auditeurs.

La Politique d’utilisation du cloud de l’entreprise soutient l’intégration d’identité centrale :

L’intégration de l’authentification unique (SSO) avec l’IdP de l’organisation est requise afin de garantir la cohérence de l’authentification.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.4.

La Politique de gestion des comptes utilisateurs et des privilèges de l’entreprise rend la surveillance explicite :

L’utilisation de systèmes d’authentification unique (SSO) doit être intégrée avec des fournisseurs d’identité centraux (par exemple, Active Directory (AD), Azure AD) et surveillée afin de détecter les activités de connexion anormales.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.4.

Ensemble, ces clauses exigent davantage que le SSO. Elles exigent une architecture d’identité centrale, une authentification cohérente, la surveillance des anomalies de connexion et des éléments probants attestant que les décisions d’accès sont revues.

Conformité des appareils : le contrôle que les auditeurs peuvent tester

La conformité des appareils est l’un des domaines les plus faciles à surestimer. Un tableau de bord peut afficher 92 % d’appareils conformes, mais un auditeur demandera si la règle s’applique aux applications importantes, si les appareils personnels sont autorisés, si les plateformes non prises en charge sont bloquées et si les exceptions sont approuvées.

La Politique de télétravail de l’entreprise fixe la base d’approbation :

Les appareils BYOD doivent être explicitement approuvés et :

Extrait de la section « Exigences de gouvernance », clause de politique 5.2.2.

Cette phrase courte est importante. Le BYOD n’est pas seulement un état technique. C’est une décision de gouvernance. Dans Conditional Access, elle doit se traduire par des règles de propriété des appareils, des configurations minimales de conformité, des exigences de chiffrement, des vérifications de correctifs et de protection contre les logiciels malveillants, la protection des applications mobiles, le traitement des prestataires et la revue des exceptions.

Le Zenith Controls de Clarysec : guide de conformité croisée cartographie le contrôle ISO/IEC 27002:2022 5.15 Contrôle d’accès comme préventif, protégeant la confidentialité, l’intégrité et la disponibilité dans la capacité opérationnelle de gestion des identités et des accès. Il relie également le contrôle d’accès aux terminaux utilisateurs, car les ordinateurs portables, mobiles et postes fixes non gérés peuvent fragiliser l’application centralisée des accès.

Un pack pratique trimestriel d’éléments probants sur les appareils pour Conditional Access doit comprendre :

• Configuration de conformité des appareils approuvée.
• Politiques Conditional Access exigeant des appareils conformes.
• Applications protégées par ces politiques.
• Export des utilisateurs, groupes, applications et plateformes exclus.
• Rapport de tendance des appareils non conformes.
• Échantillon de journaux de connexion bloquée pour appareils non conformes.
• Registre des exceptions avec propriétaire, motif, date d’expiration et acceptation du risque.
• Enregistrement de revue de direction.

Ce pack d’éléments probants soutient le contrôle opérationnel ISO/IEC 27001:2022, l’hygiène cyber NIS2, la protection et la prévention DORA, ainsi que la responsabilité GDPR.

Risque de connexion : la détection doit devenir un élément probant décisionnel

Conditional Access fondé sur les risques est le point où la détection d’identité devient gouvernance des accès. Microsoft Entra peut évaluer des signaux tels que des propriétés de connexion inhabituelles, des adresses IP anonymes, des déplacements impossibles et des identifiants divulgués. Mais les auditeurs n’accepteront pas « politique de risque activée » comme réponse finale. Ils demanderont pourquoi les seuils ont été sélectionnés, qui revoit les événements risqués et à quel moment une connexion à haut risque devient un incident.

La Politique de journalisation et de surveillance pour PME définit une exigence minimale de journalisation :

Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de l’authentification multifacteur

Extrait de la section « Exigences de gouvernance », clause de politique 5.4.2.

La Politique de journalisation et de surveillance de l’entreprise élargit l’ensemble des événements attendus :

Types d’événements à capturer (par exemple, connexions, échecs d’accès, changements de configuration, commandes administratives, détection de logiciels malveillants)

Extrait de la section « Exigences de gouvernance », clause de politique 5.1.1.

Pour Conditional Access, les éléments probants utiles doivent inclure les connexions réussies, les connexions échouées, le résultat de la politique Conditional Access, la méthode d’authentification multifacteur, le risque de connexion, le risque utilisateur, l’état de conformité de l’appareil, l’application consultée, la localisation, l’application cliente, le résultat du contrôle de session, l’historique des changements de politique et les actions administratives.

Zenith Controls cartographie le contrôle ISO/IEC 27002:2022 8.16 Activités de surveillance comme détectif et correctif, associé aux concepts Detect et Respond. Il relie la surveillance à la journalisation, à l’évaluation des événements, au renseignement sur les menaces, à la surveillance des fournisseurs et à la gestion des incidents. Il cartographie également les activités de surveillance avec GDPR Articles 32 et 33, la surveillance et la notification des incidents NIS2, le suivi des incidents liés aux TIC DORA, la surveillance continue NIST et la surveillance de sécurité COBIT.

Une connexion à haut risque bloquée par Conditional Access n’est donc pas seulement un succès de sécurité. C’est un élément probant montrant que les processus préventifs, détectifs et de réponse sont connectés.

Contrôles de session : le lien entre accès et protection des données

Les décisions prises avant l’accès ne suffisent pas. Une fois l’utilisateur authentifié, les contrôles de session déterminent le niveau d’exposition résiduelle. C’est particulièrement important pour les appareils non gérés, les prestataires, le télétravail, les terminaux partagés, les localisations risquées et les applications traitant des données à caractère personnel.

La Politique relative aux exigences de sécurité des applications pour PME indique :

Gestion des sessions : les données de session doivent expirer après 15 minutes d’inactivité et inclure des avertissements d’expiration lorsque cela est applicable.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.3.

Dans la gouvernance Microsoft Entra, cela peut correspondre à la fréquence de connexion, aux restrictions de sessions persistantes dans le navigateur, à Conditional Access App Control, aux restrictions imposées par l’application, au blocage des téléchargements, à la réauthentification après changement de risque et aux limitations de session fondées sur la sensibilité.

Les contrôles de session soutiennent les contrôles ISO/IEC 27002:2022 8.3 Restriction d’accès aux informations et 8.5 Authentification sécurisée. Ils soutiennent également GDPR Article 32 en réduisant la consultation non autorisée, le téléchargement ou la persistance de l’accès aux données à caractère personnel. Pour DORA, les restrictions de session contribuent à limiter l’exposition dans les systèmes liés aux TIC et soutiennent la détection et la réponse. Pour NIS2, elles constituent des mesures proportionnées de contrôle d’accès et d’hygiène cyber.

Les éléments probants doivent expliquer pourquoi le contrôle de session existe. Par exemple, « bloquer le téléchargement depuis des appareils non gérés pour les applications RH et financières » doit être cartographié avec la fuite de données à caractère personnel, la compromission de terminal et la perte de confidentialité. Les éléments probants doivent inclure la configuration, le périmètre applicatif, les tests de connexion depuis des appareils gérés et non gérés, les journaux montrant les restrictions et les enregistrements d’approbation.

Créer un registre de contrôle Conditional Access

Un registre de contrôle Conditional Access constitue le pont opérationnel entre le registre des risques, la Déclaration d’applicabilité et la configuration Microsoft Entra. Il ne remplace pas ces documents. Il les rend utilisables.

Utilisez un cycle de revue en cinq étapes :

1. Confirmer le périmètre : identifier les applications cloud traitant des données réglementées, financières, opérationnelles ou à caractère personnel.
2. Cartographier les politiques avec les risques : relier chaque politique Conditional Access à au moins un scénario de risque et à un propriétaire du risque.
3. Valider les exclusions : exporter les utilisateurs, rôles, applications, groupes, localisations et appareils exclus. Chaque exclusion doit avoir un propriétaire, un motif, une approbation et une date d’expiration.
4. Tester la mise en application : utiliser des comptes de test pour vérifier l’authentification multifacteur, la conformité des appareils, le blocage fondé sur le risque, le blocage de l’authentification héritée et les restrictions de session.
5. Constituer le dossier d’éléments probants : conserver les exports, captures d’écran, journaux et approbations avec leurs métadonnées.

La Politique d’audit et de surveillance de la conformité pour PME est essentielle pour l’intégrité des éléments probants :

Les métadonnées (par exemple, qui les a collectées, quand et depuis quel système) doivent être documentées.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.3.

Les captures d’écran sans source, date, collecteur ni contexte système constituent des éléments probants faibles. Les exports Conditional Access, les journaux de connexion et les rapports de revue doivent être traités comme des enregistrements d’audit contrôlés.

Cartographie de conformité croisée pour les éléments probants Conditional Access

La valeur de Conditional Access réside dans le fait qu’un même ensemble de contrôles peut satisfaire plusieurs angles d’audit lorsqu’il est correctement gouverné.

Zenith Controls cartographie également 5.15 Contrôle d’accès avec GDPR Article 32, NIS2 Article 21(2)(i), les concepts de gouvernance des accès DORA, les familles de contrôle d’accès NIST SP 800-53 et COBIT 2019 DSS06.04. Il cartographie 8.5 Authentification sécurisée avec GDPR Articles 5, 24, 25 et 32, la gestion des risques de cybersécurité NIS2, la gestion des risques liés aux TIC DORA, l’identification et l’authentification NIST, ainsi que l’identité et l’accès logique COBIT.

La leçon est simple. Les référentiels utilisent des langages différents, mais ils attendent le même schéma d’assurance : les bons utilisateurs, depuis des contextes acceptables, avec une authentification forte, via des sessions gouvernées, avec des journaux prouvant ce qui s’est produit.

Comment les auditeurs examineront Conditional Access

Un auditeur ISO/IEC 27001:2022 commencera par le SMSI. Il demandera si Conditional Access est dans le périmètre, quels risques il traite, comment il apparaît dans la SoA, comment les politiques sont approuvées, comment les changements sont contrôlés et si les éléments probants démontrent l’efficacité opérationnelle. Il faut s’attendre à un échantillonnage des utilisateurs à privilèges, des applications sensibles, des exclusions et des changements récents de politiques.

Un auditeur DORA ou NIS2 se concentrera sur la résilience opérationnelle, la responsabilité de la direction et les risques. Il pourra demander comment les contrôles d’accès protègent les fonctions critiques ou importantes, comment le conseil d’administration supervise le risque lié à l’identité, comment les connexions à haut risque sont triées et si les échecs d’accès alimentent les décisions de classification ou de notification des incidents.

Un auditeur orienté GDPR s’intéressera aux données à caractère personnel. Il pourra demander comment les données RH, financières ou clients sont protégées contre les appareils non gérés, comment les contrôles de session réduisent la consultation non autorisée, comment l’accès est limité aux utilisateurs autorisés et comment les journaux soutiennent l’évaluation des violations.

Un évaluateur COBIT 2019 recherchera des pratiques de gouvernance, une propriété claire, des indicateurs, la répétabilité, la surveillance de la performance et l’amélioration. Un évaluateur orienté NIST comparera les résultats en matière d’identité, d’authentification, d’autorisation, de surveillance et de réponse avec les éléments probants techniques.

La Politique de contrôle d’accès de l’entreprise fixe l’exigence applicable aux accès à privilèges :

L’accès administratif doit être strictement contrôlé au moyen de :

Extrait de la section « Exigences de gouvernance », clause de politique 5.4.1.

Vos éléments probants Microsoft Entra doivent compléter cette phrase de façon opérationnelle. Quels rôles sont à privilèges ? Lesquels exigent une authentification multifacteur résistante au phishing ou forte ? Lesquels sont éligibles via la gestion des identités à privilèges ? Quels comptes sont des comptes administrateur « break glass » ? Lesquels sont exclus des politiques ? Qui les revoit ? Où les alertes sont-elles envoyées ?

Indicateurs pour le conseil d’administration sur la gouvernance de Conditional Access

Parce que NIS2 et DORA mettent l’accent sur la responsabilité de la direction, le reporting Conditional Access doit être lisible par le conseil d’administration. Évitez de ne reporter que des noms de politiques. Reportez le niveau de risque et la performance des contrôles.

Les indicateurs utiles comprennent :

• Pourcentage de comptes à privilèges protégés par une authentification multifacteur forte.
• Nombre d’exclusions Conditional Access par niveau de risque.
• Nombre de connexions à haut risque bloquées, soumises à une exigence supplémentaire ou autorisées.
• Pourcentage des accès aux applications sensibles exigeant des appareils conformes.
• Nombre de sessions depuis des appareils non gérés vers des applications réglementées.
• Délai de triage des événements de connexion à haut risque.
• Nombre de changements de politiques Conditional Access au cours du trimestre.
• Nombre d’exceptions expirées, renouvelées et en retard.
• Couverture de la journalisation de l’authentification, des sessions et des changements de politiques.
• Cas de test échoués lors de la validation trimestrielle de Conditional Access.

Ces indicateurs transforment la configuration d’identité en éléments probants de supervision. Ils aident également les organes de direction à démontrer l’approbation, la revue, l’allocation des ressources et l’amélioration continue.

Constats courants à éliminer avant l’audit

Les constats relatifs à Conditional Access proviennent généralement d’une faiblesse de gouvernance, non d’une défaillance technologique. Les problèmes les plus courants comprennent :

• Les comptes administrateur « break glass » sont exclus, mais non surveillés.
• Les politiques sont nommées de manière incohérente et n’ont pas de propriétaires.
• Des applications sensibles sont absentes des règles de conformité des appareils.
• Les utilisateurs invités et les collaborateurs externes contournent les contrôles standards.
• Les comptes de service et les identités de charge de travail ne sont pas gouvernés séparément.
• Les détections de risque de connexion ne sont pas triées ni reliées aux incidents.
• Les contrôles de session ne sont jamais testés depuis des appareils non gérés.
• Les changements de politiques sont effectués directement en production sans enregistrements de changement.
• Les exclusions sont permanentes, non documentées ou approuvées verbalement.
• Les journaux sont conservés, mais non revus.
• Les éléments probants ne comportent pas de métadonnées, de contexte de source ou de chaîne de conservation.

Un état cible prêt pour 2026 comprend une gouvernance des accès approuvée par la direction, une conception Conditional Access fondée sur les risques, une cartographie explicite ISO/IEC 27001:2022 et ISO/IEC 27002:2022, un soutien documenté à NIS2, DORA et GDPR, une authentification multifacteur forte par rôle et par risque, la conformité des appareils pour les accès sensibles, des restrictions de session pour les contextes non gérés, une authentification et des changements de politiques surveillés, un cycle de vie des exceptions, des tests trimestriels et un reporting de direction.

Transformer Microsoft Entra en éléments probants prêts pour l’audit

Vos politiques Conditional Access prennent déjà des décisions de sécurité à chaque minute. La question est de savoir si ces décisions sont gouvernées, fondées sur les risques, surveillées et cartographiées avec les obligations qui importent à vos auditeurs et régulateurs.

Commencez par Zenith Blueprint Zenith Blueprint, en particulier l’étape 13, afin de relier les politiques Conditional Access aux risques, aux traitements, à la Déclaration d’applicabilité et aux notes réglementaires. Utilisez Zenith Controls Zenith Controls pour cartographier le contrôle d’accès, l’authentification sécurisée, la posture de sécurité des terminaux, la journalisation et la surveillance entre ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST et COBIT 2019.

Alignez ensuite vos exigences internes avec les politiques Clarysec, notamment Politique d’utilisation du cloud pour PME, Politique de sécurité réseau pour PME, Politique de journalisation et de surveillance pour PME, Politique d’audit et de surveillance de la conformité pour PME, Politique relative aux exigences de sécurité des applications pour PME, Politique d’utilisation du cloud, Politique de gestion des comptes utilisateurs et des privilèges, Politique de télétravail, Politique de contrôle d’accès et Politique de journalisation et de surveillance.

Clarysec vous aide à transformer Microsoft Entra Conditional Access d’un ensemble de paramètres en un système de contrôle applicable, mesurable et prêt pour l’audit. Téléchargez les kits d’outils Clarysec pertinents, demandez une revue de cartographie des politiques ou réservez une évaluation pour vérifier si vos éléments probants Conditional Access résistent à l’examen ISO 27001, NIS2, DORA et GDPR.