Was bringt Policy-as-Code?
Policy-as-Code definiert Compliance-Regeln als maschinenlesbare Dateien, die bei jedem Deployment automatisch geprüft werden. Tools wie Open Policy Agent machen Compliance versionierbar, testbar und durchsetzbar — statt auf manuelle Audits einmal im Jahr zu warten.
DevSecOps & CompliancePolicy-as-Code überträgt das Prinzip von Infrastructure as Code auf Compliance- und Governance-Regeln: Statt Vorgaben in Dokumenten zu beschreiben und einmal jährlich manuell zu prüfen, werden sie als maschinenlesbare, versionierte Regeln formuliert und bei jedem relevanten Ereignis automatisch durchgesetzt. Das verbreitetste Werkzeug ist Open Policy Agent (OPA) mit seiner Sprache Rego, daneben existieren Lösungen wie Kyverno für Kubernetes.
Der Kerngedanke ist, dass eine Regel nur dann wirklich verlässlich ist, wenn sie automatisch erzwungen wird. Eine Policy wie "kein Container darf als root laufen" oder "jedes Deployment braucht eine gültige SBOM" lässt sich als Code formulieren, im Repository versionieren, im Review besprechen und mit Tests absichern — genau wie Anwendungslogik. Verstöße werden zum Zeitpunkt des Deployments blockiert, nicht erst im nachträglichen Audit entdeckt.
In regulierten und industriellen Umgebungen ist das ein erheblicher Hebel. Policy-as-Code macht Anforderungen aus IEC 62443, NIS2 oder internen Sicherheitsrichtlinien als ausführbare Gates greifbar und liefert zugleich die Audit-Spur: Wer hat wann welche Regel geändert, und welche Deployments wurden gegen welche Policy geprüft. Das ersetzt fehleranfällige Checklisten durch reproduzierbare Durchsetzung.
Typische Stolpersteine: Policies werden zu strikt formuliert und blockieren legitime Sonderfälle, woraufhin Teams Ausnahmen am System vorbei schaffen. Oder es fehlt ein durchdachter Ausnahmeprozess für dokumentierte Risikoakzeptanz. Außerdem braucht Rego eine gewisse Einarbeitung — Regeln ohne Tests können selbst zur Fehlerquelle werden.
Kubernetes-Admission-Control im Fertigungs-Cluster
Ein Betreiber setzt OPA als Admission-Controller ein, sodass nur signierte Images aus der internen Registry und nur Pods mit definierten Ressourcen-Limits ausgerollt werden dürfen. Verstöße werden vor dem Scheduling abgewiesen, nicht erst im Betrieb entdeckt.
Compliance-Gate in der Terraform-Pipeline
Vor jedem apply prüft eine Policy, ob neue Cloud-Ressourcen verschlüsselt und korrekt getaggt sind. Fehlt die Verschlüsselung, blockiert die Pipeline — die Vorgabe aus der Sicherheitsrichtlinie wird so automatisch und ohne manuelle Kontrolle durchgesetzt.
- Wo in der Pipeline werden Policies geprüft?
- Sinnvoll sind mehrere Stellen: vorab im Pull Request als Pre-Merge-Check, im CI-Build als Gate vor dem Deployment und zur Laufzeit als Admission-Control im Cluster. Mehrschichtige Prüfung fängt Verstöße früh ab und sichert die Durchsetzung zusätzlich beim tatsächlichen Deployment.
- Brauche ich für Policy-as-Code zwingend Open Policy Agent?
- Nein, OPA ist verbreitet, aber nicht alternativlos. Für reine Kubernetes-Szenarien ist Kyverno oft einfacher, weil Regeln als YAML statt in Rego geschrieben werden. Die Wahl hängt davon ab, ob Sie heterogene Systeme oder primär Kubernetes absichern.
- Wie gehe ich mit berechtigten Ausnahmen um?
- Über einen expliziten, dokumentierten Ausnahmeprozess: Ausnahmen werden als versionierte Annotationen oder gepflegte Allowlists abgebildet, mit Begründung und idealerweise Ablaufdatum. So bleibt die Risikoakzeptanz nachvollziehbar, statt dass Teams Regeln stillschweigend umgehen.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance