Zehn Nachweisartefakte, die Ihr Cluster selbst erzeugt

TL;DR Der Regelfall im Audit ist nicht die fehlende Kontrolle, sondern die vorhandene Kontrolle ohne Beleg. Zehn Artefakte decken die technische Ebene ab, jedes entsteht aus einem Befehl oder einer Datei, die ohnehin existiert. Das Sammelskript und die Verzeichnisvorlage am Ende sind zum Kopieren gedacht.

Die unangenehme Frage im Audit ist selten, ob eine Kontrolle existiert. Sie lautet, woran der Prüfer sie sehen kann.

In den Clustern, die wir übernehmen, sind die technischen Kontrollen meist da. Zugänge laufen über ein zentrales Identitätssystem, Images kommen aus einer eigenen Registry, Backups laufen nachts durch. Was fehlt, ist der Beleg. Und weil er fehlt, beginnt vier Wochen vor dem Termin die Fleißarbeit: Screenshots, Excel-Listen, Zuarbeit aus mehreren Teams, ein Stand, der schon beim Zusammentragen veraltet.

Der Ausweg ist nicht mehr Dokumentation, sondern eine andere Quelle. In einer deklarativ beschriebenen Plattform liegt der Soll-Zustand als Code vor, die Änderungshistorie entsteht als Nebenprodukt, und die Abweichung wird gemessen statt behauptet. Damit ist der Nachweis kein eigenes Projekt mehr, sondern ein Export.

Dieser Artikel listet zehn solcher Exporte, je einen für einen technischen Kontrollbereich. Zu jedem steht der Befehl, der ihn erzeugt, und der Punkt, an dem er trotzdem nicht trägt.

Woran man ein Nachweisartefakt erkennt

Drei Eigenschaften trennen einen Beleg von einer Behauptung. Sie sind unser Arbeitsmaßstab und keine Vorgabe aus einer Norm.

Ein Artefakt trägt seinen Erzeugungszeitpunkt. Fehlt der Stand, muss der Prüfer glauben, dass die Ausgabe aktuell ist. Es ist reproduzierbar, weil der Befehl daneben steht: Wer ihn ausführt, kommt zum selben Ergebnis, und das unterscheidet den Export vom Screenshot. Und es deckt einen Zeitraum ab. Ein Stichtagswert sagt wenig über Wirksamkeit, interessant wird eine Kennzahl erst als Zeitreihe, weil sich daran ablesen lässt, ob der Zustand hält.

1. Asset-Inventar mit Digest statt Tag

Das Artefakt: Ein Inventarbericht über Workloads, Images, Namespaces und Ingress-Punkte, mit Stand und Erzeugungszeitpunkt.

Der Digest ist der Punkt, an dem es interessant wird. Ein Tag sagt, wie das Image heißt. Der Digest sagt, welches Artefakt tatsächlich läuft. Erst damit bedeutet „dieselbe Version” auch dasselbe Artefakt.

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}' | sort

Damit das Inventar vollständig bleibt, muss die Zuordnung erzwungen sein. Ohne Ownership- und Kritikalitäts-Label kein Deployment:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-ownership-labels
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-namespace-labels
      match:
        any:
          - resources:
              kinds: ["Namespace"]
      validate:
        message: "Namespace benoetigt die Labels owner und criticality."
        pattern:
          metadata:
            labels:
              cheveo.de/owner: "?*"
              cheveo.de/criticality: "low|medium|high"

Der Schutzbedarf gehört an dieselbe Stelle, und zwar als Label mit festem Wertebereich, nicht als Annotation. Annotationen sind Freitext: Sie lassen sich weder selektieren noch zählen, und damit ist die Aussage „jeder Workload trägt einen Schutzbedarf” eine Behauptung statt einer gemessenen Quote.

    - name: check-schutzbedarf
      match:
        any:
          - resources:
              kinds: ["Deployment", "StatefulSet"]
      validate:
        message: "Workload benoetigt das Label schutzbedarf: normal|hoch|sehr-hoch."
        pattern:
          metadata:
            labels:
              cheveo.de/schutzbedarf: "normal|hoch|sehr-hoch"

Woran es scheitert: Die Label-Konvention existiert als Wiki-Seite, aber nichts erzwingt sie. Nach einem halben Jahr trägt die Hälfte der Namespaces kein Label, und das Inventar zeigt Objekte ohne Verantwortlichen.

Und die zweite Grenze, die selten jemand ausspricht: Ein Cluster-Export ist ein Inventar der Container-Ebene, nicht des Systemverbunds. Die verwaltete Datenbank, das Identitätssystem, das Object Storage und die SaaS-Dienste daneben tauchen darin nicht auf. Wer den Export als vollständiges Asset-Inventar vorlegt, bekommt genau dazu die erste Rückfrage.

1b. Kommunikationsgraph aus den NetworkPolicies

Das Artefakt: Ein generierter Graph der erlaubten Verbindungen zwischen Namespaces, aus dem Ist-Stand der NetworkPolicies.

Die Objektliste sagt, was existiert. Die Frage nach dem Systemverbund ist eine andere: Wie hängt das zusammen, und wo verlässt Verkehr die Zone. Diesen Teil kann man erzeugen, statt ihn in Visio nachzuzeichnen, und ein gezeichnetes Netzdiagramm ist ohnehin nur so aktuell wie der Tag, an dem es entstand.

kubectl get netpol -A -o json \
  | jq -r '.items[] as $p | ($p.spec.ingress // [])[]? | (.from // [])[]? |
      [($p.metadata.namespace),
       (.namespaceSelector.matchLabels // {} | tostring),
       ($p.metadata.name)] | @tsv'

Die Ausgabe ist eine Kantenliste und lässt sich direkt nach Graphviz oder Mermaid schreiben. Der Nutzen liegt weniger im Bild als in dem, was auffällt: Namespaces ohne eingehende Regel, und Namespaces, die von überall erreichbar sind.

Woran es scheitert: Der Graph zeigt die erlaubten Pfade, nicht die genutzten. Ein Namespace kann eine weit offene Regel haben, die niemand braucht. Erst der Abgleich mit tatsächlichen Verbindungsdaten macht daraus eine Aussage über zu weite Rechte.

2. Audit-Policy und Retention als Code

Das Artefakt: Die Audit-Policy als versionierte Datei, die Aufbewahrungsregel ebenfalls, dazu das Protokoll einer Übung mit einem tatsächlich ausgelösten Alert.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterrolebindings", "rolebindings", "roles", "clusterroles"]
  - level: Metadata

Secrets stehen bewusst auf Metadata. Auf RequestResponse schreiben Sie den Inhalt jedes Secrets in das Audit-Log und verlagern das Problem, statt es zu lösen. Rechteänderungen dagegen gehören vollständig protokolliert, weil dort die Frage nach dem Wer und dem Wann gestellt wird.

Das Ziel liegt außerhalb des Clusters. Ein Log, das im selben Cluster liegt, ist mit ihm kompromittiert.

Woran es scheitert: Die Alarmierung existiert, hat aber keinen Empfänger mit Rufbereitschaft. Ein Alert ohne Empfänger ist kein Alert. Außerdem läuft die Erstmeldefrist nach einem Vorfall gegen eine Uhr, die stimmen muss, weshalb die NTP-Synchronisation selbst überwacht gehört.

3. Restore-Protokoll mit gemessener Dauer

Das Artefakt: Ein unterschriebenes Protokoll mit Datum, Umfang, verwendetem Backup, gemessener Dauer, Abweichungen und Verantwortlichem.

Backup-Erfolgsmeldungen sind kein Nachweis für Wiederherstellbarkeit. Sie belegen einen funktionierenden Schreibvorgang. Ob sich die Objekte im Zielcluster anlegen lassen, ob die Volumes Daten enthalten und wie lange es dauert, sagt nur der durchgeführte Test. Den Ablauf und die Vorlage dazu haben wir in einem eigenen Artikel beschrieben.

velero backup describe nightly-20260831 --details
velero restore describe restore-test-20260901 --details

Zum Protokoll gehört ein zweites Blatt, das fast immer fehlt: die Liste dessen, was die Wiederherstellung nicht zurückbringt. Ein neu aufgebauter Cluster hat eine neue Cluster-CA, also sind alle bestehenden kubeconfigs wertlos. Er hat einen neuen OIDC-Issuer, also müssen Workload Identity und die Vault-Anbindung neu eingerichtet werden. Jedes externe System, das ein Token auf diesen Cluster hält, muss neu verbunden werden. LoadBalancer bekommen neue Adressen, DNS zieht nach. Diese Liste ist bei jedem Cluster anders, sie kostet im Ernstfall die eigentliche Zeit, und sie entsteht nur im durchgeführten Test.

Und ein Detail für die Nachweiskette: Die wiederhergestellten Objekte tragen neue UIDs. Das Audit-Log aus der Zeit vor dem Restore lässt sich nicht mehr auf die heutigen Objekte beziehen. Der Restore ist damit eine Zäsur und gehört im Protokoll als solche vermerkt, sonst steht in einem ansonsten lückenlosen Änderungsnachweis eine Lücke, die niemand erklärt hat.

Woran es scheitert: Das Protokoll weist keinen Umfang aus. Dann weiß später niemand, was eigentlich bewiesen wurde, und der Nachweis zerfällt bei der ersten Rückfrage.

4. Policy-Report über verifizierte Images

Das Artefakt: Ein Report mit dem Anteil signatur-verifizierter Images, dazu die Registry-Allowlist als versionierte Datei und das SBOM-Archiv je Artefakt.

Lieferkette wird meist vertraglich gedacht. In einer Container-Umgebung ist sie technisch: Base-Images, Helm-Charts, Operatoren, CI-Plugins, alles was per Pull ins Haus kommt.

kubectl get policyreport -A -o jsonpath='{range .items[*].results[*]}{.policy}{"\t"}{.result}{"\n"}{end}' \
  | sort | uniq -c | sort -rn

Neben dem Report gehört ein zweites Artefakt hierher, das oft mit dem SBOM verwechselt wird: das Abhängigkeitsinventar. Der Unterschied ist einfach. Das SBOM ist das Ergebnis eines Builds, es sagt, was in einem Image steckt, und beantwortet unter Zeitdruck die Frage, ob eine gerade gemeldete Schwachstelle bei Ihnen vorkommt. Das Abhängigkeitsinventar ist das Ergebnis einer Entscheidung, es sagt, welche fremden Komponenten Sie überhaupt betreiben: Operatoren, Charts, Base-Images, CI-Plugins.

Je Zeile gehören vier Angaben hinein: Herkunft und eingesetzte Version; der Pflegezustand, gemessen statt geschätzt (letztes Release, Supportfenster, Trägerschaft, Status aktiv oder archiviert); die erteilten Cluster-Rechte, also welche RBAC-Rechte, Webhooks und CRDs die Komponente mitbringt; und die Entscheidung mit Datum und Person.

Die dritte Angabe ist die, die in keinem SBOM steht und bei einem Operator das eigentliche Risiko beschreibt: Der läuft nicht in einem Namespace vor sich hin, der hat clusterweite Rechte. Die Kandidatenliste dafür fällt übrigens aus Artefakt 1 heraus, Image-Digests und Registries stehen schon im Inventar, von Hand kommen nur die Spalten dazu, die im Cluster nicht stehen.

Woran es scheitert: Die Verifikation läuft im Audit-Modus. Nicht signierte Images werden gezählt und trotzdem gestartet. Der Report sieht dann aus wie ein Nachweis, belegt aber nur, dass jemand mitschreibt.

Und der Grund, warum sie im Audit-Modus landet, ist fast immer derselbe: Beim Spiegeln in die eigene Registry ist die Signatur nicht mitgekommen. Cosign legt sie als eigenes OCI-Artefakt neben dem Image ab, am selben Digest. Wer mit crane copy oder skopeo kopiert und die Signatur-Artefakte weglässt, hat anschließend Images, die die eigene Verifikation nicht bestehen, und stellt die Policy um, statt den Spiegel zu reparieren. Zwei Kontrollen, die einander aufheben, wenn man sie getrennt einführt. Beim Inventar ist der typische Fehlschlag ein anderer: Es wird einmal erhoben und nie wieder angefasst. Dann steht ein Ingress-Controller darin, dessen Projekt seit vierzehn Monaten archiviert ist, und kein Scan meldet das, weil niemand mehr CVEs dafür einreicht.

5. Schwachstellen mit Alterung und Ausnahmeregister

Das Artefakt: Ein Dashboard mit der Alterung offener Findings, eine Zeitreihe der Patch-Dauer je Schweregrad und ein Ausnahmeregister mit Frist.

Die Alterung ist der aussagekräftige Teil. Die Zahl offener Findings schwankt mit jedem Scan. Wie lange ein Finding offen bleibt, sagt etwas über den Prozess.

Jede Ausnahme braucht eine Begründung, einen Genehmigenden und ein Ablaufdatum:

# ausnahmen/CVE-2026-1234-checkout.yaml
cve: CVE-2026-1234
workload: produktion/checkout
schweregrad: high
begruendung: "Kein Fix verfuegbar, Angriffspfad durch NetworkPolicy unterbrochen."
genehmigt_von: "[Name, Rolle]"
erteilt_am: 2026-09-01
befristet_bis: 2026-10-15

Woran es scheitert: Ausnahmen ohne Ablaufdatum. Sie werden dauerhaft, und das Register belegt nach zwei Jahren nicht die Kontrolle, sondern ihre Umgehung.

6. Drift zwischen Git und Cluster

Das Artefakt: Die Abweichung zwischen Soll-Zustand in Git und Ist-Zustand im Cluster, als Kennzahl mit Verlauf, dazu die mittlere Zeit bis zur Korrektur.

Wirksamkeit wird sonst per Stichprobe geprüft. Hier wird sie fortlaufend gemessen, und das ist der Bereich, in dem eine deklarative Plattform strukturell im Vorteil ist.

argocd app list -o json \
  | jq -r '.[] | [.metadata.name, .status.sync.status, .status.health.status] | @tsv'

Woran es scheitert: Der Wert wird erhoben, aber nicht aufbewahrt. Ohne Verlauf beantwortet er die Frage nach dem Stichtag und nicht die nach der Wirksamkeit.

7. Voreinstellungen als belegbarer Zustand

Das Artefakt: Ein Report über Pod Security Standards und die deny-all-Grundregel, dazu die Adoptionsquote der Golden-Path-Templates.

kubectl get ns -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce'

# Namespaces mit einer Grundregel, die alles verbietet
kubectl get netpol -A -o json \
  | jq -r '.items[] | select(.spec.podSelector == {}) | .metadata.namespace' | sort -u

Die zweite Ausgabe ist gegen die erste zu halten. Jeder Namespace, der nur in der ersten Liste auftaucht, hat keine Grundregel.

Hier ist eine Ehrlichkeit fällig, die uns nichts kostet. Der eigentliche Nachweis für diesen Bereich ist der Schulungsnachweis, und den führt der Kunde beziehungsweise sein Informationssicherheitsbeauftragter. Die Plattform belegt die technische Hygiene, nicht die Sensibilisierung. Das ist der einzige der zehn Punkte, an dem unser Beitrag den Nachweis nur ergänzt.

Woran es scheitert: Die Standards sind gesetzt, aber der bequeme Weg führt daran vorbei. Der wirksamste Hebel für Hygiene ist nicht die Schulung, sondern der Standardpfad, und deshalb gehört die Adoptionsquote der Templates mit in den Report.

8. Zertifikatsinventar mit Laufzeiten

Das Artefakt: Ein Inventar aller Zertifikate mit Ablaufdatum, dazu die Rotationsprotokolle.

Abgelaufene Zertifikate sind der häufigste selbstverschuldete Ausfall. Das Inventar ist deshalb doppelt nützlich: als Beleg und als Frühwarnung.

kubectl get certificate -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status,ABLAUF:.status.notAfter' \
  | sort -k4

Woran es scheitert: Das Inventar erfasst nur, was cert-manager verwaltet. Manuell ausgestellte Zertifikate an Ingress-Punkten oder in Altsystemen fehlen darin, und genau die laufen ab.

9. RBAC-Stand mit Historie

Das Artefakt: Der RBAC-Stand als versionierte Datei mit Änderungshistorie, dazu die Protokolle der Zugriffsüberprüfung und das Break-Glass-Protokoll.

kubectl get clusterrolebindings,rolebindings -A -o yaml > rbac-stand.yaml

# Personen, die direkt berechtigt sind statt ueber eine Gruppe
kubectl get clusterrolebindings,rolebindings -A -o json \
  | jq -r '.items[] | select(.subjects != null) | .subjects[] | select(.kind=="User") | .name' \
  | sort -u

Die zweite Ausgabe sollte leer sein. Jeder Treffer ist eine Person, deren Zugang nicht am Identitätssystem hängt und die ein Offboarding deshalb überlebt. Prüfer werden an dieser Stelle regelmäßig fündig.

Woran es scheitert: Die Bindings sind in Git, aber daneben existieren dauerhafte kubeconfig-Dateien und statische Tokens. Der Nachweis zeigt dann eine Ordnung, die im Alltag umgangen wird.

10. MFA-Richtlinie mit Geltungsbereich

Das Artefakt: Der Export der MFA-Richtlinie aus dem Identitätssystem, mit Geltungsbereich, dazu die Zugriffsprotokolle und das dokumentierte Break-Glass-Verfahren.

Dieser Nachweis kommt nicht aus dem Cluster. Er kommt aus dem Identitätsprovider, und das ist keine Lücke, sondern die richtige Zuordnung: Der Cluster prüft Tokens, die Faktoren prüft das Identitätssystem.

Aus dem Cluster kommt nur der Gegenbeweis, nämlich jeder Zugangsweg, der daran vorbeiführt. Direkter SSH-Zugriff auf Nodes, öffentlich erreichbare administrative Schnittstellen, Service Accounts mit langlebigen Tokens für Personen.

Woran es scheitert: Die Richtlinie hat eine Ausnahmegruppe. Ein Geltungsbereich mit Ausnahme ist als Nachweis wenig wert, solange nicht dokumentiert ist, wer darin steht und warum.

Das Sammelskript

Ein Lauf, ein datiertes Verzeichnis, elf Dateien. Die Werkzeuge müssen vorhanden sein, sonst bleibt der jeweilige Export leer.

#!/usr/bin/env bash
set -euo pipefail

STAND="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
ZIEL="nachweise/$(date -u +%Y-%m-%d)"
mkdir -p "$ZIEL"
echo "Erzeugt: $STAND" > "$ZIEL/00-stand.txt"
kubectl version -o yaml >> "$ZIEL/00-stand.txt"

# 1 Asset-Inventar mit Digest
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}' \
  | sort > "$ZIEL/01-inventar.tsv"

# 1b Kommunikationsgraph als Kantenliste
kubectl get netpol -A -o json \
  | jq -r '.items[] as $p | ($p.spec.ingress // [])[]? | (.from // [])[]? |
      [($p.metadata.namespace),
       (.namespaceSelector.matchLabels // {} | tostring),
       ($p.metadata.name)] | @tsv' \
  > "$ZIEL/01b-kommunikationsgraph.tsv"

# 2 Audit-Policy und Aufbewahrung, aus dem Repository statt aus dem Cluster
cp platform/audit/policy.yaml platform/logging/retention.yaml "$ZIEL/" 2>/dev/null || true

# 4 Policy-Ergebnisse und Registry-Allowlist
kubectl get policyreport -A -o jsonpath='{range .items[*].results[*]}{.policy}{"\t"}{.result}{"\n"}{end}' \
  | sort | uniq -c | sort -rn > "$ZIEL/04-policy-report.txt"
kubectl get clusterpolicy -o yaml > "$ZIEL/04-policies.yaml"

# 6 Drift
argocd app list -o json \
  | jq -r '.[] | [.metadata.name, .status.sync.status, .status.health.status] | @tsv' \
  > "$ZIEL/06-drift.tsv"

# 7 Voreinstellungen
kubectl get ns -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce' \
  > "$ZIEL/07-pod-security.txt"
kubectl get netpol -A -o json \
  | jq -r '.items[] | select(.spec.podSelector == {}) | .metadata.namespace' \
  | sort -u > "$ZIEL/07-deny-all.txt"

# 8 Zertifikate
kubectl get certificate -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status,ABLAUF:.status.notAfter' \
  | sort -k4 > "$ZIEL/08-zertifikate.txt"

# 9 RBAC
kubectl get clusterrolebindings,rolebindings -A -o yaml > "$ZIEL/09-rbac.yaml"
kubectl get clusterrolebindings,rolebindings -A -o json \
  | jq -r '.items[] | select(.subjects != null) | .subjects[] | select(.kind=="User") | .name' \
  | sort -u > "$ZIEL/09-direktberechtigungen.txt"

echo "Fertig: $ZIEL"

Die Punkte 3, 5 und 10 fehlen im Skript, und zwar aus einem Grund. Restore-Protokoll, Ausnahmeregister und MFA-Richtlinie entstehen nicht aus einem Cluster-Aufruf. Sie werden geführt, das eine als unterschriebenes Protokoll, das zweite als Verzeichnis in Git, das dritte als Export aus dem Identitätssystem.

Nachweisverzeichnis zum Kopieren

Der Export allein reicht nicht. Was ihn brauchbar macht, ist die Zeile daneben, die sagt, wo er liegt, wer ihn verantwortet und wann er zuletzt erzeugt wurde.

# Nachweisverzeichnis Plattformebene
Stand: 2026-09-01   Verantwortlich: [Name, Rolle]   Cluster: [Name]

| # | Kontrollbereich | Artefakt | Fundort | Erzeugt | Rhythmus | Verantwortlich | Status |
|---|---|---|---|---|---|---|---|
| 1 | Inventar und Risiko | Inventarbericht, Label-Policy inkl. Schutzbedarf | nachweise/2026-09-01/01-inventar.tsv | 01.09.2026 | quartalsweise | | |
| 1b | Systemverbund | Kommunikationsgraph aus NetworkPolicies | nachweise/2026-09-01/01b-kommunikationsgraph.tsv | | quartalsweise | | |
| 1c | Umsysteme | Datenbanken, Identitaetssystem, Storage, SaaS | ausserhalb des Clusters, Zuarbeit Kunde | | jaehrlich | | |
| 2 | Vorfallbearbeitung | Audit-Policy, Retention, Übungsprotokoll | Repo platform/audit/ | | quartalsweise | | |
| 3 | Betriebsaufrechterhaltung | Restore-Protokoll, unterschrieben | Ablage Notfallvorsorge | | jährlich | | |
| 3b | Grenzen des Wiederaufbaus | Liste: CA, OIDC-Issuer, externe Token, DNS | Ablage Notfallvorsorge, je Zeile ein Zustaendiger | | jährlich | | |
| 4 | Lieferkette | Policy-Report, SBOM-Archiv, Allowlist | nachweise/2026-09-01/04-*.txt | | monatlich | | |
| 4b | Fremdkomponenten | Abhaengigkeitsinventar: Herkunft, Pflegezustand, Cluster-Rechte, Entscheidung | Repo platform/abhaengigkeiten/ | | quartalsweise | | |
| 5 | Schwachstellen | Alterungsbericht, Ausnahmeregister | Dashboard, Repo ausnahmen/ | | monatlich | | |
| 6 | Wirksamkeit | Drift-Kennzahl mit Verlauf, Quartalsbericht | nachweise/2026-09-01/06-drift.tsv | | quartalsweise | | |
| 7 | Cyberhygiene | Policy-Report, Adoptionsquote | nachweise/2026-09-01/07-*.txt | | quartalsweise | | |
| 7b | Schulung | Schulungsnachweis | beim Kunden, nicht Plattform | | | ISB | |
| 8 | Kryptographie | Zertifikatsinventar, Rotationsprotokolle | nachweise/2026-09-01/08-zertifikate.txt | | monatlich | | |
| 9 | Zugriffskontrolle | RBAC-Stand mit Historie, Break-Glass-Protokoll | Repo platform/rbac/, Git-Historie | | quartalsweise | | |
| 10 | MFA und Zugangswege | MFA-Richtlinie mit Geltungsbereich | Export Identitätssystem | | halbjährlich | | |

## Offene Punkte
1. [Artefakt] fehlt, weil [Grund]. Verantwortlich: [Name]. Frist: [Datum].

Drei Hinweise zur Vorlage. Die Spalte Fundort ist die eigentliche Arbeit, denn sie zwingt zur Entscheidung, wo ein Artefakt liegt und wer es pflegt. Die Zeile 1c steht bewusst darin, obwohl sie nie aus dem Cluster kommt: Sie hält fest, dass es eine Ebene neben der Plattform gibt, statt sie schweigend wegzulassen. Und ein Verzeichnis, in dem jede Zeile grün ist, wirkt bei jedem erfahrenen Prüfer verdächtig. Offene Punkte gehören hinein, mit Frist.

Der regulatorische Rahmen, kurz

Seit dem 6. Dezember 2025 gilt §30 BSIG. Absatz 2 listet zehn Maßnahmenbereiche, die inhaltlich Artikel 21 Absatz 2 der NIS2-Richtlinie entsprechen. Die zehn Artefakte oben folgen dieser Reihenfolge, decken aber jeweils nur den technischen Anteil ab.

Nach Absatz 1 müssen die Maßnahmen geeignet, verhältnismäßig und wirksam sein. Die Umsetzungstiefe leitet sich damit aus der Risikoanalyse ab und nicht aus einer Checkliste. Wer alle zehn Bereiche gleich tief umsetzt, hat mehr getan, als die Norm verlangt.

Außerhalb der Plattformebene liegen die organisatorischen Teile: Risikoregister und Bewertungsmethodik, die Schutzbedarfsfeststellung selbst, Notfallorganisation und Krisenstab, Meldewege gegenüber Behörden, Lieferantenbewertung und Vertragsklauseln, Schulungsprogramme sowie die Kommunikationssysteme der Organisation. Die Plattform liefert das Feld für den Schutzbedarf und misst, wie viele Workloads es tragen. Welchen Wert ein Workload bekommt, entscheidet die Fachseite. Für bestimmte Anbieterkategorien gilt nach Absatz 3 zudem ein eigener, detaillierterer Katalog aus einer EU-Durchführungsverordnung.

Dieser Artikel ist eine technische Anleitung und keine Rechtsberatung. Ob und in welcher Tiefe die Pflichten für Ihr Unternehmen gelten, welche Artefakte im Einzelfall ausreichen und welcher Katalog anzuwenden ist, klären Sie mit Ihrem Informationssicherheitsbeauftragten oder einem Fachanwalt.

Worauf es hinausläuft

Der Aufwand steckt nicht im Erzeugen der Artefakte. Die Befehle oben laufen in Minuten. Er steckt in der Entscheidung, wo jedes Artefakt liegt, wer es verantwortet und in welchem Rhythmus es entsteht. Das ist eine Stunde Arbeit am Verzeichnis und danach ein Cron-Eintrag.

Verglichen mit vier Wochen Zuarbeit vor jedem Termin ist das ein gutes Geschäft, und der Nebeneffekt zählt mehr als der Nachweis: Ein Verzeichnis, das man quartalsweise füllt, zeigt Lücken, solange sie noch billig zu schließen sind.

Wie wir die technischen Maßnahmen in Kubernetes-Umgebungen umsetzen und die Nachweise dabei als Nebenprodukt entstehen, steht auf /bsig-30-kubernetes.