ABAC in Unity Catalog: Wann tagbasierte Policies sinnvoll sind
Wann ABAC in Unity Catalog sinnvoll ist: tagbasierte Policies für PII, Regionen und Klassifizierung, und wann RBAC, Row Filter oder Column Masks besser passen.
![Mitarbeiter am Schreibtisch vor zwei Monitoren, überlagert von einer Karte 'Policy: pii' mit einer Tabelle, die dieselbe Kartenzahlungs-Spalte je nach Rolle unterschiedlich zeigt: Finance sieht VISA •••• 4417, Data Eng sieht [REDACTED], Analyst sieht einen Hash-Wert, sowie einem Badge 'Tag: pii · Policy aktiv'](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fajsqxuma%2Fproduction%2Fd047068e97c05413642cfaf0c0ecb211d8270482-1376x768.jpg%3Fw%3D1920%26fit%3Dmax%26auto%3Dformat%26q%3D75&w=3840&q=75)
Die Kernaussagen auf einen Blick.
- ABAC ergänzt das klassische Rollenmodell in Unity Catalog um Regeln auf Basis von Tags. Der Zugriff kann davon abhängen, welche Tags eine Tabelle oder Spalte hat und zu welcher Gruppe ein Nutzer gehört.
- Am meisten bringt ABAC bei Schutzregeln, die immer wieder über viele Tabellen oder Spalten gelten, etwa PII, Region, Klassifizierung oder Mandantenlogik.
- Voraussetzung sind ein sauberes Rollenmodell und verlässlich gepflegte Tags. Ohne konsistente Tags wird die Governance nicht besser, sondern nur eine zusätzliche Regelschicht, deren Wirkung schwer zu prüfen ist.
- Mein Vorschlag: ABAC nur für wenige klare Regeln einsetzen, die über viele Tabellen hinweg gelten, und tabellenspezifische Logik weiterhin mit Row Filters, Column Masks oder Dynamic Views lösen.
Inhaltsverzeichnis
Wenn Rollen zur Rollen-Explosion werden
Unity Catalog ist eingerichtet, die Datenbereiche sind sauber strukturiert, die Gruppen werden über SCIM synchronisiert. Trotzdem entsteht irgendwann eine manuell gepflegte Liste für Sonderfälle: eine Berechtigungsmatrix neben dem eigentlichen Rollenmodell. „Nur DACH sieht die Region-Spalten“, „nur Compliance darf PII-Felder unmaskiert lesen“, „nur Customer-Service mit aktivem Vertrag bekommt die Status-Tabelle“. Für jeden Sonderfall kommt eine neue View, eine neue Filterfunktion, eine neue Gruppe oder eine andere Catalog-Struktur dazu. Mit jeder weiteren Tabelle wird die Pflege aufwendiger.
Gleichzeitig will das Audit nachvollziehbare Regeln sehen, die nicht für jede Tabelle einzeln erklärt werden müssen. Statt eine lange Liste einzelner Grants durchzugehen, lässt sich eine allgemeine Schutzregel formulieren („PII-Spalten sind unabhängig von der konkreten Tabelle für Compliance-Berechtigte lesbar“). Für solche wiederkehrenden Bedingungen eignet sich ABAC. Der Fehler wäre jetzt, RBAC komplett durch Policies ersetzen zu wollen. Dann verschiebt sich die Komplexität nur in eine neue Regelschicht.
An dieser Stelle kommen zwei Begriffe ins Spiel: RBAC (Role-Based Access Control) und ABAC (Attribute-Based Access Control). RBAC ist das klassische Rollenmodell: ein Nutzer gehört zu einer Gruppe, die Gruppe hat Rechte auf bestimmten Objekten. ABAC entscheidet zusätzlich anhand von Eigenschaften (Tags am Datenobjekt und Merkmalen des Nutzers) unter welchen Bedingungen ein Zugriff tatsächlich erlaubt ist.
ABAC baut auf dem bestehenden Rollenmodell auf. Ob ein Nutzer grundsätzlich auf ein Objekt zugreifen darf, entscheidet weiterhin RBAC über Gruppen und Rechte. ABAC ergänzt Bedingungen, unter denen dieser Zugriff tatsächlich genutzt werden darf.
Was ist ABAC in Unity Catalog?
Attribute-Based Access Control entscheidet Zugriffe anhand von Eigenschaften der Daten und des Nutzers: Eigenschaften der Daten, zum Beispiel Tags, und Eigenschaften und Gruppen des Nutzers (Gruppen-Mitgliedschaft, Account-Attribute oder Kontextwerte).
ABAC folgt damit einem einfachen Prinzip: Zugriff hängt nicht nur an Rollen, sondern auch an Eigenschaften. Ein Modell, das viele Plattformen über Tags und Bedingungen umsetzen. Der Vorteil in Unity Catalog ist die direkte Einbindung in die vorhandenen Datenobjekte und Metadaten: Policies greifen direkt an Catalogs, Schemas, Tabellen oder Spalten. Dadurch braucht es kein separates System, nur um Daten zu klassifizieren und Regeln zuzuordnen.
Wo die einzelnen Mechanismen sitzen und wie sie sich gegenseitig stützen, ordnen wir im Überblick 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.
Wie prüft Unity Catalog den Zugriff?
Das Modell besteht aus vier Bausteinen:
- Governed Tags auf Catalogs, Schemas, Tabellen oder Spalten. Sie beschreiben Eigenschaften der Daten, etwa pii=true, region=DACH, classification=confidential. Bestimmte Tags können auf höherer Ebene gesetzt und für darunterliegende Objekte berücksichtigt werden und gelten dadurch für mehrere darunterliegende Objekte.
- Policies als zentrale Regeln. Sie verbinden Tags am Datenobjekt mit Nutzergruppen oder Nutzermerkmalen. Eine Policy kann auf viele Objekte mit denselben Merkmalen angewendet werden.
- Prüfung zur Abfragezeit. Bei jeder Abfrage prüft Unity Catalog sowohl die RBAC-Rechte als auch passende Policies. Der Zugriff ist nur möglich, wenn die Anforderungen beider Ebenen erfüllt sind.
- Verantwortung und Verwaltung der Policies auf Account- und Catalog-Ebene. Weil eine Policy viele Objekte betreffen kann, benötigt sie klare Ownership und kontrollierte Änderungsprozesse. Fehler oder Änderungen können deshalb viele Tabellen oder Spalten betreffen.
Wichtig ist die Kombination: ohne RBAC-Recht hilft auch keine ABAC-Policy, ohne passende Policy gilt das RBAC-Recht wie bisher. Beide Schichten werden bei jeder Abfrage kombiniert, nicht hintereinander geschaltet. Governed Tags wie confidential oder pii vererben sich dabei von oben nach unten durch die Objekt-Hierarchie aus Account, Metastore, Catalog, Schema und Tabelle bis zur Spalte, und Policies lassen sich je nach Bedarf auf Catalog-, Schema- oder Table-Ebene verankern.
ABAC ist nur so gut wie die Tags, auf denen die Policies aufbauen. Eine Policy „PII bleibt für externe Auditoren verborgen“ kann sensible Spalten nicht schützen, wenn sie nicht entsprechend getaggt sind. Das Problem: Auf dem Papier kann das Modell trotzdem vollständig aussehen. In Wirklichkeit fallen nicht getaggte sensible Spalten aus der Schutzregel heraus. Veraltete, fehlende oder uneinheitliche Tags sind deshalb eines der größten Risiken bei ABAC.
Ein belastbares Modell braucht eine verbindliche Tag-Strategie: klare Verantwortung für Tag-Namen, Werte und fachliche Bedeutung, klare Wege, wie Tags vergeben werden (manuell, IaC, automatisierte Klassifizierung), regelmäßige Prüfung auf fehlende, falsche oder veraltete Tags und ein Prozess, der neu erkannte sensible Daten wieder in die Klassifikation zurückspielt. Erst dann kann eine Policy die Datenmerkmale verlässlich auswerten.
Drei Fragen sollten vor der ersten ABAC-Policy beantwortet sein:
- Wer ist für welche Tag-Kategorie verantwortlich? Trennung zwischen technischen Tags (Pipeline, Owner) und Governance-Tags (PII, Region, Klassifizierung). Governance-relevante Tags sollten nicht beliebig von einzelnen Entwicklungsteams gesetzt werden.
- Wie wird geprüft, ob Tags vollständig und richtig sind? Ohne periodischen Abgleich mit Daten-Klassifikation und ohne Pflicht-Tags für neue Tabellen entstehen unbemerkte Lücken in der Klassifikation. Databricks bietet automatisierte Klassifizierung, die Tag-Lücken aufdeckt; automatische Klassifizierung hilft beim Erkennen, ersetzt aber keine fachliche Verantwortung.
- Wie verhält sich das Modell bei fehlenden oder fehlerhaften Tags? Ohne zusätzliche Regeln lässt sich nicht zuverlässig unterscheiden, ob ein Objekt bewusst als nicht sensibel klassifiziert oder lediglich nicht getaggt wurde. Restriktive Standardregeln können diese Lücke verkleinern. Sie erhöhen jedoch den Aufwand bei Onboarding, Freigabe und Fehlerbehebung.
PII, Regionen, Klassifizierung und Mandanten
ABAC eignet sich besonders für Regeln, die immer wieder vorkommen und für viele Tabellen oder Spalten gleich funktionieren. Vier typische Anwendungsfälle sind besonders relevant.
Beispiel: Versicherung mit vielen PII- und Regionsregeln
Ein Versicherer hat rund 400 Tabellen im Lakehouse, davon 120 mit PII-Spalten. Kundentabellen sollen je nach Region (DACH, BeNeLux, UK) nur für die zuständigen Gruppen sichtbar sein, PII-Spalten sollen nur Compliance unmaskiert sehen. Im bestehenden Modell werden dafür je Tabelle eigene Filter, Maskierungen und Rechte gepflegt. Für jede zusätzliche Tabelle müssen dieselben Schutzmechanismen erneut eingerichtet und geprüft werden.
Mit zentralen Policies und einheitlichen Tags lässt sich ein großer Teil dieser Logik wiederverwenden: eine Policy filtert Zeilen anhand des region-Tags und der Gruppen-Mitgliedschaft des Nutzers, eine zweite maskiert Spalten mit pii=true, außer für berechtigte Compliance-Gruppen. Für den ersten Anwendungsfall ist der Einführungsaufwand zunächst vergleichbar (Policies schreiben, Tags vergeben). Je mehr Tabellen sauber klassifiziert sind, desto weniger Zusatzaufwand entsteht pro neuer Tabelle, weil die Policy bereits gilt. Kommt eine neue Region dazu, muss die Zuordnung nur an einer Stelle erweitert werden und gilt für alle Tabellen mit region-Tag.
Aus der gleichen Logik fallen die typischen Anwendungsklassen:
PII per Tag maskieren
Eine Spalte ist pii=true. Eine Policy maskiert sie für alle Gruppen ohne Freigabe. Die Regel gilt für jede passend klassifizierte Spalte.
Zugriff nach Region steuern
Eine Tabelle oder Zeile trägt region=DACH. Eine Policy gibt Zugriff nur, wenn die Gruppen-Mitgliedschaft die Region abdeckt.
Zugriff nach Schutzklasse steuern
Tabellen tragen classification=internal|confidential|restricted. Eine Policy verknüpft Schutzklasse und Berechtigung der Identität.
Mandantenzugriff steuern
Tabellen tragen einen tenant-Tag. Eine Policy verbindet Tenant-Tag und Tenant-Gruppen-Mitgliedschaft des Nutzers.
Diese Fälle haben eine Gemeinsamkeit: die Bedingung gilt über viele Datenobjekte hinweg gleich und ist nicht an eine einzelne Tabelle gebunden. In diesen wiederkehrenden Mustern reduziert ABAC die Zahl objektspezifischer Regeln.
ABAC ergänzt RBAC, ersetzt das Rollenmodell aber nicht. Die grundlegende Frage „Darf dieser Nutzer oder Service Principal grundsätzlich auf dieses Objekt zugreifen?“ beantwortet weiterhin RBAC über Privilegien wie USE CATALOG, USE SCHEMA, SELECT. Die zusätzliche Bedingung „Unter welchen Bedingungen?“ beantwortet die Policy-Schicht zusätzlich. Ein Zugriff muss beide Prüfungen bestehen; fehlt entweder das grundlegende Privileg oder die erforderliche Policy-Bedingung, wird der Zugriff nicht gewährt.
ABAC funktioniert am besten, wenn die Rollen und Grundrechte in Unity Catalog bereits sauber gesetzt sind. Es ersetzt kein aufgeräumtes RBAC-Modell. Wenn eine Gruppe zum Beispiel SELECT auf einen ganzen Catalog hat, kann ABAC zwar einzelne PII-Felder maskieren. Die Gruppe hat aber weiterhin mehr Zugriff, als sie eigentlich braucht.
Die sinnvolle Reihenfolge ist deshalb: zuerst Rollen und Rechte aufräumen, danach ABAC-Policies ergänzen.
Welche Fragen RBAC gut löst und wo ABAC ergänzt, vertiefen wir im Artikel zu rollenbasierter Zugriffskontrolle in Unity Catalog.
ABAC vs Row Filter, Column Masks und Dynamic Views
ABAC, Row Filters, Column Masks und Dynamic Views schützen Daten auf ähnliche Weise, werden aber unterschiedlich eingesetzt. Die wichtigste Frage ist: Soll eine Regel für viele Tabellen gelten oder nur für eine einzelne Tabelle?
Row Filters und Column Masks werden direkt an eine Tabelle gebunden und bei jeder Abfrage angewendet. Databricks beschreibt diese Mechanismen in der Dokumentation. Dynamic Views sind dagegen SQL-Views mit eingebauter Nutzerlogik, zum Beispiel über current_user() oder is_member().
Die Auswahl sollte nicht davon abhängen, welche Funktion neuer ist, sondern davon, welche Lösung langfristig am verständlichsten und am besten wartbar bleibt.
| Anwendungsfall | Mechanismus | Warum |
|---|---|---|
| Zugriff nach Rolle oder Hierarchie | RBAC | Für stabile Rollen reichen normale Unity-Catalog-Rechte meist aus. |
| Zugriff nach Tag oder Klassifizierung über viele Tabellen | ABAC | Eine zentrale Policy kann für alle passend klassifizierten Objekte greifen. |
| Tabellenspezifische Zeilenlogik | Row Filter | Die Regel hängt eng an den Werten und der Struktur dieser Tabelle. |
| Spalten je nach Nutzer oder Wert maskieren | Column Mask | Die Ausgabe hängt vom Nutzer, vom Spaltenwert oder von einer Tabellenregel ab. |
| SQL-View mit Nutzerlogik für BI | Dynamic View | Die View bildet ohnehin eine eigene fachliche Konsumentensicht. |
Drei Faustregeln helfen bei der Auswahl:
Wenn dieselbe Bedingung für viele Tabellen gilt, ist ABAC meist die wartungsärmere Lösung. Wenn die Logik stark an einer einzelnen Tabelle oder Spalte hängt, sind Row Filter oder Column Masks oft besser nachvollziehbar. Wenn ohnehin eine fachliche View für BI oder Reporting entsteht, kann die nutzerabhängige Logik Teil dieser Dynamic View bleiben.
Wo Row Filters und Column Masks sauber eingesetzt werden, klären wir im Überblick zu Row-Level Security und Column-Masking in Unity Catalog.
Was ABAC voraussetzt
ABAC funktioniert nur dauerhaft, wenn die Plattform-Organisation dahinter stimmt. Das Feature allein reicht nicht. Vier Voraussetzungen sind wichtig.
Verlässliche Tag-Strategie
Jede Policy hängt an der Qualität der Tags. Schlüssel, Werte und Verantwortlichkeiten müssen klar sein, neue Tabellen brauchen Pflicht-Tags.
Klare Verantwortung für Policies
Wer Policies schreibt, wer sie prüft und wer bei Konflikten entscheidet, muss feststehen. Sonst wird das Regelwerk schnell unübersichtlich.
Versionierung über IaC
Policies versioniert und reproduzierbar ausrollen, etwa über Terraform oder Databricks Asset Bundles. Manuelle Änderungen bleiben die Ausnahme.
Kontrolle auf Abweichungen
Neue Tabellen ohne Tags, geänderte Schemata oder Policy-Änderungen außerhalb von IaC müssen sichtbar werden. Sonst wirkt das Modell korrekt, ohne es zu sein.
Die Aufgabenteilung dahinter läuft typischerweise in zwei Phasen ab. In der Setup-Phase legt ein Governance Council die Tag-Taxonomie fest, ein Data Steward vergibt die Tags an Catalogs, Schemas, Tabellen und Spalten, und ein Governance Admin definiert die Policies auf Catalog- oder Schema-Ebene. Im laufenden Betrieb erbt ein Data Creator Tags von Parent-Objekten und vergibt bei Bedarf zusätzliche, während bei einem Data Consumer die Policies automatisch zur Abfragezeit angewendet werden.
Quoten, Performance, Compute und regionale Verfügbarkeit
Neben Organisation und Verantwortung gibt es ein paar technische Punkte, die vor dem Rollout geprüft werden sollten. Die Databricks-Dokumentation zu ABAC-Requirements und Limitations beschreibt unter anderem Anforderungen an Compute, Policy-Grenzen und Tag-Vererbung. Für die Architektur reicht deshalb kein kleiner Test mit zwei Tabellen. Entscheidend ist, ob das Modell auch mit eurem echten Tabellenbestand, euren Tags und euren wichtigsten Workloads funktioniert.
Verfügbarkeit prüfen. Vor dem produktiven Einsatz sollte klar sein, ob ABAC in der genutzten Cloud, Region und Umgebung unterstützt wird. Das gilt besonders für regulierte oder spezielle Cloud-Regionen.
Mit echten Workloads testen. Policies werden bei Abfragen zusätzlich ausgewertet. Deshalb sollte nicht nur geprüft werden, ob eine Policy fachlich richtig greift, sondern auch, wie sie sich bei typischen BI-, SQL- und Job-Abfragen verhält. Pauschale Performance-Aussagen helfen wenig; entscheidend ist der eigene Query-Mix.
Zugriffswege vollständig prüfen. Vor dem Rollout sollte klar sein, welche Workloads über SQL Warehouses, Jobs, Cluster oder externe BI-Tools laufen. Wichtig ist, dass alle relevanten Zugriffswege dieselben Regeln anwenden.
Policies bewusst begrenzen. Zu viele überlappende Policies machen schwer nachvollziehbar, wer am Ende welche Daten sieht. Besser ist ein kleines, verständliches Regelwerk auf Basis sauberer Tags, statt viele Sonderregeln nachträglich übereinanderzulegen.
Was ABAC in Unity Catalog nicht löst
ABAC ist sinnvoll, wenn Schutzregeln über Tags und Klassifizierungen wiederverwendbar sind. Es ersetzt aber kein sauberes Rollenmodell und keine klare Governance. Diese Grenzen sind wichtig:
Ersetzt RBAC nicht
Wenn Rollen zu breit vergeben sind, kann ABAC einzelne Daten schützen, etwa PII-Felder maskieren. Die Grundrechte bleiben trotzdem zu weit gefasst.
Nur so gut wie die Tags
Policies greifen nur, wo Daten korrekt klassifiziert sind. Fehlen Tags oder werden sie uneinheitlich gepflegt, entstehen Lücken.
Passt nicht für jede Tabellenlogik
Regeln, die stark an einzelnen Spalten, Zuständen oder Zeitpunkten hängen, sind mit einer Row-Filter-Funktion oder Column Mask oft besser verständlich.
Zu viele Policies werden unübersichtlich
Wirken mehrere Policies, vererbte Tags und RBAC-Rechte gleichzeitig, wird die Frage 'Wer sieht was?' schnell aufwendig.
Service Principals müssen mit rein
Automatisierte Jobs laufen oft über Service Principals. Auch diese Identitäten müssen ins Berechtigungsmodell einbezogen werden.
ABAC bleibt damit eine sinnvolle zweite Schicht über RBAC. Es funktioniert aber nur zuverlässig, wenn Rollen, Tags, Policies und technische Zugriffswege zusammen betrachtet werden.
Fazit
ABAC in Unity Catalog ist besonders sinnvoll, wenn dieselbe Schutzregel für viele Tabellen oder Spalten gelten soll.
Typische Beispiele sind PII, Regionen, Datenklassifizierungen oder Mandantenlogik. In solchen Fällen ist eine zentrale Policy oft leichter zu pflegen als viele einzelne Rollen, Views und Sonderlösungen.
Voraussetzung ist aber ein sauberes Grundmodell. Wenn Rollen zu breit vergeben sind, wird ABAC nur zur zweiten komplizierten Schicht. Wenn Tags uneinheitlich gepflegt werden, greifen Policies nicht zuverlässig. Beides erhöht langfristig den Aufwand für Betrieb, Audit und Änderungen.
Tag-Taxonomie, Verantwortlichkeiten und Qualitätskontrolle sollten vor der ersten produktiven Policy stehen. Regeln, die stark an einzelne Tabellen gebunden sind, bleiben besser bei Row Filters, Column Masks oder Dynamic Views. Ein kleines, getestetes Policy-Modell ist langfristig verlässlicher als eine breite Einführung ohne klare Verantwortung.
ABAC zunächst nur für wenige klare Querschnittsregeln einsetzen, zum Beispiel PII, Region oder Klassifizierung.
FAQ
ABAC steht für Attribute-Based Access Control. In Unity Catalog ist es eine Regelschicht, die Zugriff anhand von Tags am Datenobjekt und Eigenschaften oder Gruppen des Nutzers entscheidet. Eine Policy gilt automatisch für alle Datenobjekte mit passenden Tags. RBAC bleibt die Grundlage, die grundsätzlich entscheidet, wer grundsätzlich auf welches Datenobjekt zugreifen darf.
