NIS2 und DORA sauber trennen: Compliance-Cluster in Kubernetes
NIS2 und DORA fordern verschiedene Pflichten. Wie Cloud-Architekten beide als getrennte Compliance-Cluster in Kubernetes umsetzen und Audits bestehen.
Zwei Regelwerke, ein Cluster, viel Verwirrung. Wer NIS2 und DORA in dieselbe Kubernetes-Umgebung presst, baut sich ein Audit-Problem, das erst beim Prüfer auffällt. Die saubere Trennung in eigene Compliance-Cluster spart im Ernstfall die Wochen, die ein Team sonst mit dem Zusammensuchen von Nachweisen verliert.
Das Wichtigste in Kürze
- NIS2 und DORA adressieren verschiedene Welten: DORA gilt seit dem 17. Januar 2025 für den Finanzsektor und seine IT-Dienstleister, NIS2 trifft einen viel breiteren Kreis kritischer und wichtiger Einrichtungen. Für Banken und Versicherer geht DORA als Spezialregel vor.
- Compliance-Cluster heißt Trennung mit Beweiskraft: Eigene Namespaces, durchgesetzte Policies und automatisch gesammelte Evidence schlagen jede nachträgliche Dokumentation. Der Prüfer will den Soll-Zustand technisch erzwungen sehen, nicht in einer PDF beschrieben.
- Datensouveränität gehört in die Cluster-Konfiguration, nicht ins Vertragswerk: Region-Pinning, Verschlüsselung und nachvollziehbare Zugriffspfade entscheiden, ob die Architektur eine Prüfung übersteht oder am ersten Tag durchfällt.
Verwandt:Kubernetes als KI-Default-OS: Cluster als Compliance-Frage / KI-Souveränität beginnt bei der Infrastruktur
1. NIS2 und DORA trennen, bevor die Architektur steht
Der häufigste Fehler passiert vor der ersten Zeile YAML. Teams behandeln NIS2 und DORA als ein einziges Compliance-Paket, weil beide aus Brüssel kommen und beide nach Resilienz klingen. In der Praxis adressieren sie unterschiedliche Adressaten mit unterschiedlicher Tiefe.
DORA, der Digital Operational Resilience Act, ist seit Anfang 2025 in Kraft. Er gilt unmittelbar für Finanzunternehmen und erfasst kritische IT-Drittanbieter über ein eigenes Aufsichts- und Vertragsregime. NIS2, die zugrunde liegende EU-Richtlinie, zieht einen weit größeren Kreis: Energie, Gesundheit, Verkehr, digitale Infrastruktur und viele Zulieferer fallen darunter. In Deutschland ist das NIS2-Umsetzungsgesetz inzwischen verabschiedet und seit Dezember 2025 in Kraft. Die Pflicht zur Umsetzung wird damit konkret.
Wichtig für die Architektur ist die Rangfolge. Für ein reguliertes Finanzunternehmen geht DORA als Spezialregel den allgemeinen NIS2-Anforderungen vor, wo beide denselben Sachverhalt regeln. Ein Cloud-Architekt im Mittelstand, der für eine Bank baut, plant also primär gegen DORA. Wer für einen Energieversorger oder einen Maschinenbauer baut, plant gegen NIS2. Wer beide Kunden bedient, braucht beide Welten getrennt, nicht vermischt.
2. Cluster sauber schneiden statt Workloads vermischen
Was ist ein Compliance-Cluster? Ein Compliance-Cluster ist eine abgegrenzte Kubernetes-Umgebung, in der Workloads eines bestimmten Regelwerks isoliert laufen, mit eigenen Policies, eigener Zugriffskontrolle und eigener Nachweisführung. Die Grenze wird technisch erzwungen und im laufenden Betrieb belegt.
Hinter dem Begriff steckt eine Schnittentscheidung. Die Grundregel: Workloads, die unter unterschiedliche Regelwerke fallen, teilen sich keine vertrauenswürdige Zone. Auf Kubernetes lässt sich das auf zwei Ebenen umsetzen.
Die harte Trennung läuft über dedizierte Cluster mit eigener Control Plane und eigenem Zugriffsmodell. Node-Pools trennen nur die Rechenkapazität und teilen sich die Steuerungsebene, für streng regulierte Finanz-Workloads reicht das oft nicht. Die weichere Trennung innerhalb eines Clusters nutzt Namespaces als Compliance-Grenze, abgesichert mit Network Policies, die den Querverkehr zwischen den Zonen unterbinden. Ein Namespace wird erst durch eine durchgesetzte Network Policy zur echten Grenze, vorher bleibt er eine reine Beschriftung.
Den Unterschied macht die Durchsetzung. Policy-Engines wie Kyverno oder Open Policy Agent prüfen jede Ressource gegen Regeln, bevor sie im Cluster landet. Kein Pod ohne definierte Ressourcengrenzen, kein Container als Root, kein Image aus einer nicht freigegebenen Registry. Diese Regeln sind der eigentliche Compliance-Nachweis, weil sie den Soll-Zustand erzwingen und damit jederzeit belegen.
| Dimension | NIS2 | DORA |
|---|---|---|
| Adressaten | Kritische und wichtige Einrichtungen quer durch viele Sektoren | Finanzunternehmen und ihre kritischen IT-Dienstleister |
| Geltung | EU-Richtlinie, nationale Umsetzung erforderlich | EU-Verordnung, seit 17. Januar 2025 unmittelbar |
| Schwerpunkt | Risikomanagement, Meldepflichten, Lieferkette | IT-Resilienz, Drittparteienrisiko, Resilienztests |
| Verhältnis | Allgemeiner Rahmen | Spezialregel, geht im Finanzsektor vor |
3. Evidence automatisch sammeln, nicht am Prüfungstag suchen
Die meiste Compliance-Arbeit verbrennt im Nachweis, nicht in der Umsetzung. Wer am Tag der Prüfung Logs zusammensucht, hat das System falsch gebaut. Ein Compliance-Cluster produziert seinen eigenen Beweis im laufenden Betrieb.
Drei Schichten gehören standardmäßig aktiviert. Das Kubernetes-Audit-Log hält jede API-Aktion fest, wer wann welche Ressource verändert hat. Ein Laufzeit-Wächter wie Falco meldet verdächtiges Verhalten in Containern, etwa eine Shell, die in einem Produktions-Pod auftaucht. Und die Policy-Engine protokolliert jede abgelehnte Ressource als belastbaren Eintrag, dass die Regel greift. Zusammen ergeben diese drei Schichten eine Beweiskette, die ein Prüfer nachvollziehen kann, ohne dem Team auf den Bildschirm schauen zu müssen.
Der Nutzen reicht über die Prüfung hinaus. NIS2 verlangt von betroffenen Einrichtungen, erhebliche Sicherheitsvorfälle innerhalb kurzer Fristen zu melden. Wer seine Telemetrie sauber instrumentiert hat, beantwortet die Frage nach dem Was und Wann eines Vorfalls aus den eigenen Daten, statt sie zu rekonstruieren.
4. Datensouveränität in die Cluster-Konfiguration verankern
Souveränität entscheidet sich in der Konfiguration, nicht im Vertrag mit dem Hyperscaler. Beide Regelwerke verlangen Kontrolle darüber, wo Daten liegen und wer auf sie zugreift. Auf Kubernetes lässt sich das technisch festnageln.
Region-Pinning über Node-Affinitäten und Topology-Constraints stellt sicher, dass regulierte Workloads die zugesagte Region nicht verlassen. Verschlüsselung gehört auf beide Pfade, im Transit und im Ruhezustand, mit Schlüsseln, deren Verwaltung das Unternehmen selbst kontrolliert. Und der Zugriff läuft über rollenbasierte Rechte, die nach dem Prinzip der minimalen Berechtigung geschnitten sind. Ein Cluster, in dem die Hälfte des Teams Cluster-Admin ist, besteht keine ernsthafte Prüfung.
Was bricht eine Prüfung
- Namespaces ohne durchgesetzte Network Policies
- Compliance nur in Dokumenten, nicht im Cluster erzwungen
- Breite Admin-Rechte ohne Begründung
- Evidence, die erst am Prüfungstag gesucht wird
Was trägt durch
- Policy-Engine setzt den Soll-Zustand technisch durch
- Audit-Log, Laufzeit-Monitoring und Policy-Logs als Beweiskette
- Region-Pinning und eigene Schlüsselverwaltung
- Rechte nach minimaler Berechtigung geschnitten
5. Womit Architekten zuerst anfangen sollten
Die Reihenfolge entscheidet über den Aufwand. Wer mit der Schnittentscheidung beginnt, welche Workloads in welche Zone gehören, spart sich später teure Umbauten. Wer mit dem Werkzeug beginnt, baut Policies für eine Trennung, die noch gar nicht durchdacht ist.
Drei Schritte in dieser Folge bringen den größten Hebel. Erst die regulatorische Landkarte: Welcher Workload fällt unter welches Regelwerk und gibt es Finanz-Workloads, die DORA-Vorrang auslösen. Dann die Trennung: dedizierte Cluster für die harten Fälle, Namespaces mit Network Policies für den Rest. Zuletzt die Automatisierung von Evidence, damit der Nachweis im Betrieb entsteht. Bußgelder sind real, die NIS2-Richtlinie sieht für wesentliche Einrichtungen Sanktionen von mindestens 10 Millionen Euro oder 2 Prozent des weltweiten Vorjahresumsatzes vor, je nachdem welcher Betrag höher ist. Der eigentliche Schaden liegt aber meist früher, in Wochen, die ein Team in der Nachdokumentation verliert, weil die Architektur den Beweis nie selbst erzeugt hat.
Häufige Fragen
Gelten NIS2 und DORA gleichzeitig für mein Unternehmen?
Das hängt vom Sektor ab. Finanzunternehmen fallen primär unter DORA, das als Spezialregel den allgemeinen NIS2-Anforderungen vorgeht, wo beide denselben Sachverhalt regeln. Unternehmen außerhalb des Finanzsektors, die als kritische oder wichtige Einrichtung gelten, planen gegen NIS2. Wer beide Welten bedient, trennt sie technisch.
Reicht ein einziges Kubernetes-Cluster für beide Regelwerke?
Technisch möglich ist es über Namespaces mit durchgesetzten Network Policies. Bei harten Fällen, etwa kritischen Finanz-Workloads unter DORA, ist die physische Trennung in dedizierte Cluster oder Node-Pools die sauberere Wahl. Die Entscheidung hängt am Risiko, nicht an der Bequemlichkeit.
Was zählt im Audit als belastbarer Compliance-Nachweis?
Ein erzwungener Soll-Zustand plus eine nachvollziehbare Beweiskette. Eine Policy-Engine, die jede Ressource gegen Regeln prüft, ein Kubernetes-Audit-Log und Laufzeit-Monitoring liefern zusammen den Nachweis, dass Vorgaben technisch greifen. Eine PDF, die den Zustand beschreibt, ist deutlich schwächer.
Seit wann gilt DORA und ist NIS2 in Deutschland schon Gesetz?
DORA gilt als EU-Verordnung unmittelbar seit dem 17. Januar 2025. NIS2 ist eine Richtlinie, die nationale Umsetzung benötigt. In Deutschland ist das NIS2-Umsetzungsgesetz seit Dezember 2025 in Kraft. Betroffene Einrichtungen sollten ihre Registrierungs- und Meldepflichten daher aktiv prüfen.
Wo fangen mittelständische Cloud-Teams am besten an?
Mit der regulatorischen Landkarte, nicht mit dem Werkzeug. Erst klären, welcher Workload unter welches Regelwerk fällt, dann die Trennung schneiden, dann Evidence automatisieren. Diese Reihenfolge verhindert teure Umbauten und sorgt dafür, dass der Nachweis schon im laufenden Betrieb vorliegt.
Bildquelle: KI-generiert (Juli 2026)
