Databricks Unity Catalog ABAC: Attribute-Based Access Control

Im Unity Catalog vergibst du Zugriff üblicherweise, indem du einem Principal ein Privileg auf einem Objekt gewährst. Die Data-Analyst-Gruppe bekommt zum Beispiel SELECT auf jede Tabelle im Gold-Layer, und in dem Moment, in dem du dieser Gruppe einen neuen Nutzer hinzufügst, erbt dieser jedes Grant, das die Gruppe bereits hat. Das ist Role-Based Access Control, und für die meisten Organisationen, die Databricks und Unity Catalog nutzen - reicht das aus.

Wenn SELECT zu freizügig ist, greifst du zur nächsten Ebene darunter. Row Filter blenden Zeilen aus, die ein Nutzer nicht sehen soll. Column Masks schwärzen Werte in einem Feld, ohne die Spalte zu verbergen. Beide werden Tabelle für Tabelle vom Table Owner angewendet, und sie funktionieren gut - bis zu dem Punkt, an dem du vierzig Tabellen hast, die alle dieselbe Maske auf derselben Art von Spalte brauchen.

Genau für dieses letzte Problem wurde Attribute-Based Access Control (ABAC) gebaut. Es ist der Neuzugang im Unity Catalog, seit Mai 2026 für Row Filter und Column Masks allgemein verfügbar, und es verschiebt die Einheit der Governance von “diese Tabelle” zu “jede Tabelle, die so aussieht”. Dieser Beitrag zeigt, wie es funktioniert, wie du es konkret einrichtest und wann du es einsetzen solltest.

Die Ebenen, die du bereits hast

Vor ABAC gibt dir Unity Catalog drei Kontrollmechanismen, und sie stapeln sich, statt zu konkurrieren.

Privilegien (RBAC). Das ist die Basisschicht. GRANT SELECT ON SCHEMA gold TO data_analysts entscheidet, wer das Objekt überhaupt anfassen darf. Vererbung fließt die Hierarchie hinunter - ein Grant auf einem Katalog erreicht dessen Schemas und Tabellen, sodass du Zugriff auf der sinnvollen Ebene verwaltest und ihn kaskadieren lässt.

Row Filter und Column Masks auf Tabellenebene. Wenn “die Tabelle sehen können” nicht dasselbe ist wie “jede Zeile und jeden Wert sehen können”, hängst du einen Row Filter oder eine Column Mask an. Beides ist eine SQL-UDF: Ein Row Filter gibt einen Boolean zurück und verwirft die Zeilen, in denen er false ist; eine Maske nimmt einen Wert und gibt ihn entweder unverändert oder geschwärzt zurück. Du bindest sie mit ALTER TABLE ... SET MASK oder dem Äquivalent für Filter, und der Table Owner verwaltet sie.

Dynamic Views. Wenn du jemandem einen umgeformten, gejointen oder geschwärzten Ausschnitt der Daten geben willst, ohne ihm die Basistabellen zu überlassen, kapselst du die Tabellen in einer View, die durch Funktionen wie is_account_group_member() abgesichert ist. Das dient dazu, eine kuratierte Oberfläche bereitzustellen, nicht dazu, die darunterliegenden Tabellen zu governen.

Die Reibung zeigt sich im Maßstab. Eine an eine Tabelle gehängte Maske lebt und stirbt mit dieser Tabelle. Kopiere das Muster über vierzig Tabellen und du bekommst vierzig nahezu identische UDF-Bindungen, jede davon ein Ort, an dem die Logik auseinanderdriften kann. Der Owner von Tabelle einundvierzig muss daran denken, sie anzuwenden. Neue Tabellen landen standardmäßig ungeschützt.

Was ABAC tatsächlich ist

ABAC verschiebt die Entscheidung vom einzelnen Objekt auf die Attribute des Objekts. Im Unity Catalog sind diese Attribute Governed Tags - Key-Value-Paare auf Account-Ebene mit einem kontrollierten Vokabular, bei dem das Governance-Team sowohl die erlaubten Werte festlegt als auch, wer sie zuweisen darf. Ein pii-Tag mit Werten wie email, phone und ssn. Ein sensitivity-Tag mit public, internal, confidential, restricted.

Du taggst deine Daten einmal. Dann schreibst du eine Policy, die sinngemäß sagt: “Maskiere jede Spalte, die mit pii:email getaggt ist, für alle außer der Compliance-Gruppe.” Die Policy hängt an einem Katalog, Schema oder einer Tabelle, und sie wird dynamisch ausgewertet: Jedes Objekt in diesem Scope, das den passenden Tag trägt, wird automatisch von ihr governt. Definiere sie auf Katalog-Ebene und sie vererbt sich hinunter auf jedes Schema und jede Tabelle darin - einschließlich Tabellen, die noch nicht existieren. So kannst du ABAC nutzen, um deine Governance-Policies zu skalieren. Eine Policy, einmal geschrieben, die Daten abdeckt, die du noch gar nicht erstellt hast.

Drei Teile bringen es zum Laufen:

• Governed Tags tragen die Attribute. Standardmäßig erbt ein Securable die Tags von seinem übergeordneten Katalog oder Schema, sodass du breit taggen und dort überschreiben kannst, wo nötig. Spalten-Tags sind die Ausnahme - sie werden nicht von der Tabelle vererbt und müssen direkt auf die Spalte angewendet werden.
• Policies tragen die Regel. Es gibt drei Typen: Row Filter, Column Masks und GRANT-Policies. Die ersten beiden sind GA; GRANT-Policies sind noch Beta und decken derzeit nur EXECUTE auf Modellen ab - behandle dynamische Privilege-Grants also eher als etwas zum Beobachten denn als etwas, worauf du bauen solltest.
• UDFs tragen die Logik. Dieselben SQL-Funktionen, die du für eine Maske auf Tabellenebene schreiben würdest, wiederverwendet durch die Policy. Bevorzuge hier SQL gegenüber Python - der Optimizer kann SQL-UDFs inlinen und kann das bei Python nicht, und zur Query-Zeit ist dieser Unterschied real.

Policies matchen über zwei Funktionen auf Tags, has_tag() und has_tag_value(). Eine WHEN-Klausel matcht auf Tabellenebene (direkte oder vererbte Tags); eine MATCH COLUMNS-Klausel matcht Spalten (nur direkte Tags). Das ist die gesamte Bedingungssprache. Sie ist bewusst klein und wird von der Control Plane gegen Metadaten ausgewertet, nicht etwas, das du in beliebige Logik verwandeln kannst.

Es steckt eine Separation-of-Duties-Geschichte darin, und das ist der Teil, der zählt, sobald mehr als eine Person beteiligt ist. Das Governance-Team definiert die Tag-Taxonomie. Data Stewards (oder automatisierte Datenklassifizierung) wenden Tags an. Governance-Admins schreiben Policies. Data Producer erstellen Tabellen innerhalb des governten Scopes. Niemand ist ein Flaschenhals, und weil Policies oberhalb der Tabelle liegen, kann ein Table Owner nicht heimlich eine Maske entfernen, die das Compliance-Team gesetzt hat.

Die Einrichtung

Der Ablauf ist: den Tag definieren, ihn auf die Daten bringen, die Policy schreiben. Hier eine Column Mask von Anfang bis Ende (die vollständige Grammatik steht in der Databricks-Policy-Referenz).

Zuerst eine UDF für die Masking-Logik, nichts ABAC-Spezifisches, nur eine SQL-Funktion, die die Domain nach dem @ zurückgibt:

CREATE FUNCTION gold.security.mask_email (email STRING)
RETURNS STRING
RETURN concat('***@', split_part(email, '@', 2));

Tagge die Spalten, die du governen willst. Du kannst das von Hand an jeder Spalte tun oder Data Classification erkennen und taggen lassen - sie lernt das Muster aus Spalten, die du bereits getaggt hast, und labelt neue, sobald sie auftauchen, und genau das hält die Abdeckung davon ab, mit der Zeit zu verrotten.

Dann die Policy selbst:

CREATE POLICY mask_email_pii
ON CATALOG gold
COLUMN MASK gold.security.mask_email
TO `account users`
EXCEPT compliance_team
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS email
ON COLUMN email;

Die in ON COLUMN genannte Spalte wird der Masking-Funktion automatisch als erstes Argument übergeben, deshalb braucht eine einargumentige Maske wie mask_email keine USING COLUMNS-Klausel; die fügst du nur hinzu, um zusätzliche Argumente über den maskierten Wert hinaus zu übergeben. Von links nach rechts gelesen: Wende auf alles im gold-Katalog die Funktion mask_email auf jede mit pii:email getaggte Spalte an, für alle Nutzer außer dem Compliance-Team. Nirgends wird eine Tabelle benannt. Lege morgen eine neue Gold-Tabelle mit einer gleich getaggten E-Mail-Spalte an, und sie ist in dem Moment maskiert, in dem sie landet.

Row Filter folgen derselben Form, mit einer WHEN-Klausel, die auswählt, auf welche Tabellen der Filter angewendet wird:

CREATE FUNCTION gold.security.region_filter (region STRING)
RETURNS BOOLEAN
RETURN region = current_user_region();
 
CREATE POLICY region_row_filter
ON SCHEMA gold.sales
ROW FILTER gold.security.region_filter
TO sales_reps
FOR TABLES
WHEN has_tag_value('sensitivity', 'confidential')
MATCH COLUMNS has_tag('region') AS region
USING COLUMNS (region);

Ein paar praktische Rahmenbedingungen, die du kennen solltest, bevor du dich festlegst:

• Du brauchst Databricks Runtime 16.4 oder höher, oder Serverless Compute. Ältere Cluster erzwingen diese Policies nicht.
• Eine Policy zu erstellen oder zu ändern erfordert MANAGE auf dem Securable (oder Ownership), plus EXECUTE auf der UDF.
• Alles ist skriptbar. CREATE POLICY ist SQL, und dieselben Operationen sind über die REST-API, die SDKs und Terraform verfügbar - und dorthin gehört das, wenn du Governance als Code behandelst statt dich durch den Catalog Explorer zu klicken.

Diesen letzten Punkt würde ich bei jedem Team, das das aufsetzt, am stärksten betonen. Tags, Policies und die UDF-Bibliothek sind Konfiguration. Leg sie in Terraform ab, reviewe sie in Pull Requests, und dein Zugriffsmodell wird zu etwas, das du diffen und auditieren kannst, statt zu Stammeswissen, das in einer UI lebt.

Wann du dazu greifen solltest - und wann nicht

Hier weicht die ehrliche Antwort von der Anbieterantwort ab. Databricks empfiehlt ABAC als Standard und rät, nur für tabellenspezifische Logik oder wenn du ABAC noch nicht eingeführt hast, auf Filter auf Tabellenebene zurückzufallen. Das ist der richtige Rat für ein großes Unternehmen. Es ist nicht automatisch der richtige Rat für eine Firma mit dreißig Leuten, einem Analyst-Team und vierzig Gold-Tabellen.

Greif zu ABAC, wenn die Ökonomie zu seinen Gunsten kippt:

• Dieselbe Masking- oder Filter-Logik wiederholt sich über viele Tabellen. Das ist der Kernfall. Drei Column Masks sind billiger von Hand zu pflegen als eine Tag-Taxonomie plus eine UDF-Bibliothek. Dreißig nicht.
• Neue Tabellen landen laufend und müssen bei Ankunft geschützt sein. Wenn unklassifizierte Daten, die unmaskiert auftauchen, ein Compliance-Vorfall sind, willst du eine Abdeckung, die nicht davon abhängt, dass eine Person an einen Schritt denkt.
• Separation of Duties ist eine echte Anforderung, kein Diagramm. Compliance schreibt die Regel, Stewards klassifizieren, Producer bauen, und kein Producer kann die Regel überschreiben. Für ein reguliertes DACH-Unternehmen unter der DSGVO ist diese Trennung oft das eigentliche Deliverable, und ABAC erzwingt sie strukturell.
• Du baust die Plattform gerade jetzt. Greenfield ist der günstigste Zeitpunkt, eine Tag-Taxonomie aufzusetzen. Sie nachträglich über Hunderte bestehender Tabellen zu legen, ist der teure Weg.

Es ist überdimensioniert, wenn noch kein solcher Druck existiert. Eine Handvoll Gold-Tabellen, eine Analyst-Gruppe, Masken, die du an einer Hand abzählen kannst - dafür Governed Tags, einen Klassifizierungsprozess und eine Policy-Bibliothek aufzubauen, ist mehr Gerüst, als das Gebäude braucht. Du steckst mehr Aufwand ins Aufstellen der Taxonomie, als du je ins direkte Pflegen der Masken stecken würdest, und eine halb befüllte Tag-Taxonomie ist schlimmer als keine, weil Policies stillschweigend die Spalten verfehlen, die niemand getaggt hat.

Die Mid-Market-Antwort, die ich einem Kunden tatsächlich geben würde: meistens noch nicht, aber plane so, als würdest du es tun. Halte deine Masking-UDFs vom ersten Tag an zentral und wiederverwendbar, auch wenn du sie Tabelle für Tabelle bindest. Benenne deine sensiblen Spalten konsistent. Wenn du die Schwelle überschreitest - mehr Tabellen, als du von Hand governen willst, ein DSGVO-Audit, das nachweisbare Separation of Duties verlangt, oder ein neuer Plattform-Aufbau - ist die Migration zu ABAC dann eine Sache des Taggens und des Hebens deiner bestehenden UDFs in Policies, keine Neuentwicklung. ABAC ist nicht der Startpunkt für die meisten Mid-Market-Teams. Es ist der Ort, an dem sie startklar sein sollten, sobald Governance pro Tabelle nicht mehr skaliert - und auf einer Snowflake- oder Databricks-Plattform, die auf Wachstum ausgelegt ist, kommt dieser Moment tendenziell früher, als die Organisation plant.

Wenn du noch dabei bist, zu verorten, wo Governance in deinem größeren Plan sitzt, ordnet Deine Datenstrategie für 2026 definieren diese Entscheidung ein, und die Unity Catalog System Tables sind der Ort, an dem du auditierst, wer tatsächlich worauf zugegriffen hat, sobald deine Policies live sind.

FAQ

Ist ABAC allgemein verfügbar oder noch in Preview?

Row-Filter-Policies, Column-Mask-Policies, Governed Tags und Data Classification erreichten im Mai 2026 GA. GRANT-Policies, also dynamische Privilege-Grants auf Basis von Tags, sind noch Beta und derzeit auf EXECUTE auf Modellen beschränkt.

Ersetzt ABAC RBAC?

Nein. Sie sitzen auf unterschiedlichen Ebenen und sind dafür gedacht, zusammen zu laufen. Privilegien entscheiden, ob ein Principal ein Objekt überhaupt erreichen kann; ABAC entscheidet, welche Zeilen und Werte er sieht, sobald er das kann. Du vergibst weiterhin SELECT; ABAC legt das Masking und Filtering obendrauf.

Kann ein Table Owner eine ABAC-Policy überschreiben oder entfernen?

Nein, und genau das ist der Punkt. Policies gehören auf Katalog- oder Schema-Ebene demjenigen, der MANAGE hält. Ein Table Owner kann keine Maske entfernen, die die Governance gesetzt hat - genau die Separation of Duties, die du mit Masken auf Tabellenebene unter Kontrolle des Owners nicht bekommst.

SQL-UDFs oder Python-UDFs für die Masking-Logik?

SQL, sofern du keinen zwingenden Grund dagegen hast. Der Optimizer kann SQL-UDFs inlinen und Prädikate durch sie hindurchschieben; bei Python kann er das nicht, deshalb kosten dich Python-Masken zur Query-Zeit. Wenn du Python nutzen musst, markiere es dort als DETERMINISTIC, wo es zutrifft.

Welches Compute brauche ich?

Databricks Runtime 16.4 oder höher, oder Serverless. Die Durchsetzung von Policies funktioniert nicht auf älteren Clustern, prüfe also deine Runtime, bevor du mit dem Taggen beginnst.

Kann ich das alles als Code verwalten?

Ja. Tags, Policies und UDFs sind alle über die REST-API, die SDKs und Terraform erreichbar. Wenn es dir mit Governance ernst ist, gehört sie dorthin - versioniert und reviewbar - statt von Hand im Catalog Explorer konfiguriert.