IT Security März/April

IT SECURITY | 35
Das PBAC-Modell fragt aus Sicht
der Ressourcen:
„Intranet-Einträge können von Entitäten
editiert werden, die »Editor« als Attributwert
in ihrer Jobbeschreibung haben,…“
und diese können auch noch
um Bedingungen ergänzt werden:
„wenn sie von Firmengeräten aus zugreifen.“
Hier wird die Frage gestellt,
welche Ressourcen ich habe, und
durch wen oder wie diese genutzt und
verwaltet werden.
Damit steht der Anwendungsentwickler
in viel engerer Beziehung mit den Objekten,
die in seiner Applikation zugreifbar
und veränderbar angeboten werden.
Der Entwickler kann – ganz den
Anforderungen der Spezifikation entsprechend
– einen Satz an Zugriffspolicies
für „seine Objekte“ anlegen und
stetig anpassen. Kommen neue Objekte
hinzu, werden neue Policies ergänzt.
Das kann sowohl einmal im Jahr passieren,
als auch jeden Sprint oder nahezu
im Minutentakt, falls erforderlich. In diesen
Policies kann natürlich auch der
etablierte Rollenbegriff und das bestehende
Rollenmodell weiter genutzt werden:
„Das Objekt kann gelesen werden,
wenn das Subjekt den Mitarbeiter-Typ
´Angestellter´ hat. Das Objekt
kann aktualisiert werden, wenn das
Subjekt die Rolle ´Editor´ hat.“
Dies führt zur angenehmen Situation,
dass RBAC mit PBAC-Ansätzen kombiniert
werden kann, und eine Koexistenz
mittelfristig sinnvoll erscheint.
Wo eignet sich PBAC?
Die Nutzung von PBAC erfordert eine
Anpassung der Berechtigungsverwaltung
in den Zielsystemen – folglich ist
PBAC nur dann sinnvoll umsetzbar,
wenn eigene neue Software-Entwicklungsvorhaben
anstehen, oder eine
existierende (Webanwendungs-)Software
einem Refactoring unterzogen
werden soll. Überall dort, wo eher dynamische
Entwicklung mit sich schnell
ändernden Anforderungen zu finden
sind, oder sehr große Mengen an Objekten
sich im wechselnden Zugriff
durch viele Subjekte finden, kann ein
PBAC-Ansatz hilfreich sein. PBAC kann
aber auch in eher statischen Umgebungen
eine sinnvolle Ergänzung zu
RBAC-Modellen sein, wenn moderne
Neuentwicklungen parallel zu Altsystemen
betrieben und geschützt werden
müssen. Hierbei kann der Pflegeaufwand
für die Administration der etablierten
Rollen erheblich reduziert werden,
und die Anwendungslandschaft
erhält eine zukunftsweisende, dynamische
Autorisierungsplattform.
Was ist für eine Umsetzung
notwendig?
Eine ganze Anwendungslandschaft auf
PBAC zu transformieren wäre ein Mammutaufgabe
– viele Entwickler haben
die Ideen rund um Zanzibar und PBAC
jedoch in Form von Open Source Bausteinen
adaptiert und stellen diese für
andere Entwickler frei zur Verfügung.
Genannt seien hier die Projekte „KETO“
und die überaus erfolgreiche Policy Engine
„Open Policy Agent“ (OPA) Software,
die mit Fördermitteln entstanden
ist und sich im Umfeld der hoch-dynamischen
Zugriffsverwaltung auf Kubernetes
Container einen Namen machen
konnte. Zur Umsetzung kommen sogenannte
Application Side Cars zum Einsatz,
die eingehende Zugriffsanfragen
an die zentrale Policy Decision Points
leiten, über die zentral verwaltete Policies
abgefragt werden können. Hierbei
finden sich weitgehend Analogien zu
abstrakten Web Access Management
Komponenten (PAP, PIP, PDP), die wiederum
über moderne Protokolle wie
OAuth 2.0 mit den entsprechenden
Flows eingebunden werden können.
Fazit
Komplexe Modelle wie im „Zanzibar“
Papier beschrieben sind nur für wenige
Unternehmen und Anwendungsfälle interessant.
Die Kernideen rund um dynamischere
Verwaltung von Zugriffsrechten
können jedoch in nahezu jedem auf
DevOps ausgelegten IT-Betrieb sinnvolle
Anwendung finden und lassen sich
mit modernen Open Source Komponenten
auch verhältnismäßig einfach in den
Entwicklungsprozess und die Werkzeuglandschaft
des IT-Betriebs einbinden.
Die etwas angestaubten RBAC-Ansätze
werden nicht obsolet, sondern
finden mit PBAC eine dynamische und
flexible Ergänzung, mit der moderne
Autorisierungsmodelle behutsam Einzug
in die IT finden können.
Sebastian Rohr
1) Zu finden unter https://research.google/pubs/pub48190/
2) Zu finden unter https://github.com/ory/keto
3) Zu finden unter https://www.openpolicyagent.org/
www.it-daily.net | März/April 2023