RBAC (Role-Based Access Control)

RBAC (Role-Based Access Control, rollenbasierte Zugriffskontrolle) regelt, wer auf welche Daten und Systeme zugreifen darf. Statt jeder Person einzeln Rechte zu geben, werden Rechte an Rollen gebunden (etwa „Datenanalyst" oder „Datenverantwortlicher"), und Nutzer bekommen eine Rolle zugewiesen. Der internationale Standard ANSI/INCITS 359 (herausgegeben 2004 vom US-Normungsinstitut NIST) beschreibt das Modell mit drei Bausteinen: Nutzer (Users), Rollen (Roles) und Rechte (Permissions).

Was ist RBAC?

Role-Based Access Control ist ein Regelwerk für Zugriffe, das eine Zwischenschicht zwischen Person und Recht einzieht: die Rolle. Ein Recht (etwa „darf Umsatzdaten lesen") hängt an einer Rolle wie data-analyst. Personen und technische Zugänge (zum Beispiel ein automatisierter Job) bekommen diese Rolle zugewiesen und erben darüber alle Rechte, die an der Rolle hängen. Meldet sich jemand an, aktiviert diese Anmelde-Sitzung (Session) einen Teil der zugewiesenen Rollen; nur die Rechte dieser aktiven Rollen wirken.

Formalisiert wurde das Modell 1992 von David F. Ferraiolo und D. Richard Kuhn (NIST); 2004 wurde es als ANSI/INCITS 359 standardisiert und 2012 überarbeitet. Der Standard beschreibt vier Kern-Elemente (Users, Roles, Permissions, Sessions) und drei Ausbaustufen: Core RBAC (Grundmodell), Hierarchical RBAC (Rollen erben Rechte von untergeordneten Rollen) und Constrained RBAC (Separation of Duties über statische oder dynamische Constraints, damit etwa eine Person nicht gleichzeitig Requester und Approver einer Freigabe sein kann).

Der Grund für diese Zwischenschicht ist Skalierbarkeit: Bei direkten Nutzer-Ressource-Zuweisungen müssten Rechte an vielen Objekten einzeln nachgezogen werden, wann immer sich das Team ändert. Rollen entkoppeln Identität von Berechtigung. Das reduziert Rechte-Drift und macht Reviews prüfbar, weil sich Fragen wie „Wer darf produktive Daten lesen?" auf eine überschaubare Zahl von Rollen beziehen.

In Datenplattformen laufen Grants typischerweise über Gruppen im Identity Provider (Entra ID, Okta, Google Workspace); die Gruppe repräsentiert dabei die Rolle. Die Gruppen-Mitgliedschaft wird über SCIM in die Plattform synchronisiert; Rechte werden per GRANT an die Gruppe erteilt, nicht an den einzelnen Nutzer. In Databricks Unity Catalog gilt das für Grants auf Metastore-, Katalog-, Schema-, Tabellen-, View-, Volume- und Function-Ebene.

Abgrenzung zu ABAC, ACL, Row-Level Security und PBAC

RBAC wird häufig mit verwandten Modellen verwechselt, weil alle Zugriffe steuern. Die Modelle unterscheiden sich aber in der Entscheidungsbasis und der Reichweite.

RBAC vs. ABAC (Attribute-Based Access Control): ABAC entscheidet zur Zugriffszeit über Attribute des Subjekts, des Objekts, der Aktion und des Umgebungskontexts. Beide Modelle koexistieren häufig; in Unity Catalog etwa greift eine ABAC-Policy nur, wenn der Nutzer über RBAC ein Basisrecht auf die Tabelle hat.

RBAC vs. ACL (Access Control List): ACL bindet Rechte direkt an Nutzer pro Ressource. RBAC schiebt eine Rollen-Ebene dazwischen, was Audits skalierbarer macht, dafür aber gröber wird als eine ACL-Zuweisung mit Einzelfall-Feinheit.

RBAC vs. Row-Level Security: Row-Level Security ist ein tabellen-lokaler Zeilenfilter, der als SQL-Funktion an der Tabelle hängt. Sie ergänzt RBAC feingranular auf Datensatz-Ebene und ist selbst kein Zugriffskontrollmodell im engeren Sinn.

RBAC vs. PBAC (Policy-Based Access Control): PBAC ist ein Oberbegriff für policy-getriebene Modelle, ABAC ist eine Ausprägung davon. RBAC bleibt rollen-zentriert.

Beispiel: Drei Rollen in Databricks Unity Catalog

Ein Datenteam definiert drei Rollen für seinen Analytics-Katalog: data-analyst mit SELECT auf freigegebene Schemas, data-engineer mit SELECT, MODIFY und CREATE TABLE auf Bronze- und Silver-Katalog, data-owner zusätzlich mit MANAGE auf ein Schema für Vergabe und Widerruf von Rechten.

Die drei Rollen sind Entra-ID-Gruppen (grp-data-analyst, grp-data-engineer, grp-data-owner), die per SCIM in den Databricks Account synchronisiert werden. Rechte werden ausschließlich an die Gruppe erteilt (GRANT SELECT ON SCHEMA analytics.sales TO grp-data-analyst``). Ein Wechsel im Team, etwa eine neue Analystin oder der Wechsel einer Engineerin ins Owner-Team, wird über die Gruppen-Mitgliedschaft im Identity Provider abgebildet; die Grants im Katalog bleiben unverändert.

Für ein Access Review beantwortet eine einzige Abfrage auf system.access.audit und die Grants-Views, welche Gruppen Rechte auf welche Objekte haben und welche Nutzer aktuell Mitglied dieser Gruppen sind. Der Review-Aufwand skaliert mit der Zahl der Rollen, nicht mit der Zahl der Nutzer oder Objekte.