Kubernetes unter NIS2, DSGVO und BSI C5: Was IT-Entscheider jetzt tun müssen

Die Regulierungswelle ist da. Die EU-Umsetzungsfrist für NIS2 lief im Oktober 2024 ab, das deutsche Umsetzungsgesetz (NIS2UmsuCG) ist seit Dezember 2025 in Kraft, BSI C5 wird im Beschaffungswesen und bei Audits zunehmend zum Prüfungsmaßstab, und die DSGVO-Bußgeldpraxis der Aufsichtsbehörden wird konkreter. Das Problem: Die meisten Kubernetes-Umgebungen, die wir in unseren Projekten antreffen, wurden nicht mit diesen Anforderungen gebaut. Das ist kein Vorwurf — Kubernetes wurde in vielen Unternehmen vor zwei, drei Jahren eingeführt, weil es technisch sinnvoll war. Compliance war damals maximal ein Randthema. Heute ist es ein Entscheidungsthema.

Was konkret auf Ihre Kubernetes-Infrastruktur zukommt, welche Lücken in der Praxis am häufigsten auftreten, und wie ein compliance-fähiges Setup tatsächlich aussieht — das beschreiben wir in diesem Artikel.

Ein Grundsatz vorweg, der sich durch den ganzen Text zieht: Gesetze und Prüfstandards definieren Schutzziele und einen risikobasierten Rahmen — sie schreiben keine konkreten Produkte oder Architekturen vor. Kubernetes, GitOps, Kyverno, Vault oder Sentinel sind mögliche, oft besonders geeignete technische Umsetzungen dieser Ziele, nicht selbst gesetzliche Pflicht. Wir schreiben hier aus der Projektpraxis, nicht als Rechtsberatung.

Was NIS2, BSI C5 und DSGVO konkret für Kubernetes bedeuten

NIS2: Mehr Unternehmen, mehr Pflichten, härtere Haftung

Die NIS2-Richtlinie (Network and Information Security Directive 2) hat den Kreis der betroffenen Unternehmen gegenüber ihrer Vorgängerin deutlich ausgeweitet. Betroffen sind Einrichtungen aus einer Vielzahl der in den Anlagen 1 und 2 des BSI-Gesetzes aufgeführten Sektoren und Einrichtungsarten — darunter Energie, Transport, Gesundheit, digitale Infrastruktur, Finanzmarktinfrastruktur, Maschinenbau und Lebensmittel.

Ob ein Unternehmen tatsächlich fällt, hängt von der konkreten Einrichtungsart, dem Sektor sowie Mitarbeiterzahl, Jahresumsatz und teilweise der Jahresbilanzsumme ab. Für viele „wichtige Einrichtungen“ liegt die Größenordnung bei mindestens 50 Beschäftigten oder mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme; für „besonders wichtige Einrichtungen“ gelten teils höhere Schwellen oder besondere Zuordnungsregeln, und einzelne Einrichtungsarten sind unabhängig von der Größe erfasst. Die Einordnung sollte deshalb im Einzelfall geprüft werden.

Für Kubernetes-Betreiber relevant sind vor allem die Anforderungen an:

• Risikomanagement für Netzwerk- und Informationssysteme: Kubernetes- und Container-Umgebungen können zu den Systemen gehören, die für die Erbringung der betroffenen Dienste relevant sind — dann müssen sie ins Risikomanagement der Einrichtung. Werden Komponenten kompromittiert und führt das zu einem erheblichen Sicherheitsvorfall, greifen die Meldepflichten. Ungepatchte Images oder zu weit gefasste RBAC-Konfigurationen sind dagegen zunächst Schwachstellen bzw. Risiken, die das Risikomanagement adressieren muss — nicht automatisch meldepflichtige Vorfälle.
• Meldepflichten: Für erhebliche Sicherheitsvorfälle gilt eine gestufte Meldekette — Erstmeldung spätestens nach 24 Stunden, qualifizierte Meldung nach 72 Stunden, Abschlussmeldung grundsätzlich einen Monat nach der 72-Stunden-Meldung (dauert der Vorfall noch an, tritt zunächst eine Fortschrittsmeldung an ihre Stelle). Ohne zentrales Logging, Monitoring und definierte Eskalationsprozesse wird es in komplexen Kubernetes-Umgebungen erheblich schwieriger, Vorfälle rechtzeitig zu erkennen, zu bewerten und fristgerecht zu melden.
• Haftung der Geschäftsführung: Die Leitungsebene muss die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen — und sich regelmäßig schulen lassen. Bei schuldhafter Pflichtverletzung kann eine persönliche Innenhaftung gegenüber der eigenen Einrichtung nach den gesellschaftsrechtlichen Regeln entstehen. Keine automatische persönliche Haftung für jeden Cybervorfall — aber eine andere Qualität als bisherige IT-Compliance-Anforderungen.

Der Bußgeldrahmen ist ebenfalls neu: Für bestimmte Verstöße können gegen „besonders wichtige Einrichtungen“ Bußgelder bis zu 10 Millionen Euro, gegen „wichtige Einrichtungen“ bis zu 7 Millionen Euro verhängt werden. Bei Einrichtungen mit mehr als 500 Millionen Euro weltweitem Gesamtumsatz können stattdessen umsatzbezogene Obergrenzen von 2 % bzw. 1,4 % greifen.

BSI C5: Prüfungsmaßstab für Cloud-Dienste — kein Gesetz

Der BSI Cloud Computing Compliance Controls Catalogue (C5) ist kein Gesetz, hat sich aber als wichtiger Prüfungsmaßstab für die Informationssicherheit von Cloud-Diensten etabliert. C5-Berichte werden zunehmend in Ausschreibungen, Lieferantenbewertungen und Verträgen verlangt. Ob ein C5-Bericht erforderlich ist, hängt vom Auftraggeber, dem konkreten Cloud-Dienst, dem Prüfungsumfang und den vertraglichen bzw. regulatorischen Rahmenbedingungen ab. Wichtig: C5 ist ausdrücklich keine BSI-Zertifizierung — korrekt spricht man von einem C5-Bericht bzw. C5-Testat, nicht von einem „Zertifikat“.

C5 unterscheidet sich von generischen Sicherheitsrahmenwerken wie ISO 27001 darin, dass er explizit auf Cloud-Infrastruktur ausgelegt ist. Für Kubernetes-Betreiber sind vor allem diese Kontrollbereiche relevant:

• Beschaffung, Entwicklung und Änderung von Informationssystemen (DEV): Sichere Entwicklungs- und Deployment-Prozesse, Image-Scanning, Kontrolle der Software-Lieferkette
• Kryptographie und Schlüsselmanagement (CRY): Geregeltes Schlüssel- und Secret-Management mit Verschlüsselung — Standard-Kubernetes-Secrets sind lediglich base64-kodiert (nicht verschlüsselt) und reichen dafür allein nicht aus
• Regelbetrieb inkl. Protokollierung (OPS): Audit-Trails für Cluster-Operationen, unveränderlich aggregiert (OPS-14); die Aufbewahrungsdauer richtet sich nach Zweck und vertraglicher Vorgabe, nicht nach einer pauschalen Frist
• Identitäts- und Berechtigungsmanagement (IDM): RBAC nach Least-Privilege-Prinzip, keine Cluster-Admin-Rechte für regulären Betrieb
• Sicherheitsvorfallmanagement (SIM): Definierte Prozesse für Container-bezogene Sicherheitsvorfälle

Wichtig ist die Perspektive: Betreibt ein Unternehmen selbst einen Cloud-Dienst auf Kubernetes, können die C5-Kriterien unmittelbar für dessen internes Kontrollsystem relevant werden. Nutzt es einen externen Managed-Dienst, ist entscheidend, welche Leistungen vom C5-Bericht des Providers umfasst sind und welche Kontrollen in der eigenen Verantwortung verbleiben (die sogenannten User Entity Controls). Ein belastbares Grundsetup zahlt in beiden Fällen ein — ohne es werden Lücken erst im Audit aufgedeckt und dann teuer nachgezogen.

DSGVO: Drittstaaten-Transfer und Container-Verarbeitung

Die DSGVO stellt für Kubernetes-Umgebungen vor allem drei Fragen:

Wo laufen Ihre Nodes? Werden personenbezogene Daten in einem Drittstaat verarbeitet oder dorthin übermittelt, müssen zusätzlich die Anforderungen der Art. 44 ff. DSGVO erfüllt sein — etwa über einen Angemessenheitsbeschluss, geeignete Garantien wie Standardvertragsklauseln oder enge Ausnahmetatbestände. Eine US-Region ist also nicht automatisch unzulässig, erfordert aber eine belastbare Transfergrundlage und eine Bewertung der konkreten Zugriffsrisiken. Das betrifft nicht nur Datenbanken, sondern auch die In-Memory-Verarbeitung in Containern: Die Hauptdatenbank in Deutschland reicht nicht, wenn personenbezogene Daten zugleich in Containern, Logs oder Supportprozessen außerhalb des EWR verarbeitet werden. Ein allgemeines EU-Lokalisierungsgebot kennt die DSGVO dabei nicht.

Wer hat Zugriff auf was? Container-Logs können personenbezogene Daten enthalten — Access-Logs, Fehlerprotokolle, Tracing-Daten aus Microservices. Soweit das der Fall ist, gehören die zugrunde liegenden Verarbeitungstätigkeiten angemessen ins Verzeichnis nach Art. 30 DSGVO, zusammen mit Zweck, Rechtsgrundlage, Zugriffsschutz und Löschfristen. Nicht jede einzelne Logquelle ist dabei zwangsläufig eine eigene Verarbeitungstätigkeit — aber ignorieren lässt sie sich auch nicht.

Wie wird Löschung umgesetzt? In einer Microservice-Architektur mit verteilten Caches, Event-Streams, Replikaten und Backups ist „Daten löschen“ keine einfache Datenbankoperation mehr. Kubernetes-Teams brauchen dokumentierte Aufbewahrungs- und Löschkonzepte auf Architekturebene — die sowohl das Recht auf Löschung (Art. 17 DSGVO) als auch gesetzliche Aufbewahrungspflichten, Sicherheitszwecke und technisch begründete Löschzyklen berücksichtigen.

TISAX: Ein kurzer Hinweis für den Automotive-Bereich

TISAX (Trusted Information Security Assessment Exchange) ist ein branchenbezogener Assessment- und Austauschmechanismus der Automobilindustrie auf Grundlage des VDA ISA — kein Gesetz und nicht automatisch für jedes Automotive-Unternehmen verpflichtend. Eine TISAX-Anforderung entsteht meist aus der Geschäftsbeziehung bzw. den Schutzanforderungen eines Auftraggebers, nicht allein aus der Tätigkeit in der Branche. Zwischen TISAX, ISO 27001 und C5 gibt es inhaltliche Überschneidungen — eine C5-orientierte Plattform ersetzt aber weder ein TISAX-Assessment noch die jeweils relevanten organisatorischen Anforderungen.

Die fünf häufigsten Compliance-Lücken in Kubernetes-Umgebungen

Wenn wir bei cloudpunks in bestehende Kubernetes-Umgebungen einsteigen, sehen wir immer wieder dieselben Muster. Keine bösartige Absicht, keine Fahrlässigkeit — sondern Entscheidungen, die zu einem Zeitpunkt getroffen wurden, als Compliance kein Thema war.

1. Network Policies fehlen oder sind zu permissiv

Standard-Kubernetes erlaubt Default-mäßig die Kommunikation zwischen allen Pods in einem Cluster. Das ist für eine Entwicklungsumgebung praktisch. In einer Produktionsumgebung sind fehlende oder zu weit gefasste Network Policies ein relevantes Sicherheitsrisiko — und können bei Audits zu Rückfragen oder Feststellungen führen, wenn keine gleichwertige Netzwerksegmentierung besteht.

Network Policies schränken den Netzwerkverkehr zwischen Pods explizit ein. In der Praxis treffen wir häufig Umgebungen an, in denen Network Policies formal vorhanden sind, aber de facto jeder Pod mit jedem reden kann — weil die Policies zu großzügig definiert wurden oder weil Ausnahmen als „temporär“ eingeführt und nie zurückgenommen wurden.

2. Secrets-Management: Kubernetes Secrets sind kein Vault

Kubernetes Secrets speichern sensible Daten wie Passwörter, API-Keys und Zertifikate. Das Problem: Kubernetes Secrets sind standardmäßig nur base64-kodiert, nicht verschlüsselt — base64 ist keine Verschlüsselung, sondern nur eine Kodierung. Wer per RBAC Leserechte auf Secrets im jeweiligen Namespace hat (get/list), kann sie damit trivial im Klartext auslesen. Der Schutz hängt also an sauberem RBAC und an etcd-Verschlüsselung — nicht am Secret-Objekt selbst.

Für sensible Zugangsdaten braucht es belastbare Verfahren für Verschlüsselung, Zugriffsschutz, Rotation und Protokollierung. Externe Secret-Stores wie HashiCorp Vault, Azure Key Vault oder AWS Secrets Manager — angebunden über den Secrets Store CSI Driver — und identitätsbasierte Verfahren wie Workload Identity sind dafür oft besonders geeignet. Ein bestimmtes Produkt ist aber nicht vorgeschrieben: Ob es ein externer Store sein muss, hängt vom Schutzbedarf, der Architektur und dem gewählten Kontrollrahmen ab. Angemessen absichern lässt sich Secret-Management je nach Risiko auch über etcd-Verschlüsselung, stark eingeschränktes RBAC, kurze Gültigkeiten und automatisierte Rotation.

3. Kein zentrales Logging und kein Container-Audit-Trail

Kubernetes generiert Ereignisse auf mehreren Ebenen: API-Server-Audit-Logs, Container-Logs, Node-Logs, Events im Cluster. In vielen Umgebungen werden diese Logs nicht zentral gesammelt, nicht manipulationsgeschützt gespeichert und nicht durchsuchbar gehalten.

Für NIS2-Meldepflichten und BSI-C5-Anforderungen brauchen Sie jedoch genau das: Wer hat wann welchen Container gestartet? Wer hat wann welches Deployment geändert? Welche externen Verbindungen hat ein bestimmter Pod aufgebaut? Ohne diesen Audit-Trail sind eine belastbare Vorfallsuntersuchung und eine Behördenauskunft kaum möglich.

4. RBAC: Zu viele Cluster-Admins

In zu vielen Umgebungen haben zu viele Personen Cluster-Admin-Rechte. Das ist menschlich nachvollziehbar — wenn unklar ist, wer welche Rechte wirklich braucht, gibt man einfach mehr. Das Ergebnis ist ein RBAC-Setup, das dem Least-Privilege-Prinzip widerspricht — genau dem Prinzip, das NIS2 und BSI C5 im Zugriffsmanagement erwarten.

Die Lösung ist kein einmaliger Rechte-Entzug, sondern ein RBAC-Konzept, das zu den tatsächlichen Rollen im Team passt: Entwickler brauchen Namespace-spezifische Rechte, keine Cluster-Admin-Rechte. CI/CD-Pipelines brauchen Deployment-Rechte für bestimmte Namespaces, keine globalen Schreibrechte. Service-Accounts in Pods brauchen minimale Rechte — und in vielen Fällen gar keine, weil die Applikation keinen Kubernetes-API-Zugriff benötigt.

5. Ungeklärte Software-Lieferkette: Images ohne Scan, ohne Signatur

NIS2 und BSI C5 adressieren die Sicherheit der Software-Lieferkette. Im Kubernetes-Kontext bedeutet das: Woher kommen Ihre Container-Images? Werden sie auf bekannte Schwachstellen gescannt? Werden sie signiert und wird die Signatur beim Deployment geprüft?

Die Realität in vielen Umgebungen: Images werden aus öffentlichen Registries gezogen, ohne dass Schwachstellen-Scanner im Deployment-Prozess integriert sind. Basisimages werden selten aktualisiert. Image-Signaturen sind kein Thema.

Unter NIS2 verschiebt sich das: Betroffene Einrichtungen müssen angemessene, verhältnismäßige Maßnahmen zur Sicherheit der Lieferkette und zum Schwachstellenmanagement umsetzen. Im Kubernetes-Kontext heißt das typischerweise kontrollierte Registries, regelmäßiges Image-Scanning, gepflegte Basisimages und — je nach Schutzbedarf — Signierung und Verifikation von Images. Ein pauschales gesetzliches Deployment-Verbot für jedes unsignierte Image folgt daraus aber nicht.

Compliance by Design statt Compliance by Retrofit

Die ehrliche Aussage: Es ist deutlich einfacher und günstiger, eine Kubernetes-Plattform von Anfang an compliance-fähig zu bauen, als eine bestehende nachträglich zu härten. Nicht weil das technisch unmöglich wäre — sondern weil jede nachträgliche Änderung an einem laufenden Produktionssystem aufwendiger, riskanter und teurer ist als derselbe Schritt beim initialen Aufbau.

Terraform vor PowerPoint. Was wir damit meinen: Compliance ist kein Konzept auf Papier, das man dem Cluster später beibringt. Es sind konkrete Konfigurationen, Policies und Architekturentscheidungen, die von Anfang an im Code stehen sollten — als eine gute technische Umsetzung der geforderten Schutzziele, nicht als Selbstzweck.

Policy-Engines als Fundament: Kyverno und OPA Gatekeeper

Policy-Engines wie Kyverno oder OPA Gatekeeper setzen Cluster-weite Regeln durch — automatisch, bei jedem Deployment. Typische Policies in einem compliance-fähigen Setup:

• Alle Pods müssen mit nicht-privilegierten Benutzern laufen
• Container-Images müssen aus dem internen Registry kommen und eine gültige Signatur haben
• Jedes Namespace muss definierte Network Policies haben
• Keine Pods ohne Resource-Limits (relevant für DoS-Prävention)

Diese Policies können als Code in GitOps-Repositories verwaltet werden — das liefert wertvolle Nachweise fürs Audit, weil sich die geltenden Sicherheitsregeln des Clusters direkt aus dem Git-Repository vorlegen lassen. Eine vollständige Compliance-Dokumentation ist ein Git-Repo damit noch nicht: Risikobewertungen, Rollen und Verantwortlichkeiten, Freigaberegeln, Ausnahmen und Wirksamkeitskontrollen kommen dazu.

GitOps als Audit-Trail

GitOps ist nicht nur eine Deployment-Strategie — es ist ein starkes Compliance-Werkzeug. Wenn alle Cluster-Konfigurationen über Git verwaltet und per ArgoCD oder Flux ausgerollt werden, entsteht automatisch ein lückenloser Nachweis: Wer hat wann welche Änderung gemacht? Welche Version war wann aktiv? Welche Genehmigungen gab es?

Für Audits und Vorfallsuntersuchungen ist dieser Nachweis Gold wert. Vorgeschrieben ist GitOps aber nicht — weder NIS2 noch DSGVO verlangen ein bestimmtes Deployment-Modell. GitOps ist eine besonders gute technische Umsetzung des Nachvollziehbarkeits-Ziels, kein gesetzliches Muss.

Managed Kubernetes vs. Self-Managed: Die Compliance-Implikation

Eine Frage, die in vielen unserer Gespräche auftaucht: Hilft mir ein Managed Kubernetes-Service (AKS auf Azure, EKS auf AWS) bei der Compliance?

Die Antwort ist differenziert. Managed Services nehmen Ihnen die Verantwortung für die Control-Plane-Infrastruktur ab — Kubernetes-API-Server, etcd, Scheduler laufen beim Cloud-Provider. Große Provider stellen für zahlreiche Dienste C5-Berichte und Vereinbarungen zur Auftragsverarbeitung bereit. Vor einer Compliance-Bewertung muss aber geprüft werden, ob der konkret genutzte Managed-Kubernetes-Dienst, die Region und alle relevanten Zusatzdienste vom aktuellen Prüfbericht umfasst sind (inklusive Prüfzeitraum und Berichtstyp) — und welche Kontrollen beim Kunden verbleiben. Ein Auftragsverarbeitungsvertrag unterstützt die DSGVO-Konformität, macht die konkrete Verarbeitung aber nicht automatisch konform.

Denn: Die Compliance Ihrer Workloads — was in Ihren Containern läuft, wie Ihre RBAC-Regeln aussehen, ob Ihre Secrets sicher verwahrt werden, ob Ihre Logs vollständig sind — das bleibt in Ihrer Verantwortung. Ein AKS-Cluster mit unsicher konfigurierten Workloads ist nicht C5-konform, auch wenn Microsoft für die Infrastruktur einen C5-Bericht vorlegen kann. Geteilte Verantwortung heißt genau das: Der Provider deckt seine Ebene ab, Sie Ihre.

Regionen und Datenlokalisierung

Für DSGVO-relevante Workloads empfehlen wir grundsätzlich EU-Regionen — auf Azure bevorzugt Deutschland (Germany West Central in Frankfurt), auf AWS eu-central-1 (Frankfurt) oder eu-west-1 (Irland). Beide Hyperscaler bieten Funktionen und vertragliche Zusagen, bestimmte Datenverarbeitungen auf die EU bzw. den EWR zu begrenzen. Deren genauer Geltungsbereich, mögliche Ausnahmen (etwa Support-, Diagnose- oder Security-Telemetrie) und Drittstaatenzugriffe müssen aber dienstbezogen geprüft werden.

Für Workloads mit BSI-C5-Anforderungen empfiehlt sich die Kombination aus EU-Region und den entsprechenden Compliance-Funktionen der Cloud-Provider — Microsoft Defender for Cloud mit Regulatory-Compliance-Dashboard auf Azure, AWS Security Hub mit EU-Compliance-Standards auf AWS.

Wie ein compliance-fähiges Kubernetes-Setup in der Praxis aussieht

In unseren Projekten bauen wir Kubernetes-Plattformen nach einem Muster, das wir intern als „Compliance by Default“ bezeichnen: Alle sicherheitsrelevanten Konfigurationen sind von Anfang an aktiviert und werden über GitOps durchgesetzt. Compliance ist kein Audit-Projekt, das einmal im Jahr stattfindet — sondern der Normalzustand.

Ein typisches Setup auf Azure sieht so aus:

Landing Zone als Fundament: Azure Policy auf Management-Group-Ebene stellt sicher, dass keine Ressource außerhalb zugelassener Regionen erstellt werden kann, dass alle Ressourcen verschlüsselt sind, und dass Diagnose-Logs aktiviert werden. Das ist die Basis, auf der der Kubernetes-Cluster aufbaut.

AKS mit gehärtetem Konfigurationsprofil: Private Cluster (kein öffentlich erreichbarer API-Server), Entra-ID-Integration für Authentifizierung, Azure Policy Add-on für Kubernetes, Azure Defender for Containers für Laufzeit-Bedrohungsschutz. Node-Pools in dedizierten Subnetzen mit restriktiven Network Security Groups.

Kyverno als Policy-Engine: Cluster-weite Policies für Pod Security (kein Root, keine privilegierten Container), Image-Herkunft und -Signatur, Pflicht-Labels für alle Workloads (für Tracing und Zuordnung), Resource Quotas pro Namespace.

Azure Key Vault mit Secrets Store CSI Driver: In der Praxis lassen sich nicht alle Kubernetes Secrets durch externe Stores ersetzen — Repo-Credentials des GitOps-Controllers (ArgoCD oder Flux), Image Pull Secrets ohne ACR-Integration oder OIDC-Auth am Gateway greifen teils noch auf K8s-Secrets zurück. Die richtige Strategie ist deshalb gestuft: Workload Identity priorisieren, wo sie unterstützt wird (keine statischen Credentials); den Secrets Store CSI Driver bevorzugen, wo externe Mounts möglich sind; den External Secrets Operator für unvermeidbare K8s-Secrets einsetzen und regelmäßige Rotation aus Key Vault sicherstellen. Die verbleibenden K8s-Secrets werden mit RBAC analog zum Key Vault abgesichert.

Azure Monitor und Log Analytics: Alle Kubernetes-Audit-Logs, Container-Logs und Node-Metriken landen zentral in Log Analytics und werden für Sicherheitsanalysen ausgewertet; Microsoft Sentinel greift auf denselben Workspace zu und erkennt Anomalien. Für besonders schutzbedürftige Audit-Nachweise ergänzen wir gezielt Aufbewahrungs-, Zugriffs- und Manipulationsschutz — restriktive Rollenmodelle und unveränderbare Archivspeicherung — denn ein normaler Workspace ist nicht per se ein unveränderbares Archiv.

GitOps mit ArgoCD oder Flux: Alle Cluster-Konfigurationen, Helm-Charts und Kyverno-Policies werden über ein GitOps-Repository verwaltet — je nach Team-Setup mit ArgoCD oder Flux, beide setzen wir gleichermaßen ein. Reguläre Änderungen laufen ausschließlich über freigegebene GitOps-Prozesse; direkte administrative Eingriffe sind technisch und organisatorisch eingeschränkt, werden protokolliert und nur über dokumentierte Notfallverfahren (Break-glass) zugelassen. Das ist gleichzeitig Audit-Trail und Vier-Augen-Prinzip.

Dieses Setup ist nicht minimal — aber es schafft eine belastbare technische Grundlage für Audits nach C5-orientierten oder NIS2-bezogenen Anforderungen. Ob die Gesamtorganisation die Anforderungen erfüllt, hängt zusätzlich von Prozessen, Verantwortlichkeiten, Verträgen, Dokumentation und der nachgewiesenen Wirksamkeit der Kontrollen ab. Und es ist reproduzierbar: Weil alles als Infrastructure as Code vorliegt, kann eine zweite Umgebung für Staging oder eine weitere Applikation in Stunden und nicht in Wochen aufgebaut werden.

Was jetzt zu tun ist

Wenn Sie eine bestehende Kubernetes-Umgebung betreiben und noch nicht systematisch für NIS2 oder BSI C5 aufgestellt sind, gibt es drei konkrete Schritte:

Schritt 1: Status ehrlich erfassen. Führen Sie einen Compliance-Audit Ihrer Kubernetes-Umgebung durch — kein Papierprozess, sondern eine technische Analyse. Was ist Ihr RBAC-Setup? Wo werden Secrets gespeichert? Werden Logs zentral gesammelt? Sind Network Policies aktiv? Diese Fragen haben konkrete, technische Antworten. Wir führen solche Audits in wenigen Tagen durch und liefern eine priorisierte Lückenanalyse — nicht ein 80-seitiges Konzept, sondern eine Entscheidungsgrundlage.

Schritt 2: Kurzfristig die kritischen Lücken schließen. Nicht alle Compliance-Lücken sind gleich riskant. Fehlende Network Policies in einem Cluster, der Internet-facing Workloads betreibt, ist ein anderes Risiko als ein RBAC-Setup, das intern gut funktioniert, aber formal zu weit gefasst ist. Priorisierung nach tatsächlichem Risiko, nicht nach Alphabetreihenfolge der Controls.

Schritt 3: Mittelfristig auf Compliance by Design umstellen. Das bedeutet: GitOps als Deployment-Standard, Policy-Engine als Cluster-Fundament, Secrets Management außerhalb von Kubernetes. Das ist nicht ein Sprint — aber es ist eine Roadmap, die sich in sechs bis zwölf Monaten umsetzen lässt, ohne den laufenden Betrieb zu gefährden.

Wir bei cloudpunks sind kein Compliance-Berater, der Papierkonzepte schreibt. Wir bauen die Plattform mit. Wir sitzen in Ihren Standups, arbeiten in Ihrem Repository, und stellen sicher dass die technischen Schutzziele im Code landen — nicht in einer Präsentation. Wenn Sie wissen wollen, wo Ihre Kubernetes-Umgebung heute steht, reden wir gern darüber.

Passende cloudpunks-Leistungen

• Kubernetes — Cluster aufbauen und compliance-fähig härten: Network Policies, RBAC, Policy-Engines
• Azure Kubernetes Service (AKS) — Gehärtete AKS-Plattformen mit Entra ID, Azure Policy und Defender for Containers
• GitOps — Git als Single Source of Truth und nachvollziehbarer Audit-Trail für Cluster-Änderungen

Unverbindlich über eure Kubernetes-Compliance reden →

Wir schauen uns eure Umgebung an und sagen euch direkt, wo ihr bei NIS2, BSI C5 und DSGVO steht — ohne Verkaufsgespräch.

Hinweis: Dieser Beitrag beschreibt technische Maßnahmen, die Unternehmen bei der Umsetzung regulatorischer und vertraglicher Sicherheitsanforderungen unterstützen können. Ob und in welchem Umfang NIS2 bzw. das BSI-Gesetz, die DSGVO, BSI C5 oder TISAX auf eine konkrete Organisation oder Plattform anwendbar sind, hängt vom jeweiligen Geschäftsmodell, der Einrichtungsart, dem Prüfungsumfang und der konkreten Datenverarbeitung ab. Der Beitrag ersetzt keine Rechts- oder Auditberatung.