Policy-Engine

In jedem größeren Computersystem gibt es Regeln darüber, wer was tun darf. Ein Mitarbeiter der Buchhaltung darf Rechnungen sehen, ein Praktikant nicht. Ein Kunde darf sein eigenes Konto abfragen, aber kein fremdes. Eine Policy-Engine ist der Programmteil, der genau diese Prüfung übernimmt. Sie bekommt eine Anfrage vorgelegt, vergleicht sie mit einem hinterlegten Regelwerk und antwortet mit „erlaubt“ oder „verboten“. Das Besondere daran: Die Regeln stehen nicht verstreut im restlichen Programmcode, sondern gebündelt an einer Stelle.

Regeln ändern, ohne Software neu zu bauen

Früher waren solche Regeln fest in den Programmcode eingebaut. Wollte man eine einzige Vorschrift ändern, musste ein Entwickler den Code anfassen und die Anwendung neu ausliefern. Das dauerte Wochen und war fehleranfällig. Mit einer Policy-Engine ändert man stattdessen nur das Regelwerk. Die Anwendung selbst bleibt unangetastet.

Der zweite Vorteil ist die Nachvollziehbarkeit. Wenn alle Regeln an einer Stelle liegen, kann man sie lesen, prüfen und einer Aufsichtsbehörde vorlegen. Banken, Versicherungen und Krankenhäuser müssen genau das können. Sie müssen belegen, dass niemand unberechtigt auf sensible Daten zugreift. Eine Policy-Engine schreibt zudem meist mit, welche Anfrage wann wie entschieden wurde.

Wichtig ist die Abgrenzung zur Authentifizierung. Die Authentifizierung klärt, wer jemand ist, etwa über Passwort oder Fingerabdruck. Die Policy-Engine klärt die nächste Frage: Was darf diese Person konkret tun? Beides gehört zusammen, ist aber technisch getrennt.

Vom Regelwerk zur Entscheidung

Eine Policy-Engine arbeitet immer nach demselben Muster. Sie erhält eine Anfrage mit drei Angaben: Wer will etwas, was will er tun, und woran. Ein Beispiel: Nutzerin Meier will die Datei „Gehälter.xlsx“ öffnen. Dazu kommen oft Zusatzinformationen wie Uhrzeit, Standort oder Gerät. Diese Sammlung von Angaben nennt man den Kontext der Anfrage.

Dann geht die Engine ihr Regelwerk durch. Die Regeln sind in einer eigenen, sehr knappen Sprache geschrieben, zum Beispiel in der verbreiteten Sprache Rego. Eine Regel könnte lauten: Zugriff auf Gehaltsdaten nur für die Personalabteilung und nur aus dem Firmennetz. Passt die Anfrage auf keine erlaubende Regel, lautet die Antwort standardmäßig „verboten“. Dieses Prinzip heißt Deny by Default und gilt als Sicherheitsstandard.

Ein häufiger Irrtum: Die Policy-Engine blockiert den Zugriff nicht selbst. Sie fällt nur das Urteil und gibt es zurück. Durchsetzen muss es die Anwendung, die gefragt hat. Man kann sich das wie einen Schiedsrichter vorstellen, der pfeift, während die Spieler die Entscheidung befolgen müssen. Deshalb ist eine Policy-Engine nur so wirksam wie die Systeme, die sie tatsächlich fragen.

Von der Cloud bis zum KI-Chatbot

Am häufigsten stecken Policy-Engines in großen Cloud-Systemen, also in Rechenzentren, die Software für viele Firmen gleichzeitig betreiben. Das bekannteste Open-Source-Projekt heißt Open Policy Agent, kurz OPA. Es entscheidet dort etwa, welche Programme überhaupt starten dürfen. Auch Kreditkartenfirmen nutzen solche Engines, um verdächtige Zahlungen in Sekundenbruchteilen zu stoppen.

In den Nachrichten taucht der Begriff zunehmend im Zusammenhang mit künstlicher Intelligenz auf. Vor und hinter einem Chatbot sitzen Regelwerke, die bestimmte Anfragen und Antworten abfangen. Anleitungen zu Waffen etwa werden geblockt, medizinische Fragen mit einem Hinweis versehen. Bei KI-Systemen, die selbstständig Aufgaben erledigen, entscheidet eine Policy-Engine, welche Werkzeuge das System benutzen darf.

Für diesen Bereich wächst der Druck durch Gesetze. Die europäische KI-Verordnung verlangt von Anbietern nachweisbare Kontrollen über ihre Systeme. Eine zentrale Stelle mit lesbaren Regeln ist dafür der naheliegende Weg. Wer heute in Stellenanzeigen „Policy as Code“ liest, meint genau diesen Ansatz: Vorschriften nicht als Text im Ordner, sondern als ausführbaren Code.