Sicherheit auf Zeilenebene mit Power BI

Sicherheit auf Zeilenebene (engl. row-level security, RLS) ist eine nützliche Funktion in Power BI, die es ermöglicht, den Datenzugriff auf Zeilenebene basierend auf Benutzerrollen und Filtern einzuschränken. Durch die Implementierung von RLS wird ein verbesserter Datenschutz und eine erhöhte Vertraulichkeit der Daten gewährleistet. In diesem Artikel werden wir uns mit der Implementierung von RLS in Power BI befassen.

Arten von RLS

Power BI unterstützt zwei Haupttypen von RLS: Statische und Dynamische Sicherheit. Im Folgenden zeigen wir die Verwendung und die Unterschiede auf.

Statische Sicherheit

Statische Sicherheit ermöglicht es, Filter auf Zeilenebene vorab festzulegen, ohne dass diese sich durch Benutzerinteraktionen oder -eingaben ändern. Mit dieser Funktion kann man beispielsweise den Datenzugriff auf bestimmte Regionen, Abteilungen oder Marken beschränken. Die Definition der Regeln für die statische Sicherheit erfolgt in Power BI Desktop unter "Modellierung" und "Rollen verwalten". Dort können verschiedene Rollen erstellt werden, z. B. eine Rolle namens "Germany" mit dem Tabellenfilter [Country] = "Germany", um nur die Daten aus Deutschland anzuzeigen.

"Rollenverwaltung in PowerBI"

Anschließend ruft man im Power BI Service "Sicherheit" auf. Hier gibt es die Möglichkeit, E-Mail-Adressen den bereits erstellten Rollen zuzuordnen. Bei vielen verschiedenen Rollen kann die Einrichtung der statischen Sicherheit etwas zeitaufwendig sein, da die Rollen manuell erstellt werden müssen. Zudem erfordert es mehr Aufwand bei komplexeren Filterlogiken, wenn unterschiedliche Personen zwar dasselbe Land, aber beispielsweise nicht dieselben Marken sehen dürfen.

Dynamische Sicherheit

Die dynamische RLS ermöglicht eine genauere Kontrolle über den Datenzugriff und vereinfacht das Verfahren. Dafür kann die DAX-Funktion USERPRINCIPALNAME() verwendet werden, die die Identität des aktuellen Benutzers abruft und die Daten entsprechend filtert.

Um die dynamische RLS zu implementieren, benötigen wir eine Tabelle mit den jeweiligen E-Mail-Adressen und den Zugriffsregeln. Zum Beispiel kann User A alle Daten aus dem Land Deutschland sehen, während User B nur bestimmte Marken aus Deutschland einsehen darf. User C hingegen darf alle Daten der Länder sehen, die zur Region EU gehören.

Beispiel:

Nun muss eine Beziehung zwischen der RLS-Tabelle und der Zieltabelle im Datenmodell hergestellt werden, z. B. über die Spalten Region, Land oder Marke. Diese Beziehung stellt sicher, dass die RLS-Regeln bei der Abfrage der Daten korrekt angewendet werden.

Ähnlich wie bei der statischen Sicherheit wird eine Rolle definiert, aber hier benötigen wir nur eine einzige Rolle. Unter "Rollen verwalten" kann bei der RLS-Tabelle in der Spalte mit den E-Mail-Adressen (hier "User") der Tabellenfilter [User] = USERPRINCIPALNAME() hinzugefügt werden. Um die Zugriffe zu testen, kann man über “Anzeigen als” die neue Rolle sowie “Anderen Nutzer” auswählen und eine gewünschte E-Mail-Adresse zum Testen eingeben.

Wichtig: RLS kann nicht auf einen Benutzer angewendet werden, wenn dieser ein Administrator, Mitglied oder Mitwirkender im Arbeitsbereich ist, in dem der Bericht veröffentlicht wird.

Vorteile auf einen Blick:

• Ein gleicher Report für alle Marken und Länder, keine einzelnen Reports. Dies reduziert den Aufwand bei der Erstellung und Änderungen und die Anzahl an Reports.
• Falls der manuelle Aufwand oder die Anzahl der verschiedenen Rollen zu hoch ist, wird die dynamische RLS gegenüber der statischen Variante bevorzugt
• Klare Definition und Dokumentation der Benutzerrollen und ihrer jeweiligen Datenzugriffsanforderungen.
• Flexible Anpassung bei Zugriffsänderung
• Datenmanagement und Sicherheitsbewusstsein wird gefördert

Weitere Informationen:

• https://learn.microsoft.com/en-us/power-bi/enterprise/service-admin-rls