Was bringt Policy-as-Code?
Policy-as-Code — oft auch Compliance as Code genannt — 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.
Ist Policy-as-Code bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Policy-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 spricht man deshalb oft von Compliance as Code — dieselbe Idee, betrachtet aus der Audit-Perspektive. Policy-as-Code macht Anforderungen aus IEC 62443, NIS2 oder internen Sicherheitsrichtlinien als ausführbare Gates greifbar, und weil jede Regel versionierbar im Repository liegt, entsteht die Audit-Spur nebenbei: Die Auditor-Frage „Wer hat diese Regel wann geändert?“ beantwortet ein git log in Sekunden — statt in einer Woche Dokumentensuche quer durch Laufwerke und Mail-Postfächer. Das ersetzt fehleranfällige Checklisten durch reproduzierbare Durchsetzung.
Das Werkzeug-Ökosystem hat sich zuletzt spürbar bewegt. Mit OPA 1.0 (Ende 2024) wurde Rego v1 zum Standard und räumte alte Sprach-Inkonsistenzen aus. Kubernetes bringt mit der ValidatingAdmissionPolicy inzwischen eine eingebaute, CEL-basierte Policy-Engine mit, die für einfache Cluster-Regeln ohne zusätzlichen Admission-Webhook auskommt. Für heterogene Landschaften — CI-Pipelines, Terraform, APIs, Kubernetes — bleibt OPA das flexibelste Werkzeug; wer ausschließlich Kubernetes absichert, fährt mit Kyverno oder den Bordmitteln oft schlanker.
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 lohnt sich Policy-as-Code zuerst?
Policy-as-Code macht Regeln maschinell prüfbar statt zum PDF im Wiki — der beste Einstieg hängt daran, was Sie absichern wollen. Zwei Klicks geben die Richtung.
Was möchten Sie regelbasiert absichern?
- 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.
- Was ist Compliance as Code?
- Compliance as Code ist im Kern dasselbe Prinzip wie Policy-as-Code, betrachtet aus der Audit-Perspektive: Regulatorische Anforderungen — etwa aus IEC 62443, NIS2 oder internen Richtlinien — werden als maschinenlesbare, versionierte Regeln formuliert und bei jedem Deployment automatisch geprüft. Der Nachweis für den Auditor entsteht damit als Nebenprodukt der Pipeline statt in wochenlanger manueller Dokumentenarbeit.
- Warum ist es wichtig, dass Policies versionierbar sind?
- Weil eine Regel erst dann auditierbar ist, wenn ihre Geschichte nachvollziehbar ist. Versionierbare Policies liegen im Repository wie Anwendungscode: Jede Änderung hat Autor, Zeitpunkt und Begründung, lässt sich im Review prüfen und bei Fehlern zurückrollen. Genau diese Nachvollziehbarkeit unterscheidet Compliance as Code von einer Richtlinie im PDF-Format.
Wo steht Ihr Team bei Policy-as-Code?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Was ist eine SBOM (Software Bill of Materials)?
Was regelt der Cyber Resilience Act der EU?
Was fordert der DORA?
Was ist ein Quality Gate?
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