IT Security Januar / Februar 2024

IT SECURITY | 41
PAP
1. View record #123
2. Can Alice view
record #123?
3. Evaluate policies
Manage policies
Bild 2:
Policy Enforcement
Komponenten
(CREATIVE COMMONS
Lizenz, Wikipedia)
PEP
PDP
Lösungen wie OAuth und SAML – inklusive
kommerzieller und kostengünstiger
Open-Source-Lösungen am Markt.
Für die zentrale Autorisierung stehen
neue Technologien zur Verfügung, die
nachfolgend behandelt werden. Vom
bekannten Role Based Access Control
(RBAC) haben sich im Laufe der Zeit Varianten
wie Attribute-based (ABAC) und
Context-based Access Control (CBAC)
entwickelt, wie sie im „Conditional Access“
in Microsofts Azure Cloud zum
Einsatz kommen. Hierbei sind nicht nur
die Rollen, sondern auch Eigenschaften
und der aktive Kontext relevant (mehr
dazu später).
Um diesen Kontext und die Eigenschaften
dynamisch in Zugriffsentscheidungen
einzubeziehen, benötigen wir eine
angepasste Applikations-Architektur
und Infrastruktur. Diese lassen sich am
besten herleiten, wenn die Komponenten
nach einer bekannten Nomenklatur
benannt und deren Eigenschaften beschrieben
werden. Hierfür haben sich
die folgenden Begriffe etabliert:
6. View record #123
5. Permit, Alice can
view record #123
PIP
4. Retrieve additional
attributes
PDP – Policy Decision Point: Fällt anhand
von Regeln und Kontext-Informationen
Zugriffsentscheidungen für den
Enforcement Point
PAP – Policy Administration Point: Zentrale
Management-Komponente zur
Verwaltung von Policies und Monitoring
von Entscheidungen des PDPs
PIP – Policy Information Point: Stellt bei
Bedarf einem PDP zusätzliche (Meta-)
Daten über Benutzer und Ressourcen
zur Verfügung
In klassischen monolithischen Anwendungen
sind Benutzerkonten, Passwörter
und Berechtigungen lokal in der Anwendung
verankert, was zu Redundanzen
und ineffizienter Berechtigungsverwaltung
führt. Ein moderner Ansatz
beginnt mit der Auslagerung der Benutzerverwaltung
und der Einführung von
Single Sign-On (SSO). Hierdurch wird
der gesamte Login-Prozess an einen externen
Identity-Provider ausgelagert.
Der Anpassungsaufwand hierfür ist
meist überschaubar und lässt sich durch
externe Module im Webserver oder vorgelagerten
Reverse-Proxy verhältnismäßig
einfach umsetzen.
In der zweiten Stufe kann die Berechtigungssteuerung
derart angepasst werden,
dass Zugriffsentscheidungen anhand
benutzerbezogener Eigenschaften
getroffen werden. Durch SSO liefert
der Identity-Provider diese Benutzer-Attribute
einheitlich beim Login gleich
mit, wodurch die Zugriffssteuerung optimiert
werden kann. Die wesentlichen
Vorteile sind eine zentralisierte und einheitliche
Verwaltung relevanter Benutzereigenschaften
sowie eine effiziente
Bereitstellung per SSO.
Eine feingranulare Zugriffssteuerung ist
trotz SAML und OpenID Connect
(OIDC) damit nur eingeschränkt möglich,
denn die Fähigkeiten beider Protokolle
sind begrenzt:
SSO kann nur begrenzte Benutzerdaten
just-in-time übermitteln, da der Platz
für SAML/OIDC-Tokens durch das
HTTP-Protokoll limitiert ist und in der Praxis
wenige kB nicht überschreiten sollte.
In realen Umgebungen ist es hingegen
üblich, dass ein Benutzer zum Beispiel
in vielen Gruppen Mitglied ist.
SSO behandelt nur Identitätsdaten; die
Entscheidung über Benutzeraktionen
und -berechtigungen liegt weiterhin in
der Anwendung. Mit SSO wird nur die
Authentisierung ausgelagert, nicht jedoch
die Autorisierung, die oft durch
Programmlogik innerhalb der Anwendung
erfolgt (wie exemplarisch in Listing
1 dargestellt).
PEP – Policy Enforcement Point: Die
Komponente, welche eine Zugriffsentscheidung
schlussendlich umsetzt. In
der Regel ist dies eine Anwendung.
LISTING 1
def perform_create(self, request, instance):
group = request.user.group
if group == ‟member” or group == ‟admin”:
instance.save()
else:
return HttpResponse(‟Unauthorized”, status=401)
www.it-daily.net | Januar/Februar 2024