Cas d'usage · NIS2 · Groupe multinational
NIS2 pour les multinationales : un IAM commun, des obligations par entité
Un groupe international peut partager ses systèmes d'information, ses plateformes d'identité et ses politiques de sécurité sans que toutes ses entités relèvent nécessairement du même cadre réglementaire. La directive NIS2 prévoit des règles communes, mais son application dépend notamment des activités exercées, des établissements et des transpositions nationales. La situation d'une filiale belge ne se confond donc pas automatiquement avec celle de sa maison mère française, même lorsque les deux utilisent une infrastructure IAM commune.
Cette diversité ne justifie pas de reconstruire la gestion des identités dans chaque pays. Un groupe peut harmoniser ses référentiels, ses processus de cycle de vie, ses règles d'habilitation, ses politiques d'authentification et ses mécanismes de traçabilité. La difficulté consiste à définir ce qui doit être commun, ce qui doit rester sous responsabilité locale et comment produire des preuves utilisables par chaque entité concernée.
NIS2 s'applique-t-elle au groupe ou à chaque filiale ?
La première difficulté consiste à identifier les entités concernées. Une filiale n'entre pas automatiquement dans le périmètre de NIS2 parce que sa maison mère y figure, pas plus qu'une société holding n'y entre du seul fait des activités de ses participations. À l'inverse, la taille d'une entité ne peut pas toujours être examinée isolément : les règles européennes relatives aux entreprises liées ou partenaires peuvent intervenir dans l'analyse des seuils.
Une organisation internationale doit donc examiner les activités et la structure de chaque entité, les critères d'assujettissement, les éventuelles exceptions et la compétence des autorités nationales. Une même organisation peut regrouper plusieurs situations réglementaires, y compris des entités essentielles, importantes et non assujetties.
La cartographie juridique peut être réalisée avec les équipes conformité et les conseils compétents. Elle fournit ensuite aux équipes IAM le périmètre réel des identités, applications, processus et responsabilités à gouverner.
Les six dimensions d'une cartographie NIS2 de groupe
- Personne morale
- Identifier les sociétés, établissements et responsabilités
- Activité
- Recenser les services réellement fournis et les secteurs concernés
- Critères d'assujettissement
- Examiner les seuils, exceptions et entreprises liées ou partenaires
- Territorialité
- Identifier les États d'établissement et les situations transfrontalières
- Compétence
- Déterminer la ou les autorités pertinentes selon l'article 26
- Obligations et preuves
- Identifier les textes applicables, échéances, responsables et justificatifs
Cette cartographie est un préalable organisationnel et juridique. Elle ne doit pas être confondue avec un simple inventaire des pays où se trouvent les utilisateurs ou les serveurs.
Quelle autorité NIS2 est compétente pour une multinationale ?
L'article 26 de la directive NIS2 définit plusieurs règles de compétence. Pour les entités relevant du régime général, l'établissement constitue le principal critère de rattachement. Une entité établie dans plusieurs États membres peut relever de plusieurs autorités, qui disposent de mécanismes de coopération et d'assistance mutuelle.
Certaines catégories d'activités suivent des règles particulières. Les opérateurs de réseaux ou services de communications électroniques accessibles au public sont notamment rattachés aux États dans lesquels ils fournissent leurs services. Pour plusieurs catégories de prestataires numériques, dont les fournisseurs cloud, les MSP et les MSSP, la directive retient au contraire un critère d'établissement principal dans l'Union.
Cette distinction est décisive pour les groupes qui mutualisent leur cybersécurité. L'emplacement du siège social, celui de la plateforme IAM et celui du centre de supervision ne suffisent pas toujours à identifier l'autorité compétente. La réponse dépend du type d'entité et des critères propres à son activité.
Régime général
- Principe
- établissement de l'entité.
- Conséquence
- une présence établie dans plusieurs États peut conduire à plusieurs compétences nationales.
Communications électroniques
- Principe
- États où les services concernés sont fournis.
- Conséquence
- plusieurs États peuvent exercer une compétence selon les activités.
Certaines activités numériques
- Principe
- établissement principal dans l'Union selon l'article 26.
- Conséquence
- un régime spécifique de compétence s'applique à l'entité concernée, sans être automatiquement étendu à toutes les sociétés de son groupe.
Établissement principal ne signifie pas simplement siège social
Pour les acteurs numériques visés par l'article 26, l'établissement principal dépend d'abord du lieu où sont principalement prises les décisions relatives aux mesures de gestion des risques cyber. À défaut, il faut examiner le lieu des opérations de cybersécurité, puis l'établissement comptant le plus grand nombre de salariés dans l'Union. Il faut donc examiner l'organisation effective des responsabilités plutôt que se limiter à l'adresse du siège.
Plusieurs pays, des calendriers et des modalités de contrôle différents
La directive fixe un cadre commun, mais les textes nationaux déterminent une partie des conditions de mise en œuvre et de supervision. Au 19 octobre 2026, la Belgique applique déjà sa loi de transposition, tandis que la France poursuit son parcours législatif. Une multinationale présente dans ces deux pays ne peut donc pas appliquer mécaniquement le calendrier belge à ses entités françaises ou considérer que l'absence de transposition complète en France suspend les obligations de ses entités belges.
La même prudence s'impose pour les autres implantations européennes : les textes applicables, les autorités compétentes, les échéances et les régimes sectoriels doivent être vérifiés pour chaque situation. Un calendrier de conformité de groupe doit conserver ces différences, sans empêcher les équipes IAM d'engager des contrôles communs dès lors qu'ils répondent aux risques.
Que faut-il mutualiser dans un IAM multinational ?
La centralisation n'est pas une fin en soi. Une organisation internationale peut avoir plusieurs sources RH, des annuaires distincts, des applications locales et des règles métier qui ne se prêtent pas à une uniformisation complète. Une architecture IAM efficace doit plutôt définir des invariants communs, puis permettre aux entités de conserver les décisions et les exceptions qui relèvent de leurs responsabilités.
Le socle partagé peut porter sur les conventions d'identification, les événements de cycle de vie, les principes de moindre privilège, les exigences d'authentification et la production de preuves. Les entités locales peuvent conserver la responsabilité de certains référentiels, de la validation des accès sensibles, des particularités métier et de la justification des exceptions. Cette articulation doit être explicite pour éviter que la centralisation technique ne crée des responsabilités ambiguës.
Ce partage est un modèle d'architecture et de gouvernance, pas une répartition réglementaire imposée par NIS2. Les responsabilités effectives doivent être définies selon l'organisation, les contrats internes, les ressources exploitées et les textes applicables.
Qui décide, qui exécute et qui répond aux contrôles ?
Un programme IAM international nécessite une gouvernance qui dépasse la seule responsabilité de l'équipe technique centrale. Les entités concernées doivent pouvoir identifier les personnes responsables des accès à leurs ressources, les équipes qui exécutent les opérations et celles qui conservent les preuves. Le groupe peut définir un cadre commun et prendre en charge une partie de l'exploitation, mais les responsabilités des entités ne disparaissent pas du fait de cette mutualisation.
Un modèle de responsabilités explicite permet également d'éviter les décisions contradictoires. Le groupe peut organiser la cohérence de l'architecture, tandis que les métiers et responsables locaux valident les besoins d'accès. Les équipes IAM exécutent ensuite les décisions dans les systèmes concernés et rendent leurs résultats vérifiables.
Exemple de répartition des responsabilités dans un groupe
Cette répartition est illustrative. Elle ne constitue pas un RACI universel imposé par NIS2. Les obligations juridiques et les responsabilités de notification doivent être confirmées pour chaque entité.
Une même opération IAM peut alimenter plusieurs dossiers de contrôle
L'une des principales difficultés d'un programme international n'est pas de produire des documents supplémentaires, mais de rendre vérifiables les opérations réellement effectuées. Une révocation de droits, une approbation d'accès ou une campagne de recertification peut relever d'un processus commun tout en concernant des ressources exploitées par différentes entités. Les preuves doivent alors permettre de comprendre la décision, son exécution, le périmètre concerné et le responsable de la ressource.
Une organisation peut industrialiser cette traçabilité sans fabriquer un système d'audit différent par pays. Les événements IAM peuvent être collectés dans des formats communs, puis rapprochés des entités, applications, propriétaires et contrôles locaux. Cette mutualisation facilite les vérifications tout en laissant aux entités concernées la responsabilité de présenter des preuves adaptées aux exigences qui leur sont applicables.
Exemple : le départ d'un collaborateur disposant d'accès transfrontaliers
Une personne est employée par une entité française, travaille avec une équipe belge et dispose d'autorisations sur des applications administrées au niveau du groupe. Son départ entraîne donc des opérations dans plusieurs systèmes et implique différents propriétaires de ressources.
- La source RH autorisée signale le départ.
- L'IAM identifie les comptes et habilitations associés.
- Les règles de révocation et les validations nécessaires sont appliquées.
- Les connecteurs exécutent les opérations dans les applications concernées.
- Les erreurs et exceptions sont détectées et traitées.
- Les événements et décisions sont conservés avec leur périmètre et leurs responsables.
Analyse Ariovis
L'organisation gagne à industrialiser ce processus plutôt qu'à demander à chaque filiale de traiter manuellement les mêmes événements. La preuve doit toutefois pouvoir être retrouvée pour une entité, une application et une période données. Un journal centralisé qui ne permet pas de rattacher les opérations à leurs responsables et à leurs ressources reste difficilement exploitable lors d'un contrôle.
Cet exemple est un scénario pédagogique fictif.
Trois situations qui changent la conception du programme IAM
Situation 1
Groupe industriel et autonomie nationale
Un groupe industriel dispose d'une gouvernance informatique centrale, mais ses filiales conservent des sources RH, des applications et des circuits de validation distincts. Chercher à imposer immédiatement une plateforme unique peut rendre le projet plus complexe que nécessaire. Le premier travail consiste à identifier les événements d'identité et les contrôles communs, puis à définir les modalités d'intégration de chaque pays sans supprimer les responsabilités locales.
La trajectoire IAM peut alors reposer sur des règles communes, des interfaces standardisées et une orchestration progressive. Le groupe obtient une meilleure visibilité sans exiger que toutes les entités fonctionnent de manière identique.
Situation 2
Déploiement d'une gouvernance des identités dans deux pays
Une organisation étend son dispositif IGA d'une première implantation européenne vers une seconde, où les populations, les applications et les règles de validation diffèrent. Le système existant constitue une base réutilisable, mais les rôles et les responsabilités doivent être adaptés. Une duplication purement technique du premier déploiement risquerait de masquer les particularités de la nouvelle entité.
Le travail d'architecture consiste à conserver un modèle cohérent tout en définissant les exceptions, les droits sensibles et les contrôles nécessaires dans chaque contexte. L'IGA devient alors un support de gouvernance commune plutôt qu'un catalogue de règles copiées d'un pays à l'autre.
Situation 3
Prestataire numérique exerçant dans plusieurs États
Un fournisseur de services numériques intervient dans plusieurs États membres et centralise une partie de ses décisions de cybersécurité. Avant de définir son organisation réglementaire, il doit déterminer si ses activités relèvent du régime particulier de l'article 26 relatif à l'établissement principal dans l'Union. La localisation des clients, des serveurs ou du siège ne suffit pas nécessairement à elle seule pour trancher cette question.
L'IAM peut être mutualisé à travers ses activités, mais la détermination de l'autorité compétente et des obligations applicables nécessite une qualification juridique distincte.
Ces trois situations sont des scénarios pédagogiques illustratifs.
Comment construire une trajectoire IAM commune et exploitable ?
Une feuille de route IAM internationale ne commence pas nécessairement par le choix d'une plateforme globale. Elle commence par la compréhension des entités, des populations, des processus existants et des risques. Les différences réglementaires sont ensuite intégrées dans une gouvernance permettant de distinguer les décisions communes des adaptations locales.
La trajectoire doit être progressive. Une organisation peut d'abord fiabiliser ses sources, sécuriser les droits les plus sensibles et industrialiser quelques processus prioritaires, avant d'étendre le dispositif à de nouvelles filiales ou applications.
Phase 1
Qualifier les responsabilités et les périmètres
Identifier les entités concernées, les référentiels applicables, les processus IAM existants, les parties prenantes et les principales dépendances.
Livrables possibles : cartographie, matrice de responsabilités et périmètre IAM prioritaire.
Phase 2
Définir les invariants IAM du groupe
Formaliser le modèle d'identité, les principes d'habilitation, les politiques d'accès, le cycle de vie et les règles de production des preuves.
Livrables possibles : principes directeurs, architecture fonctionnelle, modèle de gouvernance et backlog.
Phase 3
Industrialiser un premier périmètre
Raccorder les sources et applications prioritaires, fiabiliser le cycle de vie, organiser les validations et contrôler les privilèges sensibles.
Livrables possibles : processus opérationnels, configurations, connecteurs, tests et documentation.
Phase 4
Étendre, auditer et exploiter
Étendre le dispositif par entité ou application, organiser les revues, exploiter les preuves et intégrer les évolutions au fonctionnement récurrent.
Livrables possibles : campagnes de contrôle, reporting, procédures RUN et feuille de route d'amélioration continue.
Réutiliser les contrôles sans confondre les référentiels
La directive NIS2 prévoit notamment des exigences relatives aux politiques de contrôle d'accès, à la sécurité des ressources humaines et à l'authentification. Les transpositions et référentiels nationaux peuvent traduire ces objectifs en contrôles et modalités d'évaluation spécifiques. Il est donc possible de réutiliser une partie des mécanismes IAM entre plusieurs entités, sans supposer que les références ou les preuves attendues sont juridiquement identiques.
Un référentiel d'identités fiable, une politique MFA appliquée, un processus de révocation ou une campagne de recertification constituent des mécanismes opérationnels qui peuvent alimenter plusieurs démarches de contrôle. La correspondance entre ces mécanismes et les textes applicables doit néanmoins être documentée et validée selon chaque cadre réglementaire.
Un même contrôle IAM, plusieurs cadres de référence
Une organisation internationale peut être amenée à documenter ses mécanismes d'identité et d'accès au regard de plusieurs référentiels. Le ReCyF français, CyberFundamentals en Belgique et ISO 27001 abordent certains risques similaires, mais avec des formulations, des périmètres et des modes de vérification différents. Leur rapprochement doit donc partir du contrôle opérationnel réellement mis en œuvre, avant d'examiner les exigences auxquelles il peut contribuer.
Cette matrice relie six chantiers IAM à des références vérifiées, à des mécanismes techniques et à des preuves exploitables. Elle constitue une aide à la conception et à la préparation des contrôles, sans prétendre établir des équivalences réglementaires ou certifier la conformité d'une organisation.
La directive NIS2, notamment son article 21, paragraphe 2, prévoit des mesures relatives aux politiques de contrôle d'accès, à la sécurité des ressources humaines, à la gestion des actifs, à la cryptographie et, lorsque c'est approprié, à l'authentification multifacteur ou continue.
Référence éditoriale : 19 octobre 2026 · Rapprochements thématiques et contributions opérationnelles
Identités et cycle de vieReCyF v2.510.A.1, 10.A.2, 10.A.5, 10.A.6CyFun 2025 · BasicPR.AA-01.1ISO 27001:2022A.5.16, A.5.18
Identifier les utilisateurs, les services et leurs comptes
- Problème traité
- Une personne quitte l'organisation, change de poste ou perd la responsabilité d'un service, mais les comptes et droits qui lui étaient associés demeurent actifs. À l'inverse, certains comptes techniques existent sans propriétaire ou usage clairement identifié.
- Effet recherché
- Relier chaque compte à une identité ou à un processus autorisé, puis maîtriser son cycle de vie jusqu'à sa désactivation.
ReCyF — version de travail 2.5
10.A.1-EI/EE
Comptes individuels pour les utilisateurs et les processus automatiques.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.A.2-EI/EE
Utilisation des comptes individuels réservée à leur titulaire.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.A.5-EI/EE
Désactivation des comptes devenus inutiles dans les délais définis par la politique de gestion des comptes.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.A.6-EI/EE
Revue des comptes au moins annuelle, avec correction des anomalies.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-01.1 — Basic
Gestion des identités et informations d'authentification des utilisateurs, services et équipements autorisés.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.16
Gestion des identités.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.5.18
Droits d'accès, notamment leur gestion et leur révision.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022
Les contrôles de l'annexe A doivent être examinés selon l'évaluation des risques, le périmètre du SMSI et la déclaration d'applicabilité (SoA).
Références européennes — article 21(2)
Directive NIS2
Article 21(2)(h)
cryptographie et, le cas échéant, chiffrement.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(i)
sécurité des ressources humaines, contrôle d'accès et gestion des actifs.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(j)
MFA ou authentification continue lorsque cela est approprié.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555
Analyse Ariovis
La gouvernance commence par la capacité à distinguer une personne, une identité, un compte et une habilitation. Un système IAM peut rapprocher ces objets à partir de sources de référence et orchestrer les événements d'arrivée, de mobilité et de départ. Il doit aussi traiter les comptes techniques, dont la légitimité dépend d'un usage et d'un propriétaire, même lorsqu'aucune personne ne les utilise directement.
L'automatisation n'a de valeur que si les événements sont fiables et si les systèmes cibles exécutent réellement les décisions. Une source RH erronée ou un compte sans correspondance peut sinon produire une fausse impression de maîtrise.
Mécanismes IAM
- Référentiel d'identités.
- Corrélation identité / compte.
- Sources RH ou autres sources autoritatives.
- Processus Joiner / Mover / Leaver.
- Provisioning.
- Déprovisioning.
- Reconciliation et contrôle des écarts.
Preuves possibles
- Inventaire des comptes actifs.
- Rattachement à une identité ou à un processus.
- Propriétaire des comptes techniques.
- Historique des créations et désactivations.
- Traces des événements de départ.
- Liste des écarts non résolus.
- Résultats des revues de comptes.
- Responsabilités types
- Référentiel RH, responsable IAM, propriétaires des comptes ou applications, exploitation.
- Indicateur possible
- Part des comptes actifs dont le propriétaire ou l'identité de rattachement est identifié.
Nature et limites des rapprochements
objectif proche de gestion des identités, mais sans identité démontrée des modalités de cycle de vie ou de périodicité.
Correspondance thématique, selon l'applicabilité définie dans le SMSI.
L'automatisation n'a de valeur que si les événements sont fiables et si les systèmes cibles exécutent réellement les décisions. Une source RH erronée ou un compte sans correspondance peut sinon produire une fausse impression de maîtrise.
Approfondissement technique dans le contexte du ReCyF français.
Authentification et secretsReCyF v2.510.B.1 à 10.B.6 ; 10.B.7-EE pour l'exceptionCyFun 2025 · BasicPR.AA-03.2ISO 27001:2022A.5.17, A.8.5
Authentifier avec des mécanismes adaptés au risque
- Problème traité
- Une organisation possède une politique d'authentification, mais ne sait pas précisément quels accès sont protégés, comment les exceptions sont gérées ou à quel moment les secrets doivent être remplacés.
- Effet recherché
- Maîtriser les mécanismes d'authentification, leur couverture, la gestion des secrets et les exceptions documentées.
ReCyF — version de travail 2.5
10.B.1-EI/EE
Mécanisme d'authentification utilisant au moins un élément secret.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.2-EI/EE
Modification des secrets configurés par défaut avant mise en service.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Le texte prévoit aussi de s'assurer auprès du fournisseur des moyens et droits nécessaires au changement.
Version de travail 2.5 du 17 mars 202610.B.3-EI/EE
Renouvellement de l'élément secret d'un compte partagé lorsqu'un utilisateur de ce compte est retiré.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.4-EI/EE
Connaissance des éléments secrets réservée aux utilisateurs autorisés.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.5-EI/EE
Respect des recommandations applicables aux facteurs d'authentification et à leur gestion.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Le texte vise la complexité et la fréquence de renouvellement selon les recommandations ANSSI, compte tenu du maximum techniquement permis.
Version de travail 2.5 du 17 mars 202610.B.6-EI/EE
Mesures de réduction du risque lorsqu'un élément secret ne peut pas être modifié pour des raisons techniques ou opérationnelles.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Cette exception exige un contrôle d'accès approprié et une réduction du risque lié au secret fixe ; la traçabilité supplémentaire relève de 10.B.7-EE.
Version de travail 2.5 du 17 mars 202610.B.7-EE
Traçabilité supplémentaire dans le cadre de l'exception prévue au contrôle précédent, pour les entités essentielles.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-03.2 — Basic
MFA requis pour accéder à distance aux réseaux de l'organisation.
Rapprochement thématique · Vérification documentaire à confirmer
Portée du brief à confirmer dans le livret Basic : l'annexe Key Measures indexée emploie une formulation différente pour 2025. Le livret détaillé n'a pas pu être lu (HTTP 403).
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.17
Informations d'authentification.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.8.5
Authentification sécurisée.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022
Les contrôles de l'annexe A doivent être examinés selon l'évaluation des risques, le périmètre du SMSI et la déclaration d'applicabilité (SoA).
Références européennes — article 21(2)
Directive NIS2
Article 21(2)(h)
cryptographie et, le cas échéant, chiffrement.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(i)
sécurité des ressources humaines, contrôle d'accès et gestion des actifs.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(j)
MFA ou authentification continue lorsque cela est approprié.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555
Analyse Ariovis
Une politique d'authentification ne se mesure pas uniquement à l'existence d'un MFA. Elle doit permettre de comprendre quels parcours sont protégés, quels mécanismes sont utilisés, comment les exceptions sont autorisées et comment les informations d'authentification sont administrées. Les secrets techniques et les accès partagés nécessitent également un traitement adapté à leurs usages réels.
L'IGA gouverne les identités et les droits associés, tandis que l'Access Management applique les politiques d'authentification. Les solutions de gestion des secrets et de PAM interviennent lorsque les comptes et les opérations concernés nécessitent des contrôles supplémentaires.
Mécanismes IAM
- IdP et Access Management.
- MFA.
- Fédération.
- Politiques d'authentification.
- Gestion des exceptions.
- Coffres de secrets.
- Rotation des secrets selon les besoins et règles applicables.
- Journalisation des modifications sensibles.
Preuves possibles
- Inventaire des parcours d'authentification.
- Politiques MFA appliquées.
- Couverture des accès distants concernés.
- Exceptions autorisées et justifiées.
- Historique des changements de politique.
- Traces de rotation des secrets concernés.
- Responsabilités types
- Responsable Access Management, sécurité, responsables applicatifs et exploitation des secrets.
- Indicateur possible
- Part des parcours d'accès distants identifiés qui sont effectivement couverts par le MFA prévu.
Nature et limites des rapprochements
cette mesure ne doit pas être présentée comme imposant textuellement le MFA à toutes les applications, pour toutes les connexions et sans distinction de contexte.
Approfondissement technique dans le contexte du ReCyF français.
Droits et recertificationReCyF v2.510.C.1 à 10.C.4CyFun 2025 · BasicPR.AA-05.1 à PR.AA-05.3ISO 27001:2022A.5.15, A.5.18, A.8.3, A.5.3 selon le cas
Attribuer, revoir et retirer les droits légitimes
- Problème traité
- Les droits s'accumulent à mesure que les collaborateurs changent de fonction. Les propriétaires des applications ne disposent pas toujours d'une vision claire des permissions attribuées et les campagnes de revue peuvent rester sans correction effective.
- Effet recherché
- Maintenir les habilitations au niveau du besoin réel, documenter les décisions et contrôler leur application.
ReCyF — version de travail 2.5
10.C.1-EI/EE
Droits attribués aux utilisateurs et processus automatiques authentifiés.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.C.2-EI/EE
Limitation des droits aux ressources nécessaires.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.C.3-EI/EE
Attribution des droits aux seuls utilisateurs et processus justifiant un besoin sur la ressource.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.C.4-EI/EE
Revue des droits au moins annuelle, avec correction des anomalies.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-05.1 — Basic
Définir, gérer, appliquer et revoir les permissions, droits d'accès et autorisations.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025PR.AA-05.2 — Basic
Déterminer les personnes qui ont besoin d'accéder aux informations et technologies critiques.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025PR.AA-05.3 — Basic
Limiter les droits et privilèges aux besoins nécessaires à la réalisation des tâches.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.15
Contrôle d'accès.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.5.18
Droits d'accès.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.8.3
Restriction de l'accès aux informations.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.5.3
Séparation des tâches, lorsque pertinente pour le contrôle étudié.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022
Les contrôles de l'annexe A doivent être examinés selon l'évaluation des risques, le périmètre du SMSI et la déclaration d'applicabilité (SoA).
Références européennes — article 21(2)
Directive NIS2
Article 21(2)(h)
cryptographie et, le cas échéant, chiffrement.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(i)
sécurité des ressources humaines, contrôle d'accès et gestion des actifs.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(j)
MFA ou authentification continue lorsque cela est approprié.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555
Analyse Ariovis
La gouvernance des habilitations exige de relier une décision métier à un droit effectivement présent dans le système. Une demande approuvée, une règle de rôle ou une campagne de recertification ne suffit pas si les autorisations techniques ne sont pas alignées avec le résultat attendu. Le contrôle doit couvrir la légitimité du droit, son attribution, ses éventuelles exceptions et son retrait.
Les modèles de rôles permettent d'industrialiser une partie des décisions. Ils doivent néanmoins rester adaptés à l'organisation et peuvent être complétés par des mécanismes d'autorisation fine lorsque les décisions dépendent de la ressource, de l'action ou du contexte.
Mécanismes IAM
- Catalogue d'habilitations.
- Propriétaires des ressources.
- Rôles métier et techniques.
- Règles d'attribution.
- Demandes et validations.
- Campagnes de recertification.
- Gestion des exceptions.
- Révocation.
- Contrôles d'écart entre droits théoriques et effectifs.
Preuves possibles
- Matrice des droits.
- Validation des propriétaires.
- Historique des demandes.
- Décisions de recertification.
- Liste des exceptions.
- Corrections effectuées.
- Journal des révocations.
- Responsabilités types
- Propriétaires métier, responsables applicatifs, responsables IAM et exploitation des droits.
- Indicateur possible
- Part des décisions de révocation effectivement exécutées et vérifiées dans les systèmes cibles.
Nature et limites des rapprochements
La gouvernance des habilitations exige de relier une décision métier à un droit effectivement présent dans le système. Une demande approuvée, une règle de rôle ou une campagne de recertification ne suffit pas si les autorisations techniques ne sont pas alignées avec le résultat attendu. Le contrôle doit couvrir la légitimité du droit, son attribution, ses éventuelles exceptions et son retrait.
Approfondissement technique dans le contexte du ReCyF français.
Comptes partagésReCyF v2.510.A.2, 10.A.3, 10.B.3, 10.B.4, 10.B.6, 10.B.7-EECyFun 2025 · BasicPR.AA-01.1, PR.PS-04.1 — liens indirectsISO 27001:2022A.5.16, A.5.17, A.8.15
Encadrer les comptes partagés et préserver l'imputabilité
- Problème traité
- Certains systèmes historiques ou contraintes opérationnelles conduisent à l'utilisation de comptes partagés. Sans dispositif adapté, il devient difficile de savoir quelle personne a utilisé le compte, à quel moment et pour quelle opération.
- Effet recherché
- Limiter les usages partagés, justifier les exceptions et conserver une attribution exploitable des accès concernés.
ReCyF — version de travail 2.5
10.A.2-EI/EE
Utilisation des comptes individuels réservée à leur titulaire.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.A.3-EI/EE
Mesures compensatoires et traçabilité lorsque des contraintes empêchent le recours à des comptes individuels.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.3-EI/EE
Renouvellement de l'élément secret d'un compte partagé après retrait d'un utilisateur de ce compte.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.4-EI/EE
Protection de la connaissance des secrets.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.6-EI/EE
Exception relative aux secrets qui ne peuvent pas être modifiés, avec exigence supplémentaire de traçabilité pour les EE dans le cas prévu.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Cette exception exige un contrôle d'accès approprié et une réduction du risque lié au secret fixe ; la traçabilité supplémentaire relève de 10.B.7-EE.
Version de travail 2.5 du 17 mars 202610.B.7-EE
Exception relative aux secrets qui ne peuvent pas être modifiés, avec exigence supplémentaire de traçabilité pour les EE dans le cas prévu.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-01.1 — Basic
Gestion des identités et informations d'authentification.
Rapprochement thématique indirect · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025PR.PS-04.1 — Basic
Maintien, documentation et suivi des journaux.
Rapprochement thématique indirect · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.16
Gestion des identités.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.5.17
Informations d'authentification.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.8.15
Journalisation.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022
Les contrôles de l'annexe A doivent être examinés selon l'évaluation des risques, le périmètre du SMSI et la déclaration d'applicabilité (SoA).
Références européennes — article 21(2)
Directive NIS2
Article 21(2)(h)
cryptographie et, le cas échéant, chiffrement.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(i)
sécurité des ressources humaines, contrôle d'accès et gestion des actifs.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(j)
MFA ou authentification continue lorsque cela est approprié.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555
Analyse Ariovis
La traçabilité d'un compte partagé ne se résume pas à la conservation de ses journaux techniques. Elle suppose de pouvoir comprendre les conditions dans lesquelles le compte a été utilisé et de rattacher son usage à une personne ou à une opération autorisée. Lorsque les comptes individuels ne sont pas possibles, il faut donc documenter l'exception, définir les mesures compensatoires et vérifier qu'elles restent opérationnelles.
La gestion des secrets, le contrôle des sessions et les procédures d'exploitation peuvent contribuer à cette maîtrise. Aucun de ces mécanismes ne doit être présenté comme une autorisation générale de partager des comptes sans justification.
Mécanismes IAM
- Inventaire des comptes partagés.
- Justification des exceptions.
- Désignation des responsables.
- Gestion des secrets.
- Rotation à la révocation d'un utilisateur concerné.
- Contrôle d'accès.
- Traçabilité des usages.
- Révision des exceptions.
Preuves possibles
- Registre des comptes partagés.
- Justification technique ou opérationnelle.
- Liste des utilisateurs autorisés.
- Traces de rotation.
- Journaux pertinents.
- Résultats des contrôles périodiques.
- Décisions de maintien ou de suppression des exceptions.
- Responsabilités types
- Propriétaire du système, responsable sécurité, responsable PAM ou secrets, exploitation.
- Indicateur possible
- Part des comptes partagés identifiés disposant d'une exception justifiée et d'un dispositif de traçabilité documenté.
Nature et limites des rapprochements
Ces mesures constituent des points d'appui thématiques. Elles ne doivent pas être présentées comme une transposition textuelle des exceptions aux comptes partagés prévues par le ReCyF.
Correspondances thématiques, à apprécier selon le périmètre et les contrôles retenus.
Approfondissement technique dans le contexte du ReCyF français.
Annuaires et privilègesReCyF v2.511.A.1, 11.A.3, 11.A.4-EE, 11.B.1, 11.B.2-EE, 11.B.6-EECyFun 2025 · BasicPR.AA-05.1, PR.AA-05.4, ID.AM-08.2ISO 27001:2022A.8.2, A.8.9, A.8.15
Sécuriser les annuaires et les chemins d'administration
- Problème traité
- Une organisation dispose d'une gouvernance IAM, mais certains groupes, délégations, comptes administratifs et mécanismes hérités dans ses annuaires permettent encore des accès excessifs ou des escalades de privilèges.
- Effet recherché
- Articuler la gouvernance IAM avec la sécurité technique des annuaires et la maîtrise des droits d'administration.
ReCyF — version de travail 2.5
11.A.1-EI/EE
Séparation des comptes d'administration et de leur usage.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
L'administration se fait exclusivement via des comptes d'administration, eux-mêmes réservés exclusivement à ces actions.
Version de travail 2.5 du 17 mars 202611.A.3-EI/EE
Application des règles de gestion des identités aux comptes d'administration.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Les règles concernent les identités et les accès des comptes d'administration.
Version de travail 2.5 du 17 mars 202611.A.4-EE
Usage des comptes d'administration limité aux ressources et opérations d'administration prévues.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Connexion aux ressources administrées pour les administrer, ou à une ressource d'administration.
Version de travail 2.5 du 17 mars 202611.B.1-EI/EE
Application des correctifs de sécurité sur les annuaires concernés.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Les correctifs doivent être appliqués sans retard injustifié.
Version de travail 2.5 du 17 mars 202611.B.2-EE
Identification des ressources constituant le cœur de confiance de chaque annuaire.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
Le cœur de confiance comprend l'annuaire et les ressources permettant de l'héberger ou d'en prendre le contrôle.
Version de travail 2.5 du 17 mars 202611.B.6-EE
Revue annuelle de la configuration des annuaires.
Rapprochement thématique · Identifiant et applicabilité vérifiés dans le document officiel
La revue vise les éléments inutiles ou anormaux ; un outil automatisé est recommandé, non imposé par cette ligne.
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-05.1 — Basic
Gestion et revue des droits.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025PR.AA-05.4 — Basic
Absence de privilèges administratifs pour les tâches courantes.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025ID.AM-08.2 — Basic
Installation des correctifs et mises à jour de sécurité sur les systèmes et composants critiques concernés.
Rapprochement thématique · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.8.2
Droits d'accès privilégiés.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.8.9
Gestion des configurations.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.8.15
Journalisation.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022
Les contrôles de l'annexe A doivent être examinés selon l'évaluation des risques, le périmètre du SMSI et la déclaration d'applicabilité (SoA).
Références européennes — article 21(2)
Directive NIS2
Article 21(2)(h)
cryptographie et, le cas échéant, chiffrement.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(i)
sécurité des ressources humaines, contrôle d'accès et gestion des actifs.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(j)
MFA ou authentification continue lorsque cela est approprié.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555
Analyse Ariovis
La sécurité des annuaires ne découle pas automatiquement de la gouvernance des habilitations. L'IGA peut contrôler l'attribution de groupes et de droits, mais la protection d'Active Directory ou de LDAP nécessite aussi une analyse des délégations, des comptes sensibles, des configurations et des chemins permettant d'atteindre les ressources critiques. Les corrections doivent être priorisées selon les risques plutôt que limitées à un inventaire de comptes administratifs.
Le PAM intervient sur certains usages privilégiés, mais la réduction des privilèges permanents et la sécurisation du cœur de confiance exigent également des décisions d'architecture, de configuration et d'exploitation. Un bastion ne suffit pas à supprimer les chemins d'attaque présents dans l'annuaire.
Mécanismes IAM
- Revue des comptes administratifs.
- Analyse des groupes sensibles.
- Séparation des usages administratifs.
- Analyse des délégations.
- Réduction des privilèges.
- Contrôle des chemins d'attaque.
- Revue de configuration des annuaires.
- Gestion des correctifs.
- Journalisation des changements critiques.
Preuves possibles
- Inventaire des comptes et groupes privilégiés.
- Justification des droits sensibles.
- Cartographie des chemins d'attaque.
- Historique des remédiations.
- Rapports de revue de configuration.
- Suivi des correctifs.
- Journaux de changements privilégiés.
- Responsabilités types
- Équipe annuaire, architecte IAM, sécurité des identités, responsable PAM et exploitation.
- Indicateur possible
- Nombre de chemins d'attaque critiques identifiés puis supprimés ou maîtrisés selon un périmètre documenté.
Nature et limites des rapprochements
Ces références ne constituent pas une description exhaustive du durcissement d'Active Directory ni une équivalence aux exigences françaises sur le cœur de confiance.
Approfondissement technique dans le contexte du ReCyF français.
Identités machines et certificatsReCyF v2.510.A.1, 10.A.5, 10.B.1, 10.B.2CyFun 2025 · BasicPR.AA-01.1ISO 27001:2022A.5.16, A.8.24
Gouverner les identités machines et leurs mécanismes de confiance
- Problème traité
- Une organisation connaît les comptes de ses collaborateurs, mais maîtrise insuffisamment les identités des applications, équipements et processus automatiques. Certains certificats, secrets ou comptes techniques persistent sans propriétaire identifié ni cycle de vie documenté.
- Effet recherché
- Relier les identités techniques à leurs usages et contrôler les moyens cryptographiques associés lorsque ceux-ci sont utilisés.
ReCyF — version de travail 2.5
10.A.1-EI/EE
Identification individuelle des utilisateurs et processus automatiques accédant aux ressources.
Contribution opérationnelle · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.A.5-EI/EE
Désactivation des comptes devenus inutiles.
Contribution opérationnelle · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.1-EI/EE
Mécanismes d'authentification des utilisateurs et processus automatiques.
Contribution opérationnelle · Identifiant et applicabilité vérifiés dans le document officiel
Version de travail 2.5 du 17 mars 202610.B.2-EI/EE
Changement des éléments secrets configurés par défaut.
Contribution opérationnelle · Identifiant et applicabilité vérifiés dans le document officiel
Le texte prévoit aussi de s'assurer auprès du fournisseur des moyens et droits nécessaires au changement.
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-01.1 — Basic
Gestion des identités et informations d'authentification des utilisateurs, services et équipements.
Contribution opérationnelle · Vérification documentaire à confirmer
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.16
Gestion des identités.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022A.8.24
Utilisation de la cryptographie.
Rapprochement thématique · Vérification documentaire à confirmer
ISO/IEC 27001:2022
Les contrôles de l'annexe A doivent être examinés selon l'évaluation des risques, le périmètre du SMSI et la déclaration d'applicabilité (SoA).
Références européennes — article 21(2)
Directive NIS2
Article 21(2)(h)
cryptographie et, le cas échéant, chiffrement.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(i)
sécurité des ressources humaines, contrôle d'accès et gestion des actifs.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555Article 21(2)(j)
MFA ou authentification continue lorsque cela est approprié.
Contribution opérationnelle · Vérification documentaire à confirmer
Directive (UE) 2022/2555
Analyse Ariovis
Une identité machine ne se résume pas à un compte de service. Elle peut être portée par un certificat, une clé, un jeton, un compte applicatif ou plusieurs mécanismes combinés. L'organisation doit distinguer la légitimité de cette identité, les ressources qu'elle peut atteindre et les moyens techniques permettant de l'authentifier.
L'IAM peut gouverner les propriétaires, les usages et les habilitations de ces identités. La PKI assure la gestion des certificats et des mécanismes cryptographiques correspondants. La maîtrise du risque exige une articulation entre ces responsabilités, notamment lorsqu'une application est abandonnée, qu'un certificat expire ou qu'un secret doit être révoqué.
Mécanismes IAM
- Inventaire des identités machines.
- Identification des propriétaires.
- Gestion des comptes de service.
- Cycle de vie des identités techniques.
- Inventaire des certificats concernés.
- Attribution et retrait des droits.
- Émission, renouvellement et révocation des certificats par les dispositifs appropriés.
- Contrôle des secrets et clés associés.
Preuves possibles
- Inventaire des identités non humaines.
- Propriétaire et usage documentés.
- Références des comptes ou certificats associés.
- Dates de validité et renouvellement.
- Historique des révocations.
- Résultats des revues de droits.
- Traitement des identités devenues inutiles.
- Responsabilités types
- Responsables applicatifs, équipe IAM, équipe PKI, exploitation et sécurité.
- Indicateur possible
- Part des identités techniques critiques disposant d'un propriétaire et d'un mécanisme de renouvellement ou de révocation documenté.
Nature et limites des rapprochements
Aucune des références citées ne doit être présentée comme imposant systématiquement le déploiement d'une PKI complète pour l'ensemble des organisations.
Les certificats constituent un mécanisme technique possible pour certains usages. Leur gestion dépend des besoins d'authentification, de confiance et de cryptographie concernés.
Approfondissement technique dans le contexte du ReCyF français.
De la mesure de sécurité à la preuve de son fonctionnement
Une politique écrite décrit ce qui devrait être fait. Une preuve opérationnelle permet de vérifier ce qui a effectivement été décidé, exécuté et contrôlé. Pour un dispositif IAM, cette distinction est essentielle : la création d'un workflow de révocation ne démontre pas que toutes les révocations attendues ont été réalisées, pas plus qu'une campagne de recertification lancée ne démontre que les corrections décidées ont été appliquées.
Les organisations gagnent à structurer leurs preuves autour de quelques informations communes : le périmètre concerné, la règle appliquée, le responsable de la décision, l'opération effectuée et son résultat. Cette méthode peut alimenter plusieurs démarches de contrôle, sous réserve d'adapter le dossier aux exigences et modalités d'évaluation réellement applicables.
Anatomie d’une preuve IAM
- Périmètre
- Entité, application, population, ressource ou ensemble de comptes concernés.
- Décision
- Règle applicable, demande, approbation ou événement déclencheur.
- Exécution
- Opération réalisée dans le système cible, avec son état et sa date.
- Exception
- Écart rencontré, justification, responsable et correction prévue.
- Vérification
- Résultat du contrôle, traces conservées et capacité à reconstituer l'opération.
Une preuve techniquement disponible n'est pas automatiquement suffisante pour un audit, une vérification CyFun ou une certification ISO 27001. Sa pertinence dépend du périmètre, des exigences applicables et de la méthode d'évaluation.
Une stratégie IAM de groupe qui respecte les réalités locales
Ariovis accompagne les organisations internationales dans la définition d'une gouvernance des identités adaptée à leurs processus et à leur architecture. Cette intervention peut commencer par un diagnostic des sources, des habilitations et des responsabilités, puis se poursuivre par la construction d'un schéma directeur, l'intégration de solutions et la mise en place de contrôles opérationnels. L'objectif est de produire une trajectoire réaliste qui améliore la sécurité sans imposer aux filiales des transformations inutiles.
L'accompagnement peut associer les équipes centrales et locales, depuis la définition des principes IAM jusqu'aux raccordements applicatifs, aux revues d'accès et à l'exploitation. Les exigences réglementaires alimentent le cadrage, mais les décisions techniques restent guidées par les risques, les usages et les capacités réelles de l'organisation.
Stratégie IAM et Zero Trust
Construire un schéma directeur, un modèle de gouvernance et une trajectoire d'intégration progressive.
Gouvernance des identités
Harmoniser les cycles de vie, les habilitations, les règles de validation et la traçabilité.
Access Management et CIAM
Sécuriser la fédération, l'authentification et les politiques d'accès dans des systèmes hétérogènes.
PAM
Réduire et contrôler les privilèges et les opérations sensibles, en tenant compte des usages réels.
Sources officielles
Cette analyse repose sur la directive européenne NIS2 et sur les explications publiées par les autorités compétentes. Elle distingue les principes européens, les particularités nationales et les recommandations d'organisation IAM. Les règles de compétence et d'assujettissement nécessitent une vérification adaptée à chaque entité.
- Directive NIS2
- Article 2 — Champ d'application.
- Article 3 — Entités essentielles et importantes.
- Article 4 — Articulation avec les actes sectoriels.
- Article 21 — Mesures de gestion des risques.
- Article 23 — Notification des incidents.
- Article 26 — Compétence et territorialité.
- Article 27 — Registre de certaines entités.
- ANSSI, FAQ NIS2 multinationale
Cette source distingue notamment la notion d'entité, les différentes catégories de compétence et la situation des groupes.
La FAQ est informative et ne remplace pas les textes applicables.
- Commission européenne, FAQ NIS2
- France, ANSSI
- France, projet de loi Résilience
- Belgique, CCB
- Belgique, Safeonweb@Work
Construire un socle IAM commun sans effacer les responsabilités locales
Une organisation internationale n'a pas nécessairement besoin de multiplier ses plateformes d'identité pour répondre aux différences entre juridictions. Elle doit d'abord clarifier les responsabilités, les processus qui peuvent être mutualisés et les contrôles qui exigent des adaptations locales. Ariovis accompagne les groupes dans la définition de cette gouvernance, la construction d'une architecture cible et la mise en œuvre progressive des processus d'identité et d'accès, en conservant des preuves exploitables par les entités concernées.
Découvrir notre méthode de schéma directeur IAM