--- term: 'Rollenbasierte Zugriffskontrolle (RBAC)' seoTitle: 'RBAC erklärt: Rollen, NIST-Modell, Rollenexplosion, Entwurf' headline: 'Was ist rollenbasierte Zugriffskontrolle (RBAC)?' slug: rollenbasierte-zugriffskontrolle-rbac category: auth-security shortDefinition: 'Rollenbasierte Zugriffskontrolle ist ein Autorisierungsmodell, bei dem Berechtigungen an Rollen hängen und Nutzer sie nur über ihre Rollen erhalten.' relatedTerms: - access-control-lists-acl - class-level-permissions-clp - identity-access-management-iam - row-level-security contrastsWith: - access-control-lists-acl aboutTerms: - 'Role Hierarchy' - 'Separation of Duties' - 'Role Explosion' faq: - question: 'Was ist RBAC, einfach erklärt?' answer: 'Zugriff wird nach Funktion vergeben, nicht pro Person: Berechtigungen hängen an Rollen – Editor, Admin, Support – und Nutzer erben alles, was ihre zugewiesenen Rollen tragen. Einstellung, Beförderung und Austritt werden zu Rollenänderungen an einer Stelle statt zu überall verstreuten Berechtigungsänderungen.' - question: 'Was ist der Unterschied zwischen RBAC und ABAC?' answer: 'RBAC entscheidet anhand vordefinierter Rollen; attributbasierte Zugriffskontrolle (ABAC) wertet Attribute von Nutzer, Ressource und Kontext aus – Abteilung, Vertraulichkeit, Uhrzeit – und zwar zum Zeitpunkt der Anfrage. RBAC ist leichter zu durchdenken und zu prüfen; ABAC ist feingranularer und schwerer zu debuggen. Reife Systeme nehmen RBAC als Basis und ergänzen Attributbedingungen dort, wo der Kontext wirklich zählt.' - question: 'Was ist der Unterschied zwischen RBAC und einer ACL?' answer: 'Die Richtung der Zuordnung: Eine ACL hängt Subjekt-Berechtigungs-Einträge an jedes Objekt; RBAC hängt Berechtigungen systemweit an Rollen. Beide ergänzen sich, statt zu konkurrieren – ein ACL-Eintrag kann eine Rolle benennen, und genau so koexistieren Kontrolle auf Objektebene und Mitgliederverwaltung an einer Stelle.' - question: 'Welche RBAC-Modelle gibt es?' answer: 'Der Standard definiert Core RBAC (Nutzer, Rollen, Berechtigungen, Sessions), hierarchisches RBAC (übergeordnete Rollen erben die Berechtigungen untergeordneter Rollen) und eingeschränktes RBAC (Regeln zur Aufgabentrennung – statische Einschränkungen bei der Zuweisung, dynamische Einschränkungen dafür, was eine Session gemeinsam aktivieren darf).' - question: 'Was sind die drei Regeln von RBAC?' answer: 'Aus der ursprünglichen Formulierung von 1992: Ein Subjekt kann nur über eine ausgewählte Rolle handeln (Rollenzuweisung); das Subjekt muss für diese Rolle autorisiert sein (Rollenautorisierung); und eine Aktion ist nur erlaubt, wenn die aktive Rolle die passende Berechtigung hält (Berechtigungsautorisierung). Zusammengefasst: kein Zugriff außer über Rollen.' - question: 'Was ist Rollenexplosion?' answer: 'Unkontrolliertes Rollenwachstum, wenn jede Ausnahme, jedes Projekt, jede Region und jeder Tenant eine neue Rolle hervorbringt – Project-A-Manager-Region-West – bis es mehr Rollen als Nutzer gibt und niemand das System mehr prüfen kann. Die Ursache ist stets dieselbe: Kontextattribute werden als Rollen codiert, statt sie über Bedingungen oder Einträge pro Objekt zu behandeln.' - question: 'Ist RBAC dasselbe wie das Prinzip der geringsten Rechte?' answer: 'Nein – das Prinzip der geringsten Rechte ist der Grundsatz, RBAC ein Mechanismus, ihn zu verfolgen, und nur Rollendisziplin verbindet beides. Eine zu breit geschnittene Rolle verletzt den Grundsatz von innerhalb des RBAC; Rollen minimal zu schneiden und regelmäßig zu überprüfen ist das, was den Grundsatz tatsächlich einlöst.' - question: 'Was ist Aufgabentrennung in RBAC?' answer: 'Einschränkungen, die unvereinbare Befugnisse auseinanderhalten: Statische Trennung verbietet es einem Nutzer, jemals Zahlungserfasser und Zahlungsfreigeber zugleich zu sein; dynamische Trennung erlaubt beides, aber niemals in derselben Session aktiviert. Es ist Betrugsprävention, ausgedrückt als Rollenregel.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'NIST Role-Based Access Control project' url: 'https://csrc.nist.gov/projects/role-based-access-control' - name: 'Ferraiolo & Kuhn — Role-Based Access Control (1992)' url: 'https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf' - name: 'NISTIR 7316 — Assessment of Access Control Systems' url: 'https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7316.pdf' - name: 'OWASP Authorization Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html' cta: title: 'Rollen, die Sie abfragen können' text: 'Rollen sind in Back4app Datenbankobjekte: Mitglieder über eine Relation hinzufügen, Rollen für die Hierarchie verschachteln und Rechte über Klassenberechtigungen und Objekt-ACLs vergeben – RBAC, von der Plattform bei jeder Anfrage durchgesetzt.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-24' translationKey: role-based-access-control-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](https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf) 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 | Frage | Antwort | | --- | --- | | Die Indirektion | Nutzer → Rolle → Berechtigung – nie Nutzer → Berechtigung direkt | | Rolle ≠ Gruppe | Eine Gruppe bündelt *Nutzer*; eine Rolle bündelt *Berechtigungen* | | Die Modellstufen | Core · hierarchisch (Vererbung) · eingeschränkt (Aufgabentrennung) | | Der Fehlermodus | Rollenexplosion – Attribute als Rollen codiert, bis Rollen die Nutzer überzählen | | Die Komposition | Rollen in ACL-Einträgen: RBAC für die Masse, ACLs für die Ausnahmen | ## Nutzer, Rollen, Berechtigungen – die Indirektion in Aktion ```text 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:** ```javascript // 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 // 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(); ``` **Swift:** ```swift // 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() ``` **Kotlin:** ```kotlin // 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. ```mermaid flowchart LR accTitle: RBAC-Struktur mit Sessions und Aufgabentrennung accDescr: Nutzern werden Rollen zugewiesen, von denen sie pro Session eine Teilmenge aktivieren. Rollen tragen Berechtigungen und können von untergeordneten Rollen erben. Einschränkungen zur Aufgabentrennung regeln, welche Rollen gemeinsam zugewiesen oder aktiviert werden dürfen, und Berechtigungen gelten für Ressourcen. U["Nutzerin
Ada"] -->|"zugewiesen"| R["Rollen
Editor · Auditor"] U -->|"aktiviert Teilmenge
pro Session"| S["Session
nur Editor"] R -->|"erbt von"| RJ["Untergeordnete Rolle
Viewer"] R ---|"Trennungsregel:
nicht mit Approver"| X["Unvereinbare Rolle"] S -->|"Berechtigungen der
aktiven Rollen"| P["posts:write
posts:publish"] --> D[("Ressourcen")] ``` ## RBAC vs. ACL vs. ABAC | | RBAC | [ACL](/glossary/de/zugriffskontrolllisten-acl/) | ABAC | | --- | --- | --- | --- | | Berechtigungen hängen an | Rollen | Jedem Objekt | Attributregeln | | Ursprüngliche Frage | Was darf diese *Funktion*? | Wer darf *dieses Objekt* anfassen? | Ist das *im Kontext* erlaubt? | | Verwaltung | Eine Stelle pro Rolle | Pro Objekt | Pro Policy | | Teilen pro Objekt | Nicht ausdrückbar | Die Paradedisziplin | Ausdrückbar, aber umständlich | | Prüfung "was darf Ada?" | Ihre Rollen lesen | Jedes Objekt durchsuchen | Jede Regel auswerten | | Fehlermodus | Rollenexplosion | Wildwuchs an Listen | Undurchsichtige Policies | 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](/glossary/de/zugriffskontrolllisten-acl/) lösen, niemals über Rollen pro Objekt; Rollen strukturell pro [Tenant](/glossary/de/tenant-isolation/) 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](/glossary/de/datenschicht-vs-anwendungsschicht-sicherheit/) 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](/glossary/de/klassenberechtigungen-clp/) und [zeilenbasierten Richtlinien](/glossary/de/zeilenbasierte-sicherheit-rls/). ## Sollten Sie RBAC verwenden? Eine Entscheidungsmatrix | Situation | Tendenz | | --- | --- | | Zugriff folgt der beruflichen Funktion | RBAC – die Paradedisziplin | | Nutzer teilen einzelne Datensätze spontan | ACLs – Rollen können das nicht ausdrücken | | Der Kontext entscheidet (Zeit, Zustand, Tenant) | Attributbedingungen über den Rollen | | Eine Handvoll stabiler Nutzertypen | RBAC mit 3–7 breiten Rollen | | Tiefe Organigramme, verschachtelte Teams | Rollenhierarchie – oder ReBAC ab echter Größe | | "Nur Admins und alle anderen" | Ein einziges Rollentor – nicht übermodellieren | ## 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](/glossary/de/klassenberechtigungen-clp/) für die groben Linien und in [ACL-Einträgen](/glossary/de/zugriffskontrolllisten-acl/) 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.