Policy as Code

1) Was ist „Politik“

• Zugang/Autorisierung: RBAC/ABAC, ReBAC, Datenexport, Step-up (MFA).
• Infrastruktur-Sicherheit: Kubernetes Admission-Control, Image/Secret Policy, Netzwerkregeln.
• Compliance und Datenschutz: Einwilligungsmanagement, PII-Tagging, lokaler Meldetag, Geobeschränkungen.
• Konfigurationen und Qualität: „Verbot: neueste“, Ressourcenlimits, obligatorische Ressourcentags (Cloud).
• Daten und ML: Trainingsverbot auf Sets ohne Einwilligung, k-Anonymität, DP-Budgets, Data Lineage-Invarianten.

2) Architekturmodell PaC

PAP (Policy Administration Point): Repository und Managementprozesse (MR/PR, Revue, Version).
PDP (Policy Decision Point): Eine Engine, die eine Policy-Entscheidung berechnet (OPA, Cedar-Engine, eigener Interpreter).
PEP (Policy Enforcement Point): Anwendungspunkt (API-Gateway, Webhook-Admission in K8s, ETL-Transformator, SDK).
PIP (Policy Information Point): Attribut-/Faktenquellen: IdP, Ressourcenkataloge, Datenlager, Risikoabfrage.
Decision Log/Audit: unveränderliche Entscheidungsprotokolle (zur Analyse von Incidents und Compliance).

Thread: Die Abfrage → PEP bildet den Kontext → PDP lädt Fakten (PIP) → berechnet die Lösung → PEP wendet (allow/deny/revision) → Log/Metriken an.

3) Tools und Domains

OPA/Rego ist eine universelle Engine und Sprache für deklarative Richtlinien (Webhook-Admission in K8s: Gatekeeper, in CI - Conftest, in API - sidecar/Service).
Kyverno - deklarative Richtlinien für Kubernetes in YAML, Patch/Validierung/Generierung.
Cedar (AWS/portable) ist eine politische Sprache mit einem Schwerpunkt auf der Autorisierung von „Jemand-über-was-was“.
Cloud IAM (AWS/GCP/Azure) - Cloud-Ressourcenrichtlinien (vorzugsweise PaC-Check-to-Statik und in IaC-Plänen).
Custom - DSL/Regeln über JSON/SQL für spezifische Funktionen (z.B. ML-Compliance).

4) Der Lebenszyklus der Politik

1. Definition von Ziel und Domäne: „Verbot des Ladens von Containern mit High/CRITICAL-Schwachstellen“.
2. Formalisierung im Code: Rego/Cedar/YAML.
3. Tests: Wahrheitstabellen, Negativfälle, eigenschaftsbasiert.
4. CI-Checks: Linter, Unit, Integration auf fiktiven Manifesten/Anfragen.
5. Veröffentlichung und Verteilung: Veröffentlichung im Bundle, Unterschrift, Lieferung an PDP/Edge.
6. Überwachung: Trefferquote, Latenz p95/p99, Anteil deny, Drift Dashboards.
7. Ausnahmen/waivers: zeitlich begrenzt/Umfang, mit Audit und Eigentümer.
8. Refactoring und Archiv: Versionen, Kompatibilität, Migrationen.

5) Lagerung und Verteilung

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Versionierung: semver und 'policy _ version' in PDP-Antworten.
Bundles: komprimierte Pakete von Richtlinien + Schemas + Config, signiert (Supply Chain Security).
Verteilung: Pull (PDP zieht aus dem registry/S3) oder Push (Controller sendet).
Partielle Bewertung: Antizipation von Richtlinien für eine schnelle Ausführung am Perimeter.

6) Datenmodell und Schema

Einheitlicher Kontextvertrag: „subject“, „resource“, „action“, „env“, „legal“.
JSON-Schema/Protobuf: Validieren Sie die Faktenmodelle; Die Nichtübereinstimmung der Schemen - der Grund für „indeterminate → deny“.
Normalisierung der Attribute: einheitliche Namen (z.B. 'tenant _ id', 'risk _ level', 'pii _ tags', 'image. vulns`).

7) Leistung und Zuverlässigkeit

Entscheidungscache: Schlüssel'(subject_hash, resource_key, Aktion, policy_version)'; kurze TTL, Behinderung durch Ereignisse (Rollen-/Tag-Wechsel).
Lokale Fakten: Ziehen Sie keine schweren PIPs auf dem heißen Weg - synchronisieren Sie die Schnappschüsse.
Fail-open vs fail-closed: Sicherheit kritischer Domains - fail-closed; für UX-kritische - Degradierung (Redaktion statt Deny).
Latenzbudget: Ziel'<3-10 ms' pro Lösung im PDP-Speicher,'<30-50 ms' mit PIP.

8) Verwaltung von Ausnahmen (waivers)

Zeitlich begrenzt (z.B. 7 Tage), mit Pflichtbesitzer und Grund.
Koopiert: nach Ressource/Proekt/Neymspace; Verbot der globalen „für immer“.
Audits und Erinnerungen: Berichte über ablaufende waiver 'am, Auto-Closing/Eskalation.

9) Metriken und Beobachtbarkeit

Policy Coverage: Anteil der PaC-geschützten Pfade/Endpunkte.
Decision Latency / QPS / Error rate.
Deny Rate und False Positive/Negative (über den Modus „dry-run/shadow“).
Drift: Diskrepanz zwischen Plan (IaC) und Fakt (live), zwischen SDK und Serverlösungen.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) Anti-Muster

Richtlinien, die in Code ohne Versionen und Tests „eingenäht“ sind.
Fehlende Schemata/Kontextvalidierung → unvorhersehbare Entscheidungen.
Eine monolithische Datei "mega. rego».
Es gibt keinen Ausschlussprozess → „manuelle Runden“ und Chaos.
Nur Laufzeitanwendung ohne „shift-left“ im CI (Spätfehler).
Versteckte Seiteneffekte in der Politik (Politik muss eine reine Funktion sein).

11) Beispiele

11. 1 Rego (OPA): Verbot gefährdeter Bilder in K8s

rego package k8s. admission. vulns

deny[msg] {
input. kind. kind == "Pod"
some c img:= input. request. object. spec. containers[c].image vulns:= data. registry. scan [img] # actual-snapshot from PIP count ({v     v:= vulns[_]; v.severity == "CRITICAL"}) > 0 msg:= sprintf("image %s has CRITICAL vulns", [img])
}

11. 2 Rego: Datenexport nur mit MFA und über „weiße“ IP

rego package api. export

default allow = false

allow {
input. action == "export"
input. subject. mfa_verified == true net. cidr_contains("203. 0. 113. 0/24", input. env. ip)
}

11. 3 Cedar: Nur für Besitzer oder Teammitglieder lesen

cedar permit(
principal in Group::"team_members",
action in [Action::"read"],
resource in Photo::"")
when { resource. owner == principal          resource. team_id in principal. team_ids };

11. 4 Kyverno (YAML): das Verbot ':latest ' und objas. Ressourcen

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: disallow-latest-and-require-limits spec:
validationFailureAction: Enforce rules:
- name: disallow-latest match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image tag 'latest' is not allowed."
pattern:
spec:
containers:
- name: ""
image: "!:latest"
- name: require-limits match: { resources: { kinds: ["Pod"] } }
validate:
message: "resources. limits.{cpu,memory} required."
pattern:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"

11. 5 Conftest in CI für Terraform-Plan

bash terraform plan -out tf. plan terraform show -json tf. plan > tf. json conftest test tf. json --policy policies/terraform

12) Einbettung in bestehende Fähigkeiten

RBAC/ABAC: PaC - Deklarationsschicht; PDP/PEP aus dem Artikel über die Rollenspiel-Engine werden überstrapaziert.
Zustimmungsmanagement: Richtlinie „Anzeigen/Personalisierung“ als Bedingungen für den Zugriff auf Daten/Endpunkte.
Anonymisierung/PII: Politiker verbieten Training/Export ohne Anonymisierungsprofile und DP-Budget.
Geo-Routing: Eine Richtlinie zum Routen von Datenverkehr/Daten nach Speicherregionen.

13) Prozesse und Menschen

Policy Domain-Inhaber: Sicherheit, Plattform, Daten, Produkt/Marketing.
Revuers: Sicherheit + Domain-Besitzer.
Richtlinienkatalog: Zielbeschreibung, Risiko, SLO, Kontakt, Beispiele, Incident Links.
Training: Guides und Snippets für Entwickler (wie man Tests schreibt, wie man Rego debuggt).

14) Checkliste des Architekten

1. Sie haben einen Mindestsatz an Domains und Owners definiert?
2. Policy Repository mit Tests, Linter und CI?
3. Werden PDPs/PEPs am Perimeter, in der API, im K8s und in den Daten-Pipelines platziert?
4. Gibt es Kontextdiagramme und Validierung?
5. Unterschrift und Bundle-Lieferung, Cache-Strategie und Behinderung?
6. Metriken (Latency, Deny, Drift), Decision-Log und Audit?
7. Ausnahmeprozess mit TTL und Reporting?
8. Dry-Run/Shadow-Modus vor Enforce?
9. Partielle Auswertung/Vorkompilierung für „heiße“ Wege?
10. Runbook auf Degradation (fail-closed/allow-with-reduction)?

Schluss

Policy as Code macht Regeln reproduzierbar, überprüfbar und handhabbar nach den gleichen Prinzipien wie eine App: Code Revue, Tests, CI/CD, Metriken und Rollbacks. Durch die Verbindung von PaC mit Autorisierung (RBAC/ABAC), Compliance und Plattformsicherheit erhalten Sie eine einheitliche, vorhersehbare und skalierbare Regelschleife für das Systemverhalten - von der Zugriffskontrolle über Datenexporte bis hin zu ML-Pipelines.