Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) ist ein Modell der Zugriffssteuerung, bei dem Berechtigungen nicht einzelnen Personen, sondern Rollen zugewiesen werden. Nutzer erhalten Zugriff, indem sie einer oder mehreren Rollen zugeordnet werden, und erben damit genau die Rechte, die diese Rollen bündeln. Die Frage lautet nicht mehr „Darf Frau Meier Preise ändern?“, sondern „Darf die Rolle Vertriebsleitung Preise ändern?“ und „Ist Frau Meier Vertriebsleiterin?“.

Das Prinzip klingt banal, ist aber der Grund, warum sich Rechteverwaltung in Unternehmen überhaupt betreiben lässt. Wer bei 200 Mitarbeitenden und 80 Berechtigungen jedem Konto einzeln Rechte gibt, verwaltet bis zu 16.000 Zuordnungen. Mit zehn Rollen sind es zehn Rechtebündel und 200 Rollenzuweisungen. Wechselt jemand die Abteilung, tauscht man die Rolle, statt Dutzende Einzelrechte zu suchen und zurückzunehmen.

Wie RBAC funktioniert

Im Kern kennt RBAC vier Bausteine: Nutzer, Rollen, Berechtigungen und Sitzungen. Eine Berechtigung beschreibt eine erlaubte Operation auf einem Objekt, etwa „Bestellung lesen“ oder „Preisliste bearbeiten“. Eine Rolle bündelt mehrere Berechtigungen unter einem fachlichen Namen. Ein Nutzer wird einer oder mehreren Rollen zugewiesen. Eine Sitzung aktiviert für die Dauer einer Anmeldung eine Teilmenge der zugewiesenen Rollen. Die Prüfung zur Laufzeit läuft entsprechend über zwei Schritte: Welche Rollen hat der Nutzer aktuell, und enthält eine dieser Rollen die geforderte Berechtigung?

Entscheidend ist die Indirektion. Berechtigungen hängen an Rollen, Rollen hängen an Nutzern. Diese Zwischenebene macht Änderungen billig und Audits möglich, weil sich die Frage „Wer darf was?“ aus zwei kleinen Tabellen beantworten lässt und nicht aus tausenden Einzeleinträgen.

Die NIST-Referenzmodelle

Die heute maßgebliche Formalisierung stammt vom US-amerikanischen National Institute of Standards and Technology. Auf Arbeiten von David Ferraiolo und Richard Kuhn aus den frühen 1990er-Jahren folgte 2000 das gemeinsame NIST-Modell, das später als ANSI-Standard INCITS 359-2004 verabschiedet wurde. Es beschreibt vier aufeinander aufbauende Stufen:

• Flat RBAC: Nutzer erhalten Rollen, Rollen erhalten Berechtigungen. Mehr braucht es für den Einstieg nicht.
• Hierarchical RBAC: Rollen können andere Rollen beerben. Eine Rolle „Teamleitung“ enthält dann automatisch alles, was „Sachbearbeitung“ darf, und ergänzt eigene Rechte.
• Constrained RBAC: Es gelten Einschränkungen, vor allem Separation of Duties. Wer Rechnungen erfassen darf, darf sie nicht zugleich freigeben.
• Symmetric RBAC: Zusätzlich lässt sich prüfen, welche Rollen eine bestimmte Berechtigung besitzen, was Rechte-Reviews erleichtert.

Für die meisten Anwendungen in der Praxis reichen Flat RBAC und eine einfache Hierarchie. Der formale Rahmen ist trotzdem nützlich, weil er die Begriffe festlegt, mit denen Auditoren und Sicherheitsverantwortliche arbeiten.

Abgrenzung zu anderen Zugriffsmodellen

RBAC ist nicht die einzige Möglichkeit, Zugriffe zu steuern. Welches Modell passt, hängt davon ab, wie fein und wie dynamisch die Entscheidungen ausfallen müssen.

In der Praxis kombinieren viele Systeme die Ansätze. Eine Anwendung vergibt grobe Rechte über Rollen und verfeinert einzelne Entscheidungen über Attribute, etwa „Vertriebsleitung darf Rabatte freigeben, aber nur bis 15 Prozent und nur für Kunden der eigenen Region“. Diese Kombination heißt häufig RBAC mit ABAC-Erweiterung.

Warum RBAC im E-Commerce und B2B relevant ist

Ein Shop-Backend ist ein Werkzeug, mit dem viele Abteilungen an denselben Daten arbeiten. Die Buchhaltung sieht Zahlungen und Rechnungen, das Marketing pflegt Inhalte und Aktionen, der Kundenservice bearbeitet Bestellungen und Retouren, die Produktpflege ändert Artikel und Preise, externe Agenturen brauchen Zugriff auf Teilbereiche. Ohne Rollenmodell gibt es nur zwei schlechte Optionen: alle sind Administratoren, oder jeder Zugriff wird einzeln freigeschaltet.

Die erste Variante ist ein Sicherheitsrisiko. Ein kompromittiertes Konto mit vollen Rechten kann Preise verändern, Kundendaten exportieren oder Zahlungsarten abschalten. Die zweite Variante ist ein Betriebsrisiko, weil sie bei jeder Personaländerung händisch nachgezogen werden muss und dabei zuverlässig Fehler entstehen. RBAC löst beides, sofern die Rollen sauber geschnitten sind.

Hinzu kommen Compliance-Anforderungen. Die DSGVO verlangt in Artikel 32 angemessene technische und organisatorische Maßnahmen, und dazu zählt die Beschränkung des Zugriffs auf personenbezogene Daten auf diejenigen, die sie brauchen. Wer nach ISO/IEC 27001 zertifiziert ist oder es werden will, muss Zugriffsrechte nachvollziehbar vergeben, regelmäßig überprüfen und bei Austritten zeitnah entziehen. Ein dokumentiertes Rollenmodell macht diese Nachweise deutlich einfacher als eine gewachsene Einzelrechtevergabe.

Typische Rollen in einem Shop-Backend

Die folgende Aufstellung zeigt, wie ein Rollenschnitt für ein mittelständisches Commerce-Backend aussehen kann. Sie ist ein Beispiel, kein Standard, und muss an die tatsächliche Organisation angepasst werden.

• Administration: Vollzugriff auf Konfiguration, Nutzerverwaltung und Integrationen. Diese Rolle sollte auf sehr wenige Personen beschränkt sein.
• Produktpflege: Artikel, Kategorien, Bilder und Attribute bearbeiten, aber keine Preise freigeben.
• Preis- und Vertragsmanagement: Preislisten und kundenspezifische Konditionen ändern.
• Kundenservice: Bestellungen einsehen und Status ändern, Retouren anlegen, aber keine Zahlungsarten verwalten.
• Buchhaltung: Zahlungen, Rechnungen und Gutschriften lesen und exportieren, ohne Artikel oder Preise zu verändern.
• Externe Agentur: Zugriff nur auf Inhalte und Kampagnen, zeitlich befristet.

Ein Beispiel aus der Praxis: Kubernetes

Ein gut dokumentiertes Beispiel für RBAC im Betrieb ist Kubernetes. Die Container-Orchestrierung steuert Zugriffe auf ihre API über Objekte der Typen Role und ClusterRole, die Berechtigungen für bestimmte Ressourcen und Verben wie get, list oder delete festlegen. Über RoleBinding und ClusterRoleBinding werden diese Rollen an Nutzer, Gruppen oder Service-Accounts gebunden. Das Modell ist rein additiv: Es gibt nur erlaubende Regeln, keine ausdrücklichen Verbote. Was nicht erlaubt ist, ist verboten.

Das Beispiel zeigt zwei allgemeingültige Punkte. Erstens trennt RBAC sauber zwischen der Definition einer Rolle und ihrer Zuweisung, sodass dieselbe Rolle für viele Nutzer wiederverwendet werden kann. Zweitens gilt das Prinzip der Standardverweigerung, das auch für Shop- und Unternehmenssoftware der richtige Ausgangspunkt ist.

RBAC in Commerce-Plattformen

Wie weit ein System Rollen und Rechte unterstützt, unterscheidet sich zwischen Plattformen erheblich. Manche liefern ein fein granulares Rollenmodell im Standard, andere beschränken sich auf wenige feste Rollen, wieder andere bieten differenzierte Rechte nur in kommerziellen Editionen an. Bei Open-Source-Frameworks, die nach dem Open-Core-Prinzip arbeiten, ist genau diese Funktion ein klassischer Kandidat für die kostenpflichtige Ebene, weil Unternehmen sie zuverlässig brauchen und dafür zahlungsbereit sind.

Ein aktuelles Beispiel liefert MedusaJS. Laut der ENTERPRISE-LICENSE.md im Repository gehören RBAC und die Anbindung per OIDC seit 2026 zu den Bausteinen, die einen kommerziellen Vertrag voraussetzen, während der übrige Kern unter MIT-Lizenz steht. Wer ein solches Framework einsetzt, sollte die Frage der Rechteverwaltung deshalb früh in die Kalkulation aufnehmen und nicht erst in der Abnahme entdecken. Die Einordnung im Zusammenhang findest du im Beitrag zu MedusaJS.

Entwurf eines Rollenmodells: Vorgehen

Ein Rollenmodell entsteht selten am Reißbrett richtig. Bewährt hat sich ein iteratives Vorgehen, das bei den tatsächlichen Aufgaben ansetzt.

1. Aufgaben statt Personen erfassen. Welche Tätigkeiten laufen im System? „Preise ändern“, „Bestellung stornieren“, „Nutzer einladen“. Erst danach werden Berechtigungen abgeleitet.
2. Berechtigungen bündeln. Aus zusammengehörigen Tätigkeiten entstehen Rollen mit fachlichem Namen. Namen nach Funktion, nicht nach Personen oder Projekten.
3. Least Privilege anwenden. Jede Rolle erhält so wenig Rechte wie möglich, aber so viele wie nötig. Im Zweifel startet man enger und erweitert auf Anfrage.
4. Kritische Kombinationen ausschließen. Für sensible Vorgänge wird Funktionstrennung festgelegt, etwa zwischen Anlage und Freigabe von Gutschriften.
5. Zuweisung dokumentieren und prüfen. Wer hat welche Rolle, seit wann und warum? Ein regelmäßiger Review, zum Beispiel vierteljährlich, verhindert Rechteschleichen.
6. An den Personalprozess koppeln. Eintritt, Wechsel und Austritt lösen definierte Rollenänderungen aus, im Idealfall automatisiert über ein zentrales Identitätssystem.

Häufige Fehler und Missverständnisse

Rollenexplosion. Das bekannteste Problem entsteht, wenn für jede Ausnahme eine neue Rolle angelegt wird. Nach zwei Jahren existieren 90 Rollen, die sich kaum unterscheiden, und niemand weiß mehr, welche wofür gilt. Gegenmittel sind wenige, klar geschnittene Basisrollen, eine Hierarchie und für echte Kontextregeln ergänzende Attribute.

Rechteschleichen. Wechseln Mitarbeitende die Aufgabe und behalten ihre alten Rollen, sammeln sich Rechte an. Nach Jahren hat eine Person Zugriff auf Bereiche, die sie nie wieder braucht. Regelmäßige Reviews und ein sauberer Wechselprozess sind hier die einzige wirksame Maßnahme.

Geteilte Admin-Konten. Ein gemeinsames Administratorkonto für das ganze Team unterläuft das Rollenmodell vollständig, weil Aktionen nicht mehr einer Person zuzuordnen sind. Ohne persönliche Konten gibt es kein sinnvolles Audit-Log.

Verwechslung mit Authentifizierung. RBAC regelt, was jemand darf, nicht, wer jemand ist. Die Identitätsprüfung ist Aufgabe der Authentifizierung, zum Beispiel per Passwort, Mehrfaktor-Verfahren oder Single Sign-On. Beides gehört zusammen, ersetzt sich aber nicht.

Rollen als Sicherheitsgarantie. Ein Rollenmodell schützt nur, wenn es an allen Stellen durchgesetzt wird. Prüft ein Backend Rechte in der Oberfläche, aber nicht in der API, lassen sich Sperren über direkte Aufrufe umgehen. Die Durchsetzung muss serverseitig erfolgen.

Technische Umsetzung

Technisch gibt es drei verbreitete Muster. Bei der Anwendungslogik prüft der Code selbst, ob ein Nutzer eine Rolle hat, meist über Annotationen oder Middleware. Bei einem zentralen Identity Provider liefert ein Token die Rollen als Claims mit, und die Anwendung wertet sie aus. Bei einem externen Policy-Dienst wie Open Policy Agent oder einer Cloud-IAM-Lösung wird die Entscheidung ausgelagert und nach einheitlichen Regeln getroffen.

Für Web-Anwendungen mit Tokens ist der zweite Weg üblich. Ein Identity Provider stellt nach der Anmeldung ein signiertes Token aus, das unter anderem die Rollen oder Gruppen des Nutzers enthält. Die Anwendung prüft die Signatur und leitet daraus Rechte ab. Wichtig ist, dass Rollen im Token nur so aktuell sind wie das Token selbst. Werden Rechte entzogen, gelten sie bis zum Ablauf des Tokens weiter, sofern keine zusätzliche Prüfung erfolgt. Kurze Gültigkeitsdauern und Widerruf sind deshalb Teil eines belastbaren Konzepts.

In Datenbanken selbst ist RBAC ebenfalls verbreitet. Systeme wie PostgreSQL kennen Rollen als zentrales Konzept, denen Rechte auf Tabellen, Schemata und Funktionen erteilt werden. Auch dort gilt: Rollen bündeln Rechte, Konten erben sie.

Ausblick

Die Entwicklung geht von statischen Rollen hin zu kontextbezogenen Entscheidungen. Zero-Trust-Ansätze verlangen, dass Zugriffe nicht allein aufgrund der Netzwerkposition oder einer einmaligen Anmeldung erlaubt werden, sondern laufend anhand von Identität, Gerätezustand und Risiko bewertet werden. RBAC bleibt dabei das Fundament, wird aber häufiger um attributbasierte Regeln ergänzt. Gleichzeitig verschiebt sich die Rechteverwaltung in Richtung Automatisierung: Rollen werden aus dem Personalsystem abgeleitet, Reviews laufen werkzeuggestützt, und ungenutzte Rechte werden automatisch identifiziert.

Für Unternehmen im Mittelstand bedeutet das vor allem eines: Die Grundlagen zählen mehr als jedes Werkzeug. Ein überschaubares Rollenmodell, persönliche Konten, Least Privilege und regelmäßige Reviews bringen den größten Sicherheitsgewinn, lange bevor komplexe Policy-Engines nötig werden.

Häufige Fragen zu RBAC

Was bedeutet RBAC?

RBAC steht für Role-Based Access Control, auf Deutsch rollenbasierte Zugriffssteuerung. Berechtigungen werden Rollen zugewiesen, Nutzer erhalten sie über ihre Rollenzugehörigkeit.

Was ist der Unterschied zwischen RBAC und ABAC?

RBAC entscheidet anhand der Rolle einer Person, ABAC anhand beliebiger Attribute von Nutzer, Objekt und Situation. RBAC ist einfacher zu verwalten, ABAC feiner und kontextabhängiger.

Wie viele Rollen sind sinnvoll?

Eine feste Zahl gibt es nicht. Als Faustregel gilt: so wenige wie möglich, so viele wie nötig. Entstehen laufend neue Sonderrollen, ist das ein Hinweis auf Rollenexplosion und darauf, dass Attribute oder eine Hierarchie besser passen.

Braucht ein kleiner Shop RBAC?

Solange nur zwei oder drei Personen im Backend arbeiten, reichen persönliche Konten mit wenigen Rechten oft aus. Spätestens wenn externe Dienstleister, mehrere Abteilungen oder Compliance-Anforderungen hinzukommen, lohnt sich ein echtes Rollenmodell.

Ist RBAC dasselbe wie Authentifizierung?

Nein. Authentifizierung klärt, wer jemand ist. RBAC klärt, was diese Person tun darf. Beide Schritte sind nötig und werden meist von unterschiedlichen Komponenten übernommen.

Weiterführende Quellen

Die Grundlagen des Modells sind beim NIST Computer Security Resource Center dokumentiert, einen allgemeinen Überblick bietet der Artikel zur rollenbasierten Zugriffskontrolle auf Wikipedia. Die Kubernetes-Umsetzung beschreibt die offizielle Dokumentation.