Die rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) ist ein Autorisierungsmodell innerhalb von IAM. Es definiert, wer auf welche Ressourcen in Ihrer Anwendung zugreifen kann.

RBAC befasst sich mit der zentralen Autorisierungsfrage: „Was kann dieser authentifizierte Benutzer tun?“ Dabei weisen Sie nicht jedem Benutzer eine individuelle Berechtigung zu, sondern gruppieren die Berechtigungen in Rollen. Sie können Benutzern eine oder mehrere Rollen zuweisen, die jeweils einen definierten Satz von Berechtigungen gewähren. Dieser Ansatz erleichtert die Benutzerverwaltung, stärkt die Sicherheit und lässt sich für moderne Anwendungen gut skalieren.

Das RBAC-Modell wird durch die Beziehung zwischen Benutzern, Rollen und Berechtigungen definiert.

• Benutzer: Eine authentifizierte Person oder Entität, die Zugang zu einem System sucht.
• Berechtigung (oder Privileg): Das granular definierte Recht, eine bestimmte Aktion an einer Ressource auszuführen.
  Berechtigungen drücken Sie als Aktion/Ressource-Paar aus:
  • read:Patients
  • update:Settings
  • delete:Posts
• Rolle: Eine Sammlung von Berechtigungen, die eine bestimmte Funktion oder Zugriffsebene innerhalb der Anwendung definieren (ein einzelner Benutzer kann mehrere Rollen haben).

Wie funktioniert RBAC?

RBAC kann in drei logischen Schritten durchgesetzt werden:

1. Berechtigungen definieren: Bestimmen Sie die niedrigste Ebene von Aktionen, die ein Benutzer in der Anwendung durchführen kann (z. B. create, read, update, delete für eine bestimmte Ressource).
2. Berechtigungen für Rollen zuweisen: Gruppieren Sie Berechtigungen in logischen Rollen (z. B. kann die Rolle „Admin“ alle Berechtigungen haben, während die Rolle „Viewer“ nur read-Berechtigungen hat).
3. Rollen für Benutzer zuweisen: Weisen Sie Benutzern die Rollen zu, die ihren Verantwortlichkeiten entsprechen.

Wenn ein Benutzer den Zugriff auf eine Ressource initiiert, prüft das System die dem Benutzer zugewiesenen Rollen, um festzustellen, ob diese in Summe über die erforderliche Berechtigung verfügen.

RBAC bietet ein ausgewogenes Verhältnis von Einfachheit und Sicherheit für API-gesteuerte Anwendungen.

• Vereinfachte Verwaltung: Anstatt Berechtigungen für Tausende einzelne Benutzer zu verwalten, verwalten Sie nur noch eine kleinere Anzahl von Rollen. Wenn sich die Berechtigungen einer Rolle ändern, wird der Zugriff für alle zugewiesenen Benutzer sofort aktualisiert.
• Klarheit und Überprüfbarkeit: RBAC-Rollen bieten eine für Menschen lesbare und maschinell durchsetzbare Definition von Zugriffsrechten. Damit erleichtern sie die Überprüfung und Einhaltung des Least-Privilege-Prinzips.
• Skalierbarkeit: Wenn eine Anwendung wächst, werden neue Benutzer integriert, indem ihnen bestehende Rollen zugewiesen werden, anstatt neue, komplexe Berechtigungssätze zu erstellen.

Betrachten wir eine typische Backend-API aus dem E-Commerce mit folgenden Hauptressourcen: Produkte, Bestellungen, Kunden und Analysen.

Rolle, Berechtigungen und Beispielbenutzer

Rolle	Berechtigungen	Beispielbenutzer
Administrator	(Alle Berechtigungen für alle Ressourcen)	Sarah
Inventory Manager	create:Products, read:Products, update:Products	Matteo, Priya
Support Agent	read:Orders, read:Customers	Liam
Analysten	read:Analytics	David

RBAC-Verhalten, wenn Priya (Inventory Manager) folgende Schritte durchführen möchte:

• Produktliste anzeigen: Der Zugriff wird gewährt, da die Rolle „Inventory Manager“ die Berechtigung read:Products umfasst.
• Produktbeschreibung bearbeiten: Der Zugriff wird gewährt, da die Rolle „Inventory Manager“ die Berechtigung update:Products enthält.
• Personenbezogene Daten eines Kunden aufrufen: Der Zugriff wird verweigert, da die Rolle „Inventory Manager“ nicht die Berechtigung read:Customers enthält.

Dieses Beispiel veranschaulicht, wie Berechtigungen automatisch über die Rolle so vererbt werden, dass sich eine differenzierte Zugriffskontrolle ergibt, ohne dass Benutzerberechtigungen direkt zugeordnet werden müssen.

Bei B2B-SaaS-Plattformen, auf denen mehrere Kundenorganisationen die gleiche Anwendungsinfrastruktur nutzen, wird RBAC auf Organisationsebene angewendet. Ein Benutzer kann in verschiedenen Organisationen unterschiedliche Rollen haben.

Bei der Authentifizierung eines Benutzers muss das Autorisierungssystem nicht nur die Frage „Welche Rolle hat der Benutzer?“ beantworten, sondern auch die Frage „Welche Rolle hat der Benutzer in dieser spezifischen Organisation?“. Das JWT enthält sowohl die Identität des Benutzers als auch eine Organisationskennung, um die Durchsetzung rollenbasierter Berechtigungen innerhalb der korrekten Tenant-Grenze zu gewährleisten. Dies verhindert eine Rechteausweitung über Kundenorganisationen hinweg und gewährleistet in Multi-Tenant-Architekturen eine strikte Datenisolation.

Während RBAC für die meisten Anwendungen gut funktioniert, eignen sich andere Autorisierungsmodelle für komplexere Szenarien eventuell besser.

Modell	Fokus	Use Case	Verwendung
Rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC)	Jobfunktion/-rolle des Benutzers	Unternehmensanwendung mit statischen, klar definierten Benutzergruppen (Administrator, Editor, Viewer).	Am häufigsten und ausreichend für Anwendungen, bei denen Berechtigungen vorhersehbar sind.
Attributbasierte Zugriffskontrolle (Attribute-Based Access Control, ABAC)	Benutzerattribute, Ressourcenattribute, Umgebungsattribute	Zugriff wird über dynamische Richtlinienausdrücke (z. B. if user.department == resource.department) oder kontextbezogene Faktoren (z. B. Standort, Tageszeit) bestimmt.	Bei komplexen und kontextabhängigen Autorisierungsentscheidungen.
Beziehungsbasierte Zugriffskontrolle (Relationship-Based Access Control, ReBAC)	Beziehungen zwischen Benutzern und Ressourcen	Social-Media-Plattformen (z. B. „Beitrag kann nur von seinem Eigentümer gelöst werden“) oder Multi-Tenant-Anwendungen.	Wenn die Autorisierung vom Eigentümer oder einer direkten Beziehung zwischen dem Benutzer und den Daten abhängt.

RBAC bietet eine starke Autorisierung für die meisten Anwendungen, insbesondere wenn die Benutzerberechtigungen mit definierten organisatorischen Rollen übereinstimmen. Für die Mehrheit der B2B-SaaS-Anwendungen bietet RBAC (gegebenenfalls erweitert um grundlegende Attributprüfungen) eine ausreichende Zugriffskontrolle ohne unnötige Komplexität.

Allerdings stößt RBAC an seine Grenzen, wenn Zugriffsentscheidungen einen Kontext erfordern, den Rollen allein nicht erfassen können. Wenn Sie Regeln wie „Benutzer können nur Dokumente bearbeiten, die sie selbst erstellt haben“ oder „Zugriff ist außerhalb der Geschäftszeiten eingeschränkt“ durchsetzen müssen, beinhalten diese Szenarien Beziehungen zu bestimmten Ressourcen oder Umgebungsattributen. In diesen Fällen werden ABAC- oder ReBAC-Modelle notwendig, um den Aufbau komplexer Workarounds auf Basis von RBAC zu vermeiden.

In modernen API-gesteuerten Architekturen wird RBAC mit Access Token durchgesetzt. Sichern Sie Ihre API mit Protokollen wie OAuth 2.0 und OpenID Connect (OIDC). (In OAuth 2.0 definieren Scopes Berechtigungsbereiche. Rollen übersetzen Sie je nach Implementierung des Identity-Anbieters in Scopes oder benutzerdefinierte Claims.)

1. Authentifizierung: Der Benutzer meldet sich mit einem Identity-Anbieter an.
2. Autorisierungszuordnung: Der Identity-Anbieter bestimmt die Rollen des Benutzers und die entsprechenden Berechtigungen auf Basis des definierten RBAC-Modells.
3. Token-Ausstellung: Der Identity-Anbieter generiert ein JSON Web Token (JWT) als Access Token. Die Payload des JWT enthält Claims wie Rollen, Scopes oder benutzerdefinierte Attribute, mit denen nachgelagerte APIs RBAC durchsetzen.
4. API-Durchsetzung (Authentifizierung): Wenn der Benutzer einen API-Aufruf absetzt, validiert die Backend-API das JWT. Anschließend prüft sie die Rollen-/Berechtigungs-Claims im Token, um die RBAC-Regeln durchzusetzen, bevor der Zugriff auf Ressourcen oder Aktionen gewährt wird.

Dieser Token-basierte Ansatz macht die API neutral. Die erforderlichen Autorisierungsdaten sind im Token enthalten und kryptografisch signiert.

Obwohl JWTs eine neutrale und skalierbare Möglichkeit bieten, RBAC durch die Speicherung von Rollen- und Berechtigungsdaten im Access Token durchzusetzen, sollten Sie die folgenden Sicherheitspraktiken anwenden, um Schwachstellen zu vermeiden:

• Least-Privilege-Prinzip: Weisen Sie einem Benutzer nur die minimal erforderlichen Rollen und Berechtigungen für seine Aufgaben zu.
• Gültigkeitsdauer und Widerruf von Token: JWT-Access-Token lassen sich nicht sofort widerrufen, da sie lokal validiert werden.
  • Empfehlung: Verwenden Sie kurzlebige Access Token (z. B. 15–60 Minuten) und ändern Sie Refresh Token regelmäßig.
• Serverseitige Validierung: Validieren Sie jedes JWT bei jeder Anfrage, einschließlich:
  • Integrität: Überprüfen Sie die Signatur des Tokens.
  • Ablaufdatum: Überprüfen Sie den exp-Claim.
  • Zielgruppe: Vergewissern Sie sich, dass der aud-Claim mit Ihrer Anwendung übereinstimmt.
  • Autorität: Vergewissern Sie sich, dass der iss-Claim mit dem erwarteten Aussteller übereinstimmt.
  • Schlüsselrotation: Validieren Sie das Token anhand des JSON Web Key Sets (JWKS) des Identity-Anbieters, um die Schlüsselrotation zu unterstützen und die Integrität der Signatur zu gewährleisten.
• Rollen- und Berechtigungsspeicherung: Binden Sie nur die erforderlichen Rollen- und Berechtigungs-Claims ein. Vermeiden Sie sensible personenbezogene Daten.
• Token-Speicherung: Speichern Sie sensible Token niemals im localStorage oder sessionStorage, da dies zu XSS-Angriffen (Cross-Site-Scripting) führen kann. Verwenden Sie sichere HttpOnly-Cookies oder den Backend-Session-Speicher.
• Klare Fehlerbehandlung: Wenn die API eine Anfrage empfängt, gibt sie je nach Fehlertyp einen spezifischen HTTP-Statuscode zurück:
  • 401 Unauthorized: Der Benutzer konnte seine Identität nicht nachweisen (Authentifizierungsfehler, z. B. fehlendes oder ungültiges Token).
  • 403 Forbidden: Die Identität des Benutzers ist bekannt (authentifiziert), aber seine Rollen/Berechtigungen (RBAC) verhindern den Zugriff auf die angeforderten Ressourcen oder Aktionen (Autorisierungsfehler).

Was ist der Hauptvorteil von RBAC?

RBAC vereinfacht das User Management und verbessert die Überprüfbarkeit. Sie verwalten eine kleine Anzahl von Rollen, anstatt einer großen, komplexen Matrix einzelner Benutzerberechtigungen.

Ist RBAC ein robustes Sicherheitsmodell?

Ja. RBAC ist ein robustes, grundlegendes Autorisierungsmodell für Anwendungen, bei denen Benutzerfunktionen und Berechtigungen statisch und vorhersehbar sind.

Werden bedingte Zugriffe von RBAC unterstützt?

Nein. Für bedingte Zugriffe basierend auf Faktoren wie dem Zeit-, Standort- oder Ressourcenwert verwenden Sie die attributbasierte Zugriffskontrolle (ABAC). RBAC konzentriert sich auf die dem Benutzer zugewiesene Rolle.

RBAC ist ein leistungsstarkes Modell für die Zugriffskontrolle, aber nur eine Komponente in einer umfassenden IAM-Strategie (Identity and Access Management). In unserer Reihe „Einführung in IAM“ finden Sie weitere Informationen zu Identity and Access Management (IAM).

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.