Role-Based Access Control
Modell der Zugriffssteuerung, bei dem Berechtigungen nicht einzelnen Nutzern, sondern Rollen zugewiesen werden — Nutzer erhalten Rechte ausschließlich über ihre Rollenmitgliedschaft.
Role-Based Access Control (RBAC), auf Deutsch rollenbasierte Zugriffssteuerung, ist ein Modell der Autorisierung, bei dem Berechtigungen nicht direkt an einzelne Nutzer, sondern an Rollen vergeben werden. Nutzer erhalten Rechte ausschließlich dadurch, dass sie einer Rolle zugeordnet sind. Damit schiebt RBAC eine Abstraktionsebene zwischen Identität und Berechtigung — und macht Zugriffsrechte verwaltbar, nachvollziehbar und auditierbar. Als Autorisierungsmodell ist RBAC ein zentraler Baustein jedes Identity and Access Managements (IAM).
Rollen als Schicht zwischen Nutzern und Berechtigungen
Ohne RBAC wird jede Berechtigung einzeln an einen Nutzer geheftet. Bei wenigen Konten ist das beherrschbar, bei hunderten wird es unübersichtlich und fehleranfällig. RBAC führt eine Zwischenschicht ein: Berechtigungen werden zu Rollen gebündelt (etwa „Buchhaltung", „Helpdesk", „HR-Sachbearbeitung"), und Nutzer werden diesen Rollen zugewiesen. Ändert sich der Aufgabenbereich einer Funktion, passt man die Rolle an — nicht jeden einzelnen Account. Dieses Prinzip vereinfacht Onboarding, Offboarding und Wechsel zwischen Abteilungen erheblich, weil Zugriffsrechte an die Funktion und nicht an die Person gekoppelt sind.
Viele RBAC-Implementierungen unterstützen zusätzlich Rollenhierarchien: Eine übergeordnete Rolle erbt die Berechtigungen ihrer untergeordneten Rollen. Eine Rolle „Teamleitung Buchhaltung" kann so alle Rechte der Rolle „Buchhaltung" enthalten und zusätzliche Freigabebefugnisse ergänzen. Das reduziert Redundanz, erfordert aber sorgfältiges Design, damit die Vererbung nicht ungewollt zu überbreiten Rechten führt.
Separation of Duties und Least Privilege
RBAC ist das praktische Werkzeug, mit dem sich das Least-Privilege-Prinzip organisationsweit durchsetzen lässt. Statt pauschaler Admin-Gruppen erhält jede Rolle genau die Rechte, die ihre Funktion benötigt. Ergänzend lässt sich über RBAC die Funktionstrennung (Separation of Duties, SoD) erzwingen: Bestimmte Rollen schließen sich gegenseitig aus, damit kein einzelner Nutzer einen kritischen Prozess allein von Anfang bis Ende kontrollieren kann — etwa eine Zahlung sowohl anlegen als auch freigeben. Solche Constraints sind ein wirksames Mittel gegen Betrug und gegen den Schaden kompromittierter Konten.
RBAC im Vergleich zu ABAC, DAC und MAC
RBAC ist nicht das einzige Autorisierungsmodell. In der Praxis treten vor allem vier Ansätze auf, die sich in der Granularität und im Kontextbezug der Entscheidung unterscheiden.
| Modell | Entscheidungsgrundlage | Stärke | Typischer Einsatz |
|---|---|---|---|
| RBAC | Rollenmitgliedschaft | Verwaltbar, auditierbar, skaliert über Funktionen | Unternehmens-IT, AD-Gruppen, Cloud-IAM |
| ABAC | Attribute (Nutzer, Ressource, Kontext) | Feingranular, kontextsensitiv | Dynamische, datengetriebene Zugriffe |
| DAC | Ermessen des Eigentümers | Flexibel, dezentral | Dateifreigaben, NTFS-Berechtigungen |
| MAC | Zentrale Sicherheitsklassifikation | Erzwungene Vertraulichkeitsstufen | Behörden, militärische Systeme |
Attribute-Based Access Control (ABAC) entscheidet anhand von Attributen wie Abteilung, Standort, Tageszeit oder Geräteklassifikation und ist damit feingranularer, aber auch deutlich komplexer zu betreiben. Discretionary Access Control (DAC) überlässt die Rechtevergabe dem Eigentümer einer Ressource, während Mandatory Access Control (MAC) Zugriffe über zentral vergebene Sicherheitsklassifikationen erzwingt. In der Realität kombinieren moderne Systeme die Modelle: RBAC liefert die Grundstruktur, ABAC-artige Bedingungen wie Conditional Access verfeinern die Entscheidung kontextabhängig.
RBAC in der Praxis: AD, Entra ID und Cloud-IAM
In Windows-Umgebungen ist RBAC am sichtbarsten in Form von Sicherheitsgruppen im Active Directory: Eine Gruppe repräsentiert eine Rolle, Berechtigungen hängen an der Gruppe, Nutzer werden Mitglied. Microsoft Entra ID setzt RBAC über Verzeichnisrollen und über Privileged Identity Management (PIM) um, das Rollen nur temporär und auf Anforderung aktiviert — eine Form von Just-in-Time Access. In der Cloud folgen AWS IAM, Azure RBAC und Google Cloud IAM demselben Muster mit rollen- beziehungsweise policy-basierter Zuweisung an Ressourcen. Für besonders kritische Konten ergänzt Privileged Access Management (PAM) das Rollenmodell um Vaulting, Session-Aufzeichnung und Genehmigungsworkflows.
Grenzen: Role Sprawl und überprivilegierte Rollen
RBAC hat einen typischen Schwachpunkt, der sich in gewachsenen Umgebungen fast immer einstellt: Role Explosion beziehungsweise Role Sprawl. Weil sich für jede Sonderkonstellation eine neue Rolle anlegen lässt, entstehen mit der Zeit hunderte fast identischer Rollen, deren Unterschiede niemand mehr kennt. Das Modell, das eigentlich Übersicht schaffen sollte, wird selbst unübersichtlich. Wir finden in Assessments regelmäßig Rollen, die im Laufe der Jahre immer breiter wurden, weil bei jeder neuen Anforderung Rechte ergänzt, aber nie wieder entfernt wurden — und Nutzer, die längst überflüssige Rollen aus früheren Funktionen behalten haben. Solche überprivilegierten Rollen fallen meist erst in einem strukturierten Access Review auf, in dem Rollendefinitionen und tatsächliche Nutzung gegenübergestellt werden. Saubere Rollenmodelle erfordern deshalb nicht nur ein gutes initiales Design, sondern einen wiederkehrenden Überprüfungsprozess.
Relevanz für KMUs
RBAC ist kein Enterprise-Thema — die meisten KMUs betreiben es bereits, oft ohne es so zu nennen: über AD-Sicherheitsgruppen und Entra-ID-Rollen. Der entscheidende Unterschied liegt in der Disziplin. In der Praxis genügt es, mit einer überschaubaren Zahl klar benannter Rollen entlang der tatsächlichen Funktionen zu starten, Berechtigungen konsequent über Gruppen statt direkt an Nutzer zu vergeben und die Rollenmitgliedschaften regelmäßig zu überprüfen. Schon eine einmalige Bereinigung verwaister Rollen und doppelter Gruppen reduziert die Angriffsfläche spürbar und macht die nächste Access Review deutlich schneller.