Fein-granulare Autorisierung – warum der Hype?

Eine Herausforderung – viele Lösungsansätze

Wer an dieser Stelle beginnt, nach Optionen zur Umsetzung zu suchen, kann an der Vielzahl relativ neuer Ansätze schnell die Übersicht verlieren. Als vermutlich bekanntester Vertreter der neuen Schule findet sich der OPA oder Open Policy Agent (kurz: OPA) – ein Open Source Projekt mit erstaunlicher Resonanz in der Entwickler Community. OPA bringt eigene Beschreibungssprache namens REGO mit, mit der sich einheitliche und verständliche Policies für Zugriffsentscheidungen formulieren lassen. Der OPA ist eine Implementierungsoption für den PDP und lässt sich verhältnismäßig einfach in neue Softwareprojekte einbinden.

Da Softwareentwicklung heute primär für die Cloud in der Cloud stattfindet und Anbieter wie AWS ein umfangreiches Tooling für CI/CD Pipelines und deren Automation anbieten, ist es wenig überraschend, dass mit CEDAR auch eine Beschreibungssprache von AWS um Aufmerksamkeit buhlt.

Eine Reihe von weiteren Anbietern wie Aserto, Sgnl und Co. nutzen intern den OPA als generische Komponente, um darauf aufbauend umfassendere Dienste und Funktionen anbieten zu können, während andere wie PlainID eigene Implementierungen bevorzugen.

Viele Lösungsansätze – eine abstrakte Lösung

Gemein haben alle diese Ansätze, dass sie abstrakt nur lösen wollen, wie man möglichst effizient, wiederverwendbar und sicher die für eine Autorisierung notwendigen Regeln und Bedingung in Form von Policies formulieren und diese performant zur Laufzeit der Anwendung Zugriffsentscheidungen auswerten kann. Im Unterschied zur Authentisierungsschicht – wo es lediglich um die Frage „Wer ist der Benutzer?“ geht – kommen bei Zugriffsentscheidungen in den meisten Fällen drei Aspekte zur gemeinsamen Betrachtung zusammen:

• ein Subjekt (wer): Der agierende Benutzer, welcher eine Aktion ausführen möchte
• eine Aktion, die der Benutzer ausführen möchte, z.B. „bearbeiten“ oder „löschen“
• eine Ressource, auf welcher eine Aktion ausgeführt werden soll, z.B. ein Dokument oder eine Datei

Die konkrete Ausgestaltung dieser „Triplets“ ist dabei sehr stark vom jeweiligen Anwendungsumfeld abhängig, vereinfachend kann man aber mit dem bekannten „CRUD“-Schema aus (CREATE – READ – UPDATE – DELETE) als Beispiel beginnen (für eine Datei als Ressource wären auch ACTIONS wie „RENAME“ oder „PRINT“ sinnvoll).

Die Bausteine SUBJECT, RESOURCE und ACTION werden dann in Policies verwendet, um zu formulieren, welche Anforderungen erfüllt sein müssen, damit ein Zugriff gewährt oder verweigert werden soll. Eine solche Policy könnte frei formuliert beispielsweise lauten:

„Eine RESSOURCE darf nur dann gelöscht werden, wenn das SUBJECT sich per MFA angemeldet hat und entweder (a) Mitglied in der Gruppe „admin“ ODER (b) Eigentümer dieser Ressource ist.“

Listing 2 zeigt, wie solch eine Policy am Beispiel von REGO mit dem Open Policy Agent umgesetzt werden könnte:

Standardmäßig ist jeder Zugriff zu verweigern, was über die Zeile 2 als entsprechender Default-Wert definiert wird. In den nachfolgenden Zeilen werden einzelne Aspekte in Form von Teil-Policies geprüft, nämlich ob das SUBJEKT in einer bekannten Gruppe ist (Zeile 4-8), ob das SUBJEKT Eigentümer der RESSOURCE ist (Zeile 9-11) oder ob die Authentifizierung per MFA erfolgte (Zeile 12-15). Das eigentliche Herzstück der Policy bilden die Bedingungen den darauffolgenden Blöcken in den Zeilen 16-27 ab, mit denen die eigentlichen Anforderungen in ihrer Kombination formuliert und ausgewertet werden. Nur wenn alle genannten Bedingungen zutreffen, wird die Policy für „allow“ den gewünschten Wert „true“ zurückliefern.

Listing 2

Fein-granulare Autorisierung

Mit einer solchen Policy ausgestattet, kann eine Anwendung nun jegliche Autorisierungsentscheidungen an einen externen Policy Decision Point (PDP) wie den Open Policy Agent auslagern und muss dazu lediglich den jeweiligen Kontext mitliefern: wer ist das SUBJEKT, was die RESSOURCE und welche AKTION ausgeführt werden soll. Im Gegenzug muss die Anwendung einzig nur noch die Entscheidung des PDP („allow“) auswerten und entsprechend umsetzen. Das vorliegende Beispiel ist bewusst einfach gehalten und verzichtet auf fortgeschrittene Techniken wie wiederverwendbare Sub-Policies, oder die Einbindung externer Datenbanken die als Policy Information Service (PIP) bei Bedarf nach zusätzlichen Informationen über Subjekte und Ressourcen befragt werden können. Nichtsdestotrotz demonstriert es, wie mächtig der Ansatz generell ist und welche Vorteile sich daraus ergeben:

• Zugriffsregeln werden in einer universellen Beschreibungssprache formuliert und in einem zentralen Policy-Register (Policy-Store) gesammelt.
• Alle Policies können über einen gemanagten Review- und Freigabeprozess kontrolliert erstellt und freigegeben werden.
• Die Entscheidungslogik wird von der Anwendung an einen PDP delegiert, welcher neben der eigentlichen Auswertung auch gleich die Protokollierung vereinheitlicht, und für einen besseren Überblick sorgt.
• Feingranulares Zugriffsmanagement kann konsistent über die gesamte Applikationslandschaft hinweg realisiert werden; unabhängig von der Programmierumgebung der jeweiligen Anwendung existiert eine universelle Beschreibungssprache mit der sich selbst komplexe Policies geschäftsprozess- und anwendungsübergreifend formulieren lassen.

Fazit

Das Thema feingranulare Autorisierung ist für alle Unternehmen mit eigenen Projekten in der Softwareentwicklung ein relevanter Agendapunkt für den Austausch zwischen CTO, CIO und der Anwendungsentwicklung. Gerade bei agilen Entwicklungsprojekten und einem dynamischen Umfeld in der IT sollte über eine weitergehende Zentralisierung des Access Management und eine Ergänzung um Authorization Services nachgedacht werden. Für lediglich „konsumierende“ IT-Abteilungen mit vornehmlich SaaS-basierten externen Services kann FGA zwar auch interessant sein, man ist dann jedoch auf eher Attribut- und Kontext-bezogene Policy-Erweiterungen für die „JA/NEIN“ Entscheidung limitiert, da ein Eingriff in die Applikationslogik oft nicht möglich ist.