FAQ Container Security : 5 Questions Fréquentes sur la Conformité NIS2 dans le Secteur de la Santé

Introduction : Container Security et NIS2 – Un Enjeu Critique pour les Acteurs de la Santé

La sécurisation des conteneurs est devenue un impératif stratégique pour les établissements de santé et les éditeurs de solutions médicales, particulièrement depuis l’entrée en vigueur de la directive NIS2 (Directive (UE) 2022/2555). Avec la digitalisation accélérée des systèmes de santé et la migration vers le cloud, les conteneurs représentent à la fois un vecteur d’innovation et un risque cyber majeur.

Selon l’article 21 de la directive, les entités du secteur santé (classées en Annexe I comme entités essentielles) doivent mettre en œuvre des mesures techniques et organisationnelles proportionnées pour sécuriser leurs chaînes logicielles. Cela inclut spécifiquement les environnements conteneurisés utilisés pour :

• Les applications métiers critiques (DMP, logiciels de gestion hospitalière)
• Les dispositifs médicaux connectés
• Les plateformes d’analyse de données patients
• Les infrastructures HDS (Hébergement de Données de Santé)

Le non-respect de ces obligations expose les organisations à des sanctions administratives pouvant atteindre, pour les entités essentielles, 10 millions d’euros ou 2% du chiffre d’affaires annuel mondial (selon l’article 34). Dans un contexte où 63% des incidents cyber dans la santé concernent des vulnérabilités logicielles (source ANSSI 2025), la sécurisation des conteneurs n’est plus optionnelle.

1. Quelles Obligations NIS2 Spécifiques s’Appliquent à la Container Security ?

1.1 Les Exigences Clés de l’Article 21 pour les Environnements Conteneurisés

L’article 21 de la directive NIS2 impose aux entités du secteur santé (Annexe I) des mesures minimales de gestion des risques qui impactent directement la sécurité des conteneurs :

• Gouvernance des chaînes d’approvisionnement logicielles (Art. 21.2.a) : Audit des images de base, vérification des fournisseurs de registries, traçabilité des composants
• Contrôle d’accès et gestion des identités (Art. 21.2.b) : RBAC pour les clusters Kubernetes, authentification mutuelle entre conteneurs
• Cryptographie (Art. 21.2.c) : Chiffrement des données sensibles en transit et au repos dans les volumes persistants
• Sécurité dès la conception (Art. 21.2.d) : Intégration de DevSecOps dans les pipelines CI/CD conteneurisés
• Gestion des vulnérabilités (Art. 21.2.e) : Scan continu des images, correctifs pour les CVE critiques sous 72h

1.2 Le Cadre HDS et son Articulation avec NIS2

Pour les hébergeurs de données de santé (HDS), les exigences NIS2 viennent renforcer le référentiel existant :

Les hébergeurs HDS doivent donc :

• Documenter leur architecture conteneurisée dans le dossier de sécurité (Art. 21.3)
• Mettre en place des mécanismes de détection d’intrusion spécifiques aux orchestrateurs (Art. 23.1)
• Notifier tout incident affectant des conteneurs hébergeant des données de santé sous 24h (Art. 23.2)

2. Comment Mettre en Conformité vos Containers avec NIS2 ?

2.1 Les 5 Étapes Clés pour une Containerization Sécurisée

Conformément aux guides ANSSI sur la sécurisation des systèmes cloud,

1. Inventaire et classification (Art. 21.1) :
   • Cartographier tous les registres, clusters et conteneurs en production
   • Taguer les conteneurs selon leur criticité (niveau de risque patient)
2. Durcissement des images :
   • Utiliser des images minimales (distroless) validées ANSSI
   • Signer les images avec Cosign ou Notary
   • Scanner avec Trivy ou Grype avant déploiement
3. Sécurisation de l’orchestration :
   • Isolation réseau via Network Policies
   • Limitation des droits avec PodSecurityPolicies
   • Monitoring des API Kubernetes avec Falco
4. Protection des données :
   • Chiffrement des volumes avec KMS (Key Management Service)
   • Masquage des secrets via Vault ou SealedSecrets
5. Surveillance et réponse :
   • Centralisation des logs avec ELK ou Loki
   • Détection d’anomalies avec Sysdig ou Datadog
   • Plan de réponse aux incidents spécifique aux conteneurs

2.2 Les Outils Recommandés par l’ANSSI

Dans son guide “Sécurisation des architectures conteneurisées” (2025), l’ANSSI préconise :

• Pour le scanning : Trivy, Grype, Clair
• Pour la signature : Sigstore, Notary
• Pour le durcissement : kube-bench, kube-hunter
• Pour le monitoring : Falco, Tetragon

Ces outils permettent de répondre aux exigences de l’article 21.2.e sur la gestion proactive des vulnérabilités. Leur mise en œuvre doit être documentée dans le système de gestion de la sécurité (Art. 21.3).

# FAQ Container Security : 5 Questions Fréquentes

## 6. Comment gérer les secrets dans un environnement conteneurisé ?

La gestion des secrets (mots de passe, clés API, certificats) est un enjeu critique en container security. <2min) | Mise à jour quotidienne | Oui via Admission Controller | | Clair | Moyen (5-10min) | Extensive | Requis un registry externe | | Snyk | Variable | Avec priorités business | Plugins Helm disponibles | ## 8. Comment implémenter une politique de sécurité réseau entre containers ? ### Technologies clés - **Network Policies** (Kubernetes) : Isolation segmentée via des règles ingress/egress - **Service Mesh** : Istio/Linkerd pour du mTLS et du filtrage L7 - **Micro-segmentation** : Calico, Cilium avec eBPF ### Exemple de Network Policy ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: frontend-isolation spec: podSelector: matchLabels: role: frontend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: backend ports: - protocol: TCP port: 443 ``` ### Stratégies recommandées 1. **Modèle zero-trust** : Tout trafic est refusé par défaut 2. **Isolation par namespace** : Limitation des communications cross-namespaces 3. **Journalisation du trafic** : Monitoring avec des outils comme Suricata ou Falco ## 9. Audit et conformité : quels frameworks appliquer ? ### Standards majeurs - **ISO 27001** : Contrôles généraux de sécurité - **NIST SP 800-190** : Guide spécifique container security - **PCI DSS v4.0** : Exigences pour les workloads traitant des données cartes ### Checklist d'audit - [ ] Désactivation des privilèges inutiles - [ ] Mise en place de ressources limites (CPU/mémoire) - [ ] Rotation régulière des certificats - [ ] Revue des droits d'accès au registry ```bash # Commandes utiles pour l'audit docker inspect --format '{{ .HostConfig.Privileged }}'
kubectl get pods –all-namespaces -o json | jq ‘.items[].spec.containers[].securityContext’
“`

## 10. Que faire en cas de compromission d’un container ?

### Procédure d’incident response
1. **Isolation** : Mise en quarantaine du pod/container concerné
2. **Forensics** : Export des logs et systèmes de fichiers
3. **Root cause analysis** : Investigation via :
– Historique des déploiements
– Analyse du Dockerfile source
– Revue des accès au registry

### Outils de détection
– **Falco** : Détection runtime des comportements anormaux
– **Tracee** : Monitoring eBPF des syscalls
– **SIEM intégration** : Envoi des logs vers Splunk/ELK

> **