IT Security Januar / Februar 2024

IT SECURITY | 43
➤ eine Ressource, auf welcher die Aktion
ausgeführt werden soll, etwa
ein Dokument oder eine Datei
Diese „Triplets“ aus SUBJEKT, AKTION
und RESOURCE werden in Policies verwendet,
um die Anforderungen für gewährte
oder verweigerte Zugriffe zu
formulieren. Eine Beispiel-Policy könnte
besagen, dass „eine Ressource nur gelöscht
werden darf, wenn das Subjekt
sich per MFA angemeldet hat und entweder
Mitglied in der Gruppe „admin“
ist ODER Eigentümer der Ressource“.
Listing 2 zeigt, wie solch eine Policy am
Beispiel von REGO mit dem Open Policy
Agent umgesetzt werden könnte:
Standardmäßig wird Zugriff verweigert
(Zeile 2 als Default-Wert). In den
folgenden Zeilen werden Teil-Policies
geprüft: Ist das Subjekt in bekannter
Gruppe (Zeile 4-8), bzw. ist es Ressourceneigentümer
(Zeile 9-11) oder per
MFA authentifiziert (Zeile 12-15). Das
Herzstück der Policy sind die Bedingungen
in den darauffolgenden Blöcken
(Zeile 16-27), die die Anforderungen
kombinieren und nur bei Erfüllung
„true“ für das Policy-Ergebnis „allow“
zurückgeben.
Mit einer solchen Policy kann eine Anwendung
alle Autorisierungsentscheidungen
an einen externen PDP wie den
Open Policy Agent auslagern. Die Anwendung
muss nur den Kontext mitliefern:
Subjekt, Ressource und Aktion. Die
Entscheidung des PDP („allow“) wird
von der Anwendung ausgewertet und
umgesetzt. Das Beispiel zeigt die
Grundprinzipien, ohne fortgeschrittene
Techniken wie wiederverwendbare
Sub-Policies oder externe Datenbankintegration
als Policy Information Service
(PIP). Dennoch demonstriert es die Stärke
des Ansatzes:
LISTING 2
1 authz.check_permission
2 default allow := false
3 allowed_groups := [‟admin”, ‟member”] # required user groups
4 # check if user has required group
5 group_permitted if {
6 user_group := input.group
7 user_group in allowed_groups
8 }
9 resource_owner if {
10 input.resource.owner == input.user
11 }
12 # check if user has MFA enabled
13 mfa_enabled if {
14 input.mfa == true
15 }
16 # allow if: mfa-enabled AND user in permitted group
17 allow if {
18 mfa_enabled == true
19 input.action == ‟delete”
20 group_permitted == true
21 }
22 # OR allow if: mfa-enabled AND user is resource owner
23 allow if {
24 mfa_enabled == true
25 input.action == ‟delete”
26 resource_owner == true
27 }
➤ Zugriffsregeln werden in einer universellen
Beschreibungssprache formuliert
und im zentralen Policy-Register
gesammelt.
➤ Policies können einen gemanagten
Review- und Freigabeprozess durchlaufen.
➤ Die Entscheidungslogik wird an einen
PDP delegiert, der Auswertung
und Protokollierung vereinheitlicht.
➤ Feingranulares Zugriffsmanagement
kann konsistent über die gesamte
Applikationslandschaft realisiert
werden, dank einer universellen Beschreibungssprache,
und unabhängig
von der Programmierumgebung
der jeweiligen Anwendung.
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 interessant
sein, allerdings wird die Anwendung
hier eher auf Attribut- und Kontext-bezogene
Policy-Erweiterung für einfache
„JA/NEIN“ Entscheidungen limitiert,
da eine direkte Anpassung der Applikationslogik
häufig nicht möglich ist.
Sebastian Rohr, Roland Baum
https://www.umbrella.associates/
www.it-daily.net | Januar/Februar 2024