Wie Open Policy Agent Entwickler befähigt, Autorisierungen einfach umzusetzen

Die Frage, was ein Nutzer in einer Anwendung darf, besteht oft aus komplexen Regeln und Konfigurationen, gespeichert in Datenbanken. Regelwerke werden in großen IT-Landschaften in verschiedenen Anwendungen häufig redundant implementiert, teils auch in unterschiedlichen Sprachen. Das führt fast zwangsläufig zu Inkonsistenzen und so zu potenziellen Sicherheitslücken.

Der Open Policy Agent (OPA) ist eine generische Policy-Engine zum Definieren und Durchsetzen von Regeln. Die Idee ist es, Autorisierungslogik (Policies) und die dazu notwendigen Daten zentral zu verwalten, aber dezentral auszuwerten. Durch einen „Policies as Code“-Ansatz lassen sich technologieneutrale, wiederverwendbare Policies definieren, die einfach ausgewertet und getestet werden können.

Ein konkretes Beispiel: Eine mögliche Autorisierungsanfrage an OPA besteht aus dem aktuellen Benutzer und der Funktion, die aufgerufen werden soll. In den Regeln steht, dass diese Funktion von allen Usern aufgerufen werden darf, die in einer bestimmten Gruppe sind. In
der zusätzlichen Konfiguration steht, in welchen Gruppen ein User ist. Mit den
Informationen aus der Anfrage, den Regeln und der Konfiguration kann OPA eine
Entscheidung treffen.

In gängigen Web-Frameworks beschränkt sich die Unterstützung bei der Autorisierung bislang häufig auf die Prüfung von User, Gruppen, Rollen oder Berechtigungen. OPA ist hingegen flexibel in der Ausgestaltung der Regeln. Unterstützt werden zum Beispiel auch Regeln der Art: „Diese Funktion dürfen alle Support-Mitarbeiter ausführen, allerdings nur werktags zwischen 9 und 18 Uhr.“ 

Interessant wird OPA im Zusammenspiel mit der sogenannten Relation Based Access
Control (ReBAC). Hier wird die Berechtigungsprüfung als „Graph Traversal“-Aufgabe gelöst. Ein Beispiel: Die verschiedenen Elemente (Dokumente, Ordner, Ablagen, Gruppen, Benutzer) und Beziehungen (Eigentümer, Bearbeiter, Kommentator) in einem Google Drive werden als Graph modelliert. Wenn ich nun prüfen möchte, ob ein User ein Dokument lesen darf, prüfe ich, ob es einen Pfad durch den Graph vom Dokument zum User gibt (z. B. das Dokument liegt in einem Ordner, der Ordner ist freigegeben für eine Gruppe, der User ist Teil der Gruppe). Falls ja, wird der Zugriff gestattet. Über dieses Konzept lassen sich Prüfungen auch über eine große Zahl von Elementen abbilden, die von Nutzern erstellt werden. 

In komplexen Anwendungsszenarien mit feingranularer Autorisierungslogik und datengetriebenen Berechtigungsstrukturen ist die Kombination von OPA und einem ReBAC-basierten Modell (z. B. OpenFGA) denkbar. Die Kombination ermöglicht es, die Flexibilität der Regeln in OPA mit den Skalierungsmöglichkeiten der datengetriebenen Autorisierung von ReBAC zusammenzubringen. Mit topaz gibt es auch schon Implementierungen dieser Idee.

Die zentrale Autorisierung mittels OPA ist vor allem bei verteilten Anwendungen mit unterschiedlichen Stacks interessant. Ebenso bei Software, die einmal entwickelt wird und für unterschiedliche Einsätze unterschiedliche Regeln zur Autorisierung bekommt, zum Beispiel beim Einsatz in anderen Unternehmen. Die Verbindung von OPA mit ReBAC ist ein interessanter Ansatz, insbesondere für Anwendungen mit hohen Anforderungen bezüglich Skalierbarkeit.

Dieser Artikel erschien am 03.02.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr den Newsletter hier abonnieren.