Kubernetes in Banken: 6 Lehren aus regulierten Projekten

Gastbeitrag aus der Praxis: Dieser Artikel stammt von Pexon Consulting, dem Betreiber dieser Seite und selbst Kubernetes-Dienstleister. Er beschreibt eigene Projekte und Erfahrungen und ist nicht Teil unserer neutralen Vergleiche.

TL;DR

Kubernetes in Banken scheitert selten an der Technik, sondern am Nachweis: Wer hat wann was im Cluster geändert, wer hatte Zugriff, wann wurde der Wiederanlauf geprobt? Wir bei Pexon sehen in regulierten Projekten immer dieselben Lücken. DORA Artikel 30, das Informationsregister und der Audit-Trail entscheiden, nicht die Wahl der Plattform.

Was macht Kubernetes in Banken anders als im übrigen Mittelstand?

Der Unterschied liegt nicht im Cluster, sondern in der Beweislast. Eine Bank muss gegenüber interner Revision und BaFin jede Entscheidung erklären können, und seit DORA landet diese Pflicht über den Vertrag auch beim Dienstleister. Ein Cluster, der seit Jahren stabil läuft, aber keine Änderungshistorie führt, ist für eine Prüfung wertlos.

Dieser Beitrag ist ein gekennzeichneter Praxisbericht von Pexon Consulting, dem Betreiber dieser Seite. Wir beschreiben, was wir in regulierten Kubernetes-Projekten gelernt haben, mit den Zahlen, die wir auf pexon-consulting.de veröffentlicht haben. Eine Rechtsberatung ist das nicht: Ob DORA oder NIS2 für Ihr Haus gilt, klärt Ihre Rechtsabteilung.

Die Rechtslage, die wir in jedem Projekt zuerst auf den Tisch legen:

Regelwerk	Stand	Was es für den Cluster bedeutet
DORA, Verordnung (EU) 2022/2554	gilt seit 17.01.2025 (EUR-Lex, Art. 64)	Verträge, Informationsregister, jährliche Tests der Wiederherstellungspläne
BAIT	vollständig aufgehoben mit Ablauf des 31.12.2026 (Bundesbank)	gilt nur noch für Institute außerhalb des DORA-Anwendungsbereichs
VAIT, KAIT, ZAIT	aufgehoben mit Ablauf des 16.01.2025	ersetzt durch DORA
NIS2 über das BSIG	verkündet im BGBl. 2025 I Nr. 301 vom 05.12.2025	Risikomanagement und Nachweise für betroffene Einrichtungen
BSI C5	Kriterienkatalog, 2025/26 grundlegend überarbeitet (BSI)	Maßstab für die Konfiguration, Testat nur durch Wirtschaftsprüfer

Zwei Referenzen prägen unsere Sicht. Für eine Genossenschaftsbank haben wir eine Kubernetes-Plattform auf Azure AKS aufgebaut, Projektvolumen 102.700 EUR; der Kundenname ist bis zur Freigabe anonymisiert. Und für einen Top-10-Genossenschaftsversicherer betreuen wir seit September 2022 eine Kubernetes-Plattform im eigenen Rechenzentrum, mit Rancher und Spinnaker, für mehr als 30 interne Entwicklerteams (Case Study).

Lehre 1: Der Fragebogen kommt vor der Prüfung

Den ersten Druck erzeugt fast nie die Aufsicht selbst, sondern ein Fragebogen. Ein Bankkunde muss nach DORA Artikel 30 Mindestinhalte in jedem IKT-Vertrag regeln und fragt diese bei seinem Dienstleister ab. Gefragt wird nicht, ob der Cluster läuft, sondern wo er läuft, wer ihn ändert und wie man wieder herauskommt.

Artikel 30 Absatz 2 DORA zählt neun Mindestinhalte auf, Buchstabe a bis i. Für den Kubernetes-Betrieb sind vier davon unmittelbar relevant. Wir übersetzen sie in jedem Projekt in Betriebsfragen:

DORA-Fundstelle	Inhalt laut Verordnung	Beleg aus dem Cluster
Art. 30 Abs. 2 lit. b	Standorte, Regionen oder Länder, an denen Daten verarbeitet und gespeichert werden	Liste der Regionen für Nodes, Persistent Volumes und Backups
Art. 30 Abs. 2 lit. d	Zugang zu Daten bei Beendigung, Rückgabe in leicht zugänglichem Format	dokumentierter Exportweg, Datenformate
Art. 30 Abs. 3 lit. c	Notfallpläne implementieren und testen	Protokoll einer DR-Übung
Art. 30 Abs. 3 lit. e und f	Zugangs-, Inspektions- und Auditrechte, Ausstiegsstrategien	Prüfzugänge, beschriebener Übergabepfad

Absatz 3 gilt zusätzlich, wenn Ihr Dienst eine kritische oder wichtige Funktion der Bank stützt. Diese Einstufung trifft die Bank, nicht der Dienstleister, und wir vermuten sie bewusst nicht. Wir trennen den Fragebogen in der ersten Woche in drei Stapel: Vertragsfragen, Betriebsfragen und Rechtsfragen für die Anwälte des Kunden.

Lehre 2: Der 31. Dezember ist der eigentliche Stichtag

Das Informationsregister nach Artikel 28 Absatz 3 DORA muss den Stand zum 31. Dezember des Vorjahres zeigen. Die Bank reicht es jährlich bis spätestens 31. März bei der BaFin ein. Ihre Betriebsangaben müssen also zum Jahreswechsel stimmen, nicht erst im März. Für das Register 2027 bleiben damit noch zwölf Wochen.

Die BaFin formuliert es klar: Der Einreichungsprozess muss bis 31. März vollständig und fehlerfrei durchlaufen sein, und das Register gibt den Sachstand zum 31. Dezember des vergangenen Jahres wieder. Die Daten nutzt die Aufsicht, um Konzentrationsrisiken zu erkennen, und leitet sie an die europäischen Aufsichtsbehörden weiter.

Was wir regelmäßig sehen: Dienstleister lesen den 31. März als ihre eigene Frist, obwohl es die Frist der Bank ist, und starten kurz vor dem Stichtag eine Sammelaktion. Unsere Konsequenz ist eine Betriebsliste, die wir im Retainer monatlich fortschreiben: Wo laufen die Nodes, wo liegen die Backups, wer sind die Vorlieferanten. Ehrlich gesagt: Ein Muster dieser Liste veröffentlichen wir noch nicht, weil sie gerade erst als Standard entsteht.

Lehre 3: Ohne Audit-Log gibt es keine Änderungshistorie

Eine typische Lücke ist banal: Der Kubernetes-API-Server protokolliert nicht, wer was geändert hat. Ohne Audit-Policy schreibt kube-apiserver keine Audit-Events. Die erste Maßnahme in jedem regulierten Cluster ist deshalb eine Audit-Policy, die mindestens Metadaten aller Anfragen erfasst: Nutzer, Zeitstempel, Ressource, Verb.

Die Kubernetes-Dokumentation kennt vier Stufen: None, Metadata, Request und RequestResponse. Ohne --audit-policy-file werden keine Events geloggt. Eine minimale Policy für selbst betriebene Cluster, etwa mit Rancher on-premises:

# audit-policy.yaml: Metadaten für alle Anfragen,
# Request-Body für Änderungen an RBAC und Secrets
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
        resources: ["events"]
  - level: Request
    resources:
      - group: "rbac.authorization.k8s.io"
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata

Der Log-Backend wird über Flags am API-Server gesteuert:

kube-apiserver \
  --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
  --audit-log-path=/var/log/kubernetes/audit.log \
  --audit-log-maxage=30 \
  --audit-log-maxbackup=10 \
  --audit-log-maxsize=100

Bei Managed Kubernetes setzen Sie die API-Server-Flags nicht selbst. Auf AKS aktivieren Sie stattdessen die Diagnosekategorien kube-audit oder kube-audit-admin; Letztere lässt get- und list-Events weg, was laut Microsoft Learn die oft erheblichen Log-Kosten senkt. Wichtig ist bei Secrets die Stufe Metadata: Mit Request würde der Secret-Inhalt im Log landen. Die Aufbewahrungsdauer setzen wir nicht im Cluster, sondern im zentralen Log-Speicher, weil Node-Platten keine Archivierung sind.

Lehre 4: Freigaben gehören in die Pipeline, nicht in die Mail

Beim Genossenschaftsversicherer waren Release-Freigaben vorher manuell und undokumentiert, Security-Scans liefen ad hoc außerhalb der Pipeline. Heute hat jedes produktiv genutzte Container-Image einen dokumentierten Approval-Pfad mit Test- und Scan-Belegen. Das ist der Nachweis, den Revision und Prüfer zuerst sehen wollen.

Der Kunde betreibt eine eigene On-Premise-Cloud, weil BaFin-Vorgaben (damals VAIT), MaRisk und DSGVO einen schnellen Wechsel in die Public Cloud politisch und regulatorisch blockierten. Wir arbeiten dort im CI/CD-Enablement-Team. Der Aufbau in vier Schritten:

Rancher als Management-Schicht über Dev-, Staging- und Produktions-Clustern, mit Helm-basierten Deployments und getrennten Verantwortlichkeiten pro Umgebung.
Spinnaker als Delivery-Layer für Pipelines über Cluster-Grenzen hinweg.
Eigener Audit-Service: sammelt Metadaten zu jedem Image-Build, führt die Freigabe durch den Product Owner zusammen und schiebt freigegebene Images in eine dedizierte Release-Registry. Prisma Cloud, OWASP-CVE-Datenbank und SonarQube sind in die Pipeline integriert.
Parallele Proof of Concepts mit Azure Landing Zones, ArgoCD und GitHub Actions, damit der Weg in die Cloud offen bleibt, ohne Big-Bang-Migration.

Die Lehre daraus: Eine getrennte Release-Registry ist ein einfacher technischer Hebel. Was nicht dort liegt, kommt nicht in Produktion, und jedes Image dort hat einen Freigabe-Datensatz. Wie Rancher Prime und die Open-Source-Variante sich für solche On-Premise-Setups unterscheiden, zeigt unser Beitrag zu SUSE Rancher Prime. Spinnaker-Expertise ist am deutschen Markt übrigens selten verfügbar; wer das Werkzeug wählt, sollte das bei der Teamplanung bedenken.

Lehre 5: Der Plattformanbieter liefert nicht Ihren Nachweis

Ein C5-Testat des Cloud-Anbieters belegt dessen Infrastruktur, nicht Ihre Konfiguration darauf. Das ist ein Missverständnis, das wir in regulierten Häusern regelmäßig hören. Der Wirtschaftsprüfer testiert die Plattform, das ISMS-Haus liefert das Konzept, und den Nachweis über den Betrieb dazwischen liefert ohne klare Zuständigkeit niemand.

Wer welchen Beleg liefert, ordnen wir so:

Nachweis	ISMS-Beratung	Plattformanbieter	Betreiber des Clusters
Konzept, Richtlinie, Risikoanalyse	ja	nein	setzt darauf auf
C5-Testat	begleitet die Vorbereitung	für die eigene Infrastruktur, je nach Anbieter	kein eigenes Testat
Konfiguration gegen CIS-Benchmark	nein	nein	Konfigurations-Report
Änderungshistorie, Zugriffsnachweise	nein	Rohdaten und Logs	aufbereiteter Audit-Trail

Welche Managed-Kubernetes-Anbieter in Deutschland ein C5-Testat haben und ob der Kubernetes-Dienst im Scope liegt, zeigt der neutrale Vergleich Managed Kubernetes Deutschland. Den Betriebsnachweis führen wir mit Konfigurations-Report gegen den CIS-Benchmark, Änderungshistorie mit Zeitstempel und Verantwortlichen sowie Zugriffsnachweisen für Cluster und Registry. Wir selbst sind keine Prüfstelle und erteilen kein Siegel.

Lehre 6: Der Wiederanlauf zählt erst, wenn er geprobt ist

DORA Artikel 11 Absatz 6 verlangt, Geschäftsfortführungs- sowie Reaktions- und Wiederherstellungspläne mindestens jährlich zu testen, außerdem bei wesentlichen Änderungen an Systemen für kritische Funktionen. Ein beschriebener Wiederanlauf ist kein getesteter. Das Protokoll der Übung ist der Nachweis.

Unsere DR-Übung läuft so ab:

Szenario und Abnahmekriterium vorab festlegen, etwa Verlust eines Clusters mit Wiederherstellung aus Backup in einer zweiten Region.
Im echten Cluster üben, nicht am Modell: Ausfall simulieren, Wiederherstellung fahren.
Zeiten messen und mit den vereinbarten Zielen vergleichen.
Abweichungen protokollieren, inklusive der Schritte, die nicht dokumentiert waren.

Die Frage, wann der Wiederanlauf zuletzt geprobt wurde, steht in fast jedem Fragebogen, den wir sehen. Cluster, die seit Jahren unauffällig laufen, haben darauf oft keine belegbare Antwort. Abweichungen gehören deshalb ehrlich ins Protokoll: Sie zeigen dem Prüfer, dass die Übung echt war und was danach verbessert wurde.

Was kostet ein nachweisfähiger Kubernetes-Betrieb bei Pexon?

Wir arbeiten in Bausteinen auf einem laufenden Betrieb: Einstieg ist eine kostenlose SLA-Gap-Analyse von 60 Minuten, der laufende Nachweis-Betrieb kostet 1.500 bis 3.000 EUR im Monat je Cluster-Umgebung, eine DR-Übung 2.000 bis 4.000 EUR. Eine vorkonfigurierte AKS-Landing-Zone für Banken beginnt ab 75.000 EUR.

Baustein	Preis (netto, Stand 19.08.2026 bzw. 20.08.2026)	Inhalt
SLA-Gap-Analyse	kostenlos, 60 Minuten	Ist-Aufnahme, Abgleich mit Prüf- und Kundenanforderungen
NIS2-/C5-Modul	1.500 bis 3.000 EUR pro Monat	monatlicher Audit-Trail für NIS2 und DORA, Konfiguration gegen C5-Kriterien, Audit-Support
DR-Übung	2.000 bis 4.000 EUR je Übung	Szenario, Übung im echten Cluster, Protokoll
DORA-Blueprint AKS	ab 75.000 EUR	Gap-Analyse, AKS Private Cluster, Azure Policy, Network Policies, Image Scanning, Audit-Dokumentation

Quellen sind unsere Seiten zu Kubernetes-Compliance, zum DORA-Fragebogen und zur AKS-Landing-Zone. Für einen Fragebogen rechnen wir mit Woche 1 für die Durchsicht, Woche 2 bis 3 für die Bestandsaufnahme und Woche 4 bis 8 für das Schließen der Lücken. Danach läuft der Audit-Trail monatlich. Die Servicezeit ist Montag bis Freitag, 08:00 bis 18:00 Uhr MEZ; Verfügbarkeitsprozente sagen wir in diesem Modul nicht zu.

Offen benannt: Das Nachweis-Paket mit Konfigurations-Report, Änderungshistorie und Zugriffsnachweisen entsteht gerade, ein Muster zeigen wir erst nach Abnahme. Unser Abnahmekriterium ist streng: Fertig ist es erst, wenn Ihre Compliance-Verantwortlichen eine Prüferfrage zum Cluster aus den Unterlagen beantworten können, ohne bei uns anzurufen. Wer KI-Inferenz auf demselben Cluster plant, findet die Erfahrungen dazu in unserem Praxisbericht KI auf Kubernetes betreiben; wie wir dort nachweisen, welches Team wann eine GPU hielt, steht im Praxisbericht zu GPU-Quotas mit Kueue.

FAQ

Muss eine Bank ihren Kubernetes-Cluster wegen DORA umziehen?

Nein. DORA schreibt keine bestimmte Plattform vor, sondern Verträge, Register, Tests und Nachweise. Nachweisfähig wird der Betrieb, nicht die Plattform darunter. Ein bestehender Cluster auf AKS, auf einem deutschen Anbieter oder on-premises kann bleiben, wenn Regionen, Zugriffe, Änderungen und Wiederherstellungen belegt sind.

Was kostet ein DORA-fähiger Kubernetes-Betrieb?

Bei Pexon kostet der laufende Nachweis-Betrieb 1.500 bis 3.000 EUR im Monat je Cluster-Umgebung, eine DR-Übung 2.000 bis 4.000 EUR, jeweils netto, Stand August 2026. Die Kosten für Cluster und Compute zahlen Sie getrennt an Ihren Anbieter. Eine AKS-Landing-Zone für Banken beginnt ab 75.000 EUR einmalig.

C5-Testat vs. C5-konformer Betrieb: Was ist der Unterschied?

Ein C5-Testat erteilt ein Wirtschaftsprüfer, beauftragt vom Cloud-Anbieter, für dessen Infrastruktur. Ein C5-konformer Betrieb heißt, dass Ihre Konfiguration auf dieser Infrastruktur nach den C5-Kriterien geführt und belegt wird. Das eine ersetzt das andere nicht; ein Betriebsdienstleister kann kein Testat ausstellen.

Gilt DORA für uns, wenn wir keine Bank sind?

Direkt verpflichtet sind Finanzunternehmen. Wer sie mit Software oder Betrieb beliefert, wird als IKT-Drittdienstleister über deren Vertrag erfasst und bekommt den Fragebogen. Ob Ihr Dienst eine kritische oder wichtige Funktion stützt, entscheidet Ihr Finanzkunde. Ob Sie zusätzlich unter NIS2 fallen, ist eine Rechtsfrage für Ihre Anwälte.

Wann muss das DORA-Informationsregister bei der BaFin sein?

Jährlich bis spätestens 31. März, vollständig und fehlerfrei durchlaufen. Inhaltlich zeigt es den Stand zum 31. Dezember des Vorjahres. Für Dienstleister heißt das: Regionen, Subunternehmer und Dienste müssen zum Jahreswechsel aktuell vorliegen, damit die Bank sie übernehmen kann.

Was gilt nach dem Auslaufen der BAIT?

Die BAIT werden mit Ablauf des 31. Dezember 2026 vollständig aufgehoben. Schon jetzt sind alle Institute ausgenommen, die ein IKT-Risikomanagement nach DORA betreiben müssen. VAIT, KAIT und ZAIT sind seit dem 16. Januar 2025 aufgehoben. Maßstab für den Cluster ist damit DORA, ergänzt um BSI C5 als Kriterienkatalog.

Quellen

Pexon: Kubernetes-Compliance NIS2, DORA, C5 (abgerufen 8. Oktober 2026)
Pexon: DORA-Compliance im Fragebogen vom Bankkunden (abgerufen 8. Oktober 2026)
Pexon: DORA im Kubernetes-Betrieb, AKS-Landing-Zone für Banken (abgerufen 8. Oktober 2026)
Pexon Case Study: On-Premise Kubernetes für einen Genossenschaftsversicherer (abgerufen 8. Oktober 2026)
EUR-Lex: Verordnung (EU) 2022/2554 (DORA) (abgerufen 8. Oktober 2026)
BaFin: Informationsregister und Anzeigepflichten (abgerufen 8. Oktober 2026)
Deutsche Bundesbank: BAIT / DORA (abgerufen 8. Oktober 2026)
Bundesgesetzblatt: BGBl. 2025 I Nr. 301 (NIS-2-Umsetzung) (abgerufen 8. Oktober 2026)
BSI: Kriterienkatalog C5 (abgerufen 8. Oktober 2026)
Microsoft Learn: Monitor AKS (kube-audit) (abgerufen 8. Oktober 2026)
Kubernetes Docs: Auditing (abgerufen 8. Oktober 2026)