Berechtigungen in Power BI: Teil 3 Row Level Security (RLS)

Publiziert von

In Teil 1 dieser Blogserie wurde die sogenannte Access Control in Power BI vorgestellt, wie also der Zugang zu einer PBI Anwendung geregelt wird. In Teil 2 wurden die Konfigurationsmöglichkeiten im Power BI Admin Portal vorgestellt.

In diesem abschließenden Teil 3 geht es um die sogenannte Row Level Security, also wie innerhalb einer PBI Anwendung die Sicht auf die Daten entsprechend den Berechtigungen des aktuellen Users eingeschränkt werden kann.

Wie funktioniert die Row Level Security?

RLS funktioniert wie ein ganz normaler Filter (“Row Filter”) auf den Datenbestand mit folgenden Besonderheiten:

  • Das Filterkriterium ist der angemeldete User (und dieser Filter kann natürlich nicht vom User beeinflußt oder aufgehoben werden).
  • Der Row Filter wirkt im einfachsten Fall auf die Elemente einer einzigen Spalte des Datenmodells (bspw. Country-Spalte), in fortgeschrittenen Szenarien kommen Filter auf verschiedene Spalten (alternativ oder additiv) des Datenmodells zum Einsatz.
  • Im einfachsten Fall hat jeder User nur ein  berechtigtes Element (bspw. Germany, France, usw.) und jedes Element nur einen einzigen Berechtigten, in fortgeschrittenen Szenarien sind many-to-many Beziehungen zwischen User und den Berechtigungselementen abzubilden.

Voraussetzungen und Rahmenbedingungen

Verfügbarkeit

  • RLS ist in Power BI Desktop/Service und SQL Server Tabular Model verfügbar, nicht aber in Power Pivot.
  • RLS ist auch in Verbindung mit der Funktion Analyze in Excel verfügbar.
  • RLS ist auch bei der Distribution über Power BI Embedded und SharePoint Online verfügbar.

Aktivierung

  • RLS wird durch die simple Anlage der ersten Rolle aktiviert (die Rolle muß kein DAX-Filterstatement enthalten).
  • Ab diesem Zeitpunkt sehen nur noch jene User Daten in den Reports, die explizit als Member einer Rolle zugewiesen sind. User, die keiner Rolle zugewiesen sind, können zwar den Report öffnen, sehen aber keine Daten mehr.

Zusammenspiel von RLS und Access Control

  • RLS wirkt ausschließlich im Power BI Service, in Power BI Desktop werden zwar die Rollen angelegt, die RLS wirkt dort aber noch nicht.
  • RLS wirkt im Power BI Service nicht für den Administrator eines Workspaces. Da jeder User im eigenen My Workspace die Admin Role innehat, kann ein User im eigenen My Workspace die RLS nicht mit dem eigenen Account testen. Gleiches gilt für jeden User mit der Admin Role in einem App-Workspace. Für die Members eines App-Workspaces wird die RLS nur wirksam, wenn der App-Workspace mit der Option Members can only view Power BI content definiert wurde (die Edit-Berechtigung am App-Workspace neutralisiert also ebenfalls die RLS).
  • Für die End User („Empfänger“) einer App oder einer Sharing-Einladung wirkt die RLS immer, es sei denn, diese haben gleichzeitig eine Admin Role oder eine Edit Role im App-Workspace inne.

Einschränkungen

  • Es werden ETL- und DirectQuery-Verbindungen unterstützt, Live-Connections zu Analysis Services werden im lokalen Modell verarbeitet (das ist auch sinnvoll so).
  • RLS unterstützt derzeit weder Q&A noch Cortana. Das Q&A-Eingabefeld wird nicht angezeigt, wenn für eine Anwendung RLS aktiviert ist.
  • Die externe Freigabe wird zurzeit nicht für Anwendungen unterstützt, in denen RLS aktiviert ist.
  • Für jedes bestehende Modell beträgt die Maximalzahl der Azure AD-Prinzipale (d.h. der Einzelbenutzer oder Sicherheitsgruppen), die den Roles zugewiesen werden können, 1.000. Um Roles große Benutzerzahlen zuzuweisen, achten Sie darauf, die Zuweisung an Sicherheitsgruppen statt an Einzelbenutzer vorzunehmen (dies ist ohnehin aus Gründen der Wartung der Berechtigungen ratsam)

Quelle: https://docs.microsoft.com/de-de/power-bi/service-admin-rls

Szenario

In den folgenden beiden Abschnitten zur Vorstellung der sogenannten Static RLS und Dynamic RLS wird ein simples One-to-Many Szenario umgesetzt. Dabei kann ein User mehrere Berechtigungsobjekte (hier: Regionen) innehaben, aber umgekehrt kann ein Berechtigungsobjekt immer nur 1 Berechtigten haben. Als weitere Vereinfachung kommen die Berechtigungsobjekte aus 1 einzigen Spalte im Datamodel. Weiters gibt es keine hierarchischen Rechte in diesem Szenario.

Power User Perspektive

Aufbauend auf Teil 1 dieser Blogserie ist der User „robert.lochner@linearis.at“ wieder in der Power User Rolle, arbeitet direkt im App-Workspace und sieht daher alle Daten des Datamodels:

End User Perspektive

Der User „support@linearis.at“ ist wiederum in der End User Rolle, erhält Zugang über eine Power BI App (zu erkennen an der „bunten App-Navigation“ rechts oben im Screenshot) und wird über die Row Level Security auf die beiden Länder United Kingdom und France berechtigt: 

1. Static RLS („Role Based Security“)

Das Prinzip der sogenannten Static RLS liegt

  • in der manuellen Anlage idR mehrerer Rollen mit statischen DAX-Filter-Statements (bspw. auf eine Region)
  • in der manuellen statischen Zuweisung der User(gruppen) zur gewünschten Rolle (und der damit verbundenen Wartung bei organisatorischen Änderungen)

1a. Power User Perspektive

Schritt 1: Definition der Rollen und Filterbedingungen (PBI Desktop)

Die Definition der Rollen – vorerst noch ohne Bezug zu konkreten User(gruppen) – erfolgt in Power BI Desktop im Ribbon Modelling mit dem Button Manage Roles:

Im folgenden Dialog werden mit dem Button Create die gewünschten Rollen angelegt und anschließend – mit Wizard-Unterstützung – pro Rolle und pro Tabelle ein DAX-Filter-Statement („Table Filter“) erzeugt, das mit etwas DAX Know-How auch verfeinert werden kann:

  • [SalesTerritoryCountry]=“France“ || [SalesTerritoryCountry] = „United Kingdom“

Die Rolle Sales France + UK wird also nicht für ein sondern für zwei Länder berechtigt, die Verknüpfung der beiden Filter erfolgt mit dem ODER-Operator (“||”) in der Formelsprache DAX. Die für viele auf den ersten Blick vielleicht logischere UND-Verknüpfung (“&&”) würde zu einem Null-Ergebnis führen.

Pro Rolle können Bedingungen auch in mehreren Tabellen definiert werden, die einzelnen Table Filter werden mit einem UND zu einem Gesamtfilter verknüpft (und die Sicht wird mit jedem Table Filter weiter eingeschränkt). Eine ODER Verknüpfung der Table Filter ist nach unserer Einschätzung in der statischen RLS nicht möglich.

Schritt 2: Überprüfen der Rolle (PBI Desktop)

Der Power User kann mit dem Button View as Roles

… zuerst die zu testende Rolle auswählen …

… um dann das Filterergebnis im Preview-Mode zu sehen und überprüfen zu können, ob der Row Level Filter tatsächlich das gewünschte Resultat erzeugt:

Schritt 3: Publish und Hinzufügen der Members (Power BI Service)

Im nächsten Schritt wird die PBI Desktop Anwendung mit der Publish Funktion nach PowerBI.com deployed. Auf Ebene des jeweiligen Datasets wird über den Befehl Security

… der Bereich geöffnet, in dem die Zuweisung der konkreten User zu der zuvor in PBI Desktop definierten Rollen erfolgt und diese damit zu Members werden:

Folgende Zusammenhänge sind zu beachten:

  • Wird der gleiche User mehreren Roles zugewiesen, dann summieren sich die Rechte für den User aus allen Rollen (die Sicht wird mit jeder zusätzlichen Rolle erweitert).
  • Ein User, der keiner Rolle zugewiesen wird, sieht nicht alles sondern gar nichts. Damit wird sichergestellt, daß ein über die Access Control irrtümlich berechtigter User trotzdem keine Daten einsehen kann. Die Aktivierung der RLS in einem Dataset – diese wird wie weiter oben beschrieben durch die Anlage der ersten Rolle aktiviert – zwingt also zur expliziten Berechtigung aller User in der RLS mit aktivem Zugang.

Schritt 4: Überprüfen der Rolle im Dienst (Power BI Service)

Auch im Power BI Service steht für den Power User die Funktion Test as Role zur Verfügung, mit der die Funktionsweise der definierten Row Level Filter …

… wiederum im Preview-Mode getestet werden kann:

1b. End User Perspektive

Wie bereits erwähnt, sieht ein End User, der zwar aktiven Zugang (bspw. über eine App) zu einer PBI Anwendung hat, aber noch keiner Rolle als Member zugewiesen ist, keinerlei Daten im Report:

Erst nach Hinzufügen des Users zu einer Rolle zeigt der Bericht die für diesen User berechtigten Daten:

2. Dynamic RLS („Model Based Security“)

Das Prinzip der sogenannten Dynamic RLS liegt

  • in der Erweiterung des Datenmodells um eine User-Datenspalte, die mit der Faktentabelle über Beziehungen oder DAX-Statements verknüpft wird
  • in der Nutzung der DAX-Funktion USERNAME() zur dynamischen Filterung dieser User-Datenspalte
  • in der Anlage lediglich 1 Rolle zur Aktivierung der RLS, zur Aufnahme des dynamischen DAX-Filter-Statements und zur Zuweisung aller User(grupppen) als Member

2a. Power User Perspektive

Schritt 1: Erweiterung des Datamodels um eine Username-Datenspalte (PBI Desktop)

An die Dimensionstabelle Dim Customer kann beispielsweise eine Berechtigungstabelle für die RLS Regions (= Kombination der beiden Felder SalesTerritoryCountry und SalesTerritoryRegion) und eine User-Tabelle angeschlossen werden („Snowflaking“). Der dynamische Filter wird dann in weiterer Folge auf das Feld RLS Username angewendet werden, das dann im Datamodel „nach innen“ bis zur Faktentabelle und damit den Measures filtern wird:

Hier der (mögliche Aufbau) der Berechtigungstabelle für die RLS Regions. Beachten Sie, daß aufgrund des einfachen One-to-Many Szenarios in diesem Beispiel die Spalte RLS Region ein Primary Key Feld ist (d.h. jeder Eintrag ist eindeutig) und daher die Berechtigungstabelle als „ganz normale“ Dimensionstabelle mit anderen Tabellen in Beziehung gesetzt werden kann („Snowflaking“ mit normalem „Single Direction“ Filter):

Hier der (mögliche Aufbau) der User-Tabelle:

Wichtig ist, daß in diesem Szenario nicht die zusätzlichen Tabellen die Dynamic RLS ermöglichen, sondern lediglich das Feld RLS Username. Das Feld hätte auch als Attribut direkt in die Dim Customers Tabelle (bspw. mittels einer Merge Query) integriert werden können, auf die beiden Snowflake-Tabellen könnte dann verzichtet werden.

Schritt 2: Anlage der Role und Erstellung des dynamischen DAX-Filter-Statements (PBI Desktop)

In der Dynamic RLS braucht lediglich eine einzige Rolle angelegt zu werden mit folgendem dynamischen DAX-Statement:

  • [RLS Username] = USERNAME()

Es wird also das Feld RLS Username – dieses enthält die E-Mailadressen der berechtigten User – dynamisch auf den aktiven User im Power BI Service mittels der DAX-Funktion USERNAME() gefiltert. Daher die Bezeichnung Dynamic RLS für diese Methode.

Das Ergebnis der Funktion USERNAME() können wir übrigens auch mit einem einfachen Measure abfragen und mit einem Card-Visual im Report sichtbar machen:

  • Current User = USERNAME()

Beachten Sie, daß die USERNAME()-Funktion in PBI Desktop nicht den Power BI Account sondern den Windows User zurückliefert. Erst nach dem Deployment der Anwendung in den Power BI Service zeigt die Funktion den Account des Users (= E-Mail Adresse) an. Die Funktion USERPRINCIPALNAME() sollte eigentlich auch in PBI Desktop die Mailadressse des Accounts anzeigen, bei unseren Tests hat das bisher aber nicht funktioniert (und ist auch nicht unbedingt notwendig).

Schritt 3: Publish und Hinzufügen der Members zur Rolle (PBI Service)

Auch bei der Dynamic RLS muß – genauso wie bei der Static RLS – jeder berechtigte User explizit einer Rolle zugewiesen werden, da nicht hinzugefügte User zwar den Report öffnen können, aber keine Daten angezeigt bekommen. In der Dynamic RLS werden alle User – am besten über eine einzige Usergruppe – der dynamischen Rolle als Members hinzugefügt:

2b. End User Perspektive

Für den End User ist das Ergebnis der Dynamic RLS bei gleichem logischem Aufbau der Berechtigungen natürlich ident wie bei der Static RLS:

Gegenüberstellung Static vs. Dynamic und Best Practices

Static RLS
(„Role Based Security“)
Dynamic RLS
(„Model Based Security“)
Eigenschaften
  • Manuelle Anlage idR mehrerer Rollen mit statischem DAX-Filter-Statement (bspw. auf die Region)
  • Manuelle statische Zuweisung der User(gruppen) zu den einzelnen Rollen als Member
  • Erweiterung des Datamodels um eine Username-Datenspalte, die mit der Faktentabelle (über Beziehungen oder DAX-Statements) verknüpft wird
  • Nutzung der DAX-Funktion USERNAME() zur dynamischen Filterung der Username-Datenspalte
  • Anlage lediglich 1 Role zur Aktivierung der RLS, zur Aufnahme des dynamischen DAX-Filter-Statement und zur Zuweisung aller User(gruppen) als Member
Pro
  • Anspruchsvolle Berechtigungsstrukturen mit wenig Know-How abbildbar (additive Table-Filter, Mehrfachzuordnung eines Users zu verschiedenen ROLEs möglich)
  • Dynamische (= automatische) Zuweisung der User zum Row Filter
  • Modellbasierte (= saubere) Lösung
  • Wartungsfrei (sofern die Berechtigungsdaten sauber und aktuell ins Datenmodell „geliefert“ werden)
Contra
  • Entspricht eher einer adhoc Lösung
  • Bei größeren Strukturen hoher Wartungsaufwand, verschachtelte DAX-Statements werden rasch sehr unübersichtlich
  • Fortgeschrittene Security Patterns nur mit Modellierungs- und DAX-Know-How umsetzbar
Einsatzgebiet
  • Kleine Berechtigungsstrukturen mit wenig Volatilität
  • Umfangreiche Berechtigungsstrukturen mit hoher Volatilität

Fortgeschrittene Security Patterns

Das bisher in diesem Blogbeitrag umgesetzte One-to-Many Szenario ist sehr simpel, da jedes Berechtigungsobjekt (hier: Country/Region) nur max. 1 Berechtigten haben kann. Dazu kommen alle Berechtigungsobjekte aus nur 1 Datenfeld und es existieren auch keine hierarchischen Rechte.

Top-Management Pattern

Das Top-Management darf immer alle Daten sehen. Ohne Zuweisung zu einer (Filter-)Role bekommt das Top-Management jedoch gar keine Daten angezeigt. Der folgende Lösungsansatz (den wir aber in der Praxis bisher noch nicht eingesetzt haben) erscheint sehr simpel: es dürfte reichen, sowohl in der Static RLS als auch Dynamic RLS eine Rolle ohne DAX-Filter-Statement anzulegen und auf diese Rolle im Power BI Service die User Accounts des Top-Managements zuzuweisen:

Ein Blick auf den kumulativen Effekt zeigt: wird der gleiche User 2 Roles mit je einem Filter zugewiesen, dann werden die Filterergebnisse beider Roles angezeigt (also bspw. die Datensätze von „France + UK“ und „Canada“). Wird ein User sowohl einer Role mit Filter (bspw. auf „Germany“) als auch der Top-Management Role ohne Filter zugewiesen, dann sieht der User sämtliche Daten. Es werden also immer die Filtergebnisse aller Roles angezeigt.

Hier ein Link zu einer anderen und recht interessanten Lösung zur Abbildung des Top-Management Levels über die Berechtigungstabelle („model driven“) und einem relativ einfachen DAX-Statement: radacad.com/dynamic-row-level-security-with-manager-level-access-in-power-bi

Many-to-Many Security Pattern

Sollen auf das gleiche Berechtigungsobjekt (bspw. „Canada“) nicht nur der ADM sondern auch der übergeordnete Gebietsverantwortliche und dann auch der Länderverantwortliche  Zugriff erhalten, dann wird in einer Dynamic RLS Lösung die Berechtigungstabelle zur Bridge Tabelle, da diese in dieser Konstellation kein Primary Key Feld mehr hat:

Folglich braucht es ein Many-to-Many Security Pattern im Datamodel. Dieses Pattern braucht in Power BI eine Zwischentabelle zur Verknüpfung der Berechtigungstabelle (= Bridge Tabelle) mit der Dim Customer Tabelle sowie eine sogenannte bidirektionale Beziehung, um den USERNAME-Filter „von außen nach innen“ zur Faktentabelle wirken zu lassen:

Quellen zur detaillierten Umsetzung des Many-to-Many Security Patterns:

Weitere Security Patterns

radacad.com/dynamic-row-level-security-with-organizational-hierarchy-power-bi -> interessante Lösung für die Management Level Thematik in einer Parent-Child-Organisationsstruktur.

community.powerbi.com/t5/Community-Blog/Different-approach-to-Dynamic-Row-Level-Security/ba-p/80108 -> interessante Lösung mit einem LOOKUP in einer Calculated Column und einem TRUE-Filter in der Role.

Interessant sind auch Security Patterns, bei denen nicht auf 1 Feld im Datamodel sondern – abhängig von der User-Role – auf unterschiedliche Felder einer (oder mehrerer) Tabellen alternativ (oder additiv) gefiltert werden muß.

Zum Security Pattern „ADM darf Sales-Daten des eigenen Gebiets im Detail sehen und zusätzlich die Ländersumme, jedoch ohne die Details der anderen Gebiete des Landes analysieren zu können“ ist uns leider bisher kein Lösungsansatz bekannt. Über Inputs im Kommentarbereich dieses Blogbeitrags freuen wir uns!

Kritische Würdigung

Nach unserer Einschätzung sind mit der RLS in Power BI und Tabular Model bereits viele Szenarien umsetzbar, die Technologie ist gut entwickelt.

Jedoch ist kritisch anzumerken, daß bereits für relativ einfache RLS-Szenarien Modellierungs- und DAX-Know-How notwendig ist, hier wären Wizards wie aus den SQL Server Analysis Services („Cubes“) bekannt sehr wünschenswert. Für anspruchsvolle Szenarien fehlen möglicherweise auch noch Mechanismen oder zumindest die Idee, wie solche Patterns heute schon umgesetzt werden können.

Kritisch anzumerken ist auch, daß eine Object Level Security (OLS) – also die Berechtigung von Tabellen, Attributen und Measures – bisher nur in SQL Server Tabular Model eingeführt wurde, aber in Power BI aber noch vollständig fehlt. Die RLS ist also noch durch eine OLS zu ergänzen, sinnvollerweise sollten in Power BI auch gleich die einzelnen Sheets der Reports in die OLS einbezogen werden.

Quellen

docs.microsoft.com/de-de/power-bi/service-admin-rls

Row Level Security – Revisited (Guy in a Cube)

Static RLS

powerbi.microsoft.com/de-de/documentation/powerbi-admin-rls/

radacad.com/row-level-security-configuration-in-power-bi-desktop

Dynamic RLS (1:n)

radacad.com/dynamic-row-level-security-with-power-bi-made-simple

Robert Lochner

Robert Lochner ist seit 2001 als Unternehmer tätig und Gründer der Linearis. Seit seinem Betriebswirtschaftsstudium an der WU Wien ist er als Unternehmer in der BI Branche tätig, ist Trainer für Excel BI und Power BI und unterstützt Unternehmen bei der digitalen Transformation ihrer Business Intelligence Prozesse. Er ist Autor des Linearis Blogs und mehrerer fachlicher Publikationen.

Weitere Beiträge

Kategorien: Analyse, Dashboarding, Power BI im Team nutzen, Reporting, SQL Server als DWH nutzen