Unity Catalog RBAC: Rollenmodell mit Gruppen, Ownership und Vererbung
Die Kernaussagen auf einen Blick.
- Role-Based Access Control (RBAC) in Unity Catalog heißt: Rechte gehen an Gruppen, nicht an einzelne Nutzer. Diese Gruppen bekommen Zugriff auf Catalogs, Schemas und Tabellen.
- Bevor der erste GRANT läuft, sollten drei Dinge stehen: eine klare Catalog- und Schema-Struktur, eindeutige Gruppen aus dem Identity Provider und benannte Owner für die wichtigsten Objekte.
- Identitäten kommen über SCIM aus dem Identity Provider. Wir vergeben Rechte nur an Account-Gruppen und Service Principals, nicht an persönliche Nutzer oder Workspace-Gruppen.
- RBAC ist die Basis. Wer zusätzlich nach Spalten, Zeilen oder Tags filtern muss, ergänzt Attribute-Based Access Control (ABAC), Row Filter oder Column Masks später gezielt.
Inhaltsverzeichnis
Spätestens im Audit fällt das fehlende Modell auf
In einem Plattform-Review zeigte sich ein über Jahre gewachsener Bestand an einzeln vergebenen Berechtigungen, mehrere parallele Namenskonventionen für Gruppen, und ein Schema war weiterhin einem Benutzerkonto zugeordnet, das bereits seit Monaten deaktiviert war. Die vorgesehene Berechtigungsmatrix in Excel war zuletzt vor einem halben Jahr gepflegt worden. Im Audit musste dennoch eine aktuelle und vollständige Rollenmatrix vorgelegt werden.
In wachsenden Plattformen entsteht eine solche Situation häufig schrittweise. Unity Catalog ist eingeführt, weil eine zentrale Governance gewollt war. Die ersten Berechtigungen werden meist aufgrund konkreter kurzfristiger Anforderungen vergeben: ein Analyst braucht Zugriff, eine Pipeline läuft nicht, ein neuer Use Case kommt rein. Jede einzelne Vergabe lässt sich begründen, das Gesamtmodell wird jedoch zunehmend unübersichtlich.
Welche Rollen werden tatsächlich benötigt? Ist ein allgemeines SELECT-Recht auf den gesamten Catalog vertretbar? Welche Identität besitzt die Tabelle und welche Änderungsrechte ergeben sich daraus? Brauchen wir ABAC, oder reicht RBAC?
RBAC bildet die grundlegende Rollen- und Berechtigungsstruktur einer Datenplattform ab, sofern Identitäten, Gruppen, Catalog-Schnitt und Ownership stimmen. Der eigentliche GRANT-Befehl sollte erst nach den grundlegenden Entscheidungen zu Identitäten, Gruppen, Objektstruktur und Ownership folgen. Behandelt man ihn als erste Maßnahme, entsteht schnell ein Berechtigungsmodell, dessen effektive Zugriffe nur noch schwer nachvollziehbar sind.
Was ist RBAC im Unity Catalog?
RBAC in Unity Catalog ist ein rollenbasiertes Berechtigungsmodell, das sich an der Hierarchie von Catalog, Schema und den darunterliegenden Objekten orientiert. Die sogenannten Securables bilden die schützbaren Objekte der Plattform: Metastore, Catalog, Schema und darunter Tabellen, Views, Volumes, Models, Functions sowie External Locations, Storage Credentials und Connections. Berechtigungen wie USE_CATALOG, USE_SCHEMA, SELECT, MODIFY, EXECUTE, CREATE_TABLE, READ_VOLUME oder BROWSE werden Principals über GRANT <PRIVILEGE> ON <SECURABLE> TO <PRINCIPAL> zugewiesen und können auf darunterliegende Objekte vererbt werden, an Account-Users, Account-Groups oder Service Principals.
RBAC sitzt damit auf einer von vier Schichten der Databricks-Plattform-Sicherheit. Über RBAC liegen die accountweite Identitäts- und die Workspace-Schicht, darunter folgen die feingranularen Daten-Mechanismen wie Row Filter und Column Masks.
Drei Eigenschaften sind für das Berechtigungsmodell besonders relevant. Erstens: USE_CATALOG und USE_SCHEMA sind Voraussetzungen. Ohne diese übergeordneten Nutzungsrechte kann ein Principal nicht auf das Objekt zugreifen, selbst wenn er ein SELECT-Recht auf eine Tabelle darunter hat. Zweitens: Ownership bildet eine separate Steuerungsebene neben den regulären Privilegien. Der Owner kann das Objekt verwalten und Berechtigungen darauf vergeben, unabhängig vom Privilegien-Modell. Drittens: Workspace-Catalog-Bindings legen fest, in welchen Workspaces ein Catalog verfügbar ist. Damit lässt sich verhindern, dass produktive Catalogs in Entwicklungs-Workspaces verfügbar sind.
Wie RBAC, Ownership und attribut-basierte Policies als komplementäre Mechanismen der Unity Catalog Access Control ineinandergreifen, zeigen wir im Überblick zu Unity Catalog Zugriffskontrolle. Wo RBAC in das Gesamtbild von Catalog, Lineage und Discovery passt, ordnen wir im Dach-Artikel zu Unity Catalog ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Zuerst die Identitäten, dann die Grants
Bevor die ersten Berechtigungen vergeben werden, müssen Identitäten und Gruppen geklärt sein. Unity Catalog kennt drei Principal-Typen: Account-Users, Account-Groups und Databricks Service Principals. Identitäten und Gruppen sollten zentral im Identity Provider (IdP) verwaltet werden. Entra ID, Okta oder ein anderer SCIM-fähiger Identity Provider synchronisiert Nutzer und Gruppen über Databricks SCIM in den Databricks-Account.
Unity Catalog kennt drei Admin-Rollen: Account Admin, Workspace Admin und optional Metastore Admin. Eine klare Zuordnung dieser administrativen Rollen ist eine Voraussetzung für ein kontrolliertes Berechtigungsmodell: Account Admins verwalten Identitäten und Catalogs, Metastore Admins haben Default-Ownership auf zentrale Securables, Workspace Admins steuern den Workspace-Kontext.
Besonders wichtig ist die Entscheidung über die Gruppenstruktur. Workspace-lokale Gruppen aus älteren Setups eignen sich nicht für die zentrale Vergabe von Unity-Catalog-Berechtigungen. Privileges werden ausschließlich gegen Account-Level-Identitäten vergeben. Werden Workspace-Gruppen parallel weitergeführt, entstehen zwei getrennte Identitäts- und Berechtigungsmodelle, die sich mit der Zeit unterschiedlich entwickeln. Daraus folgt: Der Identity Provider ist die Single Source of Truth für Nutzer und Gruppen. Andernfalls entsteht parallel zum Identity Provider eine zweite Gruppenstruktur innerhalb von Databricks, die mit der Zeit auseinanderläuft.
| Voraussetzung | Konkret | Warum vor dem ersten Grant |
|---|---|---|
| SCIM-Sync | IdP-Konnektor zu Databricks aktiv (Entra ID, Okta, andere) | Unity-Catalog-Berechtigungen sollten ausschließlich an accountweite Identitäten vergeben werden |
| Account-Gruppen | Naming-Konvention, IdP als Source of Truth | Workspace-lokale Gruppen sind nicht konsistent über mehrere Workspaces hinweg nutzbar |
| Admin-Rollen | Account Admin und Metastore Admin benannt | Ohne eindeutig benannte administrative Rollen bleiben zentrale Ownership- und Delegationsprozesse ungeklärt |
| Service Principals | Pro Datenprodukt oder Job, nicht pro Person | An persönliche Konten gebundene Ownership wird bei Rollen- oder Personalwechseln schnell zum Betriebsrisiko |
Die Catalog-Struktur bestimmt die Rollen
Die benötigte Zahl von Rollen hängt wesentlich davon ab, wie Catalogs und Schemas strukturiert sind. Drei Strukturmodelle sind besonders verbreitet, jede mit eigenen Folgen für die Anzahl der Grants und die spätere Pflege.
Variante A: Aufbau nach Fachbereich. Ein Catalog pro Domäne (finance, sales, operations), Schemata pro Datenprodukt darunter. Dieses Modell folgt der bestehenden fachlichen Organisation, weil die fachliche Verantwortung schon entlang dieser Linien organisiert ist. Der Nachteil: Domänenübergreifende Anwendungsfälle benötigen Berechtigungen über mehrere Catalogs hinweg, und die Umgebungsabgrenzung muss zusätzlich über Schemas oder getrennte Workspaces umgesetzt werden.
Variante B: Aufbau nach Umgebung. Catalogs dev, test, prod, jeweils mit Domänen-Schemata. Das vereinfacht den Promotion-Prozess und ermöglicht eine klare Steuerung der Catalog-Sichtbarkeit über Workspace-Bindings: der prod-Catalog ist nur im Produktions-Workspace sichtbar. Ownership und Berechtigungen müssen jedoch für jede Umgebung separat verwaltet werden. Bei vielen Datenprodukten steigt dadurch der Verwaltungsaufwand deutlich.
Variante C: Aufbau nach Datenprodukt. Ein Catalog pro fachlichem Datenprodukt, mit Umgebungs-Schemata darunter (customer_360.dev, customer_360.prod). Dieses Modell eignet sich für Organisationen mit klar etablierten Datenprodukten und Produktverantwortung, setzt aber eine funktionierende Datenprodukt-Organisation voraus. Fehlt diese organisatorische Reife, kann schnell eine große Zahl schwer verwaltbarer Catalogs entstehen.
| Variante | Sinnvoll, wenn | Vorteil | Nachteil |
|---|---|---|---|
| Fachbereich | klare Domänen-Verantwortung, wenige Umgebungen | intuitive Owner-Linie | Querschnitt braucht Cross-Catalog-Grants |
| Umgebung | starker Promotion-Prozess dev → prod | Workspace-Binding wirkt sauber | Owner pro Umgebung pflegen |
| Datenprodukt | reife Data-Mesh-Struktur | klare Produkt-Ownership | Catalog-Inflation bei vielen Produkten |
Ist die Unity-Catalog-Struktur sauber, landen die meisten Berechtigungen auf Catalog- oder Schema-Ebene und vererben sich nach unten. Wenige, klar zugeordnete Rechte tragen die ganze Plattform. Ist die Struktur ungünstig, müssen Berechtigungen auf einzelnen Tabellen nachgezogen werden. Das macht den Betrieb aufwendig und Audit-Auswertungen mühsam.
Für ein mittelständisches Unternehmen kann daraus beispielsweise folgendes Modell entstehen: drei Fachbereiche, vier Umgebungen, rund hundert Nutzer, und daraus wird eine überschaubare Gruppen-Matrix entlang der Domänen statt 20 Rollen pro Person.
| Gruppe (IdP) | Mapping | Privilegien |
|---|---|---|
| uc_finance_read | Finance-Analysten | USE_CATALOG auf finance_prod, SELECT auf finance_prod.* |
| uc_finance_engineer | Finance-Engineers | USE_CATALOG + SELECT/MODIFY/CREATE_TABLE auf finance_dev und finance_test, nur SELECT auf finance_prod |
| uc_sales_read | Sales-Analysten | analog für sales_prod |
| uc_owner_finance_prod | Owner-Gruppe Finance Prod | Ownership auf finance_prod und produktive Schemata |
| sp_pipeline_finance | Service Principal für die Finance-Pipelines | Ownership auf erzeugte Tabellen, MODIFY für Job-Owner |
Mit wenigen standardisierten Gruppen pro Domäne bleibt die Rollenmatrix überschaubar, die sich zentral und reproduzierbar im Identity Provider verwalten lässt. Eine separat manuell gepflegte Berechtigungsliste kann dadurch weitgehend entfallen. information_schema und system.access-Tabellen zeigen, wer worauf Zugriff hat.
Vererbte Rechte und ihre Tücken
Vererbte Berechtigungen sind praktisch, solange die Struktur passt. Ein Recht muss dann nicht auf jeder Tabelle einzeln gesetzt werden, sondern kann weiter oben vergeben werden.
Schwierig wird es, wenn ein Catalog zu breit gebaut ist. Liegen dort Marketing-, Vertriebs- und HR-Daten zusammen, wird ein breites Leserecht schnell zu groß. Dann ist nicht nur der einzelne GRANT falsch, sondern oft die Catalog-Struktur.
Drei Punkte sind wichtig.
Catalog- und Schema-Zugriff
Wer eine Tabelle lesen soll, braucht auch Zugriff auf den Catalog und das Schema darüber. Fehlt dieser Zugriff, kommt eine Fehlermeldung, obwohl das Tabellenrecht selbst vorhanden ist.
Ownership bewusst setzen
Verantwortung wird nicht automatisch vererbt. Owner sollten bewusst gesetzt werden und nicht nebenbei aus der Struktur entstehen.
Delegation begrenzen
Rechte zum Weitergeben von Berechtigungen gehören nur an wenige Stellen. Sonst entstehen Zugriffsketten, die später kaum noch jemand erklären kann.
Ein einfacher Test: Soll diese Gruppe wirklich den ganzen Catalog lesen dürfen? Wenn die Antwort nicht klar ja ist, sollte man nicht nur den GRANT prüfen, sondern auch den Zuschnitt des Catalogs.
Welche Rolle verwaltet Zugriffsrechte im Unity Catalog?
Ownership wird bei Berechtigungen oft unterschätzt. Der Owner eines Objekts kann es ändern, löschen und Rechte vergeben. Deshalb sollte bei jedem Audit nicht nur geprüft werden, wer SELECT oder MODIFY hat, sondern auch: Wem gehört das Objekt?
Für produktive Objekte gelten drei einfache Regeln.
Owner ist eine Gruppe
Produktive Schemas und Tabellen sollten Gruppen gehören, nicht einzelnen Personen. Besser ist eine feste Owner-Gruppe, zum Beispiel uc_owner_finance_prod.
Pipelines laufen technisch
Tabellen, die von Pipelines erzeugt werden, sollten nicht unter persönlichen Accounts entstehen. Die Pipeline läuft mit einer technischen Identität. Die Verantwortung bleibt bestehen, wenn Personen wechseln.
Wechsel dokumentieren
Ownership-Wechsel sollten dokumentiert sein. Es muss später nachvollziehbar sein, warum ein Owner geändert wurde und wer die Verantwortung übernommen hat.
Eine saubere Ownership-Struktur erspart viele spätere Berechtigungsdiskussionen. Wenn Objekte noch persönlichen Accounts oder alten Setup-Nutzern gehören, ist meist unklar, wer wirklich verantwortlich ist. Genau solche Fälle tauchen in Plattform-Reviews besonders häufig auf.
Wann ein Catalog im Workspace unsichtbar bleibt
Workspace-Catalog-Binding legt fest, in welchen Workspaces ein Catalog überhaupt sichtbar ist. Das ist eine zusätzliche Grenze neben den normalen Berechtigungen.
Ein Nutzer kann also grundsätzlich Zugriff auf einen Catalog haben und ihn trotzdem in einem bestimmten Workspace nicht sehen. Zum Beispiel: Eine Analystengruppe hat SELECT auf finance_prod, der Catalog ist aber nicht an den dev-Workspace gebunden. Dann taucht er dort auch nicht auf.
Catalog-Binding verbindet damit zwei Ebenen: Unity Catalog regelt die Berechtigungen accountweit. Die Workspace-Struktur kann trotzdem weiter genutzt werden, um Umgebungen zusätzlich zu trennen.
Was RBAC nicht regelt
RBAC entscheidet zuerst, ob eine Gruppe oder Identität überhaupt Zugriff auf ein Objekt bekommt. Es beantwortet aber nicht jede Detailfrage innerhalb der Daten.
Ein Beispiel: Eine Tabelle wird von vier Gruppen genutzt, aber jede Gruppe soll andere Zeilen sehen oder bestimmte Spalten nur maskiert bekommen. Dann reicht RBAC allein nicht aus. Dafür braucht es Row-Level Security, Column Masks oder ABAC.
Die Reihenfolge ist wichtig: RBAC ist die erste Tür. Wenn RBAC den Zugriff nicht erlaubt, greifen die weiteren Regeln gar nicht erst. Wenn RBAC den Zugriff erlaubt, können die nachgelagerten Regeln den Zugriff nur weiter einschränken. Sie geben keinen zusätzlichen Zugriff, sondern begrenzen, was innerhalb des freigegebenen Objekts sichtbar ist.
Eine einzige Quell-Tabelle, mehrere Gruppen, mehrere verschiedene Sichten: das folgende Beispiel zeigt, wie sich RBAC, RLS, Column Mask und ABAC an der Tabelle sales.orders (Bestellungen aus Berlin, Bayern, Hamburg und Madrid) im konkreten Fall überlagern:
| Gruppe | Filter-Stack | Tatsächliche Sicht |
|---|---|---|
| uc_sales_berlin | RBAC (SELECT) + Row Filter auf Region | Nur Berlin-Zeilen |
| uc_sales_audit | RBAC (SELECT) + Column Mask auf customer_email | Alle Zeilen, customer_email maskiert |
| uc_marketing_read | RBAC ohne USE_SCHEMA | Permission Denied |
Jede Berechtigungs-Frage gehört damit auf genau eine dieser Ebenen:
| Berechtigungs-Frage | Mechanismus |
|---|---|
| Sichtbarkeit eines Catalogs für einen Principal | RBAC (USE_CATALOG) |
| Abfrage-Recht auf eine Tabelle | RBAC (SELECT) |
| Recht zum Ändern des Schemas | Ownership |
| Zeilen-Filter (z. B. nur die eigene Region) | Row-Level Security |
| Spalten-Maskierung (z. B. salary nur für HR) | Column Masking |
| Zugriff abhängig von Tag oder Attribut (z. B. pii=false) | ABAC |
| Klassische Filter-Sicht über View-Definition | Dynamic Views |
RBAC und ABAC sind keine Gegensätze. RBAC ist das Grundmodell: Welche Gruppe oder Identität darf auf welches Objekt zugreifen? ABAC ergänzt dieses Modell, wenn der Zugriff zusätzlich von Tags, Datenmerkmalen oder Kontext abhängt. Microsoft Learn beschreibt das als komplementäres Modell auf governierten Tags und zentralen Policies.
Die Reihenfolge ist wichtig. Zuerst sollten Rollen, Gruppen und Objektberechtigungen sauber stehen. Danach kann ABAC dort helfen, wo dieselbe Regel über viele Tabellen oder Spalten gelten soll, zum Beispiel bei PII, Vertraulichkeitsstufen oder Regionen.
Wie ABAC, Row-Level-Filter und Column Masks die Lücken füllen, die RBAC bewusst offen lässt, zeigen wir im Überblick zu attribut-basierter Zugriffskontrolle in Unity Catalog.
Grenzen
RBAC in Unity Catalog ist eine gute Grundlage für Objektberechtigungen. Es regelt, welche Gruppen oder Identitäten auf Catalogs, Schemas, Tabellen und Views zugreifen dürfen. Für den Betrieb reicht das allein aber nicht aus.
Übersicht wird schwieriger
Je mehr Catalogs, Schemas und Tabellen entstehen, desto schwerer wird es, Berechtigungen manuell zu prüfen. Einzelne Grants, alte Gruppen oder direkte Nutzerrechte fallen oft erst im Audit auf. Deshalb braucht es regelmäßige Auswertungen über System Tables und Audit-Logs.
Ownership kann liegen bleiben
Neue Objekte gehören oft der Identität, die sie erstellt hat. Wechselt die Person die Rolle oder verlässt das Unternehmen, entsteht schnell ein Problem. Deshalb sollten produktive Objekte Gruppen oder technischen Identitäten gehören.
Effektive Rechte bleiben unsichtbar
Ein Zugriff ergibt sich oft aus mehreren Stellen: Catalog-, Schema- und Tabellenrechten plus Gruppenmitgliedschaften und Vererbung. Eine einfache Abfrage zeigt nicht immer vollständig, wer am Ende wirklich Zugriff hat.
Manuelle Pflege skaliert nicht
Bei wenigen Catalogs lassen sich Berechtigungen noch manuell verwalten. Mit mehreren Domänen, Umgebungen und Datenprodukten wird das unzuverlässig. GRANTs sollten dann versioniert und automatisiert ausgerollt werden, zum Beispiel über Terraform.
Keine Zeilen-, Spalten- oder Tag-Regeln
RBAC entscheidet, ob eine Gruppe grundsätzlich auf ein Objekt zugreifen darf. Es regelt nicht, welche Zeilen sichtbar sind, ob Spalten maskiert werden oder ob eine Regel auf Basis von Tags greift. Dafür braucht es ABAC, Row Filter, Column Masks oder Dynamic Views.
Mehr zu den Detailmechanismen in den Artikeln zu Row Filter und Column Masks und Dynamic Views.
Die wichtigste Grenze ist damit nicht technisch, sondern betrieblich: RBAC funktioniert nur dauerhaft, wenn Berechtigungen, Owner, Gruppen und Änderungen regelmäßig geprüft werden.
Fazit
Mein Vorschlag: Erst Identitäten, Gruppen, Catalog-Struktur und Ownership als RBAC-Fundament sauber setzen, dann ABAC, Row Filter und Column Masks gezielt ergänzen.
Ein RBAC-Modell wird wichtig, sobald mehrere Fachbereiche, Domänen und produktive Datenprodukte dieselbe Plattform nutzen. Dann reicht es nicht mehr, Zugriffe einzeln zu vergeben. Es muss klar sein, welche Gruppen auf welche Catalogs und Schemas zugreifen dürfen, wer Owner ist und wie sich Berechtigungen im Audit nachweisen lassen.
Drei Anzeichen sprechen dafür, das Rollenmodell zu prüfen:
- Die Berechtigungsmatrix wird manuell gepflegt und passt nicht mehr zum tatsächlichen Stand.
- Neue Anforderungen führen immer wieder zu Sonderrechten auf einzelnen Tabellen oder Schemas.
- Fachbereiche wollen eigene Workspaces, weil das gemeinsame Berechtigungsmodell nicht mehr verständlich ist.
Ein funktionierendes Modell muss nicht neu gebaut werden, nur weil es methodisch anders aussehen könnte. Wenn diese Anzeichen aber auftreten, sollten Gruppen, Catalog-Struktur und Ownership geprüft werden.
Wer mit komplexen Policies startet, ohne das Rollenmodell zu klären, baut auf einer wackligen Basis. Auch das beste Berechtigungsmodell kann eine schlechte Catalog- oder Gruppenstruktur nicht ausgleichen. Es macht die Probleme nur sichtbarer.
Die drei genannten Anzeichen als Checkliste gegen die eigene Plattform prüfen, bevor weitere Sonderrechte vergeben werden.
FAQ
RBAC in Unity Catalog ist ein rollen-basiertes Berechtigungsmodell, das Privileges wie USE_CATALOG, SELECT oder MODIFY per GRANT an Account-Gruppen, Users oder Service Principals vergibt. Die Privileges wirken auf einer hierarchischen Objekt-Struktur (Metastore, Catalog, Schema, Tabelle/View/Volume/Model) und vererben sich nach unten.
