Einschränken des Zugriffs auf Power BI-Modelldaten
Als Datenmodellierer richten Sie Sicherheit auf Zeilenebene (RLS) ein, indem sie eine oder mehrere Rollen erstellen. Eine Rolle hat einen eindeutigen Namen im Modell und umfasst normalerweise eine oder mehrere Regeln. Regeln erzwingen Filter auf Modelltabellen mithilfe von DAX-Filterausdrücken (Data Analysis Expressions).
Hinweis
Standardmäßig verfügt ein Datenmodell nicht über Rollen. Ein Datenmodell ohne Rollen bedeutet, dass Benutzer (die die Erlaubnis haben, das Datenmodell abzufragen) Zugriff auf alle Modelldaten haben.
Tipp
Es ist möglich, eine Rolle zu definieren, die keine Regeln enthält. In diesem Fall bietet die Rolle Zugriff auf alle Zeilen aller Modelltabellen. Diese Rolleneinrichtung eignet sich für einen Administratorbenutzer, der alle Daten anzeigen darf.
Sie können Rollen in Power BI Desktop erstellen, überprüfen und verwalten. Für Azure Analysis Services- oder SQL Server Analysis Services-Modelle können Sie Rollen mithilfe der SQL Server Data Tools (SSDT) erstellen, überprüfen und verwalten.
Sie können Rollen auch mithilfe von SQL Server Management Studio (SSMS) erstellen und verwalten oder ein Tool eines Drittanbieters verwenden, z. B. Tabular Editor.
Um besser zu verstehen, wie die Sicherheit auf Zeilenebene (RLS) den Zugriff auf Daten einschränkt, sehen Sie sich die folgende animierte Abbildung an.
Anwenden von Sternschema-Entwurfsprinzipien
Wir empfehlen Ihnen die Anwendung der Sternschema-Entwurfsprinzipien, um ein Modell mit Dimensions- und Faktentabellen zu erstellen. Es ist üblich, Power BI einzurichten, um Regeln zu erzwingen, die Dimensionstabellen filtern, damit Modellbeziehungen diese Filter effizient an Faktentabellen weitergeben können.
Die folgende Abbildung zeigt das Modelldiagramm des Datenmodells für die Verkaufsanalyse von Adventure Works. Sie zeigt ein Sternschema mit einer einzelnen Faktentabelle für die Umsätze. Die anderen Tabellen sind Dimensionstabellen, die die Analyse von Verkaufsmaßnahmen nach Datum, Vertriebsgebiet, Kunde, Händler, Bestellung, Produkt und Vertriebsmitarbeiter unterstützen. Beachten Sie die Modellbeziehungen, die alle Tabellen verbinden. Diese Beziehungen verteilen Filter (direkt oder indirekt) auf die Tabelle mit den Umsätzen.
Dieser Modellentwurf unterstützt die in dieser Lektion vorgestellten Beispiele.
Definieren von Regeln
Regelausdrücke werden im Zeilenkontext ausgewertet. Zeilenkontext bedeutet, dass der Ausdruck für jede Zeile ausgewertet wird, indem die Spaltenwerte dieser Zeile verwendet werden. Wenn der Ausdruck TRUE zurückgibt, kann der Benutzer die Zeile „sehen“.
Tipp
Um mehr über Zeilenkontext zu erfahren, arbeiten Sie das Modul Hinzufügen von berechneten Tabellen und Spalten zu Power BI Desktop-Modellen durch. Dieses Modul beschreibt zwar das Hinzufügen von Modellberechnungen, enthält aber auch eine Lerneinheit, in der der Zeilenkontext vorgestellt und beschrieben wird.
Sie können Regeln definieren, die entweder statisch oder dynamisch sind.
Statische Regeln
Statische Regeln verwenden DAX-Ausdrücke, die sich auf Konstanten beziehen.
Betrachten Sie die folgende Regel, die auf die Tabelle Region angewendet wird und den Zugriff auf die Daten der Verkäufe im Mittleren Westen (Midwest) einschränkt.
'Region'[Region] = "Midwest"
In den folgenden Schritten wird erläutert, wie Power BI die Regel erzwingt. Sie hat folgende Aufgaben:
Filtert die Tabelle Region und liefert eine sichtbare Zeile (für Mittlerer Westen (Midwest)).
Verwendet die Modellbeziehung, um den Tabellenfilter Region an die Tabelle für den Bundesstaat weiterzugeben, was zu 14 sichtbaren Zeilen führt (die Region „Mittlerer Westen“ (Midwest) besteht aus 14 Bundesstaaten).
Verwendet die Modellbeziehung, um den Filter der Tabelle für den Bundesstaat an die Tabelle für die Umsätze weiterzugeben. Das Ergebnis sind Tausende von sichtbaren Zeilen (die Umsatzdaten für die Bundesstaaten, die zur Region „Mittlerer Westen“ (Midwest) gehören).
Die einfachste statische Regel, die Sie erstellen können, schränkt den Zugriff auf alle Tabellenzeilen ein. Betrachten Sie die folgende Regel, die auf die Tabelle mit den Umsatzdetails angewendet wird (nicht im Modelldiagramm dargestellt).
FALSE()
Diese Regel stellt sicher, dass Benutzer keinen Zugriff auf die Tabellendaten haben. Es könnte nützlich sein, wenn Vertriebsmitarbeiter zwar aggregierte Verkaufsergebnisse (aus der Tabelle der Umsätze), aber keine Details auf Bestellebene sehen dürfen.
Die Definition von statischen Regeln ist einfach und effektiv. Ziehen Sie in Erwägung, sie zu verwenden, wenn Sie nur wenige davon erstellen müssen, z. B. bei Adventure Works, wo es nur sechs US-Regionen gibt. Beachten Sie jedoch die Nachteile: Das Festlegen statischer Regeln kann mit erheblichem Aufwand verbunden sein, um sie zu erstellen und einzurichten. Außerdem müssten Sie das Dataset aktualisieren und neu veröffentlichen, wenn das Onboarding für neue Regionen durchgeführt wird.
Wenn Sie viele Regeln einrichten müssen und davon ausgehen, dass in Zukunft neue Regeln hinzukommen werden, sollten Sie stattdessen dynamische Regeln erstellen.
Dynamische Regeln
Dynamische Regeln verwenden spezielle DAX-Funktionen, die Umgebungswerte zurückgeben (im Gegensatz zu Konstanten). Umgebungswerte werden von drei speziellen DAX-Funktionen zurückgegeben:
USERNAME oder USERPRINCIPALNAME: Gibt den Power BI-authentifizierten Benutzer als Textwert zurück.
CUSTOMDATA: Gibt die in der Verbindungszeichenfolge übergebene CustomData-Eigenschaft zurück. Andere Berichtstools als die von Power BI, die mithilfe einer Verbindungszeichenfolge eine Verbindung mit dem Dataset herstellen, z. B. Microsoft Excel, können diese Eigenschaft festlegen.
Hinweis
Beachten Sie, dass die Funktion USERNAME den Benutzer im Format „DOMÄNE\Benutzername“ zurückgibt, wenn Sie sie in Power BI Desktop verwenden. Wenn sie jedoch im Power BI-Dienst verwendet wird, gibt sie das Format des Benutzerprinzipalnamens (UPN) zurück, etwa username@adventureworks.com. Alternativ können Sie auch die Funktion USERPRINCIPALNAME verwenden, die den Benutzer immer im Format des Benutzerprinzipalnamens zurückgibt.
Erwägen Sie einen überarbeiteten Modellentwurf, der jetzt die (ausgeblendete) Tabelle AppUser enthält. Jede Zeile der Tabelle AppUser beschreibt einen Benutzernamen und eine Region. Eine Modellbeziehung zur Tabelle Region überträgt Filter aus der Tabelle AppUser.
Die folgende Regel, die auf die Tabelle AppUser angewendet wird, beschränkt den Datenzugriff auf die Region(en) des authentifizierten Benutzers.
'AppUser'[UserName] = USERPRINCIPALNAME()
Die Definition von dynamischen Regeln ist einfach und effektiv, wenn eine Modelltabelle Werte von Benutzernamen speichert. Sie ermöglichen Ihnen die Durchsetzung eines datengesteuerten RLS-Entwurfs. Wenn z. B. Vertriebsmitarbeiter zur Tabelle AppUser hinzugefügt oder aus dieser entfernt werden (oder verschiedenen Regionen zugewiesen werden), funktioniert dieser Entwurfsansatz problemlos.
Überprüfen von Rollen
Wenn Sie Rollen erstellen, ist es wichtig, dass Sie diese testen, um sicherzustellen, dass sie die richtigen Filter anwenden. Für Datenmodelle, die in Power BI Desktop erstellt wurden, gibt es die Funktion Anzeigen als, mit der Sie den Bericht anzeigen können, wenn verschiedene Rollen erzwungen und verschiedene Werte für den Benutzernamen übergeben werden.
Einrichten von Rollenzuordnungen
Rollenzuordnungen müssen im Voraus festgelegt werden, bevor Benutzer auf Power BI-Inhalte zugreifen. Die Rollenzuordnung umfasst die Zuweisung von Microsoft Entra-Sicherheitsobjekten zu Rollen. Sicherheitsobjekte können Benutzerkonten oder Sicherheitsgruppen sein.
Tipp
Wenn möglich, empfiehlt es sich, Rollen zu Sicherheitsgruppen zuzuordnen. Auf diese Weise gibt es weniger Zuordnungen, und Sie können die Verwaltung der Gruppenmitgliedschaft an die Netzwerkadministratoren delegieren.
Bei Modellen, die mit Power BI Desktop entwickelt wurden, wird die Rollenzuordnung normalerweise im Power BI-Dienst vorgenommen. Bei Azure Analysis Services- oder SQL Server Analysis Services-Modellen erfolgt die Rollenzuordnung in der Regel in SSMS.
Weitere Informationen zum Festlegen der Sicherheit auf Zeilenebene finden Sie unter:
Sicherheit auf Zeilenebene (Row-Level Security, RLS) mit Power BI
Leitfaden zu Sicherheit auf Zeilenebene (Row-Level Security; RLS) in Power BI Desktop
Verwenden von einmaligem Anmelden (SSO) für DirectQuery-Quellen
Wenn Ihr Datenmodell über DirectQuery-Tabellen verfügt und deren Datenquelle einmaliges Anmelden (SSO) unterstützt, kann die Datenquelle Datenberechtigungen erzwingen. Auf diese Weise erzwingt die Datenbank RLS, und Power BI-Datasets und -Berichte berücksichtigen die Datenquellensicherheit.
Beachten Sie, dass Adventure Works für Vertriebsvorgänge eine Azure SQL-Datenbank verwendet, die sich im selben Mandanten wie Power BI befindet. Die Datenbank erzwingt RLS, um den Zugriff auf Zeilen in verschiedenen Datenbanktabellen zu steuern. Sie können ein DirectQuery-Modell erstellen, das eine Verbindung mit dieser Datenbank ohne Rollen herstellt, und es im Power BI-Dienst veröffentlichen. Wenn Sie die Anmeldeinformationen der Datenquelle im Power BI-Dienst festlegen, aktivieren Sie einmaliges Anmelden (SSO). Wenn Berichtsverbraucher Power BI-Berichte öffnen, übergibt Power BI ihre Identität an die Datenquelle. Die Datenquelle erzwingt dann RLS, basierend auf der Identität des Berichtsverbrauchers.
Informationen zu RLS in Azure SQL-Datenbank finden Sie unter Sicherheit auf Zeilenebene (RLS).
Hinweis
Berechnete Tabellen und berechnete Spalten, die auf eine DirectQuery-Tabelle aus einer Datenquelle mit SSO-Authentifizierung verweisen, werden im Power BI-Dienst nicht unterstützt.
Weitere Informationen zu Datenquellen, die SSO unterstützen, finden Sie unter Einmaliges Anmelden (SSO) für DirectQuery-Quellen.