ABAC – Attributbasierte Zugriffskontrolle
RBAC ist leistungsstark, hat aber eine strukturelle Grenze: Die Rolle entscheidet alles – egal zu welcher Uhrzeit, von welchem Gerät, aus welchem Land, oder ob die Daten als vertraulich klassifiziert sind. Eine Ärztin mit der Rolle „Ärztin" darf alle Patientenakten lesen – auch die einer fremden Klinik, auch um 3 Uhr morgens von einem unbekannten Laptop. Das ist unbefriedigend.
ABAC – Attribute-Based Access Control geht einen Schritt weiter: Die Zugriffsentscheidung basiert nicht auf einer Rolle, sondern auf Attributen – Eigenschaften des anfragenden Benutzers, der angeforderten Ressource und des Kontexts der Anfrage. Eine ABAC-Policy könnte lauten: „Zugriff auf Patientenakte erlaubt, wenn: Benutzer ist Ärztin UND Benutzer ist in derselben Klinik wie der Patient UND Uhrzeit ist 6–22 Uhr UND Gerät ist MDM-verwaltet." Das ist präzise Zugriffskontrolle auf Basis echter Umstände.
1) Die drei Attributkategorien
ABAC-Policies kombinieren Attribute aus drei Bereichen. Jede Kategorie liefert Informationen für die Entscheidungslogik. Je mehr relevante Attribute einfließen, desto präziser – und desto komplexer – wird die Policy.
2) ABAC Policy-Simulator
Die folgende Demo zeigt, wie eine ABAC-Policy mehrere Attributbedingungen gleichzeitig auswertet. Alle Bedingungen müssen erfüllt sein (AND-Verknüpfung). Ändere die Attribute und beobachte, wie sich die Zugangsentscheidung verändert.
3) RBAC vs. ABAC
Zusammenfassung
ABAC entscheidet Zugriffsanfragen anhand von Attributen des Subjekts, der Ressource und des Kontexts – deutlich feingranularer als RBAC. Policies können lauten: „Erlaubt wenn Rolle = Ärztin UND gleiche Klinik UND Uhrzeit 6–22 UND Gerät MDM-verwaltet." Praktischer Einsatz: Microsoft Conditional Access, AWS IAM Conditions, Open Policy Agent. Eng verwandt mit Zero Trust. Für die klassische Listenvariante: Access Control Lists.