Festpreis-Audit
Kubernetes-Sicherheitsaudit
nach BSI APP.4.4
Seit dem 6. Dezember 2025 müssen betroffene Einrichtungen nach § 30 Absatz 1 BSIG nachweisen können, dass sie ihre Systeme abgesichert haben. Für Kubernetes-Plattformen gibt es dafür ein anerkanntes Prüfraster: den BSI-Baustein APP.4.4 mit 21 Anforderungen.
Ich prüfe Ihren Cluster dagegen und liefere Ihnen einen belegten Beitrag zu Ihrer technischen Dokumentation.
Das Problem
Nicht unsicher — nicht nachweisbar sicher
„Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren.“
§ 30 Absatz 1 Satz 3 BSIG
Ihr Team weiß, dass die Berechtigungen sauber sind. Nur steht es nirgends. Es weiß, dass etcd gesichert wird. Nur hat das niemand dokumentiert. Und wenn die Aufsicht, der Wirtschaftsprüfer oder ein Kunde im Lieferkettenfragebogen nachfragt, beginnt eine Woche Archäologie im eigenen Cluster.
Sechs der zehn Maßnahmenbereiche aus § 30 Absatz 2 BSIG betreffen direkt den Betrieb einer Container-Plattform: Backup und Wiederherstellung, Lieferkettensicherheit, Schwachstellenmanagement, Kryptografie, Zugriffskontrolle und Multi-Faktor-Authentifizierung.
Ergebnis
Was Sie bekommen
Prüfbericht
Eine Zeile je Anforderung: erfüllt, teilweise erfüllt, nicht erfüllt oder nicht anwendbar — jeweils mit Begründung und Belegstelle.
Nachweismappe
Die Rohdaten dazu: ausgeführte Kommandos, Zeitstempel, Benchmark-Ausgaben, Konfigurationsauszüge. Jede Bewertung hält der Rückfrage eines Dritten stand.
Maßnahmenplan
Priorisiert nach Risiko und Aufwand, mit Aufwandsschätzung je Maßnahme. Ihr Team weiß danach, was es am Montag anfasst.
Management-Summary
Zwei Seiten für die Geschäftsleitung. Kein Fachjargon, keine Produktnamen.
Zuordnung zum BSIG
Jede APP.4.4-Anforderung den Nummern aus § 30 Absatz 2 BSIG zugeordnet, damit sich die Ergebnisse in Ihre Dokumentation einordnen lassen.
Abschlussworkshop
90 Minuten mit Betrieb und Entwicklung. Unterlagen vorab, damit Sie fragen können statt zu lesen.
Arbeitsprobe
So sieht eine Bewertung aus
Ein Auszug aus einem fiktiven Musterbericht — eine von zwölf bewerteten Anforderungen, vollständig, in genau der Form, in der Sie sie bekommen.
Identitäts- und Berechtigungsmanagement bei Kubernetes
Feststellung
Drei ClusterRoleBindings binden an cluster-admin:
| Binding | Subjekt | Umfang |
|---|---|---|
dev-all-admin | Gruppe dev-all | 24 Personen |
ops-admin | Gruppe ops | 7 Personen |
ci-runner-admin | ServiceAccount ci/ci-runner | Dienstkonto |
Zusätzlich existiert die ClusterRole portal-operator mit
apiGroups: ["*"], resources: ["*"], verbs: ["*"],
gebunden an zwei Dienstkonten. Die Anbindung an den Identitätsanbieter über OIDC ist
korrekt konfiguriert, anonyme Zugriffe auf die API sind deaktiviert
(--anonymous-auth=false, belegt durch die vom Auftraggeber bereitgestellte
kube-bench-Ausgabe zu Prüfpunkt 1.2.1, Nachweismappe N-01). Eine periodische
Überprüfung der vergebenen Rechte findet nicht statt; die letzte dokumentierte
Durchsicht datiert von 2023.
Bewertungsbegründung
Die Authentifizierung ist sauber gelöst, die Autorisierung nicht. Der Baustein verlangt, dass Benutzende nur die unbedingt notwendigen Rechte erhalten. 31 Personen mit unbegrenzten Clusterrechten auf einem Produktionssystem erfüllen das nicht, unabhängig von der Vertrauenswürdigkeit der Beteiligten: Die Rechte überleben jeden Rollenwechsel und jede Kompromittierung eines einzelnen Kontos.
Empfehlung
- Vier rollenbezogene ClusterRoles definieren (Entwicklung lesend, Entwicklung schreibend je Namespace, Plattformbetrieb, Notfallzugang) und die drei bestehenden Bindungen ersetzen. Aufwand: 2 PT.
- Den Notfallzugang als gesondertes, protokolliertes Verfahren ausgestalten statt als Daueranspruch.
portal-operatorauf die tatsächlich genutzten Ressourcen einschränken; die benötigten Rechte lassen sich aus den Audit-Logs der letzten 30 Tage ableiten. Aufwand: 1 PT.- Halbjährliche Rechteüberprüfung als wiederkehrenden Termin etablieren.
Die drei bezifferten Positionen aus A3 und A10 — ClusterRoles 2 PT,
portal-operator 1 PT, Dienstkonten je Zielumgebung 1 PT — sind im
Maßnahmenplan des Berichts in Maßnahme M-03 mit zusammen 4 PT zusammengefasst und
werden dort nicht erneut gerechnet.
Pakete
Drei Umfänge, drei Festpreise
Der Schnitt folgt der Struktur des Bausteins: Basis-Anforderungen (MUSS), Standard-Anforderungen (Stand der Technik) und Anforderungen bei erhöhtem Schutzbedarf.
Basis-Check
- Die fünf MUSS-Anforderungen A1–A5
- Anwendungsseparierung, CI/CD und Secrets
- Berechtigungen, Pod-Separierung
- Datensicherung inklusive etcd
- CIS-Benchmark-Lauf
- Kurzbericht mit Sofortmaßnahmen
Standard-Audit
- Alle zwölf Anforderungen A1–A12
- Der Umfang, der laut BSI dem Stand der Technik entspricht
- Netzseparierung und Default-Deny
- Service-Account-Hygiene, Pipeline-Rechte
- Registry und Infrastrukturdienste
- Vollständiger Berichtssatz
- Abschlussworkshop
Vollaudit
- Alle 21 Anforderungen A1–A21
- Dedizierte Nodes, Mikro-Segmentierung
- Node-Attestierung, verschlüsselte Datenhaltung
- Abgleich gegen Ihre Risikoanalyse
- NIST SP 800-190
- Entwurf einer Admission-Policy-Baseline
Alle Preise netto zzgl. USt. Enthalten ist ein Cluster mit bis zu drei Namespaces im Detail. Weitere Cluster und Namespaces auf Anfrage.
Beauftragen Sie innerhalb von 30 Tagen nach Berichtsübergabe ein Umsetzungsprojekt ab zehn Personentagen, rechne ich bis zu 1.900 € des Auditpreises an — den Gegenwert des Basis-Checks. Einmalig je Auftraggeber, nicht auszahlbar.
Die angegebenen Arbeitstage laufen ab der vollständigen Bereitstellung der vereinbarten Zugänge und Auskünfte, nicht ab Auftragserteilung. Konkrete Termine für Kickoff, Erhebung und Abschlussworkshop werden nach Vereinbarung festgelegt.
Ablauf
Vier Schritte, vier Stunden Ihrer Zeit
- Gespräch, 30 Minuten
Welche Plattform, welcher Schutzbedarf, welcher Anlass. Danach wissen Sie, welches Paket passt — oder dass Sie keines brauchen.
- Zugang
Eine eigens angelegte, rein lesende ClusterRole — das mitgelieferte
viewreicht für Berechtigungen nicht aus. Das fertige Manifest bringe ich mit. Keine Rechte auf Secrets. Alternativ: eine begleitete Sitzung mit einem Ihrer Administratoren. - Erhebung
Lesend. Keine Änderungen, keine Neustarts, keine dauerhaft installierten Agenten.
- Bericht und Workshop
Unterlagen zwei Werktage vor dem Termin, damit Sie im Workshop fragen können statt zu lesen.
Abgrenzung
Was dieses Audit nicht ist
Ich finde es fairer, das vorne zu sagen.
- Keine Rechtsberatung. Ob Sie dem BSIG unterliegen und welchen Schutzbedarf Sie festlegen, entscheiden Sie. Ich liefere die technische Bewertung, nicht die juristische Einordnung.
- Kein Zertifikat. Kein Audit nach ISO 27001, keine Zertifizierung auf Basis IT-Grundschutz. Sie bekommen einen Prüfbericht, kein Siegel.
- Kein vollständiger BSIG-Nachweis. § 30 Absatz 2 BSIG umfasst zehn Maßnahmenbereiche, die weit über die Plattform hinausgehen. Dieses Audit deckt den plattformtechnischen Ausschnitt ab — es ist ein Beitrag zu Ihrer Dokumentation, nicht ihr Ersatz.
- Kein Penetrationstest. Ich prüfe Konfiguration und Konzept, ich greife nichts an.
- Kein Code-Review Ihrer Anwendungen.
- Baustein SYS.1.6 Containerisierung ist nicht enthalten und wird separat angeboten.
Wer prüft
Sie sprechen mit der Person, die prüft
Senior Platform Engineer, freiberuflich, mit Schwerpunkt auf Kubernetes-Sicherheit in regulierten Umgebungen.
- Mandate im Schweizer Bundesumfeld (BIT, VBS, RUAG, EJPD), bei einer Stadtverwaltung, einem Versicherungs-IT-Dienstleister und einem Telekommunikationskonzern
- Aktive Schweizer Personensicherheitsprüfung
- B.Sc. Informatik und B.Sc. Mathematik
Es gibt keinen Vertrieb, der etwas anderes verspricht, als nachher geliefert wird.
Häufige Fragen
Bevor Sie fragen
Wir sind gar nicht NIS2-betroffen. Lohnt sich das trotzdem?
Oft ja, aber aus einem anderen Grund: Lieferkettenfragebögen. Wenn einer Ihrer Kunden betroffen ist, wird er Sie nach § 30 Absatz 2 Nummer 4 BSIG befragen. Dann ist ein fertiger Prüfbericht die kürzeste Antwort.
Wir haben schon ein Schwachstellen-Scanning-Tool.
Das prüft Images und CVEs. APP.4.4 prüft Konzept und Konfiguration der Plattform: Berechtigungen, Netztrennung, Service-Accounts, Secrets, Sicherung. Das Werkzeug beantwortet eine andere Frage.
Managed Kubernetes bei AWS oder Azure — ist das nicht Sache des Anbieters?
Der Anbieter verantwortet die Control Plane. Alles darüber — Berechtigungen, Namespaces, Netzpolitik, Secrets, Pipelines — verantworten Sie. Das ist der größere Teil des Bausteins.
Was, wenn das Ergebnis schlecht ausfällt?
Dann haben Sie einen priorisierten Plan und wissen, was die Behebung kostet. Das ist der Zweck. Ich schreibe keine Berichte, die gut aussehen sollen.
Wie viel Zeit kostet uns das?
Etwa vier Stunden auf Ihrer Seite: Kickoff, Zugang einrichten, Rückfragen, Workshop.
Bekommen wir den Bericht auch auf Englisch?
Ja. Bericht und Management-Summary liefere ich auf Wunsch zweisprachig.
Hält Ihre Plattform einer Prüfung stand?
Das ist die Antwort auf eine Frage, die Sie ohnehin bald beantworten müssen.