Blog Details

  • Home
  • Datenzugriff nach Mass – Row-Level Security in Power BI

Datenzugriff nach Mass – Row-Level Security in Power BI

Reports in Power BI werden über Workspaces und Apps an die Konsumenten verteilt, auf welche diese entsprechend berechtigt sind. Das heisst, sie haben nur Zugriff auf jene Auswertungen, die auch für sie bestimmt sind. Was aber, wenn Konsumenten innerhalb eines Reports nur bestimmte Daten sehen dürfen? Der Verkaufsleiter Europa sollte nur die Daten aus Europa sehen und die Verkaufsleiterin Asien nur jene aus Asien. Auch wenn man geneigt ist, hier einzelne Workspaces/Apps zu erstellen und den Report mehrfach zu verteilen, gibt es eine einfachere Möglichkeit: Datenzugriff nach Mass mit dem Konzept von “Row-Level Security”. Was das ist und wie es funktioniert, stellen wir in diesem Beitrag vor.

Ein Report für alle

Die Ausgangslage ist ein Report wie dieser: Umsatzzahlen pro Quartal nach Regionen in der Deutschschweiz. Es sollte nun möglich sein, dass ein Benutzerkreis nur die Daten aus einer bestimmten Region sehen kann, während andere Benutzer alles sehen dürfen.

Umsatzreport und Datenmodell
Umsatzreport nach Regionen (links) mit dem unterliegenden Datenmodell im Star-Schema (rechts) in Power BI

Das Konzept des Datenzugriff nach Mass

Das Konzept von “Row-Level Security” (RLS) setzt auf dem Datenmodell auf: Die Datensätze (Rows) werden nach den definierten Kriterien gefiltert und der zugewiesenen Benutzergruppe angezeigt. Durch die Verknüpfungen im Datenmodell werden die anderen Tabellen automatisch gemäss Relationen ebenfalls gefiltert.

Row-Level Security
Konzept von Row-Level Security: User oder Usergroups sehen nur Daten, die für sie freigegeben sind

In Power BI gibt es zwei Möglichkeiten Row-Level Security zu implementieren: Statisch oder dynamisch.

Statische Row-Level Security

Bei der statischen RLS werden Rollen in Power BI Desktop erstellt und die Datenfilter fix definiert. Zum Beispiel wird eine Rolle “Region NW” für die Einschränkung auf die Daten aus der Region Nordwestschweiz gesetzt.

Statische RLS
Statische RLS in Power BI Desktop

Zur Auswahl stehen die Tabellen gemäss Datenmodell und es können mehrere Kriterien definiert werden. Es gibt zudem gleich die Möglichkeit die Ansicht dieser Rolle in Power BI Desktop zu testen, ehe die Reports publiziert werden. Zu diesem Zeitpunkt wurde noch nicht definiert, welche User die Rolle “Region NW” inne haben – dies wird nach dem Publish im Power BI Service gemacht, also Online.

Statische RLS Zuweisung Member
Statische RLS in Power BI Service

Mit der Zuweisung von einzelnen User oder User Groups bekommen diese Personen nur noch jene Daten zu sehen, die für sie bestimmt sind:

Statische RLS nach Zuweisung
Datenzugriff mittels statische Rolle zeigt nur noch Daten an, die gemäss Filter definiert worden sind

Dynamische Row-Level Security

Die Erstellung von logischen Rollen und der manuellen Zuweisung von Kriterien und User/User Groups ist sehr praktisch. Bei grösseren Organisationen mit vielen verschiedenen User/User Groups kann das Ganze jedoch sehr aufwändig werden. Hier eignet sich die Methode der dynamischen RLS. Hier wird aufgrund des eingeloggten Users ermittelt, welche Daten dieser sehen darf. Voraussetzung ist, dass die User (oder User Groups) mit dem User Principal Name im Datenmodell integriert sind, so dass sie gemappt werden können. In unserem Beispiel ist die E-Mail-Adresse in der Mitarbeiter-Tabelle vorhanden, welche mit der Region und somit mit der Umsatztabelle verbunden ist.

Die Definition wird an der gleichen Stelle in Power BI Desktop erstellt, diesmal aber direkt im DAX-Editor.

Dynamische RLS
Dynamische RLS im Power BI Desktop

Wichtig: Auch hier müssen User/User Groups in Power BI Service als Member hinzugefügt werden, damit die Row-Level Security angewendet wird – allerdings benötigt es nur diese eine Rolle und mit einem sauberen Aufsetzen von AD Gruppen sollte dieser Aufwand minimal gehalten werden können.

Fazit

Mittels Einschränkung der Daten auf Datensatz-Ebene kann der gleiche Report für mehrere Benutzergruppen verwendet werden. Dies ist insbesondere bei Reports sinnvoll, die von mehreren Teilnehmer genutzt werden, deren Daten vertraulich sind. Hier ist der administrative Aufwand um ein Vielfaches kleiner, als mehrere Workspaces und Apps erstellen zu müssen.