Unity Catalog Access Control: RBAC, ABAC und RLS als Drei-Schicht-Modell
Die Kernaussagen auf einen Blick.
- Access Control in Unity Catalog besteht aus mehreren Bausteinen: RBAC steuert Grundrechte über Gruppen und Privilegien, ABAC ergänzt Regeln über Tags und Policies, Row-Level Security, Column Masking, Dynamic Views, Ownership und Audit über System Tables.
- RBAC eignet sich für stabile Zugriffe auf Catalogs, Schemas und Datenprodukte. ABAC hilft bei wiederkehrenden Schutzregeln für Klassifikationen wie PII, Sensitivity oder Domain. Row-Level Security und Column Masking regeln, welche Zeilen und Spaltenwerte Nutzer tatsächlich sehen.
- Dynamic Views bleiben vor allem für bestehende Altmodelle oder sehr spezielle Sonderfälle sinnvoll. Für neue standardisierte Schutzregeln sind ABAC, Row Filter und Column Masks meist wartbarer und besser auditierbar.
- Mein Vorschlag: Access Control in Unity Catalog klar aufteilen: RBAC als Basis, ABAC für Klassifikationen, Row-Level Security und Column Masking für feine Tabellenlogik. Änderungen über Terraform oder Asset Bundles ausrollen, Owner nicht auf einzelne Personen setzen, sondern auf Gruppen oder Service Principals, und Audit-Abfragen aus System Tables regelmäßig laufen lassen.
Inhaltsverzeichnis
Rollen allein sichern keine sensiblen Daten
Plattformen, die jeden Zugriff nur über Rollen abbilden, kommen mit wachsender Zahl an Datenprodukten schnell an Grenzen: Ein neues Datenprodukt enthält personenbezogene Daten und soll anders geschützt werden als der Rest des Schemas, und das bestehende Rollenmodell bildet diesen Sonderfall nicht sauber ab. Häufig entsteht dann einfach eine weitere Rolle, nur für diese eine Klassifikation. Mit der Zeit entstehen viele Rollen, die kaum noch sauber zu unterscheiden sind. Wer am Ende wirklich was sehen darf, lässt sich dann nur noch mühsam nachvollziehen, und neue Schutzanforderungen führen regelmäßig zu weiteren Rollenvarianten.
Spätestens im Audit kommt dann die Frage: „Zeigt mir, wer in den letzten neunzig Tagen auf Tabellen mit personenbezogenen Daten gelesen hat.“ Die nötigen Informationen liegen aber verteilt über Account-Konsole, Workspace-Rechte, GRANT-Historie, SCIM-Gruppen und Pipeline-Identitäten. Eine vollständige Antwort ist dann nicht mal eben in einer Stunde gebaut.
Eine solche Entwicklung ist in gewachsenen produktiven Plattformen häufig zu beobachten, sobald Unity Catalog mehr als ein oder zwei Workloads trägt. Das Problem ist selten eine einzelne Funktion. Meist fehlt ein klares Gesamtmodell für Identitäten, Klassifikationen, Policies und Audit. Dieses Modell muss Berechtigungen, Identitäten, Datenklassifikationen und Audit zusammenbringen.
Was umfasst Access Control in Unity Catalog?
Unity Catalog bringt mehrere Bausteine für Zugriffskontrolle mit. Ein sauberes Zugriffsmodell betrachtet diese Bausteine zusammen. Das gilt auch, wenn einzelne Funktionen erst später produktiv genutzt werden:
- Privilegien (RBAC). Privilegien werden auf Catalogs, Schemas, Tabellen, Volumes, Funktionen und Modelle vergeben und können von Catalogs auf Schemas und darunterliegende Objekte vererbt werden. Ergänzend bestehen administrative Rollen auf Account- und Metastore-Ebene. Die Privilegien-Referenz listet jedes verfügbare Recht im Detail; die Syntax dahinter zeigt der Detailartikel zu Unity Catalog Permissions.
- Tagbasierte Regeln (ABAC). Policies werden anhand von Objektmerkmalen wie Schutzbedarf, Domäne oder PII-Klassifikation angewendet (PII = true, Sensitivity = restricted, Domain = finance) statt für jede Variante eine neue Rolle zu bauen. Tag-Strategie und Vergabe vertiefen wir in Tags in Unity Catalog; wie Policies syntaktisch wirken, dokumentiert die Databricks-Doku zu Attribute-Based Access Control.
- Row-Level Security und Column Masking. Feine Steuerung, welche Zeilen und Spaltenwerte sichtbar sind, über ROW FILTER und COLUMN MASK auf Basis von SQL-Funktionen. Funktion und Syntax beschreibt die Doku zu Row Filters and Column Masks.
- Dynamic Views. Ein älteres, viewbasiertes Verfahren mit Views, die über is_account_group_member() oder current_user() filtern oder maskieren. Für neue standardisierte Schutzregeln sind sie meist nicht mehr die erste Wahl.
- Identitäten. Users, Groups, Service Principals, synchronisiert über SCIM und Identity Federation.
- Ownership. Jedes Datenobjekt hat genau einen Owner. Der Owner verwaltet das Objekt und kann Berechtigungen darauf vergeben oder delegieren.
- Workspace-Catalog-Bindings. Workspace-Catalog-Bindings legen fest, aus welchen Workspaces ein Catalog überhaupt sichtbar ist. Das ist eine zusätzliche Grenze auf Workspace-Ebene, mit der produktive Catalogs auf die vorgesehenen Workspaces beschränkt werden können.
- Audit. System Tables (system.access.audit, system.access.table_lineage) und information_schema.*_privileges als zentrale Quellen für Audit-Auswertungen zu Zugriffen, Berechtigungsänderungen und aktuellen Privilegien.
Die genaue GRANT-Syntax gehört in den Detailartikel zu Unity Catalog Permissions.
Im Zusammenspiel ergibt sich ein Drei-Schicht-Modell: RBAC als unterste Schicht mit Privilegien wie USE CATALOG, SELECT und MANAGE, die von Catalog auf Schema und Tabelle vererbt werden; ABAC als mittlere Schicht mit Tags wie pii, sensitivity und domain plus den zugehörigen Policies; RLS und Column Masking als oberste Schicht mit ROW FILTER- und COLUMN MASK-Funktionen pro Tabelle. Identitäten aus dem Identity Provider (Users, Groups, Service Principals über SCIM) verankern das Modell, Audit über system.access.audit und information_schema.*_privileges läuft als Querschnitt über alle drei Schichten, und Ownership bildet mit Gruppen oder Service Principals als Owner das Fundament darunter.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
RBAC, ABAC, RLS, Column Masking und Dynamic Views im Vergleich
| Baustein | Wie es funktioniert | Wann sinnvoll | Skaliert durch | Performance | Wartung |
|---|---|---|---|---|---|
| RBAC | auf Datenobjekte, Gruppen über SCIM | stabile Rollen pro Catalog/Domäne | Vererbung Catalog auf Schema auf Object | sehr gut, solange das Rollenmodell übersichtlich bleibt | gut, solange die Zahl der Rollen pro Catalog überschaubar bleibt |
| ABAC | Tagbasierte Policies (Sensitivity, PII, Domain) | Klassifikationen wie PII, Sensitivity oder Domain | Tags und Policies, keine neuen Rollen | gut | sehr gut, weniger neue Rollen für wiederkehrende Schutzregeln |
| Row-Level Security | mit SQL-Funktion (oft -bezogen) | Mandantentrennung pro Zeile | UDF-Logik pro Tabelle | abhängig davon, wie komplex die SQL-Funktion ist (Photon prüfen) | höher, weil die Regel pro Tabelle gepflegt wird |
| Column Masking | mit SQL-Funktion (Rolle, Tag) | PII-Maskierung pro Spalte | UDF-Logik pro Spalte | abhängig davon, wie komplex die SQL-Funktion ist | erhöht, gebündelt mit RLS sinnvoll |
| Dynamic Views | View mit / | Altmodelle oder sehr komplexe Sonderlogik | View-Definitionen | wie View-Plan | hoch, schwer auditierbar, viele schwer wartbare Views |
Rollen pro Catalog, Domäne und Umgebung
RBAC deckt die stabilen Grundrechte ab. Diese Schicht sollte zuerst sauber stehen. Sie funktioniert gut, solange die Rollen pro Catalog überschaubar bleiben.
Sinnvoll ist ein Rollenmodell entlang von Catalog, Domäne und Umgebung. Rollen pro einzelnes Datenprodukt sollten die Ausnahme bleiben. Ein Catalog wie analytics_finance braucht meist nur wenige Rollen: Reader, Writer, Owner und gegebenenfalls eine Maintainer-Rolle für Pipeline-Identitäten.
Diese Rollen sollten Gruppen aus dem Identity Provider sein und über SCIM synchronisiert werden. Produktive Pipelines laufen über Service Principals, nicht über persönliche Nutzerkonten. Auch Owner sollten möglichst eine Gruppe oder ein Service Principal sein, keine einzelne Person. Sonst hängt die Verantwortung an einer Person und wird spätestens beim Wechsel zum Problem.
Die Rechte vererben sich von Catalog auf Schema und von dort auf Tabellen. Ein GRANT auf Catalog-Ebene wirkt also auf die darunterliegenden Objekte. Genau hier ist RBAC stark: bei klar getrennten Catalogs für Domänen und Umgebungen.
Wichtig ist die Unterscheidung der Privilegien. USE CATALOG macht einen Catalog sichtbar, erlaubt aber noch keinen Zugriff auf Daten. Dafür braucht es zusätzlich SELECT auf Schema- oder Tabellenebene. ALL PRIVILEGES vergibt bestehende Rechte, aber nicht automatisch zukünftige. MANAGE erlaubt die Verwaltung von GRANTs, ohne selbst Daten lesen zu müssen. Diese Unterschiede gehören in jede Onboarding-Dokumentation.
An Grenzen kommt RBAC, sobald Klassifikationen dazukommen. Wenn eine Spalte personenbezogen ist, braucht plötzlich jede Reader-Rolle eine PII-Variante. Bei mehreren Domänen und Umgebungen wächst die Zahl der Rollen schnell. Genau an diesem Punkt wird ABAC sinnvoll.
Tag-basierte Policies für Klassifikation und PII
ABAC steuert Zugriff über Eigenschaften der Daten, nicht über immer neue Rollen. Eine Tabelle oder Spalte bekommt ein Tag, zum Beispiel PII = true, Sensitivity = restricted oder Domain = finance. Eine Policy legt dann fest, was mit diesen Daten passieren soll: Wer darf sie sehen, wer sieht sie nur maskiert, und für welche Bereiche gilt die Regel?
Der Vorteil: Es braucht nicht für jeden Sonderfall eine neue Rolle. Wenn eine neue Tabelle mit personenbezogenen Daten dazukommt und korrekt getaggt ist, greift die bestehende Policy automatisch. Es braucht keinen neuen GRANT und keine neue Sonderrolle.
Damit das funktioniert, muss die Tag-Strategie vor dem produktiven Einsatz stehen. Meist reichen wenige klar definierte Tag-Achsen aus, zum Beispiel Domain, Sensitivity, PII und optional Owner-Domain oder Compliance-Zone. Zu viele Tags machen das Modell schnell unübersichtlich. Zu wenige Tags lassen wichtige Schutzfälle offen.
Wie sich Tags sauber über Catalogs, Schemas und Tabellen nutzen lassen, klären wir im Überblick zu Tags in Unity Catalog. Wie ABAC-Policies konkret geschrieben werden, führen wir im Detail zu Attribute-Based Access Control aus.
ABAC passt aber nicht für jede Regel. Wenn der Zugriff pro Zeile entschieden wird, zum Beispiel nach Mandant, Filiale oder Land, ist Row-Level Security meist die bessere Lösung.
Row-Level Security und Column Masking als feingranulare Zugriffsschicht
Row-Level Security wird wichtig, wenn Nutzer unterschiedliche Zeilen derselben Tabelle sehen sollen. Typisches Beispiel: Eine zentrale Bestelltabelle enthält Daten mehrerer Mandanten, aber jeder Mandanten-Reader darf nur die eigenen Zeilen sehen. Eine SQL-Funktion entscheidet dann bei jeder Abfrage, welche Zeilen für die aktuelle Identität sichtbar sind.
Column Masking arbeitet auf Spaltenebene. Eine Telefonnummer, E-Mail-Adresse oder Kundennummer wird für die meisten Nutzer maskiert. Nur berechtigte Gruppen sehen den Klartext. Auch hier entscheidet eine SQL-Funktion, ob der Originalwert ausgegeben oder ersetzt wird.
Beide Mechanismen sollten vor dem produktiven Einsatz mit echten Abfragen getestet werden. Komplexe Funktionen, große Mapping-Tabellen oder unnötige Joins im Filter können Abfragen deutlich verlangsamen. Besser sind einfache Funktionen, vorberechnete Zuordnungstabellen und ein kurzer Blick in den Query-Plan, bevor die Regel breit ausgerollt wird.
Die Faustregel: Mandantentrennung pro Zeile gehört in Row-Level Security. PII-Spalten, die je nach Gruppe sichtbar oder maskiert sein sollen, gehören ins Column Masking. Wenn beides auf derselben Tabelle gebraucht wird, sollte die Logik gemeinsam geplant werden.
Wann RLS, wann Column Masking und wie die Funktionen sauber aufgebaut werden, zeigen wir im Detail zu Row-Level Security und Column Masking.
Wann sind Dynamic Views noch sinnvoll?
Dynamic Views sind der ältere Weg, um Nutzerlogik in Unity Catalog abzubilden. Die View enthält Filter- oder Maskierungslogik, zum Beispiel über current_user() oder Gruppenabfragen, und wird statt der eigentlichen Tabelle freigegeben. Für viele Plattformen war das der erste praktikable Weg, um Zeilen- oder Spaltenschutz umzusetzen.
Heute sollte die Frage aber nicht mehr lauten: Dynamic View oder gar nichts. Für viele neue Standardfälle sind Row-Level Security, Column Masking oder ABAC besser wartbar. Die Regeln hängen dann direkt an Tabellen, Spalten oder Tags und sind leichter zu prüfen als Logik, die in vielen View-Definitionen verteilt ist.
Sinnvoll bleiben Dynamic Views vor allem in zwei Fällen: bei komplexer fachlicher Logik, die ohnehin als View-Modell gebraucht wird, und als Übergangslösung aus bestehenden Legacy-Strukturen. Neue Standardregeln für PII, Mandanten oder Klassifizierungen sollten dagegen nicht mehr automatisch als Dynamic Views gebaut werden.
Wann Dynamic Views noch tragen und wie der Übergang zu ABAC oder RLS aussehen kann, klären wir im Überblick zu Dynamic Views.
Owner, Service Principals und SCIM-Gruppen als Grundlage des Zugriffsmodells
Ohne klare Identitäten funktioniert kein Zugriffsmodell dauerhaft sauber. Drei Punkte sollten vor jedem Rollout geklärt sein:
Owner als Gruppe
Einzelne Personen als Owner sind langfristig riskant. Sobald die Person das Unternehmen oder die Rolle verlässt, ist die Owner-Position verwaist und GRANTs lassen sich nicht mehr vergeben. Eine Owner-Gruppe löst das.
Pipelines als Service Principal
Pipelines sollten über Service Principals laufen, nicht über persönliche Konten. So bleibt getrennt, was automatisiert läuft und was eine Person ausgelöst hat.
Gruppen über SCIM
Manuelle Gruppenpflege in Unity Catalog erzeugt eine zweite Wahrheit neben dem Identity Provider. SCIM und Identity Federation halten die Plattform-Gruppen synchron und machen den GRANT-Prozess nachvollziehbarer.
Der Identity Provider (Entra ID, Okta, Keycloak) synchronisiert Users, Groups und Service Principals über SCIM auf die Unity-Catalog-Account-Ebene, Identity Federation reicht die Identitäten an die Workspace-Ebene weiter, und dort werden GRANTs auf Securable Objects wie Catalog, Schema und Tabelle vergeben.
Terraform, Asset Bundles und CI/CD
Ein Zugriffsmodell sollte nicht nur in der Oberfläche, in Confluence-Seiten oder im Wissen einzelner Personen existieren. Wenn GRANTs, Rollen und Policies manuell gepflegt werden, lässt sich später nur schwer nachvollziehen, welcher Stand wirklich gilt. Spätestens im Audit kostet das unnötig Zeit.
Sauberer ist ein Modell als Code: Catalogs, Schemata, Rollen, GRANTs, ABAC-Policies, Row-Filter-Funktionen und Column-Masks werden über Terraform oder Databricks Asset Bundles ausgerollt. Änderungen laufen über Pull Requests, werden geprüft und anschließend reproduzierbar deployed. Manuelle Änderungen in Produktion bleiben die Ausnahme.
So bleibt auch ein mehrschichtiges Zugriffsmodell mit vielen Catalogs und Datenprodukten wartbar. Gleichzeitig werden Abweichungen sichtbar, bevor sie zum Problem werden: etwa manuelle GRANTs in der Konsole, Notebook-Änderungen oder Unterschiede zwischen Code-Stand und Plattform-Stand.
Zugriffe und GRANTs über System Tables prüfen
Für Audits sind vor allem zwei Fragen wichtig:
Wer hat zuletzt auf sensible Daten zugegriffen?
Über system.access.audit lässt sich nachvollziehen, welche Identitäten auf Daten zugegriffen haben. In Kombination mit Tag-Informationen, zum Beispiel aus system.information_schema.column_tags, kann gezielt geprüft werden, wer in den letzten 90 Tagen Tabellen oder Spalten mit PII = true gelesen hat.
Wer hat neue Berechtigungen bekommen?
GRANTs und Revokes lassen sich ebenfalls über system.access.audit auswerten. So wird sichtbar, wer in den letzten 30 Tagen Zugriff auf produktive Catalogs erhalten hat, welches Privileg vergeben wurde und wer die Änderung durchgeführt hat.
Beide Prüfungen sollten nicht erst im Audit gebaut werden. Sinnvoll ist eine feste monatliche Routine, die sensible Zugriffe, neue GRANTs und auffällige Änderungen regelmäßig sichtbar macht.
Wie System Tables aufgebaut sind und welche Abfragen sich für solche Kontrollen eignen, zeigen wir im Detail zu System Tables.
Migration zu Unity Catalog Access Control aus Workspace-ACLs und Dynamic Views
Die meisten Plattformen starten nicht bei null. Häufig gibt es noch Hive Metastore, Workspace-ACLs, alte Dynamic Views, manuelle GRANTs und persönliche Owner-Konten. Der Übergang zu Unity Catalog Access Control sollte deshalb nicht als Big Bang geplant werden.
Drei Schritte machen die Migration beherrschbar:
Inventur
Zuerst muss klar sein, was heute existiert: Catalogs, Schemata, Tabellen, Owner, GRANTs, Dynamic Views und bestehende Workspace-ACLs. Vieles lässt sich über information_schema.* auswerten. Diese Inventur ist die Grundlage für jede Modellentscheidung.
Zielmodell
Danach wird festgelegt, wie die Plattform künftig aufgebaut sein soll: Catalogs nach Domäne und Umgebung, Grundrollen pro Catalog, Tag-Achsen für ABAC, Kandidaten für Row-Level Security und der Umgang mit bestehenden Dynamic Views. Dieses Zielmodell sollte als Code entstehen, zum Beispiel über Terraform oder Databricks Asset Bundles.
Schrittweise Übernahme
Anschließend wird Catalog für Catalog migriert. Neue GRANTs werden aufgebaut, Owner von Einzelpersonen auf Gruppen oder Service Principals umgestellt und alte Strukturen zu einem klaren Cutover-Datum abgelöst. Der technische Teil lässt sich vorbereiten, der Stichtag bleibt eine organisatorische Entscheidung.
Robuster als eine Big-Bang-Migration ist meist ein Vorgehen pro Domäne oder Catalog, mit klarer Inventur, sauberem Zielmodell und festem Cutover.
Grenzen von Unity Catalog Access Control
Unity Catalog Access Control löst die Zugriffskontrolle in der Datenplattform. Es ersetzt aber nicht die angrenzenden Governance-Aufgaben. Fünf Punkte sollten vor dem Rollout klar sein.
Identity Provider
Unity Catalog arbeitet mit den Gruppen, die über SCIM und Identity Federation kommen. Wenn die Zuordnung im Identity Provider falsch ist, hilft das beste Rollenmodell nicht.
Datenklassifikation
ABAC funktioniert nur, wenn Tags korrekt vergeben werden. Ein Datenprodukt ohne PII-Tag wird nicht als PII behandelt, auch wenn sensible Spalten enthalten sind.
Performance
Row Filters und Column Masks hängen an SQL-Funktionen. Komplexe Funktionen sollten vor dem produktiven Einsatz mit echten Abfragen getestet werden.
Audit
System Tables sind wichtig, um Zugriffe und GRANTs nachzuvollziehen. Für Echtzeit-Erkennung oder Security Monitoring braucht es aber weiterhin ein SIEM.
Sonderfälle
Delta Sharing, externe Empfänger, Service Principals und KI-Workloads sollten gesondert bewertet werden. Sie gehören nicht nebenbei in dasselbe Standardmodell.
Unity Catalog ist damit eine starke Grundlage für Zugriffskontrolle. Verlässlich wird das Modell aber erst, wenn Identitäten, Tags, Policies, Audit und Sonderfälle bewusst mitgeführt werden.
Fazit
Mein Vorschlag: RBAC, ABAC und Row-Level Security/Column Masking als ein gemeinsames Zugriffsmodell planen.
Dynamic Views nur noch für Altmodelle oder Übergänge nutzen, GRANTs, Policies und Filter über Terraform oder Asset Bundles ausrollen, Owner auf Gruppen oder Service Principals setzen, Audit-Reports aus den System Tables zur monatlichen Routine machen.
Damit lassen sich zwei Fragen sauber beantworten, an denen jedes Zugriffs-Modell hängt: „Wer darf was?“ und „Wer hat was gesehen?“, in einer Form, die auch bei mehr Datenprodukten noch funktioniert und Audits in Stunden statt in Wochen beantwortet.
In gewachsenen Hive- oder Workspace-ACL-Umgebungen beginnt der Weg mit Inventur und Catalog-Aufteilung. ABAC und feinere Regeln kommen erst danach. Das Modell wächst von den Grundrechten aus und nicht aus dem schönsten ABAC-Policy-Diagramm heraus.
FAQ
Access Control in Unity Catalog regelt, wer welche Daten sehen, ändern oder verwalten darf. Es kombiniert mehrere Mechanismen: Privilegien über GRANT (RBAC), Tag-basierte Regeln (ABAC), Zeilen- und Spaltenfilter (RLS, Column Masking), Dynamic Views und Ownership. Die Funktionen sind breit; die Steuerung wird tragfähig, wenn diese Bausteine als zusammenhängendes Modell geplant werden und jede Schicht ihren klaren Use Case bekommt.
