6 Min. de lecture<\/p>\n
Deux cadres r\u00e9glementaires, un cluster, beaucoup de confusion. Tenter de faire cohabiter NIS2 et DORA dans le m\u00eame environnement Kubernetes cr\u00e9e un probl\u00e8me d’audit qui ne se r\u00e9v\u00e8le qu’au moment de l’inspection. Une s\u00e9paration stricte au sein de clusters de conformit\u00e9 d\u00e9di\u00e9s permet d’\u00e9conomiser, en cas de crise, les semaines qu’une \u00e9quipe perdrait autrement \u00e0 rassembler les justificatifs.<\/strong><\/p>\n Articles connexes :<\/span>Kubernetes comme OS par d\u00e9faut pour l’IA : le cluster, une question de conformit\u00e9<\/a> \/<\/span> La souverainet\u00e9 de l’IA commence par l’infrastructure<\/a><\/p>\n L’erreur la plus fr\u00e9quente survient avant la premi\u00e8re ligne de YAML. Les \u00e9quipes traitent NIS2 et DORA comme un seul et m\u00eame paquet de conformit\u00e9, car les deux proviennent de Bruxelles et \u00e9voquent tous deux la r\u00e9silience. En pratique, ils s’adressent \u00e0 des cibles diff\u00e9rentes avec une profondeur d’application variable.<\/p>\n DORA, le Digital Operational Resilience Act, est en vigueur depuis le d\u00e9but de l’ann\u00e9e 2025. Il s’applique directement aux entreprises financi\u00e8res et couvre les prestataires informatiques critiques via un r\u00e9gime de supervision et de contractualisation d\u00e9di\u00e9. NIS2, la directive europ\u00e9enne sous-jacente, \u00e9largit consid\u00e9rablement le p\u00e9rim\u00e8tre : l’\u00e9nergie, la sant\u00e9, les transports, les infrastructures num\u00e9riques et de nombreux fournisseurs entrent dans son champ d’application. En Allemagne, la loi de transposition de NIS2 a \u00e9t\u00e9 adopt\u00e9e et est entr\u00e9e en vigueur en d\u00e9cembre 2025, rendant l’obligation de mise en conformit\u00e9 concr\u00e8te.<\/p>\n Pour l’architecture, la hi\u00e9rarchie des normes est primordiale. Pour une entreprise financi\u00e8re r\u00e9gul\u00e9e, DORA pr\u00e9vaut sur les exigences g\u00e9n\u00e9rales de NIS2 en tant que r\u00e9glementation sp\u00e9cifique lorsque les deux textes traitent du m\u00eame sujet. Un architecte cloud intervenant pour des PME et des ETI, qui con\u00e7oit une solution pour une banque, planifie donc son infrastructure en priorit\u00e9 selon DORA. Celui qui travaille pour un fournisseur d’\u00e9nergie 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.<\/p>\n Qu’est-ce qu’un cluster de conformit\u00e9\u00a0?<\/strong> Un cluster de conformit\u00e9 est un environnement Kubernetes d\u00e9limit\u00e9, dans lequel les charges de travail d’un r\u00e8glement particulier fonctionnent isol\u00e9ment, avec leurs propres politiques, leur propre contr\u00f4le d’acc\u00e8s et leur propre preuve. La limite est impos\u00e9e techniquement et appliqu\u00e9e en cours d’ex\u00e9cution.<\/p>\n Derri\u00e8re ce terme se cache une d\u00e9cision cruciale. R\u00e8gle de base\u00a0: les charges de travail soumises \u00e0 des r\u00e8glements diff\u00e9rents ne partagent pas la m\u00eame zone de confiance. Sur Kubernetes, cela peut s’appliquer sur deux niveaux.<\/p>\n La s\u00e9paration stricte passe par des clusters d\u00e9di\u00e9s avec leur propre plan de contr\u00f4le et leur propre mod\u00e8le d’acc\u00e8s. Les pools de n\u0153uds ne s\u00e9parent que la capacit\u00e9 de calcul et partagent le niveau de gestion, ce qui est souvent insuffisant pour les charges de travail financi\u00e8res strictement r\u00e9glement\u00e9es. La s\u00e9paration plus douce au sein d’un cluster utilise les namespaces comme fronti\u00e8re de conformit\u00e9, s\u00e9curis\u00e9e par des Network Policies qui emp\u00eachent le trafic entre les zones. Un namespace devient seulement une v\u00e9ritable fronti\u00e8re gr\u00e2ce \u00e0 une Network Policy appliqu\u00e9e, sinon il reste juste une \u00e9tiquette.<\/p>\n C’est l’application des r\u00e8gles qui fait la diff\u00e9rence. Des moteurs de politique comme Kyverno ou Open Policy Agent v\u00e9rifient chaque ressource contre des r\u00e8gles avant qu’elle ne soit d\u00e9ploy\u00e9e dans le cluster. Aucun pod sans limites de ressources d\u00e9finies, aucun conteneur en tant que root, aucune image provenant d’une registry non approuv\u00e9e. Ces r\u00e8gles constituent le v\u00e9ritable preuve de conformit\u00e9, car elles imposent l’\u00e9tat souhait\u00e9 et permettent donc de le prouver \u00e0 tout moment.<\/p>\n La plupart du travail de conformit\u00e9 consiste \u00e0 produire des preuves, et non \u00e0 mettre en \u0153uvre les r\u00e8gles. Celui qui rassemble les logs le jour de l’audit a mal con\u00e7u son syst\u00e8me. Un cluster de conformit\u00e9 produit ses propres preuves en cours d’ex\u00e9cution.<\/p>\n Trois couches doivent \u00eatre activ\u00e9es par d\u00e9faut. Le journal d’audit Kubernetes enregistre chaque action API, c’est-\u00e0-dire qui a modifi\u00e9 quelle ressource \u00e0 quel moment. Un outil de surveillance en temps r\u00e9el 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\u00e9e comme une entr\u00e9e fiable prouvant que la r\u00e8gle s’applique. Ensemble, ces trois couches forment une cha\u00eene de preuves que l’auditeur peut suivre sans avoir besoin de regarder l’\u00e9cran de l’\u00e9quipe.<\/p>\n L’avantage va au-del\u00e0 de l’audit. NIS2 exige des installations concern\u00e9es de signaler rapidement des incidents de s\u00e9curit\u00e9 importants. Celui qui a correctement instrument\u00e9 sa t\u00e9l\u00e9m\u00e9trie r\u00e9pond aux questions sur la nature et le moment d’un incident \u00e0 partir de ses propres donn\u00e9es, sans avoir \u00e0 les reconstruire.<\/p>\n La souverainet\u00e9 se d\u00e9finit dans la configuration, pas dans le contrat avec l’hyperscaler. Les deux cadres r\u00e9glementaires exigent une ma\u00eetrise de la localisation des donn\u00e9es et de qui y acc\u00e8de. Sur Kubernetes, cela peut \u00eatre mis en \u0153uvre techniquement.<\/p>\n Le pinning r\u00e9gional via les affinit\u00e9s de n\u0153uds et les contraintes de topologie garantit que les charges de travail r\u00e9glement\u00e9es ne quittent pas la r\u00e9gion promise. La chiffrement s’applique aux deux chemins, en transit et au repos, avec des cl\u00e9s dont l’administration est contr\u00f4l\u00e9e par l’entreprise elle-m\u00eame. L’acc\u00e8s s’effectue via des droits bas\u00e9s sur les r\u00f4les, tranch\u00e9s selon le principe de moindre privil\u00e8ge. Un cluster o\u00f9 la moiti\u00e9 de l’\u00e9quipe est administrateur du cluster ne passe pas une v\u00e9rification s\u00e9rieuse.<\/p>\n Ce qui fait \u00e9chouer une v\u00e9rification<\/p>\n Ce qui permet de r\u00e9ussir<\/p>\n L’ordre d\u00e9termine l’effort. Celui qui commence par la d\u00e9cision de d\u00e9coupage, c’est-\u00e0-dire quelles charges de travail appartiennent \u00e0 quelle zone, \u00e9vite ainsi des reconstructions co\u00fbteuses plus tard. Celui qui commence par le outil construit des politiques pour une s\u00e9paration qui n’a m\u00eame pas encore \u00e9t\u00e9 bien pens\u00e9e.<\/p>\n Trois \u00e9tapes dans cette s\u00e9quence offrent le levier le plus important. Tout d’abord, la carte r\u00e9glementaire : quelle charge de travail rel\u00e8ve de quel cadre r\u00e9glementaire, et y a-t-il des charges financi\u00e8res d\u00e9clenchant un priorit\u00e9 DORA ? Ensuite, la s\u00e9paration : des clusters d\u00e9di\u00e9s pour les cas les plus exigeants, des namespaces avec des politiques de r\u00e9seau pour le reste. Enfin, l’automatisation des preuves, afin que la preuve soit g\u00e9n\u00e9r\u00e9e en production. Les amendes sont r\u00e9elles, la directive NIS2 pr\u00e9voit des sanctions de minimum 10 millions d’euros ou 2 % du chiffre d’affaires mondial de l’ann\u00e9e pr\u00e9c\u00e9dente, selon ce qui est le plus \u00e9lev\u00e9. Le v\u00e9ritable co\u00fbt r\u00e9side souvent plus t\u00f4t, en semaines perdues par une \u00e9quipe pour la documentation post\u00e9rieure, car l’architecture n’a jamais produit elle-m\u00eame la preuve.<\/p>\n Cela d\u00e9pend du secteur. Les entreprises financi\u00e8res rel\u00e8vent principalement de DORA, qui, en tant que r\u00e8gle sp\u00e9ciale, prime sur les exigences g\u00e9n\u00e9rales de NIS2 lorsque les deux r\u00e9gissent la m\u00eame situation. Les entreprises en dehors du secteur financier, consid\u00e9r\u00e9es comme des entit\u00e9s critiques ou importantes, se pr\u00e9parent pour NIS2. Celles qui op\u00e8rent dans ces deux mondes les s\u00e9parent techniquement.<\/p>\n<\/details>\n C’est techniquement possible via des Namespaces avec des Network Policies appliqu\u00e9es. Dans les cas complexes, comme les Workloads financiers critiques sous DORA, la s\u00e9paration physique en clusters d\u00e9di\u00e9s ou en Node-Pools est le choix le plus propre. La d\u00e9cision d\u00e9pend du risque, et non de la commodit\u00e9.<\/p>\n<\/details>\n Un \u00e9tat cible impos\u00e9 associ\u00e9 \u00e0 une cha\u00eene de preuves tra\u00e7able. Une Policy-Engine qui v\u00e9rifie chaque ressource par rapport aux r\u00e8gles, un journal d’audit Kubernetes et une surveillance du runtime fournissent ensemble la preuve que les exigences sont techniquement appliqu\u00e9es. Un PDF d\u00e9crivant l’\u00e9tat est nettement plus faible.<\/p>\n<\/details>\n En tant que r\u00e8glement de l’UE, DORA s’applique directement depuis le 17 janvier 2025. NIS2 est une directive qui n\u00e9cessite une transposition nationale. En Allemagne, la loi de transposition de NIS2 est en vigueur depuis d\u00e9cembre 2025. Les entit\u00e9s concern\u00e9es doivent donc v\u00e9rifier activement leurs obligations d’enregistrement et de d\u00e9claration.<\/p>\n<\/details>\n Par la cartographie r\u00e9glementaire, et non par l’outil. Il faut d’abord clarifier quel Workload rel\u00e8ve de quelle r\u00e9glementation, puis d\u00e9finir la s\u00e9paration, et enfin automatiser les preuves de conformit\u00e9. Cet ordre emp\u00eache les restructurations co\u00fbteuses et garantit que la preuve est d\u00e9j\u00e0 disponible en production.<\/p>\n<\/details>\nLes points cl\u00e9s en bref<\/h2>\n
\n
1. S\u00e9parer NIS2 et DORA avant de concevoir l’architecture<\/h2>\n
2. Couper proprement les clusters au lieu de m\u00e9langer les charges de travail<\/h2>\n
\n\n
\n \nDimension<\/th>\n NIS2<\/th>\n DORA<\/th>\n<\/tr>\n<\/thead>\n \n Destinataires<\/strong><\/td>\n Installations critiques et importantes \u00e0 travers de nombreux secteurs<\/td>\n Entreprises financi\u00e8res et leurs prestataires IT critiques<\/td>\n<\/tr>\n \n Port\u00e9e<\/strong><\/td>\n Directive europ\u00e9enne, mise en \u0153uvre nationale n\u00e9cessaire<\/td>\n R\u00e8glement europ\u00e9en, applicable directement depuis le 17 janvier 2025<\/td>\n<\/tr>\n \n Point central<\/strong><\/td>\n Gestion des risques, obligations de signalement, cha\u00eene d’approvisionnement<\/td>\n R\u00e9silience informatique, risque tiers, tests de r\u00e9silience<\/td>\n<\/tr>\n \n Relation<\/strong><\/td>\n Cadre g\u00e9n\u00e9ral<\/td>\n R\u00e8gle sp\u00e9cifique, pr\u00e9valente dans le secteur financier<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n 3. Collecter automatiquement les preuves, et non chercher le jour de l’audit<\/h2>\n
4. Int\u00e9grer la souverainet\u00e9 des donn\u00e9es dans la configuration des clusters<\/h2>\n
\n
\n
5. Avec quoi les architectes devraient commencer en premier lieu<\/h2>\n
Foire aux questions<\/h2>\n
Les r\u00e9glementations NIS2 et DORA s’appliquent-elles simultan\u00e9ment \u00e0 mon entreprise ?<\/strong><\/summary>\n
Un seul cluster Kubernetes suffit-il pour les deux r\u00e9glementations ?<\/strong><\/summary>\n
Qu’est-ce qui compte comme preuve de conformit\u00e9 solide lors d’un audit ?<\/strong><\/summary>\n
Depuis quand DORA s’applique-t-elle, et NIS2 est-elle d\u00e9j\u00e0 une loi en Allemagne ?<\/strong><\/summary>\n
Par o\u00f9 les \u00e9quipes Cloud des PME devraient-elles commencer ?<\/strong><\/summary>\n