Compliance-by-Design: SOC2, ISO 27001, BSI

Lernziele

Nach dieser Lektion kannst du erklären, warum Compliance in einer Developer Platform nicht nachträglich „draufgeklebt” wird, sondern in Architektur und Golden Paths eingebaut sein muss. Du kennst die zentralen Anforderungsfelder von SOC 2, ISO 27001 und dem BSI IT-Grundschutz im Plattformkontext, weißt, welche Controls sich technisch automatisieren lassen und wie du Audit-Nachweise ohne manuelle Excel-Listen erzeugst. Du kannst Compliance-by-Design gegen reine Dokumentations-Compliance abgrenzen und den Spannungsbogen zu Developer Velocity ehrlich benennen.

Das Problem: Audit-Woche als jährlicher Schock

Stell dir vor, der externe Auditor kommt in zwei Wochen. Das Security-Team schickt plötzlich Fragebögen an alle Teams: Wer hat wann Zugriff auf Produktion gehabt? Wo liegen eure Logs? Warum deployt Team Checkout am Freitagabend ohne Genehmigung? Die Antworten kommen fragmentiert zurück — Screenshots aus Slack, veraltete Wiki-Seiten, ein Excel mit „vermutlich noch aktuell”.

Genau dieses Szenario ist der Beweis, dass Compliance nicht funktioniert hat. Es wurde nicht designed, sondern nachgeholt. Für eine interne Plattform mit dutzenden Teams ist das besonders fatal: Die Plattform ist der Ort, an dem fast jeder technische Control greift — Identität, Deployment, Logging, Netzwerksegmentierung, Secrets. Wenn Compliance dort nicht eingebaut ist, musst du hinterher hunderte Insellösungen prüfen.

Compliance-by-Design heißt: Regulatorische und interne Anforderungen werden von Anfang an in Architekturentscheidungen, Automatisierung und Defaults übersetzt — so, dass der normale Betrieb der Plattform gleichzeitig der Nachweis ist.

SOC 2, ISO 27001, BSI — was Plattform-Teams wirklich brauchen

Die drei Frameworks klingen nach Papierkram, haben aber überlappende technische Kerne, die du als Platform Engineer kennen musst:

SOC 2 (Trust Service Criteria) ist der häufigste Kunde-Audit-Standard für SaaS und Tech-Unternehmen. Für die Plattform relevant sind vor allem Security (Zugriffskontrolle, Verschlüsselung), Availability (Plattform-SLOs, DR — Lektion 40) und Confidentiality (Mandantentrennung, Secrets-Handling). SOC 2 fragt nicht „habt ihr ein Tool?”, sondern „funktioniert der Control zuverlässig und habt ihr Evidenz?”.

ISO 27001 ist ein Managementsystem für Informationssicherheit. Annex A listet Controls — von Asset-Inventar über Change Management bis Incident Response. Für die Plattform bedeutet das: Jede Golden-Path-Komponente braucht einen Owner, Änderungen laufen über Git und Review, und Zugriffe sind nachvollziehbar dokumentiert. ISO ist breiter als SOC 2, aber weniger branchenspezifisch.

BSI IT-Grundschutz (und Bausteine wie APP.4.4 für Kubernetes) ist in deutschen Behörden und regulierten Branchen verbreitet. Er verlangt explizite Absicherungsebenen, Härtung und Nachweisführung — oft strenger bei Netzwerksegmentierung und Protokollierung als reine Cloud-Native-Defaults.

Der gemeinsame Nenner für alle drei: Zugriff, Änderungen, Logs, Trennung, Wiederherstellung. Deine Plattform muss diese fünf Themen nicht fünfmal implementieren, sondern einmal richtig — und die Frameworks mappen darauf.

Controls in die Plattform übersetzen

Compliance-by-Design lebt von der Übersetzung abstrakter Anforderungen in konkrete Plattform-Mechanismen:

Anforderung	Plattform-Mechanismus
Least Privilege	RBAC-Rollen pro Team, keine dauerhaften Cluster-Admin-Rechte (Lektion 45)
Change Management	GitOps: jeder Deploy ist ein Commit mit Author, Review, Zeitstempel
Logging & Monitoring	Zentraler Log-Pfad, Audit-Logs der Kubernetes-API, unveränderliche Speicherung
Mandantentrennung	Namespaces, Quotas, NetworkPolicies, ggf. dedizierte Cluster (Lektion 19)
Secrets-Schutz	External Secrets Operator, kurzlebige Credentials, kein Secret in Git

Der entscheidende Schritt: Diese Mechanismen sind Default im Golden Path, nicht optional. Wer über den Scaffolder ein neues Service anlegt, bekommt automatisch ein Deployment mit Resource Limits, ein ServiceAccount ohne unnötige Rechte, eine NetworkPolicy-Vorlage und CI-Integration mit Signaturprüfung (Lektion 44). Wer den Golden Path nutzt, ist compliant — ohne ein Compliance-Formular auszufüllen.

Policy-as-Code (Lektion 28) ist der technische Rückgrat: Regeln wie „kein :latest-Tag”, „kein Privileged Container” oder „Images nur aus vertrauenswürdiger Registry” werden am Admission-Webhook durchgesetzt. Der Audit-Nachweis ist dann nicht „wir haben eine Regel”, sondern „hier ist die Policy in Git, hier ist der Enforcement-Point, hier sind die abgelehnten Deployments der letzten 90 Tage”.

Compliance und Velocity — kein Widerspruch, wenn die Plattform es trägt

Der häufigste Einwand aus dem Engineering: „Compliance bremst uns.” Stimmt — wenn Compliance ein manuelles Gate ist. Stimmt nicht, wenn Compliance der schnellste Weg ist.

Self-Service mit Guardrails ist schneller als Ticket-Warteschlangen: Ein Team, das über den Golden Path deployt, braucht keine separate Security-Freigabe, weil die Freigabe in die Pipeline eingebaut ist. Der Trade-off, den du ehrlich nennen musst: Standardisierung statt Flexibilität. Teams, die vom Golden Path abweichen (Escape Hatch), übernehmen den Compliance-Nachweis selbst — dokumentiert, zeitlich begrenzt, reviewbar. Ohne Escape Hatch wird die Plattform zur Gefängnismauer; ohne Standards wird sie irrelevant.

Ein zweiter Trade-off: Automatisierung vs. Vollständigkeit. Nicht jeder Control lässt sich voll automatisieren — organisatorische Prozesse (Access Reviews, Incident-Reporting) bleiben menschlich. Die Plattform liefert die technische Evidenz; das Security-Team orchestriert die Prozesse drumherum.

Praxis

Nimm einen konkreten Control und baue ihn end-to-end durch — im Lab oder als Architektur-Skizze:

1. Wähle eine Anforderung aus SOC 2 CC6 (logische Zugriffskontrolle): „Produktions-Deployments erfordern identifizierbaren Actor und nachvollziehbaren Change.”
2. Mappe sie auf GitOps: Merge in main triggert Argo CD Sync; der Commit-Author ist der Actor; der PR-Review ist die Genehmigung.
3. Ergänze technische Guardrails: Branch Protection, required Reviewers, signierte Commits optional.
4. Definiere den Audit-Nachweis: Git-History + Argo CD Application Events + Kubernetes Audit Log für den Sync-User.

Schreibe dazu eine halbe Seite: Welche Evidenz liefert welche Komponente? Wo ist die Lücke, die du manuell schließen musst? Genau diese Lücken-Diskussion ist es, die Auditoren und Interviewer überzeugt.

Typische Stolperfallen

Compliance-Wiki statt Compliance-Code. Regeln, die nicht automatisch durchgesetzt werden, gelten nur im Happy Path — und der ist selten.

Audit als Einmalprojekt. Wer nur vor dem Audit aufräumt, baut keine nachhaltige Plattform. Continuous Compliance heißt: Evidenz entsteht im laufenden Betrieb.

Framework-Vollständigkeit vor Plattform-Relevanz. Nicht jeder ISO-27001-Control braucht ein eigenes Tool. Priorisiere die Controls, die über die Plattform technisch greifen.

Golden Path ohne Adoption. Der schönste compliant Default nützt nichts, wenn alle Teams drumherum arbeiten. Metriken: Wie viel Prozent der Deployments laufen über den Golden Path?

Interview-Vorbereitung

Die Frage „Was ist Compliance-by-Design?” beantwortest du am stärksten so: Problem (nachträgliche Audit-Hetz, fragmentierte Controls) → Definition (regulatorische Anforderungen in Plattform-Architektur, Defaults und Automatisierung übersetzt) → Beispiel (Golden Path mit Policy-as-Code und GitOps als Change-Management-Nachweis) → Trade-off (Standardisierung vs. Escape Hatch, Automatisierung vs. organisatorische Prozesse).

Rechne mit Follow-ups:

• „SOC 2 vs. ISO 27001 — was ist der Unterschied für die Plattform?” — SOC 2 ist audit-orientiert und kundengetrieben; ISO 27001 ist ein ISMS mit breiteren organisatorischen Controls.
• „Wie balancierst du Compliance und Developer Velocity?” — Guardrails im Golden Path statt manueller Gates; Escape Hatch mit dokumentierter Eigenverantwortung.
• „Welche Controls automatisierst du zuerst?” — Zugriff, Change Management, Logging — weil sie den höchsten Audit-Aufwand manuell erzeugen.

Zusammenfassung

Compliance-by-Design bedeutet, regulatorische Anforderungen (SOC 2, ISO 27001, BSI) nicht als jährliche Papierarbeit zu behandeln, sondern in Plattform-Architektur, Golden Paths und Policy-as-Code zu übersetzen. Die fünf Kernthemen — Zugriff, Änderungen, Logs, Trennung, Wiederherstellung — werden einmal zentral gelöst; der normale Plattformbetrieb erzeugt die Audit-Evidenz. Der zentrale Trade-off ist Standardisierung gegen Flexibilität: Der Golden Path ist der schnellste und complianteste Weg; Abweichungen sind möglich, aber teurer. In der nächsten Lektion verschieben wir den Fokus von „wer darf was” auf „was darf überhaupt deployed werden” — Supply Chain Security.