Vue d’ensemble : NIS2 Article 21 et mesures de gestion des risques de cybersécurité
La Directive NIS2 Article 21 établit les mesures de base de gestion des risques de cybersécurité que les entités essentielles et importantes doivent mettre en œuvre. Pour les organisations s’appuyant sur des pipelines CI/CD pour livrer des logiciels, ces exigences se traduisent directement en contrôles de gouvernance des pipelines que les auditeurs et les responsables conformité doivent évaluer.
L’Article 21 impose une approche tous risques — ce qui signifie que les contrôles doivent couvrir les risques sur l’ensemble du cycle de vie de livraison logicielle, pas uniquement l’infrastructure de production. Cela inclut les environnements de build, l’automatisation du déploiement, la gestion des artefacts et les workflows d’approbation des changements.
Le tableau ci-dessous met en correspondance chaque exigence de l’Article 21 avec les contrôles CI/CD correspondants et les preuves que les auditeurs devraient demander lors des évaluations.
Exigences de l’Article 21 mises en correspondance avec les contrôles CI/CD
| Exigence NIS2 Article 21 | Contrôle CI/CD | Preuves pour les auditeurs |
|---|---|---|
| Art. 21(2)(a) — Analyse des risques et politiques de sécurité des systèmes d’information | Politique de sécurité des pipelines documentée couvrant les étapes de build, test et déploiement ; évaluations périodiques des risques de l’infrastructure CI/CD | Documents de politique approuvés avec historique de versions ; rapports d’évaluation des risques référençant les actifs CI/CD ; enregistrements de validation par la direction |
| Art. 21(2)(b) — Gestion des incidents | Procédures de réponse aux incidents de pipeline ; alertes automatisées sur les échecs de build/déploiement ; mécanismes de rollback | Playbooks de réponse aux incidents spécifiques aux défaillances de pipeline ; enregistrements de configuration des alertes ; journaux d’incidents montrant les délais détection-résolution |
| Art. 21(2)(c) — Continuité d’activité et gestion de crise | Plans de redondance et de reprise après sinistre des pipelines ; sauvegarde des configurations et secrets de pipeline ; objectifs de temps de récupération pour l’infrastructure de build | Plans de continuité d’activité couvrant les systèmes CI/CD ; procédures de récupération documentées ; résultats de tests des exercices PRA ; journaux de vérification des sauvegardes |
| Art. 21(2)(d) — Sécurité de la chaîne d’approvisionnement | Politiques de gouvernance des dépendances ; registres et catalogues d’images de base approuvés ; évaluations des fournisseurs d’outils CI/CD ; génération de Software Bill of Materials (SBOM) | Listes de dépendances approuvées ; enregistrements SBOM par release ; rapports d’évaluation des risques fournisseurs ; workflows d’approbation des composants tiers |
| Art. 21(2)(e) — Sécurité dans l’acquisition, le développement et la maintenance des réseaux et systèmes d’information | Standards de configuration sécurisée des pipelines ; séparation des environnements (dev/staging/production) ; barrières de scan de sécurité automatisées | Baselines de configuration des pipelines ; documentation d’architecture des environnements ; politiques de barrières de scan et enregistrements réussite/échec |
| Art. 21(2)(f) — Politiques et procédures pour évaluer l’efficacité des mesures de gestion des risques de cybersécurité | Métriques et KPI de sécurité des pipelines ; audits périodiques des pipelines ; revues d’efficacité des contrôles | Rapports de tableaux de bord sur les taux de réussite des barrières de sécurité ; constats d’audit et suivi de remédiation ; comptes rendus de revue de direction |
| Art. 21(2)(g) — Pratiques de base en cyberhygiène et formation en cybersécurité | Formation des développeurs sur l’utilisation sécurisée des pipelines ; procédures d’onboarding documentées pour l’accès aux pipelines | Enregistrements de formation complétée ; checklists d’onboarding ; supports de programme de sensibilisation référençant la sécurité CI/CD |
| Art. 21(2)(h) — Politiques et procédures relatives à l’utilisation de la cryptographie et du chiffrement | Politiques de gestion des secrets ; chiffrement des artefacts en transit et au repos ; exigences de signature de code | Attestations de configuration des outils de gestion des secrets ; politiques de chiffrement ; enregistrements de vérification des artefacts signés ; journaux de gestion des certificats |
| Art. 21(2)(i) — Sécurité des ressources humaines, politiques de contrôle d’accès et gestion des actifs | Contrôle d’accès basé sur les rôles (RBAC) pour les systèmes de pipeline ; inventaire des actifs pipeline ; processus arrivée/mutation/départ pour l’accès CI/CD | Matrices RBAC pour les outils de pipeline ; journaux de revue d’accès ; registres d’actifs listant les composants CI/CD ; enregistrements de provisionnement et dé-provisionnement d’accès |
| Art. 21(2)(j) — Utilisation de l’authentification multi-facteurs (MFA) et communications sécurisées | Application du MFA sur toutes les interfaces d’administration des pipelines ; canaux de communication chiffrés entre les composants de pipeline | Attestations de configuration de l’application MFA ; journaux d’authentification montrant l’utilisation du MFA ; preuves de configuration TLS/mTLS pour la communication inter-composants |
Ce que les auditeurs doivent vérifier
Couche politique et gouvernance
- Existence et actualité des politiques : Confirmer que les politiques de sécurité des pipelines existent, sont approuvées par la direction appropriée et ont été revues dans les 12 derniers mois.
- Adéquation du périmètre : Vérifier que les politiques couvrent explicitement l’infrastructure CI/CD, pas uniquement les systèmes de production. De nombreuses organisations négligent les environnements de build dans leurs cadres de sécurité.
- Couverture de l’évaluation des risques : Vérifier que le registre des risques de l’organisation inclut les risques spécifiques au CI/CD tels que l’altération de pipeline, la fuite de secrets et l’empoisonnement de dépendances.
Couche d’implémentation des contrôles
- Séparation des tâches : Vérifier que la personne qui écrit le code ne peut pas aussi l’approuver et le déployer sans revue indépendante.
- Traçabilité des changements : Confirmer que chaque déploiement en production peut être retracé vers une demande de changement approuvée, une revue de code et un scan de sécurité réussi.
- Contrôles d’accès : Demander des preuves de revues d’accès périodiques pour les outils d’administration des pipelines. Rechercher les comptes dormants et les privilèges excessifs.
- Gestion des secrets : Confirmer que les secrets ne sont pas codés en dur dans les configurations de pipeline. Demander une attestation de l’outil de gestion des secrets.
Couche de preuves et surveillance
- Complétude des journaux : Vérifier que les journaux de pipeline capturent qui a déclenché un déploiement, ce qui a été déployé, quand cela a été déployé et si toutes les barrières requises ont été franchies.
- Périodes de rétention : Confirmer que la rétention des journaux respecte à la fois les exigences NIS2 et la propre politique de l’organisation (typiquement un minimum de 12 à 24 mois).
- Protection contre l’altération : Vérifier si les journaux de pipeline sont stockés dans un stockage en ajout seul ou immuable pour empêcher la manipulation post-incident.
Signaux d’alerte à surveiller
- Des politiques de sécurité des pipelines qui se contentent de référencer les politiques IT générales sans contrôles spécifiques CI/CD
- Aucune preuve de revues d’accès périodiques pour les outils de pipeline
- Des déploiements qui contournent les barrières d’approbation requises (rechercher les enregistrements de dérogation ou de déploiement d’urgence sans justification a posteriori)
- Des secrets visibles dans les journaux de pipeline ou les fichiers de configuration
- Aucune gouvernance documentée de la chaîne d’approvisionnement pour les dépendances tierces
Comment les auditeurs testent ces contrôles en pratique
Mettre en correspondance les exigences avec les contrôles n’est que la moitié de l’exercice. Sur le terrain, les auditeurs ne lisent pas les politiques de façon isolée — ils testent si les contrôles cartographiés fonctionnent réellement comme décrit. Comprendre leur méthode aide les équipes conformité à préparer les bonnes preuves.
Une évaluation type combine trois techniques :
- L’entretien — interroger les responsables et ingénieurs des pipelines pour comprendre comment un contrôle est censé fonctionner, puis comparer ce récit à la politique documentée.
- L’inspection — examiner la configuration, les matrices RBAC, les définitions des barrières et des échantillons de journaux pour confirmer que le contrôle existe tel que configuré, et pas seulement tel que rédigé.
- La ré-exécution et l’échantillonnage — sélectionner un échantillon de releases de production sur la période examinée et retracer chacune depuis le changement d’origine jusqu’au déploiement, en passant par la revue, les barrières de sécurité et l’approbation.
Parce que l’Article 21 exige une approche tous risques, un seul échantillon en défaut — une release parvenue en production sans barrière de sécurité franchie, ou une approbation accordée par l’auteur du changement — suffit souvent à soulever un constat contre l’exigence correspondante. Préparer à l’avance un petit nombre d’exemples de releases complets et traçables est l’un des moyens les plus efficaces de raccourcir une évaluation.
Recoupement avec DORA, ISO 27001 et SOC 2
La plupart des entités réglementées sont soumises à plusieurs cadres à la fois. Les contrôles qui satisfont l’Article 21 couvrent également de larges pans de DORA, ISO 27001 et SOC 2 — ce qui signifie qu’un environnement de contrôle CI/CD unique et bien étayé peut répondre simultanément à plusieurs obligations. La correspondance ci-dessous met en évidence les recoupements les plus forts.
| Thème NIS2 Article 21 | DORA | ISO 27001 (Annexe A) | SOC 2 |
|---|---|---|---|
| Analyse des risques et politiques de sécurité (a) | Cadre de gestion des risques TIC | A.5.1, A.5.9 | CC3.x |
| Gestion des incidents (b) | Gestion et notification des incidents TIC | A.5.24–A.5.27 | CC7.x |
| Sécurité de la chaîne d’approvisionnement (d) | Risque TIC lié aux tiers | A.5.19–A.5.23 | CC9.2 |
| Développement et acquisition sécurisés (e) | Gestion des changements TIC | A.8.25–A.8.32 | CC8.1 |
| Contrôle d’accès et MFA (i, j) | Protection et prévention TIC | A.5.15–A.5.18, A.8.5 | CC6.x |
Pour les auditeurs, ce recoupement est une occasion de réduire les doublons : une seule revue de bout en bout du pipeline peut fournir des preuves pour plusieurs cadres. Pour les responsables conformité, il plaide pour le maintien d’un jeu de contrôles consolidé plutôt que d’une documentation parallèle propre à chaque cadre.
Préparer un dossier de preuves pour l’Article 21
Plutôt que de rassembler les preuves de façon réactive, les équipes matures maintiennent un dossier de preuves permanent aligné sur les dix sous-exigences de l’Article 21. Au minimum, il devrait contenir :
- La politique de sécurité des pipelines en vigueur, avec ses dates d’approbation et de dernière revue
- La dernière évaluation des risques CI/CD et l’inventaire des actifs
- Les matrices RBAC et la dernière revue d’accès pour l’outillage des pipelines
- Un exemple de SBOM, un enregistrement d’artefact signé et une approbation de dépendance pour une release récente
- Des procédures de réponse aux incidents et de continuité d’activité qui nomment explicitement le pipeline
- Deux ou trois exemples de releases entièrement traçables couvrant le code, la revue, les barrières, l’approbation et le déploiement
Maintenir ce dossier à jour transforme chaque évaluation d’un exercice dans l’urgence en une revue de bout en bout sans heurts, et répond directement à l’exigence (f) — l’obligation d’évaluer l’efficacité des mesures elles-mêmes.
Ressources connexes
Pour une compréhension plus approfondie de la façon dont les principes d’architecture de sécurité NIS2 s’appliquent aux environnements CI/CD, consultez Architecture de sécurité NIS2 expliquée.
Pour la bibliothèque complète de ressources de conformité NIS2, visitez notre Hub de conformité NIS2.
Connexe pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- DORA Article 21 — Analyse approfondie
- Comparaison NIS2 vs DORA
- Checklist de préparation à l’audit
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
