Serie | Microsoft Power Platform – Sicherheitskonzepte in Microsoft Power BI – dynamisches Row Level Security
Ausgangslage & Set-up
Sie haben viele Rollen (>50) und/oder es werden sehr regelmäßig Rollen erstellt? Dann benötigen Sie dynamisches RLS in Ihrem Bericht.
Es gibt einige Voraussetzungen, um dynamische RLS im Vergleich zu statischen RLS zu verwenden.
- Sie müssen eine Tabelle mit allen Benutzern haben, die auf den Bericht zugreifen, mit ihrer E-Mail-Adresse (oder ihrem UPN, falls dieser abweicht).
- In der Faktentabelle, die Sie herausfiltern wollen, müssen Sie eine Identifikation für jeden Mitarbeiter einer Gruppe von Mitarbeitern haben, die pro Zeile die Daten sehen können
Wir haben eine dummy Liste von Mitarbeitern mit DAX (und auch mit Humor) definiert. In einem professionellen Umfeld würde diese Liste bereits aus SharePoint oder einer anderen von der Personalabteilung zur Verfügung gestellten Quelle gefüllt werden.
Je nachdem, wer angemeldet ist, müssen die Daten gefiltert werden.
Da eine Organisation mit AAD (on-premise oder nicht) verwaltet ist, werden wir als Identifikationsmethode die E-Mail bzw. die UserPrincipalName wählen.
Um die E-Mail-Adressen (als Identifikationsmethode) der Benutzer zu erhalten, gibt es zwei Möglichkeiten bzw. Funktionen, die von Power BI zur Verfügung gestellt werden:
- UserPrincipalName() gibt immer den gleichen Wert zurück, egal ob Sie sich in Power BI Desktop oder in Power BI Service befinden. Sie gibt den UPN zurück, der in AAD von dem Benutzer eingegeben wurde, der eine Verbindung herstellt. Oft ist es Ihre E-Mail-Adresse, aber vielleicht auch nicht, je nachdem, was in AAD eingegeben wurde. Es wird jedoch immer derselbe Wert sein.
- Username() erzeugt eine andere Ausgabe. In Power BI Service, da Sie nicht mit einem Rechner verbunden sind, wird Ihr UPN ausgegeben. In Power BI Desktop hingegen wird der mit dem Windows-Rechner verbundene Benutzer ausgegeben. Die Syntax der Ausgabe ist immer dieselbe: <Name PC>/<Name registrierter Benutzer>.
Ziehen Sie immer UserPrincipalName dem Benutzernamen vor, es sei denn, es gibt spezielle gute Gründe, dies nicht zu tun. Es wird immer die gleiche Ausgabe haben und einfacher zu verarbeiten sein.
Auf Power BI Desktop haben wir kleine visuelle Darstellungen erstellt, um zu verstehen, wie diese Funktionen funktionieren:
In Power BI Desktop:
In Power BI Service:
Wir entscheiden uns für die Verwendung von UserPrincipalName() für unseren Anwendungsfall:
Der zweite Schritt besteht darin, unser Datenmodell zu erstellen. Wir müssen unsere Mitarbeitertabelle (jede ID jedes Mitarbeiters sollte eindeutig sein) mit unserer Faktentabelle verbinden, die wir filtern wollen, wobei wir möglicherweise viele Einträge pro Mitarbeiter haben werden. Dies ist das Standard-Datenmodell mit RLS, das am übersichtlichsten ist.
Die Mitarbeitertabelle ist mit 1:n auf die Produkttabellen bezogen. Eine Spalte “Users” bezeichnet die gleiche ID aus der Mitarbeitertabelle.
Verbinden wir uns nun mit unserer Rolle “Office 365”. Wir werden sehen, dass wir das gleiche Ergebnis wie beim statischen RLS haben. Dieses wird sich jedoch als dynamisch erweisen, da alle Benutzer mit der ID gefiltert werden.
Beschränkungen für dynamische RLS
Zuordnung in mehreren Rollen
Ein Benutzer sollte niemals mehrere Rollen zugeordnet werden, da es keine definierten Regeln für die Ausgabe der Daten gibt. Dies wird zu Problemen führen und wird von Power BI bis jetzt noch nicht unterstützt.
Im Gegensatz zu den meisten Datenbank-RLS-Einstellungen gilt im Power BI-RLS-System nicht unbedingt das Prinzip “einmal verweigert, immer verweigert”. Wenn ein Benutzer mehrere Rollen hat, kann man die Ausgabe nicht übernehmen. Daher darf ein Benutzer höchstens in einer Gruppe sein.
Wenn Sie einen Benutzer mit “mehreren Rollen” benötigen, sollten Sie eine neue Rolle erstellen, in der alle Filter für beide Rollen zusammengefasst sind.
Angenommen, wir möchten einen Benutzer erstellen, der sowohl auf alle Power Platform- als auch auf Office 365-Produkte zugreifen kann, aber nicht auf XBOX. In diesem Fall fügen Sie den Benutzer nicht zu beiden Gruppen hinzu, sondern erstellen eine neue Rolle “Office+PowerPlatform”.
Für die DAX-Messung können Sie Operatoren verwenden, um verschiedene Filter hinzuzufügen:
Sobald wir den Bericht in unserer neuen Rolle sehen, können wir bestätigen, dass unsere Lösung wie erwartet funktioniert.
Für eine andere Ebene filtern
Ein weiterer häufiger Fall von RLS ist, wenn die Faktentabelle keine direkten Informationen über die Benutzer enthält. Im Falle des Verkaufs wäre eine Abteilung oder eine Region für den Verkauf zuständig, aber nicht genau eine bestimmte Person. In diesem Fall gibt es in der Vertriebstabelle keine Spalte für Benutzer, sondern für eine andere Hierarchieebene.
Nehmen wir das Beispiel mit unserer Produkttabelle. Wir haben nun die Verkäufe nach Regionen geordnet, was bestimmten Teilen der Welt entspricht. Wir wollen RLS pro Benutzer implementieren und wir wissen, wo welche Person arbeitet.
Wie funktioniert RLS? Wir müssen eine “Rollentabelle” einrichten und unsere Mitarbeitertabelle mit den Informationen darüber, welcher Benutzer zu welcher Rolle gehört, beibehalten. In der Produkttabelle haben wir mit „Region_ID“ die Identifikation, um die Daten zu filtern.
Unser Datenmodell muss sich ändern: Wir werden die Faktentabelle mit unserer Rollentabelle filtern. Die Benutzertabelle wird nach unserer Rollentabelle gefiltert.
Da die RLS aus der Mitarbeitertabelle stammen und unsere Identifizierungsmethode die UPN bleibt, müssen wir die Filterung zwischen Rolle und Benutzer auf beiden Seiten durchführen. Andernfalls kann die Mitarbeitertabelle die Produkttabelle nicht filtern.
Dies ist ein Paradebeispiel für einen RLS, der für eine andere Hierarchiestufe arbeitet. Wir haben eine Rollentabelle (hier: Region) und die Benutzertabelle (hier: Employee_Region) und die Beziehungen für das Datenmodell sind immer so aufgebaut: Benutzertabelle – Rollentabelle – Faktentabelle.
Hierarchie für eine Organisation
Bis jetzt hatten wir nur Mitarbeiter in verschiedenen Abteilungen. In einem größeren Unternehmen haben wir öfter andere Hierarchieebenen. Es gibt zum Beispiel die Abteilung Power Plattform und in dieser Abteilung die Branchen „Power BI“, „Power Automate“, „PowerApps“.
Wir wollen natürlich, dass eine Person für in der Power Plattform Ebene alle Produkte von Power Plattform sehen kann. Aber eine Person in der Power BI Branche sollte nur die Produkte für Power BI und nicht die verschiedenen anderen
In diesem Fall haben wir nur eine Ebene hinzugefügt, benötigen Firmen aber oft viel mehr Ebenen, um alle Mitarbeiter zu ordnen. Um mehr Hierarchiestufen für RLS einzuführen, müssen wir die DAX-Formel anpassen (PATH, PATHCONTAINS, LOOKUPVALUE).
Standard Role
Was passiert, wenn sich ein Benutzer mit dem Bericht verbindet und seine E-Mail-Adresse in keiner der zuvor definierten Rollen eingetragen ist? Er wird nichts sehen. Dies ist beabsichtigt und verhindert, dass neue oder unbekannte Benutzer irgendetwas in Ihrem Bericht sehen, was sie eigentlich nicht sehen sollten.
In Ihrer Organisation könnten Sie jedoch eine Rolle hinzufügen, die als “Master” angesehen werden kann und die die Standardansicht für alle neuen Benutzer im Bericht ist. Dies könnte praktischer sein als gar nichts zu sehen, da ein neuer Benutzer nicht nur nichts sieht, sondern auch eine Fehlermeldung erhält.
Normalerweise würden Sie eine leere Rolle No_RLS erstellen und die Rolle filtert nichts oder eine Standardfilterung.
Dann erstellen Sie eine AD-Gruppe für die Personen, die zu dieser Rolle gehören sollen, und Sie können diese Gruppe der Rolle zuweisen, wenn Sie die Sicherheit des Datasets konfigurieren.
Dranbleiben lohnt sich: In unseren folgenden Impulsen gehen wir tiefer in die Materie und erklären, wie Object Level Security (OLS) und Page/Tab Level Security integriert werden können, und was Private Endpoints sind!
Übersicht zur Microsoft Power Platform:
- Power BI Deep Dive
- Power Apps Deep Dive
- Power Automate Deep Dive
- Power Virtual Agents Deep Dive
- Sicherheitskonzepte in MS PBI – statisches Row Level Security
- Sicherheitskonzepte in MS PBI – dynamisches Row Level Security
- Sicherheitskonzepte in MS PBI – Object, Page & Organisation Level Security
- Best Practice Power BI Verwaltungsportal und Mandanteneinstellungen
- Eltern-Kind-Hierarchien in Power BI zur Abbildung von Organigrammen
Interessiert? Dann nichts wie ab zu unserer Power BI Schulung, BI Einführungsworkshop oder Power BI Performanceoptimierung. Damit Wissen nicht nur theoretisch im Kopf bleibt, sondern praktisch umgesetzt werden kann.
Haben wir Ihr Interesse geweckt? Kontaktieren Sie uns gerne.
Ihr Ansprechpartner
