DevOps und CI/CD für regulierte Branchen: Versicherung, Banking und Gesundheitswesen

Eine CI/CD-Pipeline für ein Fintech-Startup zu bauen und eine für eine BaFin-regulierte Bank sind nicht dasselbe Problem. Die Mechanik überschneidet sich — Commit, Build, Test, Deploy — aber die Rahmenbedingungen sind grundlegend verschieden. Regulierte Branchen schreiben Audit-Trail-Anforderungen, Change-Management-Kontrollen, Umgebungstrennungsvorgaben und in manchen Fällen Vier-Augen-Prinzip-Anforderungen vor, die strukturell in die Pipeline selbst kodiert sein müssen — nicht nachträglich angehängt. Deka Technology hat CI/CD-Systeme für Banking-, Versicherungs- und Healthcare-Kunden in der DACH-Region konzipiert. Hier ist, was uns diese Erfahrung gelehrt hat.

Regulatorischer Kontext: Was Pipelines nachweisen müssen

BaFins BAIT (Bankaufsichtliche Anforderungen an die IT) und die ICT-Leitlinien der Europäischen Bankenaufsichtsbehörde verlangen, dass Finanzinstitute nachweisen, wer jede Deployment autorisiert hat, was sich geändert hat, wann die Änderung ausgeführt wurde und welche Rollback-Kapazität besteht. Die Versicherungsregulierung unter Solvency II stellt ähnliche Anforderungen an versicherungsmathematische und Meldesysteme. Healthcare-Deployments unter der EU-MDR (Medizinprodukteverordnung) erfordern validierte Softwareumgebungen, in denen jede Änderung an einem Produktionssystem ein formales Validierungsprotokoll auslöst.

Das sind keine Checkbox-Anforderungen. Prüfer untersuchen Pipeline-Logs, Deployment-Aufzeichnungen und Zugriffskontrollen bei Vor-Ort-Prüfungen. Eine Pipeline, die keinen maschinenlesbaren Audit-Trail jedes Produktions-Deployments erzeugen kann, ist eine Haftung.

Vier-Augen-Prinzip bei Deployments

Das Vier-Augen-Prinzip — das zwei unabhängige Genehmigungen für jede bedeutende Aktion erfordert — lässt sich direkt in das Pipeline-Design übersetzen. In unseren Pipelines für regulierte Kunden erfordern Produktions-Deployments:

• Einen Merge Request, der von mindestens zwei Ingenieuren genehmigt wurde (auf VCS-Ebene in GitLab/GitHub durchgesetzt).
• Ein manuelles Approval-Gate in der CI/CD-Plattform (GitLab CI geschützte Umgebungen, GitHub Actions Environments mit erforderlichen Reviewern), das einen benannten Genehmiger verlangt, der vom Deployment-Initiator verschieden ist.
• Einen automatisierten Deployment-Eintrag in einem unveränderlichen Audit-Log (wir verwenden Append-only-S3-Buckets oder Azure Blob mit Immutability-Policies).

Das Vier-Augen-Prinzip ist nur dann sinnvoll, wenn es strukturell unmöglich ist, es zu umgehen. Das Pipeline-Design muss konformes Verhalten zum Weg des geringsten Widerstands machen — nicht zu einer Disziplinanforderung, die Ingenieuren unter Termindruck auferlegt wird.

Automatisierte Compliance-Checks in der Pipeline

Manuelle Compliance-Reviews zum Deployment-Zeitpunkt schaffen einen Engpass und ein Risiko: Menschen übersehen unter Druck Dinge. Unser Ansatz verschiebt Compliance-Checks nach links — in die Pipeline, mit Ausführung bei jedem Commit:

• SAST (Static Application Security Testing): SonarQube oder Semgrep scannt nach Schwachstellenmustern und Codequalitäts-Gates. Builds schlagen bei kritischen Befunden fehl.
• Dependency Scanning: Trivy oder Snyk für bekannte CVEs in Container-Images und Paketabhängigkeiten. Regulierte Kunden verlangen ein Zero-Critical-CVE-Gate vor der Produktion.
• Lizenz-Compliance: FOSSA oder REUSE für Open-Source-Lizenz-Scanning — kritisch für Kunden mit GPL-Inkompatibilitätsanforderungen.
• Infrastructure-Policy-Checks: OPA/Conftest gegen Terraform-Pläne, um nicht konforme Ressourcenkonfigurationen daran zu hindern, irgendeine Umgebung zu erreichen.

Umgebungstrennung und Secrets Management

Regulierte Kunden erfordern strikte Umgebungstrennung: Entwicklung, QA, Staging/UAT und Produktion müssen logisch und physisch isoliert sein, mit separaten Credentials, separaten Netzwerksegmenten und separaten Zugriffskontrollen. Wir implementieren dies mit separaten Kubernetes-Namespaces mit Network Policies, umgebungsspezifischen Vault-Pfaden für Secrets und Pipeline-Logik, die verhindert, dass Secrets Umgebungsgrenzen überschreiten.

Secrets Management nutzt HashiCorp Vault in allen regulierten Kundenumgebungen. Dynamische Secrets — kurzlebige Datenbankzugangsdaten, die pro Deployment generiert werden — eliminieren das Risiko langlebiger Credential-Leaks. Jeder Secret-Zugriff wird protokolliert, und Vault-Audit-Logs fließen in das SIEM des Kunden.

Unser Pipeline-Template für regulierte Kunden

Deka pflegt eine CI/CD-Referenzarchitektur für regulierte Branchen, die wir für jeden Kunden anpassen. Das Template enthält: GitLab-CI- oder GitHub-Actions-Workflow-Definitionen, OPA-Policy-Bibliothek, Vault-Integrationsmuster, unveränderliche Audit-Log-Konfiguration und ein Deployment-Approval-Runbook. Einen neuen regulierten Kunden auf eine konforme CI/CD-Baseline zu onboarden, dauert typischerweise vier bis sechs Wochen — statt der Monate, die ein Aufbau von Grund auf benötigt.