Unity Catalog Permissions: Berechtigungen, Owner und Service Principals sauber steuern
Die Kernaussagen auf einen Blick.
- Databricks Unity Catalog Permissions bestehen aus Privilegien, Vererbung, Ownership und Identitäten. Erst das Zusammenspiel dieser vier Ebenen ergibt ein prüfbares Berechtigungsmodell.
- Für Datenzugriff reicht ein SELECT auf der Tabelle nicht aus. Zusätzlich müssen USE CATALOG und USE SCHEMA entlang der Objekt-Hierarchie gesetzt sein.
- Owner sind keine normalen Leser oder Schreiber, sondern verwalten Objekte und Berechtigungen. Produktive Catalogs, Schemas und Tabellen sollten deshalb Gruppen oder Service Principals gehören, nicht einzelnen Benutzerkonten.
- Mein Vorschlag: GRANTs nur an Gruppen und Service Principals vergeben, Gruppen über SCIM synchronisieren, Owner bewusst setzen, Metastore Admins stark begrenzen und Permissions über Terraform versioniert ausrollen.
Inhaltsverzeichnis
GRANTs allein sind kein Berechtigungsmodell
Ein Audit fragt nicht nur: Welche SQL-Statements wurden ausgeführt? Es fragt vor allem: Wer darf auf welche Daten zugreifen, wer hat diesen Zugriff vergeben, wann wurde er vergeben und wer kann ihn wieder entziehen?
Versionierte GRANT-Skripte helfen, weil sie den gewünschten Zustand dokumentieren. Sie zeigen aber nicht automatisch, welche Zugriffe gerade wirklich wirksam sind.
In vielen Plattformen sieht man nach ein paar Jahren ein ähnliches Bild: Rechte wurden nach und nach ergänzt. Manche Grants kamen direkt aus Notebooks, manche per manueller SQL-Ausführung. Einzelne Nutzer haben Zugriff bekommen, obwohl eigentlich Gruppen berechtigt sein sollten. Kritische Tabellen gehören noch alten Benutzerkonten. Pipelines laufen mit persönlichen Zugangsdaten statt mit Service Principals.
Das Problem ist dann nicht ein einzelner falscher Grant. Das Problem ist das fehlende Modell dahinter. Ein auditierbares Berechtigungsmodell braucht drei sauber getrennte Dinge: Privilegien, Ownership und Identitäten. Wer darf was? Wer ist verantwortlich? Und über welche Identität laufen produktive Prozesse?
Wenn diese Trennung fehlt, wächst mit der Zeit eine Rechte-Struktur, die zwar funktioniert, aber kaum noch erklärbar ist.
Was sind Permissions in Unity Catalog?
Permissions legen fest, welche Identität welche Aktion auf einem schützbaren Unity-Catalog-Objekt ausführen darf. Das Modell besteht aus drei zentralen Komponenten:
- Privilegien wie SELECT, MODIFY, CREATE TABLE, USE CATALOG, EXECUTE, READ VOLUME. Sie werden per GRANT an Identitäten vergeben und können vererben.
- Ownership als separate Verwaltungsverantwortung. Der Owner eines Objekts darf Privilegien vergeben und entziehen, das Objekt umbenennen oder löschen. Ownership und das Privileg MANAGE sind nicht gleichzusetzen.
- Identitäten als Träger: Users, Groups, Service Principals. Plus zwei administrative Rollen: Account Admin und Metastore Admin.
Das Grundprinzip basiert auf dem etablierten SQL-Modell aus GRANT und REVOKE. Unity Catalog überträgt das Konzept auf einen Metastore, der Catalogs, Schemas, Tabellen, Volumes, Models, Functions und External Locations als hierarchische, vererbungsfähige Objekte verwaltet. Dadurch lassen sich nicht nur Tabellen, sondern auch weitere Plattformobjekte einheitlich absichern.
Das Berechtigungsmodell gilt zentral für alle Workspaces, die denselben Metastore verwenden, die an denselben Metastore angebunden sind. Eine Berechtigung gilt je Object im Metastore, also workspace-übergreifend. Damit wird die zuvor workspaceabhängige Berechtigungsvergabe durch ein accountweites Modell ersetzt, in älteren Setups wurden Berechtigungen dagegen häufig pro Workspace separat gepflegt.
Nicht Bestandteil dieses Privilegienmodells sind: feingranulare Row- und Column-Filter (das übernehmen Dynamic Views, Row Filters und Column Masks), attributbasierte Policies (ABAC) und die Identity-Synchronisation aus dem Identity Provider (das ist SCIM). Wie das Privilegien-Modell zur breiteren Strategie passt, klären wir im Überblick zu Access Control in Unity Catalog.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Unity Catalog Privileges und Securable Objects im Überblick
Securable Objects sind die Unity-Catalog-Objekte, auf denen Berechtigungen gesetzt werden können. Die Hierarchie hängt am Metastore und verzweigt sich in zwei Richtungen: einmal in den Drilldown Catalog → Schema → Tabellen, Views, Volumes, Functions und Features, einmal in die direkt am Metastore hängenden Neben-Securables wie Service Credential, Storage Credential, External Location, External Metadata, Share, Recipient, Provider, Connection und Clean Room.
Die verfügbaren Privilegien unterscheiden sich je nach Objekttyp. Die wichtigsten:
| Objekt | Typische Privilegien |
|---|---|
| Catalog | USE CATALOG, CREATE SCHEMA, BROWSE, APPLY TAG, MANAGE, ALL PRIVILEGES |
| Schema | USE SCHEMA, CREATE TABLE, CREATE VOLUME, CREATE FUNCTION, CREATE MATERIALIZED VIEW, MANAGE |
| Table / View | SELECT, MODIFY, APPLY TAG, MANAGE |
| Volume | READ VOLUME, WRITE VOLUME, MANAGE |
| Function | EXECUTE, MANAGE |
| External Location | READ FILES, WRITE FILES, CREATE EXTERNAL TABLE, CREATE EXTERNAL VOLUME, MANAGE |
| Storage Credential | READ FILES, WRITE FILES, CREATE EXTERNAL LOCATION, MANAGE |
| Connection | USE CONNECTION, CREATE FOREIGN CATALOG, MANAGE |
Zwei Privilegien werden in der Praxis oft falsch eingeschätzt. ALL PRIVILEGES ist eine Sammelvergabe: die Identität bekommt alle Einzelprivilegien, die für diesen Objekttyp existieren, in einem Schritt. Owner wird sie dadurch aber nicht. MANAGE erlaubt das Verwalten von Berechtigungen, also Grants vergeben und entziehen — ohne das Recht, das Objekt zu löschen, und ohne Tag-Eigentum. MANAGE und Ownership sind also zwei verschiedene Ebenen und sollten im Rollenmodell auch so behandelt werden.
| Fähigkeit | Owner | MANAGE | ALL PRIVILEGES |
|---|---|---|---|
| Privilegien vergeben und entziehen (GRANT/REVOKE) | ✓ | ✓ | ✗ |
| Objekt droppen | ✓ | ✗ | ✗ |
| Objekt umbenennen | ✓ | ✗ | ✗ |
| Tags setzen | ✓ | ✗ | ✗ |
| Alle Lese- und Schreib-Rechte auf dem Objekt | ✓ | ✗ | ✓ |
Owner ist eine eigene Rolle, MANAGE und ALL PRIVILEGES sind Privilegien. ALL PRIVILEGES vergibt deshalb keine Ownership, und MANAGE ersetzt sie nicht.
BROWSE ist insbesondere für Discovery-Szenarien relevant: erlaubt das Sehen der Existenz und Metadaten eines Objekts, ohne Datenzugriff. Damit können Nutzer Objekte und Metadaten finden, ohne Zugriff auf deren Inhalte zu erhalten im Catalog Explorer, ohne breite SELECT-Rechte zu vergeben.
Warum USE CATALOG und USE SCHEMA Pflicht sind
Die Vererbung von Rechten hilft, größere Catalog-Strukturen einfacher zu verwalten. Gleichzeitig entstehen hier viele Missverständnisse. Drei Punkte sind wichtig.
Rechte können nach unten wirken. Ein Recht auf Catalog-Ebene kann für die darunterliegenden Schemas, Tabellen und Views gelten. Ein SELECT auf einem Schema gilt zum Beispiel für die Tabellen und Views in diesem Schema. Dadurch muss nicht jede Tabelle einzeln berechtigt werden.
USE CATALOG und USE SCHEMA werden trotzdem gebraucht. Ein Nutzer kann ein Tabellenrecht nur nutzen, wenn er auch durch die Hierarchie dorthin kommt. Dafür braucht er USE CATALOG auf dem Catalog und USE SCHEMA auf dem Schema. Fehlt eines davon, wirkt es so, als ob der Zugriff auf die Tabelle fehlt, obwohl eigentlich nur der Weg dorthin nicht freigegeben ist. Das ist eine der häufigsten Fehlerquellen.
| Kette | Catalog | Schema | Tabelle | Status |
|---|---|---|---|---|
| Funktionierend | USE CATALOG gesetzt | USE SCHEMA gesetzt | SELECT gesetzt | Zugriff erlaubt |
| Fehlerhaft | USE CATALOG gesetzt | USE SCHEMA fehlt | SELECT gesetzt | Permission Denied |
Owner werden nicht automatisch vererbt. Der Owner eines Catalogs ist nicht automatisch Owner aller Schemas und Tabellen darunter. Ownership bleibt pro Objekt gesetzt. Das ist sinnvoll, weil Plattformverantwortung und fachliche Verantwortung getrennt werden können: Das Plattform-Team kann den Catalog verantworten, während ein Fachbereich Owner seines Schemas ist.
Ein einfaches Muster für einen produktiven Analytics-Catalog kann so aussehen:
Die Idee dahinter ist einfach: Leser bekommen Sichtbarkeit und Lesezugriff. Die Pipeline bekommt Schreibrechte. Beides läuft auf derselben Objektstruktur, aber über getrennte Identitäten und klar getrennte Rechte.
Warum Owner eine eigene Steuerungsebene sind
Der Owner eines Objekts ist nicht lediglich ein Principal mit besonders vielen Privilegien. Ownership umfasst eigenständige Verwaltungs- und Delegationsrechte:
- Privilegien auf dem eigenen Objekt vergeben und entziehen (GRANT und REVOKE)
- Objekt umbenennen, umziehen, droppen
- Tags setzen und ändern
- Owner-Wechsel anstoßen
In der alten Workspace-ACL-Welt waren Zugriff und Verantwortung oft dasselbe. Unity Catalog trennt das bewusst: Wer darf zugreifen, und wer verwaltet das Objekt? Genau an dieser Trennlinie passieren in der Praxis die meisten Fehler.
Drei Muster sehen wir besonders häufig:
- Owner ist ein persönlicher User. Ein Mitarbeiter hat das Setup gemacht und ist seitdem Owner zentraler Catalogs. Verlässt die Person das Unternehmen, gibt es keinen aktiven Owner mehr, und ein Owner-Wechsel wird zum Ticket an den Metastore-Admin.
- Owner ist ein Workspace-Admin-Account. Wirkt sauberer, ist es aber nicht. Workspace-Admin-Rechte haben oft mehrere Personen, und das ist keine fachliche Verantwortung.
- Ownership und Privilegien werden vermischt. Ein Team bekommt ALL PRIVILEGES, aber niemand setzt den Owner um. Der ursprüngliche Ersteller bleibt Owner, das Team kann Rechte verteilen, aber die Tabelle nicht löschen.
Sauberer ist es, Ownership immer einer dauerhaften Gruppe oder einer technischen Identität zu geben. Der Wechsel ist ein bewusster Schritt und sollte dokumentiert sein:
Wer den Owner setzen darf, hängt von der Hierarchie ab. Bei einem Schema sind das der aktuelle Owner, der Owner des übergeordneten Catalogs, der Metastore-Admin oder jemand mit MANAGE auf dem Schema. Das ist gleichzeitig der natürliche Eskalationsweg, wenn ein Owner-Wechsel ansteht — und der gehört ins Runbook.
User, Groups und Service Principals in Unity Catalog
Unity Catalog kennt fünf Identitäts-Typen. Die Identitätstypen sollten abhängig vom jeweiligen Einsatzzweck verwendet werden.
| Identität | Wofür | Wofür nicht |
|---|---|---|
| User | Interaktive Analyse, Notebook-Arbeit, Catalog Explorer | Pipeline-Identität, GRANT-Empfänger für Teams, Owner |
| Group | GRANT-Empfänger, Owner, Berechtigungs-Bündelung | Pipeline-Identität |
| Service Principal | Pipeline, Jobs, IaC-Deployment, Programmatic Access | Interaktive Analyse |
| Account Admin | Metastores anlegen, Workspaces anbinden, SCIM-Konfiguration | Tages-Operationen |
| Metastore Admin | Cross-Catalog-Eingriffe, verwaiste Owner setzen, Notfall-Zugriff | Default-Rolle für Plattform-Engineers |
Die wichtigste Konvention: Team- und Domänenberechtigungen sollten grundsätzlich an Gruppen statt an einzelne Nutzer vergeben werden. Diese Trennung ist eine zentrale Voraussetzung für nachvollziehbares Offboarding und auditierbare Berechtigungen. Direkte Nutzerberechtigungen lassen sich nur schwer standardisieren und bei Rollenwechseln zuverlässig pflegen. Gruppen ermöglichen eine zentrale, reproduzierbare und vom einzelnen Nutzer unabhängige Vergabe.
Automatisierte Jobs und Deployments sollten unter Service Principals ausgeführt werden. Sie sind nicht an Personen gebunden, sind nicht an ein persönliches Benutzerkonto gebunden und überleben Personalwechsel. Jobs, Workflows, Asset Bundles und Terraform-Deployments laufen unter einem Service Principal, also nicht unter einem Personal Access Token. Diese Trennung reduziert einen großen Teil der typischen Risiken durch personenbezogene technische Zugänge.
Die Gruppen-Pflege selbst läuft idealerweise über SCIM. Der Identity Provider sollte die führende Quelle für Gruppen und Mitgliedschaften sein (Entra ID, Okta, andere), Unity Catalog synchronisiert sie auf Account-Ebene. Identity Federation hebt die Gruppen anschließend in alle angeschlossenen Workspaces. Ohne zentrale Synchronisierung entstehen schnell unterschiedliche Gruppenstände und Namensvarianten, GRANTs verlieren ihren Empfänger.
Welche Admin-Rollen sind wirklich nötig?
Der Metastore Admin ist für Ausnahmefälle da. Wer diese Rolle hat, kann im gesamten Metastore Owner ändern, Objekte löschen und Rechte vergeben. Deshalb sollte sie nur an wenige klar benannte Personen gehen.
Der Account Admin verwaltet den Databricks Account: Metastores, Workspace-Zuordnungen, SCIM und Identitäten. Auch diese Rolle gehört nicht in den täglichen Fachbereichsbetrieb.
Account Admin und Metastore Admin sollten getrennt bleiben. Wenn eine Person beide Rollen hat, sollte das bewusst so entschieden und dokumentiert sein.
Eine GRANT-Strategie legt fest, welche Gruppen und technischen Identitäten welche Rechte bekommen. Wichtig ist, dass diese Regeln je Catalog-Typ klar sind und nicht jedes Team eigene Muster baut.
Prod-Catalog
Lesen und Schreiben sind getrennt: Lesegruppen bekommen USE CATALOG, USE SCHEMA und SELECT, Schreibrechte gehen an die Pipeline-Identität.
Sandbox-Catalog
Für Exploration gedacht — Gruppen legen eigene Schemas an, produktive oder sensible Daten liegen hier nicht dauerhaft.
Shared-Catalog
Mehrere Domänen lesen, nur die kuratierende Domäne schreibt über ihren Service Principal und bleibt Owner.
Prod-Catalog. In produktiven Catalogs sollten Lesen und Schreiben getrennt sein. Fachliche Lesegruppen bekommen die nötigen Rechte zum Navigieren und Lesen: USE CATALOG, USE SCHEMA und SELECT auf den passenden Schemas. Schreibrechte gehören nicht an persönliche Nutzer, sondern an die technische Identität der jeweiligen Pipeline.
Owner der Schemas ist die zuständige Domänen-Gruppe. Owner des Catalogs ist das Plattform-Team. Direkte Berechtigungen an einzelne Nutzer sollten vermieden werden. ALL PRIVILEGES sollte nur in begründeten und dokumentierten Ausnahmefällen vergeben werden.
Sandbox-Catalog. Ein Sandbox-Catalog ist für Exploration gedacht. Nutzer oder Gruppen können dort eigene Schemas anlegen und Dinge ausprobieren, ohne produktive Bereiche zu verändern. Owner eines Sandbox-Schemas ist die Gruppe, die es angelegt hat.
Produktive oder sensible Daten sollten dort nicht dauerhaft liegen. Außerdem braucht der Bereich klare Löschregeln: Schemas ohne Aktivität werden nach einer definierten Zeit markiert und später entfernt. Sonst wächst der Sandbox-Bereich unkontrolliert weiter.
Shared-Catalog. Ein Shared-Catalog enthält Datenprodukte, die mehrere Domänen oder Teams nutzen. Viele Gruppen dürfen lesen, aber nur eine verantwortliche Domäne sollte schreiben. Die Updates laufen über den Service Principal dieser Domäne.
Owner ist die kuratierende Domäne, nicht das Plattform-Team. Das Plattform-Team stellt die Struktur bereit, aber die fachliche Verantwortung bleibt beim Datenprodukt.
Für alle drei Profile gilt: Jede Berechtigung sollte klar benennen, wer welches Recht auf welches Objekt bekommt und warum.
Unity Catalog Permissions mit Terraform verwalten
Manuelle GRANTs in Notebooks sind schwer sauber zu kontrollieren. Sie laufen oft ohne Review, haben keine verlässliche Versionshistorie und lassen sich nur umständlich zurückrollen. Berechtigungen sollten deshalb als Code verwaltet werden.
Terraform mit dem Databricks Provider passt gut für zentrale Plattform- und Governance-Ressourcen: Metastores, Catalogs, Schemas, External Locations, Storage Credentials, Gruppen, Service Principals und Grants. Der gewünschte Berechtigungsstand liegt dann im Repository und wird nicht nebenbei in Notebooks oder über manuelle SQL-Befehle gepflegt.
Ein einfaches Muster für ein Schema kann so aussehen:
Der Vorteil ist nicht nur Automatisierung. Jeder GRANT ist nachvollziehbar, jede Änderung läuft über Review, und ein fehlerhafter Change kann über Git zurückgenommen werden. Damit lässt sich später deutlich besser erklären, wann welche Berechtigung geändert wurde und warum.
Wie Gruppen und Privilegien im Rollenmodell zusammenspielen, klären wir im Überblick zu RBAC in Unity Catalog. Welche Erweiterungen über Attribute und Tags möglich sind, zeigen wir im Überblick zu ABAC in Unity Catalog.
Asset Bundles oder Terraform?
Databricks Asset Bundles sind für das Deployment von Workloads gedacht: Jobs, Pipelines, Notebooks, DLT oder MLflow-Experimente. Für das Unity-Catalog-Berechtigungsmodell ist Terraform meist der bessere Ort.
Die Trennung ist einfach:
Terraform nutzen, wenn
- Metastore, Catalogs oder Schemas verwaltet werden
- GRANTs auf Catalog-, Schema- oder Tabellen-Ebene versioniert werden sollen
- Service Principals oder Storage Credentials angelegt werden
- External Locations eingerichtet werden
Asset Bundles nutzen, wenn
- Jobs, Pipelines oder Notebooks deployed werden
- Workload-nahe Workspace-Permissions vergeben werden
- Der Lifecycle an einzelne Workloads statt an die Plattform gebunden ist
Job-Rechte oder Pipeline-Rechte, die direkt zum Deployment gehören, können im Asset Bundle liegen. Catalog-, Schema- und Tabellen-GRANTs sollten dagegen ins Terraform-Repository. Sie haben einen anderen Lifecycle als einzelne Workloads und betreffen meist mehrere Jobs, Teams oder Datenprodukte.
Wer beides vermischt, verliert schnell den Überblick: Welche Änderung kommt aus welchem Stack? Wer reviewed sie? Und was wird bei einem Rollback tatsächlich zurückgenommen?
Die praktische Regel: Terraform für Plattform und Unity-Catalog-Rechte. Asset Bundles für Workloads und deren Deployment.
Unity Catalog Audit: GRANTs, Owner-Wechsel und Service Principals über System Tables prüfen
Für ein Audit reicht es nicht, nur die geplanten Berechtigungen zu dokumentieren. Wichtig ist auch, was tatsächlich passiert ist: Wer hat wann auf welche Tabelle zugegriffen? Wer hat ein Recht vergeben oder entzogen? Welche technischen Identitäten wurden genutzt?
Die Grundlage dafür liefern die System Tables. Drei Bereiche sind besonders wichtig:
- system.access.audit zeigt Ereignisse wie Logins, GRANTs, REVOKEs, Owner-Wechsel, Catalog-Anlagen und Service-Principal-Nutzung.
- system.information_schema.table_privileges zeigt den aktuellen Stand der Rechte: Wer hat heute welches Privileg auf welchem Objekt?
- system.access.table_lineage und system.access.column_lineage zeigen, welche Tabellen und Spalten tatsächlich genutzt wurden.
Damit lässt sich der geplante Zugriff mit der tatsächlichen Nutzung abgleichen: Eine Identität durfte eine Tabelle lesen — und sie hat sie auch gelesen.
Eine typische Audit-Frage lautet: „Wer hat in den letzten 30 Tagen GRANTs auf produktiven Catalogs vergeben?“
Für den Betrieb reichen oft drei feste Auswertungen: ein Wochenreport über GRANTs und REVOKEs auf produktiven Catalogs, ein Monatsreport über Owner-Wechsel und ein Quartalsreport über Service-Principal-Aktivität.
So werden Audit-Fragen nicht erst beantwortet, wenn sie gestellt werden. Die wichtigsten Nachweise liegen bereits vor. Wie sich solche Auswertungen weiter operationalisieren lassen, klären wir im Überblick zu System Tables auf Databricks.
Migration aus Hive Metastore und Workspace-ACLs
Bei Migrationen aus älteren Databricks-Setups gibt es meist drei Altlasten: Hive-Metastore-GRANTs, Workspace-ACLs auf Notebooks, Cluster oder Tabellen und Personal Access Tokens, die in Pipelines genutzt werden.
Diese Dinge sollten nicht eins zu eins nach Unity Catalog übernommen werden. Hive-GRANTs sind workspace-lokal und kennen keine Catalog-Struktur. Workspace-ACLs folgen einem anderen Berechtigungsmodell. Personal Access Tokens sind keine saubere Identität für produktive Pipelines.
Die Migration sollte deshalb schrittweise laufen:
Identitäten zuerst klären
Gruppen über SCIM synchronisieren, Identity Federation aktivieren und die relevanten Gruppen auf Account-Ebene verfügbar machen.
Catalog-Struktur aufbauen
Prod-, Sandbox- und Shared-Catalogs anlegen und Owner sauber setzen.
Datenobjekte migrieren
Tabellen kontrolliert aus dem Hive Metastore übernehmen. External Tables werden über External Locations und Storage Credentials angebunden.
GRANTs neu modellieren
Alte Berechtigungen als Hinweis nutzen, aber nicht ungeprüft übernehmen. Das Zielmodell wird aus den künftigen Rollen und Verantwortlichkeiten abgeleitet.
Pipelines auf Service Principals umstellen
Persönliche Tokens durch technische Identitäten ersetzen und Jobs auf diese Identitäten umstellen.
Workspace-ACLs zurückbauen
Alte ACLs entfernen, sobald Unity Catalog die Zugriffssteuerung übernimmt.
Die Migration sollte Catalog für Catalog oder Schema für Schema erfolgen. Der Einstieg sollte nicht mit dem kritischsten Bereich starten. Jeder Schritt braucht einen klaren Test, eine dokumentierte Änderung und einen Weg zurück, falls etwas nicht funktioniert.
Grenzen des Unity-Catalog-Privilegienmodells
Unity Catalog Permissions regeln, wer auf welche Objekte zugreifen darf. Sie sind die Grundlage des Berechtigungsmodells. Sie ersetzen aber nicht alle angrenzenden Governance-Aufgaben.
Feingranulare Zugriffskontrolle
Wenn Nutzer nur bestimmte Zeilen oder maskierte Werte sehen sollen, reichen normale GRANTs nicht aus. Dafür braucht es Row-Level Security und Column Masking über Row Filters, Column Masks oder Dynamic Views. Für wiederkehrende Regeln auf Basis von Tags oder Klassifizierungen kommt ABAC dazu.
Identitäten entstehen extern
Unity Catalog arbeitet mit Gruppen, Nutzern und Service Principals, die über SCIM und Identity Federation bereitgestellt werden. Wenn Gruppen im Identity Provider falsch oder veraltet gepflegt sind, übernimmt Unity Catalog diese Probleme.
Klassifizierung bleibt eigene Aufgabe
Ein GRANT auf eine Tabelle sagt nicht, was diese Tabelle fachlich bedeutet, ob sie PII enthält oder welches Datenprodukt sie trägt. Die fachliche Einordnung muss vorher geklärt werden, Tags machen sie danach nur sichtbar.
Datenschutz ist kein Technik-Ersatz
Ein technisch korrekt gesetzter Zugriff ist nicht automatisch fachlich oder rechtlich zulässig. Besonders bei personenbezogenen Daten braucht es weiterhin Datenschutzprüfung, Zweckbindung und klare Freigabeprozesse.
Change-Prozesse bleiben nötig
Auch wenn GRANTs als Code verwaltet werden, brauchen Änderungen Review, Freigabe und einen Weg zurück. Versionierung ersetzt keinen Entscheidungsprozess.
Zeitlich befristete Rechte
Unity Catalog kennt kein einfaches GRANT bis Datum. Temporäre Zugriffe müssen über Prozesse, Automatisierung oder regelmäßige Reviews abgebildet werden.
Tiefer gehen die Überblicke zu Row-Level Security und Column Masking, Dynamic Views, ABAC und SCIM.
Die wichtigste Konsequenz: Unity Catalog Permissions funktionieren nur dauerhaft, wenn Identitäten, Ownership, Klassifizierung und Change-Prozesse mitgeführt werden. Metastore Admin, Catalog Owner und Schema Owner sollten nicht nur technisch gesetzt, sondern organisatorisch klar verantwortet sein.
Ohne diese Verankerung fallen Berechtigungen mit der Zeit oft auf technische Setup-Konten, persönliche Nutzer oder historisch gewachsene Einzelvergaben zurück. Dann funktioniert der Zugriff zwar noch, ist aber schwer zu erklären und im Audit nur mühsam nachzuvollziehen.
Wie diese Schichten zusammenspielen, zeigen wir im Überblick zur Architektur von Unity Catalog.
Fazit
Permissions in Unity Catalog sind mehr als einzelne GRANT-Befehle: Erst das Zusammenspiel aus Privilegien, Vererbung, Ownership und Identitäten ergibt ein auditfähiges Berechtigungsmodell.
Ein tragfähiges Modell beginnt bei den Identitäten: Gruppen kommen über SCIM aus dem Identity Provider, Berechtigungen gehen an Gruppen und Service Principals, nicht an einzelne Nutzer. Owner werden ebenfalls als Gruppe oder technische Identität gesetzt. GRANTs werden pro Catalog-Typ definiert und als Code verwaltet. Metastore Admins bleiben auf wenige klar benannte Personen begrenzt. Änderungen und Nutzung werden regelmäßig über System Tables geprüft.
Beim Setup eines neuen Catalogs sollten diese Fragen direkt beantwortet sein: Wer ist Owner? Welche Gruppen dürfen lesen? Welche technische Identität darf schreiben? Wenn diese Punkte erst im Audit geklärt werden, ist das Berechtigungsmodell nicht sauber genug aufgesetzt.
Klärt bei jedem neuen Catalog-Setup vorab, wer Owner ist, welche Gruppen lesen dürfen und welche Identität schreiben darf, bevor der erste GRANT läuft.
FAQ
Permissions in Unity Catalog sind ein Modell aus drei Achsen: Privilegien (SELECT, MODIFY, USE CATALOG und weitere), Ownership als eigene Rolle und Identitäten (User, Group, Service Principal, Metastore Admin). Ein GRANT-Statement vergibt ein Privileg an eine Identität auf einem Securable Object. Das Modell vererbt abwärts von Catalog auf Schema auf Tabelle, sobald USE CATALOG und USE SCHEMA gesetzt sind.
