Row-Level Security in Power BI: Berichtszugriff sauber trennen

In einem Banktresor können Dutzende Schließfächer im selben Raum stehen, doch der Schlüssel eines Kunden öffnet nur sein eigenes Fach. Ein Power BI Bericht kann nach einer ähnlichen Logik funktionieren: Menschen öffnen dieselbe Seite, sehen aber unterschiedliche Datenzeilen. Dafür sorgt Power BI Row Level Security (RLS) — ein Mechanismus, der den Zugriff auf Daten abhängig von der Rolle oder dem Benutzerkonto einschränkt.

Was ist Row-Level Security in Power BI?

Kurz auf die Frage geantwortet, was RLS in Power BI ist: ein Mechanismus, der festlegt, welche Zeilen des Datenmodells einem bestimmten Nutzer zur Verfügung stehen. Der Bericht selbst kann dabei ein einziger bleiben: Ein Regionalleiter sieht die Umsätze seiner Region, die Geschäftsführung die konsolidierten Kennzahlen.

Row Level Security in Power BI funktioniert über Rollen in Power BI und Filterregeln. Sie werden in Power BI Desktop erstellt, Nutzer oder Gruppen werden den entsprechenden Rollen dann in Power BI Service zugewiesen. Wenn ein Unternehmen Power BI für Unternehmen einsetzt, bestimmt RLS, welchen Datenausschnitt jeder Nutzer nach der Anmeldung erhält.

Wie funktioniert RLS in Power BI? Das System ermittelt die Rolle des Nutzers, wendet die entsprechende Regel an und gibt nur die erlaubten Zeilen zurück.

Warum Unternehmen RLS brauchen

Wenn ein Dashboard von der Geschäftsführung, von Managern und von einzelnen Abteilungen genutzt wird, benötigt nicht jeder den vollen Zugriff auf Power BI Berichte. Ohne RLS muss man entweder separate Versionen des Berichts erstellen oder einen größeren Datenumfang freigeben, als der jeweilige Nutzer braucht.

Mit RLS muss man nicht mehr einzelne Versionen eines Berichts nur wegen unterschiedlicher Nutzerrechte vervielfachen. Die Daten bleiben in einem Modell, und der verfügbare Ausschnitt wird durch die Rolle bestimmt. Zugriffsrechte in Power BI hängen nicht allein von RLS ab. Die Rechte im Power BI Arbeitsbereich und der Zugriff auf den Bericht selbst werden separat konfiguriert: RLS ersetzt diese Berechtigungsebenen nicht. Besonders wichtig ist die Einschränkung des Datenzugriffs in Power BI, wenn verschiedene Abteilungen mit einem Bericht arbeiten. Der Vertrieb braucht möglicherweise Kunden- und Regionskennzahlen, die Finanzabteilung die Margen und die Geschäftsführung das Gesamtbild. Allen den gleichen Zugriff zu geben, ergibt in so einer Situation einfach keinen Sinn.

Beispiel: Regionalleiter sehen nur ihre eigenen Daten

Am einfachsten lässt sich die Zugriffstrennung in Power BI an einer regionalen Struktur zeigen. Das Unternehmen hat einen Vertriebsbericht, doch jedem steht nur der benötigte Teil der Daten zur Verfügung:

Im Ergebnis pflegt der Analyst einen Bericht, und eine Änderung von Zahlen oder der Struktur einer Visualisierung erfordert kein Synchronisieren mehrerer Kopien. Genau deshalb sollte man bei der Einführung von Business Analytics auf Basis von Power BI die Zugriffslogik gemeinsam mit dem Datenmodell und den Nutzerrollen durchdenken.

Wie man RLS in Power BI einrichtet

Um zu verstehen, wie man RLS in Power BI einrichtet, genügen einige grundlegende Schritte:

In Power BI gibt es mehrere Zugriffsebenen. Power BI workspace permissions legen die Rechte eines Nutzers im Arbeitsbereich fest, Power BI report permissions den Zugriff auf einen konkreten Bericht. RLS wirkt auf Ebene des Datenmodells, das Ergebnis hängt aber auch von der Rolle des Nutzers im Arbeitsbereich ab. Die RLS-Einschränkungen gelten für Viewer, während Admin, Member und Contributor weitergehende Zugriffsrechte haben.

Statische Rollen

Statisches RLS in Power BI nutzt feste Regeln. Für die Rolle „Süd“ lässt sich zum Beispiel eine Bedingung definieren, die nur die Zeilen dieser Region behält; anschließend weist man der Rolle in Power BI Service die passenden Nutzer zu.

Diese Variante ist praktisch, wenn es wenige Segmente gibt, die Regeln stabil und leicht zu pflegen sind. Ändert sich die Zugriffsstruktur häufig, wächst die Zahl der statischen Rollen und manuellen Zuweisungen schnell an.

Dynamische Rollen auf Basis von Nutzerdaten

Beim dynamischen RLS in Power BI hängt die Regel davon ab, wer den Bericht geöffnet hat. Eine verbreitete Variante ist die Funktion USERPRINCIPALNAME(), die in Power BI Service die Nutzerkennung (UPN) zurückgibt, zusammen mit einer separaten Zuordnungstabelle, etwa „Nutzer → Region“.

Darauf baut dynamic row level security in Power BI auf: Für jede Region oder jeden Mitarbeiter eine eigene Rolle anzulegen, ist nicht nötig — der benötigte Ausschnitt wird über die Nutzerdaten bestimmt.

Reduziert man static vs dynamic RLS auf den praktischen Unterschied, liegt er in der Art, wie der Zugriff bestimmt wird:

Wenn Daten zu Zugriffsrechten bereits in Unternehmenssystemen liegen, muss die Datenfilterung nach Nutzer in Power BI nicht manuell gepflegt werden. In einer Data Platform für Unternehmen lässt sich die Zuordnungstabelle „Nutzer → Region“ zum Beispiel gemeinsam mit anderen Stammdaten aktualisieren.

Typische Fehler bei der Einrichtung von RLS

Am häufigsten liefert RLS aufgrund der Modell- oder Berechtigungskonfiguration ein falsches Ergebnis:

RLS in Power BI vs Datensicherheit in Microsoft Fabric

RLS in Power BI wirkt auf Ebene des Datenmodells und legt fest, welche seiner Zeilen einem Nutzer zur Verfügung stehen. Microsoft Fabric umfasst mehr Zugriffsebenen: Arbeitsbereiche, einzelne Plattformressourcen und die Daten selbst werden separat kontrolliert.

In Fabric ist RLS für die Filterung der Zeilen im Datenmodell zuständig. Der Zugriff auf Arbeitsbereiche, einzelne Plattformressourcen und weitere Datenebenen wird separat konfiguriert.

Wie IWIS Datensicherheit für Kunden einrichtet

In zwei Unternehmen mit gleich vielen Nutzern kann das RLS-Schema völlig unterschiedlich aussehen. In einem genügen einige stabile Rollen nach Regionen, in einem anderen hängt der Zugriff von Position, Abteilung, Kunde oder mehreren Bedingungen gleichzeitig ab. Deshalb erstellt das IWIS-Team zuerst eine Zugriffsmatrix und definiert erst darauf aufbauend statische oder dynamische Regeln und prüft sie gemeinsam mit den Berechtigungen des Arbeitsbereichs.