Art. 21(2)(i)+(j) NIS 2 + CIR §11

Contrôle d'accès NIS 2 au titre de l'article 21(2)(i)+(j)

L'article 21(2)(i) nomme les politiques de contrôle d'accès. L'article 21(2)(j) nomme l'authentification multifacteur. Le CIR §11 les couvre ensemble en sept sous-sections. Cette page parcourt les obligations plus larges de politique, de comptes à privilèges et d'identité. La page MFA dédiée couvre le §11.7.

Simon OrzelSimon Orzel·

En bref

Le contrôle d'accès figure aux points (i) et (j) de l'article 21(2). Le point (i) nomme « la sécurité des ressources humaines, les politiques de contrôle d'accès et la gestion des actifs ». Le point (j) nomme « l'utilisation de solutions d'authentification multifacteur ou d'authentification continue, de communications vocales, vidéo et textuelles sécurisées ». Les deux s'appliquent à toute entité essentielle et importante dans l'UE.

Le CIR (UE) 2024/2690 §11 couvre les deux lettres ensemble, sous l'intitulé « Contrôle d'accès (article 21(2), points (i) et (j) de la directive (UE) 2022/2555) ». Il décompose l'obligation en sept sous-sections : la politique elle-même, la gestion des droits, les comptes à privilèges, les systèmes d'administration des systèmes, l'identification, l'authentification et l'authentification multifacteur. Cette page parcourt le §11.1 au §11.6. Pour le §11.7 en particulier, voir la page MFA dédiée.

L'Allemagne inscrit l'obligation de politique au §30(2)(9) BSIG et l'obligation MFA au §30(2)(10) BSIG. La référence allemande de mise en œuvre est IT-Grundschutz ORP.4 « Identitäts- und Berechtigungsmanagement ».

La source juridique
Trois couches, mais le niveau de la directive se scinde en deux lettres. L'article 21(2)(i) pour les politiques de contrôle d'accès (avec la sécurité du personnel et la gestion des actifs). L'article 21(2)(j) pour la MFA et les communications sécurisées. Le CIR §11 couvre ensuite les deux lettres ensemble. Le BSIG les scinde de nouveau au niveau national.

info.accessControl.legalAnchor.directiveI.label

info.accessControl.legalAnchor.directiveI.quote

info.accessControl.legalAnchor.directiveI.context

info.accessControl.legalAnchor.directiveJ.label

info.accessControl.legalAnchor.directiveJ.quote

info.accessControl.legalAnchor.directiveJ.context

CIR (UE) 2024/2690, annexe §11

Contrôle d'accès (article 21(2), points (i) et (j) de la directive (UE) 2022/2555).

Le CIR §11 comporte sept sous-sections : §11.1 politique de contrôle d'accès, §11.2 gestion des droits d'accès, §11.3 comptes à privilèges et comptes d'administration des systèmes, §11.4 systèmes d'administration des systèmes, §11.5 identification, §11.6 authentification, §11.7 authentification multifacteur. Ce règlement lie directement les fournisseurs de DNS, de cloud, les centres de données, les fournisseurs de services gérés et les autres secteurs cités dans l'annexe.

§30(2)(9) et (10) BSIG (Allemagne)

Konzepte für die Zugriffskontrolle und für das Management von Anlagen. […] Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung.

L'Allemagne scinde le point (i)+(j) de l'UE en deux numéros du BSIG. Le §30(2)(9) porte le contrôle d'accès et la gestion des actifs. Le §30(2)(10) porte la MFA et les communications sécurisées. Le fond est la même règle de l'UE.

Les trois éléments que le §11 du CIR exige réellement (hors §11.7 MFA)
Le CIR §11 décompose le contrôle d'accès en sept sous-sections. Les sous-sections §11.1 à §11.6 couvrent la politique, le registre des droits, les comptes à privilèges et la couche d'identité. Le §11.7 (MFA) a sa propre page. Voici les trois blocs dans lesquels les six autres sous-sections se répartissent.
§11.1 + §11.2

Politique et gestion des droits

Consignez par écrit comment l'accès fonctionne (logique et physique) pour le personnel, les visiteurs, les fournisseurs et les prestataires de services. Octroyez, modifiez et révoquez les droits selon le besoin métier : besoin d'en connaître, besoin d'utiliser, séparation des tâches. Chaque droit est attribué à une personne nommée. La révocation s'exécute au changement d'emploi, pas sur un cycle hebdomadaire. L'accès des tiers (visiteurs, fournisseurs) est suivi.

§11.3 + §11.4

Comptes à privilèges et comptes d'administration

Les comptes d'administration reçoivent une identification, une authentification et une autorisation fortes. Comptes d'administration dédiés uniquement, utilisés exclusivement pour l'installation, la configuration, la gestion et la maintenance. Les droits d'administration sont taillés individuellement et restreints. Les systèmes d'administration des systèmes résident sur leur propre réseau logique, séparés des réseaux applicatifs, accessibles via authentification et chiffrement.

§11.5 + §11.6

Identité et authentification

Cycle de vie de l'identité : identifiants uniques, chaque identifiant lié à une personne, surveillance et journalisation tout au long du cycle de vie. Les procédures d'authentification correspondent à la politique de contrôle d'accès : robustesse des mots de passe proportionnée à la classification des actifs, procédures de changement, verrouillage sur tentatives échouées, expiration des sessions, identifiants distincts pour les comptes à privilèges.

Deux règles qui structurent tout le reste
Deux principes traversent chaque sous-section du CIR §11. Tous deux déterminent la manière dont un auditeur lit ce que vous avez réellement construit.

Besoin d'en connaître, besoin d'utiliser, séparation des tâches

Le CIR §11.2 nomme les trois. Besoin d'en connaître : seules les personnes qui ont besoin des données obtiennent les données. Besoin d'utiliser : les droits correspondent à la tâche, pas au titre. Séparation des tâches : aucune personne seule ne devrait pouvoir octroyer, utiliser et auditer le même droit. Si vos groupes AD sont « informatique » et « tous les autres », vous n'avez mis en œuvre aucun des trois.

Privilégié n'est pas simplement régulier avec plus de droits

Le CIR §11.3 et §11.4 relèvent le niveau spécifiquement pour les comptes d'administration. Identification forte. La MFA est nommée dans le §11.3 lui-même, pas seulement au §11.7. Comptes dédiés utilisés uniquement pour le travail d'administration. Systèmes d'administration des systèmes sur leur propre réseau. L'enjeu : un compte d'administration compromis compromet tout, donc les comptes d'administration ont leur propre régime.

Comment les régulateurs nationaux l'appliquent concrètement
L'UE fixe la règle. Chaque pays la transpose. Le fond est le même. Les modalités locales diffèrent quelque peu.
Allemagne

BSI / IT-Grundschutz ORP.4

La référence allemande est le module IT-Grundschutz ORP.4 « Identitäts- und Berechtigungsmanagement ». ORP.4 couvre le cycle de vie de l'identité, les droits fondés sur les rôles, la séparation des comptes à privilèges, les règles de mots de passe et la cadence de réexamen. Au titre du §44(2) BSIG, la mise en œuvre de Grundschutz est explicitement reconnue comme satisfaisant aux obligations NIS 2 en Allemagne.

À l'échelle de l'UE

Orientations techniques de mise en œuvre de l'ENISA

Les orientations techniques de mise en œuvre de l'ENISA pour le CIR (UE) 2024/2690 parcourent chaque sous-section du §11 en langage opérationnel et la mettent en correspondance avec l'ISO/IEC 27001:2022 (A.5.15 à A.5.18, A.8.2 à A.8.5) et le NIST CSF 2.0 (PR.AA). Une mise en œuvre existante de contrôle d'accès ISO 27001 couvre déjà l'essentiel du §11.

Autres États membres

Lois nationales de transposition

Chaque État membre transpose l'article 21(2)(i) et (j) dans sa propre loi (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). Les obligations sont identiques parce que la directive fixe une norme unique à l'échelle de l'UE. Ce qui diffère : la norme de référence vers laquelle pointe le régulateur national.

Trois pièges que nous voyons constamment
Trois hypothèses qui reviennent dans presque chaque revue de contrôle d'accès du Mittelstand. Toutes trois créent des lacunes qu'un auditeur trouvera.

  • Nous avons des groupes AD, donc nous avons un contrôle d'accès.

    Un début, pas l'aboutissement. Le CIR §11.2 veut une politique de droits d'accès documentée, des droits attribués à des personnes nommées, une procédure de révocation liée au changement d'emploi, et un journal d'audit des octrois et des révocations. Les groupes AD vous donnent le mécanisme. Ils ne vous donnent pas la politique, le registre des personnes nommées ni la procédure d'arrivées-mouvements-départs qu'un auditeur réclamera.

  • Nos administrateurs utilisent leur compte normal pour le travail d'administration, avec sudo ou « exécuter en tant qu'administrateur ».

    Pas au titre du CIR §11.3.2. Le texte exige des « comptes d'administration dédiés » utilisés uniquement pour l'installation, la configuration, la gestion et la maintenance. Le compte normal d'un administrateur sert au courrier, à l'agenda et à Excel. Un compte d'administration distinct, avec sa propre MFA, sert au travail à privilèges. Mélanger les deux signifie qu'un courriel d'hameçonnage peut compromettre le rôle d'administration.

  • Nous synchronisons les droits d'accès chaque lundi matin.

    Proche, mais pas ce que demande le §11.2. L'obligation de révocation se déclenche au changement d'emploi, pas sur un cycle calendaire. Une personne partie le mardi ne devrait pas avoir d'accès le mercredi. Pour les changements de rôle au sein de l'entreprise, en particulier ceux à privilèges, le changement devrait être immédiat. Une cadence hebdomadaire convient pour la revue d'audit, pas pour la révocation elle-même.

Comment les opérateurs du Mittelstand procèdent réellement

Configuration typique d'un Mittelstand de 50 à 250 personnes : Active Directory ou Entra ID pour les identités, groupes AD pour l'accès aux applications, un système RH qui émet des tickets d'arrivée vers l'informatique. Le mécanisme est pour l'essentiel en place. Les lacunes du §11 résident à trois endroits.

Ce que nous voyons les praticiens corriger en premier : une politique de droits d'accès écrite (la plupart ont une ébauche, peu ont une version actuelle signée), des comptes d'administration dédiés (la plupart des administrateurs utilisent encore sudo sur leur compte quotidien), et la procédure d'arrivées-mouvements-départs qui est gérée par la seule informatique plutôt que pilotée par les RH (de sorte que le compte d'un prestataire subsiste parce que les RH n'ont jamais prévenu l'informatique de son départ). Corriger ces trois points referme l'essentiel de la lacune du §11.

Comment nous traitons cela sur la plateforme

Notre module ACC couvre le §11.1 (vous téléversez ou rédigez la politique de contrôle d'accès et l'organe de direction la valide), le §11.2 (un registre des droits lié à des utilisateurs nommés), le §11.3 (inventaire des comptes à privilèges avec preuve d'authentification distincte), et le §11.5 plus le §11.6 (journal des sources d'identité lié à votre IdP). La séparation des systèmes d'administration des systèmes du §11.4 est documentée comme une décision d'architecture avec preuve.

Pour le volet MFA du §11.7 en particulier, voir la page MFA dédiée et son flux de preuves. La piste d'audit que la plateforme tient automatiquement (validations, statut des tâches, journal des changements) couvre ce qu'un auditeur veut voir pour la cadence de réexamen et pour la décision de l'organe de direction.

Sources
  • Directive (UE) 2022/2555 (NIS 2), article 21(2)(i) et (j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §11 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • Loi BSI (BSIG), §30(2)(9) et §30(2)(10) tels que modifiés par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
  • IT-Grundschutz Kompendium, module ORP.4 « Identitäts- und Berechtigungsmanagement » — bsi.bund.de/grundschutz
  • Orientations techniques de mise en œuvre de l'ENISA pour le CIR (UE) 2024/2690 (état de mai 2026)
Menez le contrôle d'accès sans l'amas de tableurs
Politique, registre des droits, comptes à privilèges et journal d'identité sur une seule plateforme. Gratuit, open source, sans lock-in.
Ouvrir la plateforme gratuite