Sicherheit auf Zeilenebene (row-level security; RLS) mit Power BI

Die Sicherheit auf Zeilenebene (Row-Level Security, RLS) schränkt den Datenzugriff für bestimmte Benutzer ein. Filter beschränken Daten auf Zeilenebene, und Sie definieren Filter innerhalb von Rollen. Im Power BI-Dienst haben Benutzer*innen, die Zugriff auf einen Arbeitsbereich haben, Zugriff auf die semantischen Modelle in diesem Arbeitsbereich. RLS schränkt den Datenzugriff nur für Benutzer mit Viewer-Berechtigungen ein. Sie gilt nicht für Administratoren, Mitglieder oder Mitwirkende.

Um RLS zu implementieren, befolgen Sie diesen allgemeinen Workflow:

1. Rollen und Regeln in Power BI Desktop mit DAX-Filterausdrücken definieren.
2. Publish das semantische Modell und melden Sie dem Power BI-Dienst.
3. Mitglieder hinzufügen zu Rollen im Power BI-Dienst.
4. Überprüfen Sie mithilfe des Features "Als Rolle testen ", um zu bestätigen, dass die Datenfilterung erwartungsgemäß funktioniert.

Sie können RLS für importierte Semantikmodelle in Power BI Desktop oder dem Power BI-Dienst konfigurieren. Außerdem können Sie die RLS für semantische Modelle konfigurieren, die „DirectQuery“ verwenden. Dies ist beispielsweise für SQL Server möglich. Für Analysis Services- oder Azure Analysis Services-Liveverbindungen konfigurieren Sie die Sicherheit auf Zeilenebene im Modell und nicht in Power BI. Die Sicherheitsoption wird nicht für semantische Liveverbindungsmodelle angezeigt.

Definieren von Rollen und Regeln in Power BI Desktop

Sie können Rollen und Regeln in Power BI Desktop definieren. Mit diesem Editor können Sie zwischen der standardmäßigen Dropdownoberfläche und einer DAX-Oberfläche umschalten. Wenn Sie etwas in Power BI veröffentlichen, werden auch die Rollendefinitionen veröffentlicht.

Definition von Sicherheits-Rollen:

1. Importieren Sie Daten in Ihren Power BI Desktop-Bericht, oder konfigurieren Sie eine DirectQuery-Verbindung.

   Hinweis

   Sie können in Power BI Desktop keine Rollen für Analysis Services-Liveverbindungen definieren. Sie müssen sie im Analysis Services-Modell definieren.

2. Wählen Sie auf der Registerkarte " Modellierung " die Option "Rollen verwalten" aus.

3. Wählen Sie im Fenster Rollen verwalten die Option Neu aus, um eine neue Rolle zu erstellen.

4. Geben Sie unter Rollen einen Namen für die Rolle an, und drücken Sie die EINGABETASTE.

   Hinweis

   Sie können eine Rolle nicht mit einem Komma definieren, z. B London,ParisRole.

5. Wählen Sie unter Tabellen auswählen die Tabelle aus, auf die Sie einen Sicherheitsfilter auf Zeilenebene anwenden möchten.

6. Verwenden Sie unter Daten filtern den Standard-Editor, um Ihre Rollen zu definieren. Die erstellten Ausdrücke geben „true“ oder „false“ als Wert zurück. Ein DAX-Filter wertet WAHR/FALSCH für jede Zeile aus. Nur Zeilen, die WAHR zurückgeben, sind sichtbar, alles andere wird vollständig entfernt.

   Hinweis

   Nicht alle in Power BI unterstützten Sicherheitsfilter auf Zeilenebene können mit dem Standard-Editor definiert werden. Zu den Einschränkungen gehören Ausdrücke, die heute nur mithilfe von DAX definiert werden können, einschließlich dynamischer Regeln wie benutzername() oder userprincipalname(). Um Rollen mit diesen Filtern zu definieren, müssen Sie den DAX-Editor verwenden.

7. Wählen Sie optional "Zu DAX-Editor wechseln" aus, um zur Verwendung des DAX-Editors zu wechseln, um Ihre Rolle zu definieren. DAX-Ausdrücke geben einen Wert von True oder False zurück. Beispiel: [Entity ID] = “Value” Der DAX-Editor ist mit einer Autovervollständigung für Formeln ausgestattet (Intellisense). Sie können das Häkchen über dem Ausdrucksfeld setzen, um den Ausdruck zu bestätigen, und die Schaltfläche X über dem Ausdrucksfeld anklicken, um Änderungen rückgängig zu machen.

   Hinweis

   Sie können benutzernamen() in diesem Ausdruck verwenden. Beachten Sie, dass benutzername() das Format " DOMÄNE\Benutzername " in Power BI Desktop aufweist. Im Power BI-Dienst und im Power BI-Berichtsserver entspricht das Format dem Benutzerprinzipalnamen des Benutzers. Verwenden Sie in diesem Ausdrucksfeld außerdem Kommas, um DAX-Funktionsargumente zu trennen, auch wenn Sie ein Gebietsschema verwenden, bei dem normalerweise Semikolons als Trennzeichen verwendet werden (z. B. Französisch oder Deutsch).

8. Sie können zurück zum Standard-Editor wechseln, indem Sie Zum Standard-Editor wechseln auswählen. Alle Änderungen, die in beiden Editoroberflächen vorgenommen werden, bleiben beim Wechsel der Oberfläche nach Möglichkeit erhalten. Wenn Sie versuchen, bei der Definition einer Rolle im DAX-Editor, die nicht im Standard-Editor definiert werden kann, zum Standard-Editor zu wechseln, wird eine Warnung angezeigt, dass beim Wechseln der Editoren einige Informationen verloren gehen könnten. Um diese Informationen beizubehalten, wählen Sie Abbrechen aus, und bearbeiten Sie nur diese Rolle im DAX-Editor.

   Hinweis

   Verwenden Sie in diesem Ausdrucksfeld Kommas, um DAX-Funktionsargumente zu trennen, auch wenn Sie ein Gebietsschema verwenden, bei dem normalerweise Semikolons als Trennzeichen verwendet werden (z. B. Französisch oder Deutsch).

9. Wählen Sie Speichern.

In Power BI Desktop ist es nicht möglich, Benutzer einer Rolle zuzuweisen. Sie können diese Zuweisung im Power BI-Dienst vornehmen. Sie können dynamische Sicherheit in Power BI Desktop aktivieren, indem Sie die DAX-Funktionen "username()" oder " userprincipalname()" verwenden und die richtigen Beziehungen konfiguriert haben.

Allgemeine DAX-Filtermuster

Die folgenden Beispiele zeigen allgemeine DAX-Filterausdrücke, die Sie beim Definieren von RLS-Rollen verwenden können:

• Statisches RLS – Schränkt Daten auf einen festen Wert ein:

  [Region] = "West"
  

• Dynamische RLS mit UPN ΓÇö Schränkt Daten basierend auf der E-Mail-Adresse des angemeldeten Benutzers ein:

  [UserEmail] = USERPRINCIPALNAME()
  

• Dynamische RLS mit BENUTZERNAME ΓÇö Schränkt Daten basierend auf der Domäne und dem Benutzernamen des Benutzers ein:

  [UserDomain] = USERNAME()
  

• Dynamisches RLS mit CUSTOMDATA — Beschränkt Daten auf Grundlage einer benutzerdefinierten Zeichenfolge, die von der Einbettungsanwendung übergeben wird:

  [AppRole] = CUSTOMDATA()
  

  Hinweis

  CUSTOMDATA() wird in erster Linie in eingebetteten Szenarien verwendet, in denen die Anwendung eine benutzerdefinierte effektive Identitätszeichenfolge über die Power BI REST-API übergibt.

Dynamische RLS ist der am häufigsten verwendete Ansatz, da eine einzelne Rollendefinition das Filtern von Daten für jeden Benutzer basierend auf einer Benutzerzuordnungstabelle in Ihrem Datenmodell ermöglicht.

Beispiel: Filtern von Umsatzdaten nach Region

Angenommen, Sie haben eine Sales Tabelle mit Spalten Region, Productund Amount. Sie möchten die Benutzer einschränken, die der Rolle "Westen" zugewiesen sind, sodass nur Zeilen angezeigt werden, in denen die Region "West" ist.

Geben Sie im DAX-Filterfeld für die Rolle "Westen" den folgenden Ausdruck ein:

[Region] = "West"

Vor dem Filtern (alle Daten):

Nach dem Filtern (Ansicht für "West"-Rollenbenutzer):

Der DAX-Ausdruck fungiert als Zeilenfilter, der jede Zeile in der Tabelle auswertet. Nur Zeilen, in denen die Region Spalte "West" entspricht, sind für Benutzer sichtbar, die dieser Rolle zugewiesen sind.

Standardmäßig werden beim Filtern mit Sicherheit auf Zeilenebene einzelne unidirektionale Filter verwendet, unabhängig davon, ob die Beziehungen als unidirektional oder bidirektional festgelegt wurden. Sie können die bidirektionale Kreuzfilterung mit Sicherheit auf Zeilenebene manuell aktivieren, indem Sie die Beziehung auswählen und das Kontrollkästchen Sicherheitsfilter in beide Richtungen anwenden aktivieren. Beachten Sie, dass wenn eine Tabelle Teil mehrerer bidirektionaler Beziehungen ist, diese Option nur für eine dieser Beziehungen ausgewählt werden kann. Aktivieren Sie dieses Kontrollkästchen, wenn Sie auch dynamische Sicherheit auf Zeilenebene auf der Serverebene implementiert haben, bei der die Sicherheit auf Zeilenebene auf dem Benutzernamen oder der Anmelde-ID basiert.

Weitere Informationen finden Sie unter Bidirektionale Cross-Filterung mit DirectQuery in Power BI und im technischen Artikel Securing the Tabular BI Semantic Model.

Bidirektionale Kreuzfilterung

Standardmäßig werden beim Filtern mit Sicherheit auf Zeilenebene einzelne unidirektionale Filter verwendet, unabhängig davon, ob die Beziehungen als unidirektional oder bidirektional festgelegt wurden.

Sie können die bidirektionale Kreuzfilterung mit Sicherheit auf Zeilenebene manuell aktivieren, indem Sie die Beziehung auswählen und das Kontrollkästchen Sicherheitsfilter in beide Richtungen anwenden aktivieren. Aktivieren Sie dieses Kontrollkästchen, wenn Sie auch dynamische Sicherheit auf Zeilenebene auf der Serverebene implementiert haben, bei der die Sicherheit auf Zeilenebene auf dem Benutzernamen oder der Anmelde-ID basiert. Wenn eine Tabelle an mehreren bidirektionalen Beziehungen teilnimmt, können Sie diese Option nur für eine dieser Beziehungen auswählen.

Weitere Informationen finden Sie unter Bidirektionale Cross-Filterung mit DirectQuery in Power BI und im technischen Artikel Securing the Tabular BI Semantic Model.

Verwalten der Sicherheitseinstellungen Ihres Modells

Um die Sicherheit Ihres semantischen Modells zu verwalten, öffnen Sie den Arbeitsbereich, in dem Sie Ihr semantisches Modell in Fabric gespeichert haben, und führen Sie die folgenden Schritte aus:

1. Wählen Sie in Fabric das Menü Weitere Optionen für ein semantisches Modell aus. Dieses Menü wird angezeigt, wenn Sie mit dem Mauszeiger auf einen Semantikmodell-Namen gehen.

   

2. Wählen Sie Sicherheit aus.

   

Sicherheit führt Sie zur Seite Sicherheit auf Rollenebene, auf der Sie Mitglieder zu einer von Ihnen erstellten Rolle hinzufügen können. Benutzer mit Mitwirkenden - oder höheren Arbeitsbereichsrollen sehen die Sicherheitsoption und können Benutzern eine Rolle zuweisen. Abhängig vom Szenario kann auch die Berechtigung zum Besitz des Semantikmodells oder die Build-Berechtigung erforderlich sein.

Rollenmitgliedschaft verwalten

Hinzufügen von Mitgliedern

Im Power BI-Dienst können Sie der Rolle ein Mitglied hinzufügen, indem Sie die E-Mail-Adresse oder den Namen des Benutzers oder der Sicherheitsgruppe eingeben. Sie können keine in Power BI erstellten Gruppen hinzufügen. Sie können Ihrer Organisation externe Mitglieder hinzufügen. Anleitungen zur Funktionsweise von RLS mit externen B2B-Gastbenutzern finden Sie unter Überlegungen für externe Benutzer (B2B-Gastbenutzer).

Sie können die folgenden Gruppen zum Einrichten der Sicherheit auf Zeilenebene verwenden.

• Verteilergruppe
• E-Mail-aktivierte Gruppe
• Microsoft Entra-Sicherheitsgruppe – Wenn die Sicherheitsgruppe externe B2B-Gastbenutzer enthält, finden Sie unter Hinweise zu externen Benutzern (B2B-Gastbenutzern) Informationen zu bekannten Einschränkungen.

Sie können sehen, wie viele Mitglieder teil der Rolle sind, indem Sie die Nummer in Klammern neben dem Rollennamen oder neben "Mitglieder" angeben.

Entfernen von Mitgliedern

Sie können Mitglieder entfernen, indem Sie das „X“ neben ihrem Namen auswählen.

Überprüfen der Rolle im Power BI-Dienst

Sie können überprüfen, ob die von Ihnen definierte Rolle im Power BI-Dienst ordnungsgemäß funktioniert, indem Sie die Rolle testen.

1. Wählen Sie Weitere Optionen (...) neben der Rolle aus.
2. Wählen Sie Test als Rolle aus.

Überprüfen Sie beim Laden des Berichts Folgendes:

• Der Bericht zeigt nur Datenzeilen an, die dem in der Rolle definierten Filterausdruck entsprechen.
• Visuelle Elemente, Tabellen und Diagramme spiegeln die gefilterten Daten wider, nicht das vollständige Dataset.
• Wenn Sie dynamische RLS verwenden, entsprechen die Daten der Benutzeridentität, die in der Kopfzeile Jetzt als angezeigt dargestellt wird.

Im Seitenkopf wird die angewandte Rolle angezeigt. Testen Sie andere Rollen, eine Kombination aus Rollen oder eine bestimmte Person, indem Sie Jetzt anzeigen als auswählen. Hier sehen Sie wichtige Details zu den Berechtigungen der zu testenden Person oder Rolle. Weitere Informationen dazu, wie Berechtigungen mit RLS interagieren, finden Sie unter RLS-Benutzeroberfläche.

Testen Sie andere Berichte, die mit dem semantischen Modell verbunden sind, indem Sie im Seitenkopf die Option Ansicht auswählen. Sie können nur Berichte testen, die sich im selben Arbeitsbereich wie Ihr semantisches Modell befinden.

Um zur normalen Ansicht zurückzukehren, wählen Sie Zurück zur Sicherheit auf Zeilenebene aus.

Verwenden der DAX-Funktion „username()“ oder „userprincipalname()“

Sie können die DAX-Funktion username() oder userprincipalname() in Ihrem Dataset verwenden. Sie können sie innerhalb von Ausdrücken in Power BI Desktop verwenden. Wenn Sie Ihr Modell veröffentlichen, wird es im Power BI-Dienst verwendet.

In Power BI Desktop gibt username() einen Benutzer im Format DOMÄNE\Benutzer und userprincipalname() einen Benutzer im Format user@contoso.com zurück.

Im Power BI-Dienst geben sowohl username() als auch userprincipalname() den Benutzerprinzipalnamen (User Principal Name, UPN) des Benutzers zurück. Das sieht einer E-Mail-Adresse ähnlich.

Verwenden von RLS mit Arbeitsbereichen in Power BI

Wenn Sie Ihren Power BI Desktop-Bericht in einem Arbeitsbereich im Power BI-Dienst veröffentlichen, werden die RLS-Rollen auf Mitglieder angewendet, denen die Viewer-Rolle im Arbeitsbereich zugewiesen ist. Auch wenn Zuschauer*innen Buildberechtigungen für das semantische Modell erhalten, gilt weiterhin RLS. Wenn beispielsweise Viewer mit Buildberechtigungen In Excel analysieren verwenden, wird Ihre Ansicht der Daten durch RLS eingeschränkt. Arbeitsbereichsmitglieder, denen Administrator, Mitglied oder Mitwirkender zugewiesen ist, verfügen über bearbeitungsberechtigungen für das semantische Modell und daher gelten RLS nicht für sie. Wenn RLS auf Personen in einem Arbeitsbereich angewendet werden soll, können Sie ihnen nur die Rolle Betrachter zuweisen. Weitere Informationen finden Sie unter Rollen in Arbeitsbereichen.

Überlegungen für externe Benutzer (B2B-Gastbenutzer)

Wenn Sie Power BI Inhalte für externe Benutzer über Microsoft Entra B2B freigeben, beachten Sie die folgenden Überlegungen für RLS.

Entra-Sicherheitsgruppen mit externen Mitgliedern

Microsoft Entra Sicherheitsgruppen, die externe B2B-Gastbenutzer enthalten, funktionieren möglicherweise nicht wie erwartet, wenn sie für die RLS-Rollenmitgliedschaft verwendet werden. In einigen Konfigurationen , insbesondere wenn der externe Benutzer über ein Gasttypkonto verfügt (anstelle eines Mitgliedskontos), wird die Gruppenmitgliedschaft des Gasts beim Erzwingen von RLS-Filtern nicht ordnungsgemäß von der Power BI-Dienst ausgewertet.

Empfohlene Problemumgehung: Anstatt externe Benutzer über Entra-Sicherheitsgruppen zu RLS-Rollen hinzuzufügen, fügen Sie sie der Rolle direkt anhand ihrer E-Mail-Adresse hinzu. Die E-Mail-Adresse wird dem B2B-Konto des Nutzers zugeordnet. Dadurch wird sichergestellt, dass Ihre Identität beim Anwenden von RLS-Filtern korrekt zugeordnet wird. Weitere Informationen finden Sie unter Verwalten der Rollenmitgliedschaft.

Für Organisationen mit vielen externen Benutzern sollten Sie die Verwendung dynamischer RLS mit USERPRINCIPALNAME() anstelle einer gruppenbasierten Rollenzuweisung in Betracht ziehen. Dieser Ansatz wertet die Identität jedes Benutzers einzeln aus und vermeidet das Problem der Gruppenmitgliedschaftsauflösung vollständig.

Weitere Informationen zum Freigeben von Inhalten für externe Benutzer finden Sie unter Distribute Power BI Inhalte für externe Gastbenutzer mit Microsoft Entra B2B.

Wenn das Problem nach Anwendung der Problemumgehung weiterhin besteht, finden Sie unter Problembehandlung: Externer Gast sieht keine Daten weitere Diagnoseschritte.

UPN-Auflösung für B2B-Gäste

Wenn ein externer B2B-Gastbenutzer auf einen Power BI Bericht zugreift, gibt die DAX-Funktion USERPRINCIPALNAME() in der Regel einen E-Mail-ähnlichen Bezeichner zurück (z. B. user@partner.com). In einigen Konfigurationen kann ein Gast-UPN im #EXT# Format zurückgegeben werden (z. B user_partner.com#EXT#@yourtenant.onmicrosoft.com. ).

Diese Unterscheidung ist für dynamische RLS wichtig. Wenn Ihre Benutzerzuordnungstabelle ein anderes Bezeichnerformat als das USERPRINCIPALNAME() zurückgibt, stimmt der Filterausdruck nicht überein, und der Gastbenutzer sieht möglicherweise keine Daten oder falsche Daten.

USERNAME()-Verhalten für B2B-Gäste

Die USERNAME() DAX-Funktion gibt die Domäne\Benutzername-ID des Benutzers zurück. Bei B2B-Gastbenutzern gibt diese Funktion in der Regel einen UPN-ähnlichen Bezeichner zurück, der je nach Konfiguration (z. B. user@partner.com) USERPRINCIPALNAME() ähnelt, und nicht das Format Domäne\Benutzername. Da USERNAME() und USERPRINCIPALNAME() häufig denselben Wert für B2B-Gäste zurückgeben, verwenden die meisten Implementierungen USERPRINCIPALNAME() für Konsistenz.

[UserEmail] = USERPRINCIPALNAME()

Enthält die UserEmail Spalte E-Mail-Adressen wie user@partner.com für interne und externe Benutzer.

Problembehandlung: Externer Gast sieht keine Daten

Wenn ein B2B-Gastbenutzer einen leeren Bericht sieht oder eine Meldung "keine Daten" empfängt, führen Sie die folgenden Schritte aus:

1. Überprüfen Sie das zurückgegebene UPN-Format – Erstellen Sie ein Testmaß mithilfe von USERPRINCIPALNAME() und zeigen Sie es in einem visuellen Kartenformat an. Lassen Sie den Gastbenutzer den Bericht anzeigen, um den tatsächlich zurückgegebenen Wert anzuzeigen.
2. Überprüfen Sie die Benutzerzuordnungstabelle – Vergewissern Sie sich, dass die Zuordnungstabelle eine Zeile mit einem Wert enthält, der exakt den Rückgabewerten für diesen Gast entspricht USERPRINCIPALNAME() .
3. Prüfen Sie die Groß-/Kleinschreibung – DAX-Zeichenfolgenvergleiche sind standardmäßig nicht auf Groß-/Kleinschreibung angewiesen, aber überprüfen Sie, ob Ihre Datenquelle keine case-sensitiven Werte eingeführt hat.
4. Überprüfen Sie mandantenübergreifende Zugriffseinstellungen – Wenn Ihre Organisation mandantenübergreifende Zugriffsrichtlinien verwendet, kann sich dies auf das UPN-Format auswirken, das für Power BI dargestellt wird.
5. Testen Sie mit dem tatsächlichen Gastbenutzer – Das Feature "Als Rolle testen " verwendet Ihre eigene Identität. Überprüfen Sie immer mit dem echten externen Gastkonto.
6. Überprüfen Sie die Rollenzuweisung – Wenn ein Gastbenutzer mehr Daten als erwartet sieht, bestätigen Sie, dass er einer RLS-Rolle zugewiesen ist. Benutzer, denen keine RLS-Rolle zugewiesen ist, sehen in der Regel keine Daten (leere Ergebnisse), da RLS erzwungen wird, aber keine übereinstimmende Rolle angewendet wird. Ein DAX-Filter wertet WAHR/FALSCH für jede Zeile aus. Nur Zeilen, die WAHR zurückgeben, sind sichtbar. Alles andere wird vollständig entfernt.

Weitere Informationen zum Freigeben von Power BI Inhalten für externe Benutzer finden Sie unter Distribute Power BI Inhalte für externe Gastbenutzer mit Microsoft Entra B2B.

Überlegungen und Einschränkungen

Hier finden Sie aktuelle Einschränkungen für die Sicherheit auf Zeilenebene für Cloudmodelle:

• Wenn Sie bereits Rollen und Regeln im Power BI-Dienst definiert haben, müssen Sie diese in Power BI Desktop neu erstellen.
• Sie können RLS nur für die semantischen Modelle definieren, die mit Power BI Desktop erstellt wurden. Wenn Sie RLS für mit Excel erstellte semantische Modell aktivieren möchten, müssen Sie Ihre Dateien zunächst in PBIX-Dateien (Power BI Desktop) konvertieren. Weitere Informationen
• Dienstprinzipale können keiner RLS-Rolle hinzugefügt werden. Entsprechend wird RLS nicht für Apps angewendet, die einen Dienstprinzipal als endgültige effektive Identität verwenden.
• Es werden nur Import- und DirectQuery-Verbindungen unterstützt. Live-Verbindungen zu Analysis Services werden im lokalen Modell verarbeitet.
• Wenn RLS aktiviert ist, kann die Verwendung der USERELATIONSHIP()-Funktion in DAX-Abfragen und -Measures zu unerwarteten Fehlern führen. Um dieses Problem zu umgehen, entwerfen Sie Ihre DAX-Ausdrücke neu, um USERELATIONSHIP() zu vermeiden und stattdessen modelweite Beziehungen oder andere DAX-Muster zu verwenden.
• Die Funktion „Anzeigen als Rolle/Testen als Rolle“ funktioniert nicht für DirectQuery-Modelle, bei denen Single Sign-On (SSO) aktiviert ist.
• Die Funktion „Als Rolle testen/Als Rolle anzeigen“ zeigt nur Berichte aus dem Arbeitsbereich „Semantische Modelle“ an.
• Die Funktion „Als Rolle testen/Als Rolle anzeigen" funktioniert nicht für paginierte Berichte.
• Die tokenbasierte Identität funktioniert nur für DirectQuery-Modelle in einer Kapazität, die mit einer Azure SQL-Datenbank-Instanz verbunden und so konfiguriert ist, dass sie die Microsoft Entra-Authentifizierung zulässt. Weitere Informationen finden Sie unter Einbetten eines Berichts mit tokenbasierter Identität
• Der Parameter "IdentityBlob" ist ein OAuth 2.0-Zugriffstoken für Azure SQL und wird nur für Datasets mit einer DirectQuery-Verbindung mit Azure SQL unterstützt. Der Mechanismus selbst ist Azure-SQL-spezifisch: Das Blob is ein Microsoft Entra Zugriffstoken, das auf https://database.windows.net/.default festgelegt ist. Es gibt keinen äquivalenten Mechanismus zur Tokenübergabe für andere Datenquellen im App-owns-data-Embedding. Weitere Informationen finden Sie in der REST-API-Referenz für GenerateToken.

Überlegungen und Einschränkungen für dynamische RLS

Wenn Sie dynamische Sicherheit auf Zeilenebene (Dynamic Row-Level Security, RLS) mit DAX-Funktionen wie USERPRINCIPALNAME(), USERNAME()oder CUSTOMDATA(), verwenden, beachten Sie die folgenden Überlegungen.

Mandantenübergreifende B2B-Szenarien

In B2B-Szenarien gibt USERPRINCIPALNAME() die Identität zurück, wie sie vom Power BI-Dienst aufgelöst wird und die je nach Mandantenkonfiguration unterschiedlich sein kann. Es kann entweder wie folgt erscheinen:

• Die E-Mail-Adresse des externen Benutzers (user@partner.com) oder
• Ein mandantenaufgelöster Wert, z. B. user_partner.com#EXT#@tenant.onmicrosoft.com

Das genaue Format ist nicht garantiert und muss in Ihrer Umgebung überprüft werden.

Wenn Ihre Benutzerzuordnungstabelle Bezeichner in einem anderen Format speichert als die USERPRINCIPALNAME() für Gastbenutzer zurückgegebenen Werte, stimmt der RLS-Filterausdruck nicht überein, und der Gast sieht keine Daten oder falsche Daten. Überprüfen Sie immer den genauen Wert, der von USERPRINCIPALNAME() für externe Benutzer in Ihrer Umgebung zurückgegeben wird.

Testen als Rollenbeschränkungen mit dynamischen RLS

Das Feature Test as role im Power BI-Dienst verwendet beim Auswerten dynamischer RLS-Ausdrücke Ihre eigene Identität. Dies bedeutet, dass USERPRINCIPALNAME()Ihr UPN zurückgegeben wird und nicht der Benutzer, den Sie simulieren möchten. Sie können "Test" nicht als Rolle verwenden, um zu sehen, was ein bestimmter B2B-Gastbenutzer oder -dienstprinzipal sehen würde.

Testen als Rolle simuliert die Rollenmitgliedschaft, repliziert aber nicht vollständig den Authentifizierungskontext eines anderen Benutzers, insbesondere für B2B-Gäste oder eingebettete Szenarien.

Um dynamische RLS für externe Benutzer zu überprüfen, melden Sie sich als tatsächlicher Gastbenutzer an, und zeigen Sie den Bericht direkt an. Dies ist die einzige Möglichkeit, zu bestätigen, dass USERPRINCIPALNAME() der erwartete Wert zurückgegeben wird und dass RLS-Filter für diesen Benutzer ordnungsgemäß übereinstimmen.

Eingebettete Szenarien mit Dienstprinzipalen

Wenn auf einen Bericht über eine eingebettete Anwendung zugegriffen wird, die sich mit einem Dienstprinzipal authentifiziert, geben USERPRINCIPALNAME() und USERNAME() die Anwendungs-ID des Dienstprinzipals oder eine leere Zeichenfolge zurück – nicht die Identität eines Endbenutzers.

Diese Funktionen geben die Endbenutzeridentität nicht zurück und können daher nicht für die Benutzerfilterung in Dienstprinzipaleinbettungsszenarien verwendet werden. Dies bedeutet, dass dynamische RLS-Filter, die auf diesen Funktionen basieren, keine Daten pro Benutzer in eingebetteten Szenarien filtern.

Um RLS pro Benutzer in eingebetteten Szenarien anzuwenden, verwenden Sie das Feature effective Identity der Power BI REST-API. Übergeben Sie das EffectiveIdentity Objekt mit dem entsprechenden Benutzernamen und den entsprechenden Rollen, wenn Sie ein Einbettungstoken generieren. Wenn Ihre RLS-Regeln CUSTOMDATA() verwenden, übergeben Sie die benutzerdefinierte Datenzeichenfolge über EffectiveIdentity.CustomData.

Weitere Informationen finden Sie unter RLS für eingebettete Szenarien für ISVs.

Beachten Sie, dass, wenn ein Power BI-Bericht auf eine Zeile mit konfiguriertem RLS verweist, dieselbe Meldung wie für ein gelöschtes oder nicht vorhandenes Feld angezeigt wird. Für diese Benutzer sieht es so aus, als sei der Bericht beschädigt.

Häufig gestellte Fragen

Frage: Was passiert, wenn ich im Power BI-Dienst bereits Rollen und Regeln für ein Dataset erstellt habe? Funktionieren sie weiterhin, wenn ich sie so belasse?
Antwort: Nein. Visuelle Elemente werden nicht richtig gerendert. Sie müssen die Rollen und Regeln in Power BI Desktop neu erstellen und anschließend im Power BI-Dienst veröffentlichen.

Frage: Kann ich solche Rollen für Analysis Services-Datenquellen erstellen?
Antwort: Ja. Das ist möglich, wenn Sie die Daten in Power BI Desktop importiert haben. Wenn Sie eine Liveverbindung verwenden, können Sie die RLS nicht im Power BI-Dienst konfigurieren. Sie definieren RLS im lokalen Analysis Services-Modell.

Frage: Kann ich mit RLS die Spalten oder Measures beschränken, auf die Benutzer Zugriff haben?
Antwort: Nein. Wenn ein Benutzer Zugriff auf eine bestimmte Datenzeile hat, sind alle Datenspalten dieser Zeile für ihn sichtbar. Um den Zugriff auf Spalten und Spaltenmetadaten einzuschränken, sollten Sie die Sicherheit auf Objektebene in Erwägung ziehen.

Frage: Kann ich bei RLS Detaildaten in Visuals ausblenden und Zugriff auf in Visuals zusammengefasste Daten erteilen?
Antwort: Nein. Sie sichern einzelne Datenzeilen, für die Benutzer werden jedoch immer entweder die Details oder die zusammengefassten Daten angezeigt.

Frage: Für meine Datenquelle sind bereits Sicherheitsrollen definiert (z. B. SQL Server-Rollen oder SAP BW-Rollen). In welcher Beziehung stehen diese Rollen und RLS?
Antwort: Die Antwort hängt davon ab, ob Sie Daten importieren oder DirectQuery verwenden. Wenn Sie Daten in das Power BI-Dataset importieren, werden die Sicherheitsrollen in der Datenquelle nicht verwendet. In diesem Fall sollten Sie RLS definieren, um Sicherheitsregeln für Benutzer zu erzwingen, die in Power BI eine Verbindung herstellen. Wenn Sie DirectQuery verwenden, werden die Sicherheitsrollen in Ihrer Datenquelle verwendet. Wenn ein Benutzer einen Bericht öffnet, sendet Power BI eine Abfrage an die zugrunde liegende Datenquelle, die Sicherheitsregeln für die Daten basierend auf den Anmeldeinformationen des Benutzers anwendet.

Frage: Kann ein Benutzer zu mehreren Rollen gehören?
Antwort: Ein Benutzer kann mehreren Rollen angehören, und die Rollen sind additiv. Wenn ein Benutzer beispielsweise der Rolle „Vertrieb“ und „Marketing“ angehört, kann er Daten für beide Rollen anzeigen.

Zugehöriger Inhalt

• Einschränken des Datenzugriffs mit Sicherheit auf Zeilenebene (RLS) für Power BI Desktop
• Power BI implementation planning: Report consumer security planning (Power BI-Implementierungsplanung: Bericht zur Planung der Consumersicherheit)
• RLS für eingebettete Szenarien für ISVs
• Zuteilen Power BI Inhalte für externe Gastbenutzer mit Microsoft Entra B2B

Haben Sie Fragen? Versuchen Sie, die Power BI-Community zu fragen Vorschläge? Einbringen von Ideen zur Verbesserung von Power BI