RBAC vs. ABAC vs. PBAC: Ein ehrlicher Vergleich für Teams, die einfachen Rollen entwachsen sind
RBAC scheitert bei Skalierung. ABAC ist leistungsstark, aber schwer zu debuggen. PBAC ist das Modell, auf das die meisten realen Programme hinauslaufen. Ein ehrlicher Überblick über alle drei - mit Entscheidungsleitfaden.
10 Min. Lesezeit · Zuletzt aktualisiert Juli 2026
Die meisten Gespräche über Zugriffskontrolle beginnen mit RBAC, weil es das am einfachsten zu erklärende Modell ist. Eine Rolle zuweisen, Berechtigungen bündeln, fertig. Doch irgendwo zwischen 50 und 500 Mitarbeitenden verwandelt sich diese Einfachheit still und leise in eine Schwachstelle - und das Team, das die Rollenstruktur aufgebaut hat, bemerkt es als letztes.
Dieser Beitrag räumt mit dem Marketing rund um alle drei wichtigen Zugriffsmodelle auf - RBAC, ABAC und PBAC -, definiert jedes klar, zeigt, wo jedes versagt, und liefert einen praxistauglichen Entscheidungsleitfaden. Kein Vendor-Spin. Nur die echten Abwägungen.
RBAC: Einfach - bis es das nicht mehr ist
Role-Based Access Control vergibt Berechtigungen, indem User vordefinierten Rollen zugewiesen werden. Eine Rolle ist ein benanntes Bündel von Berechtigungen: Finance Manager darf Spesenberichte genehmigen und QuickBooks einsehen. Emma und David diese Rolle zuweisen - und beide erhalten sofort denselben Zugriff.
Der Reiz liegt auf der Hand. RBAC ist einfach zu verwalten, einfach zu auditieren und bildet Organigramme auf natürliche Weise ab. Wechselt jemand das Team, tauscht man die Rolle. Muss eine gefährliche Berechtigung entzogen werden, aktualisiert man die Rolle einmal - und alle Mitglieder sind sofort betroffen.
Ein konkretes Beispiel: Ein SaaS-Unternehmen mit 80 Mitarbeitenden definiert die Rollen Engineer, Product, Finance, Support und Admin. Jede entspricht einem Satz von App-Berechtigungen. Das Onboarding dauert Minuten. Access-Reviews sind unkompliziert. Das funktioniert.
Wo RBAC versagt: Role Explosion
Das klassische statische RBAC-Modell skaliert nicht. Es funktioniert gut bei einigen Dutzend Rollen, aber mit wachsender Anzahl verbundener Systeme wächst auch die Anzahl der Rollen.
Die Mathematik ist brutal. In einem echten Unternehmen: 50 Jobfunktionen × 20 Standorte × 10 Projekte = 10.000 Rollen. 10.000 Rollen wie Sales-Tokyo-ProjA und Sales-Osaka-ProjB zu verwalten ist keine Governance - das ist Chaos mit einer Tabellenkalkulation.
Eine Organisation mit tausend Mitarbeitenden kann leicht auf einige tausend Rollen kommen. Das schwierige Problem, tausend Mitarbeitende zu verwalten, verwandelt sich in das noch schwierigere Problem, einige tausend Rollen zu verwalten.
Massiver Role Explosion macht Audits langsam und fehleranfällig. Das Least-Privilege-Prinzip lässt sich nicht mehr durchsetzen. Security-Teams verlieren das Vertrauen in die Berechtigungsdaten. An diesem Punkt geraten viele RBAC-Systeme in eine Wartungs-Todesspirale - jedes neue Projekt braucht eine maßgeschneiderte Rolle, und jeder Review-Zyklus erzeugt mehr Verwirrung als Klarheit.
RBAC wurde als statisches Modell konzipiert und bildet keine Richtlinien / Policies ab, die von kontextuellen Details wie Tageszeit, Standort oder der Beziehung zwischen Usern und Ressourcen abhängen. Das ist kein Fehler in RBAC - es ist eine Designgrenze. Das Problem entsteht, wenn Teams versuchen, diese Grenze zu überdehnen, indem sie immer engere Rollen erstellen, anstatt das Modell zu wechseln.
Untersuchungen zeigen, dass die meisten Organisationen aufgrund mangelnder Governance-Disziplin einen unnötigen Rollenüberschuss von typischerweise 40-60 % mit sich tragen.
ABAC: Leistungsstark - aber den Komplexitätspreis respektieren
Attribute-Based Access Control trifft Zugriffsentscheidungen, indem Attribute - des Users, der Ressource und der Umgebung - gegen einen Satz von Richtlinien / Policies ausgewertet werden. Statt "Emma hat die Rolle Finance Manager" fragt die Entscheidungsmaschine: Gehört der User zur Abteilung Finance? Ist das Dokument als Vertraulich klassifiziert? Liegt die Anfrage innerhalb der Geschäftszeiten? Ist das Gerät konform?
ABAC berücksichtigt mehrere Faktoren: User-Attribute (Abteilung, Freigabestufe), Umgebungsattribute (Tageszeit, Standort), Geräteattribute (Gerätezustand, Patch-Status) und Ressourcenattribute (Datensensitivität, Datenvolumen).
Ein konkretes Beispiel: Ein Gesundheitssystem nutzt ABAC, um einem Arzt den Zugriff auf Patientenakten nur dann zu erlauben, wenn: die Abteilung mit dem Behandlungsteam des Patienten übereinstimmt, der Zugriff während der Schicht erfolgt und das Gerät eine Posture-Prüfung besteht. Keine Rolle könnte alle drei Bedingungen gleichzeitig abbilden, ohne in Dutzende von Varianten zu explodieren.
Im Gegensatz zu RBAC, das durch die Notwendigkeit, zahlreiche Rollen für verschiedene Szenarien zu erstellen, unter "Role Explosion" leiden kann, reduziert ABAC die Komplexität durch den Einsatz von Attributen - was zu weniger Rollen und besser handhabbaren Richtlinien / Policies führt.
Wo ABAC versagt: Debuggbarkeit und Datenqualität
ABAC-Richtlinien können aufgrund der Anzahl von Attributen, Bedingungen und logischen Kombinationen schnell komplex werden. Dies kann zu Policy-Konflikten, unbeabsichtigten Zugriffsgewährungen oder -verweigerungen und Schwierigkeiten beim Verstehen des Policy-Verhaltens führen.
Das Debuggen von Zugriffskontrollentscheidungen in ABAC kann eine Herausforderung sein, insbesondere bei der Analyse dynamischer Attribute. Ohne die richtigen Tools kann es schwierig sein, genau zu bestimmen, warum eine Anfrage erlaubt oder abgelehnt wurde.
Das Datenqualitätsproblem ist ebenso ernst. ABAC-Entscheidungen hängen von sauberen Daten ab - ein fehlendes oder veraltetes Attribut bricht den Zugriff. Hat HR die Abteilung eines Users nicht aktualisiert oder fehlt einem Dokument sein Klassifizierungs-Tag, trifft das System die falsche Entscheidung.
Verschiedene Teams erfinden Attribute im laufenden Betrieb: Ein Service taggt dept=finance, ein anderer schreibt team=fin, ein weiterer verwendet department=FIN. Jetzt passen die Richtlinien / Policies nicht mehr zusammen.
Die Schwierigkeit, eine getroffene Entscheidung zu erklären, ist eine echte operative Herausforderung. Die Attribute selbst können sensibel sein und rechtliche sowie Compliance-Risiken erzeugen.
ABAC ist genuinen leistungsstark. Es erfordert jedoch eine ausgereifte Attributverwaltungsinfrastruktur, saubere Identitätsdaten und Werkzeuge, die Policy-Ergebnisse simulieren und erklären können. Teams, die diesen Aufwand unterschätzen, landen bei einem System, das schwerer zu auditieren ist als das RBAC-Chaos, dem sie entkommen wollten.
PBAC: Die pragmatische Synthese
Policy-Based Access Control ist das Modell, auf das die meisten ernsthaften Enterprise-Programme hinauslaufen - nicht weil es ein drittes eigenständiges Modell ist, sondern weil es die pragmatische Synthese der anderen beiden darstellt.
PBAC repräsentiert ein Autorisierungsmodell der nächsten Generation, das Entscheidungslogik vom Anwendungscode trennt. Anstatt sich ausschließlich auf fest kodierte Rollen oder Attribute zu stützen, verwendet PBAC zentralisierte Richtlinien / Policies, die Kontext, Ressourcenattribute, User-Attribute und Umgebungsbedingungen auswerten, um zur Laufzeit dynamische Zugriffsentscheidungen zu treffen.
PBAC übernimmt die zentrale Kontrolle durch explizite, auditierbare Richtlinien / Policies, die Rollen, Attribute und direkte Berechtigungen kombinieren. Das Schlüsselwort ist zentralisiert. Statt Zugriffslogik, die über Dutzende von Apps verstreut ist, definiert PBAC sie einmal in einer Policy-Engine und setzt sie überall durch.
Ein konkretes Beispiel: Ein Fintech-Unternehmen definiert eine PBAC-Policy: "User mit der Rolle Payments dürfen Überweisungen bis zu 10.000 € während der Geschäftszeiten von einem verwalteten Gerät initiieren. Überweisungen oberhalb dieses Schwellenwerts erfordern einen zweiten Genehmiger aus der Rolle Finance Lead." Diese einzelne Policy kodiert Rollenzugehörigkeit, ein Ressourcenattribut (Betrag), eine Umgebungsbedingung (Zeit, Gerät) und eine Workflow-Regel - alles in einer einzigen auditierbaren Aussage.
PBAC stärkt die Unternehmenssicherheit, indem es Geschäftslogik in durchsetzbare Zugriffsrichtlinien übersetzt. Es arbeitet harmonisch mit Identity Governance and Administration (IGA)-Systemen zusammen und entwickelt diese weiter, um eine vollständigere Sicht darauf zu bieten, was User sehen, aufrufen oder tun dürfen.
PBAC unterstützt auch das Least-Privilege-Prinzip - es werden nur die notwendigen Berechtigungen vergeben, was die Chance auf unbefugten Zugriff reduziert. Und entscheidend: Wenn sich Vorschriften weiterentwickeln, werden einfach die Richtlinien / Policies aktualisiert, anstatt gesamte Rollenhierarchien neu zu konfigurieren.
PBAC ersetzt weder RBAC noch ABAC; es kombiniert sie - verwendet Rollen als einen von vielen Eingaben, schichtet Attribute und Kontext darüber und drückt das Ergebnis als menschenlesbare Policy aus, die Compliance-Teams tatsächlich prüfen können.
Die Vergleichstabelle
| Dimension | RBAC | ABAC | PBAC |
|---|---|---|---|
| How access is decided | User's assigned role(s) | Attributes of user, resource, and environment | Centralized policies combining roles, attributes, and context |
| Strengths | Simple, auditable, easy to onboard | Fine-grained, context-aware, fewer roles needed | Auditable, flexible, maps to business logic, composable |
| Weaknesses | Role explosion at scale, no context awareness | Complex to debug, data-quality dependent, high setup cost | Requires policy governance discipline; initial design effort |
| Best fit | Stable orgs, clear job functions, <200 roles | Healthcare, government, multi-tenant SaaS, data classification | Compliance-driven orgs, SaaS-heavy stacks, hybrid environments |
| Auditability | High — roles are explicit and traceable | Low to medium — dynamic decisions are hard to explain | High — policies are human-readable and centrally logged |
| Least privilege support | Coarse — roles often over-provision | Strong — decisions are contextually precise | Strong — policies enforce minimum necessary access |
| IGA integration | Native — most IGA tools are built on RBAC | Possible but requires attribute pipeline | Native — modern IGA platforms are policy-driven by design |
Die meisten realen Programme sind hybrid - und das ist in Ordnung
Die klarste Erkenntnis von Praktikern, die Access Governance in großem Maßstab betrieben haben: Der Übergang von RBAC zu ABAC zu PBAC bedeutet nicht, frühere Modelle aufzugeben - es geht darum, Ausdrucksstärke hinzuzufügen, um zunehmend komplexe Zugriffsanforderungen zu bewältigen, ohne Role Explosion zu erzeugen.
RBAC ist eine hervorragende Grundlage für hybride oder fortgeschrittene Zugriffsmodelle. Viele Organisationen setzen RBAC ein, um grundlegende Zugänglichkeit sicherzustellen, und fügen anschließend kontextuelle Kontrollen durch PBAC oder ABAC für risikoreiche Aktionen hinzu.
Ein praktisches hybrides Modell sieht so aus: RBAC behandelt die 80 %-Fälle - Standard-Jobfunktionszugriff, App-Provisionierung, Onboarding. ABAC- oder PBAC-Schichten behandeln die 20 %, die Kontext benötigen - erhöhte Privilegien, Zugriff auf sensible Daten, teamübergreifende Zusammenarbeit, zeitbasierter Zugriff für Auftragnehmer. PBAC ermöglicht es, zeitlich begrenzten, aufgabenspezifischen Zugriff zu gewähren, der automatisch abläuft, und reduziert so die Gefahr von verbleibenden Konten oder Privilege-Missbrauch.
Hier wird IGA auch zum verbindenden Gewebe. KI-gestütztes Role Mining kann RBAC- und ABAC-Postures kontinuierlich aktualisieren, indem HR-Daten, Berechtigungen und Verhaltensmuster kombiniert werden - Role Sprawl wird verhindert und das Least-Privilege-Prinzip ermöglicht. Ohne eine IGA-Schicht, die Lifecycle-Ereignisse (Joiner, Mover, Leaver) durchsetzt, driftet selbst das am besten konzipierte PBAC-Modell. Zugriffe häufen sich an. Richtlinien / Policies veralten. Das Modell, das für Least Privilege konzipiert wurde, beginnt mehr zu gewähren als es sollte.
Genau deshalb gehören Access-Modell-Design und die Durchsetzung von Segregation of Duties in dasselbe Gespräch. SoD-Regeln - die verhindern, dass eine Person widersprüchliche Berechtigungen hält - lassen sich am zuverlässigsten als PBAC-Policies ausdrücken, nicht als Rollenbeschränkungen. Eine Rolle kann sagen, was jemand ist; eine Policy kann sagen, welche Kombinationen verboten sind, unabhängig davon, wie diese Berechtigungen vergeben wurden.
Für einen tieferen Einblick, warum die zugrunde liegende Plattformarchitektur genauso wichtig ist wie das gewählte Modell, lesen Sie unseren Vergleich Modern IGA vs. Legacy IGA.
Das Role-Explosion-Problem ist ein IGA-Problem
Es lohnt sich, direkt zu sein: Role Explosion ist nicht nur ein RBAC-Designversagen. Es ist ein Governance-Versagen. Überlappende Verantwortlichkeiten erzeugen doppelte Rollen. Fehlende Lifecycle-Management-Disziplin lässt veraltete Rollen jahrelang bestehen. Granulare Berechtigungen werden direkt neuen Rollen zugewiesen, ohne eine Standardvorlage wiederzuverwenden. Legacy-Rollen werden nie überarbeitet.
Die meisten Organisationen stellen fest, dass sie 40-60 % mehr Rollen pflegen als erforderlich - viele davon sind temporäre Rollen, die dauerhaft wurden, oder wurden durch Kopieren von User-Rechten ohne Prüfung der tatsächlichen Zugriffsanforderungen erstellt.
Die Lösung besteht nicht immer darin, RBAC herauszureißen und durch ABAC zu ersetzen. Oft geht es darum, Lifecycle-Disziplin durchzusetzen - veraltete Rollen zu deprovisionieren, regelmäßige Access-Reviews durchzuführen und Role Mining einzusetzen, um Konsolidierungsmöglichkeiten zu identifizieren. Das ist eine IGA-Funktion, keine Modellwechsel-Übung.
Wo PBAC seinen Wert beweist, ist die Ausdrucksstärke der Absicht hinter Zugriffsentscheidungen auf eine Weise, die organisatorische Veränderungen überlebt. Wenn eine Policy besagt: "Auftragnehmer in der EU dürfen während ihrer Vertragslaufzeit nur von verwalteten Geräten auf Kundendaten zugreifen", bleibt diese Policy gültig, auch wenn sich das Organigramm verschiebt, neue Apps hinzukommen und der Auftragnehmer-Pool wechselt. Eine Rolle namens EU-Contractor-CustomerData-ManagedDevice übersteht dieselben Veränderungen nicht so elegant.
Entscheidungsleitfaden: Welches Modell passt zu Ihrer Situation?
Für eine schnelle Orientierung:
Wählen Sie RBAC, wenn:
- Sie weniger als 200 Rollen und stabile Jobfunktionen haben
- Ihre Apps gut strukturiert und rollenkompatibel sind
- Ihr primäres Ziel schnelles Onboarding und einfache Access-Reviews sind
- Sie am Anfang Ihrer Governance-Reise stehen und eine Grundlage benötigen
Wählen Sie ABAC, wenn:
- Zugriffsentscheidungen tatsächlich von Ressourcenklassifizierung, Gerätestatus oder Echtzeit-Kontext abhängen
- Sie über ausgereifte, saubere Attributdaten aus einer zuverlässigen Quelle der Wahrheit verfügen
- Sie im Gesundheitswesen, im öffentlichen Sektor oder in einer mandantenfähigen SaaS-Umgebung tätig sind
- Sie über Werkzeuge verfügen, um Policy-Entscheidungen zu simulieren und zu erklären
Wählen Sie PBAC (oder hybrides RBAC + PBAC), wenn:
- Sie Compliance-getrieben sind und menschenlesbare, auditierbare Richtlinien / Policies benötigen
- Sie SoD-Regeln durchsetzen müssen, die mehrere Apps und Berechtigungstypen umfassen
- Ihr Stack Apps ohne SCIM oder native Rollenunterstützung enthält
- Sie möchten, dass Zugriffsentscheidungen organisatorische Veränderungen ohne manuelles Rollen-Refactoring überstehen
- Sie auf Zero Trust hinarbeiten und eine kontinuierliche, kontextbewusste Auswertung benötigen
Das Fazit
RBAC ist nicht kaputt - es ist nur begrenzt. Es funktioniert gut, wenn Ihre Organisation klein ist, Ihre Rollenanzahl überschaubar ist und Ihre Zugriffsentscheidungen statisch sind. In dem Moment, in dem Sie Kontext, feingranulare Zugriffskontrolle oder appübergreifende SoD-Durchsetzung benötigen, haben Sie diese Grenze erreicht.
ABAC löst das Kontextproblem, führt aber einen Komplexitäts- und Datenqualitätspreis ein, den viele Teams unterschätzen. Es ist das richtige Werkzeug für spezifische, hochriskante Szenarien - kein universeller Ersatz.
PBAC ist das Modell, auf das governance-reife Organisationen hinauslaufen: zentralisierte, auditierbare, kombinierbare Richtlinien / Policies, die Geschäftsabsichten statt technischer Rollenzuweisungen ausdrücken. Kombiniert mit einer modernen IGA-Plattform, die Lifecycle-Ereignisse durchsetzt und Policy-Drift aufzeigt, ist es das Nächste, was in der Praxis nachhaltiger Least-Privilege-Umsetzung entspricht.
Das Zugriffsmodell, das Sie wählen, ist nur so gut wie die Governance-Schicht, die es durchsetzt. Feingranulare Richtlinien / Policies bedeuten nichts, wenn veraltete Berechtigungen unkontrolliert anwachsen, wenn das Offboarding manuell ist oder wenn Ihre Long-Tail-SaaS-Apps vollständig außerhalb des Governance-Perimeters liegen.
Das ist die Lücke, die Iden schließt - richtliniengesteuerte, feingranulare Access Governance über Ihren gesamten Stack, einschließlich der Apps, die jedes andere Tool unverwaltet lässt.