RLS – Sicherheit auf Zeilenebene in Power BI

Nun ist ein Unternehmen oft in Bereiche und Abteilungen unterteilt, die jeweils einen Leiter haben. Weiterhin kann es Gruppen mit ihren jeweiligen Leitern geben und schließlich die Gruppenmitglieder selbst. Die verschiedenen Mitarbeiter haben dabei auch unterschiedliche Berechtigungen auf die Unternehmens- bzw. personenbezogenen Daten.
Wenn nun mit Power BI Berichte für das Unternehmen bzw. die Mitarbeiter erstellt werden sollen, ist dies ein Anlass, sich mit den Berechtigungen für diese Berichte zu beschäftigen.

Das Beispiel-Szenario

Wir gehen beispielhaft von folgendem Szenario aus: In einem Power-BI-Bericht werden Zahlen dargestellt und analysiert, die jeden Mitarbeiter betreffen. Allerdings ist auch nur der betreffende Mitarbeiter berechtigt, seine eigenen Daten einzusehen. Ausnahmen bilden die jeweiligen Gruppen- und Abteilungsleiter. Diese dürfen auch die Daten ihrer Mitarbeiter einsehen. Es entsteht also eine hierarchische Rechte-Struktur. Abbildung 1 soll dies verdeutlichen.

Der Bereichsleiter (BL) hat somit das Recht, die Daten aller Abteilungsleiter (AL), Gruppenleiter (GL) und Mitarbeiter (MA) einzusehen, was mit der schwarzen Ellipse angedeutet ist. Der AL wiederum kann die Daten seiner Mitarbeiter einsehen (blaue Ellipse). Ebenso verhält es sich mit GL und dem MA, der nur seine eigenen Daten einsehen darf. Der grüne Pfad wird später bei der Umsetzung der hier eigentlich thematisierten RLS (Row Level Security), also Sicherheit auf Zeilenebene, noch relevant.
Soviel zu dem Rechte-Szenario, das nun für den Power BI Bericht umgesetzt werden soll.

RLS – Sicherheit auf Zeilenebene

Es könnten nun Berichte erstellt werden, die auf die Mitarbeiter zugeschnittene Filter beinhalten und an diese verteilt werden können, damit die entsprechenden Berechtigungen eingehalten werden. Dies ist allerdings, je nach Mitarbeiterzahl, mit sehr hohem Aufwand verbunden. Glücklicherweise können die Berechtigungen aber auch in einem einzigen Bericht aufgrund des Datenmodells umgesetzt werden. Somit ist die Wartung nur für einen Bericht nötig.
Sicherheit auf Zeilenebene bedeutet, dass für jede Zeile des zugrunde liegenden Datasets die Berechtigung für die Mitarbeiter gesetzt wird und dementsprechend angezeigt wird oder nicht. Welche Datenzeilen angezeigt und welche herausgefiltert werden sollen, wird über die Anmeldung im Power BI Dienst festgesetzt.
Um dies aufgrund der Daten umsetzen zu können, muss das Datenmodell aber auch die hierarchische Struktur des Unternehmens darstellen. Die einfachste Lösung dafür ist, in der im Dataset eingebundenen Mitarbeitertabelle eine Spalte „Vorgesetzter" zu verwenden. Wenn diese in der Datenstruktur des Unternehmens noch nicht vorhanden ist, müsste sie in Power BI selbst umgesetzt werden, damit die vorliegende Lösung funktioniert. Im einfachsten Fall ist die Beziehung zwischen Mitarbeiter und dessen Vorgesetzten über die Mitarbeiternummer des Vorgesetzten darzustellen.

Umsetzung der RLS im Power-BI-Bericht

Abbildung 2 zeigt beispielhaft Zeilen der Mitarbeitertabelle des Power-BI-Datenmodells.

Einem Mitarbeiter sind damit eine Nummer und eine Vorgesetztennummer zugeordnet. Die vierte Spalte muss manuell über einen DAX-Ausdruck (Data Analysis Expression) hinzugefügt werden und stellt die Umsetzung des in Abbildung 1 gezeigten grünen Pfades dar. Nun hat KAL den Mitarbeiter KBL als Vorgesetzten, wodurch KGL nicht nur KAL als Vorgesetzten hat, sondern auch indirekt KBL. Dementsprechend tauchen KBL, KAL und KGL in der Spalte „Pfad_Vorgesetzte" von KMA auf.
Meldet sich KBL in Power BI an, so werden alle Zeilen angezeigt, in denen die 1 (eigene MA_NR) in der Spalte „Pfad_Vorgesetzte" vorkommt. Dies wären in diesem Beispiel alle Zeilen. KGL würde nur die letzten beiden Zeilen sehen können und KMA somit nur die letzte, also seine eigene. Dies ist im Grunde auch schon die theoretische Lösung des Problems.

In der Praxis werden dafür wie schon erwähnt DAX-Ausdrücke verwendet. Die neue Spalte „Pfad_Vorgesetzte" wird mit folgendem DAX-Ausdruck erstellt (Tabellenname ist „worker"):
Pfad_Vorgesetzte = PATH('worker'[MA_NR],'worker'[Vorgesetzter_NR])

Mit diesem Ausdruck wird mit der Funktion PATH() automatisch von Power BI überprüft, wer wen als Vorgesetzten hat, und dies wird als Pipe-separierte Liste in der jeweiligen Zeile dargestellt, bzw. gespeichert. Dabei hat die Funktion PATH() die beiden Spalten „MA_NR" und „Vorgesetzter_NR" als Input.
Um nun nach der Anmeldung im Power-BI-Dienst die richtige Filterung umsetzen zu können, muss eine sogenannte Rolle erstellt werden. Diese beinhaltet einen weiteren DAX-Ausdruck zum Filtern. Da im vorliegendem Beispiel dynamisch überprüft wird, wer angemeldet ist und anhand dessen gefiltert wird, wird das Vorgehen auch als „dynamische RLS" bezeichnet. Bei einer statischen RLS würde nicht überprüft werden, wer sich im Dienst angemeldet hat. Somit müssten mehrere Berichte mit entsprechendem Filter erstellt werden.
Doch nun zurück zu dem Filter-Ausdruck für die dynamische RLS.
In Power BI Desktop, der lokalen Erstellungssoftware für Power-BI-Berichte, muss nun über den Button „Rollen verwalten" eine neue Rolle erstellt werden. Dieser Rolle wird im nächsten Schritt ein Filter auf einer Tabelle als DAX-Ausdruck hinzugefügt. In vorliegendem Beispiel ist dies die Tabelle „worker". In Abbildung 3 ist der Vorgang dargestellt.

Im Folgenden nochmals der DAX-Ausdruck des Tabellenfilters aus Abbildung 3:

PATHCONTAINS('worker'[Pfad_Vorgesetzte],
    MinX(
        Filter('worker', [MA_Kuerzel]=[Kuerzel]),
        'worker'[MA_NR]
    )
)
 

Das Herzstück des Ausdrucks ist die Funktion Filter(). Diese filtert bzw. vergleicht die in der Tabelle "worker" ebenfalls vorhandene Spalte „MA_Kuerzel" mit dem Measure „Kuerzel" (Berechnung in Power BI – manuell erstellt). Das Measure „Kuerzel" ist durch den DAX-Ausdruck

Kuerzel = LEFT(USERPRICIPALNAME(), (IFERROR(SEARCH("@", USERPRINCIPALNAME()), BLANK()))-1)

definiert und gibt das Kürzel des angemeldeten Mitarbeiters zurück. Dieses wird mithilfe der Funktion USERPRINCIPALNAME() aus der eindeutigen E-Mail-Adresse extrahiert, mit der sich die Mitarbeiter im Power-BI-Dienst anmelden.
Da das System nun das Kürzel des angemeldeten Mitarbeiters mit dem im Dataset gespeicherten Kürzel vergleichen kann, können durch die Filter-Funktion alle nicht benötigten Zeilen herausgefiltert werden. Somit ist der angemeldete Mitarbeiter identifiziert und über die Funktion MinX() kann die Mitarbeiternummer der gefilterten Zeile zurückgegeben werden. Diese wird anschließend in der Funktion PATHCONTAINS() verwendet.
PATHCONTAINS() überprüft nun in jeder Zeile des Datasets den Inhalt der Spalte „Pfad_Vorgesetzte". Alle Zeilen, in denen die selektierte Mitarbeiternummer nicht vorhanden ist, werden herausgefiltert, und es bleiben lediglich die Zeilen sichtbar, die für den angemeldeten Mitarbeiter sichtbar sein sollen.

Letzter wichtiger Schritt

Damit der gesetzte Filter auf Zeilenebene auch seine Arbeit richtig erledigen kann, ist noch ein weiterer Schritt nötig, da sonst für alle Mitarbeiter nur leere Visuals im Bericht sichtbar wären.
Sobald der Bericht im Power-BI-Dienst veröffentlicht wurde, muss dort in den Einstellungen für das Dataset noch jeder Mitarbeiter, der den Bericht auch tatsächlich sehen können soll, der Sicherheitsrolle zugewiesen werden (in Power BI Desktop erstellt – siehe Abbildung 3). Dies kann bei vorhandenen Microsoft-Gruppen auch vereinfacht über diese geschehen.

Damit werden dem angemeldeten Mitarbeiter bei Betrachtung des Berichtes im Power-BI-Dienst nur Daten angezeigt, für die er auch berechtigt ist.

In Kürze zusammengefasst

Das vorgestellte RLS-Vorgehen kann für einen Power-BI-Bericht eingesetzt werden, der innerhalb eines hierarchisch aufgebauten Unternehmens von allen Mitarbeitern gelesen werden soll. Die Berechtigung, seine eigenen und als Vorgesetzter auch die Daten seiner Mitarbeiter einzusehen, ist dabei direkt auf Datenebene verankert. Durch das Kürzel des angemeldeten Mitarbeiters werden dann die richtigen Filter gesetzt.
Die Umsetzung weiterer Berechtigungsszenarien ist durchaus möglich, kann unter Umständen allerdings auch etwas komplexer ausfallen.
Da RLS vom Autor des Berichtes gut getestet werden kann und Power BI für den Eigengebrauch und zu Testzwecken auch kostenlos verwendbar ist, bleibt nur noch zu sagen: Probiert es selbst aus!