Power BI Sicherheit: Wie Power Apps die Verwaltung von Row-Level-Security auf das nächste Level hebt

/in /von

Was ist Row-Level-Security?

Row-Level-Security (RLS) ist ein Konzept in Power BI, welches es ermöglicht, den Zugriff auf Daten auf Zeilenebene zu steuern. Mit RLS kann festlegt werden, welche Daten bestimmte Reportuser oder Usergruppen sehen dürfen, basierend auf definierten Rollen. Diese Rollen können auf verschiedenen Regeln bzw. Kriterien basieren, wie z.B. Benutzerrollen, Abteilungszugehörigkeit oder individuellen Berechtigungen. So können Sie sicherstellen, dass jeder Reportuser nur die Daten sieht, auf die er zugreifen darf und gleichzeitig die Datensicherheit und -integrität gewährleisten.

Wie implementiert man es & wo gibt es Probleme?

Um zu erklären, wie man RLS implementieren kann, wird als Beispiel ein Auszug der Adventureworks Sales LT DB herangezogen:

AdventureWorks Sales LT ist eine von Microsoft entwickelte fiktive Datenbank. Sie enthält typische Daten eines Unternehmens, insbesondere im Bereich Vertrieb (Sales), wie zum Beispiel Produkte, Bestellungen und Verkaufstransaktionen:

  • SalesLT.Product: und SalesLT.ProductCategory: Hier werden Produkte kategorisiert und Produktinformationen gespeichert, einschließlich Produktname, Beschreibung, Preis usw.
  • SalesLT.SalesOrderHeader und SalesLT.SalesOrderDetail: Diese Tabellen enthalten Informationen zu Verkaufsaufträgen, wie Auftragsdatum, Lieferadresse, Bestellpositionen und -details.
  • SalesLT.Address: Diese Tabelle enthält Adressinformationen, die mit Verkaufsaufträgen verknüpft sind.

Für das Beispiel wird das Modell noch um die Tabelle SalesLT.Employee ergänzt, die Informationen über Mitarbeiter im Vertrieb enthält. Somit können Verkäufe Mitarbeitern zugeordnet werden, um nachzuvollziehen, wer für bestimmte Transaktionen verantwortlich ist.

Datenbank-Schema unseres Test-Use-Cases

EINFACHER USECASE

Ein unkomplizierter und leicht umzusetzender Anwendungsfall für Row-Level-Security liegt vor, wenn der Kontext direkt aus den vorhandenen Daten abgeleitet werden kann. Beispielsweise, wenn Sales-Mitarbeiter Verkäufe tätigen, die in einem Report dargestellt werden sollen, um ihren Fortschritt zu verfolgen. In diesem Szenario ist es wichtig, dass jeder Sales-Mitarbeiter ausschließlich seine eigenen Verkaufszahlen einsehen kann.

Dies lässt sich einfach realisieren, da jedem Verkauf ein bestimmter Sales-Mitarbeiter zugeordnet werden kann. Die Umsetzung und Pflege gestalten sich ebenfalls unkompliziert, da lediglich eine Rolle definiert und verwaltet werden muss, um dieses Szenario abzudecken.

KOMPLIZIERTER USECASE

Es wird komplizierter, wenn der Bezug des Reportusers nicht aus dem vorhandenen Kontext der Daten abgeleitet werden kann, das heißt es keine direkten Verbindungen zwischen Reportuser und Records des Datenmodells gibt. Ein Beispiel hierfür sind Sales-Manager, die für unterschiedliche Regionen, Mitarbeiter oder Vertriebskanäle zuständig sind, jedoch keine eigenen Verkäufe vorweisen können. In solchen Fällen müssen für jede mögliche Ausprägung separate Rollen erstellt, zugewiesen und verwaltet werden, was sowohl zeitaufwändig als auch fehleranfällig sein kann, da dies händisch erfolgt.

Insbesondere bei einer großen Anzahl von Reports erhöht sich der Aufwand erheblich, da für jeden Report die individuellen Rollen gleichermaßen erstellt, zugewiesen und gepflegt werden müssen. Dies steigert das Fehlerpotenzial zusätzlich und erfordert eine umfassende Verwaltung der Zugriffsstruktur.

Lösung: Entwicklung von Security-Tabellen und pflege über eine grafische Oberfläche wie Power Apps

Eine Möglichkeit, diese Zugriffsstruktur bereitzustellen, ist die Entwicklung von Security-Tabellen. Hier werden die Berechtigungsattribute und die User losgelöst vom eigentlichen Datenmodell abgebildet und über Mapping-Tabellen (User_2_) einander zugeordnet.

Die Mapping-Tabellen werden anschließend aufbereitet und im Power BI-Datenmodell per DirectQuery an die entsprechenden Tabellen angebunden, sodass die vorgenommenen Änderungen an der Berechtigung auch sofort vollzogen werden.

Da Attribute immer auf die jeweiligen Email-Adressen der Reportuser gemappt werden, reicht hierfür eine einzige Rolle mit einer einfachen DAX-Formel pro Mapping-Tabelle im Dataset.

Ist diese Rolle allen Reportusern im Power BI Service zugewiesen, müssen die gesetzten Berechtigungen an einem Ort verwaltet werden. Hier kommt Microsoft Power Apps ins Spiel:

Power Apps ist eine Low-Code Plattform von Microsoft, die es Benutzern ermöglicht, benutzerdefinierte Unternehmensanwendungen ohne umfangreiche Programmierkenntnisse zu erstellen. Mit Power Apps können schnell und einfach interaktive Apps erstellt werden, die auf verschiedenen Geräten wie PCs, Tablets oder Smartphones laufen können. Die Plattform bietet eine Vielzahl von Vorlagen und Tools zur Gestaltung von Benutzeroberflächen sowie zur Integration von Daten aus verschiedenen Quellen wie Microsoft 365, SharePoint, SQL-Server und vielen anderen.

In dieser entwickelten Power App werden links in der Liste zu berechtigende Reportuser und rechts die bereits vergebenen Berechtigungen angezeigt. Über die Dropdown-Menüs kann dann die entsprechende Berechtigung gewählt werden. Die getroffene Auswahl wird nach dem Speichern in der App direkt in die Mapping-Tabellen geschrieben. Durch die bereits angesprochene Anbindung der Security-Tabellen via DirectQuery werden Änderungen direkt in das Power BI-Datenmodell übertragen und bietet so die Möglichkeit, schnell und flexibel auf Änderungen in der Berechtigungsstruktur zu reagieren.

Bei einer größeren Anzahl von Reports kann eine solche Lösung als zentrales Verwaltungstool eingesetzt werden und somit das oben erläuterte repetitive Zuweisen der Rollen pro Report durch einfache Klicks ersetzen. Zudem verschafft es einen Überblick aller vergebenen Rechte an einem Ort und beugt somit Fehler in der Zuweisung der Rollen vor.

Autor

Maximilian Leist,
maximilian.leist@scieneers.de