Unity Catalog Berechtigungen: Rollen und Zugriffe planen

Wer darf Vertriebsdaten lesen, wer Tabellen verändern und welche Pipeline darf in Produktion schreiben? Ohne ein gemeinsames Berechtigungskonzept werden solche Fragen schnell zu Einzelfallentscheidungen. Das erschwert Audits, verlangsamt Freigaben und lässt Zugriffsrechte entstehen, deren Zweck später niemand mehr erklären kann.

Mit Unity Catalog Berechtigungen steuerst Du den Zugriff auf Datenobjekte in Databricks zentral. Dafür reicht es allerdings nicht, einzelne GRANT-Anweisungen auszuführen. Du brauchst eine Struktur, die fachliche Verantwortung, technische Identitäten und überprüfbare Regeln verbindet. Dieser Artikel zeigt Dir, wie Du sie aufbaust.

Kurz gesagt: Ein nachvollziehbares Berechtigungskonzept im Unity Catalog verbindet Kataloge und Schemas als Zugriffsgrenzen mit Gruppen für Menschen und Service Principals für automatisierte Prozesse. Du vergibst nur die benötigten Rechte, berücksichtigst deren Vererbung und kontrollierst regelmäßig sowohl direkte als auch indirekte Zugriffsmöglichkeiten.

Wie funktionieren Unity Catalog Berechtigungen?

Unity Catalog Berechtigungen regeln, welche Identitäten auf welche Datenobjekte zugreifen und welche Aktionen sie ausführen dürfen. Für den Tabellenzugriff sind neben dem eigentlichen Datenrecht auch Nutzungsrechte auf dem übergeordneten Katalog und Schema erforderlich.

Die grundlegende Hierarchie lautet:

• Metastore: übergeordnete Verwaltungseinheit für Unity-Catalog-Objekte.
• Katalog: organisatorische Grenze, beispielsweise für eine Umgebung oder Domäne.
• Schema: Unterteilung eines Katalogs, etwa nach Datenprodukt oder Verarbeitungsstufe.
• Datenobjekt: beispielsweise Tabelle, View oder Volume mit jeweils passenden Privilegien.

Zum Lesen einer Tabelle benötigt eine Identität normalerweise USE CATALOG, USE SCHEMA und SELECT. Die beiden Nutzungsrechte allein erlauben noch keinen Zugriff auf Tabelleninhalte.

Wichtig ist die Vererbung: Ein SELECT auf einem Katalog oder Schema gilt für darunterliegende Tabellen und Views, einschließlich künftig angelegter Objekte. Ein enges Tabellenrecht begrenzt deshalb keinen bereits vorhandenen breiten Zugriff. Prüfe immer die übergeordneten Grants und sämtliche Gruppenmitgliedschaften mit.

Wie strukturierst Du Kataloge und Schemas sinnvoll?

Kataloge und Schemas sollten stabile Verantwortungs- und Zugriffsgrenzen abbilden, nicht jede Veränderung im Organigramm. Trenne Bereiche dann, wenn sich Schutzbedarf, zuständige Verantwortliche oder erlaubte Nutzerkreise unterscheiden.

Kataloge als bewusste Sicherheitsgrenzen

Für eine überschaubare Plattform können Kataloge wie dev, test und prod sinnvoll sein. Bei stärker getrennten Fachdomänen kommen Kombinationen wie prod_sales und prod_finance infrage. Entscheidend ist nicht das Namensmuster, sondern ob sich Rechte damit verständlich vergeben lassen.

Beantworte vorab:

• Welche Teams verantworten die enthaltenen Daten?
• Welche Daten dürfen nicht gemeinsam freigegeben werden?
• Welche Workspaces sollen den Katalog verwenden dürfen?
• Wer genehmigt Änderungen an Struktur und Zugriffen?

Workspace-Bindings können die Verwendung eines Katalogs auf bestimmte Workspaces begrenzen. Sie ergänzen die Objektberechtigungen, ersetzen sie aber nicht.

Schemas nach Zugriffsmustern schneiden

Innerhalb von prod könnten sales_raw und sales_reporting unterschiedliche Freigaben erhalten. Enthält ein Reporting-Schema ausschließlich freigegebene Daten, kann ein schemaweites Leserecht angemessen sein. Liegen dort zusätzlich sensible Personalinformationen, ist diese Grenze zu grob.

Lege vor jedem übergeordneten Grant fest, ob auch zukünftige Objekte automatisch für die Gruppe zugänglich sein sollen.

Wie verbindest Du Rollen, Gruppen und Service Principals?

Fachliche Rollen beschreiben Aufgaben; Gruppen bündeln die dafür erforderlichen Rechte für Menschen. Service Principals sind technische Identitäten für automatisierte Abläufe und sollten unabhängig von persönlichen Benutzerkonten berechtigt werden.

Gruppen statt dauerhafter Einzelberechtigungen

Nutze Account-Gruppen, die möglichst aus Deinem zentralen Identitätsmanagement synchronisiert werden. Workspace-lokale Gruppen sind kein geeigneter Ersatz für dieses Unity-Catalog-Gruppenmodell.

Ein einfaches Muster unterscheidet beispielsweise:

• sales_analysts: freigegebene Vertriebsdaten lesen.
• sales_engineers: definierte Datenbestände verarbeiten und pflegen.
• sales_data_owners: fachliche Verantwortung und Genehmigungen übernehmen.

Diese Namen sind Organisationskonventionen, keine eingebauten Unity-Catalog-Rollen. Auch fachliche Verantwortung verlangt nicht automatisch technische Eigentümerschaft an allen Objekten.

Technische Identitäten gezielt zuschneiden

Eine produktive Ladepipeline sollte unter einem dafür vorgesehenen Service Principal laufen. Trenne technische Identitäten nach Umgebung und Verantwortungsbereich, damit ein Entwicklungsprozess nicht automatisch produktive Schreibrechte erhält.

Dokumentiere für jeden Service Principal Zweck, verantwortliches Team, benötigte Objekte und Authentifizierungsverfahren. Verwende möglichst kurzlebige Authentifizierung statt langlebiger persönlicher Tokens. Ein Job-Startrecht für Menschen und die Datenrechte seiner ausführenden Identität sind getrennt zu betrachten: Prüfe deshalb auch die konfigurierte Run-as-Identität.

Welche Rechte braucht ein Team tatsächlich?

Ein Team benötigt nur die Privilegien, die seine konkreten Aufgaben erfordern. Lesen, Daten verändern, Objekte anlegen und Berechtigungen verwalten sind unterschiedliche Fähigkeiten und sollten getrennt bewertet werden.

Für eine Analystengruppe kann der Zugriff auf eine einzelne freigegebene Tabelle so aussehen:

GRANT USE CATALOG ON CATALOG prod
TO `sales_analysts`;

GRANT USE SCHEMA ON SCHEMA prod.sales_reporting
TO `sales_analysts`;

GRANT SELECT ON TABLE prod.sales_reporting.monthly_revenue
TO `sales_analysts`;

Das Beispiel ist eine gezielte Freigabe, keine vollständige Absicherung. Hat die Gruppe bereits SELECT auf prod, bleibt der Zugriff entsprechend breiter.

Für eine Pipeline unterscheidest Du dagegen Quell- und Zielrechte: SELECT zum Lesen, gegebenenfalls MODIFY für Datenänderungen und passende Erstellungsrechte, wenn neue Objekte entstehen sollen. Dazu kommen die erforderlichen Nutzungsrechte auf Katalog und Schema. Welche Kombination nötig ist, hängt von den tatsächlich ausgeführten Operationen ab.

Vergib Eigentümerschaft und MANAGE besonders restriktiv. MANAGE ist zwar kein Leserecht, erlaubt aber die Verwaltung von Grants und kann damit zur Vergabe von Datenzugriffen genutzt werden. Solche administrativen Rechte gehören ausdrücklich in die Sicherheitsprüfung.

Wie überprüfst Du Zugriffe zuverlässig?

Eine belastbare Zugriffsprüfung kombiniert vorhandene Grants, Gruppenmitgliedschaften, administrative Rechte und tatsächliche Nutzung. Eine Liste direkter Tabellenberechtigungen allein zeigt nicht alle wirksamen Zugriffsmöglichkeiten.

Kontrolliere regelmäßig:

• Vererbung: Welche Rechte kommen vom Katalog oder Schema?
• Identitäten: Sind Gruppenmitglieder und technische Konten weiterhin berechtigt?
• Administration: Wer besitzt Objekte oder darf Grants verändern?
• Ausführung: Unter welcher Identität laufen Jobs tatsächlich?
• Nebenwege: Erlauben Cloud-IAM-Rechte direkten Zugriff auf zugrunde liegenden Speicher?

Nutze dafür unter anderem SHOW GRANTS, passende Information-Schema-Ansichten und Audit-Logs. Beachte deren Sichtbarkeitsgrenzen: Eine Abfrage unter einer eingeschränkten Identität liefert nicht automatisch ein vollständiges Berechtigungsinventar.

Teste außerdem mit repräsentativen Identitäten sowohl erlaubte als auch verbotene Aktionen. Wenn nach dem Entzug eines Tabellenrechts weiterhin Zugriff besteht, suche nach weiteren Grant-Pfaden statt vorschnell einen technischen Fehler anzunehmen.

So gehen wir vor

Ein tragfähiges Konzept beginnt bei konkreten Aufgaben und endet mit überprüfbaren Zugriffstests. In der Databricks-Beratung übersetzen wir diese Anforderungen gemeinsam mit Plattformteam, Fachverantwortlichen und IT-Sicherheit in umsetzbare Regeln.

Vom Datenbestand zur Berechtigungsmatrix

1. Bestand erfassen: Datenobjekte, Schutzbedarf, Workspaces, Gruppen und technische Identitäten aufnehmen.
2. Grenzen festlegen: Kataloge und Schemas nach Umgebung, Verantwortung und Zugriffsmustern strukturieren.
3. Matrix erstellen: Für jede Gruppe und jeden Service Principal Objektbereich, Privilegien, Genehmigende und Zweck dokumentieren.
4. Änderungen kontrollieren: Grants möglichst versioniert und reproduzierbar ausrollen; Ausnahmen begründen und befristen.
5. Wirksamkeit testen: Erwartete Freigaben und ausdrücklich verbotene Zugriffe prüfen, anschließend Ergebnisse dokumentieren.

Den Betrieb mitplanen

Zur Übergabe gehören auch Eintritt, Rollenwechsel und Austritt von Beschäftigten sowie die Stilllegung technischer Identitäten. Definiere feste Prüfanlässe und einen risikogerechten Review-Zyklus. Jede Ausnahme braucht eine verantwortliche Person und ein Ablaufdatum oder einen verbindlichen Prüftermin.

So entsteht nicht nur eine Berechtigungsmatrix, sondern ein Verfahren, das bei neuen Datenprodukten und Teamänderungen weiter funktioniert.

Dein nächster Schritt

Starte mit einem klar abgegrenzten Datenprodukt und prüfe daran Struktur, Gruppen und technische Identitäten. Übertrage das Muster erst danach auf weitere Bereiche.

Du möchtest Dein Konzept entwerfen oder bestehende Zugriffe überprüfen? Ailio unterstützt Dich aus Bielefeld und Hamburg mit Databricks-Beratung – von der Berechtigungsmatrix bis zur überprüfbaren Umsetzung.