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 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Wie Du mit dynamischer Row Level Security in Power BI den Zugriff auf Deine Daten schützt erschien zuerst auf THE SELF-SERVICE-BI BLOG.

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

RLS ist nicht für jedes Szenario anwendbar. Dies hat mein vorangegangener Beitrag gezeigt. Sollte RLS für Dich jedoch in Frage kommen, kannst Du zwischen statischer und dynamischer RLS wählen. Der aktuelle Beitrag zeigt Dir, wie Du statische RLS für Dich umsetzen kannst.

So funktioniert «statische Row Level Security»

Um Row Level Security zeigen zu können, benötige ich ein Datenmodell. Meines ist für den Demo-Zweck sehr einfach gehalten.

Datenmodell und Report

Für den Demo-Zweck habe ich ein sehr einfaches Datenmodell erstellt. Es besteht aus zwei Tabellen:

• Tabelle Kosten: Diese enthält die Kosten je Bereich.
• Tabelle Organisationsstruktur: Diese enthält die Organisationsstuktur, bestehend aus dem Unternehmen selbst (U01) und den beiden Bereichen B01 und B02

Basierend auf diesem Modell, erstelle ich folgende Visualisierung, die die Kosten entlang der Organisationsstruktur darstellt:

Das Ziel ist es, den Leiter des Bereiches B01, auch nur dessen Daten sehen zu lassen und die gleiche Logik auch auf Bereich B02 anzuwenden. Der Geschäftsführer des Unternehmens soll jedoch alles sehen dürfen. Um dies zu bewerkstelligen, definiere ich sog. Rollen in Power BI Desktop. Das schauen wir uns jetzt an.

Definieren von Rollen in Power BI Desktop

Um Rollen in Power BI Desktop zu definieren, gehe auf den Reiter Modellierung und klicke auf die Schaltfläche Rollen verwalten.

Es öffnet sich ein Dialogfenster, in welchem die Rollen erstellt, benannt und definiert werden können. Hierfür gehe ich wie folgt vor:

1. Erstelle eine neue Rolle
2. Gib dieser Rolle einen sprechenden Namen
3. Mit einem Rechtsklick auf die entsprechende Tabelle (in meinem Fall Organisationsstruktur) öffnet sich das Kontextmenü zum Erzeugen eines Filters. Dieser Filter wird auf Basis einer Spalte der ausgewählten Tabelle erzeugt. Diese Spalte wählst Du hier zunächst aus, bevor wir im nächsten Schritt den Filter als wahrheitswertigen Ausdruck mittels DAX definieren.

Der definierte DAX-Ausdruck [Bereich] = "B01" definiert die Rolle Bereich01 derart, dass bei derjenigen Person, die sich im Power BI Service anmeldet und dieser Rolle zugeordnet wurde, automatisch folgendes Filterszenario abspielt (siehe Abbildung):

• Im Datenmodell wird ein Filter auf die Spalte Organisationsstruktur[Bereich] = „B01“ gesetzt.
• Über die Beziehung zwischen den Tabellen Organisationsstruktur und Kosten fließt der Filter des Bereiches B01 in die Tabelle Kosten, deren Datensätze automatisch auf jene eingeschränkt werden, die zum Bereich B01 gehören.

Auf diese Weise kann ein Nutzer mit der Rolle Bereich01, nur Werte aus dem Bereich B01 sehen. Die Auswirkung der entsprechenden Rolle läßt sich in Power BI Desktop testen. Ich zeige Dir wie das funktioniert.

Testen der Rollen in Power BI Desktop

Wie bereits beschrieben, greift Row Level Security erst im Power BI Service. Sofern ich eine Power BI Desktop-Datei verteile und ein Kollege öffnet diese, wird er/ sie immer alle Daten sehen können. In Power BI Desktop wird RLS zwar definiert, aber sie hat hier keine datenschützende Funktion. Diese gibt es erst im Power BI Service. Ich werde nicht müde zu erwähnen, dass Power BI Desktop eine Entwicklungsumgebung ist und kein Reporting-Tool 😉 Dennoch kann man in Power BI Desktop simulieren, man wäre mit der entsprechenden Rolle im Power BI Service angemeldet. So kann ich sehen, wie sich die Rolle auswirkt. Hierfür gibt es die Schaltfläche Modellierung → Als Rollen anzeigen.

Die Testergebnisse der Rollen (ich habe mittlerweile die Rollen Bereich01, Bereich02 und Geschaeftsfuehrung definiert) sehen wie folgt aus:

Die Vorgehensweise im Power BI Service (powerbi.com)

Damit die in Power BI Desktop definierte Row Level Security im Power BI Service zum Tragen kommt, muss ich den entsprechend definierten Rollen diejenigen Mitarbeiter meines Unternehmens zuordnen, die diese Daten sehen können sollen. Ist ein Mitarbeiter keiner Rolle zugeordnet, sieht er/ sie auch keine Daten.

Zuordnen von Nutzern zu Rollen im Power BI Service

Row Level Security ist eine Eigenschaft des Datasets (1). Deshalb befindet sich die Möglichkeit, Mitarbeiter Rollen zuzuordnen im Bereich der Datasets, unter dem Punkt Sicherheit (3).

Nachdem ich den Punkt Sicherheit ausgewählt habe, gelange ich in den Bereich, in welchem ich den erstellten Rollen die entsprechenden Mitarbeiter zuordnen kann.

Ich aktiviere die gewünschte Rolle und gebe im Bereich Mitglieder manuell diejenigen Kollegen mit ihren E-Mailadressen ein, die Zugriff auf die Daten hinter den Rollen haben sollen. Mitarbeiter können mehreren Rollen gleichzeitig zugeordnet werden. Zu beachten ist hierbei, dass falls ein Mitarbeiter mehreren Rollen gleichzeitig zugeordnet ist, dieser Mitarbeiter dann immer Zugriff auf die Obermenge der zugewiesenen Rollen hat. Hat ein Mitarbeiter beispielsweise Berechtigung für die Rollen Bereich01 und Geschaeftsfuehrung, so hätte er automatisch die Berechtigung für das gesamte Unternehmen, weil Bereich01 eine Teilnehme der Rolle Geschaeftsfuehrung ist.

Nachdem der Rolle Bereich01 der Mitarbeiter Max Mustermann zugeordnet wurde, erhöht sich hinter der entsprechenden Rollenbezeichnung (in meinem Beispiel Bereich01) der Zähler. Mit einem Klick auf Speichern ist die erste Zuordnung eines Mitarbeiters zu einer Rolle definiert.

Die Auswirkungen dieser Definition lassen sich nun am besten prüfen, indem wir uns ansehen, was Mitarbeiter Max Mustermann sehen kann, wenn er sich im Power BI Service anmeldet und diesen mit ihm geteilten Report betrachtet.

Die Auswirkungen von RLS beim Report-Empfänger

Meldet sich Max Mustermann bei Powerbi.com mit seiner Firmen-E-Mailadresse an, dann erkennt der Power BI Service, welchen Rollen er zugeordnet wurde. Ich hatte ihm die Rolle des Bereich01 zugeordnet, folglich sieht der geteilte Report bei Max Mustermann wie folgt aus:

Die Zuweisung von Mitarbeitern zu Rollen lässt sich auf einfache Art und Weise anpassen. Ich, in meiner Rolle als Dataset-Besitzer, melde mich in meinem Account von powerbi.com (nicht Max Mustermann!!!) an und gehe wieder in die Sicherheitseinstellungen des Datasets. Um Max Mustermann wieder aus der Rolle Bereich01 zu entfernen, klicke ich neben Max Mustermann auf das x (1) und speichere (2) anschließend.

Diese Einstellung hat dann zur Folge, dass Max Mustermann innerhalb dieses Reports keine Daten mehr sieht, weil er nun keiner Rolle mehr zugeordnet ist.

So viel zum Thema statische RLS. Beim nächsten Mal zeige ich Dir, wie Du das Ganze dynamisch handhabst, falls Du viele unterschiedliche Rollen und viele Mitarbeiter zu bewältigen hast.

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 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Wie Du mit statischer Row Level Security in Power BI den Zugriff auf Deine Daten schützt erschien zuerst auf THE SELF-SERVICE-BI BLOG.

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

Warum ein Berechtigungskonzept für den Zugriff auf Daten?

Daten sind das Gold des 21. Jahrhunderts und die meisten Unternehmen versuchen ihre Daten vor unbefugtem Zugriff zu schützen. „Unbefugt“ gilt hierbei nicht nur für Menschen außerhalb des Unternehmens, sondern auch im Hinblick darauf, dass jeder Mitarbeiter nur diejenigen Daten sehen soll, die für seine Arbeit auch tatsächlich notwendig sind. Sieh Dir die folgende Abbildung an. In der dargestellten Faktentabelle sind Kosten je Team dargestellt. Ein entsprechend aufbereitetes Berechtigungskonzept würde die Datensätze in Reports und Dashboards für Ditmar Pfeiffer (Team 1) auf die des Teams 1 beschränken. Heike Stark (Abteilung 1) könnte alle Daten für die Teams 1 und 2 sehen. Karsten Müller, der den Bereich 1 verantwortet, hätte folglich die Berechtigung, auf alle Daten der Abteilungen 1 und 2, inklusive der darunter befindlichen Teams einzusehen.

Schutz der Unternehmensdaten durch die Zugriffsbeschränkung auf notwendige Datensätze, ist der Sinn eines Berechtigungskonzeptes. Doch wie läßt sich ein solches Konzept mit Power BI umsetzen? Die Antwort lautet: Row Level Security, oder kurz RLS!

Was ist Row Level Security (RLS)?

Row Level Security ist die technische Möglichkeit, den Zugriff innerhalb von Power BI auf Datensatzebene , d. h. Zeilenebene, auf befugte Mitarbeiter zu beschränken. Ein solches Berechtigungskonzept wird in Power BI Desktop definiert, findet allerdings zum gegenwärtigen Zeitpunkt ausschließlich Anwendung im Power BI Service. Für den Power BI Report Server steht diese Möglichkeit noch aus. Wichtig zu verstehen ist, dass es keine Zugriffsbeschränkung auf Datensatzebene in Power BI Desktop gibt. Erhält jemand eine pbix-Datei, stehen ihm/ ihr immer alle Daten uneingeschränkt zur Verfügung. Power BI Desktop ist die Entwicklungsumgebung für die Power BI Platform, kein Reporting-Tool! Wurde ein Datenmodell mit bestehender RLS in den Service hochgeladen, kann über das hinterlegte Berechtigungskonzept abgeglichen werden, welche Daten dieser Mitarbeiter, der sich mit seinen Nutzerdaten anmelden und somit identifizieren musste,  sehen darf. Alle Daten, für die diese Person nicht berechtigt wurde, werden auch nicht angezeigt. Existiert für diesen Nutzer gar keine Berechtigung, Daten zu sehen, sieht er/ sie in entsprechenden Reports und Dashboards nur leere Visualisierungen.

Da es verschiedene Typen von RLS gibt, gehe ich nun auf diese und deren wesentliche Unterschiede ein. In weiteren Beiträgen werde ich dies deutlich ausführlicher beschreiben. Mein Ziel für den aktuellen Beitrag ist es, einen Überblick und ein grundlegendes Verständnis für das Thema zu schaffen.

Verschiedene Typen von Row Level Security

Um Row Level Security einzurichten, gibt es zwei unterschiedliche Varianten: die statische und die dynamische Row Level Security.

Statische RLS

Die statische Row Level Security macht es erforderlich, dass in Power BI Desktop (häufig viele) Rollen definiert werden, denen dann im Power BI Service manuell Personen zugeordnet werden können. So kann ich beispielsweise alle Daten meines Datenmodells, die in den Ländern Dänemark, Schweden und Norwegen erhoben wurden, der Rolle Skandinavien zuordnen. Im Power BI Service bin ich dann in der Lage, entsprechende Mitarbeiter, die für Skandinavien zuständig sind, dieser Rolle manuell zuzuordnen. Hierbei kann ich auch auf Azure Active Directory Groups zurückgreifen, falls ich nicht jeden Mitarbeiter einzeln zuordnen möchte. Sofern die Mitarbeiter lediglich dieser einen Rolle zugeordnet wurden (es könnten auch mehrere Rollen parallel sein) wären sie ausschließlich in der Lage, Werte aus Skandinavien zu sehen. Dies ist für Szenarien mit wenigen Rollen (z. B. eine Rolle je Kontinent) sehr gut umsetzbar.

Jetzt stell Dir bitte vor, Du arbeitest für ein Handelsunternehmen, das mit mehreren 100 Produktgruppen handelt. Mitarbeiter aus Einkauf und Marketing sollen nur diejenigen Produktgruppen sehen, für die sie zuständig sind. Du müßtest wahrscheinlich sehr viele Rollen anlegen (z. B. Rolle Elektroartikel) und im Service stets pflegen, welcher Mitarbeiter welche Rolle(n) sehen darf. Das kann schnell sehr unübersichtlich werden und birgt stets die Gefahr, dass Daten in die falschen Hände geraten. Deshalb entscheidet man sich in einem solchen Szenario für die dynamische Row Level Security.

Dynamisch RLS

Auch bei der dynamischen Row Level Security erfolgt im Power BI Service die Zuordnung des Mitarbeiters (oder Azure Active Directory Security Groups) zu Rollen, aber ich benötige hier im Idealfall nur noch eine einzige Rolle, weil die Aufgabe der Rollen durch das Datenmodell übernommen wird. Auf diese Weise wird es beispielsweise möglich, Tabellen zu pflegen, die die Zuordnung von Mitarbeitern zu Gruppen (z. B. Abteilungen, Teams, Produktengruppen) beinhalten. Der Power BI Service erkennt dann automatisch über Anmeldung des Nutzers, für welche Datensätze dieser berechtigt ist. Der große Vorteil dieser RLS-Variante ist, dass die Zuordnung des Nutzers zu seinen relevanten Daten durch das Datenmodell definiert ist und nicht durch die (aufwändige) Definition von Rollen. Tabellen, die diese Zuordnung definieren, können beispielsweise aus HR-Systemen automatisert übernommen und via Power Query ins Datenmodell integriert werden. Wie das geht, werde ich im Laufe dieser Beitragsserie zeigen.

Nach dieser kurzen Vorstellung der RLS-Typen, hast Du vielleicht eine Idee, für welchen von beiden Typen Du Dich in Deinem Szenario entscheiden würdest. Bevor Du das jedoch tust, hier noch ein kurzer Exkurs, wann RLS überhaupt in Power BI zur Verfügung steht.

Wann steht RLS zur Verfügung?

Ob RLS zur Verfügung steht, ist von einigen Faktoren abhängig, auf die ich jetzt eingehen werde.

Ort der Anwendung

RLS kann, wie weiter oben schon erwähnt, gegenwärtig nur im Power BI Service genutzt werden. RLS funktioniert nicht (und wird es hoffentlich auch nie) in Power BI Desktop. Gegenwärtig ist RLS noch nicht im Power BI Report Server vorhanden, wurde aber bereits für Anfang 2019 angekündigt.

Lizenzen

RLS ist nur interessant, wenn ich im Power BI Service Reports/ Dashboards und/oder Datasets mit anderen teilen möchte. Für mich alleine muss ich schließlich kein Berechtigungskonzept einrichten. Teilen ist in Power BI ein sog. Pro-Feature, d. h. es erfordert eine Power BI Pro-Lizenz. Dies ist sowohl für den Reportsender, als auch für den Empfänger notwendig.

Bist Du im glücklichen Umstand, dass in Deinem Unternehmen, zusätzlich zu (mindestens einer) Power BI Pro-Lizenz auch Power BI Premium vorhanden ist, dann stellt sich das Szenario mit dem Teilen etwas anders dar: Sofern sich meine Inhalte in einem App-Workspace (App-Arbeitsbereich) in einer Premium-Kapazität befinden, bin ich in der Lage, diese Inhalte auch mit Nutzern einer kostenlosen Free-Lizenz zu teilen. Eine sinnvolle Frage wäre an dieser Stelle, ob auch beim Vorhandensein von Power BI Premium der Berichtsempfänger, bei dem RLS greifen soll, eine Pro Lizenz benötigt, oder ob dafür die Free-Lizenz ausreichend ist? Die Antwort ist: RLS ist kein Pro Feature, sondern das Teilen von Daten ist eines. RLS kann somit im Falle von Power BI Premium auch mit Nutzern einer Free-Lizenz verwendet werden.

ACHTUNG: Auch wenn ich die RLS in meinem Modell korrekt aufgesetzt und im PBI Service die entsprechenden Mitarbeiter ihren Rollen zugeordnet habe, gibt es eine kleine „Falle“, die dafür sorgen kann, dass die Mitarbeiter trotzdem alle Daten einsehen können.

Sofern ich meine Daten über einen App-Workspace teile, kann ich diesem Workspace unter Arbeitsbereich bearbeiten (3) Mitlieder hinzufügen. Hierbei kann ich wählen, ob diese Mitglieder Inhalte nur anzeigen (2) oder auch bearbeiten können (1):

Sofern ich Mitgliedern hier das Recht einräume, Inhalte auch zu bearbeiten, greift die Row Level Security nicht mehr. Hierbei reicht es, dem betreffenden Kollegen den Status Mitglied zuzuordnen. Er muss kein Admin sein und trotzdem kann er alle Daten sehen und nicht nur diejenigen, die ihm laut RLS zugewiesen sind. Beachte das unbedingt, wenn Du RLS im Unternehmen integrierst!

Verbindung zur Datenquelle

Ein weiterer wichtiger Punkt für die Möglichkeit, RLS zu nutzen, ist die Verbindung zur Datenquelle. Power BI unterstützt hier:

• Importierte Daten,
• Datenquellen, zu denen die Verbindung via DirectQuery aufgenommen wurde.

Eine Ausnahme stellen hierbei Liveverbindungen (Live Connection) z. B. zu den SQL Server Analysis Services (SSAS), oder auch zum Power BI Service dar, da diese Datenquellen ein eigenes Berechtigungskonzept beinhalten, das eins zu eins durchgereicht wird. Hier besteht keine Möglichkeit, es durch RLS in Power BI Desktop zu übersteuern.

Einschränkungen durch Row Level Security

Row Level Security bringt zum gegenwärtigen Zeitpunkt auch Einschränkungen mit sich, derer man sich bewußt sein sollte, bevor man beginnt, RLS in sein Modell zu integrieren. Die Wesentlichen sind:

• Q&A steht im Falle von RLS nicht zur Verfügung. Willst Du Q&A also unbedingt in Deinem Modell nutzen, kannst Du keine RLS integrieren.
• Es können dem Modell maximal 1.000 Nutzer oder Sicherheitsgruppen zugeordnet werden. Sollte das für Dein Szenario nicht ausreichen, kannst Du RLS derzeit nicht nutzen.

Da sich diese Einschränkungen schnell ändern können, empfehle ich diesen Artikel zu konsultieren, bevor Du mit RLS in Deinem Modell beginnst.

Das war viel Theorie, aber mir ist wichtig, dass gleich zu Beginn klar ist, wofür RLS gut ist, welchen Typ man für das eigene Szenario wählen sollte, und ob damit verbundene Einschränkungen eventuell die Nutzung von RLS verhindern. In den nächsten Beiträgen geht es dann an die technische Umsetzung von Row Level Security in Power BI 🙂

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 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Allgemeine Einführung in Row Level Security in Power BI erschien zuerst auf THE SELF-SERVICE-BI BLOG.