Was ist rollenbasierte Zugriffskontrolle (RBAC)?

Rollenbasierte Zugriffskontrolle ist ein Autorisierungsmodell, bei dem Berechtigungen an Rollen hängen und Nutzer sie nur über ihre Rollen erhalten. Diese Indirektion ist der ganze Gedanke: Nichts wird jemals direkt an eine Person vergeben, also wird organisatorische Veränderung zu einer Datenänderung – eine Beförderung ist eine Rollenzuweisung, keine Ausgrabung in verstreuten Einzelrechten. 1992 von Ferraiolo und Kuhn als Alternative zu den älteren diskretionären und verbindlichen Modellen vorgeschlagen, wurde es zum Standard ANSI/INCITS 359 und zum Standardvokabular der Autorisierung in Unternehmenssoftware.

Das Wichtigste in Kürze

Nutzer, Rollen, Berechtigungen – die Indirektion in Aktion

Berechtigungen              Rollen                   Nutzer
─────────────               ─────────────            ─────────────
posts:read        ─┐
posts:write        ├──▶     Editor          ◀──────  Ada, Grace
posts:publish     ─┘
users:manage      ─┐
billing:view       ├──▶     Admin           ◀──────  Linus
posts:*           ─┘
posts:read        ────▶     Viewer          ◀──────  alle anderen

Ada veröffentlicht, weil Editor posts:publish trägt – weisen Sie ihr
eine andere Rolle zu, und alle Rechte wandern mit. Eine Änderung, nicht N.

Rollen als lebende Daten, verdrahtet mit den Objektberechtigungen:

// JavaScript / Node.js — Back4app JS SDK
// Roles as data: create a role, add members, grant through it
const roleACL = new Parse.ACL();
roleACL.setPublicReadAccess(true);
const editors = new Parse.Role('Editors', roleACL);
editors.getUsers().add(adaUser);
await editors.save();

// Grant by role, not by user — membership changes in one place
const post = new Parse.Object('Post');
const acl = new Parse.ACL(currentUser);  // owner entry
acl.setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// Flutter / Dart — Back4app Flutter SDK
// Roles as data: create a role, add members, grant through it
final roleACL = ParseACL()..setPublicReadAccess(allowed: true);
final editors = ParseObject('_Role')
  ..set('name', 'Editors')
  ..setACL(roleACL)
  ..addRelation('users', [adaUser]);
await editors.save();

// Grant by role, not by user — membership changes in one place
final post = ParseObject('Post');
final acl = ParseACL(owner: currentUser)  // owner entry
  ..setRoleWriteAccess('Editors', true);  // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// iOS / Swift — Back4app Swift SDK
// Roles as data: create a role, add members, grant through it
var editors = try ParseRole(name: "Editors")
let savedRole = try await editors.save()
try await savedRole.users.add([adaUser]).save() // membership = a relation

// Grant by role, not by user — membership changes in one place
var post = Post()
var acl = ParseACL()
acl.setReadAccess(user: currentUser, value: true)
acl.setWriteAccess(user: currentUser, value: true)   // owner entry
acl.setWriteAccess(roleName: "Editors", value: true) // RBAC meets the ACL
post.ACL = acl
try await post.save()

// Android / Kotlin — Back4app Android SDK
// Roles as data: create a role, add members, grant through it
val roleACL = ParseACL()
roleACL.publicReadAccess = true
val editors = ParseRole("Editors", roleACL)
editors.users.add(adaUser)
editors.save()

// Grant by role, not by user — membership changes in one place
val post = ParseObject("Post")
val acl = ParseACL(ParseUser.getCurrentUser()) // owner entry
acl.setRoleWriteAccess("Editors", true)        // RBAC meets the object's ACL
post.acl = acl
post.save()

Das NIST-Modell, korrekt dargestellt

Die meisten Erklärungen pressen den Standard in eine Aufzählung; die tatsächliche Struktur ist dreißig Sekunden wert. Core RBAC definiert Nutzer, Rollen, Berechtigungen – und Sessions, das vergessene Element: Ein Nutzer aktiviert pro Session nur eine Teilmenge seiner Rollen, und genau so kann ein Administrator standardmäßig mit Mitgliedsrechten arbeiten und bewusst eskalieren. Die drei Regeln der Originalarbeit halten das zusammen: nur über eine Rolle handeln, nur autorisierte Rollen halten, nur tun, was die aktive Rolle erlaubt. Hierarchisches RBAC ergänzt Vererbung – übergeordnete Rollen schließen untergeordnete ein (Manager ⊇ Mitarbeiter) und beseitigen Dopplungen. Eingeschränktes RBAC ergänzt die Aufgabentrennung: Statische Regeln verbieten unvereinbare Rollenzuweisungen von vornherein (niemals Zahlungserfasser und Zahlungsfreigeber zugleich); dynamische Regeln erlauben die Zuweisung, verbieten aber, beide in einer Session zu aktivieren. Und die schärfste Klarstellung des NIST, die regelmäßig verdreht wird: Eine Gruppe ist eine Sammlung von Nutzern; eine Rolle ist eine Sammlung von Berechtigungen – die Rolle wird dadurch definiert, was sie darf, nicht dadurch, wer in ihr ist.

RBAC vs. ACL vs. ABAC

Die Einsicht, die die Anbieterergebnisse der Suchmaschinen begraben: Diese Modelle ergänzen sich, sie konkurrieren nicht. Rollen regeln Zugriff, der der Funktion folgt; ACL-Einträge regeln Ausnahmen pro Objekt – und das Scharnier ist der Rollen-ACE, eine ACL-Zeile, die eine Rolle statt eines Nutzers benennt und so Kontrolle auf Objektebene mit Mitgliederverwaltung an einer Stelle verbindet. Attributbedingungen legen sich darüber, wo der Kontext (Zeit, Tenant, Zustand des Datensatzes) tatsächlich entscheidet. “Welches Modell?” ist meist die falsche Frage; “welche Schicht trifft welche Entscheidung?” ist der Entwurf.

Rollenexplosion – der Fehlermodus

Die charakteristische Krankheit des RBAC: Jede Ausnahme prägt eine neue Rolle, dann vervielfachen Projekte, Regionen und Tenants sie – Project-A-Manager-Region-West-ReadOnly – bis es mehr Rollen als Nutzer gibt und die Prüfantwort auf “wer darf was?” lautet: “weiß niemand”. Die Ursache ist immer dieselbe: Kontextattribute, die als Rollen codiert werden. Die Gegenmaßnahmen, der Reihe nach: Attribute aus Rollennamen heraushalten (Region und Tenant sind Bedingungen oder Scopes, keine Rollen); das Teilen pro Objekt über ACL-Einträge lösen, niemals über Rollen pro Objekt; Rollen strukturell pro Tenant abgrenzen statt über verbogene Namen; und prüfen – Rollen, die niemand hält, Berechtigungen, die keine Rolle nutzt, und Rechte, an die sich niemand erinnert, sind Drift, und Drift ist die Art, wie das Prinzip der geringsten Rechte leise stirbt. Eine brauchbare Faustregel: Wenn eine Rollenliste nicht mehr auf einen Bildschirm passt, übernimmt das Modell Arbeit, die einer anderen Schicht gehört.

Rollen entwerfen: Top-down, Bottom-up oder beides

Der Teil, den keine Ranking-Erklärung behandelt: woher Rollen kommen. Top-down leitet sie aus der Organisation und ihren Prozessen ab – das Geschäft befragen, die Funktionen benennen, minimale Berechtigungen zuweisen; genau, aber langsam. Bottom-up gewinnt sie aus bestehenden Rechten – wer hält bereits was, gruppiert, und die Rollenkandidaten fallen heraus; schnell, aber vergangene Fehler werden so zu Richtlinien geadelt. Die Praxis ist hybrid: Kandidaten gewinnen, gegen die Funktionen validieren, dann den 80/20-Test anwenden – eine Handvoll breiter Rollen für die Masse der Organisation, Ausnahmen über ACLs oder Bedingungen statt über maßgeschneiderte Rollen. Und eine Umsetzungsregel, die jede Umstrukturierung überlebt: Code sollte Berechtigungen prüfen, nicht Rollennamen – can('posts:publish'), nicht hasRole('Editor') –, damit das Neuschneiden einer Rolle eine Datenänderung bleibt und kein Refactoring, durchgesetzt serverseitig und standardmäßig verweigernd.

Typische Anwendungsfälle

• Adminbereiche und Back-Offices – Support, Moderation, Finanzen, Superadmin: Funktionen lassen sich sauber auf Rollen abbilden.
• Redaktions- und Publishing-Abläufe – Autor, Redakteur, Veröffentlicher, mit Trennung zwischen Schreiben und Freigeben.
• Teamberechtigungen in B2B-SaaS – Owner/Admin/Member/Billing pro Workspace, abgegrenzt pro Tenant.
• Regulierte Abläufe – Aufgabentrennung als durchsetzbare Rolleneinschränkung, mit der Rollenmitgliedschaft als Prüfnachweis.
• Das Rollentor auf Datenschichten – Rollen als das “Wer” in Klassenberechtigungen und zeilenbasierten Richtlinien.

Sollten Sie RBAC verwenden? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Teilen pro Objekt liegt außerhalb des Modells. “Teile dieses Dokument mit Ana” hat keine RBAC-Antwort außer einer Rolle pro Dokument – diese Entscheidung gehört zu den ACLs.
• Gleiche Rolle, gleiche Rechte. Zwei Redakteure sind ununterscheidbar; individuelle Nuancen brauchen eine weitere Schicht, keine fast identische Zweitrolle.
• Rollenentwurf ist echte Vorarbeit. Wer sie überspringt, bekommt Rollen, die weder die Organisation noch das Risikomodell abbilden – und die dann für immer kopiert werden.
• Statische Rollen übersehen dynamisches Risiko. Die Rollenmitgliedschaft sieht keine ungewöhnlichen Uhrzeiten, neuen Geräte oder sensiblen Datensatzzustände; das ist Attributgebiet.
• Drift ist der Normalzustand. Ohne regelmäßige Rezertifizierung wächst der Rollenumfang nur; die Prüfbarkeit von RBAC ist eine Möglichkeit, keine Garantie.

Rollen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Rollen sind hier Daten, nicht Code: Jede ist ein Objekt der Klasse _Role mit einer users-Relation für Mitglieder und einer roles-Relation für die Verschachtelung – und Verschachtelung ist Hierarchie zum Nulltarif, denn Mitglieder einer untergeordneten Rolle erben, was deren übergeordneten Rollen gewährt wurde. Die Rechtevergabe selbst geschieht genau dort, wohin der Abschnitt zur Komposition zeigt: Rollennamen erscheinen in Klassenberechtigungen für die groben Linien und in ACL-Einträgen pro Objekt für die Ausnahmen – die Code-Tabs zeigen beide Hälften –, und Back4app setzt das Ergebnis bei jeder REST-, GraphQL- und Live-Query-Anfrage durch. Weil Rollen abfragbare Objekte sind, werden Mitgliederverwaltung, Prüfungen und Admin-Oberflächen zu gewöhnlicher Datenbankarbeit: Vermeidung von Rollenexplosion als Gewohnheit der Datenmodellierung, nicht als Governance-Projekt.