Row Level Security für PowerBI auf Databricks: durchsetzen & pflegen

Es ist Montagmorgen, und beim Plattformteam liegen bereits drei Anfragen vor. „Füge Sara zur EMEA-Pipeline-Ansicht hinzu“ , „Verschiebe Marco von den US-Konten zu APAC, er hat vor zwei Wochen das Team gewechselt“ , „Die Revision möchte die Zugriffsliste zum Stand des ersten Quartals, noch heute.“
Auf der Databricks-Seite sieht es in der Regel gut aus: Unity Catalog mit Katalogen, Schemata, Berechtigungen und Herkunftsnachweisen. Der Teil, der entscheidet, wer welche Zeilen sehen darf, befindet sich oft an einem etwas unauffälligeren Ort, z. B. in einer Tabelle auf SharePoint, einer Sidecar-SQL-Tabelle oder einem Power BI-Datensatz, der jede Nacht neu importiert wird, in der Hoffnung, dass sich nichts geändert hat.

Die Sicherheit auf Zeilenebene (Row-Level Security, RLS) für Power BI auf Databricks hat eigentlich zwei Aufgaben. Die erste ist die Durchsetzung: sicherzustellen, dass eine Abfrage nur die Zeilen zurückgibt, die ein Benutzer sehen darf. Die zweite ist die Pflege: die Liste der Personen, die was sehen dürfen, auf dem neuesten Stand zu halten, wenn Mitarbeiter hinzukommen, wechseln oder die Region wechseln. Die Durchsetzung ist gut verstanden, und es gibt zwei bewährte Wege, dies zu tun. Bei der Pflege veralten die meisten Konfigurationen still und leise.

Dieser Artikel führt durch beide Implementierungsansätze, vergleicht sie ehrlich und wendet sich dann der Frage der Wartung zu, die keiner der beiden Ansätze für sich allein beantwortet. Die Implementierungsdetails (die SQL, das Schema, die Screenshots) sind im letzten Abschnitt zusammengefasst, sodass Sie sich zunächst über die Grundzüge der Entscheidung informieren und später zur Umsetzung zurückkehren können.

Was bei der Sicherheit auf Zeilenebene in diesem Stack richtig gemacht werden muss

Behalten Sie beim Lesen diese vier Fragen im Hinterkopf. Anhand dieser Fragen können Sie eine solide Konfiguration von einer anfälligen unterscheiden, und genau diese Punkte bilden später die Grundlage für den Vergleich.

• Aktualität: Wenn sich Zugriffsrechte ändern, wie schnell spiegelt der Bericht dies wider?

• Verantwortung: Wer bearbeitet die Zugriffsliste, und können die Personen, die die Antwort kennen, dies sicher tun?

• Wiederverwendung: Befindet sich die Regel an einem Ort oder wird sie in jedes Datenset kopiert?

• Prüfung: Können Sie nachweisen, wer wann auf was zugegriffen hat und auf wessen Anweisung?

Die Ansätze im Vergleich

Ansatz 1: RLS in Power BI mit DAX-Sicherheitsrollen

Der bekannteste Ansatz hält alles innerhalb von Power BI. Sie erstellen eine Zuordnung von Benutzern zu den Werten, die sie sehen dürfen, importieren diese in das Modell und schreiben eine DAX-Sicherheitsrolle, die die Daten basierend auf dem angemeldeten Benutzer filtert. Weisen Sie Personen im Power BI-Dienst der Rolle zu, veröffentlichen Sie den Bericht, und dieser berücksichtigt die Zuordnung für jeden Betrachter.

Wo es passt: Datensets im Importmodus, bei denen die Durchsetzung vollständig innerhalb von Power BI bleiben soll; kleinere, in sich geschlossene Berichte, die durchgängig von einem einzigen BI-Entwickler betreut werden; Teams, die etwas suchen, das sie mit ihren vorhandenen Fähigkeiten noch heute einrichten können.

Was zu beachten ist: Die Zuordnung ist nur so aktuell wie die letzte Aktualisierung des Datensets, sodass Änderungen am Zugriff erst bei der nächsten Aktualisierung wirksam werden. Die Wartung obliegt dem BI-Team, wodurch routinemäßige Anfragen zu Hinzufügungen und Verschiebungen zu einer Ticket-Warteschlange werden. Jedes Datenset enthält in der Regel eine eigene Kopie der Rollen, sodass sich dieselbe Regel über Berichte hinweg fortsetzt. Jeder Neuaufbau des semantischen Modells ist eine Gelegenheit, einen Zeilenfilter unbemerkt zu entfernen. Und den Prüfverlauf der Liste müssen Sie manuell zusammenstellen.

Dieser Ansatz ist durchaus nützlich und kann für einen einzelnen Bericht, der einer einzigen Person gehört, die richtige Entscheidung sein. Er stößt jedoch an seine Grenzen, sobald dieselbe Zugriffslogik für mehr als ein Datenset gelten muss.

Ansatz 2: Plattformgestützte RLS mit Zeilenfiltern aus dem Unity Catalog

Der zweite Ansatz verlagert die Durchsetzung auf Databricks selbst. Die Zuordnung befindet sich in einer Tabelle im Unity Catalog; eine Zeilenfilterfunktion liest die angemeldete Identität und wird direkt an die Daten angehängt. Power BI stellt dann über DirectQuery eine Verbindung mit Microsoft Entra ID Single Sign-On her, sodass die Identität des Benutzers zum Zeitpunkt der Abfrage Databricks erreicht und der Filter bei jeder Abfrage ausgelöst wird, nicht bei jeder Aktualisierung.

Wo es passt: Mehrere User, die dieselben Daten lesen, wobei Sie einen einzige single-source-of-truth für Power BI, Notebooks und Pipelines gleichermaßen wünschen; Teams, die möchten, dass Berechtigungsänderungen bereits bei der nächsten Abfrage wirksam werden; Umgebungen, in denen das semantische Modell häufig neu erstellt wird und bei jedem Neuaufbau die Durchsetzung intakt bleiben soll.

Was zu beachten ist: Die Durchsetzung ist solide, aber die Zugriffstabelle benötigt noch einen Eigentümer und eine sichere Möglichkeit, sie zu bearbeiten. Das manuelle oder skriptgesteuerte Bearbeiten einer Unity-Catalog-Tabelle verlagert Routineänderungen wieder auf die Entwickler, und eine versehentliche Änderung wirkt sich sofort auf jeden Bericht aus. Die Validierung von Einträgen wie echten Identitäten, bekannten Codes, sinnvollen Operatoren und Wertekombinationen müssen Sie weiterhin selbst implementieren. Und den Änderungsverlauf der Liste müssen Sie nach wie vor separat erfassen.

Dies ist das stärkere der beiden Implementierungsmodelle, da die Regel einmalig auf der Plattform existiert und jeder Nutzer sie erbt. Es bleibt genau eine Frage offen: Wer sorgt dafür, dass die Zugriffstabelle selbst korrekt bleibt, und wie geschieht dies auf sichere Weise?

Die gemeinsame Schwachstelle: die Pflege der Zugriffsliste

Beide Ansätze lösen die Durchsetzung gut. Beide lassen dieselbe Lücke offen. Das Lakehouse ist zentralisiert und kontrolliert, während die Liste, die entscheidet, wer welche Zeilen sieht, manuell in einer Tabelle, einer Sidecar-Tabelle oder einem Skript gepflegt wird, an dessen Ausführung sich eine Person erinnern muss. Diese Lücke zeigt sich in drei wiederkehrenden Kosten:

• Organisatorische Veränderungen gibt es laufend. Neue Mitarbeiter, Versetzungen, Austritte und Veränderungen an Regionen lassen die Liste bereits am Tag nach ihrer Erstellung veralten.

• Routinemäßige Aktualisierungen landen beim falschen Team. Die IT- oder Plattformabteilung wird zum Engpass für Anfragen, die eigentlich in den Zuständigkeitsbereich der Personalabteilung fallen, und die Personen, die die Antwort kennen, sind nicht diejenigen, die die Knöpfe drücken.

• Die Revision verlangt die Liste, nicht das Lakehouse. SOX, DSGVO und DORA verlangen eine versionierte, nachvollziehbare Aufzeichnung darüber, wer wann Zugriff auf was hatte. Eine Tabelle ohne Historie kann diese Frage kaum beantworten.

Die entscheidende Frage dreht sich also weniger darum, wie man Sicherheit auf Zeilenebene durchsetzen kann (die beiden oben genannten Ansätze kümmern sich darum), sondern vielmehr darum, wie man die Zugriffsliste aktuell, gültig und nachvollziehbar hält – und zwar in der Verantwortung des Teams, das tatsächlich die Antwort kennt.

Seien Sie einer der Ersten und
melden Sie sich für die neue Version an!

Wie man sich entscheidet

Gemessen an den vier Fragen lassen sich die drei Optionen klar voneinander abgrenzen:

Wenn Sie alleiniger Eigentümer eines einzelnen Berichts sind, reichen DAX-Sicherheitsrollen aus. Wenn mehrere Nutzer dieselben Daten lesen, ist ein Zeilenfilter im Unity Catalog das strengere Implementierungsmodell und allein schon aus diesem Grund eine lohnende Lösung. In beiden Fällen benötigt die Zugriffsliste jedoch einen Eigentümer – daher die dritte Spalte, auf der der Rest dieses Artikels aufbaut.

Die Umsetzung von Anfang bis Ende

Der Rest dieses Artikels befasst sich mit der Umsetzung: dem Schema, der SQL und wie die einzelnen Teile in der Praxis aussehen. Er folgt Ansatz 2, da dies das Modell ist, auf das sich die meisten Teams einigen, sobald mehr als ein Verbraucher beteiligt ist.

Die Zugriffstabelle

Die Zuordnung erfolgt in einer einzigen operatorabhängigen Tabelle: eine Zeile pro Berechtigung, mit einem Benutzer, einem Operator und den Werten, die sie steuert. Die Operator-Spalte ermöglicht es, in einem Schema „gleich“, „in einer Liste“, „zwischen“ und „alle“ auszudrücken, ohne dass für jede Regel eine eigene Spalte erforderlich ist.

Die operatorenbezogene Zugriffstabelle: eine Zeile pro Berechtigung, ausgedrückt als Benutzer → Operator → Wert(e).

Der Zeilenfilter

Eine Zeilenfilterfunktion von Unity Catalog liest current_user() und führt eine Verknüpfung mit der Zugriffstabelle durch; anschließend wird sie mit ALTER TABLE … SET ROW FILTER an jede geschützte Tabelle angehängt. Da die Funktion zum Zeitpunkt der Abfrage ausgewertet wird, ist eine Änderung an der Tabelle bereits bei der nächsten Abfrage sichtbar.

Die Zeilenfilterfunktion und die ALTER TABLE-Anweisung, die sie an die Daten anhängt.

Zum Vergleich: Die native Power BI-Version desselben Konzepts (Ansatz 1) ist eine DAX-Sicherheitsrolle, die den angemeldeten Benutzer anhand einer importierten Zuordnung nachschlägt:

[Region] =
LOOKUPVALUE(
    UserAccess[Region],
    UserAccess[E-Mail], USERPRINCIPALNAME()
)

So sieht die Durchsetzung aus

Wenn der Filter angewendet ist und Power BI über DirectQuery mit Entra ID SSO verbunden ist, öffnen zwei Personen denselben Bericht und sehen unterschiedliche Daten, jeweils beschränkt auf die Zeilen, die ihre Identität zulässt. Kein benutzerspezifischer Arbeitsbereich, kein doppeltes Datenset.

Ein Benutzer mit umfassenden Berechtigungen sieht den vollständigen Satz an Plattformen, Gruppen und Buchungskreisen.

Ein Benutzer, der auf einen einzelnen Buchungskreis beschränkt ist, sieht nur seinen Ausschnitt desselben Berichts. Gleiches Datenset, gleiche Visualisierungen, gefiltert nach der Plattform.

Die Wartungslücke schließen

Die Durchsetzung ist geregelt. Die offene Frage aus dem Vergleich, d. h. wer die Zugriffstabelle korrekt hält und wie, ist ein Wartungsproblem, und es ist dasjenige, das die meisten Teams unterschätzen. Eine Möglichkeit, diese Lücke zu schließen, besteht darin, dem Unternehmen eine sichere, validierte Oberfläche für dieselbe Zugriffstabelle zur Verfügung zu stellen, sodass die Verantwortlichen für das Organigramm diese direkt pflegen können, anstatt Tickets einzureichen. Das ist die Rolle, die NextTables in der hier gezeigten Konfiguration spielt.

Die Zugriffstabelle bleibt genau dort, wo sie ist, nämlich in Databricks. Eine datenbasierte App auf Ordnerebene stellt sie als vertrautes Raster dar, wobei eine intelligente Suche Benutzeridentitäten und Berechtigungswerte anhand vorhandener Stammdaten auflöst, sodass Mitwirkende den richtigen Wert auswählen können, anstatt sich Codes merken zu müssen.

Die als Raster dargestellte Zugriffstabelle kann das Team, das für das Organigramm verantwortlich ist, direkt pflegen.

Jeder Eintrag wird bei der Eingabe validiert: Ungültige Identitäten, unbekannte Codes und nicht übereinstimmende Operator-/Wert-Kombinationen werden abgefangen, bevor sie die Plattform erreichen, und Berechtigungen auf Ordnerebene beschränken den Bearbeitungsumfang, sodass das Team, das den EMEA-Zugriff verwaltet, nicht versehentlich den APAC-Zugriff ändern kann.

Geführte Eingabe mit Validierung: Der Operator und seine Werte werden überprüft, bevor die Zeile geschrieben wird.

Die Durchsetzung bleibt unverändert. Derselbe Zeilenfilter im Unity Catalog liest die Tabelle in Echtzeit, sodass eine Bearbeitung im Raster bei der nächsten Abfrage sichtbar ist und Power BI, Notebooks und Pipelines alle dieselbe Regel übernehmen.

Eine Zugriffstabelle auf der Plattform; ein Zeilenfilter; jeder Nutzer erbt dieselbe Regel.

Da die Zugriffstabelle und ihr Verlauf in Databricks verbleiben, handelt es sich hierbei nicht um ein neues System of Record und auch nicht um einen Ersatz für Entra ID oder Unity Catalog. Es setzt das bereits vorhandene Modell durch und bietet dem Unternehmen eine validierte, autorisierte und überprüfbare Oberfläche zur Pflege der darin enthaltenen Daten. Entfernt man es, bleibt die Plattform weiterhin die Quelle der Wahrheit.

Row Level Security: Unser Fazit

Die Governance des Lakehouse muss über technische Metadaten hinausgehen und die menschliche Logik des Zugriffs einbeziehen. Die Zuordnung, die die Sichtbarkeit bestimmt, sollte von der Abteilung verwaltet werden, die für das Organigramm verantwortlich ist, und auf derselben Plattform gehostet werden, auf der sich die zugrunde liegenden Daten befinden. Während die Durchsetzung über DAX oder Unity Catalog eine gelöste technische Herausforderung ist, liegt der eigentliche operative Vorteil darin, sicherzustellen, dass die Zugriffsliste aktuell, gültig und vollständig nachvollziehbar bleibt. Durch die Überbrückung der Kluft zwischen Plattformingenieuren und Geschäftsverantwortlichen kann das Lakehouse sein Versprechen einer sicheren, genauen Datenbereitstellung bis hin zur endgültigen Abfrage erfüllen, anstatt an der Grenze des Unity Catalog Halt zu machen. NextTables erleichtert diese Governance, indem es die Eigentümer des Organigramms direkt mit der Zugriffskontrolle der Plattform verbindet und so sicherstellt, dass die menschliche Logik des Unternehmens genau in der Datenschicht widergespiegelt wird.

Bringen Sie die Logik Ihres Unternehmens direkt in die Zugriffskontrolle Ihrer Datenplattform. Kontaktieren Sie uns für eine unverbindliche Beratung oder fordern Sie eine Testversion von NextTables an, um den Mehrwert business-gesteuerter Governance selbst zu erleben.