Sécurité des réseaux NIS 2 au titre de l'article 21, paragraphe 2, point e)
NIS 2 prévoit que vos réseaux et systèmes d'information doivent être sûrs lors de l'acquisition, du développement et de la maintenance. L'article 21, paragraphe 2, point e), est l'endroit où réside l'obligation, le CIR (UE) 2024/2690 §6.7 et §6.8 en détaillent les éléments propres au réseau, et le §30, alinéa 2, point 5, du BSIG en est la transposition allemande.
La version courte
L'article 21, paragraphe 2, point e), est le cinquième de la liste des dix obligations de cybersécurité au titre de NIS 2. Il couvre l'ensemble du cycle de vie des réseaux et systèmes d'information : comment vous les achetez, comment vous les construisez et comment vous les maintenez en service en toute sécurité. Le CIR (UE) 2024/2690 §6 décline ensuite cela en plusieurs sous-sections. Les éléments propres au réseau sont le §6.7 (sécurité des réseaux) et le §6.8 (segmentation des réseaux).
Le §6.7 est le plus difficile à lire des deux. Douze actions concrètes, de la documentation de votre architecture réseau à l'hygiène DNS et à la sécurisation de la messagerie. Le §6.8 est le plus simple : divisez votre réseau en zones selon ce que chaque zone doit faire, et tenez à l'écart les trafics de production, de test et d'administration.
L'Allemagne inscrit la même obligation en droit national par le §30, alinéa 2, point 5, du BSIG. Le BSI désigne IT-Grundschutz NET.1 (Netze und Kommunikation) et NET.3.2 (Firewall) comme la voie de mise en œuvre pratique. Cette page parcourt la directive, le CIR et la couche allemande dans cet ordre.
Article 21, paragraphe 2, point e), de la directive NIS 2 (2022/2555)
La sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités.
Le point e) de la liste de l'article 21, paragraphe 2. Il couvre l'ensemble du cycle de vie de vos réseaux et systèmes informatiques, pas seulement leur état en exploitation. Le CIR §6 décompose ensuite cela en plusieurs sous-sections. Le §6.7 et le §6.8 sont les sous-sections propres au réseau.
CIR (UE) 2024/2690, annexe §6.7 et §6.8
§6.7 Sécurité des réseaux. Les entités concernées prennent les mesures appropriées pour protéger leurs réseaux et systèmes d'information des cybermenaces. §6.8 Segmentation des réseaux. Les entités concernées segmentent leurs systèmes […] en réseaux ou en zones conformément aux résultats de l'appréciation des risques […] ; elles segmentent également leurs propres systèmes et réseaux des systèmes et réseaux de tiers.
Comme il s'agit d'un règlement (et non d'une directive), c'est du droit de l'Union directement contraignant. Le §6.7 énumère douze actions concrètes, de l'architecture réseau documentée à l'hygiène DNS et messagerie. Le §6.8 énumère huit actions de segmentation, dont la DMZ, la séparation des réseaux d'administration et la séparation de la production du développement et du test.
§30, alinéa 2, point 5, du BSIG (Allemagne)
Des mesures de sécurité lors de l'acquisition, du développement et de la maintenance des systèmes, composants et processus de technologie de l'information, y compris la gestion et la divulgation des vulnérabilités.
L'Allemagne reprend le texte de l'UE presque mot pour mot. Le BSI désigne ensuite IT-Grundschutz NET.1 (Netze und Kommunikation) et NET.3.2 (Firewall) comme la voie de mise en œuvre reconnue pour le détail du §6.7 et du §6.8.
Documenter le réseau, contrôler l'accès interne
Tenez un schéma à jour et clair de votre architecture réseau. Définissez et appliquez des contrôles pour protéger les domaines internes contre l'accès non autorisé. Bloquez les connexions et services qui ne sont pas nécessaires. Définissez des contrôles distincts pour l'accès à distance, y compris l'accès à distance des fournisseurs. N'autorisez pas l'utilisation des systèmes d'administration à d'autres fins. Désactivez ou interdisez explicitement les connexions et services que vous n'utilisez pas.
Hygiène au niveau des appareils, des protocoles, du DNS et de la messagerie
Le cas échéant, restreignez l'accès aux seuls appareils approuvés. N'autorisez les connexions des fournisseurs qu'après une demande d'approbation et seulement pour une fenêtre de temps définie (par exemple, la maintenance). Faites transiter la communication de système à système par des canaux de confiance, séparés logiquement, cryptographiquement ou physiquement, avec une identification sécurisée des points terminaux. Planifiez et accélérez la migration vers des protocoles modernes de couche réseau. Adoptez des standards de messagerie modernes et interopérables pour combler les vulnérabilités liées à la messagerie. Appliquez des pratiques éprouvées de sécurité DNS et d'hygiène de routage pour le trafic entrant et sortant.
Segmenter par le risque, séparer la production du test et de l'administration
Segmentez vos systèmes en réseaux ou en zones en utilisant le résultat de l'appréciation des risques du §2.1, et non par simple commodité. Tenez compte des liens fonctionnels, logiques, physiques et de localisation entre systèmes de confiance. Accordez l'accès aux zones en fonction des exigences de sécurité de cette zone. Placez les systèmes indispensables à l'exploitation ou à la sécurité à l'intérieur de zones sécurisées. Exploitez une DMZ sur les réseaux de communication. Restreignez l'accès aux zones et au sein des zones à ce dont l'exploitation a besoin. Exploitez un réseau d'administration dédié pour les systèmes, séparé du réseau opérationnel. Tenez les canaux d'administration réseau séparés des autres trafics. Tenez les systèmes de production des services en exploitation séparés du développement et du test, y compris leurs sauvegardes.
Segmenter par le risque, pas par commodité
Le CIR §6.8.2 rattache la segmentation au §2.1 : c'est l'appréciation des risques qui vous dit de quelles zones vous avez besoin et à quel point les frontières entre elles doivent être strictes. Un réseau à plat avec un seul pare-feu n'est pas de la segmentation. Des zones fondées sur ce que chaque partie de l'activité fait réellement, et sur le risque qu'elle porte, le sont. Si vous ne pouvez pas pointer la ligne de l'appréciation des risques qui justifie une zone, vous n'avez pas de segmentation au sens de la norme.
Documenter l'architecture, la tenir à jour
Le §6.7.2 a) est la première action de la liste pour une raison. Tout le reste du §6.7 et du §6.8 repose sur un schéma réseau documenté et à jour. Les auditeurs regardent le schéma en premier. S'il n'existe pas, ou s'il a deux ans de retard, chaque autre mesure devient plus difficile à vérifier. Traitez le schéma comme un document vivant, pas comme un fichier Visio créé une fois pour toutes.
BSI / §30, alinéa 2, point 5, du BSIG / IT-Grundschutz
Le BSI désigne IT-Grundschutz NET.1 (Netze und Kommunikation) pour la conception réseau générale et NET.3.2 (Firewall) pour les contrôles de périmètre et de segmentation. Les deux Bausteine correspondent aux actions du §6.7 et du §6.8 presque une pour une. Si vous exploitez déjà un réseau conforme au Grundschutz, vous pouvez utiliser la documentation existante comme base de preuve.
Orientations techniques de mise en œuvre de l'ENISA
Les orientations techniques de mise en œuvre (TIG) de l'ENISA couvrent l'art. 21, paragraphe 2, point e), et les sous-sections du CIR §6, y compris la sécurité des réseaux et la segmentation. Elles mettent les exigences en correspondance avec les mesures d'ISO/IEC 27001:2022 (A.8.20 Sécurité des réseaux, A.8.21 Sécurité des services de réseau, A.8.22 Cloisonnement des réseaux) et avec le NIST CSF 2.0 PR.IR (Technology Infrastructure Resilience). Si vous exploitez déjà l'un de ces référentiels, vous pouvez réutiliser les mesures.
Lois nationales de transposition
Les autres États membres transposent l'art. 21, paragraphe 2, point e), dans leurs propres lois (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). La substance est identique parce que le détail du CIR §6 lie directement les secteurs nommés. Ce qui diffère, c'est l'agence à laquelle vous vous adressez et quelles orientations nationales de mise en œuvre vous lisez en parallèle du CIR.
Nous avons un pare-feu, donc nous sommes couverts.
Un pare-feu, c'est bien. Ce n'est pas tout le §6.7. Le §6.7.2 a) veut une architecture réseau documentée et à jour. Le §6.7.2 c) veut que les connexions et services inutilisés soient bloqués par défaut. Le §6.7.2 f) veut que les services inutilisés soient explicitement interdits ou désactivés. Le §6.8 veut une segmentation par le risque. Un pare-feu sans ces quatre éléments satisfait à une ligne du §6.7, pas à la sous-section.
La production et le test se trouvent sur le même réseau parce que c'est plus facile.
Le §6.8.2 h) est explicite : les systèmes de production des services en exploitation doivent être séparés du développement et du test, y compris leurs sauvegardes. C'est l'une des lacunes les plus difficiles à rattraper et l'une des plus faciles à repérer pour un auditeur. Un sous-réseau partagé entre production et test ne survivra pas à la revue du §6.8.
Nos administrateurs se connectent au pare-feu depuis leurs postes de travail habituels.
Le §6.8.2 f) veut un réseau d'administration distinct pour les systèmes. Le §6.8.2 g) veut que les canaux d'administration soient séparés des autres trafics réseau. Se connecter à un pare-feu depuis un poste de travail qui fait aussi tourner la messagerie et un navigateur enfreint les deux. Utilisez un hôte rebond dédié ou un poste de travail à accès privilégié, sur un VLAN de gestion séparé.
Un réseau Mittelstand typique de 60 à 250 personnes dispose déjà d'un pare-feu et souvent d'une DMZ. Les lacunes §6.7 et §6.8 que nous voyons sont généralement les trois mêmes : pas de schéma réseau documenté, pas de réseau d'administration dédié, et la production et le test sur le même sous-réseau. Chacune d'elles est peu coûteuse à consigner une fois et pénible à rattraper plus tard.
L'ordre pragmatique : dessinez le réseau actuel sur une page, segmentez selon ce que chaque zone fait réellement (bureau, serveurs, DMZ, OT ou production, administration), consignez quelles connexions sont autorisées entre zones et pourquoi, et faites passer l'accès d'administration sur un VLAN de gestion séparé avec un hôte rebond. Cela couvre le §6.7.2 a), le cœur de segmentation du §6.8, et la séparation du réseau d'administration du §6.8.2 f) et g). Le reste est de l'hygiène qui en découle.
Le module PRO de la plateforme contient l'inventaire de l'architecture réseau, les règles de segmentation et le registre du réseau d'administration. Vous consignez chaque zone, ce qu'elle fait, ce à quoi elle se connecte et quelle ligne de l'appréciation des risques la justifie. Le schéma et la logique de segmentation vivent au même endroit, et non éclatés entre un fichier Visio et une page Confluence.
Les modifications du réseau sont consignées au fil de l'eau, de sorte que le §6.7.2 a) reste un document vivant plutôt qu'un instantané. La piste d'audit capture qui a modifié quoi et quand, ce qui est la preuve qu'un auditeur veut voir lorsqu'il demande si la documentation reflète la réalité.
- Directive (UE) 2022/2555 (NIS 2), article 21, paragraphe 2, point e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §6.7 et §6.8 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi sur le BSI (BSIG), §30, alinéa 2, point 5, telle que modifiée par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- BSI IT-Grundschutz, Bausteine NET.1 (Netze und Kommunikation) et NET.3.2 (Firewall) — bsi.bund.de/grundschutz
- Orientations techniques de mise en œuvre de l'ENISA pour le CIR (UE) 2024/2690 (en date de mai 2026)