Séparation claire de NIS2 et DORA : cluster de conformité dans Kubernetes
NIS2 et DORA impose différentes obligations. En tant qu'architectes cloud, comment mettre en œuvre séparément ces exigences de conformité dans Kubernetes…
Deux cadres réglementaires, un cluster, beaucoup de confusion. Tenter de faire cohabiter NIS2 et DORA dans le même environnement Kubernetes crée un problème d’audit qui ne se révèle qu’au moment de l’inspection. Une séparation stricte au sein de clusters de conformité dédiés permet d’économiser, en cas de crise, les semaines qu’une équipe perdrait autrement à rassembler les justificatifs.
Les points clés en bref
- NIS2 et DORA s’adressent à des mondes différents : DORA s’applique depuis le 17 janvier 2025 au secteur financier et à ses prestataires de services informatiques, tandis que NIS2 concerne un cercle bien plus large d’entités essentielles et importantes. Pour les banques et les assureurs, DORA prime en tant que réglementation spécifique.
- Un cluster de conformité signifie une séparation dotée d’une force probante : Des namespaces dédiés, des politiques appliquées et des preuves collectées automatiquement surpassent toute documentation a posteriori. L’auditeur souhaite constater un état cible techniquement imposé, et non simplement décrit dans un PDF.
- La souveraineté des données relève de la configuration du cluster, et non du contrat : Le Region-Pinning, le chiffrement et les chemins d’accès traçables déterminent si l’architecture survit à un audit ou échoue dès le premier jour.
Articles connexes :Kubernetes comme OS par défaut pour l’IA : le cluster, une question de conformité / La souveraineté de l’IA commence par l’infrastructure
1. Séparer NIS2 et DORA avant de concevoir l’architecture
L’erreur la plus fréquente survient avant la première ligne de YAML. Les équipes traitent NIS2 et DORA comme un seul et même paquet de conformité, car les deux proviennent de Bruxelles et évoquent tous deux la résilience. En pratique, ils s’adressent à des cibles différentes avec une profondeur d’application variable.
DORA, le Digital Operational Resilience Act, est en vigueur depuis le début de l’année 2025. Il s’applique directement aux entreprises financières et couvre les prestataires informatiques critiques via un régime de supervision et de contractualisation dédié. NIS2, la directive européenne sous-jacente, élargit considérablement le périmètre : l’énergie, la santé, les transports, les infrastructures numériques et de nombreux fournisseurs entrent dans son champ d’application. En Allemagne, la loi de transposition de NIS2 a été adoptée et est entrée en vigueur en décembre 2025, rendant l’obligation de mise en conformité concrète.
Pour l’architecture, la hiérarchie des normes est primordiale. Pour une entreprise financière régulée, DORA prévaut sur les exigences générales de NIS2 en tant que réglementation spécifique lorsque les deux textes traitent du même sujet. Un architecte cloud intervenant pour des PME et des ETI, qui conçoit une solution pour une banque, planifie donc son infrastructure en priorité selon DORA. Celui qui travaille pour un fournisseur d’énergie ou un constructeur industriel planifie selon NIS2. Si vous accompagnez les deux types de clients, vous devez maintenir deux environnements distincts, et non les fusionner.
2. Couper proprement les clusters au lieu de mélanger les charges de travail
Qu’est-ce qu’un cluster de conformité ? Un cluster de conformité est un environnement Kubernetes délimité, dans lequel les charges de travail d’un règlement particulier fonctionnent isolément, avec leurs propres politiques, leur propre contrôle d’accès et leur propre preuve. La limite est imposée techniquement et appliquée en cours d’exécution.
Derrière ce terme se cache une décision cruciale. Règle de base : les charges de travail soumises à des règlements différents ne partagent pas la même zone de confiance. Sur Kubernetes, cela peut s’appliquer sur deux niveaux.
La séparation stricte passe par des clusters dédiés avec leur propre plan de contrôle et leur propre modèle d’accès. Les pools de nœuds ne séparent que la capacité de calcul et partagent le niveau de gestion, ce qui est souvent insuffisant pour les charges de travail financières strictement réglementées. La séparation plus douce au sein d’un cluster utilise les namespaces comme frontière de conformité, sécurisée par des Network Policies qui empêchent le trafic entre les zones. Un namespace devient seulement une véritable frontière grâce à une Network Policy appliquée, sinon il reste juste une étiquette.
C’est l’application des règles qui fait la différence. Des moteurs de politique comme Kyverno ou Open Policy Agent vérifient chaque ressource contre des règles avant qu’elle ne soit déployée dans le cluster. Aucun pod sans limites de ressources définies, aucun conteneur en tant que root, aucune image provenant d’une registry non approuvée. Ces règles constituent le véritable preuve de conformité, car elles imposent l’état souhaité et permettent donc de le prouver à tout moment.
| Dimension | NIS2 | DORA |
|---|---|---|
| Destinataires | Installations critiques et importantes à travers de nombreux secteurs | Entreprises financières et leurs prestataires IT critiques |
| Portée | Directive européenne, mise en œuvre nationale nécessaire | Règlement européen, applicable directement depuis le 17 janvier 2025 |
| Point central | Gestion des risques, obligations de signalement, chaîne d’approvisionnement | Résilience informatique, risque tiers, tests de résilience |
| Relation | Cadre général | Règle spécifique, prévalente dans le secteur financier |
3. Collecter automatiquement les preuves, et non chercher le jour de l’audit
La plupart du travail de conformité consiste à produire des preuves, et non à mettre en œuvre les règles. Celui qui rassemble les logs le jour de l’audit a mal conçu son système. Un cluster de conformité produit ses propres preuves en cours d’exécution.
Trois couches doivent être activées par défaut. Le journal d’audit Kubernetes enregistre chaque action API, c’est-à-dire qui a modifié quelle ressource à quel moment. Un outil de surveillance en temps réel comme Falco signale des comportements suspects dans les conteneurs, par exemple l’apparition d’une shell dans un pod de production. Et la policy engine enregistre chaque ressource refusée comme une entrée fiable prouvant que la règle s’applique. Ensemble, ces trois couches forment une chaîne de preuves que l’auditeur peut suivre sans avoir besoin de regarder l’écran de l’équipe.
L’avantage va au-delà de l’audit. NIS2 exige des installations concernées de signaler rapidement des incidents de sécurité importants. Celui qui a correctement instrumenté sa télémétrie répond aux questions sur la nature et le moment d’un incident à partir de ses propres données, sans avoir à les reconstruire.
4. Intégrer la souveraineté des données dans la configuration des clusters
La souveraineté se définit dans la configuration, pas dans le contrat avec l’hyperscaler. Les deux cadres réglementaires exigent une maîtrise de la localisation des données et de qui y accède. Sur Kubernetes, cela peut être mis en œuvre techniquement.
Le pinning régional via les affinités de nœuds et les contraintes de topologie garantit que les charges de travail réglementées ne quittent pas la région promise. La chiffrement s’applique aux deux chemins, en transit et au repos, avec des clés dont l’administration est contrôlée par l’entreprise elle-même. L’accès s’effectue via des droits basés sur les rôles, tranchés selon le principe de moindre privilège. Un cluster où la moitié de l’équipe est administrateur du cluster ne passe pas une vérification sérieuse.
Ce qui fait échouer une vérification
- Des namespaces sans politiques de réseau appliquées
- Une conformité uniquement documentaire, pas imposée dans le cluster
- Des droits d’administrateur larges sans justification
- Des preuves recherchées seulement le jour de la vérification
Ce qui permet de réussir
- L’engine de politique met en œuvre l’état souhaité techniquement
- Les logs d’audit, le monitoring en temps réel et les logs de politique comme chaîne de preuve
- Le pinning régional et la gestion propre des clés
- Des droits tranchés selon le principe de moindre privilège
5. Avec quoi les architectes devraient commencer en premier lieu
L’ordre détermine l’effort. Celui qui commence par la décision de découpage, c’est-à-dire quelles charges de travail appartiennent à quelle zone, évite ainsi des reconstructions coûteuses plus tard. Celui qui commence par le outil construit des politiques pour une séparation qui n’a même pas encore été bien pensée.
Trois étapes dans cette séquence offrent le levier le plus important. Tout d’abord, la carte réglementaire : quelle charge de travail relève de quel cadre réglementaire, et y a-t-il des charges financières déclenchant un priorité DORA ? Ensuite, la séparation : des clusters dédiés pour les cas les plus exigeants, des namespaces avec des politiques de réseau pour le reste. Enfin, l’automatisation des preuves, afin que la preuve soit générée en production. Les amendes sont réelles, la directive NIS2 prévoit des sanctions de minimum 10 millions d’euros ou 2 % du chiffre d’affaires mondial de l’année précédente, selon ce qui est le plus élevé. Le véritable coût réside souvent plus tôt, en semaines perdues par une équipe pour la documentation postérieure, car l’architecture n’a jamais produit elle-même la preuve.
Foire aux questions
Les réglementations NIS2 et DORA s’appliquent-elles simultanément à mon entreprise ?
Cela dépend du secteur. Les entreprises financières relèvent principalement de DORA, qui, en tant que règle spéciale, prime sur les exigences générales de NIS2 lorsque les deux régissent la même situation. Les entreprises en dehors du secteur financier, considérées comme des entités critiques ou importantes, se préparent pour NIS2. Celles qui opèrent dans ces deux mondes les séparent techniquement.
Un seul cluster Kubernetes suffit-il pour les deux réglementations ?
C’est techniquement possible via des Namespaces avec des Network Policies appliquées. Dans les cas complexes, comme les Workloads financiers critiques sous DORA, la séparation physique en clusters dédiés ou en Node-Pools est le choix le plus propre. La décision dépend du risque, et non de la commodité.
Qu’est-ce qui compte comme preuve de conformité solide lors d’un audit ?
Un état cible imposé associé à une chaîne de preuves traçable. Une Policy-Engine qui vérifie chaque ressource par rapport aux règles, un journal d’audit Kubernetes et une surveillance du runtime fournissent ensemble la preuve que les exigences sont techniquement appliquées. Un PDF décrivant l’état est nettement plus faible.
Depuis quand DORA s’applique-t-elle, et NIS2 est-elle déjà une loi en Allemagne ?
En tant que règlement de l’UE, DORA s’applique directement depuis le 17 janvier 2025. NIS2 est une directive qui nécessite une transposition nationale. En Allemagne, la loi de transposition de NIS2 est en vigueur depuis décembre 2025. Les entités concernées doivent donc vérifier activement leurs obligations d’enregistrement et de déclaration.
Par où les équipes Cloud des PME devraient-elles commencer ?
Par la cartographie réglementaire, et non par l’outil. Il faut d’abord clarifier quel Workload relève de quelle réglementation, puis définir la séparation, et enfin automatiser les preuves de conformité. Cet ordre empêche les restructurations coûteuses et garantit que la preuve est déjà disponible en production.
Plus d’articles du réseau MBF Media
Source de l’image : générée par IA (Juli 2026)
