'Row-Level Security (RLS): Unternehmensweite Berechtigungsverwaltung in Power BI'

„Der Geschäftsführer soll den gesamten Umsatz sehen, die Regionalleiter nur ihre eigene Region, die Außendienstmitarbeiter nur ihre eigenen Kunden.“ Dieser Bedarf wird mit dem Feature Row-Level Security (RLS) von Power BI erfüllt. Ein richtig konzipiertes RLS ermöglicht es Ihnen, mit einem einzigen Bericht + einem einzigen Dataset Dutzende verschiedener Berechtigungsstufen zu verwalten; eine falsche Konzeption dagegen erzeugt eine Sicherheitslücke und beeinträchtigt die Performance. In diesem Beitrag behandeln wir ausführlich statisches und dynamisches RLS, die Verwendung von USERPRINCIPALNAME und Praxisanwendungen.

01. Was ist RLS und was löst es?

Row-Level Security sorgt über Filter, die auf das Datenmodell angewendet werden, dafür, dass derselbe Bericht von verschiedenen Nutzern mit einer unterschiedlichen Zeilenmenge gesehen wird. Statt sich abzumühen und 10 verschiedene Berichte zu kopieren, baut die Führungskraft einen einzigen Bericht; sie trennt Rollen und Filter.

RLS arbeitet in zwei Schichten:

• Modellschicht: Welche Rolle welche Zeilen sieht, wird mit DAX-Filtern definiert
• Service-Schicht: Welcher Nutzer welcher Rolle zugewiesen ist, wird im Power BI Service verwaltet

Werden diese beiden Schichten nicht richtig verbunden, sieht der Nutzer entweder gar keine Daten oder er greift auf Daten zu, für die er keine Berechtigung hat.

02. Statisches RLS: einfach, aber nicht skalierbar

Beim statischen RLS wird für jede Rolle der DAX-Filter von Hand definiert. Zum Beispiel:

• Für die „Marmara-Rolle“: [Region] = "Marmara"
• Für die „Ege-Rolle“: [Region] = "Ege"
• Für die „Istanbul-Händler-Rolle“: [Region] = "Marmara" && [Stadt] = "Istanbul"

Dieser Ansatz funktioniert bei wenigen Rollen (2–5), doch bei 20+ Rollen wird die Verwaltung zur Hölle. Wird eine neue Region hinzugefügt, sind eine Modellaktualisierung und eine erneute Veröffentlichung nötig.

03. Dynamisches RLS: der skalierbare, richtige Ansatz

Beim dynamischen RLS wird eine einzige Rolle definiert, und der Filter arbeitet danach, wer der angemeldete Nutzer ist. Die Funktion USERPRINCIPALNAME() liefert die E-Mail des angemeldeten Nutzers. Dieser Wert wird mit einer Security-Tabelle namens „Benutzer“ abgeglichen:

• Benutzertabelle: [E-Mail], [Benutzername], [Region], [Händlercode], [Rolle]
• DAX-Filter (auf der Region-Dimension): [Region] IN CALCULATETABLE(VALUES(Benutzer[Region]), Benutzer[E-Mail] = USERPRINCIPALNAME())

Wird ein neuer Nutzer hinzugefügt, ändern Sie nicht das Modell; Sie fügen nur eine Zeile in die Benutzertabelle ein.

04. Das Design der Security-Tabelle

Das Herz des dynamischen RLS ist die Security-Tabelle. Eine gut gestaltete Security-Tabelle:

• zeigt die Nutzer-Zugriffs-Beziehung klar (ein Nutzer kann auf mehrere Regionen zugreifen)
• lässt sich mit den Haupt-Dimensionstabellen verknüpfen
• lässt Änderungen leicht verwalten (aus Excel, SharePoint oder SQL)
• unterstützt eine Rollenhierarchie (Geschäftsführer = alle Regionen)

Typische Umsetzung für die Geschäftsführer-Rolle: ein „*“-Symbol oder ein leer gelassenes Filterfeld in der Security-Tabelle; in DAX wird die Logik „falls * dann alles sichtbar“ verarbeitet.

05. Test- und Validierungsprozess

Nach der RLS-Umsetzung mit der Annahme „wir haben veröffentlicht, es funktioniert“ voranzugehen, ist gefährlich. Die Testschritte:

• Vorschau für jede Rolle über das Feature „View as roles“ in Power BI Desktop
• Live-Test durch Anmeldung mit verschiedenen E-Mail-Konten im Service
• Es sollte bestätigt werden, dass sich der Gesamtwert im Bericht je Nutzer ändert
• Es sollte bestätigt werden, dass null Zeilen angezeigt werden, wenn der Nutzer einen Filter auf eine berechtigungsfremde Dimension anwendet
• Der Performanceeinfluss sollte gemessen werden (eine Abfrage mit RLS kann 10–30 % langsamer sein als eine ohne)

06. Der Unterschied zu Object-Level Security (OLS)

RLS verbirgt Zeilen, aber alle Spalten sind sichtbar. In manchen Szenarien ist ein spaltenbasiertes Verbergen nötig: etwa dass nur die Personalabteilung die Gehaltsspalte in der Lohntabelle sieht. Für diesen Bedarf wird Object-Level Security (OLS) verwendet.

OLS wird mit einem externen Werkzeug wie dem Tabular Editor definiert; in Power BI Desktop gibt es dafür noch keine Oberfläche. In Enterprise-Szenarien werden RLS + OLS gemeinsam eingesetzt: zeilenbasierte Berechtigung + rollenbasiertes Verbergen sensibler Spalten.

07. Häufige Fallen

Häufige Fehler bei der RLS-Umsetzung:

• Das Ergebnis von USERPRINCIPALNAME stimmt nicht 1:1 mit der E-Mail in der Benutzertabelle überein (Groß-/Kleinschreibung, Leerzeichen)
• Die Security-Tabelle über eine bidirektionale Beziehung anbinden: Die Performance bricht ein
• RLS in einem Composite-Modell (DirectQuery + Import gemischt) ohne Test veröffentlichen
• Den Excel-Export vergessen: Aus dem Bericht nach Excel exportierte Daten folgen dem RLS-Filter, aber ein direkter DB-Zugriff des technischen Teams umgeht RLS
• In Template-Berichten RLS nach der Service-Veröffentlichung nicht neu definieren