§ 30 BSIG auf Kubernetes übersetzt: was der Gesetzestext technisch bedeutet

TL;DR

1. § 30 Absatz 2 BSIG listet zehn Maßnahmenbereiche. Keiner nennt eine Technologie. Ein amtliches Mapping auf Kubernetes-Kontrollen existiert nicht — weder vom BSI noch von der ENISA.
2. Sieben der zehn Kategorien lassen sich trotzdem auf benannte Mechanismen abbilden: Audit-Policy, etcd- und PV-Backup mit getestetem Restore, Image-Herkunft und Digest-Pinning, Patch-Stand, CIS-Benchmark-Läufe, Secrets-Verschlüsselung at rest, RBAC, NetworkPolicies, Pod Security Standards, OIDC-Kopplung. Drei Kategorien sind rein organisatorisch.
3. "Stand der Technik" ist kein definierter Wert. Wer Ihnen dafür eine exakte Konformitätsschwelle verkauft, erfindet sie.
4. Was nicht aus § 30 BSIG folgt: Systeme zur Angriffserkennung (nur kritische Anlagen, § 31 Absatz 2), turnusmäßige externe Audits (nur kritische Anlagen, § 39), eine ISO-27001-Zertifizierung, eine gesetzliche Mindestaufbewahrungsdauer für Audit-Logs.

Was § 30 BSIG tatsächlich sagt

Der Wortlaut von § 30 Absatz 1 Satz 1 BSIG ist kurz: Besonders wichtige und wichtige Einrichtungen sind verpflichtet, "geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen" zu ergreifen, um Störungen der Verfügbarkeit, Integrität und Vertraulichkeit ihrer IT-Systeme zu vermeiden und Auswirkungen von Sicherheitsvorfällen gering zu halten.

Zwei Sätze weiter steht der Satz, den die meisten überlesen: "Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren." Das ist eine eigenständige Pflicht. Ein technisch sauber gehärteter Cluster ohne Dokumentation verletzt sie.

Absatz 2 Satz 1 verlangt, dass die Maßnahmen den Stand der Technik einhalten sollen, einschlägige europäische und internationale Normen berücksichtigen und auf einem gefahrenübergreifenden Ansatz beruhen. Satz 2 zählt die zehn Bereiche auf, die mindestens abgedeckt sein müssen.

Der Gesetzestext nennt keine Produkte, keine Konfigurationswerte und keine Prüftiefe. Die folgende Übersetzung ist fachliche Auslegung und stützt sich technisch auf die Kubernetes Security Checklist und die BSI-Bausteine APP.4.4 (Kubernetes) und SYS.1.6 (Containerisierung) aus dem IT-Grundschutz-Kompendium Edition 2023.

Nummer 1: Risikoanalyse und IT-Sicherheitskonzepte

Verlangt sind "Konzepte in Bezug auf die Risikoanalyse und auf die Sicherheit in der Informationstechnik".

Im Cluster heißt das zuerst: Schnitt begründen. Welche Anwendungen teilen sich einen Cluster, welche einen Namespace, und warum? APP.4.4.A1 formuliert das als Muss-Anforderung — die Architektur von Namespaces, Clustern und Netzen muss auf Basis des Schutzbedarfs der Anwendungen festgelegt werden, und nur Anwendungen mit ähnlichem Schutzbedarf sollen sich einen Cluster teilen.

Produktive Workloads im Namespace default (kubectl get pods -n default) sind ein Befund. Nicht weil default technisch schlechter wäre, sondern weil weder Pod Security Admission noch NetworkPolicy greifen, wenn alles im selben Namespace liegt — beide wirken namespace-bezogen.

Das eigentliche Artefakt dieser Kategorie ist aber ein datiertes Dokument, kein YAML. Ohne Schutzbedarfsfeststellung ist jede spätere Verhältnismäßigkeitsargumentation freihändig.

Nummer 2: Bewältigung von Sicherheitsvorfällen

Was diese Kategorie technisch erzwingt, ergibt sich erst im Zusammenspiel mit § 32 BSIG: Erstmeldung binnen 24 Stunden nach Kenntniserlangung, Meldung mit erster Bewertung von Schweregrad und Auswirkungen binnen 72 Stunden, Abschlussmeldung spätestens einen Monat nach der 72-Stunden-Meldung. Ohne Audit-Log können Sie nach 72 Stunden weder sagen, wer was geändert hat, noch den Schweregrad belegen.

Kubernetes-Auditing ist standardmäßig aus. Die Dokumentation ist eindeutig: Ohne gesetztes --audit-policy-file werden keine Events geloggt. Eine brauchbare Minimal-Policy:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  # Secrets und ConfigMaps: nur Metadaten, niemals Bodies
  - level: Metadata
    resources:
      - group: ''
        resources: ['secrets', 'configmaps']
  # Rechteänderungen vollständig protokollieren
  - level: RequestResponse
    resources:
      - group: 'rbac.authorization.k8s.io'
        resources: ['roles', 'rolebindings', 'clusterroles', 'clusterrolebindings']
  # Alles Übrige auf Metadatenebene
  - level: Metadata

Bei Managed Clusters setzen Sie die Policy nicht selbst, sondern aktivieren die Control-Plane-Logs des Anbieters und prüfen deren Aufbewahrungsdauer. Wichtig: Es gibt keine gesetzlich vorgeschriebene Mindestaufbewahrung für Kubernetes-Audit-Logs. Dass die Rohdaten die Abschlussmeldung nach einem Monat überleben sollten, ist eine Herleitung aus § 32, keine Rechtsvorschrift.

Nummer 3: Aufrechterhaltung des Betriebs und Krisenmanagement

Wörtlich: "Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement".

APP.4.4.A5 ist hier konkreter als das Gesetz und als Basis-Anforderung formuliert. Gesichert werden müssen Persistent Volumes, die Konfigurationsdateien von Kubernetes und Control Plane, der aktuelle Cluster-Zustand inklusive Erweiterungen, etcd, alle Infrastrukturanwendungen sowie die Datenhaltung der Code- und Image-Registries. Dazu der Satz, an dem die meisten Backup-Konzepte scheitern: Snapshots dürfen die Datensicherung nicht ersetzen. Ein reiner VM- oder Storage-Snapshot der Control-Plane-Nodes genügt also nicht.

Für etcd verweist die Kubernetes-Dokumentation auf etcdctl snapshot save zur Sicherung und etcdutl snapshot restore zur Wiederherstellung. Der Aufruf mit TLS (Pfade je nach Distribution anpassen):

etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-$(date +%F).db

Was in Audits regelmäßig fehlt, ist nicht das Backup, sondern der Nachweis, dass es funktioniert. Ein Backup ohne durchgeführten Restore in einen leeren Cluster dokumentiert nichts. Wer den Restore einmal jährlich fährt und Datum sowie tatsächlich benötigte Wiederherstellungszeit protokolliert, hat für diese Kategorie das belastbarste Einzelartefakt im ganzen Katalog.

Nummer 4: Sicherheit der Lieferkette

Der Wortlaut erfasst ausdrücklich die "sicherheitsbezogenen Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern".

Der erste Teil ist die Image-Herkunft. SYS.1.6.A6 verlangt als Muss, dass sämtliche verwendeten Images aus vertrauenswürdigen Quellen stammen, dass eindeutig identifizierbar ist, wer ein Image erstellt hat, und dass die verwendete Version eines Basis-Images nicht abgekündigt ist. Der erste Blick darauf ist billig:

kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u

Die Ausgabe zeigt, aus wie vielen unterschiedlichen Quellen produktiv gezogen wird. In Bestandsclustern sind zweistellige Registry-Zahlen der Normalfall (Beobachtung aus eigener Praxis, kein erhobener Benchmark).

Der zweite Teil ist unbequemer: Cluster-Add-ons. CNI, CSI-Treiber, Ingress-Controller, Cert-Manager, Monitoring-Stack, Backup-Tool — für jede dieser Komponenten fragt Nummer 4 nach der Sicherheitsbeziehung zum Anbieter. Bei Community-Open-Source-Projekten gibt es keinen Vertragspartner und keine zugesagte Reaktionszeit. Das ist kein Verstoß, aber eine Lücke, die benannt und begründet gehört. Ein Add-on-Inventar mit Bezugsquelle, Supportstatus und Meldeweg je Komponente ist das erwartbare Artefakt.

Nummer 5: Erwerb, Entwicklung, Wartung und Schwachstellenmanagement

Hier wird ein Cluster am schnellsten unverteidigbar. Das Kubernetes-Projekt pflegt eine Patch-Release-Serie rund vierzehn Monate — zwölf Monate regulärer Support plus zwei Monate Maintenance Mode, praktisch also drei aktive Minor-Versionen. Danach gibt es keine Sicherheitspatches, und "Stand der Technik" ist nicht mehr argumentierbar.

kubectl version
kubectl get nodes -o wide

Die zweite Zeile ist genauso wichtig: Sie zeigt Kernel-Version und Container-Runtime der Nodes. Ein aktueller Control-Plane-Stand bei drei Jahre alten Node-Images ist ein häufiger Befund.

Beim Schwachstellenmanagement der Images verlangt die Kubernetes Security Checklist Scans "during creation and in deployment". Der Zusatz ist der entscheidende: Ein reiner Build-Zeit-Scan findet nichts, was nach dem Deploy bekannt wird. Dazu gehört eine schriftliche Frist, bis wann ein kritischer Fund gepatcht sein muss — gesetzlich vorgegeben ist sie nicht, dokumentierbar schon, ihr Fehlen ebenfalls.

Tags sind veränderlich. Die Checklist verlangt deshalb, Images entweder per sha256-Digest zu referenzieren oder ihre Signatur beim Deploy per Admission Control zu prüfen. Beides zusammen ist nicht nötig. Was tatsächlich läuft, zeigt:

kubectl get pod <name> -n <ns> -o jsonpath='{.status.containerStatuses[*].imageID}'

Nummer 6: Bewertung der Wirksamkeit

Verlangt sind "Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen" — Verfahren, nicht Zertifikate.

APP.4.4.A13 beschreibt die passende Kontrolle: ein automatisches Audit der Einstellungen von Nodes, Kubernetes und Pods gegen eine definierte Liste erlaubter Einstellungen und gegen standardisierte Benchmarks. Der De-facto-Benchmark ist der CIS Kubernetes Benchmark, im Cluster ausgeführt über kube-bench. Wenn Sie Control-IDs dokumentieren, nennen Sie die Benchmark-Version dazu — die Nummern verschieben sich zwischen Versionen.

Der Ausgangsbefund ist die Baseline, der wiederkehrende Lauf ist das Verfahren, das datierte Ergebnis ist die Dokumentation nach § 30 Absatz 1 Satz 3. Ein einmaliger Lauf ohne Wiederholungstermin bedient diese Kategorie nicht.

Nummer 7: Schulungen und Sensibilisierung

"Grundlegende Schulungen und Sensibilisierungsmaßnahmen im Bereich der Sicherheit in der Informationstechnik" — im Cluster gibt es dafür nichts zu konfigurieren.

Erwähnenswert ist die Kategorie trotzdem, weil sie eine persönlich adressierte Parallelvorschrift hat: § 38 Absatz 3 BSIG verpflichtet die Geschäftsleitungen selbst, regelmäßig an Schulungen teilzunehmen, um Risiken und Risikomanagementpraktiken erkennen und bewerten zu können. Absatz 1 verpflichtet sie, die Maßnahmen nach § 30 umzusetzen und ihre Umsetzung zu überwachen.

Zur Haftung, weil dazu viel Unsinn kursiert: § 38 Absatz 2 regelt Innenhaftung gegenüber der eigenen Einrichtung nach den Regeln des anwendbaren Gesellschaftsrechts — und nach dem BSIG selbst nur subsidiär. Eine neu geschaffene Außenhaftung gegenüber Dritten ist das nicht.

Nummer 8: Kryptographische Verfahren

"Konzepte und Prozesse für den Einsatz von kryptographischen Verfahren."

Der teuerste Default in Kubernetes steht hier. Die Secrets-Dokumentation sagt wörtlich: "Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd)." Base64 ist Kodierung, keine Verschlüsselung. Wer nichts konfiguriert hat, hat seine Zugangsdaten im Klartext in etcd — und in jedem etcd-Backup.

Die Abhilfe ist eine EncryptionConfiguration, die am API-Server über --encryption-provider-config eingehängt wird:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aesgcm:
          keys:
            - name: key1
              secret: <32 Byte, base64-kodiert>
      - identity: {}

Zur Providerwahl: Die Kubernetes-Dokumentation stuft aescbc in ihrer Provider-Tabelle als schwach ein und rät wegen der Anfälligkeit von CBC gegenüber Padding-Oracle-Angriffen davon ab. Für Produktivumgebungen ist ein KMS-Provider (kms v2) die empfohlene Variante, weil das Schlüsselmaterial dann nicht als Klartext in der Konfigurationsdatei auf dem Control-Plane-Knoten liegt. Das Beispiel oben ist die Minimalvariante ohne externes KMS.

Zwei Fallen dabei. Erstens: Der erste Provider in der Liste verschlüsselt neue Schreibvorgänge. Steht identity an erster Stelle, wird weiterhin Klartext geschrieben — die Doku sagt dazu, diese Konfiguration biete keine Vertraulichkeit. identity gehört ans Ende, damit bestehende unverschlüsselte Einträge lesbar bleiben. Zweitens: Bestehende Secrets werden nicht rückwirkend verschlüsselt, sie müssen einmal neu geschrieben werden (kubectl get secrets -A -o json | kubectl replace -f -).

Bei Managed Clusters lautet die Aufgabe: prüfen, ob die KMS-basierte etcd-Verschlüsselung des Anbieters aktiviert ist, und das Ergebnis dokumentieren.

Nummer 9: Personalsicherheit, Zugriffskontrolle, Verwaltung von IKT-Systemen

Die inhaltlich breiteste Kategorie. Vier Kubernetes-Kontrollen fallen darunter.

RBAC. Wie viele Subjekte hängen an cluster-admin, und ist jedes einer benannten Person oder einem dokumentierten Dienst zuordenbar?

kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name, (.subjects[]?|.kind+"/"+.name)'

Die RBAC Good Practices weisen zusätzlich darauf hin, dass die Gruppe system:masters sämtliche RBAC-Prüfungen umgeht. Wer sie nach dem Bootstrapping noch für Authentifizierung nutzt, hat faktisch keine Zugriffskontrolle. Der vollständige Durchlauf steht im RBAC-Audit-Leitfaden.

Identitäten und Offboarding. Die härteste strukturelle Lücke, und keine Fehlkonfiguration, sondern eine Eigenschaft von Kubernetes: Die Authentifizierungs-Dokumentation stellt fest, dass Kubernetes keinen Zertifikatswiderruf unterstützt — ein ausgestelltes Zertifikat bleibt bis zum Ablauf gültig. Ein ausgeschiedener Administrator mit einer kubeconfig auf Basis eines X.509-Client-Zertifikats behält vollen Zugriff, bis das Zertifikat abläuft; der einzige Weg, ihn vorher zu entziehen, ist eine Rotation der Cluster-CA. Wer Zugriffskontrolle belegen will, koppelt den Cluster-Zugang per OIDC an den zentralen Identity Provider, statt Client-Zertifikate zu verteilen.

Netztrennung. Pods sind per Default nicht isoliert; ein- und ausgehende Verbindungen sind offen. Eine default-deny-Policy je produktivem Namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Danach werden benötigte Verbindungen explizit freigegeben, DNS zuerst — sonst steht die Anwendung:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Das Label des DNS-Pods variiert je nach Distribution — vorher mit kubectl get pods -n kube-system --show-labels verifizieren. Und der Prüfschritt, den fast alle auslassen: Die NetworkPolicy-Dokumentation hält fest, dass eine NetworkPolicy ohne implementierenden Controller wirkungslos ist. Vorhandene Policy-Objekte sind kein Beweis für Durchsetzung, solange das CNI-Plugin sie nicht umsetzt.

Pod Security Standards. Ohne Label lässt ein Namespace privilegierte Container zu. Durchgesetzt wird über Pod Security Admission:

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Nur enforce lehnt nicht konforme Pods ab; warn und audit lassen sie durch. Genau das ist der Zwischenschritt oben: enforce: baseline blockiert bereits die groben Verstöße, während warn und audit auf restricted den Abstand zum Zielzustand messen.

Nummer 10: Multi-Faktor-Authentifizierung und gesicherte Kommunikation

Verlangt sind Lösungen zur Multi-Faktor- oder kontinuierlichen Authentifizierung sowie gesicherte Sprach-, Video- und Textkommunikation.

Kubernetes bringt keine MFA mit. Die Authentifizierungs-Dokumentation listet X.509-Client-Zertifikate, Bootstrap-Token, Service-Account-Token, eine statische Token-Datei sowie die externen Integrationen OIDC, Webhook-Token-Authentifizierung und Authenticating Reverse Proxy. MFA lässt sich ausschließlich über den vorgelagerten Identity Provider erzwingen — technisch dieselbe Maßnahme wie die OIDC-Kopplung aus Nummer 9.

Der zweite Teil betrifft die Exposition der Steuerungsebene. Die Kubernetes Security Checklist formuliert es als eigenen Punkt: Kubernetes-API, kubelet-API und etcd sind nicht öffentlich aus dem Internet erreichbar. Bei Managed Clusters ist das eine Portal-Einstellung (privater Endpunkt oder IP-Allowlist), bei selbst betriebenen Clustern zusätzlich --anonymous-auth=false an API-Server und kubelet sowie --read-only-port=0 am kubelet.

Regelmäßig übersehen wird das CI/CD-System. Es deployt oft mit weiteren Rechten als jeder einzelne Mensch und hat naturgemäß keinen zweiten Faktor. Die Konsequenz ist nicht MFA für die Pipeline, sondern eine getrennte, minimal berechtigte Deploy-Identität.

Übersicht: zehn Kategorien, ein Prüfschritt je Zeile

Wo der Gesetzestext offen bleibt

Zwei Stellen halten der Prüfung nicht stand, wenn Ihnen dort jemand Eindeutigkeit verspricht.

"Stand der Technik" ist kein definierter Wert. § 30 Absatz 2 Satz 1 sagt, die Maßnahmen sollen ihn einhalten und einschlägige europäische und internationale Normen berücksichtigen. Welche Normen, in welcher Fassung, mit welcher Prüftiefe — steht nicht da. In der Praxis argumentiert man über anerkannte Kataloge (IT-Grundschutz, CIS Benchmark, ISO 27001) und dokumentiert die Wahl. Belastbare Argumentation, aber keine Rechtssicherheit.

Verhältnismäßigkeit ist eine Einzelfallabwägung. Absatz 1 Satz 2 nennt Risikoexposition, Größe der Einrichtung, Umsetzungskosten sowie Eintrittswahrscheinlichkeit und Schwere von Vorfällen. Kein Schwellenwert, keine Formel. Ein 120-Personen-Maschinenbauer und ein 1.800-Personen-Klinikverbund schulden nicht dasselbe. Wer diese Abwägung schriftlich führt, steht besser da als jemand mit teureren Tools und keiner Begründung.

Die Tabelle oben ist deshalb verteidigbar, aber nicht verbindlich: Jede Zeile hängt an einer Muss- oder Soll-Anforderung des IT-Grundschutzes oder an der Kubernetes Security Checklist — ein amtliches Mapping ersetzt sie nicht.

Was aus § 30 BSIG gerade nicht folgt

Überkonformität kostet Geld ohne Nutzen. Vier verbreitete Annahmen halten dem Gesetzestext nicht stand.

Systeme zur Angriffserkennung sind nicht für alle Pflicht. Die Pflicht, Systeme zur Angriffserkennung einzusetzen, die Parameter aus dem laufenden Betrieb kontinuierlich und automatisch auswerten, steht in § 31 Absatz 2 BSIG und richtet sich an Betreiber kritischer Anlagen. Für sonstige besonders wichtige und wichtige Einrichtungen besteht sie nicht. Ein Runtime-Security-Stack kann trotzdem sinnvoll sein — als NIS2-Pflicht verkauft ist er es nicht.

Turnusmäßige externe Audits sind nicht für alle Pflicht. Der Nachweis durch Sicherheitsaudits, Prüfungen oder Zertifizierungen alle drei Jahre steht in § 39 BSIG und trifft Betreiber kritischer Anlagen. Für alle anderen bleibt es bei der Dokumentationspflicht aus § 30 Absatz 1 Satz 3. Das heißt allerdings nicht, dass niemand sonst geprüft wird: § 61 Absatz 1 BSIG erlaubt dem BSI gegenüber einzelnen besonders wichtigen Einrichtungen schon heute, Audits, Prüfungen oder Zertifizierungen anzuordnen. Nur die turnusmäßige Vorlage von Nachweisen nach § 61 Absatz 3 ist frühestens drei Jahre nach Inkrafttreten möglich. Wichtige Einrichtungen werden nach § 62 BSIG anlassbezogen geprüft.

Eine ISO-27001-Zertifizierung ist nirgends vorgeschrieben. § 30 Absatz 2 Satz 1 verlangt, einschlägige Normen zu berücksichtigen. Berücksichtigen ist nicht zertifizieren.

Bußgeldhöhen sind differenziert. Der Rahmen bis zehn Millionen Euro beziehungsweise zwei Prozent des Gesamtumsatzes gilt nach § 65 BSIG für besonders wichtige Einrichtungen bei Verstößen gegen die Maßnahmenpflicht aus § 30 Absatz 1; bei wichtigen Einrichtungen sind es sieben Millionen beziehungsweise 1,4 Prozent. Der Verstoß gegen die Registrierungspflicht ist dagegen mit bis zu 500.000 Euro bewehrt. Wer "keine Registrierung, zehn Millionen" hört, hört eine falsche Zahl.

FAQ

Gilt das alles auch für Managed Kubernetes? Der Scope verschiebt sich, er verschwindet nicht. Control-Plane-Flags wie --audit-policy-file oder --encryption-provider-config setzen Sie bei AKS, EKS und GKE nicht selbst, sondern aktivieren die entsprechenden Anbieterfunktionen und dokumentieren das. Alles ab Workload-Ebene — RBAC, NetworkPolicies, Pod Security, Image-Herkunft, Service-Accounts — liegt unverändert bei Ihnen.

Reicht es, die Kategorien einmal abzuarbeiten? Nein. Das BSI schreibt in seinen FAQ zu NIS-2: "Das NIS‑2‑Umsetzungsgesetz sieht keine allgemeine Übergangsfrist vor." Nummer 6 verlangt zudem ausdrücklich Verfahren zur Wirksamkeitsbewertung — also Wiederholung, nicht Einmalaktion.

Was ist mit der Registrierung beim BSI? Registrierung nach § 33 BSIG und Maßnahmen nach § 30 BSIG sind zwei getrennte Pflichten. Das BSI schreibt auf seiner Seite für NIS-2-regulierte Unternehmen: "Die gesetzliche Registrierungsfrist ist bereits abgelaufen." Die Maßnahmenpflicht läuft davon unabhängig.

Womit fange ich an, wenn nichts davon existiert? Mit den drei Punkten, die Defaults sind und praktisch jeden Cluster betreffen: Secrets liegen unverschlüsselt in etcd, es gibt keine NetworkPolicies, und kein Namespace hat ein Pod-Security-Label. Danach Audit-Logging und der Restore-Test. Eine vollständigere Reihenfolge steht im Härtungs-Leitfaden.

Fazit

§ 30 BSIG verlangt zehn Dinge, von denen sieben im Cluster sichtbar werden: Audit-Policy, Backup mit getestetem Restore, Image-Herkunft, Patch-Stand, Benchmark-Lauf, Secrets-Verschlüsselung, RBAC plus NetworkPolicy plus Pod Security. Der Aufwand liegt weniger im Umsetzen als im Nachweisen — Absatz 1 Satz 3 verlangt Dokumentation, und genau die fehlt bei den meisten technisch ordentlich betriebenen Clustern.

Welche der zehn Kategorien in Ihrer Umgebung heute unbelegt sind, klärt der NIS2-Check für Kubernetes: pro Kategorie prüfbare Fragen, die Sie mit kubectl oder einem Blick in die Anbieterkonsole beantworten, und zu jeder Lücke der konkrete nächste Schritt.

Hinweis: Dieser Artikel ist eine technische Einordnung des Gesetzestextes auf Kubernetes-Mechanismen und stellt keine Rechtsberatung dar. Die Zuordnung einzelner Cluster-Kontrollen zu den Kategorien des § 30 Absatz 2 BSIG ist fachliche Auslegung; ein amtliches Mapping existiert nicht. Ob und als was Ihr Unternehmen unter das BSIG fällt, richtet sich nach § 28 BSIG und den Anlagen 1 und 2 und ist eine Einzelfallprüfung. Für eine verbindliche rechtliche Bewertung ziehen Sie bitte eine Rechtsberatung hinzu. Rechtsstand der zitierten Vorschriften: BSIG in der Fassung des NIS2UmsuCG, abgerufen am 2. August 2026.