Databricks Row Level Security und Column Masking zentral steuern
Die Kernaussagen auf einen Blick.
- Row Filter und Column Masks schützen sensible Daten direkt in Unity Catalog. Sie regeln zentral, wer welche Zeilen sehen darf und welche Spalten nur maskiert angezeigt werden.
- Diese Regeln gelten für alle Zugriffswege: SQL, Notebooks, BI-Tools und Anwendungen. Dadurch wandert der Schutz aus einzelnen Reports, Views und Skripten an eine zentrale Stelle.
- Für größere Plattformen wird die Kombination mit Tags wichtig. PII-Spalten können klassifiziert und automatisch mit passenden Maskierungen versehen werden.
- Vor dem Einsatz sollten Performance, Runtime und Compute, Auditierbarkeit und eingeschränkte Workloads geprüft werden. Dynamic Views bleiben sinnvoll, wenn zusätzlich ein eigenes fachliches Datenmodell gebraucht wird.
Inhaltsverzeichnis
Row-Level Security pro BI-Tool wird zum Flickenteppich
In einem Plattform-Review bei einem Versicherer wurden drei unterschiedliche PII-Mechanismen parallel eingesetzt: ein Power-BI-Datenmodell mit Row-Level-Security pro Region, vier handgepflegte SQL-Views pro Mandant und eine Hash-Funktion im ETL für die E-Mail-Spalte. Jede dieser Lösungen erfüllt ihren jeweiligen Zweck. In Kombination entsteht jedoch eine schwer nachvollziehbare Schutzlogik über mehrere Systeme hinweg, das niemand mehr vollständig überblickt. Eine neue PII-Spalte erfordert Anpassungen in mehreren Teams und Werkzeugen. Eine weitere Region führt zu zusätzlichen Views und Einträgen in den Berechtigungsmodellen.
In wachsenden Lakehouse-Plattformen entsteht eine solche Struktur häufig schrittweise. BI-Teams ziehen RLS in das semantische Modell, weil sich Rollen und Filter dort direkt im semantischen Modell abbilden lassen. Plattform-Teams ergänzen Views für Sonderfälle, weil sich Sonderfälle dort mit vertrauter SQL-Logik umsetzen lassen. ETL-Teams maskieren auf dem Weg in den Speicher, weil sensible Werte dadurch bereits vor dem Zugriff weiterer Konsumenten verändert werden. Die einzelnen Entscheidungen sind nachvollziehbar, führen gemeinsam jedoch zu einem schwer prüfbaren Gesamtmodell.
Welche Spalten sind heute maskiert, welche nicht? Wo wird entschieden, ob eine neue Spalte PII trägt? Was sieht ein direkter SQL-Zugriff, der das BI-Modell umgeht? Wer übernimmt die Verantwortung für mandantenspezifische Views, wenn sich Zuständigkeiten im Team ändern? Welche Schutzlogik gilt bei Zugriffen, die außerhalb des ursprünglichen BI-Modells erfolgen?
Solange PII-Schutz auf der BI-Schicht hängt, kostet jede neue Datenquelle drei parallele Anpassungen. Liegt die Schutzlogik überwiegend im BI-Tool, verteilt sich die Verantwortung auf eine Schicht mit begrenzter plattformweiter Nachvollziehbarkeit.
| Modell | Schutzmechanismen | Zugriffswege |
|---|---|---|
| BI-RLS-Patchwork | Power-BI-RLS, SQL-Views pro Mandant, ETL-Hash, je ein eigener Pfad auf dieselbe Tabelle | Jeder Weg braucht seine eigene Pflege |
| Plattform-RLS (Unity Catalog) | Eine zentrale Schicht aus Row Filter und Column Mask am Tabellen- und Spalten-Objekt | SQL, Notebook, Power BI und Python-Job greifen auf dieselbe Schutzlogik zu |
Was sind Row Filter und Column Masks im Unity Catalog?
Row Filter und Column Masks schützen Daten direkt im Unity Catalog. Sie legen fest, welche Zeilen ein Nutzer sehen darf und wie sensible Spaltenwerte angezeigt werden.
Ein Row Filter entscheidet, ob eine Zeile für einen Nutzer sichtbar ist. Eine Column Mask verändert den sichtbaren Wert einer Spalte, zum Beispiel indem eine E-Mail-Adresse maskiert, ein Wert gehasht oder ein sensibler Inhalt ausgeblendet wird. Die Regeln werden im Unity Catalog definiert und direkt an Tabellen oder Spalten gebunden. Microsoft Learn beschreibt beide als Zugriffskontrollen, die Zeilen und Spaltenwerte zur Abfragezeit einschränken.
Der große Vorteil: Diese Regeln gelten unabhängig davon, wie jemand auf die Daten zugreift. Egal ob über SQL, Notebook, Power BI, Tableau oder einen Python-Job, die Schutzlogik bleibt dieselbe. Damit muss der Zugriffsschutz nicht mehr in jedem BI-Tool, jeder View oder jeder Anwendung einzeln nachgebaut werden. Unity Catalog übernimmt die zentrale Kontrolle, während die Nutzer weiterhin mit den bekannten Tabellen arbeiten.
Row Filter und Column Masks erzeugen keine zusätzlichen Views. Sie verändern also nicht die Datenstruktur und führen auch keine neue View-Ebene ein. Die Tabelle behält ihren Namen, ihr Schema und ihre Ownership. Nur die Ausgabe wird zur Abfragezeit gesteuert: Manche Zeilen werden nicht angezeigt, manche Spaltenwerte werden maskiert.
Das vereinfacht die Architektur, weil weniger zusätzliche Objekte gepflegt werden müssen. Die Regeln können angepasst werden, ohne Tabellen umzubenennen oder eine View-Hierarchie aufzubauen. Dynamic Views bleiben trotzdem sinnvoll, wenn über den Zugriffsschutz hinaus eine eigene fachliche Sicht auf die Daten entstehen soll. Das ordnen wir im Überblick zu Dynamic Views in Unity Catalog genauer ein.
Wie Row Filter, Column Mask und die anderen Berechtigungs-Mechaniken im Catalog zusammensitzen, klären wir im Überblick zu Unity Catalog.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Zeilen zur Query-Laufzeit einschränken
Ein Row Filter ist eine Regel, die bei jeder Abfrage prüft, ob eine Zeile für den jeweiligen Nutzer sichtbar sein soll. Dafür nutzt die Regel Werte aus der Tabelle und Informationen über den aktuellen Nutzer oder seine Gruppe. Ein typischer Aufbau sieht so aus:
Drei Punkte sind dabei wichtig.
Nutzer-Kontext
Row Filter kann Gruppenmitgliedschaften oder den aktuellen Nutzer auswerten. Die Prüfung gilt überall gleich, im SQL-Editor, in Jobs, in Notebooks oder über BI-Tools.
Nur explizite Spalten
Die Funktion arbeitet nur mit den Spalten, die ihr ausdrücklich übergeben werden. Änderungen an anderen Spalten bleiben ohne Einfluss auf den Filter.
Kein Ersatz für SELECT
Ein Row Filter ersetzt keine Tabellenberechtigung. Nutzer brauchen weiterhin das passende SELECT-Recht und sehen nur, was der Filter innerhalb dieser Berechtigung erlaubt.
Bei vielen Mandanten oder Geschäftsbereichen sollte die Filterlogik möglichst einfach bleiben. Statt für jeden Mandanten eigene Views zu bauen, kann eine zentrale Governance-Tabelle festlegen, welcher Nutzer oder welche Gruppe welche Daten sehen darf. Der Row Filter liest diese Zuordnung aus und wendet sie bei der Abfrage an.
PII-Spalten zentral schützen
Eine Column Mask legt fest, wie ein sensibler Spaltenwert angezeigt wird. Nutzer mit der passenden Berechtigung sehen den Originalwert. Alle anderen sehen eine maskierte Version, zum Beispiel einen anonymisierten, gekürzten oder ausgeblendeten Wert.
Die Regel bekommt den ursprünglichen Spaltenwert, prüft den aktuellen Nutzer oder seine Gruppe und gibt dann die passende Darstellung zurück:
Eine Column Mask sollte möglichst einfach und vorhersehbar arbeiten. Sie soll keine zusätzlichen Tabellen abfragen, keine Daten verändern und keine komplexe Nebenlogik ausführen. Ihre Aufgabe ist nur: den Wert so anzeigen, wie ihn der jeweilige Nutzer sehen darf. Je einfacher die Regel bleibt, desto besser lässt sie sich verstehen, testen und performant betreiben.
In der Praxis gibt es drei häufige Varianten.
Hash-Maskierung
E-Mail, Telefonnummer oder IBAN werden in einen stabilen Hash umgewandelt, sinnvoll, wenn der Wert nicht lesbar sein muss, aber für Vergleiche oder Verknüpfungen gebraucht wird.
Teilweise Maskierung
Ein Teil des Werts bleibt sichtbar, etwa bei Support-Fällen, wenn eine E-Mail oder IBAN wiedererkannt werden soll, ohne sie vollständig offenzulegen.
Vollständige Maskierung
Der Wert wird komplett ersetzt, etwa durch NULL oder einen festen Platzhalter, passend, wenn eine Rolle den Originalwert für ihre Arbeit nicht braucht.
Wichtig ist: Die Spalte bleibt für Anwendungen weiterhin vorhanden. Name und Datentyp ändern sich nicht. Eine Anwendung sieht also weiterhin die Spalte email, aber je nach Berechtigung nicht den echten Inhalt. Dadurch müssen bestehende Schnittstellen in vielen Fällen nicht angepasst werden.
Die manuelle Zuordnung von Maskierungsfunktionen wird schnell aufwendig, sobald viele Tabellen und PII-Spalten im Spiel sind. Bei einigen wenigen Tabellen ist das noch beherrschbar. In größeren Umgebungen wird daraus aber schnell eine dauerhafte Pflegeaufgabe.
Dafür eignet sich ein tagbasierter Ansatz über ABAC im Unity Catalog. Microsoft Learn stellt dazu ABAC-Policies und Table-Level-Bindung gegenüber. Die Idee ist einfach: Sensible Spalten werden mit Tags klassifiziert, zum Beispiel pii=high. Eine zentrale Policy legt dann fest, welche Maskierungsfunktion für alle Spalten mit diesem Tag gilt. Kommt später eine neue PII-Spalte dazu, muss sie nicht einzeln an eine Maskierungsfunktion gebunden werden. Sie fällt automatisch unter die passende Regel, sobald sie korrekt getaggt ist.
Spalten klassifizieren
Sensible Spalten werden mit einem Tag versehen, zum Beispiel pii=high.
Policy zentral definieren
Eine Policy legt fest, welche Maskierungsfunktion für alle Spalten mit diesem Tag gilt.
Automatisch angewendet
Jede aktuelle und neue Spalte mit diesem Tag fällt automatisch unter die Regel, ohne einzelne Bindung.
Das reduziert manuelle Arbeit und sorgt dafür, dass PII-Schutz über mehrere Domänen hinweg einheitlich umgesetzt wird. Die Voraussetzung ist aber eine saubere Klassifikation. Wenn sensible Spalten nicht oder falsch getaggt sind, greift auch die beste Policy nicht. Deshalb müssen Tags regelmäßig geprüft und idealerweise schon beim Ingestion-Prozess oder über Sensitive-Data-Discovery vergeben werden. Wie das skalierbar bleibt, ordnen wir im Überblick zu Tags im Unity Catalog ein.
Operativ sind drei Punkte wichtig: Die zentrale Policy sollte klar verantwortet sein, ohne die Ownership der einzelnen Tabellen aufzulösen. Die Maskierungslogik sollte standardisiert werden, statt für jede Domäne eigene Sonderregeln zu bauen. Und die Anzahl der Maskierungsvarianten sollte begrenzt bleiben: meist reichen eine Default-Maskierung und wenige begründete Spezialfälle.
Wie das Policy-Modell im Unity Catalog funktioniert, erklären wir im Überblick zu Attribute-based Access Control.
Row Filter und Column Masks vs. Dynamic Views
Row Filter, Column Masks und Dynamic Views adressieren ähnliche Anforderungen an rollenabhängige Datensichten. Der Unterschied liegt vor allem darin, wo die Logik verankert ist.
Row Filter und Column Masks greifen direkt an der Tabelle oder Spalte. Die Tabelle bleibt dieselbe, aber Unity Catalog entscheidet zur Abfragezeit, welche Zeilen sichtbar sind oder welche Spaltenwerte maskiert werden. Das ist besonders sinnvoll, wenn dieselbe Schutzregel für viele Tabellen gelten soll, zum Beispiel bei PII-Daten, mandantenabhängigen Zugriffen oder standardisierten Maskierungen.
Dynamic Views sind dagegen eigene View-Objekte. Sie können ebenfalls abhängig vom Nutzer filtern oder Werte verändern, bilden aber eine separate fachliche Sicht auf die Daten. Das ist sinnvoll, wenn über den reinen Zugriffsschutz hinaus eine eigene konsumorientierte Datenstruktur entstehen soll, etwa für Reporting, Fachbereiche oder bestimmte Datenprodukte.
| Frage | Row Filter / Column Mask | Dynamic View |
|---|---|---|
| Wo sitzt die Logik? | Direkt an Tabelle oder Spalte | In einem eigenen View-Objekt |
| Wann passt es gut? | Wiederkehrende Schutzregeln über viele Tabellen | Eigene fachliche Sicht für einen konkreten Use Case |
| Wie skaliert es? | Gut über zentrale Funktionen, Tags und ABAC | Pflegeaufwand wächst mit der Zahl der Views |
| Was bleibt sichtbar? | Die ursprüngliche Tabelle | Eine separate View |
| Was wird gepflegt? | Schutzlogik und Bindung | Fachliches Modell und Schutzlogik gemeinsam |
Als Orientierung gilt: Wenn dieselbe Sicherheitslogik über viele Tabellen hinweg gebraucht wird, sind Row Filter und Column Masks meist einfacher zu betreiben. Wenn eine View ohnehin ein eigenes fachliches Datenmodell abbildet, kann eine Dynamic View weiterhin der richtige Ort für rollenabhängige Logik sein.
Ein funktionierendes Setup mit wenigen Dynamic Views muss deshalb nicht automatisch ersetzt werden. Eine Ablösung lohnt sich vor allem dann, wenn viele Views nur wegen Zugriffsschutz existieren, der Wartungsaufwand steigt oder Audit und Governance zentraler nachvollziehbar werden sollen.
Der Unterschied ist also nicht „alt gegen neu“, sondern der Zweck: Row Filter und Column Masks eignen sich für zentrale Schutzregeln. Dynamic Views eignen sich für fachliche Sichten, in denen Zugriffsschutz nur ein Teil der Logik ist.
Row-Level Security, Column Masking und das GRANT-Modell
Row Filter und Column Masks ersetzen keine Tabellenberechtigungen. Sie setzen auf dem bestehenden GRANT-Modell auf und schränken zusätzlich ein, welche Daten innerhalb einer Tabelle sichtbar sind.
Die Reihenfolge ist wichtig: Ohne SELECT auf der Tabelle sieht ein Nutzer gar nichts. Mit SELECT darf er die Tabelle grundsätzlich lesen, bekommt aber nur die Zeilen und Spaltenwerte, die durch Row Filter und Column Masks erlaubt sind. Zugriff entsteht also erst durch beides zusammen: Objektberechtigung und Schutzregel.
In der Architektur gilt deshalb eine klare Reihenfolge: zuerst die Basisberechtigungen sauber strukturieren, dann Row Filter und Column Masks ergänzen. Ein zu breites SELECT auf viele Tabellen wird durch Maskierung nicht sauber gelöst. Die Rolle hat weiterhin Zugriff auf Tabellen und Metadaten, auch wenn einzelne Werte verborgen werden. Wie diese GRANT-Schicht im Unity Catalog aufgebaut werden sollte, ordnen wir im Überblick zu Permissions im Unity Catalog ein.
Im Zusammenspiel mit ABAC ist die Trennung einfach: ABAC entscheidet, wo eine Regel greifen soll, etwa über Tags wie pii=high. Row Filter und Column Masks definieren, was dann passiert: welche Zeilen sichtbar bleiben oder wie ein Spaltenwert maskiert wird.
Zusammen entsteht daraus ein skalierbares Modell: Tags klassifizieren die betroffenen Daten, Policies ordnen die passende Regel zu, und die Funktion setzt den Schutz zur Abfragezeit um. Wichtig ist nur, dass pro Schutzbedingung klar verantwortete Funktionen genutzt werden, damit keine konkurrierenden Regeln entstehen.
Performance und Compute-Anforderungen
Row Filter und Column Masks sollten vor einem breiten Rollout technisch geprüft werden. Entscheidend sind vor allem zwei Punkte: Wie komplex sind die Filter- und Maskierungsfunktionen? Und auf welcher Runtime beziehungsweise welchem Compute sollen die Tabellen genutzt werden?
Die Funktionen sollten möglichst einfach bleiben. Row Filter und Column Masks werden bei Abfragen laufend ausgewertet. Je komplexer die Logik ist, desto stärker kann sie die Performance beeinflussen. Databricks nennt in der Performance-Sektion zu Row Filter und Column Mask klare Hebel: Einfache SQL-Funktionen sind meist die bessere Wahl als Python-UDFs, verschachtelte Abfragen oder zusätzliche Look-ups auf andere Tabellen. Berechtigungslogik sollte so modelliert werden, dass die eigentliche Filter- oder Maskierungsfunktion schlank bleibt.
Runtime und Compute müssen unterstützt sein. Nicht jede Databricks Runtime kann Tabellen mit Row Filter oder Column Masks lesen. Ältere oder nicht unterstützte Runtimes verweigern den Zugriff, statt die Regeln zu umgehen. SQL Warehouses und Shared-Access-Cluster sind in der Regel der naheliegende Pfad. Bei Dedicated-Access-Clustern und Schreiboperationen müssen die jeweils unterstützten Runtime-Versionen vorab geprüft werden.
Grenzen von Row-Level Security und Column Masking in Databricks
Row Filter und Column Masks sind stark für wiederkehrende Schutzregeln auf Tabellen- und Spaltenebene. Sie ersetzen aber keine vollständige Governance-Architektur. Vor einem breiten Rollout sollten vier Grenzen klar sein.
Nicht jede Regel gehört in eine Policy
Komplexe fachliche Bedingungen mit Statuslogik, Historie oder mehreren Zusatzabfragen gehören eher in eine vorgelagerte Transformation oder Dynamic View. Policies sollten schlank und gut testbar bleiben.
Falsche Datentypen führen zu unerwartetem Verhalten
Filter- und Maskierungsfunktionen müssen sauber zum Datentyp der betroffenen Spalte passen. Falsche Typen können zu schwer erkennbaren Fehlern führen und sollten früh getestet werden.
Audit zeigt den Zugriff, nicht jeden sichtbaren Wert
Unity Catalog protokolliert, wer zugegriffen hat und welche Policy angewendet wurde, aber nicht automatisch jeden konkreten Wert, den ein Nutzer gesehen hat.
Einige Workloads brauchen eine gesonderte Prüfung
Bestimmte DML-Operationen, Time Travel, Clones, AI-Search-Indizes oder externe Sharing-Szenarien sind eingeschränkt. Besonders bei Delta Sharing sollte der Freigabepfad vorher geprüft werden.
Innerhalb dieser Grenzen sind Row Filter und Column Masks eine sinnvolle Schutzschicht für PII-Daten, mandantenabhängige Sichten und wiederkehrende Zugriffsmuster, besonders in Kombination mit sauberem GRANT-Modell, Tags und ABAC.
Fazit
Row Filter und Column Masks sind die zentrale Schutzschicht für PII und Multi-Tenant-Sichten, Auto-Masking läuft tagbasiert über ABAC, Dynamic Views bleiben auf fachliche Datenmodelle beschränkt.
Row Filter und Column Masks im Unity Catalog lohnen sich, wenn PII-Schutz oder Mandantentrennung über viele Tabellen, Teams und Tools hinweg einheitlich greifen sollen. Statt Regeln in BI-Modellen, Views oder ETL-Skripten mehrfach zu pflegen, liegt die Schutzlogik zentral an Tabelle oder Spalte.
Relevant wird das vor allem bei vielen sensiblen Spalten, mehreren BI-Konsumenten und klaren Audit-Anforderungen. In kleinen, stabilen Umgebungen kann eine View-Lösung weiterhin reichen. Eine Migration sollte deshalb durch konkreten Wartungs-, Audit- oder Skalierungsdruck begründet sein.
Wichtig ist die Reihenfolge: Erst das GRANT-Modell bereinigen, dann Row Filter und Column Masks ergänzen. Für Auto-Masking über ABAC braucht es außerdem eine verlässliche Tag-Strategie. Fehlen PII-Tags, greifen auch zentrale Policies nicht vollständig.
Zuerst das GRANT-Modell bereinigen, dann Row Filter und Column Masks ergänzen und die PII-Tag-Strategie für automatisches Masking über ABAC absichern.
FAQ
Ein Row Filter ist eine SQL-Funktion mit , die pro Zeile entscheidet, ob sie sichtbar bleibt; sie wird mit an eine Tabelle gebunden. Eine Column Mask ist eine SQL-Funktion, die einen einzelnen Spaltenwert umschreibt und mit an eine Spalte gebunden wird. Beide nutzen und , beide wirken zur Query-Laufzeit für jeden Konsumenten.
