Was ist Policy as Code (PaC)?

Anstatt sich auf Menschen zu verlassen, um die Einhaltung von Vorschriften zu überprüfen oder sich Sicherheitsregeln zu merken, existieren diese Regeln als ausführbare Logik, die immer dann ausgeführt wird, wenn ein Entwickler oder ein System eine Änderung oder Anforderung vorschlägt. Wenn jemand eine Änderung absendet, bewertet eine Policy-Engine die Änderung automatisch anhand der codierten Regeln und genehmigt, verweigert oder kennzeichnet sie.

Dieser Prozess verlagert die Richtlinienverwaltung von statischen Dokumenten hin zu einer dynamischen, kontinuierlich durchgesetzten Kontrolloberfläche, die in die Delivery Pipeline eingebettet ist.

Codebasierte Regeln tragen dazu bei, dass überall dieselben Richtlinien wiederholbar und skalierbar angewendet werden. Policy-Engines können automatische Prüfungen in Sekundenschnelle während der Entwicklung oder Bereitstellung durchführen, was die Feedback-Zyklen verkürzt und DevOps-Teams hilft, Sicherheits- oder Compliance-Überraschungen in späten Phasen zu vermeiden.

PaC ermöglicht es Unternehmen, ihre allgemeine Cybersicherheit zu verbessern und die Einhaltung von Branchen- und regulatorischen Standards aufrechtzuerhalten. Darüber hinaus entspricht die Behandlung von Richtlinien wie Code einem breiteren „Alles als Code“-Übergang, der Infrastrukturanfragen in überprüfbare Codedateien verwandelt, damit die Entwicklungsteams zusammenarbeiten können.

In Bezug auf DevOps ist eine Richtlinie eine klare, durchsetzbare Regel darüber, wie IT-Infrastruktur und Anwendungen konfiguriert oder ausgeführt werden müssen, bzw. wie auf sie zugegriffen werden kann. Genauer gesagt legen diese Richtlinien fest, welche Handlungen erlaubt, erforderlich oder verboten sind, damit Systeme in ihrem idealen Zustand weiterlaufen. 

Zum Beispiel handelt es sich bei „Alle Speicher-Buckets müssen verschlüsselt sein“ oder „kein öffentlicher Dienst kann Port 22 offenlegen“ um Richtlinien, weil sie konkrete Einschränkungen für das Systemverhalten festlegen.

Bei PaC werden Richtlinien in einer strukturierten Programmiersprache geschrieben, sodass Policy-Engines und Automatisierungstools sie deterministisch analysieren und auswerten können. Auf diese Weise werden Richtlinien zu ausführbaren Vorgaben, die Systeme und Techniker erfüllen müssen, anstatt zu bloßen Leitlinien, die von verschiedenen Personen unterschiedlich interpretiert werden könnten.

Policy-as-Code-Tools ermöglichen es Entwicklern, ausführbaren Code in Laufzeitumgebungen und in Continuous Integration/Continuous Delivery (CI/CD) Pipelines zu schreiben, sodass jede Änderung automatisch auf Einhaltung überprüft wird.

Technisch gesehen folgen die meisten PaC-Setups den gleichen Kernschritten:

• Entwickler schreiben Richtlinien in Form von Codedateien. Sie können eine Reihe von hochrangigen imperativen und deklarativen Sprachen verwenden, darunter Python, YAML, JavaScript Object Notation (JSON) oder Rego, was in der Regel zusammen mit dem Open Policy Agent (OPA), einer Open-Source-Policy-Engine, verwendet wird. Jede Richtliniendatei deklariert die Eingaben, die für sie relevant sind („resource.kind“ oder „metadata.labels“ als Beispiele) und kodiert Bedingungen – auch „Prädikate“ genannt – und Ergebnisse (Erlauben/Verweigern, Schweregrad, Meldungen).

• Der Code wird an ein Versionskontrollsystem wie Git oder GitHub übermittelt und durchläuft die gleichen Workflows wie Anwendungscode, einschließlich Pull Requests, Reviews und rigoroser Syntaxtests.

• Eine Policy-Engine liest die Codedatei, analysiert sie und wandelt sie in intern verständliche Datenstrukturen und Anweisungen um. Diese Strukturen und Anweisungen werden dann zur schnellen Auswertung in ein kompaktes, niedrigstufiges Anweisungsformat (Bytecode) umgewandelt.

• Ein Aufrufer – das Codestück, das die Policy-Engine nach einer Entscheidung fragt – normalisiert die Eingaben. Der Aufrufer verarbeitet verschiedene Eingabeformate, darunter HashiCorp Configuration Language (HCL) Dateien und JSON-Vorlagen von IaC-Tools, YAML-Manifeste von Kubernetes und Cloud-Plattformen, HTTP-Anfragen von API-Aufrufen sowie App-Daten und Telemetriedaten aus Laufzeit- und Produktionsumgebungen. Er bereinigt und formt die Roheingabe zu einer Standardstruktur um, sodass die Richtlinien die Eingabe auf konstante Weise lesen können.

• Der Aufrufer gibt die normalisierten Daten an die Richtlinien-Engine zurück, die damit beginnt, Richtliniencode gegen die Dateneingaben auszuführen.  

• Die Policy-Engine geht die Regeln durch und vergleicht die Prädikate jeder Regel mit den Eingaben, um zu verstehen, welche Prädikate gelten. Man kann es sich so vorstellen, dass die Policy-Engine fragt: „Was sagt diese Regel über diese Eingabe aus?“

• Die Policy Engine nimmt die Ergebnisse aller Regeln und kombiniert sie zu einer einzigen Policy Decision– ein Prozess namens Decision Aggregation – und erstellt eine Liste von Nachrichten. Nachrichten enthalten mehr Details (welche Regel verletzt wurde und welches Objekt sie verletzt hat) über fehlerhaften Code und bieten manchmal Vorschläge für Fixes an.

• Die Policy-Engine gibt die Entscheidung einschließlich relevanter Meldungen, Tags und Informationen zum Schweregrad zurück. Lautet die Entscheidung „Verweigern“, blockiert die Policy-Engine alle Pull-Anfragen und Code-Merges und stoppt die Bereitstellung, bis die Entwickler den Richtlinienverstoß beheben. Wenn die Entscheidung „Zulassen“ lautet, erstellt die Engine ein Build-Artefakt (eine kompilierte, verpackte und getestete Codedatei) und stellt den Code bereit. Wenn Warnungen vorliegen, darf der Code weitergegeben werden, aber die Engine nimmt die Warnungen in Logdateien oder Kommentaren auf. 

Richtlinienprüfungen können zu jedem Zeitpunkt des Softwareentwicklungszyklus (SDLC) erfolgen, von der Code-Integration bis hin zur Live-Produktion und Überwachung.

Da Richtlinien Code sind, können sie auch wie jedes andere Software-Artefakt behandelt werden.

Entwicklungsteams können automatisierte Tests schreiben, die Stichprobeneingaben in die Richtlinien einspeisen und die Entscheidungen überprüfen, die sie zurückgeben, um die Feedbackzyklen bei Änderungen der Richtlinien zu beschleunigen.

Wenn Richtlinien kodiert werden, können Entwickler gemeinsame Logik in wiederverwendbare Module oder Funktionen auslagern. Mehrere übergeordnete Richtlinien greifen dann auf gemeinsam genutzte Richtlinien zurück, anstatt Bedingungen überall zu duplizieren.

Entwickler können große Richtlinien auch umbenennen, umstrukturieren oder in kleinere aufteilen, ohne deren Verhalten zu ändern, genau wie beim Refactoring einer großen App-Funktion in kleinere.

Diese Funktionen ermöglichen es Teams, bestehende Software-Engineering-Praktiken auf Governance-Logik anzuwenden, was ihnen dabei hilft, Sicherheits- und Compliance-Anforderungen aufrechtzuerhalten, während IT-Architekturen skalieren und sich weiterentwickeln.

Nehmen wir an, Unternehmen X möchte eine „Nur-HTTPS“-Richtlinie einführen, nach der jeder Webdienst HTTPS und nicht einfaches HTTP verwenden muss. Um die Richtlinie zu kodifizieren, verfasst ein Plattformentwickler eine einfache Regel, die besagt:

• Wenn das Protokoll eines Dienstes HTTP ist, sollte die Änderung abgelehnt werden.
• Wenn das Protokoll eines Dienstes HTTPS ist, ist die Änderung erlaubt.

Der Techniker legt diese Richtliniendatei in einen Ordner „Policies“ im selben Code-Repository wie die Anwendung ab und öffnet einen Pull Request, um die Richtlinie hinzuzufügen. Dieser Pull Request löst eine automatische Syntaxprüfung der Richtliniendatei und eine Code-Überprüfung durch einen anderen Techniker aus. Erst wenn die Richtlinie die notwendigen Tests bestanden hat, wird sie in den Hauptzweig übernommen.

In der Continuous Integration (CI) Pipeline werden alle Richtliniendateien aus dem Ordner „Policies“ in die Policy-Engine geladen. Die Policy-Engine liest die Richtlinie, wandelt sie in eine interne Repräsentation um und kompiliert sie in eine kompakte, niedrigschwellige Form. Diese kompakte Form ermöglicht es dem System, für jeden Dienst, den die Pipeline prüft, schnell die Frage „Zulassen oder Verweigern?“ zu beantworten.

Unabhängig vom Dateiformat nimmt ein CI-Job die vorhandene Konfigurationsdatei, extrahiert die wichtigen Felder (Name, Protokoll, Port) und erstellt eine einfache JSON-Beschreibung für jeden Dienst.

Der Aufrufer bittet die Policy-Engine um eine Entscheidung, indem er die standardisierte Servicebeschreibung als Eingabe sendet und angibt, dass das Richtlinienpaket für „Nur HTTPS“ angewendet werden soll.

Die Policy-Engine bewertet dann die Eingabe im Vergleich zu den Regeln. Sie prüft das Protokollfeld des Dienstes. Wenn das Protokoll HTTP ist, bedeutet dies, dass die Eingabe der „Verweigern“-Bedingung in der Richtlinie entspricht. Die Engine signalisiert, dass die Änderung abgelehnt werden sollte, und erstellt eine Meldung, die den Entwickler darauf hinweist, dass der Dienst HTTPS anstelle von HTTP verwenden muss. Wenn der Dienst HTTPS verwendet, ist keine der Ablehnungsbedingungen erfüllt, und die Engine signalisiert, dass die Änderung zulässig ist.

Anschließend fasst die Policy-Engine die Regelbewertungen in einem einzigen Entscheidungsobjekt für den Service zusammen. Entscheidungsobjekte legen in der Regel fest, ob die Gesamtentscheidung „Zulassen“ oder „Verweigern“ lautet und wie schwerwiegend das Problem ist (hoch, mittel, niedrig). Sie enthalten außerdem eine Liste von Meldungen, die erläutern, warum die Eingabe abgelehnt wurde, sowie alle Warnungen, die die Engine während der Bewertung gefunden hat. Wenn alle Bedingungen erfüllt sind, besagt das Entscheidungsobjekt, dass die Änderung zulässig ist und enthält lediglich informative Hinweise (oder gar keine Meldungen).

Schließlich setzen CI-Tools die Entscheidung durch. Lautet die Entscheidung „Verweigern“, kann die Änderung nicht in den Hauptcodezweig übernommen werden. Der Techniker sieht eine Fehlermeldung, die besagt, dass der Dienst HTTPS verwenden und bestimmte Änderungen vornehmen muss. Lautet die Entscheidung „Zulassen“, wird das Artefakt verpackt und bereitgestellt, und die CI-Pipeline wird wie gewohnt fortgesetzt.

Policy as code entstand aus einer breiter gefassten „Alles als Code“-Bewegung im modernen DevOps- und Cloud-Engineering.

Ursprünglich stellte Infrastructure as Code (IaC) die große Veränderung dar. Systemadministratoren mussten sich nicht mehr durch Benutzeroberflächen klicken oder Runbooks folgen, dafür beschrieben Teams Server, Netzwerke und andere Ressourcen in deklarativen Codedateien. Diese Dateien werden in Versionskontrollsystemen gespeichert und über automatisierte Pipelines angewendet.

Als Unternehmen die Vorteile erkannten, breitete sich der Ansatz auf andere Komponenten der IT-Architektur aus. Die Anwendungskonfiguration wurde auf codebasierte Ansätze umgestellt. CI/CD-Pipelines wurden zu Skripten, die in Code-Repositories gespeichert sind. Auch Überwachungs- und Alarmierungsregeln wurden in den Code integriert. Zusammen wurden diese Praktiken unter dem Begriff „Alles als Code“ bekannt.

Die zentrale Idee von „Alles als Code“ besteht darin, dass, wenn ein Teil des Systems beschrieben werden kann, dieser als Code beschrieben und auf die gleiche Weise wie Anwendungen verwaltet werden sollte.

PaC ist im Wesentlichen die Anwendung dieser Philosophie auf Regeln, Governance und Compliance. Traditionell waren die Richtlinien in PDFs und Wikis gespeichert oder wurden von einem Komitee entschieden und von Menschen durchgesetzt. Dieses Verfahren funktionierte, solange die Releasezyklen langsam und die Infrastruktur relativ statisch waren.

Als cloudnative und Microservice Architekturen die Oberhand gewannen und Teams damit begannen, mehrmals täglich Code bereitzustellen, konnten manuelle Prozesse nicht Schritt halten. PaC hat diese Herausforderung gelöst, indem Richtlinien in maschinenlesbaren Formaten formuliert werden, sodass sie in Git versioniert, wie Code-Dateien überprüft, in CI getestet und automatisch in Pipelines oder zur Laufzeit durchgesetzt werden können.

Policy as Code ist eine Methode zur Verwaltung von IT-Richtlinien wie Softwarecode. Infrastructure as Code (IaC) ist ähnlich, aber mit einem anderen Schwerpunkt. Es ermöglicht Entwicklungsteams, die IT-Infrastruktur mithilfe von Anwendungscode zu definieren und zu verwalten.

Anstatt Netzwerkressourcen wie virtuelle Maschinen (VMs) und Load Balancer manuell zu erstellen und zu konfigurieren, ermöglicht IaC Entwicklern, Code zu schreiben, der den gewünschten Zustand dieser Ressourcen beschreibt. Ein IaC-Tool nimmt dann diesen Code und erstellt oder modifiziert die angegebenen Ressourcen.

IaC vereinfacht die Skalierung und Automatisierung der Infrastruktur erheblich. Wenn ein Team mehr Server braucht, kann es einfach eine Zahl im Code ändern (zum Beispiel von sechs auf neun). Automatisierungstools übernehmen die Details der Bereitstellung dieser zusätzlichen Ressourcen.

Auf einer übergeordneten Ebene legt IaC fest, welche Infrastruktur vorhanden und wie sie konfiguriert sein sollte, während PaC sich auf die Regeln und Einschränkungen konzentriert, die die Infrastruktur befolgen muss. IaC-Code erstellt und konfiguriert Ressourcen, und der PaC-Code hilft sicherzustellen, dass diese Ressourcen (und deren Nutzungsweise) definierten Sicherheitsanforderungen, Compliance-Standards und operativen Vorgaben entsprechen.

In vielen modernen IT-Architekturen und CI/CD-Systemen bieten IaC und PaC ergänzende Vorteile. IaC automatisiert die Bereitstellung und PaC fügt automatisierte Governance hinzu.

Wenn ein Entwickler eine IaC-Datei ändert, kann eine PaC-Engine den neuen Plan oder die neue Konfiguration überprüfen. Wenn alles mit den festgelegten Richtlinien übereinstimmt, kann die Änderung fortgesetzt und die Infrastruktur aktualisiert werden. Wenn etwas gegen eine Regel verstößt, schlägt die Pipeline fehl und es wird nichts bereitgestellt, bis das Problem behoben ist.

Bei DevSecOps geht es darum, Sicherheit und Compliance in den DevOps-Lebenszyklus einzubetten, anstatt sie am Ende noch einzubauen. Es handelt sich um einen Entwicklungsansatz, bei dem Sicherheitsprozesse in jeder Phase des Softwareentwicklungszyklus priorisiert und ausgeführt werden.

PaC unterstützt DevSecOps-Praktiken durch:

PaC hilft Teams dabei, die Sicherheit frühzeitig in den Entwicklungsprozess zu integrieren, indem Sicherheitsprüfungen in die frühesten Phasen des Entwicklungsprozesses verlagert werden, anstatt erst nach der Bereitstellung Prüfungen durchzuführen, wenn Probleme die Benutzer beeinträchtigen. Wenn ein Entwickler eine riskante Konfiguration oder ein unsicheres Muster einführt, können automatisierte Richtlinien helfen, das Problem zu erkennen und die Entwicklung zu unterbrechen.

PaC-Tools automatisieren die Durchsetzung, indem sie Sicherheitsregeln direkt in CI/CD-Pipelines und Laufzeitsysteme einbetten, sodass Überprüfungen jedes Mal automatisch erfolgen, wenn sich Code oder Infrastruktur ändert. Anstatt sich darauf zu verlassen, dass sich Menschen an jeden Sicherheitsstandard erinnern und jede Änderung manuell überprüfen, bewertet das System die Änderungen ständig, um sicherzustellen, dass kein Schritt versehentlich übersprungen wird.

PaC hilft Entwicklern, die Bereitstellungsgeschwindigkeit aufrechtzuerhalten, ohne Abstriche bei Konstanz und Sicherheit machen zu müssen. Es wendet in jeder Umgebung und in jeder Phase – Entwicklung, Test, Staging und Produktion – dieselben Richtliniendefinitionen an. Diese Funktion ermöglicht es Teams, häufig neue Releases zu veröffentlichen, da sie darauf vertrauen können, dass überall die gleichen Regeln angewendet werden. Es hilft ihnen außerdem, Situationen zu vermeiden, in denen verschiedene Umgebungen voneinander abweichen oder leicht unterschiedliche Interpretationen der Regeln verwenden.

PaC behandelt Anwendungssicherheitsrichtlinien wie jedes andere Code-Artefakt, das in einem Versionskontrollsystem existiert. Entwicklungs-, Betriebs- und Sicherheitsteams können alle Richtlinien mithilfe vertrauter Workflows (Reviews, Strategie) überprüfen, diskutieren und aktualisieren, wodurch Richtliniendiskussionen transparenter und besser in die tägliche Entwicklungsarbeit integriert werden.

Policy as code bietet eine breite Anwendung für IT-Architekturen in Unternehmen.

Entwickler und Sicherheitsexperten erkunden Policy as Code als eine Möglichkeit, mehrschichtige Leitplankenmodelle zu erstellen, die den gesamten Lebenszyklus eines KI- oder agentischen Workflows abdecken. Obwohl sich diese Praxis noch entwickelt, haben erste Untersuchungen viele mögliche Anwendungen von PaC in KI-Workflows aufgezeigt.

PaC kann dazu beitragen, eine klare Trennung zwischen dem Denkprozess der KI und dem System herzustellen, das entscheidet, welche Aktionen sie tatsächlich ausführen darf. Das KI-Tool kann Aktionen oder Pläne vorschlagen, aber eine Policy-Engine bewertet diese Vorschläge anhand kodifizierter Regeln, bevor ein zugrunde liegendes System angefasst wird.

Bereits in der Eingabe kann PaC dabei helfen, Benutzereingaben zu filtern oder zu transformieren, sensible Daten zu schwärzen, die Tenant-Isolation durchzusetzen und bekannte Angriffsmuster zu blockieren. Während der Planung kann PaC von KI-Agenten verlangen, strukturierte Pläne zu erstellen und jeden Schritt anhand der erlaubten Tools, Maßnahmen und Risikobedingungen zu validieren, bevor die Ausführung erlaubt ist.

Bei der Ausführung kann jeder Toolaufruf oder API-Aufruf von der Policy-Durchsetzungsebene überprüft werden. Die zuständige Instanz entscheidet, ob eine Handlung zugelassen, verweigert oder abgeändert oder an einen Menschen weitergeleitet wird. Nach der Ausführung können Richtlinien Protokollierung, Prüfprotokolle, Aufbewahrungsregeln und Nachfilter der Ausgaben steuern, um sicherzustellen, dass die Antworten den erforderlichen Anforderungen entsprechen.

• Konstanz. Mit PaC werden Richtlinien in allen Umgebungen auf die gleiche Weise angewendet, weil überall derselbe Code läuft. Diese Konstanz reduziert individuelle, „spezielle“ Konfigurationen und verhindert, dass sich Teams für jede Umgebung leicht unterschiedliche manuelle Prozesse merken müssen.

• Effizienz. Wenn Richtlinien kodifiziert sind, können sie automatisch in CI/CD-Pipelines oder bei der Bereitstellung durchgesetzt werden, sodass keine manuellen Prüfungen und Genehmigungen erforderlich sind.

• Automatisierung. PaC ermöglicht automatisierte Validierung und Policy-Tests, die Teams dabei unterstützen, die Auswirkungen menschlicher Fehler zu minimieren, Fehlkonfigurationen zu erkennen und Sicherheitslücken zu beheben, bevor sie in die Produktion kommen.

• Transparenz. Mit den im Code geschriebenen und zentral gespeicherten Richtlinien können die Stakeholder genau sehen, welche Regeln gelten, anstatt sich auf verstreute Dokumente und die Erinnerungen der Menschen verlassen zu müssen.

• Skalierbarkeit. Die Richtlinienauswertung ist automatisiert, sodass Unternehmen Richtlinien in großem Maßstab über viele Dienste, Cluster oder Konten hinweg durchsetzen können, ohne die Mitarbeiterzahl proportional zu erhöhen.

• Zusammenarbeit. PaC optimiert die Zusammenarbeit rund um den Policy-Code. Diese gemeinsamen Workflows überwinden Silos, bringen Sicherheit und Governance mit DevOps in Einklang und gestalten Richtliniendiskussionen konkreter und testbarer.