Policy as Code

Wie Policy as Code funktioniert

Viele technische Systeme besitzen Regeln.

Sie können beispielsweise lauten:

Produktivsysteme dürfen nicht direkt aus dem Internet administrierbar sein.

oder:

Anwendungskomponenten dürfen nicht direkt auf die Datenbank zugreifen.

oder:

Direkte Ausgaben auf stdout sind in diesem Projekt nicht erlaubt.

Solange solche Regeln nur in Dokumentationen, Besprechungen oder den Köpfen beteiligter Personen existieren, müssen Menschen ihre Einhaltung bei jeder relevanten Änderung erneut überprüfen.
Policy as Code versucht, geeignete Regeln so zu formalisieren, dass diese Prüfung zumindest teilweise durch Maschinen erfolgen kann.

Von der Aussage zur prüfbaren Regel

Nicht jede verständliche Regel ist bereits maschinell prüfbar.

Die Aussage:

Unsere Server müssen sicher konfiguriert sein.

ist für Menschen verständlich.
Für eine automatische Prüfung ist sie jedoch zu unbestimmt.
Zunächst müsste beschrieben werden, welche beobachtbaren Eigenschaften unter „sicher konfiguriert“ verstanden werden.

Daraus könnten beispielsweise konkretere Regeln entstehen:

SSH-Passwortanmeldung ist deaktiviert.

Root-Login über SSH ist deaktiviert.

Dienst X darf ausschließlich auf dem internen Interface lauschen.

Erst wenn ausreichend klar ist, welcher Zustand erlaubt oder nicht erlaubt ist, kann daraus eine maschinenlesbare Policy entstehen.

Eine Policy benötigt Informationen

Eine Policy kann nur Eigenschaften auswerten, für die ihr geeignete Informationen zur Verfügung stehen.

Angenommen, die Regel lautet:

Produktionsdaten dürfen nicht auf Entwicklungssystemen gespeichert werden.

Dann benötigt die Prüfung unter anderem Informationen darüber:

Welche Daten sind Produktionsdaten?
Welche Systeme sind Entwicklungssysteme?
Wo werden die betreffenden Daten tatsächlich gespeichert?

Fehlen diese Informationen, kann auch eine formal perfekt geschriebene Policy die Regel nicht zuverlässig prüfen.
Policy as Code besteht deshalb nicht nur aus der Policy selbst.
Auch die Qualität und Bedeutung ihrer Eingabedaten bestimmen, welche Aussage die Auswertung erlaubt.

Aus Regel und Zustand entsteht eine Entscheidung

Vereinfacht kann eine Policy-Auswertung so aussehen:

Policy
   +
beobachteter Zustand
   ↓
Auswertung
   ↓
Ergebnis

Beispielsweise:

Policy:
frontend darf database nicht direkt verwenden

Zustand:
frontend → database

Ergebnis:
Regel verletzt

Oder:

Policy:
SSH-Passwortanmeldung muss deaktiviert sein

Zustand:
PasswordAuthentication no

Ergebnis:
Regel erfüllt

Dabei ist entscheidend, dass die Policy nicht den gewünschten Zustand mit dem tatsächlichen Zustand verwechselt.
Sie benötigt Informationen über das tatsächlich zu prüfende System.

Nicht alles ist wahr oder falsch

Eine einfache Policy kann zwei Ergebnisse besitzen:

erfüllt
verletzt

In realen Systemen kann jedoch ein weiterer Zustand wichtig sein:

nicht bewertbar

Beispielsweise verlangt eine Policy:

Dienst X darf ausschließlich intern erreichbar sein.

Das Prüfwerkzeug kennt jedoch nur die lokale Konfiguration des Dienstes und nicht die davorliegenden Firewall- oder Netzwerkregeln.

Dann wäre die Aussage:

Regel erfüllt

möglicherweise stärker als die vorhandene Evidenz erlaubt.
Ein sinnvoller Prüfprozess muss deshalb unterscheiden können zwischen:

Regel erfüllt
Regel verletzt
nicht ausreichend bekannt

Die genaue technische Darstellung solcher Zustände hängt vom verwendeten Policy-System ab.
Das zugrunde liegende Problem bleibt jedoch dasselbe.

Policy und Enforcement sind nicht dasselbe

Eine Policy kann eine Abweichung feststellen.
Was anschließend geschieht, ist eine weitere Entscheidung.

Mögliche Reaktionen sind beispielsweise:

protokollieren

Warnung erzeugen

manuelle Prüfung anfordern

Deployment blockieren

Zugriff verweigern

Ausnahme dokumentieren

Damit lassen sich zwei Schritte unterscheiden:

Evaluation:
Entspricht der Zustand der Policy?

Enforcement:
Welche Konsequenz hat das Ergebnis?

Nicht jede Policy muss automatisch durchgesetzt werden.

Automatische Korrektur ist noch einmal etwas anderes

Eine weitere Stufe wäre:

Abweichung erkannt
        ↓
System verändert Zustand automatisch
        ↓
Policy erneut prüfen

Beispielsweise könnte ein System eine unerlaubte Konfiguration automatisch zurücksetzen.
Das kann für bestimmte klar definierte Fälle sinnvoll sein.
Es ist aber nicht notwendiger Bestandteil von Policy as Code.

Zwischen:

Wir können die Abweichung erkennen.

und:

Wir wissen automatisch, wie auf diese Abweichung reagiert werden muss.

liegt ein erheblicher Unterschied.

Ausnahmen gehören zum Regelsystem

Nicht jede Abweichung muss dauerhaft verboten sein.

Eine Architekturregel könnte beispielsweise festlegen:

Komponente A darf nicht direkt auf Datenbank B zugreifen.

Für eine Migration ist dieser Zugriff vorübergehend notwendig.
Eine mögliche Ausnahme könnte deshalb zusätzliche Bedingungen enthalten:

Ausnahme:
Komponente A → Datenbank B

Grund:
Datenmigration

gültig bis:
2026-10-31

verantwortlich:
Migrationsteam

Damit wird die Regel nicht heimlich umgangen.
Die Ausnahme wird damit selbst zu einem expliziten Bestandteil des Regelsystems und seiner Bewertung.
Nach Ablauf der Ausnahme kann erneut geprüft werden, ob sie noch benötigt wird.

Policies können versioniert werden

Maschinenlesbare Policies können wie andere technische Artefakte versioniert werden.

Dadurch lässt sich nachvollziehen:

Welche Regel galt zu welchem Zeitpunkt?
Wann wurde sie verändert?
Warum wurde sie verändert?
Welche Systeme waren davon betroffen?

Das ist besonders wichtig, wenn sich Anforderungen im Laufe der Zeit verändern.
Ein System kann heute regelkonform sein und morgen gegen eine neu eingeführte Policy verstoßen, obwohl sich am System selbst nichts geändert hat.
Die Bewertung eines Zustands hängt deshalb auch von der jeweils gültigen Version der Regeln ab.

Eine Policy kann selbst fehlerhaft sein

Maschinenlesbare Regeln können Fehler enthalten.

Eine falsch formulierte Policy kann:

• gültige Zustände als Fehler markieren
• tatsächliche Verstöße übersehen
• falsche Annahmen über Eingabedaten besitzen
• unerwartete Sonderfälle nicht berücksichtigen
• aufgrund einer Regeländerung falsche Ergebnisse erzeugen

Policies müssen deshalb selbst überprüft und getestet werden.

Ein Test könnte beispielsweise bekannte Zustände enthalten:

Fall A:
bekannt gültig
→ Policy muss erlauben

Fall B:
bekannt ungültig
→ Policy muss Verletzung melden

Fall C:
notwendige Information fehlt
→ Policy darf keine unbegründete Freigabe erzeugen

Policy as Code verschiebt Regeln damit nicht aus dem Qualitätssicherungsproblem heraus.
Es macht die Regeln selbst zu einem Teil des technischen Systems.

Policies und Architekturkonformität

Architekturkonformität untersucht, ob ein tatsächliches System mit seinen Architekturvorgaben übereinstimmt.
Policy as Code kann eine Möglichkeit sein, bestimmte Architekturvorgaben maschinenlesbar zu formulieren.

Aus:

Alle Ausgaben müssen über die zentrale Ausgabekomponente erfolgen.

kann beispielsweise eine prüfbare Regel entstehen.
Ein Werkzeug untersucht anschließend den Quellcode und liefert Informationen über direkte Ausgaben.
Die Policy bewertet diese Informationen.

Damit entsteht:

Architekturentscheidung
        ↓
formalisierte Policy
        ↓
Information über Ist-Zustand
        ↓
Policy-Auswertung
        ↓
Konformität / Abweichung

Nicht jede Architekturregel eignet sich dafür.
Aber Regeln, die sich eindeutig auf beobachtbare Eigenschaften abbilden lassen, können wiederholbar geprüft werden.

Policies und KI-generierte Ergebnisse

Policy as Code wird besonders interessant, wenn Ergebnisse nicht mehr ausschließlich von Menschen erzeugt werden.

Ein Sprachmodell kann eine Regel als Kontext erhalten:

Verwende niemals direkte stdout-Ausgaben.

Das verbessert möglicherweise die Wahrscheinlichkeit, dass die Regel eingehalten wird.
Es beweist ihre Einhaltung jedoch nicht.

Nach der Generierung kann deshalb unabhängig geprüft werden:

KI erzeugt Code
      ↓
Policy prüft Code
      ↓
Regel erfüllt / verletzt

Damit wird die Regel nicht nur zu einer Anweisung für das probabilistische System.

Ihre Einhaltung wird zusätzlich zu einer überprüfbaren Eigenschaft seines Ergebnisses.

Policy as Code ist nicht KI-spezifisch

Der Ansatz existiert unabhängig von generativer KI.

Typische Einsatzgebiete sind beispielsweise:

• Zugriffssteuerung
• Infrastrukturkonfiguration
• Cloud-Ressourcen
• Sicherheitsvorgaben
• Softwarearchitektur
• Deployment-Regeln
• Compliance-Prüfungen

KI-Systeme schaffen lediglich weitere Anwendungsfälle.
Insbesondere bei automatisch erzeugten Änderungen kann eine unabhängige maschinenlesbare Prüfung sinnvoll sein.
Das zugrunde liegende Prinzip bleibt dasselbe:

Eine Regel wird so beschrieben, dass ihre Einhaltung anhand geeigneter Informationen wiederholbar ausgewertet werden kann.

Regeln besitzen einen Gültigkeitsbereich

Eine Policy ist nicht automatisch universell.

Eine Regel kann beispielsweise nur gelten:

für Produktionssysteme

oder:

für Modul A

oder:

ab Version 3

oder:

während des normalen Betriebs

Der Gültigkeitsbereich gehört damit zur Bedeutung der Regel.
Eine formal korrekte Policy, die auf den falschen Systembereich angewendet wird, kann ein formal korrektes und trotzdem sachlich unbrauchbares Ergebnis erzeugen.

Auch bei maschinenlesbaren Regeln bleibt deshalb die Frage wichtig:

Wo und unter welchen Bedingungen gilt diese Regel?

Warum Policy as Code praktische Auswirkungen hat

• Regeln werden wiederholbar prüfbar: Geeignete Vorgaben müssen nicht ausschließlich manuell kontrolliert werden.
• Regeln können versioniert werden: Änderungen an Vorgaben werden nachvollziehbar.
• Prüfung und Durchsetzung können getrennt werden: Eine erkannte Abweichung muss nicht automatisch blockiert werden.
• Ausnahmen können explizit werden: Abweichungen müssen nicht heimlich außerhalb des Regelsystems existieren.
• Automatisierte Änderungen können unabhängig geprüft werden: Auch KI-generierter Code kann denselben Regeln unterliegen.
• Architekturentscheidungen können näher an der Implementierung bleiben: Bestimmte Vorgaben lassen sich direkt gegen den tatsächlichen Zustand prüfen.
• Unwissen kann sichtbar bleiben: Fehlende Informationen müssen nicht zwangsläufig in eine scheinbar eindeutige Entscheidung umgewandelt werden.
• Policies werden selbst überprüfbar: Maschinenlesbare Regeln können getestet und weiterentwickelt werden.

Typisches Beispiel

Ein Projekt besitzt die Architekturregel:

Direkte Kommandozeilenausgaben aus Fachkomponenten sind nicht erlaubt.

Die Regel wird formalisiert.
Ein Analysewerkzeug liefert für eine Änderung:

file: order.lua
line: 184
operation: direct_stdout

Die Policy bewertet diesen Zustand:

rule: no_direct_stdout
result: violation

Damit ist zunächst nur festgestellt:

Die beobachtete Änderung entspricht nicht der geltenden Regel.

Die Projektkonfiguration legt anschließend fest:

lokale Entwicklung:
Warnung

Pull Request:
Review erforderlich

Release:
Blockieren

Für einen besonderen Diagnosefall existiert außerdem eine dokumentierte Ausnahme.
Die gleiche Policy kann damit in unterschiedlichen Situationen unterschiedliche Konsequenzen besitzen, ohne dass die eigentliche Architekturregel verändert werden muss.

Abgrenzung

• Policy as Code bezeichnet die maschinenlesbare Formalisierung von Regeln und Richtlinien, sodass diese automatisiert ausgewertet werden können.
• Architekturkonformität beschreibt die Übereinstimmung zwischen tatsächlichem System und Architekturvorgaben. Policy as Code kann ein Werkzeug für solche Prüfungen sein.
• Verifikation und Validierung sind allgemeinere Verfahren zur Untersuchung von Anforderungen und vorgesehenem Einsatzzweck. Policy-Prüfungen können Bestandteil einer Verifikation sein.
• Monitoring oder Beobachtbarkeit liefern Informationen über Zustände und Verhalten. Eine Policy kann solche Informationen auswerten, ist aber nicht mit ihrer Erfassung gleichzusetzen.
• Enforcement bezeichnet die Durchsetzung einer Entscheidung. Eine Policy kann Grundlage dafür sein, ohne dass automatische Durchsetzung notwendiger Bestandteil von Policy as Code ist.

Weiterführend

Verwandte Begriffe

→ Architekturkonformität
→ Systemarchitektur
→ Verifikation und Validierung
→ Beobachtbarkeit
→ Resilienz