NIS2 im Kubernetes-Betrieb: Welche Nachweise ein Prüfer sehen will
NIS2 verlangt keine bestimmte Technik, sondern Maßnahmen und Belege. Für den Kubernetes-Betrieb heißt das: persönliche Zugänge, ein lückenloses Protokoll und getestete Backups.
Die NIS2-Richtlinie hat die Frage verschoben, die Kunden und Prüfer an SaaS-Anbieter stellen. Früher hieß sie: Haben Sie ein Sicherheitskonzept? Heute heißt sie: Zeigen Sie mir, dass es gelebt wird. Für den Kubernetes-Betrieb ist das eine gute Nachricht, denn fast alles, was ein Prüfer sehen will, lässt sich aus dem Betrieb selbst belegen, wenn er richtig aufgebaut ist.
Dieser Beitrag ist keine Rechtsberatung. Ob Ihr Unternehmen selbst unter NIS2 fällt, hängt von Sektor und Größe ab, das klären Sie mit Ihrer Rechtsberatung. Aber auch wer nicht darunter fällt, bekommt die Fragen: von Kunden, die ihre Lieferkette prüfen müssen.
Was verlangt Art. 21 der NIS2-Richtlinie?
Artikel 21 der Richtlinie zählt Maßnahmen auf, die ein betroffenes Unternehmen treffen muss. Für den Betrieb von Anwendungen auf Kubernetes sind sieben davon greifbar:
- Zugriffskontrolle und Verwaltung von Berechtigungen
- Mehr-Faktor-Authentifizierung
- Kryptografie und Verschlüsselung
- Aufrechterhaltung des Betriebs: Backups und Wiederherstellung
- Bewältigung von Sicherheitsvorfällen
- Sicherheit bei Wartung, einschließlich Umgang mit Schwachstellen
- Sicherheit der Lieferkette
Die übrigen, etwa Risikoanalyse, Schulungen und Personalsicherheit, sind organisatorisch. Sie lassen sich nicht aus einem Cluster belegen.
Welche Fragen stellt ein Prüfer, und welche Belege beantworten sie?
Frage des Prüfers | Schwacher Beleg | Starker Beleg |
|---|---|---|
Wer hat Zugriff auf die Produktion? | Eine Liste im Wiki | Nutzerliste mit Rollen aus dem System selbst |
Ist Mehr-Faktor Pflicht? | Eine Richtlinie | Anmeldung ohne zweiten Faktor ist technisch unmöglich |
Wer hat am 12. März was geändert? | Git-Historie, sofern alles in Git lag | Protokoll jeder Änderung mit Person und Zeit |
Funktionieren Ihre Backups? | Ein Cron-Job | Protokoll einer Wiederherstellung aus diesem Quartal |
Wie sind Geheimnisse geschützt? | Kubernetes Secrets | Verschlüsselt, nicht auslesbar, Zugriff protokolliert |
Wie aktuell ist die Plattform? | Wir aktualisieren regelmäßig | Versionsstand und Datum der letzten Upgrades |
Wie bemerken Sie Vorfälle? | Kunden melden sich | Alarme mit Zeitstempel und Empfänger |
Welche Lücken finden Prüfer am häufigsten?
Die geteilte kubeconfig. Ein Admin-Token, drei Kollegen, eine CI-Pipeline. Niemand kann sagen, wer eine Änderung gemacht hat, und beim Abschied eines Kollegen müsste der Token rotiert werden, was niemand tut. Ein Prüfer sieht das in fünf Minuten.
Backups ohne Wiederherstellung. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung. Der Beleg, den ein Prüfer sehen will, ist eine Wiederherstellung mit Datum, am besten in eine Kopie neben der laufenden Datenbank.
Secrets, die nur kodiert sind. Ein Kubernetes Secret ist Base64, keine Verschlüsselung. Wer im Namespace Secrets lesen darf, liest alle Passwörter. Warum das so ist und wie es besser geht, steht in Kubernetes Secrets: Warum Base64 keine Verschlüsselung ist.
Updates nach Gefühl. Eine Kubernetes-Version, die ihr Support-Ende überschritten hat, ist eine Schwachstelle mit Ansage. Ein Upgrade pro Quartal ist leichter zu belegen und leichter durchzuführen als eines alle zwei Jahre.
Meldepflichten brauchen Zeitstempel
NIS2 verlangt bei erheblichen Vorfällen eine Frühwarnung innerhalb von 24 Stunden und eine Meldung innerhalb von 72 Stunden. Beides setzt voraus, dass Sie wissen, wann ein Vorfall begann. Ein Alarm mit Zeitstempel, ein Protokoll der Änderungen davor und die Logs der betroffenen Anwendung sind die Grundlage jeder Meldung. Wer erst durch Kundenanrufe von einem Ausfall erfährt, beginnt die Frist mit einem Rückstand. Wie Logs und Verfügbarkeit ohne eigenen Monitoring-Stack sichtbar werden, zeigt Logs & Monitoring.
Ein Nachweispaket für den Kubernetes-Betrieb
Was sich bewährt hat, ist eine Mappe, die jedes Quartal aus dem Betrieb erzeugt wird, statt vor dem Audit zusammengesucht:
- Nutzerliste mit Rollen und Status der Mehr-Faktor-Anmeldung
- Protokoll der Änderungen des Quartals, gefiltert nach Produktion
- Beleg einer Wiederherstellung: welches Backup, wohin, wann, von wem
- Versionsstand von Kubernetes und Add-ons mit Datum des letzten Upgrades
- Liste der Alarmkanäle und der Alarme des Quartals
- Standort der Daten und die Liste der Dienstleister
Die Lieferkette: Fragen Ihrer Kunden
Auch wenn Ihr Unternehmen selbst nicht unter NIS2 fällt: Ihre Kunden prüfen ihre Dienstleister, und ein SaaS-Anbieter ist genau das. Die Fragebögen ähneln sich stark:
- Wo werden unsere Daten verarbeitet, und welche Unterauftragnehmer sind beteiligt?
- Wie schnell informieren Sie uns über einen Sicherheitsvorfall, der uns betrifft?
- Wie ist der Zugriff Ihrer Mitarbeitenden auf unsere Daten geregelt und protokolliert?
- Wie oft sichern Sie, und wann haben Sie zuletzt eine Wiederherstellung getestet?
- Wie schnell spielen Sie Sicherheitsupdates ein?
Wer die Belege aus dem vorherigen Abschnitt hat, beantwortet diese Fragen mit Anhängen statt mit Absichtserklärungen. Das verkürzt Vertragsverhandlungen spürbar, gerade mit größeren Kunden.
Ein Quartal Nachweise in der Praxis
So sieht die Routine aus, wenn sie einmal eingespielt ist. Am Ende jedes Quartals, eine Stunde Arbeit:
- Nutzerliste exportieren und mit der Personalliste abgleichen: Hat jemand das Team verlassen und noch Zugang?
- Audit-Log des Quartals für die Produktion filtern und ablegen.
- Eine Datenbank aus einem Backup in eine Kopie wiederherstellen, kurz prüfen, dokumentieren, Kopie löschen.
- Versionsstand von Kubernetes und Add-ons notieren, fällige Upgrades einplanen.
- Die Alarme des Quartals durchsehen: Gab es Vorfälle, und wurden sie bearbeitet?
Die Mappe dieses Quartals ist die Antwort auf die nächste Kundenfrage und der Anfang des nächsten Audits.
Was nicht aus dem Cluster kommt
Ehrlich bleibt: Ein gut geführter Kubernetes-Betrieb deckt nur einen Teil von NIS2 ab. Risikoanalyse, Sicherheitsrichtlinien, Schulungen, das Verfahren für Meldungen an Behörden und die Bewertung Ihrer eigenen Dienstleister sind organisatorische Arbeit. Und die Sicherheit Ihres eigenen Codes, von Abhängigkeiten bis zur Eingabeprüfung, liegt in der Entwicklung. Der Betrieb liefert die Belege für seinen Teil, nicht für alles.
Wie Clusterward das abdeckt
Clusterward erzwingt die technischen Teile und schreibt sie mit: persönliche Konten mit Pflicht-Mehr-Faktor, Rollen pro Bereich und Anwendung, ein Audit-Log mit Person oder API-Token zu jeder Änderung, verschlüsselte Secrets, die nach dem Speichern nicht mehr angezeigt werden, Backups mit Wiederherstellung neben der laufenden Datenbank und Alarme an Ihre Kanäle. Der Export der Konfiguration samt Audit-Log des letzten Jahres ist eine Datei. Die Zuordnung zu den Maßnahmen aus Art. 21 steht unter Audit & NIS2, die Rollen und Anmeldung unter Sicherheit & Zugriff, die Backups unter Backups & Wiederherstellung.
Fazit
NIS2 prüft nicht, ob Sie Kubernetes kennen, sondern ob Sie belegen können, wer was darf, wer was getan hat und wie Daten zurückkommen. Bauen Sie den Betrieb so, dass diese Belege nebenbei entstehen: persönliche Zugänge, ein Protokoll, getestete Wiederherstellung, regelmäßige Updates. Dann ist das Audit ein Export und kein Projekt.
Ihre Prüfliste für den Kubernetes-Betrieb? Schicken Sie uns die Fragen Ihres Prüfers oder Kunden. Wir zeigen, welche davon der Betrieb mit Clusterward beantwortet. Frage stellen →
Quellen und weiterführende Links
Häufige Fragen
- Von den Maßnahmen aus Artikel 21 sind sieben für den Betrieb greifbar: Zugriffskontrolle und Berechtigungsverwaltung, Mehr-Faktor-Authentifizierung, Kryptografie, Backups und Wiederherstellung, Bewältigung von Sicherheitsvorfällen, Sicherheit bei Wartung einschließlich Schwachstellen sowie Sicherheit der Lieferkette. Risikoanalyse, Schulungen und Personalsicherheit sind organisatorisch.