NIS2-Quick-Check für Kubernetes · kubernetes-administration.de · technische Selbsteinschätzung, keine Rechtsberatung

Kostenlos · 24 Fragen · Ergebnis ohne E-Mail-Abfrage

NIS2-Quick-Check für Kubernetes

24 Fragen entlang der zehn Maßnahmenkategorien des § 30 Abs. 2 BSIG, jede in wenigen Minuten mit kubectl oder einem Blick in die Betriebsdokumentation beantwortbar. Sie bekommen einen gewichteten Erfüllungsgrad, eine Aufschlüsselung pro Kategorie und zu jeder Lücke die konkrete technische Maßnahme samt Rechtsgrundlage. Ohne Formular, ohne Registrierung, ohne Datenübertragung.

Ihre Antworten verlassen diesen Browser nicht

Der Check läuft vollständig clientseitig. Es gibt keinen Server-Aufruf, keine Speicherung und keine E-Mail-Abfrage vor dem Ergebnis. Ein Reload löscht alle Antworten.

Technische Selbsteinschätzung, keine Rechtsberatung

Dieser Check ist eine technische Selbsteinschätzung des Kubernetes-Betriebs. Er ersetzt keine Rechtsberatung, trifft keine Aussage darüber, ob Ihr Unternehmen unter NIS2 fällt, und übernimmt keine Gewähr für Vollständigkeit im Einzelfall.

0 von 24 Fragen beantwortet
Das Ergebnis unten aktualisiert sich mit jeder Antwort.
—
Erfüllungsgrad

§ 30 Abs. 2 Nr. 1 — Risikoanalyse und Sicherheitskonzepte

0/2 beantwortet

Gesetzeswortlaut: Konzepte in Bezug auf die Risikoanalyse und auf die Sicherheit in der Informationstechnik

Frage 1 · Hoch

Existiert ein datiertes Dokument, das für jeden produktiven Cluster den Schutzbedarf der darin betriebenen Anwendungen festhält und begründet, welche Anwendungen sich einen Cluster teilen dürfen?

Frage 2 · Mittel

Läuft jede Anwendung in einem eigenen Namespace, und ist der Namespace default frei von produktiven Workloads?

§ 30 Abs. 2 Nr. 2 — Bewältigung von Sicherheitsvorfällen

0/3 beantwortet

Gesetzeswortlaut: Bewältigung von Sicherheitsvorfällen

Frage 3 · Kritisch

Ist Kubernetes Audit-Logging am kube-apiserver aktiviert und werden die Logs außerhalb des Clusters gespeichert?

Frage 4 · Kritisch

Ist eine namentlich benannte Person mit definierter Erreichbarkeit festgelegt, die einen erheblichen Sicherheitsvorfall innerhalb von 24 Stunden an das BSI melden kann, und wurde der Meldeweg mindestens einmal durchgespielt?

Frage 5 · Hoch

Können Sie für einen beliebigen produktiven Pod innerhalb von 30 Minuten belegen, welches Image mit welchem sha256-Digest läuft, wer es deployed hat und wann?

§ 30 Abs. 2 Nr. 3 — Betrieb, Backup, Krisenmanagement

0/2 beantwortet

Gesetzeswortlaut: Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement

Frage 6 · Kritisch

Umfasst Ihr Cluster-Backup alle sechs vom BSI geforderten Bestandteile: Persistent Volumes, Konfigurationsdateien von Kubernetes und Control Plane, den aktuellen Cluster-Zustand inklusive Erweiterungen, etcd, alle Infrastrukturanwendungen und die Datenhaltung der Code- und Image-Registries?

Frage 7 · Kritisch

Wurde in den letzten 12 Monaten ein vollständiger Restore in einen leeren Cluster durchgeführt, und sind Datum sowie die tatsächlich benötigte Wiederherstellungszeit protokolliert?

§ 30 Abs. 2 Nr. 4 — Sicherheit der Lieferkette

0/3 beantwortet

Gesetzeswortlaut: Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern

Frage 8 · Kritisch

Stammen alle produktiven Images aus einer kontrollierten Registry, ist für jedes Basis-Image identifizierbar wer es erstellt hat, und ist keines der eingesetzten Basis-Images als deprecated markiert?

Frage 9 · Hoch

Werden Images per sha256-Digest referenziert oder ihre Signatur beim Deploy per Admission Controller geprüft — statt über veränderliche Tags wie latest?

Frage 10 · Hoch

Ist für jeden Cluster-Betriebsdienstleister und für jedes eingesetzte Cluster-Add-on (CNI, CSI, Ingress-Controller, Monitoring, Backup-Tool) geregelt, wie Sicherheitslücken gemeldet werden, und kennen Sie die zugesagte Reaktionszeit?

§ 30 Abs. 2 Nr. 5 — Erwerb, Entwicklung, Wartung, Schwachstellen

0/3 beantwortet

Gesetzeswortlaut: Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen

Frage 11 · Kritisch

Läuft Ihre Kubernetes-Version noch im Patch-Support, also innerhalb der drei aktuellsten Minor-Releases?

Frage 12 · Hoch

Werden produktive Images sowohl beim Build als auch fortlaufend im laufenden Betrieb auf bekannte Schwachstellen gescannt, und existiert eine schriftlich festgelegte Frist, bis wann ein kritischer Fund gepatcht sein muss?

Frage 13 · Hoch

Liegen alle Cluster-Manifeste versioniert in einem Repository, sodass jede Änderung an der Cluster-Konfiguration einem Autor und einem Zeitpunkt zuordenbar ist — oder gibt es produktive Ressourcen, die per kubectl apply von einem Laptop entstanden sind?

§ 30 Abs. 2 Nr. 6 — Bewertung der Wirksamkeit

0/2 beantwortet

Gesetzeswortlaut: Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Sicherheit in der Informationstechnik

Frage 14 · Hoch

Wurde in den letzten 12 Monaten ein automatisierter Konfigurations-Audit gegen einen anerkannten Benchmark gefahren — etwa der CIS Kubernetes Benchmark via kube-bench — und liegt das Ergebnis datiert und auffindbar ab?

Frage 15 · Mittel

Könnten Sie der Aufsicht heute ohne Vorbereitungszeit vorlegen, welche technischen Maßnahmen im Cluster gesetzt sind, wer sie verantwortet und wann sie zuletzt überprüft wurden?

§ 30 Abs. 2 Nr. 7 — Schulung und Sensibilisierung

0/1 beantwortet

Gesetzeswortlaut: grundlegende Schulungen und Sensibilisierungsmaßnahmen im Bereich der Sicherheit in der Informationstechnik

Frage 16 · Hoch

Hat die Geschäftsleitung selbst — nicht die IT — in den letzten 12 Monaten nachweislich an einer Schulung zu IT-Sicherheitsrisiken teilgenommen?

§ 30 Abs. 2 Nr. 8 — Kryptographische Verfahren

0/2 beantwortet

Gesetzeswortlaut: Konzepte und Prozesse für den Einsatz von kryptographischen Verfahren

Frage 17 · Kritisch

Ist Encryption at Rest für die Secret-API aktiviert — oder liegen Ihre Kubernetes Secrets unverschlüsselt in etcd?

Frage 18 · Kritisch

Sind Kubernetes-API, kubelet-API und etcd nicht öffentlich aus dem Internet erreichbar, ist der API-Zugang auf definierte Quell-IP-Bereiche beschränkt, und ist anonymer Zugriff abgeschaltet?

§ 30 Abs. 2 Nr. 9 — Personal, Zugriffskontrolle, IKT-Verwaltung

0/5 beantwortet

Gesetzeswortlaut: Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen

Frage 19 · Kritisch

Wie viele Subjekte sind an die Rolle cluster-admin gebunden, und ist jedes davon einer benannten Person oder einem dokumentierten Dienst zuordenbar?

Frage 20 · Kritisch

Ist der Cluster-Zugang an Ihre zentrale Identität gekoppelt (OIDC, Entra ID, LDAP), sodass das Ausscheiden einer Person den Cluster-Zugriff automatisch beendet — oder existieren kubeconfig-Dateien mit X.509-Client-Zertifikaten?

Frage 21 · Kritisch

Existiert für jeden produktiven Namespace eine default-deny NetworkPolicy, und unterstützt das eingesetzte CNI-Plugin NetworkPolicies überhaupt?

Frage 22 · Kritisch

Ist für alle produktiven Namespaces ein Pod Security Standard auf baseline oder restricted im Modus enforce gesetzt?

Frage 23 · Hoch

Nutzen produktive Pods den default-Service-Account, und wird der Service-Account-Token auch dort eingehängt, wo die Anwendung ihn gar nicht braucht?

Achtung, umgekehrte Richtung: hier ist Nein der gute Fall.

§ 30 Abs. 2 Nr. 10 — Multi-Faktor-Authentifizierung, gesicherte Kommunikation

0/1 beantwortet

Gesetzeswortlaut: Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung

Frage 24 · Kritisch

Ist für jeden menschlichen Zugang zur Kubernetes-Steuerungsebene MFA erzwungen — also für kubectl, die Cloud-Konsole, ein Management-UI wie Rancher und das CI/CD-System, das ins Cluster deployen darf?

Ergebnis: NIS2-Quick-Check Kubernetes

Beantworten Sie mindestens eine Frage. Das Ergebnis erscheint hier sofort — ohne Formular, ohne E-Mail-Adresse.

Registrierung ist nicht Umsetzung

Das Gesetz zur Umsetzung der NIS-2-Richtlinie ist am 6. Dezember 2025 in Kraft getreten und hat das BSIG neu gefasst. Nach § 33 BSIG muss sich eine betroffene Einrichtung spätestens drei Monate, nachdem sie erstmals oder erneut als besonders wichtige oder wichtige Einrichtung gilt, beim BSI registrieren. Das BSI stellt auf seiner Themenseite für NIS-2-regulierte Unternehmen fest, dass die gesetzliche Registrierungsfrist bereits abgelaufen ist.

Damit ist aber nur ein Verwaltungsakt erledigt. Die eigentliche Pflicht steht in § 30 BSIG: geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen, konkretisiert in zehn Kategorien, dauerhaft. Und Satz 3 des Absatzes 1 macht daraus eine eigenständige Dokumentationspflicht — eine technisch saubere, aber undokumentierte Umgebung ist gegenüber der Aufsicht angreifbar. Das BSI schreibt in seiner FAQ ausdrücklich, dass das Gesetz keine allgemeine Übergangsfrist vorsieht.

Genau an dieser Stelle setzt der Check an. Er prüft nicht, ob Sie registriert sind. Er prüft, ob der Kubernetes-Betrieb das hält, was § 30 Abs. 2 BSIG verlangt.

Wer den Cluster betreibt, ist Teil Ihrer Lieferkette

§ 30 Abs. 2 Nr. 4 BSIG erfasst ausdrücklich die sicherheitsbezogenen Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern. Für einen Kubernetes-Betrieb heißt das: nicht nur der Cloud-Anbieter zählt, sondern jedes Add-on im Cluster — CNI, CSI-Treiber, Ingress-Controller, Monitoring-Stack, Backup-Werkzeug. Ein großer Teil davon sind Community-Projekte ohne Vertragspartner und ohne zugesagte Reaktionszeit. Das ist kein Verbot, aber es ist eine Lücke, die benannt und dokumentiert sein muss.

Managed Service Provider und Managed Security Service Provider sind im Übrigen in Anlage 1 BSIG selbst als Einrichtungsarten gelistet (Nummern 6.1.10 und 6.1.11, Sektor Digitale Infrastruktur). Ein Betriebsdienstleister ist also je nach Größe nicht nur Lieferant eines Betroffenen, sondern selbst regulierte Einrichtung. Das ist eine sinnvolle Frage an jeden Anbieter, mit dem Sie gerade sprechen.

Was der Check nicht leistet

  • Keine Betroffenheitsfeststellung. Ob Sie als besonders wichtige oder wichtige Einrichtung gelten, ergibt sich aus § 28 BSIG und den Anlagen 1 und 2, mit Zurechnungs- und Ausnahmeregeln, die eine Einzelfallprüfung verlangen.
  • Keine Rechtsberatung. Die Zuordnung einzelner Kubernetes-Kontrollen zu einer Nummer des § 30 Abs. 2 BSIG ist fachliche Auslegung. Ein amtliches Mapping des Gesetzes auf Kubernetes existiert weder vom BSI noch von der ENISA.
  • Kein Cluster-Audit. Der Check fragt nach Ihrer Einschätzung, er sieht den Cluster nicht. Ein automatisierter Konfigurations-Audit gegen den CIS Kubernetes Benchmark, etwa mit kube-bench, liefert belastbare Werte — das ist Frage 14 in diesem Katalog, nicht sein Ergebnis.
  • Keine organisatorische Vollabdeckung. § 30 Abs. 2 BSIG gilt für die gesamte Einrichtung. Dieser Katalog deckt den Kubernetes-Anteil ab, nicht Endgeräte, nicht Netzwerk außerhalb des Clusters, nicht physische Sicherheit.

Häufige Fragen

Sagt mir der Check, ob mein Unternehmen unter NIS2 fällt?

Nein. Ob eine Einrichtung als besonders wichtig oder wichtig gilt, richtet sich nach § 28 BSIG und den Anlagen 1 und 2. Dort greifen Zurechnungs- und Ausnahmeregeln, die eine Einzelfallprüfung erfordern — unter anderem die KMU-Empfehlung 2003/361/EG für die Schwellenwerte, die Möglichkeit, vernachlässigbare Nebentätigkeiten außer Betracht zu lassen, die Ausnahme für Finanzunternehmen im Anwendungsbereich der DORA-Verordnung sowie Ausnahmen für Telekommunikations- und Energienetzbetreiber nach EnWG. Der Check setzt voraus, dass Sie von einer Betroffenheit ausgehen, und prüft nur die technische Seite der Maßnahmen nach § 30 BSIG.

Reicht die Registrierung beim BSI?

Nein. Die Registrierung nach § 33 BSIG ist ein Verwaltungsakt: spätestens drei Monate, nachdem eine Einrichtung erstmals oder erneut als besonders wichtige oder wichtige Einrichtung gilt. Die Maßnahmenpflicht aus § 30 BSIG besteht davon unabhängig und dauerhaft. Das BSI stellt in seiner FAQ ausdrücklich klar, dass das NIS-2-Umsetzungsgesetz keine allgemeine Übergangsfrist vorsieht.

Wie hoch sind die Bußgelder wirklich?

Differenziert. Nach § 65 Absatz 5 BSIG sind Verstöße unter anderem gegen § 30 Absatz 1 Satz 1 (Maßnahmen), § 30 Absatz 1 Satz 3 (Dokumentation) und § 32 (Meldungen) bei besonders wichtigen Einrichtungen mit bis zu 10 Millionen Euro und bei wichtigen Einrichtungen mit bis zu 7 Millionen Euro bewehrt. Ab einem Gesamtumsatz von mehr als 500 Millionen Euro kann die Geldbuße stattdessen bis zu 2 Prozent beziehungsweise 1,4 Prozent des weltweiten Gesamtumsatzes betragen (§ 65 Absätze 6 und 7 BSIG). Der reine Verstoß gegen die Registrierungspflicht liegt dagegen bei bis zu 500.000 Euro. Der teurere Hebel ist also die Maßnahmenpflicht, nicht die Registrierung.

Haftet die Geschäftsführung persönlich?

§ 38 Absatz 2 BSIG regelt eine Innenhaftung gegenüber der eigenen Einrichtung nach den auf die Rechtsform anwendbaren Regeln des Gesellschaftsrechts — und nach dem BSIG selbst nur subsidiär, wenn das Gesellschaftsrecht keine solche Regelung enthält. Eine neue Außenhaftung gegenüber Dritten ist damit nicht geschaffen. Unmittelbar und persönlich adressiert ist dagegen § 38 Absatz 3 BSIG: die Pflicht der Geschäftsleitung, regelmäßig selbst an Schulungen teilzunehmen. Der schärfste aufsichtliche Hebel ist § 61 Absatz 9 Satz 2 Nummer 2 BSIG — bei besonders wichtigen Einrichtungen kann die zuständige Aufsichtsbehörde als letztes Mittel unzuverlässigen Geschäftsleitungen die Ausübung ihrer Tätigkeit vorübergehend untersagen, wenn Anordnungen des BSI trotz Fristsetzung nicht erfüllt werden.

Schreibt NIS2 ein Angriffserkennungssystem und externe Audits vor?

Nicht allgemein. Die Pflicht, Systeme zur Angriffserkennung einzusetzen, trifft nach § 31 Absatz 2 BSIG ausschließlich Betreiber kritischer Anlagen. Der turnusmäßige Nachweis durch Sicherheitsaudits, Prüfungen oder Zertifizierungen alle drei Jahre nach § 39 BSIG ebenfalls. Bei sonstigen besonders wichtigen Einrichtungen kann das BSI Nachweise nach § 61 Absatz 3 BSIG frühestens drei Jahre nach Inkrafttreten des Gesetzes anordnen; wichtige Einrichtungen werden nach § 62 BSIG nur anlassbezogen geprüft. Was für alle gilt, ist die Dokumentationspflicht aus § 30 Absatz 1 Satz 3 BSIG.

Werden meine Antworten gespeichert oder übertragen?

Nein. Der Check läuft vollständig im Browser. Es gibt keinen Server-Aufruf mit Ihren Antworten, keine Speicherung und keine E-Mail-Abfrage vor dem Ergebnis. Ein Reload löscht alles. Wenn Sie das Ergebnis behalten wollen, nutzen Sie die Druckfunktion im Ergebnisblock.

Rechtsstand und Quellen

Alle Paragraphenangaben beziehen sich auf das BSIG in der Fassung des NIS2-Umsetzungsgesetzes, in Kraft seit dem 6. Dezember 2025. Technische Belege stammen aus der Kubernetes-Dokumentation, dem BSI IT-Grundschutz-Kompendium Edition 2023 (Bausteine APP.4.4 Kubernetes und SYS.1.6 Containerisierung) und dem CIS Kubernetes Benchmark v1.12.0. Control-Nummern verschieben sich zwischen Benchmark-Versionen, daher ist die Version überall mitgeführt.

Ein Hinweis zur Formulierung: Artikel 20 Abs. 1 der NIS-2-Richtlinie verlangt von den Leitungsorganen, die Risikomanagementmaßnahmen zu „billigen“. Das deutsche Gesetz sagt in § 38 Abs. 1 BSIG stattdessen „umzusetzen und ihre Umsetzung zu überwachen“. Wo der Begriff Billigung auftaucht, ist es Richtlinientext, nicht BSIG.

Nach dem Check

Die meisten Lücken aus diesem Katalog sind Betriebsarbeit, keine Projektarbeit: Audit- Logging mit externer Ablage, ein verifizierter Restore, Pod Security Standards auf enforce, OIDC statt kubeconfig-Zertifikate, ein wiederkehrender kube-bench-Lauf mit datiertem Ergebnis. Wer das nicht selbst dauerhaft leisten will, kann den Kubernetes-Betrieb abgeben — was das kostet, steht auf der Preisseite.

Technische Selbsteinschätzung, keine Rechtsberatung

Dieser Quick-Check ist eine technische Selbsteinschätzung des Kubernetes-Betriebs auf Basis Ihrer eigenen Angaben. Er ersetzt keine Rechtsberatung, stellt nicht fest, ob Ihr Unternehmen unter das BSIG fällt, und übernimmt keine Gewähr für Vollständigkeit im Einzelfall. Die Zuordnung der Kubernetes-Kontrollen zu den Nummern des § 30 Abs. 2 BSIG ist fachliche Auslegung. Für die verbindliche Beurteilung der Betroffenheit und der Pflichtenlage ziehen Sie bitte rechtliche Beratung hinzu. Betreiber dieser Seite: Pexon Consulting GmbH — siehe Impressum.