Kubernetes in regulierten Branchen: Was du wissen musst

Kubernetes ist in Start-ups und Tech-Unternehmen längst Standard. Doch wie sieht es in Branchen aus, in denen Datenschutz, Regulatorik und Auditierbarkeit keine optionalen Features sind? Krankenhäuser, Banken und Behörden arbeiten unter ganz anderen Voraussetzungen als ein SaaS-Start-up. Wer dort Kubernetes einsetzen möchte, muss von Anfang an anders denken.

Dieser Artikel zeigt, worauf es im Gesundheitswesen, in der Finanzbranche und in der öffentlichen Verwaltung konkret ankommt und wie du von Anfang an die richtigen Weichen stellst.

Was sind regulierte Branchen?

Regulierte Branchen unterliegen besonders strengen gesetzlichen, technischen und organisatorischen Vorgaben.

Dazu gehören unter anderem:

• Gesundheitswesen
• Banken und Finanzdienstleister
• Versicherungen
• öffentliche Verwaltung
• kritische Infrastrukturen
• Energieversorger
• Telekommunikation

Warum regulierte Branchen besondere Anforderungen stellen

In regulierten Umgebungen geht es nicht nur darum, dass die Anwendung läuft. Vielmehr muss nachgewiesen werden können, dass sie sicher läuft – gegenüber Auditoren, Regulatoren und im Zweifelsfall auch vor Gericht.

Das bedeutet in der Praxis:

• Nachvollziehbarkeit: Jede Änderung von Konfigurationen oder Zugriffsrechten muss nachvollziehbar sein.
• Datensouveränität: Personenbezogene oder sicherheitskritische Daten dürfen nur in definierten Regionen gespeichert und verarbeitet werden.
• Verfügbarkeit: SLAs sind keine Wunschliste, sondern eine vertragliche oder gesetzliche Verpflichtung.
• Trennung von Verantwortlichkeiten: Wer deployt, darf nicht gleichzeitig die Produktionsdaten einsehen, auch nicht technisch. Daher muss die Zugriffskontrolle klar geregelt sein.
• Datenschutz: Personenbezogene Daten dürfen nur zweckgebunden verarbeitet werden und müssen technisch vor unbefugtem Zugriff geschützt sein.
• Informationssicherheit: Vertraulichkeit, Integrität und Verfügbarkeit der Systeme sind keine Kür, sondern gesetzliche oder vertragliche Pflicht und müssen durch konkrete technische Maßnahmen nachweisbar sichergestellt werden.
• Dokumentation: Auditoren wollen keine Aussagen, sondern Belege: jede Konfigurationsentscheidung, jedes Zugriffsrecht und jede Änderung am Cluster muss schriftlich dokumentiert sein.
• Risikomanagement: Risiken müssen nicht nur erkannt, sondern auch bewertet, priorisiert und mit konkreten Maßnahmen adressiert werden. Ein informeller „Das haben wir im Blick“-Ansatz reicht in regulierten Umgebungen schlicht nicht aus.

Warum Kubernetes für regulierte Branchen immer wichtiger wird

Kubernetes hat sich von einer modernen Entwicklerplattform zu einer zentralen Infrastrukturtechnologie für Unternehmen entwickelt. Besonders in regulierten Branchen wie dem Gesundheitswesen, dem Finanzsektor oder der öffentlichen Verwaltung wächst das Interesse an containerisierten Plattformen und cloud-nativen Architekturen.

Der Grund dafür liegt auf der Hand: Unternehmen und Behörden müssen heute gleichzeitig:

• hochverfügbare digitale Services bereitstellen,
• sensible Daten schützen,
• regulatorische Anforderungen erfüllen,
• flexibel skalieren und
• Innovationen müssen schneller umgesetzt werden.

Kubernetes bietet hierfür enorme Vorteile. Gleichzeitig steigen jedoch die Anforderungen an Sicherheit, Datenschutz, Governance und Compliance.

Gerade in regulierten Branchen gelten strenge gesetzliche Vorgaben. Fehlkonfigurationen oder Sicherheitslücken können nicht nur finanzielle Schäden verursachen, sondern auch rechtliche Konsequenzen und Vertrauensverlust nach sich ziehen.

Kubernetes im Gesundheitswesen

Regulatorischer Rahmen: DSGVO, DIGA-Anforderungen und mehr

Im Gesundheitswesen sind die Anforderungen besonders hoch. Patientendaten unterliegen nicht nur der DSGVO, sondern zusätzlich dem ärztlichen Berufsgeheimnis sowie, je nach Anwendungsfall, den Anforderungen des Digitale-Versorgung-Gesetzes (DVG) und den Vorgaben des BSI für KRITIS-Betreiber.

Digitalisierung im Healthcare-Bereich

Krankenhäuser, Kliniken und Gesundheitsdienstleister digitalisieren zunehmend ihre Prozesse.

Dazu gehören:

• elektronische Patientenakten
• Telemedizin
• Gesundheitsportale
• mobile Gesundheits-Apps.
• KI-gestützte Diagnostik

Kubernetes hilft dabei, moderne Anwendungen skalierbar bereitzustellen.

Konkret bedeutet dies für den Betrieb von Kubernetes im Gesundheitsbereich:

• Verschlüsselung: Datenverschlüsselung ist Pflicht, sowohl at rest als auch in transit. etcd muss verschlüsselt betrieben werden und TLS muss zwischen allen Cluster-Komponenten verwendet werden.
• Daten in Deutschland: Patientendaten dürfen in der Regel nicht auf Servern außerhalb des EWR gespeichert werden. In der Praxis bevorzugen viele Einrichtungen explizit deutsche Rechenzentren.
• Zugriffskontrolle auf Datenebene: RBAC auf Kubernetes-Ebene reicht nicht aus. Wer auf welche Patientendaten zugreifen darf, muss auf Applikationsebene geregelt und protokolliert sein.
• Audit Trails für Auditoren: Nicht nur technische Ereignisse, sondern auch fachliche Zugriffe auf Patientenakten müssen nachvollziehbar sein.
• Schutz personenbezogener Gesundheitsdaten: Gesundheitsdaten zählen nach Art. 9 DSGVO zu den besonders schützenswerten Datenkategorien. Der Zugriff muss auf das absolut notwendige Minimum beschränkt und technisch durchgesetzt werden, nicht nur organisatorisch geregelt sein.
• Hohe Verfügbarkeit: In der Medizin kann ein Systemausfall die Patientenversorgung direkt gefährden. Kubernetes-Cluster im Gesundheitswesen müssen daher auf Hochverfügbarkeit ausgelegt sein und über redundante Controlplane-Komponenten sowie definierte SLAs verfügen.
• Disaster Recovery: Ein dokumentiertes und regelmäßig getestetes Wiederherstellungskonzept ist Pflicht. Im Ernstfall muss nachweisbar sein, dass Daten vollständig wiederhergestellt werden können und wie lange das dauert (RTO/RPO).

Praxisbeispiel: Telemedizin-Plattform

Eine Telemedizin-Plattform, die Video-Konsultationen und Patientendaten verwaltet, betreibt ihre Services auf Kubernetes. Die kritischen Designentscheidungen: Patientendaten und Metadaten laufen in separaten Namespaces mit strikten Network Policies. Kein Pod außerhalb des patient-data-Namespaces darf direkt auf die Datenbankservices zugreifen. Secrets werden nicht in Kubernetes gespeichert, sondern über einen externen Vault-Service injiziert. Alle API-Calls auf patientenbezogene Endpoints werden in einem zentralen SIEM protokolliert.

Best Practices für Kubernetes im Gesundheitswesen:

Strikte Zugriffskontrollen

Da Zugriffe auf medizinische Daten streng geregelt werden müssen.

Wichtige Maßnahmen:

• RBAC nutzen
• Multi-Faktor-Authentifizierung
• Least-Privilege-Prinzip
• zentraler Identity-Provider

Verschlüsselung sensibler Daten

Sämtliche sensiblen Daten sollten verschlüsselt werden.

• im Ruhezustand
• während der Übertragung
• bei Backups

Netzwerksegmentierung

Medizinische Systeme sollten voneinander isoliert werden.

Mit Kubernetes Network Policies lassen sich:

• Datenflüsse kontrollieren und
• laterale Bewegungen verhindern.

Kubernetes in der Finanzbranche

Regulatorischer Rahmen: MaRisk, DORA und PCI-DSS

Banken, Versicherungen und Zahlungsdienstleister agieren in einem der am dichtesten regulierten Umfelder überhaupt. Neben der DSGVO kommen hier die Mindestanforderungen an das Risikomanagement (MaRisk), der EU Digital Operational Resilience Act (DORA) und bei Zahlungsdaten PCI-DSS ins Spiel.

DORA gilt seit Januar 2025 verbindlich und stellt besondere Anforderungen an die digitale Betriebsresilienz: Finanzunternehmen müssen nachweisen können, dass ihre IT-Systeme, inklusive Cloud-Infrastrukturen und Kubernetes-Cluster, widerstandsfähig gegen Ausfälle und Cyberangriffe sind.

Digitalisierung von Banken und Finanzdienstleistern

Banken modernisieren ihre Anwendungen zunehmend mit cloud-nativen Technologien.

Typische Einsatzbereiche:

• Online-Banking
• Zahlungsplattformen
• Trading-Systeme
• Fraud Detection
• Mobile Banking
• FinTech-Anwendungen

Kubernetes ermöglicht dabei eine schnelle Skalierung und hohe Verfügbarkeit.

Für den Kubernetes-Betrieb bedeutet das konkret:

• Hochverfügbarkeit by Design: Controlplane-Komponenten müssen redundant bereitgestellt werden. Single Points of Failure sind in einem DORA-konformen Setup nicht tolerierbar.
• Change Management: Jede Änderung am Cluster, auch ein Kubernetes-Upgrade, muss dokumentiert, genehmigt und im Nachgang auditierbar sein.
• Supplier Risk Management: Wer Managed Kubernetes nutzt, muss seinen Provider als IT-Dienstleister im Sinne von DORA behandeln. Das schließt regelmäßige Risikoeinschätzungen und vertragliche Absicherungen ein.
• Penetrationstests: DORA verlangt für systemrelevante Institute regelmäßige TLPT (Threat-Led Penetration Tests).
• Continuous Monitoring: Finanzsysteme müssen kontinuierlich überwacht werden. Wichtige Monitoring-Bereiche sind: API-Zugriffe, Netzwerkaktivitäten, Anomalien, Sicherheitsereignisse und Benutzeraktivitäten.
• Sichere CI/CD-Pipelines: CI/CD-Prozesse müssen gegen Manipulation geschützt werden. Dazu gehören signierte Container-Images, automatisierte Security-Scans, Policy-Enforcement und Supply-Chain-Security.
• Hochverfügbare Architekturen: Banking-Systeme benötigen minimale Ausfallzeiten. Kubernetes unterstützt hier mit Multi-Zone-Deployments, automatischer Skalierung, redundanten Services und Self-Healing.
• PCI-DSS: Cardholder-Daten dürfen nur in explizit dafür vorgesehenen, segmentierten Namespaces verarbeitet werden. Network Policies müssen den Traffic zu und von CDE-Komponenten (Cardholder Data Environment) vollständig kontrollieren. Alle Zugriffe auf CDE-Namespaces müssen protokolliert und regelmäßig überprüft werden. Image-Scanning ist Pflicht: Nur geprüfte, signierte Container-Images dürfen in CDE-relevanten Namespaces ausgeführt werden.

Praxisbeispiel: Online-Banking-Plattform

Eine Direktbank, die ihre Online-Banking- und Mobile-App-Services auf Kubernetes betreibt, sieht sich mit klassischen Finanz-Compliance-Anforderungen konfrontiert. PCI-DSS für Zahlungsdaten, DORA für Betriebsresilienz und MaRisk für das interne Risikomanagement. Die kritischen Designentscheidungen:

Zahlungsdaten und Transaktionslogik laufen ausschließlich im dedizierten cde-Namespace (Cardholder Data Environment). Strikte Network Policies verhindern jede direkte Kommunikation mit anderen Namespaces. Zudem werden alle Container-Images vor dem Deployment automatisch auf Schwachstellen gescannt und nur signierte Images aus der internen Registry zugelassen. Secrets wie API-Keys zu Zahlungsdienstleistern werden nie in Kubernetes gespeichert, sondern zur Laufzeit aus einem gehärteten Vault-Service injiziert. Sämtliche Zugriffe auf den CDE-Namespace fließen in Echtzeit in das zentrale SIEM – inklusive automatischer Alerts bei ungewöhnlichen Zugriffsmustern.

Best Practices für Kubernetes in der Finanzbranche

Strikte Netzwerksegmentierung

Finanzdaten und Zahlungsprozesse müssen von allen anderen Workloads isoliert sein.

Mit Kubernetes Network Policies lassen sich:

• Cardholder Data Environments strikt abschotten.
• Laterale Bewegungen nach einem initialen Einbruch verhindern.

Lückenlose Auditierbarkeit

Regulatoren wie die BaFin und Auditoren für PCI-DSS erwarten vollständige Nachvollziehbarkeit.

Wichtige Maßnahmen:

• Kubernetes Audit Logging aktivieren und zentral aggregieren.
• Alle Zugriffe auf finanzrelevante Namespaces protokollieren.
• Log-Aufbewahrung gemäß regulatorischer Vorgaben (MaRisk: mind. 5 Jahre).
• Regelmäßige Reviews der Audit Trails einplanen.

Change Management und GitOps

Jede Änderung am Cluster muss dokumentiert, genehmigt und nachvollziehbar sein, denn das ist in DORA und MaRisk explizit gefordert.

In der Praxis bedeutet das:

• Alle Konfigurationsänderungen laufen über Git-Commits.
• Kein manueller Zugriff auf Produktions-Namespaces.
• Deployments werden über ArgoCD oder Flux gesteuert und sind vollständig auditierbar.

Supply-Chain-Security

In der Finanzbranche ist die Frage, was im Container läuft, keine rhetorische.

Wichtige Maßnahmen:

• Automatisches Image-Scanning auf bekannte CVEs vor jedem Deployment.
• Image-Signing mit Cosign/Sigstore als Pflichtschritt in der CI/CD-Pipeline.
• Software Bill of Materials (SBOM) für alle produktiven Container-Images.
• Nur Images aus der eigenen, gehärteten Registry zulassen.

Kubernetes in der öffentlichen Verwaltung

Regulatorischer Rahmen: BSI-Grundschutz und EVB-IT

Behörden und öffentliche Einrichtungen in Deutschland orientieren sich am BSI-Grundschutz, einem der umfassendsten Sicherheitsrahmenwerke überhaupt. Wer Kubernetes für Verwaltungsanwendungen betreibt, muss den Cluster gegen die entsprechenden Bausteine absichern und dies im Rahmen eines Information Security Management Systems (ISMS) dokumentieren.

Hinzu kommen vergaberechtliche Anforderungen. Cloud-Dienste für die öffentliche Hand müssen bestimmte Zertifizierungen nachweisen, etwa C5 (Cloud Computing Compliance Criteria Catalogue) des BSI oder ISO 27001.

Digitale Behörden und E-Government

Behörden modernisieren zunehmend ihre IT-Systeme.

Beispiele:

• Bürgerportale
• Online-Anträge
• Registersysteme
• Verwaltungsplattformen

Kubernetes ermöglicht eine flexiblere und effizientere Bereitstellung dieser Anwendungen.

Praktische Konsequenzen für den Kubernetes-Betrieb:

• Kein Public-Cloud-Hyperscaler ohne Prüfung: Für viele Verwaltungsanwendungen ist die Datenhaltung bei US-amerikanischen Anbietern aus rechtlichen Gründen problematisch. Deutsche oder europäische Anbieter mit nachgewiesener C5-/ISO-Zertifizierung sind hier klar im Vorteil.
• Strikte Netzwerktrennung: Verwaltungsanwendungen, die mit Bürgerdaten arbeiten, dürfen keinen gemeinsam genutzten Netzwerk-Layer mit anderen Applikationen haben.
• Dokumentationspflichten: Der BSI-Grundschutz erfordert eine umfangreiche Systemdokumentation, die alle Kubernetes-Konfigurationen, RBAC-Einstellungen und Netzwerkpolicies umfasst.
• Open Source: Open Source-Lösungen werden bevorzugt, um Herstellerabhängigkeiten zu vermeiden und den Quellcode prüfen zu können.
• IT-Sicherheit: Kubernetes-Cluster in Behörden müssen gegen den BSI-Grundschutz gehärtet und regelmäßig auf Schwachstellen geprüft werden, da sich Bedrohungslagen und Anforderungen kontinuierlich weiterentwickeln und ein einmaliges Setup nicht ausreicht.
• Verfügbarkeit: Verwaltungsanwendungen, die Bürger oder interne Prozesse bedienen, dürfen nicht einfach ausfallen. Hochverfügbare Controlplane-Architekturen und definierte SLAs sind im öffentlichen Sektor daher eine Betriebsvoraussetzung.
• Transparenz: Behörden sind gegenüber Aufsichtsbehörden, Rechnungshöfen und im Zweifel auch der Öffentlichkeit rechenschaftspflichtig. Alle Cluster-Konfigurationen, Zugriffsrechte und Änderungen müssen daher jederzeit einsehbar und verständlich dokumentiert sein.

Praxisbeispiel: Digitales Bürgerportal einer Stadtverwaltung

Eine mittelgroße Stadtverwaltung betreibt ihr digitales Bürgerportal inklusive Online-Anträgen, Dokumentenmanagement und interner Fachanwendungen auf Kubernetes. Die Anforderungen: BSI-Grundschutz, DSGVO-Konformität und eine Zertifizierung nach ISO 27001.

Die kritischen Designentscheidungen: Bürgeranwendungen und interne Fachanwendungen laufen in strikt getrennten Namespaces. Kein Pod aus dem öffentlich erreichbaren Portal-Namespace darf direkt mit internen Verwaltungssystemen kommunizieren. Zudem basieren alle eingesetzten Container-Images ausschließlich auf Open Source-Komponenten und werden in einer selbst betriebenen, internen Registry verwaltet, um Abhängigkeiten von externen Anbietern zu minimieren. Konfigurationsänderungen am Cluster sind ausschließlich über einen GitOps-Prozess möglich – jede Änderung ist einem Ticket, einem Bearbeiter und einem Zeitstempel zugeordnet und damit vollständig revisionssicher. Alle Cluster-Logs fließen in ein zentrales Logging-System, das die gesetzlichen Aufbewahrungsfristen automatisch durchsetzt und das sich jederzeit für externe Prüfungen durch den Rechnungshof auswerten lässt.

Best Practices für Kubernetes in Behörden

Private oder Sovereign Cloud

Viele Behörden setzen auf:

• On-Premises-Kubernetes
• Private Clouds
• Sovereign-Cloud-Konzepte

Dadurch bleibt die Datenhoheit erhalten.

Starke Governance-Strukturen

Kubernetes benötigt klare organisatorische Regeln.

Wichtige Bereiche:

• Rollenmodelle
• Sicherheitsrichtlinien
• Auditierung
• Freigabeprozesse
• Compliance-Kontrollen

Langfristige Wartbarkeit

Behördliche Systeme müssen oft über viele Jahre hinweg betrieben werden.

Daher sind folgende Punkte wichtig:

• standardisierte Plattformen
• dokumentierte Prozesse
• automatisierte Updates
• Lifecycle-Management

Was alle drei Branchen gemeinsam haben

Trotz aller Unterschiede gibt es branchenübergreifende Muster, die jede regulierte Kubernetes-Umgebung erfüllen sollte.

Namespace-Strategie als Fundament:

Die Namespace-Struktur ist nicht nur eine organisatorische, sondern auch eine Sicherheitsentscheidung. In regulierten Umgebungen empfiehlt sich vor allem eine fachliche und regulatorische Trennung: Workloads mit unterschiedlichem Schutzbedarf – etwa Patientendaten, Zahlungsinformationen oder öffentlich erreichbare Dienste – sollten in eigenen Namespaces mit jeweils eigenen RBAC-Richtlinien, Network Policies und Resource Quotas laufen. So lässt sich der Zugriff gezielt einschränken, der Datenfluss zwischen Bereichen kontrollieren und im Audit-Fall klar nachweisen, welche Workloads unter welche Compliance-Anforderungen fallen.

Immutable Infrastructure und nachvollziehbare Deployments:

In regulierten Umgebungen darf niemand manuell in laufende Container eingreifen. Alle Änderungen laufen über Git. GitOps-Werkzeuge wie ArgoCD oder Flux stellen sicher, dass der Cluster-State mit dem Repository übereinstimmt und jede Änderung einem Commit zugeordnet werden kann. Dies ist keine Best Practice, sondern in vielen Regulatoriken explizit gefordert.

Supply Chain Security:

Woher kommt das Container-Image, das gerade in deinem Cluster läuft? In regulierten Umgebungen ist das keine rhetorische Frage. Image-Signing (z. B. mit Cosign/Sigstore), eine Software Bill of Materials (SBOM) und automatisiertes Vulnerability-Scanning sind keine Extras, sondern die Grundlage eines nachweisbaren Sicherheitsniveaus.

Zentrales Logging und SIEM-Integration:

Kubernetes-native Audit Logs sind ein guter Anfang. In regulierten Umgebungen müssen diese Logs aber in ein zentrales SIEM fließen, dort über einen Zeitraum von 6 bis 12 Monaten oder länger aufbewahrt und regelmäßig ausgewertet werden. Tools wie Prometheus und Grafana helfen beim operativen Monitoring. Für compliance-relevantes Logging braucht es darüber hinaus aber eine durchdachte Aggregations- und Archivierungsstrategie.

Die Frage des Betriebs lautet: Selbst oder Managed?

In einer regulierten Branche stellt sich oft die Frage: Kubernetes selbst betreiben oder einen Managed Service nutzen?

„Selbst betreiben” bedeutet volle Kontrolle, aber auch volle Verantwortung. CVE-Patches, Kubernetes-Upgrades, Backup-Strategien, Node-Hardening: Das ist ein Fulltime-Job – selbst für erfahrene Teams.

Ein Managed-Kubernetes-Service nimmt einen Teil dieser Verantwortung ab – aber nur dann, wenn der Anbieter auch die regulatorischen Anforderungen erfüllt. Relevante Fragen an einen potenziellen Provider sind:

• Wo stehen die Rechenzentren? (Deutschland/EU)
• Welche Zertifizierungen liegen vor? (ISO 27001, C5, BSI)
• Wie werden Kubernetes-Upgrades durchgeführt und wer informiert wen?
• Gibt es eine dokumentierte Shared-Responsibility-Matrix?
• Kann ich meinen Cluster vollständig auditieren?

NWS betreibt NETWAYS Managed Kubernetes® ausschließlich in deutschen Rechenzentren, ist ISO-zertifiziert und DSGVO-konform. Kunden behalten die volle Kontrolle über ihre Deployments, während NWS die Cluster-Infrastruktur, Updates und Verfügbarkeit übernimmt.

Vorteile:

• automatisierte Updates
• integrierte Sicherheitsfunktionen
• geringerer Betriebsaufwand
• schnellere Skalierung

Fazit

Kubernetes in regulierten Branchen ist kein Widerspruch, erfordert aber mehr als als traditionelle Setups. Ob Patientendaten, Zahlungsinformationen oder Behördendaten: Die Anforderungen an Nachvollziehbarkeit, Datensouveränität und Sicherheit lassen sich mit Kubernetes umsetzen, wenn von Anfang an die richtigen Entscheidungen getroffen werden.

Eine Namespace-Strategie, RBAC, Audit Logging, Supply-Chain-Security und ein Provider, der die regulatorischen Rahmenbedingungen versteht, sind die Bausteine eines Clusters, der nicht nur läuft, sondern auch auditierbar ist. Je früher diese Weichen gestellt werden, desto weniger schmerzhaft wird der erste Audit.

In welcher Branche betreibst du Kubernetes und welche Compliance-Anforderung bereitet dir die größten Schwierigkeiten? Schreib es in die Kommentare oder melde dich direkt bei uns. Wir kennen die Tücken regulierter Umgebungen aus der Praxis.