Wem gehören NIS2 und DORA in einem Kubernetes-Plattformteam

GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.

Es gibt ein Meeting, das sich gerade in vielen europäischen Engineering-Organisationen wiederholt. Jemand aus Legal oder Risk bringt eine NIS2-Kontrolle, einen DORA-Artikel oder eine Anfrage wie „Können wir das nachweisen?“ in den Raum. Das Kubernetes-Plattformteam schaut auf Security. Security schaut auf das Plattformteam. Ein Ticket landet im Security-Board, weil sich das wie der richtige Ort für alles anfühlt, das eine Verordnung im Titel trägt. Drei Sprints später hat sich am Cluster nichts geändert, der Nachweis existiert immer noch nicht, und alle sind leise genervt vom Security-Lead.

Das Versagen ist weder rechtlicher noch technischer Natur. Es ist ein Ownership-Versagen mit einer spezifischen Form: Ein Verordnungsname wurde auf ein Board gelegt, statt ein Artefakt in einen Sprint zu legen. Security kann die Policy schreiben. Security kann den Helm-Chart nicht mergen.

Dieser Artikel – von Matteo Bisi von Reevo – schließt diese Lücke auf einer Cloud-Native-Plattform: die Rückverfolgbarkeitskette von einer regulatorischen Anforderung bis zu einem Kubernetes-Objekt, ein RACI, das den Kontakt mit der Sprint-Planung überlebt, und die Open-Source-Projekte, die den Nachweis tatsächlich erzeugen.

Hinweis: Nichts davon ist Rechtsberatung, und keine der Zuordnungen ist eine offizielle Compliance-Zuordnung. NIS2 und DORA sind ergebnisorientierte Texte. Welche Unternehmen und Dienste in den Anwendungsbereich fallen, welche Maßnahmen verhältnismäßig sind und welche Nachweise ausreichen, hängt von der eigenen Risikobewertung der Organisation, ihren Branchenregeln, der nationalen Umsetzung und der zuständigen Aufsichtsbehörde ab – nicht von einer Tabelle in einem Blogbeitrag.

Was passiert, wenn Security die Verordnung besitzt

Der übliche Standard ist, dass alles mit einer Verordnung im Titel zu einem Security-Ticket wird. Der CISO – oder der eine leitende Security-Ingenieur, der noch auf Slack antwortet – wird zum Eigentümer von NIS2, DORA und allem, was als Nächstes kommt. Plattformingenieure bleiben bei der Produktarbeit. Security wird zu einer Warteschlange.

Zwei Fehlermuster folgen daraus, und sie verstärken sich gegenseitig:

• Der Engpass. Jede Image-Ausnahme, jedes privilegierte securityContext, jede Anfrage wie „Wir brauchen dieses Log im SIEM“ wartet auf dieselben zwei Personen. Lieferteams lernen, dass Reden mit Security bedeutet, dass Arbeit stirbt, also umgehen sie es: hier ein Break-Glass-kubeconfig, dort ein Sidecar, das niemand geprüft hat, eine Registry, die nicht im genehmigten Katalog steht.
• Erlernte Hilflosigkeit. Wenn Compliance dauerhaft im Backlog von jemand anderem liegt, übernehmen Plattformingenieure nie die Begründung dahinter. Sie liefern eine Admission-Policy aus, weil man es ihnen gesagt hat, deaktivieren sie, wenn sie ein Release blockiert, und warten, bis Security es bemerkt. Einem Plattformteam kann man nicht abverlangen, Ergebnisse zu verantworten, während das regulatorische Ergebnis auf dem Board eines anderen Teams liegt.

Keines der beiden Fehlermuster ist ein Persönlichkeitsproblem. Beide sind Organisationsdesigns, die niemand laut benannt hat.

Was NIS2 Artikel 20 und DORA Artikel 5 tatsächlich zuweisen

Beide Texte sind unmissverständlich, wo die Verantwortung liegt – und es ist nicht „das Security-Team“.

• NIS2 Artikel 20 legt Maßnahmen zum Cybersicherheits-Risikomanagement dem Leitungsorgan von wesentlichen und wichtigen Einrichtungen auf. Es genehmigt die Maßnahmen, überwacht die Umsetzung, kann bei Nichteinhaltung haftbar gemacht werden und muss Schulungen absolvieren.
• DORA Artikel 5 tut dasselbe für Finanzunternehmen: Das Leitungsorgan definiert, genehmigt, überwacht und bleibt verantwortlich für das IKT-Risikomanagementrahmenwerk, und Rollen und Verantwortlichkeiten für alle IKT-bezogenen Funktionen müssen klar zugewiesen und dokumentiert werden. Ein CISO-Titel ist kein Ersatz – er ist eine der Rollen, die die Zuweisung benennen muss.

Aber ein Vorstandsproblem wird bis Freitagnachmittag zu einem Problem des mittleren Managements. Das Leitungsorgan wird containerd nicht patchen. Es wird nicht entscheiden, ob Audit-Logs von kube-apiserver 12 oder 18 Monate aufbewahrt werden. Es wird nicht in der Planungssitzung sitzen, in der „neuen Mandanten ausliefern“ gegen „wir haben immer noch keine Nachweiskette“ konkurriert. Diese Entscheidungen treffen Engineering-Manager – oder sie werden gar nicht getroffen. Dasselbe Vakuum entsteht in Programmen zum Cyber Resilience Act, die eine härtere Uhr haben.

Artefakte auf das Board legen, nicht Verordnungsnamen

Eine Verordnung ist ein Grund, kein Ticket. „NIS2 Artikel 21“ kann man im Sprint-Review nicht demonstrieren. „kube-apiserver-Audit-Policy ausgeliefert, Logs an das SIEM geliefert, Aufbewahrung dokumentiert“ schon.

Das Artefakt stammt aus einer Rückverfolgbarkeitskette mit einer sauberen Übergabe in der Mitte: Die Schritte eins bis drei (Scope, Kontrollfrage, Nachweisdefinition) gehören zu Risk, Legal und Security; die Schritte vier bis sechs (Artefakt, Sprint-Item, wiederkehrender Betrieb) gehören zu den Plattform- und Anwendungsteams. Die Übergabe ist das Artefakt, nicht die Artikelnummer. Ein Ticket, das „NIS2 Artikel 21(2)(d) umsetzen“ sagt, hat die Mitte der Kette übersprungen und verlangt von einem Ingenieur, als Anwalt zu handeln, der entschieden hat, dass das Gesetz gilt.

Die Kette schließt sich: Schritt sechs erzeugt den Nachweis, den Schritt drei verlangt hat, sodass Lieferergebnisse als Routine an Risk, Audit und SOC zurückfließen – nicht als Feuerwehrübung drei Tage vor einer Prüfung.

So sieht das in der Praxis aus (die Herkunftsspalten verweisen auf Bestimmungen, die das Artefakt relevant machen, nicht auf eine Behauptung, dass der Text diese Umsetzung vorschreibt):

Die Cloud-Native-Projekte, die den Nachweis erzeugen

Keines dieser Artefakte erfordert ein Compliance-Produkt – die Art von Tool, das Nachweise über eine Plattform erzeugt, die es ansonsten nicht berührt. Es sind gewöhnliche Plattformfähigkeiten, und Open Source deckt die meisten davon ab:

• Härteter Image-Katalog & Rebuild-Pipeline – Harbor (Registry), Sigstore (Signieren/Verifizieren), in-toto (Attestierungen), ein Image-Scanner in CI. Das Produkt ist nicht die Pipeline; es ist die Rebuild-Kadenz, die über jedes Basis-Image hinweg aufrechterhalten wird, auch in der Woche, in der die halbe Mannschaft im Urlaub ist. Das Basis-Layer von jemandem zu beziehen, der es Vollzeit pflegt, ist legitim – der Anbieter fällt dann unter NIS2 Art. 21(2)(d) und DORA Art. 28 in den Drittparteien-Scope.
• Secrets als verwalteter Dienst – OpenBao oder Äquivalent, External Secrets Operator zum Einspielen von Secrets, SPIFFE/SPIRE für Workload-Identität, cert-manager für den Zertifikatslebenszyklus. Ein Credential-Pfad: identitätsbasiert, kurzlebig, keine langlebigen Tokens in Manifests.
• Audit- & Erkennungsnachweise – Kubernetes-Audit-Policy, Fluentd/Fluent Bit + OpenTelemetry für die Sammlung, Falco für Laufzeitereignisse, Prometheus für Betriebssignale. Das SIEM am anderen Ende wird meist gekauft; der Sammlungspfad ist Ihrer.
• Admission Control & Ausnahmen – Kyverno oder OPA Gatekeeper plus Kubernetes Pod Security Admission. Policies in der Versionskontrolle, Ausnahmen als Objekte, die ablaufen, statt als Slack-Nachrichten.
• Software-Inventar – SBOM-Erzeugung in CI, als Attestierung neben dem Artefakt gespeichert, nicht in einem Wiki.
• Service-Ownership-Metadaten – Backstage oder Äquivalent, damit „wer ist der Engineering-Manager für diesen Dienst“ maschinenlesbar ist – das macht das RACI real.

Der eigentliche Punkt: Ein Cluster kann Kyverno installiert, Falco laufend und SBOMs in CI haben und trotzdem bei einer Prüfung durchfallen – weil niemand sagen kann, wer entschieden hat, was „akzeptabel“ bedeutet, oder wer dafür verantwortlich ist, dass es so bleibt. Tooling ist die einfache Hälfte.

Ein RACI, das Sprint-Planung überlebt

Sobald die Rückverfolgbarkeitskette existiert, beantwortet das RACI, wer das Artefakt über die Ziellinie bringt und es wahr hält:

Security ist selten Rechenschaftspflichtig für das Artefakt selbst. Ein Secrets-Manager und ein Image-Katalog sind Dienste, die das Plattformteam betreibt, keine Geräte, die Security am Ende darüberstreut.

Drei Zeilen, die es wert sind, ausgeführt zu werden

Erkennung ist nicht Meldung. Incident-Erkennung und Behördenmeldung sind verschiedene Aufgaben mit verschiedenen Uhren. NIS2 Art. 23 erwartet eine Frühwarnung an das CSIRT/die zuständige Behörde innerhalb von 24 Stunden nach Kenntnis eines bedeutenden Vorfalls, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. Wenn Sie den Bereitschaftsingenieur „Eigentümer der NIS2-Meldung“ machen lassen, bekommen Sie um 02:00 Uhr Panik oder Schweigen. Der Ingenieur besitzt die Fakten – was kaputtging, wann, Auswirkungsradius, was getan wurde. Die benannte Kontrollfunktion besitzt die Meldung. Eine Frühwarnung ist eine sachliche Einreichung, keine Ursachenanalyse; Audit-Logs und ein geprobtes Runbook sind das, was die Fakten in Minuten sammelbar macht.

Ausnahmen gehören dem anfordernden Engineering-Manager. Security kann beraten, dass CAP_SYS_ADMIN in einem Produktions-Namespace eine schlechte Idee ist – nur der Manager des anfordernden Teams kann entscheiden, dass das Produktrisiko es wert ist, es aufschreiben und ein Ablaufdatum setzen. Wenn Security Ausnahmen besitzt, wird jede Ausnahme zu einer Verhandlung mit der Person, die alle meiden, und der eigentliche Entscheider bleibt unsichtbar. Den anfordernden Manager rechenschaftspflichtig zu machen, legt die Kosten dorthin, wo der Nutzen liegt, und die Ausnahme bekommt ein natürliches Ablaufdatum: Der Manager, der sie wollte, verlängert sie.

Kapazität ist der Teil, der übersprungen wird. Der nützliche Test in der Planung: Ist das Artefakt im nächsten Sprint mit einem benannten Engineering-Manager, oder ist es immer noch eine Kontrollaussage auf einer Security-Folie? Eine zweite Frage: Wer hält Arbeit mit dem Label „Security“ oder „Compliance“, die nicht seine sein sollte? Scope ehrlich zu kürzen ist besser, als „DORA“ auf eine Folie zu setzen und Ingenieure dazu zu bringen, abends Stunden zu finden.

Security setzt weiterhin die Messlatte – was „restriktiv“ bedeutet, welche CVEs akzeptabel sind, was ein Faktenpaket enthält. Aber Konsultiert muss „antwortet innerhalb desselben Sprints“ bedeuten, nicht „tritt einer Arbeitsgruppe bei“. Teams gehen auf Security zu, wenn Reden mit ihr die Arbeit kleiner macht; sie gehen um sie herum, wenn es das Gegenteil bewirkt.

Fazit

Die Kette ist kurz. Das Leitungsorgan ist im Text rechenschaftspflichtig; der Engineering-Manager ist im Cluster rechenschaftspflichtig; Security ist der Spezialist, den Sie konsultieren; der Ingenieur ist verantwortlich für das Objekt, das ausgeliefert wird. Besetzen Sie nur Leitungsorgan und Security, bekommen Sie Policies und Haftung ohne Kubernetes. Besetzen Sie nur Engineering-Manager und Ingenieur, bekommen Sie eine schnelle Plattform, die Sie einer Aufsicht nicht erklären können.

Wenn das nächste Mal eine Verordnung in den Raum kommt, schauen Sie nicht zuerst auf Security. Schauen Sie auf den Engineering-Manager, der das System besitzt, das die Anforderung beschreibt, und stellen Sie zwei Fragen: welches Artefakt werden Sie demonstrieren, und in welchem Sprint ist es? Wenn es keine Antwort gibt, hat die Organisation keine Sicherheitslücke. Sie hat eine Ownership-Lücke – und die sind die teuren.

Referenzen: Verordnung (EU) 2024/2847 (CRA), Richtlinie (EU) 2022/2555 (NIS2), Verordnung (EU) 2022/2554 (DORA).