RBAC vs. ABAC: Wann greift man in der Praxis zu welchem?
Kurzantwort
RBAC vergibt Berechtigungen über Rollen, die Benutzern zugewiesen werden — einfach nachzuvollziehen, aber anfällig für eine Rollenexplosion, je mehr Sonderfälle entstehen. ABAC wertet Richtlinien über Attribute von Benutzer, Ressource, Aktion und Umgebung aus und skaliert so auf feingranulare, kontextbewusste Entscheidungen, allerdings auf Kosten der Komplexität. Die meisten reifen Systeme kombinieren beides: Rollen für grobe Vergaben, Attribute und Richtlinien für die bedingten Details.
Zugriffskontrollmodelle entscheiden, wer was mit welcher Ressource tun darf. RBAC und ABAC sind die beiden, die Sie vergleichen sollen, und die starke Antwort lautet selten „wähle eines".
RBAC: die Rolle als Vergabeeinheit
Bei der rollenbasierten Zugriffskontrolle werden Berechtigungen zu Rollen gebündelt, und Rollen werden Benutzern zugewiesen. Eine Rolle billing-admin trägt die Berechtigungen, Rechnungen zu lesen und Rückerstattungen auszustellen; jeder in dieser Rolle erbt sie. Das ist leicht zu prüfen („wer ist in billing-admin?") und bildet Arbeitsfunktionen sauber ab.
Der Fehlermodus ist die Rollenexplosion. Jedes „aber diese Benutzergruppe braucht fast dasselbe, nur dass..." erzeugt eine neue Rolle. Ein paar Hundert Benutzer können hinter Tausenden überlappenden Rollen landen, die niemand vollständig versteht, was das Prinzip der minimalen Rechte still aushöhlt.
ABAC: Richtlinien über Attribute
Die attributbasierte Zugriffskontrolle wertet zur Anfragezeit eine Richtlinie über Attribute aus: das Subjekt (Abteilung, Freigabestufe, Beschäftigungsstatus), die Ressource (Klassifizierung, Eigentümer, Region), die Aktion und die Umgebung (Tageszeit, Gerätezustand, Quell-IP). Eine Regel wie „Lesen erlauben, wenn user.department == resource.department und device.compliant == true" drückt in einer Anweisung aus, was viele RBAC-Rollen erfordern würde.
Der Preis ist Komplexität: Sie brauchen eine vertrauenswürdige Quelle für jedes Attribut, Richtlinien werden schwerer nachzuvollziehen, und „warum wurde das verweigert?" kann undurchsichtig sein.
In der Praxis: kombinieren Sie sie
Die meisten reifen Systeme nutzen Rollen für grobe Vergaben und Attribute/Richtlinien für die bedingten Details — manchmal PBAC oder Policy-as-Code genannt (z. B. OPA/Rego, AWS-IAM-Bedingungen). RBAC beantwortet „welche Aufgabe haben Sie", ABAC beantwortet „ist es in diesem konkreten Kontext erlaubt".
Worauf Interviewer achten: Sie können Rollenexplosion und Attributvertrauen als die echten Abwägungen benennen, und Sie schlagen eine Schichtung vor, statt es als Glaubensfrage zu behandeln.
Wahrscheinliche Anschlussfragen
- Was ist die «Rollenexplosion» und wie hilft ABAC, sie zu vermeiden?
- Wie würden Sie RBAC und ABAC in einem System kombinieren?
- Wo speichern Sie die Attribute, auf die sich ABAC stützt, und wem vertrauen Sie dabei?