Eine einfache Variante, um Zugriffsberechtigungen in Power BI einzurichten, ist die statische Row Level Security (RLS), die ich in meinem letzten Beitrag erläutert habe. Sofern Dein Szenario jedoch viele unterschiedliche Rollen umfasst, ist die dynamische Row Level Security die deutlich bessere Wahl. Ich zeige Dir im aktuellen Beitrag, wie Du mit dynamischer Row Level Security in Power BI den Zugriff auf Deine Daten schützt und dabei das Anlegen der Rollen in das Datenmodell auslagerst. Viel Spaß 🙂

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

So funktioniert «dynamische Row Level Security» in Power BI

Wann Du Dich für die statische und wann für die dynamische Variante von RLS entscheiden solltest, habe ich im ersten Teil dieser Beitragsreihe bereits erwähnt. Grundsätzlich ist es bei der statischen RLS so, dass Du eine gewisse Anzahl an Rollen in der pbix-Datei definierst (z. B. die Rollen Vertriebsgebiet Nord, Süd, Ost und West) und dann im Power BI Service diesen Rollen die berechtigten Mitarbeiter mit ihrer Firmen-Emailadresse/  User Principal Name (UPN) zuordnest. Bei 10 Rollen und jeweils 10 Mitarbeitern, die für jede Rolle zugelassen werden sollen, ergeben sich im Power BI Service folglich 100 Zuordnungen zwischen Rollen und Mitarbeitern. Ziel der dynamischen Row Level Security ist, die Anzahl der Rollen möglichst auf eine Rolle zu reduzieren. Die Zuordnung der berechtigen Mitarbeiter auf diese eine Rolle ist im Power BI Service dennoch vorzunehmen. Habe ich  für ein Dataset RLS in Power BI Desktop definiert, haben Mitarbeiter, die nicht der entsprechenden Rolle im Power BI Service zugeorndet sind, auch keinen Zugriff auf die Daten des Datasets. In freigegebenen Berichten und Dashboards sehen sie dann nur leere Visualisierungen.

Die Zuordnung des Mitarbeiters zu den berechtigten Datensätzen steckt im Datenmodell

Kasper de Jonge hat auf seinem Dynamic Security Cheat Sheet eine Vorlage für das Modellieren von dynamischer RLS veröffentlicht, auf der mein hiesiger Beitrag beruhen wird. Diese Vorlage beinhaltet eine Erweiterung des Datenmodells um drei zusätzliche Tabellen. Ich zeige zunächst das veränderte Datenmodell und erläutere dann die Funktionsweise.

Das vorliegende Datenmodell besteht neben der Faktentabelle Kosten und der Dimensionstabelle Organisationsstruktur aus drei weiteren Tabellen: Group, UserGroup und Users. Diese Tabellen dienen allein der Implementierung der dynamischen RLS und sollten daher für den Endanwender ausgeblendet werden. Daher sind sie im dargestellten Screenshot ausgegraut. Die Bedeutung der zusätzlichen Tabellen und Beziehungen dieses Datenmodells erklärt sich wie folgt:

1. Tabelle Group: Beinhaltet eine unikate Auflistung der existierenden Unternehmens-Bereiche (B01 und B02). Diese kann aus der Tabelle UserGroup (2) abgeleitet werden.
2. Tabelle UserGroup: Beinhaltet eine Zuordnung des jeweiligen Users mit seiner Firmen-E-Mailadresse (UPN) zu den Bereichen, auf die er/ sie Zugriff haben soll. Dies ist quasi das Herzstück der dynamischen RLS. Diese Zuordnung muss bei jeder personellen Änderung gepflegt werden, damit die RLS auf dem aktuellen Stand bleibt. Dies kann beispielsweise auf Basis einer Organisationstabelle des Personalbereichs automatisiert erzeugt werden. Wie das funktioniert, werde ich im nächsten Beitrag zu dieser Serie zeigen.
3. Tabelle Users: Beinhaltet eine unikate Auflistung der vorhandenen User, auf Basis ihrer Firmen-Emailadresse (UPN). Diese kann aus der Tabelle UserGroup (2) abgeleitet werden.
4. Kreuzfilterrichtung auf beide (engl.: Bi-directional relationsship): Diese Beziehung muss auf bi-directional gestellt sein, damit der Filter von Tabelle Users über die Tabelle UserGroup auch die Tabelle Group filtern kann, was dann automatisch zur Filterung der Tabelle Kosten führt. Damit nicht nur der Filter, sondern auch die Weitergabe der Row Level Security über die Beziehung funktioniert, muss auch der Haken bei Sicherheitsfilter in beide Richtungen anwenden gesetzt werden.

 

Nachdem nun ein Verständnis für die notwendigen Änderungen im Datenmodell herrscht, machen wir uns jetzt an die Einrichtung der zentralen Rolle in Power BI Desktop.

Einrichten der zentralen Rolle in Power BI Desktop

Während ich im Beitrag zur statischen Row Level Security für die Bereiche B01 und B02 jeweils eine Rolle definiert und diesen beiden Rollen dann im Power BI Service die Mitarbeiter zugeordnet habe, erfolgt im aktuellen Beispiel lediglich die Definition einer zentralen Rolle. Dies ist möglich, weil über die neu hinzugefügte Tabellen UserGroup je Bereich (B01 und B02) definiert ist, welcher Mitarbeiter für welchen der beiden Bereiche berechtigt ist. Was jetzt noch fehlt, ist das Einrichten der Tabellenfilter für diese zentrale Rolle. Nur so gelingt es im Power BI Service, dass ein eingeloggter User ausschließlich diejenigen Datensätze sehen kann, für die er/ sie berechtigt ist. Dies geschieht, wie im folgenden Screenshot dargestellt.

 

Die verwendete DAX-Funktion USERPRINCIPALNAME() ermittelt im Power BI Service den Anmeldenamen des eingeloggten Users im Format user@domain. Mit dem ermittelten UPN werden die Einträge in der Tabelle Users abgeglichen und so der Filter auf die Daten in der Faktentabelle weitergeleitet. Auf diese Weise sieht der eingeloggte User ausschließlich die für ihn freigegebenen Daten.

Randbemerkung: Der UPN ist eine Eigenschaft von Azure Active Directory und dient der Authentifizierung des angemeldeten Nutzers. Um den Nutzer im Power BI Service via DAX zu ermitteln, können zwei Funktionen genutzt werden: USERNAME() und USERPRINCIPALNAME() Beide Funktionen liefern den eingeloggten User im Format user@domain zurück, sofern dies so in Azure Active Directory definiert wurde. Nun könnte die Frage aufkommen, warum gibt es zwei Funktionen für dasselbe Ergebnis? Die Antwort ist: Beide Funktionen liefern zwar im Power BI Service dasselbe Ergebnis zurück, ihre Ergebnisse unterscheiden sich jedoch beim Aufruf in Power BI Desktop (also auf der lokalen Maschine):

• USERNAME():
  • Lokale Maschine (Laptop/ PC): Gibt den angemeldeten Nutzer mit den Anmeldeinformationen zurück, mit denen er sich angemeldet hat. Bei mir ist dies LS-PC\LS
  • Power BI Service: Gibt den angemeldeten Nutzer mit den Anmeldeinformationen zurück, mit denen er sich angemeldet hat. Bei mir ist dies im Power BI Service larsschreiber@domain

 

• USERPRINCIPALNAME():
  • Lokale Maschine (Laptop/ PC): Liefert den Namen des Benutzers als dessen E-Mail-Adresse (UPN) zurück.
  • Power BI Service: Liefert den Namen des Benutzers als dessen E-Mail-Adresse (UPN) zurück.

Okay, beide Funktionen geben also im Power BI Service dasselbe Ergebnis und können somit beide für die Definition von RLS genutzt werden. Sie unterscheiden sich also nur beim Aufruf auf der lokalen Maschine, so zumindest die Theorie. Auf meinem Laptop geben trotzdem beide Funktionen den Wert LS-PC\LS zurück. Wieso das denn? Die Ursache hierfür liegt darin, dass ich auf meinem Laptop kein Azure Active Directory nutze. Daher ist mein UPN gleich meinem Anmeldenamen und beide Funktionen liefern dasselbe Ergebnis zurück. Lass Dich also nicht verwirren, wenn der eigentliche Nutzen der Funktion USERPRINCPALNAME(), nämlich auch auf der lokalen Maschine den UPN widerzugeben, nicht funktioniert.

Nach diesem Exkurs gehe ich jetzt auf die Nutzerzuordnung zur zentralen Rolle im Power BI Service ein.

Zuordnen von Nutzern zur zentralen Rolle im Power BI Service

Sofern für ein Dataset Row Level Security definiert ist, können lediglich diejenigen Nutzer auf das Dataset zugreifen, die auch mit Ihrer Emailadresse der definierten Rolle zugeordnet sind.

 

Die Zuordnung des Nutzers zur Rolle findet wie folgt statt:

 

Damit ist die Definition der dynamischen Row Level Security zumindest für diesen eine Person abgeschlossen. Sollen mehrere Personen auf diese Rolle zugreifen können, müssen auch diese Personen mit ihrem UPN hinzugefügt werden. Schauen wir uns die Funktionsweise der dynamischen RLS zum besseren Verständnis noch einmal an einem Beispiel an.

RLS im Einsatz verstehen

Okay, Du weißt jetzt , wie die dynamische RLS technisch definiert wird, aber ich möchte, dass Du wirklich verstehst, wie die nun gebaute Architektur tatsächlich funktioniert. Betrachten wir die Abläufe, wenn sich der Nutzer Max Mustermann mit seinem Account anmeldet.

Max Mustermann loggt sich bei powerbi.com ein

Max Mustermann loggt sich mit seiner Firmen-Emailadresse ein und aktiviert den Bericht, der auf dem Dataset beruht, für welches ich die RLS definiert habe. Die Funktion USERPRINCIPALNAME() ermittelt, wer der angemeldete User ist.

Da der Filter auf die Spalte Users[User] gesetzt wurde, wird diese Spalte nach Max.Mustermann@MeineDomain gefiltert. Der folgende Screenshot zeigt den Filterverlauf.

1. Die Funktion USERPRINCIPALNAME() ermittelt den UPN von Max Mustermann (Max.Mustermann@MeineDomain). Dadurch entsteht der Filter Users[User] = „Max.Mustermann@MeineDomain“.
2. Der Filter fließt von der Tabelle Users von der 1 zur n-Seite und filtert die Tabelle UserGroup auf UserGroup[User] = „Max.Mustermann@MeineDomain“. Hierbei kristallisiert sich heraus, dass Max Mustermann für den Bereich B02 berechtigt ist.
3. Durch das aktivieren einen bi-direktionalen Beziehung und der Aktivierung der Funktionalität, dass der Sicherheitsfilter ebenfalls in beide Richtungen fließen kann, kann der Bereichsfilter von der n- zur 1-Seite fließen.
4. Der Filter schränkt damit die Tabelle Group auf Zeilen mit Group[Bereich] = B01 ein.
5. B01 wird als Filter an die Faktentabelle weitergereicht und schränkt diese auf Datensätze ein, die dem Bereich B01 zugeordnet sind.

Auf diese Weise kann sichergestellt werden, dass der Nutzer Max Mustermann nur Werte für den Bereich B01 sehen kann. Der gewünschte Effekt der Row Level Security wurde erreicht.

Schlussüberlegung

Der vorliegende Beitrag hat gezeigt wie dynamische Row Level Security in ein bestehendes Datenmodell implementiert werden kann. Damit ist das Thema dynamische RLS jedoch noch nicht abgeschlossen, denn Unternehmen sind organische, sich verändernde Gebilde, in denen Mitarbeiter kommen und gehen. Diese Dynamik muss sich in der Pflege zweier Elemente wiederfinden:

• Den drei RLS-Tabellen Group, UserGroup und Users und
• Der Zuordnung der Mitarbeiter zur Rolle im Power BI Service.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂