Kubernetes NIS2 und ISO 27001: Welche Nachweise der Cluster liefert

Welche Nachweise liefert Ihr Cluster schon? Das Cluster-Audit von WZ-IT prüft Konfiguration, Versionen, Zugriffe, Netzwerk-Richtlinien und den Restore-Weg gegen den CIS Kubernetes Benchmark und BSI APP.4.4. Ergebnis ist ein Bericht mit priorisierten Maßnahmen, ein Konfigurations-Review ohne Penetrationstest. Kubernetes Cluster-Audit ansehen

Kunden, Auditoren und Aufsichtsbehörden fragen bei Kubernetes selten nach dem Konzept. Sie fragen nach Belegen: Wer hat Administratorrechte? Wann wurde die Wiederherstellung zuletzt getestet? Wie lange werden Zugriffe protokolliert? Dieser Leitfaden zeigt, welche technischen Nachweise ein Kubernetes-Betrieb für Artikel 21 der NIS2-Richtlinie, für ISO 27001 Anhang A und für den BSI-Baustein APP.4.4 liefern kann und wo diese Nachweise im Cluster liegen. Stand Oktober 2026.

Die Abgrenzung vorab: Der Cluster liefert technische Nachweise. Er liefert keine Zertifizierung, ersetzt weder Risikoanalyse noch Managementsystem und ist keine Rechtsberatung. Ob ein Unternehmen unter NIS2 fällt, klärt die Rechtsberatung.

Inhaltsverzeichnis

• Was NIS2, ISO 27001 und APP.4.4 am Cluster verlangen
• Die Nachweis-Matrix: Anforderung, Nachweis, Fundort
• Vier Nachweise, die ein frischer Cluster nicht erzeugt
• Zusätzlich bei kritischen Anlagen (KRITIS)
• Was der Cluster nicht liefert
• In welchem Rhythmus Nachweise entstehen
• Stand und Methodik
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides
• Quellen

Was NIS2, ISO 27001 und APP.4.4 am Cluster verlangen

NIS2. Artikel 21 der Richtlinie (EU) 2022/2555 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen. Absatz 2 nennt zehn Bereiche (a bis j), darunter die Bewältigung von Sicherheitsvorfällen, Backup-Management und Wiederherstellung nach einem Notfall, Sicherheitsmaßnahmen bei der Wartung einschließlich Schwachstellenmanagement, Zugriffskontrolle und Multi-Faktor-Authentifizierung. Kubernetes kommt im Text nicht vor, die Anforderungen sind technologieneutral. In Deutschland entsprechen ihnen die Nummern 1 bis 10 in § 30 Absatz 2 BSIG, und Absatz 1 verlangt, dass die Einrichtungen die Einhaltung dokumentieren. Wer dokumentieren muss, braucht Belege, die aus dem laufenden Betrieb entstehen. Für Einrichtungsarten wie Cloud-Computing-Dienstleister, Rechenzentrumsdienste oder Anbieter verwalteter Dienste konkretisiert die Durchführungsverordnung (EU) 2024/2690 die technischen Anforderungen (Artikel 21 Absatz 5).

ISO 27001. Die Norm beschreibt ein Managementsystem für Informationssicherheit. Anhang A der Ausgabe 2022 umfasst 93 Maßnahmen in vier Themengebieten. Die technologischen Maßnahmen tragen die Nummern A.8.x. Die meisten Cluster-Nachweise fallen darunter, Zugriffsrechte und Vorfallbehandlung zusätzlich unter A.5.x. Der Normtext ist kostenpflichtig. Die Nummern in diesem Artikel stammen aus der ENISA-Zuordnungstabelle.

BSI APP.4.4. Der Baustein APP.4.4 Kubernetes (Edition 2023) hat 21 Anforderungen. Fünf sind Basis-Anforderungen (A1 bis A5, MUSS), sieben Standard-Anforderungen (A6 bis A12, SOLLTE) und neun gelten bei erhöhtem Schutzbedarf (A13 bis A21). Er wird zusammen mit SYS.1.6 Containerisierung angewendet.

Die Nachweis-Matrix: Anforderung, Nachweis, Fundort

Die Tabelle ordnet jedem Bereich die Bezüge, den Nachweis aus dem Cluster und den Fundort zu. Sie ist eine Lesehilfe und kein offizielles Mapping. Bezüge: NIS2 = Buchstabe in Artikel 21 Absatz 2, ISO = Anhang A der Ausgabe 2022, APP = Anforderung im Baustein APP.4.4.

Die Meldefristen stammen aus Artikel 23 Absatz 4: Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht spätestens einen Monat nach der Meldung. Die Beispiele für Nachweise folgen der ENISA-Umsetzungshilfe zur Durchführungsverordnung 2024/2690, etwa Aufzeichnungen regelmäßiger Restore-Tests, Patch-Historien mit Zeitstempel und Verantwortlichem oder Konfigurations-Snapshots vor und nach Änderungen.

Vier Nachweise, die ein frischer Cluster nicht erzeugt

Manche Belege entstehen von selbst, etwa die Git-Historie eines GitOps-Repositories. Vier brauchen eine bewusste Einrichtung oder eine wiederkehrende Handlung.

1. Das Audit-Log. Der API-Server schreibt nur dann Ereignisse, wenn eine Audit-Policy konfiguriert ist: Ohne --audit-policy-file wird nichts protokolliert. Das Log beantwortet, was wann geschah, wer es auslöste, auf welcher Ressource und von wo. Eine Policy, die alle Anfragen auf Metadaten-Ebene festhält, genügt als Anfang:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Das Log-Backend schreibt in eine Datei (--audit-log-path, Rotation über --audit-log-maxage, --audit-log-maxbackup und --audit-log-maxsize), das Webhook-Backend sendet an eine externe API. Für die Aufbewahrung gibt es keine feste Frist. Die Durchführungsverordnung verlangt für die von ihr erfassten Einrichtungsarten Protokolle für einen vorab festgelegten Zeitraum und Schutz vor unbefugtem Zugriff oder Änderung, die ENISA-Hilfe nennt als Nachweis eine festgelegte Frist. Frist und Begründung legt der Betreiber fest. Verstöße gegen Pod-Security-Standards landen im Modus audit als Annotation im selben Log (Pod Security Admission).

2. Der RBAC-Export mit Rezertifizierung. Wer administrative Rechte hat, belegt ein Export mit Stichtag, abgelegt in Git oder im Nachweis-Repository:

kubectl get clusterrolebindings,rolebindings -A -o yaml > rbac-$(date +%F).yaml
kubectl get clusterrolebindings -o custom-columns='NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name' | grep cluster-admin

Der Export ist nur der halbe Beleg. Die zweite Hälfte ist die dokumentierte Prüfung: wer die Liste wann gesichtet und was entzogen hat. Mitglieder der Gruppe system:masters umgehen alle RBAC-Prüfungen, und ihr Zugriff lässt sich nicht durch das Entfernen von Bindings widerrufen (RBAC Good Practices). Admin-Zugänge über diese Gruppe gehören deshalb in die Prüfung. APP.4.4.A3 verlangt zudem, dass administrative Handlungen nicht anonym erfolgen.

3. Das Restore-Protokoll. Ein grüner Backup-Job belegt, dass geschrieben wurde. Ein Protokoll belegt, dass sich der Cluster wiederherstellen lässt. Die Felder folgen Punkt 4.2 der Durchführungsverordnung und den Nachweisbeispielen der ENISA dazu (Wiederherstellungszeiten, Vollständigkeit einschließlich Konfigurationsdaten, Tests und Korrekturmaßnahmen):

• Datum, Verantwortlicher, Umfang (Namespace, Volumes, Datenbank)
• Backup-Quelle mit Zeitstempel, daraus ergibt sich der tatsächliche Datenverlust
• Restore-Ziel, nie das Produktivsystem
• Beginn, Ende und gemessene Dauer im Vergleich zum Ziel
• Integritätsprüfung, etwa Zeilenzahl oder Smoke-Test der Anwendung
• Abweichungen mit Korrekturmaßnahme und Termin
• Freigabe, Ablageort, Datum des nächsten Tests

APP.4.4.A5 definiert den Umfang der Sicherung: Persistent Volumes, Konfigurationsdateien von Kubernetes und Control Plane, der Cluster-Zustand einschließlich Erweiterungen, etcd, Infrastrukturanwendungen und die Daten der Registries. Snapshots dürfen die Datensicherung nicht ersetzen. Der etcd-Snapshot (etcdctl snapshot save) enthält den gesamten Cluster-Zustand und sollte verschlüsselt abgelegt werden (Kubernetes-Dokumentation). Die vier Sicherungsebenen beschreibt Kubernetes-Backup: die vier Ebenen.

4. Die Versions- und Änderungshistorie. Kubernetes pflegt jede Minor-Version rund vierzehn Monate, zwölf im Standard und zwei im Wartungsmodus (Patch Releases). Stand 28.10.2026 ist 1.34 seit dem 27.10.2026 am Ende des Supports, 1.35 läuft bis zum 28.02.2027. Ein Nachweis zeigt, auf welcher Version der Cluster stand, wann er aktualisiert wurde und wer die Änderung freigab. Liegt die Cluster-Konfiguration in Git, ist die Historie vollständig: Das GitOps-Prinzip Versioned and Immutable verlangt genau das, und APP.4.4.A8 fordert versionierte und annotierte Konfigurationsdateien. Ergänzend gibt es einen offiziellen CVE-Feed als JSON und RSS, gegen den sich der Versionsstand abgleichen lässt.

Ein Hinweis zu NetworkPolicies als Beleg für Netztrennung: Sie wirken nur, wenn das CNI sie durchsetzt. Ohne unterstützendes Netzwerk-Plugin haben sie keine Wirkung, und ein Pod ist ohne Policy nicht isoliert. Welche CNI-Funktionen darüber hinaus Flow-Daten als Nachweis liefern, vergleicht Cilium vs. Calico.

Zusätzlich bei kritischen Anlagen (KRITIS)

Für Betreiber kritischer Anlagen gilt zusätzlich zu § 30 BSIG der § 31: Maßnahmen über das Schutzniveau anderer besonders wichtiger Einrichtungen hinaus können verhältnismäßig sein, und für die maßgeblichen IT-Systeme ist eine Angriffserkennung Pflicht, die Parameter aus dem laufenden Betrieb kontinuierlich und automatisch erfasst und auswertet. Das Audit-Log eines Clusters ist eine Datenquelle für diese Erkennung, nicht die Erkennung selbst. Den Nachweis der Umsetzung erbringen Betreiber nach § 39 gegenüber dem BSI durch Sicherheitsaudits, Prüfungen oder Zertifizierungen, erstmals zu einem vom BSI festgelegten Zeitpunkt (frühestens drei Jahre nach der Einstufung als Betreiber) und danach alle drei Jahre. Welche Anlagen als kritisch gelten, ist eine Frage der Rechtsberatung und der jeweiligen Rechtsverordnung. Technisch heißt das für den Cluster: dieselben Nachweise wie in der Matrix, eine Angriffserkennung mit angebundenen Logquellen und Nachweise, die sich für das Audit im Dreijahresrhythmus vorlegen lassen.

Was der Cluster nicht liefert

Nicht aus dem Cluster stammen Risikoanalyse und Sicherheitskonzept (Artikel 21 Absatz 2 Buchstabe a), Schulungen (Buchstabe g), Personalsicherheit, die Billigung und Überwachung der Maßnahmen durch die Leitungsorgane nach Artikel 20 und die Festlegung, wer Vorfälle meldet. Der Cluster liefert die technischen Belege für diese Entscheidungen, nicht die Entscheidungen.

Auch die Verantwortungsgrenze beeinflusst die Nachweise. Bei verwalteten Kubernetes-Diensten liegen Control Plane und etcd beim Anbieter. Bei selbst betriebenen Clustern auf Proxmox, Bare Metal oder bei einem Cloud-Anbieter gehören etcd-Backup, API-Server-Konfiguration einschließlich Audit-Policy und Upgrades zum Betrieb. Ein Zertifikat des Rechenzentrums oder des Anbieters gilt für dessen Geltungsbereich und sagt nichts über RBAC, Netzwerk-Richtlinien oder Restore des Clusters. Zu prüfen sind Geltungsbereich, Laufzeit, Zertifizierungsstelle, monatliche Nachweise aus dem laufenden Betrieb und die beteiligten Unterauftragnehmer.

Der Cluster liefert technische Nachweise; Zertifizierung und rechtliche Bewertung liegen außerhalb der Technik. Die Nachweise aus dem Betrieb stammen aus dem vereinbarten Leistungsbereich und ersetzen nicht das Managementsystem des Kunden.

In welchem Rhythmus Nachweise entstehen

Die Regelwerke schreiben für die meisten Nachweise keinen festen Takt vor. Die Tabelle zeigt die Empfehlung von WZ-IT, begründet nach Kritikalität. Die ENISA-Hilfe nennt zwei Orientierungswerte: Konfigurationen mindestens monatlich überprüfen (Punkt 6.3.3) und Backups nach Kritikalität prüfen, als Beispiel wöchentlich bei hoher und monatlich bei mittlerer oder niedriger Kritikalität (Punkt 4.2.6).

Wer die Exporte kurz vor dem Audit von Hand zieht, belegt nur den Stichtag. Ein geplanter Job (CI-Pipeline oder CronJob) mit Ablage im Nachweis-Repository belegt den gesamten Zeitraum.

Stand und Methodik

• Stand: 28.10.2026. Kubernetes-Dokumentation in der Fassung für Version 1.37, Support-Termine aus der Seite Patch Releases.
• NIS2: Buchstaben a bis j nach dem Richtlinientext (EUR-Lex), Nummern 1 bis 10 nach § 30 Absatz 2 BSIG (gesetze-im-internet.de).
• ISO 27001: Nummern aus der ENISA-Zuordnungstabelle Version 1.2 (September 2025). Sie ordnet jeder Anforderung der Durchführungsverordnung (EU) 2024/2690 Anhang-A-Nummern zu. Wir haben die Nummern den Cluster-Bereichen zugeordnet. Die ENISA hält fest, dass die Zuordnung keine Gleichwertigkeit der Regelwerke aussagt. Die Umsetzungshilfe richtet sich formal an die Einrichtungsarten der Verordnung und dient anderen Einrichtungen als Orientierung.
• APP.4.4: Anforderungen und Einstufung aus dem Baustein, Edition 2023.
• Befehle: Beispiele, vor dem Einsatz am eigenen Cluster zu prüfen.
• Nicht enthalten: Rechtsauslegung, sektorspezifische Regeln und der Vergleich von SIEM-Produkten.

Unser Vorgehen bei WZ-IT

1. Bestandsaufnahme im Cluster-Audit. Das Cluster-Audit prüft Konfiguration, Versionen und Upgrade-Pfad, Zugriffe, Netzwerk-Richtlinien, Secrets sowie Backup und Restore-Weg gegen den CIS Kubernetes Benchmark und APP.4.4. Es ist ein Konfigurations-Review mit Bericht und kein Penetrationstest. Es kostet ab 1.490 € einmalig netto und wird auf den ersten Betriebsmonat angerechnet. Stand Oktober 2026.
2. Nachweise im Betrieb. Im Betrieb von Kubernetes entstehen Upgrade-, Backup- und Restore-Nachweise im vereinbarten Leistungsbereich. Managed Kubernetes kostet ab 590 € je Cluster und Monat netto inklusive drei Worker-Nodes. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level.
3. Abgrenzung. WZ-IT liefert technische Nachweise und leistet keine Rechtsberatung. Ob und welche NIS2-Pflichten für Ihr Unternehmen gelten, klären Sie mit Ihrer Rechtsberatung; eine erste Orientierung bietet die Betroffenheitsprüfung des BSI.

Die Betriebsnachweise außerhalb von Kubernetes, etwa Patch-, Monitoring- und Incident-Reports, beschreibt die Seite Compliance.

Weiterführende Guides

• Kubernetes-Backup: die vier Ebenen: etcd, Ressourcen, Volumes und konsistente Datenbanken sowie der getestete Restore.
• Kubernetes-Cluster übernehmen: Audit-Checkliste: Bestandsaufnahme und Red Flags bei fremden Clustern.
• Cilium vs. Calico: CNI-Vergleich mit Policies, Flow-Daten und Verschlüsselung.
• Kubernetes privat über NetBird erreichen: Cluster-API ohne öffentliche Exposition und mit nachvollziehbarem Zugriff.
• Longhorn vs. Rook-Ceph: Storage-Schicht unter den Volumes, die gesichert werden.

Cluster auf Nachweise prüfen lassen oder den Betrieb mit Nachweisen aufsetzen: Kubernetes Cluster-Audit von WZ-IT.

Quellen

Abruf aller Quellen am 28.10.2026.

• Richtlinie (EU) 2022/2555 (NIS2), Artikel 20, 21 und 23
• BSIG § 30, § 31 und § 39
• BSI: NIS-2-regulierte Unternehmen und NIS-2-Betroffenheitsprüfung
• BSI IT-Grundschutz-Kompendium: APP.4.4 Kubernetes, Edition 2023
• BSI: Aktuelles und Ausblick zum IT-Grundschutz (Anpassung an ISO 27001:2022)
• ENISA: Technical Implementation Guidance (Version 1.0, Juni 2025) und Mapping Table (Version 1.2)
• Kubernetes: Auditing, RBAC Good Practices, Network Policies, Pod Security Admission
• Kubernetes: etcd-Cluster betreiben und sichern, Verschlüsselung von Daten im Ruhezustand
• Kubernetes: Patch Releases und Official CVE Feed
• OpenGitOps: GitOps Principles
• kube-bench und CIS Kubernetes Benchmark
• Velero