La directive NIS2 renforce considérablement les exigences en matière de cybersécurité et de gestion des risques pour les entités essentielles et importantes à travers l’Union européenne. Contrairement aux approches purement politiques, NIS2 met fortement l’accent sur les contrôles techniques, la préparation opérationnelle et les mesures de sécurité démontrables.
Cette page explique une architecture de sécurité NIS2 de référence, montrant comment la gouvernance, les pipelines CI/CD et les systèmes opérationnels fonctionnent ensemble pour répondre aux obligations NIS2 en pratique.
NIS2 Security Architecture (Overview)
“NIS2 Security Architecture – Secure Delivery and Operations”
Cette architecture illustre comment les organisations peuvent implémenter les exigences NIS2 sur l’ensemble du cycle de vie des services numériques, de la gouvernance et du développement à la production et à la réponse aux incidents.
Comment lire ce diagramme
Le diagramme est structuré de gauche à droite, suivant le cycle de vie de la livraison et de l’exploitation des services numériques :
- Gouvernance et gestion des risques
- Développement sécurisé et CI/CD
- Opérations et gestion des incidents
Une couche transversale de sécurité et de preuves s’applique à tous les composants, reflétant l’accent mis par NIS2 sur une posture de cybersécurité et une préparation continues.
Couche de gouvernance et de gestion des cyber-risques
La couche de gouvernance reflète les exigences NIS2 liées à la gestion des risques, à la responsabilité et aux mesures organisationnelles.
Cette couche comprend :
- Évaluations des risques de cybersécurité
- Politiques et normes de sécurité
- Rôles et responsabilités définis
- Supervision et revue par la direction
Sous NIS2, la responsabilité s’étend à la direction exécutive. L’architecture de sécurité doit donc soutenir une propriété claire et un contrôle démontrable.
Couche de développement sécurisé et CI/CD
NIS2 exige explicitement des organisations qu’elles implémentent des pratiques de développement sécurisé et gèrent les risques tout au long de la chaîne d’approvisionnement.
Dans cette architecture, les pipelines CI/CD agissent comme points d’application pour :
- Pratiques de développement logiciel sécurisé
- Contrôle d’accès et séparation des fonctions
- Tests de sécurité (SAST, analyse de dépendances, détection de secrets)
- Atténuation des risques de la chaîne d’approvisionnement
Les pipelines CI/CD garantissent que les contrôles de sécurité sont appliqués de manière cohérente avant que le logiciel n’atteigne les environnements de production.
Couche opérations et gestion des incidents
La couche opérationnelle répond aux exigences NIS2 en matière de détection, de réponse et de résilience.
Les capacités clés incluent :
- Surveillance et journalisation continues
- Détection et classification des incidents
- Réponse coordonnée aux incidents
- Mécanismes de récupération et de continuité de service
Les pipelines CI/CD s’intègrent aux opérations pour soutenir la remédiation rapide et la récupération contrôlée suite aux incidents de sécurité.
Sécurité de la chaîne d’approvisionnement (préoccupation transversale)
NIS2 met explicitement l’accent sur la sécurité de la chaîne d’approvisionnement. Cette architecture intègre les contrôles de la chaîne d’approvisionnement à travers le développement et les opérations :
- Validation et surveillance des dépendances
- Intégrité des artefacts et provenance
- Intégrations tierces contrôlées
- Visibilité sur les services externalisés
Ces contrôles réduisent l’exposition aux attaques de la chaîne d’approvisionnement logicielle et aux risques tiers.
Preuves continues et responsabilité
À travers toutes les couches, l’architecture génère des preuves de sécurité continues, notamment :
- Journaux et données de surveillance
- Résultats des tests de sécurité
- Historiques de déploiement et de changements
- Enregistrements de traitement des incidents
Ces preuves soutiennent la supervision réglementaire, les obligations de signalement d’incidents et l’analyse post-incident requises par NIS2.
Pourquoi cette architecture est importante pour NIS2
NIS2 exige des organisations qu’elles démontrent une gestion efficace des risques de cybersécurité, et pas seulement qu’elles la documentent.
Cette architecture permet :
- L’application technique des mesures de cybersécurité
- Une visibilité continue sur la posture de sécurité
- Une détection et une réponse plus rapides aux incidents
- Une responsabilité claire entre les équipes et la direction
En intégrant la sécurité dans la livraison et les opérations, les organisations peuvent répondre aux attentes NIS2 de manière durable.
Mettre l’architecture en correspondance avec l’Article 21 de NIS2
Les auditeurs n’évaluent pas un diagramme d’architecture dans l’abstrait. Ils testent si chaque couche satisfait une obligation précise de l’Article 21 et si elle produit des preuves sur demande. Le tableau ci-dessous relie les couches ci-dessus aux mesures pertinentes de l’Article 21 et aux artefacts qu’un évaluateur demande généralement.
| Couche d’architecture | Mesure NIS2 Article 21 | Preuves demandées par les auditeurs |
|---|---|---|
| Gouvernance et gestion des risques | Art. 21(2)(a), (f) | Évaluations des risques nommant les services numériques ; politiques approuvées avec dates de revue ; enregistrements de revue et de validation par la direction |
| Développement sécurisé et CI/CD | Art. 21(2)(e) | Enregistrements de réussite/échec des barrières de sécurité ; SBOM ; preuves de séparation des tâches dans les approbations de release |
| Opérations et gestion des incidents | Art. 21(2)(b), (c) | Configuration de la surveillance et des alertes ; journaux d’incidents avec délais détection-résolution ; résultats des tests de reprise après sinistre |
| Chaîne d’approvisionnement (transversale) | Art. 21(2)(d) | Évaluations des risques fournisseurs ; provenance et signatures des artefacts ; registres et listes de dépendances approuvés |
| Accès et authentification | Art. 21(2)(i), (j) | Matrices RBAC ; revues d’accès périodiques ; attestations d’application du MFA pour les interfaces de pipeline et de production |
| Preuves continues | Art. 21(2)(f) | Journaux immuables ; configuration de la rétention ; revues documentées d’efficacité des contrôles |
Constats fréquents à l’encontre de cette architecture
Les mêmes faiblesses reviennent lorsqu’une architecture NIS2 existe sur le papier mais n’a pas été pleinement rendue opérationnelle. Chacune est un point où un contrôle ne peut pas être étayé par des preuves, ce qui, lors d’une revue de supervision, est traité comme un contrôle qui n’est pas efficace :
- Architecture documentée mais non appliquée dans le pipeline, laissant les contrôles de sécurité consultatifs plutôt que bloquants
- Responsabilité de la direction exigée par NIS2 non étayée par des preuves — aucun enregistrement de revue ou d’approbation de la posture de risque par la direction
- Contrôles de la chaîne d’approvisionnement limités à la production, les dépendances au moment du build restant non gouvernées
- Procédures d’incident qui ne nomment pas le pipeline de livraison comme un système dans le périmètre
- Preuves de surveillance impossibles à corréler entre gouvernance, livraison et opérations
- Rétention des journaux inférieure à la période nécessaire à la notification aux autorités de supervision et à l’analyse post-incident
Questions de vérification pour chaque couche
Avant une revue de supervision, les responsables de contrôles peuvent éprouver l’architecture en répondant aux questions qu’un évaluateur est le plus susceptible de soulever. Toute réponse qui repose sur une assurance verbale plutôt que sur un enregistrement signale une lacune à combler :
- La direction peut-elle démontrer, preuves à l’appui, qu’elle a revu et approuvé la posture de risque de cybersécurité de l’organisation ?
- Pour une release échantillonnée, pouvez-vous montrer quelles barrières de sécurité elle a franchies et qui a autorisé le déploiement ?
- Comment les dépendances tierces sont-elles validées avant d’entrer dans un build, et où cela est-il enregistré ?
- Quand a eu lieu le dernier exercice de réponse aux incidents incluant un scénario lié au pipeline ?
- La plateforme CI/CD elle-même figure-t-elle dans l’inventaire des actifs TIC et est-elle couverte par des revues d’accès périodiques ?
- Combien de temps les preuves sont-elles conservées, et sont-elles stockées de manière à ne pas pouvoir être altérées après coup ?
Responsabilité de la direction et obligations de notification
NIS2 relève les enjeux pour la gouvernance d’une manière que l’architecture doit activement soutenir. En vertu de l’Article 20, les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité, superviser leur mise en œuvre, et peuvent être tenus personnellement responsables des défaillances. La couche de gouvernance ci-dessus n’est donc pas décorative — c’est là qu’une organisation étaye cette responsabilité auprès d’une autorité de supervision.
L’architecture doit également servir le calendrier de notification des incidents de NIS2. Une fois un incident important identifié, les couches opérations et preuves doivent produire, dans l’ordre :
- Une alerte précoce à l’autorité compétente dans les 24 heures
- Une notification formelle de l’incident dans les 72 heures, incluant une évaluation initiale de la gravité et de l’impact
- Un rapport final dans un délai d’un mois, décrivant la cause racine, les mesures d’atténuation et tout impact transfrontalier
Sans preuves corrélées et horodatées circulant de la surveillance jusqu’au traitement des incidents, respecter ces délais avec des informations défendables est difficile. La couche de preuves continues est ce qui rend une notification rapide et exacte réalisable plutôt qu’aspirationnelle — et c’est précisément cette préparation à la notification que les auditeurs sondent lorsqu’ils testent la couche opérations.
De l’architecture à l’implémentation
Cette architecture fournit une référence de haut niveau. Les détails d’implémentation pratique et les guides d’audit sont couverts dans le contenu associé, notamment :
Conclusion
La conformité NIS2 commence par l’architecture. En intégrant la gouvernance, le développement sécurisé, l’application CI/CD et la résilience opérationnelle dans une architecture de sécurité unifiée, les organisations peuvent répondre aux exigences NIS2 de manière proactive et cohérente.
Ce diagramme fournit une compréhension claire et partagée de la façon dont les obligations de sécurité NIS2 sont implémentées dans les systèmes numériques modernes.
