Kubernetes-Sicherheit für reguliertes SaaS in Deutschland: Kontrollen, die Audits tragen

Warum reguliertes SaaS auf Kubernetes ein Kontroll-Design-Problem ist

Managed Kubernetes nimmt viel Control-Plane-Aufwand ab, entbindet aber nicht von Verantwortung für Workload-Konfiguration, Datenflüsse und Zugriffspfade. Bei reguliertem SaaS stellen Prüfer und Kunden-Security dieselben Fragen - ob EKS, AKS oder GKE: Wer darf Produktion ändern, wie sind Mandanten oder Umgebungen getrennt, wo landen Logs, und wie belegen Sie, dass eine präventive Kontrolle ein schlechtes Deployment blockiert hat?

Framework-Mappings (SOC-2-Trust-Kriterien, ISO-27001-Anhang-A-Themen, DORAs IKT-Risikomanagement in Artikel 5-16) schreiben keine Produktkategorie vor. Sie erwarten risikobasierte Kontrollen, dokumentierte Begründung und Betriebsstichproben. Kubernetes ist ein legitimer Ort für diese Kontrollen - wenn RBAC, Network Policy, Secrets und Admission zum Compliance-Scope gehören, nicht zu „Plattform-Interna“.

Identität und RBAC: Least Privilege, das Churn übersteht

Cluster-Admin für Application-Teams ist der schnellste Weg zu einem gescheiterten Review. Das tragfähige Muster bindet Menschen an den zentralen Identity Provider (SSO mit MFA), nutzt kurzlebige Credentials für Automation und trennt Rollen für Deploy, Read-only-Support und Break-glass.

• ✓Namespace-scoped Roles für Application-Teams; clusterweite Änderungen nur für Platform Engineering mit ticketbasierter Freigabe.
• ✓Keine long-lived kubeconfig-Dateien in CI-Secrets, wo OIDC oder Cloud-Federation verfügbar ist.
• ✓Regelmäßige Access Reviews, die Cloud-IAM-Bindings und Kubernetes-RBAC stichprobenartig prüfen - ohne Inventar driften sie schnell auseinander.
• ✓API-Server- und Control-Plane-Audit-Logs im selben Archiv wie Application-Logs aufbewahren.

Network Policies und Segmentierung

Default-allow Pod-Netzwerk ist in der Entwicklung bequem und im Incident teuer. Für Multi-Tenant- oder Multi-Environment-SaaS sollten Network Policies (oder Service-Mesh-Policies, wenn Sie bereits ein Mesh betreiben) eine dokumentierte Matrix durchsetzen: welche Namespaces Datenbanken, Internet-Egress und interne Admin-Tools erreichen dürfen.

Auf EKS, AKS und GKE müssen Policies zur Cloud-Netzwerk-Realität passen - Security Groups, Private Link, Firewall-Regeln und CNI-Verhalten. Eine in YAML korrekte Policy, die über Load-Balancer-Fehlkonfiguration umgangen wird, ist ein häufiger Audit-Befund. Erlaubte Pfade einmal diagrammieren; Policies daraus ableiten statt Ticket-für-Ticket-Regeln anzuhäufen.

Secrets, Images und Admission

Secrets in Plain Manifests oder unrotierte Bootstrap-Tokens tauchen in fast jeder ersten externen Bewertung auf. Bevorzugen Sie externe Secret Stores mit Cluster-Integration (Cloud Secret Manager mit CSI, Sealed Secrets mit definiertem Rotation-Owner oder von Ihrer Risikobewertung akzeptierte Muster).

Admission ist die Schnittstelle zwischen präventiven Guardrails und Compliance-Narrativ: privilegierte Pods blockieren, Resource Limits erzwingen, Standard-Labels für Kosten und Datenklassifikation verlangen, Images aus nicht freigegebenen Registries oder ohne Signaturprüfung ablehnen, wo Sie diese eingeführt haben. Policy-Engines (OPA Gatekeeper, Kyverno oder Cloud-Add-ons) sollten Ihre Kontrollmatrix referenzieren, damit Prüfer eine Linie von Policy-PDF bis Ablehnung im API-Server-Audit-Log sehen.

Nachweise für SOC 2, ISO 27001 und DORA-orientierte Käufer

Detection ohne Retention ist kein Nachweis. Für SOC-2-Type-II und ISO-Überwachungsaudits reichen Stichproben über Wochen oder Monate: API-Audit-Einträge zu RoleBinding-Änderungen, Tickets für Network-Policy-Ausnahmen, Vulnerability-Scan-Ergebnisse laufender Images, Backup-/Restore-Tests für Stateful Workloads.

DORA ersetzt Kubernetes-Best-Practice nicht, aber Finanzsektor-Kunden mappen Ihr Hosting oft auf IKT-Risikomanagement und Incident-Pflichten (Artikel 5-16 und das Incident-Kapitel ab Artikel 17). Ihre Aufgabe als SaaS-Anbieter: technische Artefakte exportierbar machen - Konfigurations-Baselines, Log-Queries, Change Records und Testergebnisse - ohne DORA für sie auszulegen.

Was Stratoworks leistet

Wir entwerfen und implementieren Landing Zones, Cluster-Baselines, Guardrails und Evidence Paths in Terraform und in Ihren Runbooks - auf EKS, AKS oder GKE. Wenn Sie bereits CNAPP oder Kubernetes-Scanner betreiben, richten wir präventive Kontrollen und Logging so aus, dass Tool-Fundstellen und Audit-Stichproben dieselben Objekte treffen.

Wir verkaufen oder betreiben kein Kubernetes-Security-Produkt. Boutique bedeutet hier hands-on Engineering für regulierte SaaS-Teams in Deutschland und der EU: proportionale Kontrollen, reproduzierbare Konfiguration und ein Evidence Store, den Kunden und Prüfer wirklich stichproben können.

FAQ