Leitfaden zu Sicherheit auf Zeilenebene (Row-Level Security; RLS) in Power BI Desktop

Dieser Artikel ist an Modellierer von Daten gerichtet, die mit Power BI Desktop arbeiten. Er umfasst empfohlene Entwurfsmethoden, um Sicherheit auf Zeilenebene in Ihren Datenmodellen zu erzwingen.

Bei RLS-Filtern ist es wichtig, die Funktionsweise von Tabellenzeilen zu verstehen. Bei Tabellenzeilen kann der Zugriff auf Modellobjekte (einschließlich Tabellen, Spalten oder Measures) nicht eingeschränkt werden.

Hinweis

Die Funktion „Sicherheit auf Zeilenebene“ und ihre Einrichtung werden in diesem Artikel nicht beschrieben. Weitere Informationen finden Sie unter Einschränken des Datenzugriffs mit Sicherheit auf Zeilenebene (RLS) für Power BI Desktop.

Auch das Erzwingen von Sicherheit auf Zeilenebene in Liveverbindungen mit extern gehosteten Modellen mithilfe von Azure Analysis Services oder SQL Server Analysis Services wird nicht erläutert. In diesen Fällen wird Sicherheit auf Zeilenebene von Analysis Services erzwungen. Wenn Power BI per Single Sign-On (SSO) verbunden wird, wird Sicherheit auf Zeilenebene durch Analysis Services erzwungen (sofern das Konto nicht über Administratorrechte verfügt).

Erstellen von Rollen

Es ist möglich, mehrere Rollen zu erstellen. Beim Bestimmen der erforderlichen Berechtigungen für einen einzelnen Berichtsbenutzer sollten Sie versuchen, eine einzige Rolle zu erstellen, mit der all diese Berechtigungen erteilt werden. Diese Vorgehensweise sollte dem Zuweisen eines Berichtsbenutzers zu mehreren Rollen vorgezogen werden. Der Grund dafür ist, dass ein Berichtsbenutzer mehreren Rollen zugeordnet werden kann (entweder direkt über das Benutzerkonto oder indirekt durch eine Mitgliedschaft in Sicherheitsgruppen). Mehrere Rollenzuordnungen können jedoch zu unerwarteten Ergebnissen führen.

Wenn ein Berichtsbenutzer mehreren Rollen zugewiesen wird, werden RLS-Filter additiv. Das bedeutet, dass Berichtsbenutzer Tabellenzeilen sehen können, die eine Kombination dieser Filter darstellen. In einigen Szenarien kann außerdem nicht garantiert werden, dass ein Berichtsbenutzer bestimmte Zeilen in einer Tabelle nicht sehen kann. Im Gegensatz zu Berechtigungen, die auf SQL Server-Datenbankobjekte (und andere Berechtigungsmodelle) angewendet werden, gilt das Prinzip „einmal verweigert, immer verweigert“ also nicht.

Angenommen, Sie verfügen über ein Modell mit zwei Rollen: Mit der ersten Rolle Mitarbeiter wird mithilfe des folgenden Regelausdrucks der Zugriff auf alle Zeilen der Tabelle Gehaltsabrechnung eingeschränkt:

FALSE()

Hinweis

Wenn das Ergebnis des Ausdrucks FALSE ist, gibt die Regel keine Tabellenzeilen zurück.

Allerdings wird mit der zweiten Rolle Führungskräfte Zugriff auf alle Zeilen der Tabelle Gehaltsabrechnung gewährt. Dazu wird folgender Regelausdruck verwendet:

TRUE()

Gehen Sie also mit Bedacht vor: Wenn einem Berichtsbenutzer beide Rollen zugeordnet sind, sieht er alle Zeilen in der Tabelle Gehaltsabrechnung.

Optimieren von Sicherheit auf Zeilenebene

Bei Sicherheit auf Zeilenebene werden automatisch Filter auf jede DAX-Abfrage angewendet. Diese Filter können sich negativ auf die Abfrageleistung auswirken. Daher ist ein ausgereifter Modellentwurf für effiziente Sicherheit auf Zeilenebene entscheidend. Es ist wichtig, unsere Leitfäden für den Modellentwurf zu befolgen, wie in den folgenden Artikeln beschrieben:

• Informationen zum Sternschema und dessen Wichtigkeit für Power BI
• Alle Leitfadenartikel zu Beziehungen in der Dokumentation zum Power BI-Leitfaden

Im Allgemeinen ist es effizienter, RLS-Filter bei Dimensionstabellen zu erzwingen als bei Faktentabellen. Außerdem sollten durchdachte Beziehungen definiert werden, damit RLS-Filter auf andere Modelltabellen übertragen werden. RLS-Filter werden nur über aktive Beziehungen weitergegeben. Vermeiden Sie also die DAX-Funktion LOOKUPVALUE, wenn Modellbeziehungen dasselbe Ergebnis zur Folge haben könnten.

Wenn RLS-Filter bei DirectQuery-Tabellen erzwungen werden und Beziehungen zu anderen DirectQuery-Tabellen vorhanden sind, muss die Quelldatenbank optimiert werden. Dieser Vorgang kann das Entwerfen geeigneter Indizes oder das Verwenden persistenter berechneter Spalten umfassen. Weitere Informationen finden Sie unter Leitfaden für das DirectQuery-Model in Power BI Desktop.

Messen der Auswirkungen von Sicherheit auf Zeilenebene

Die Auswirkungen von RLS-Filtern auf die Leistung lassen sich in Power BI Desktop mithilfe der Leistungsanalyse messen. Ermitteln Sie dazu zunächst die Dauer von Abfragen für visuelle Berichtselemente, wenn Sicherheit auf Zeilenebene nicht erzwungen wird. Verwenden Sie dann auf der Registerkarte Modellierung des Menübands den Befehl Anzeigen als, um Sicherheit auf Zeilenebene zu erzwingen, und vergleichen Sie die Dauer der Abfragen.

Konfigurieren von Rollenzuordnungen

Nach der Veröffentlichung in Power BI müssen Sie Member zu semantischen Modellrollen (früher als Dataset bezeichnet) zuordnen. Nur Besitzer eines semantischen Modells oder Arbeitsbereich-Administratoren können Mitglieder zu Rollen hinzufügen. Weitere Informationen finden Sie unter Sicherheit auf Zeilenebene (row-level security; RLS) mit Power BI (Verwalten der Sicherheitseinstellungen Ihres Modells).

Mitglieder können Benutzerkonten, Sicherheitsgruppen, Verteilergruppen oder E-Mail-aktivierte Gruppen sein. Wann immer möglich, empfehlen wir Ihnen, Sicherheitsgruppen den Rollen des semantischen Modells zuzuordnen. Dazu gehört die Verwaltung von Sicherheitsgruppenmitgliedschaften in Microsoft Entra ID (ehemals Azure Active Directory). Möglicherweise wird die Aufgabe an Ihre Netzwerkadministratoren delegiert.

Überprüfen von Rollen

Testen Sie jede Rolle, um sicherzustellen, dass das Modell ordnungsgemäß gefiltert wird. Führen Sie dazu einfach den Befehl Anzeigen als auf der Registerkarte Modellierung des Menübands aus.

Wenn das Modell über dynamische Regeln verfügt, für die die DAX-Funktion USERNAME verwendet wird, müssen erwartete und unerwartete Werte getestet werden. Beim Einbetten von Power BI-Inhalten – insbesondere im Szenario Einbetten für Ihre Kunden – kann App-Logik einen beliebigen Wert als Benutzernamen für eine effektive Identität übergeben. Stellen Sie wenn möglich sicher, dass versehentlich oder böswillig übergebene Werte zu Filtern führen, die keine Zeilen zurückgeben.

Gehen wir von folgendem Beispiel aus: Bei Verwendung von Power BI Embedded übergibt die App das Aufgabengebiet eines Benutzers als effektiven Benutzernamen: Der Wert lautet entweder „Führungskraft“ oder „Mitarbeiter“. Führungskräfte können alle Zeilen sehen, Mitarbeiter können lediglich auf Zeilen zugreifen, bei denen der Wert der Spalte Typ „Intern“ lautet.

Es wurde der folgende Regelausdruck definiert:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Das Problem bei diesem Regelausdruck ist, dass bei allen Werten außer „Mitarbeiter“ alle Tabellenzeilen zurückgegeben werden. Wenn also versehentlich der Wert „Mtarbeiter“ übergeben wird, werden alle Tabellenzeilen zurückgegeben. Aus diesem Grund ist es sicherer, einen Ausdruck zu schreiben, mit dem jeder unerwartete Wert getestet wird. Beim folgenden verbesserten Regelausdruck hat ein unerwarteter Wert zur Folge, dass die Tabelle keine Zeilen zurückgibt.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Entwerfen von partieller Sicherheit auf Zeilenebene

Mitunter sind für Berechnungen Werte erforderlich, die nicht durch RLS-Filter eingeschränkt sind. Beispiel: In einem Bericht soll der Umsatzanteil der Vertriebsregion des Berichtsnutzers am gesamten Umsatz angezeigt werden.

Da es nicht möglich ist, Sicherheit auf Zeilenebene mit einem DAX-Ausdruck außer Kraft zu setzen (mit einem solchen Ausdruck lässt sich nicht einmal ermitteln, ob Sicherheit auf Zeilenebene erzwungen wird), können Sie eine Zusammenfassungsmodelltabelle verwenden. Die Zusammenfassungsmodelltabelle wird abgefragt, um Umsätze für „alle Regionen“ abzurufen. Für diese Tabelle gelten keine Einschränkungen durch RLS-Filter.

Sehen wir uns nun an, wie Sie diese Entwurfsanforderung implementieren können. Betrachten wir zunächst den folgenden Modellentwurf:

Das Modell umfasst vier Tabellen:

• In der Tabelle Salesperson wird eine Zeile pro Vertriebsmitarbeiter gespeichert. Sie umfasst die Spalte EmailAddress, in der die E-Mail-Adresse der Vertriebsmitarbeiter gespeichert ist. Diese Tabelle ist ausgeblendet.
• In der Tabelle Sales wird eine Zeile pro Auftrag gespeichert. Sie umfasst das Measure Revenue % All Region, mit dem der Umsatzanteil der Region des Berichtsbenutzers am Gesamtumsatz aller Regionen zurückgegeben wird.
• In der Tabelle Date wird pro Zeile ein Datum gespeichert. Diese Tabelle lässt sich nach dem Jahr und nach dem Monat filtern und gruppieren.
• SalesRevenueSummary ist eine berechnete Tabelle. In dieser Tabelle wird der Gesamtumsatz für jedes Auftragsdatum gespeichert. Diese Tabelle ist ausgeblendet.

Mit dem folgenden Ausdruck wird die berechnete Tabelle SalesRevenueSummary definiert:

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Hinweis

Dieselbe Entwurfsanforderung ließe sich mit einer Aggregationstabelle erfüllen.

Die folgende RLS-Regel wird auf die Tabelle Salesperson angewendet:

[EmailAddress] = USERNAME()

In der folgenden Tabelle werden die drei Modellbeziehungen beschrieben:

Beziehung	BESCHREIBUNG
	Zwischen den Tabellen Salesperson und Sales besteht eine m:n-Beziehung. Die RLS-Regel filtert die Spalte EmailAddress der verborgenen Tabelle Salesperson mithilfe der DAX-Funktion USERNAME. Der Wert der Spalte Region (für den Berichtsbenutzer) wird an die Tabelle Sales übergeben.
	Zwischen den Tabellen Date und Sales besteht eine 1:n-Beziehung.
	Zwischen den Tabellen Date und SalesRevenueSummary besteht eine 1:n-Beziehung.

Mit dem folgenden Ausdruck wird das Measure Revenue % All Region definiert:

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Hinweis

Gehen Sie sorgfältig vor, um die Offenlegung vertraulicher Daten zu verhindern. Wenn in diesem Beispiel nur zwei Regionen vorhanden sind, könnte ein Berichtsbenutzer den Umsatz für die andere Region berechnen.

Wann sollte die Verwendung von RLS vermieden werden?

Manchmal ist es sinnvoll, die Verwendung von RLS zu vermeiden. Wenn Sie lediglich über wenige einfache RLS-Regeln verfügen, die statische Filter anwenden, sollten Sie stattdessen die Veröffentlichung mehrerer semantischer Modelle in Betracht ziehen. Da jedes semantische Modell Daten für eine bestimmte Berichtsbenutzergruppe enthält, für die dieselben Datenberechtigungen gelten, werden durch die semantischen Modelle keine Rollen definiert. Erstellen Sie anschließend einen Arbeitsbereich für jede Benutzergruppe, und weisen Sie dem Arbeitsbereich oder der App Zugriffsberechtigungen zu.

Beispiel: Ein Unternehmen, das lediglich über zwei Vertriebsregionen verfügt, veröffentlicht ein semantisches Modell für jede Vertriebsregion in unterschiedlichen Arbeitsbereichen. Die semantischen Modelle erzwingen keine RLS. Sie verwenden jedoch Abfrageparameter, um Quelldaten zu filtern. Auf diese Weise wird in jedem Arbeitsbereich dasselbe Modell veröffentlicht. Lediglich die Parameterwerte des semantischen Modells unterscheiden sich. Vertriebsmitarbeiter erhalten jeweils nur für einen Arbeitsbereich (oder eine veröffentlichte App) Zugriff.

Das Vermeiden von Sicherheit auf Zeilenebene hat eine Reihe von Vorteilen:

• Höhere Abfrageleistung: Da weniger Filter verwendet werden, kann eine verbesserte Leistung erzielt werden.
• Kleinere Modelle: Wenngleich eine größere Anzahl von Modellen vorhanden ist, sind die Modelle selbst weniger umfangreich. Durch kleinere Modelle lässt sich die Reaktionszeit bei Abfragen und Datenaktualisierungen verbessern. Dies trifft insbesondere dann zu, wenn es bei der hostenden Kapazität zu einer hohen Ressourcenauslastung kommt. Darüber hinaus ist es einfacher, die von Ihrer Kapazität festgelegten Grenzwerte für die Modellgröße einzuhalten. Zudem lassen sich Workloads besser auf unterschiedliche Kapazitäten verteilen, da Sie Arbeitsbereiche auf unterschiedlichen Kapazitäten erstellen bzw. in diese Kapazitäten verschieben können.
• Zusätzliche Features: Sie können Power BI-Features nutzen, die mit Sicherheit auf Zeilenebene nicht funktionieren (z. B. Im Web veröffentlichen).

Allerdings müssen auch einige Nachteile berücksichtigt werden, wenn Sie Sicherheit auf Zeilenebene vermeiden:

• Mehrere Arbeitsbereiche: Für jede Berichtsbenutzergruppe ist ein Arbeitsbereich erforderlich. Wenn Apps veröffentlicht werden, ist zudem eine App pro Berichtsbenutzergruppe vorhanden.
• Duplizierung von Inhalten: Berichte und Dashboards müssen in jedem Arbeitsbereich erstellt werden. Für Einrichtung und Verwaltung muss ein höherer Zeit- und Arbeitsaufwand eingeplant werden.
• Benutzer mit erhöhten Rechten: Benutzer mit erhöhten Rechten, die mehreren Berichtsbenutzergruppen angehören, können keine konsolidierte Ansicht der Daten anzeigen. Stattdessen müssen diese Benutzer mehrere Berichte (in unterschiedlichen Arbeitsbereichen oder Apps) öffnen.

Problembehandlung bei Sicherheit auf Zeilenebene

Wenn bei Sicherheit auf Zeilenebene unerwartete Ergebnisse auftreten, sollten Sie folgende Bereiche auf Probleme untersuchen:

• Falsche Beziehungen zwischen Modelltabellen (Spaltenzuordnungen und Filterrichtungen). Bedenken Sie, dass RLS-Filter nur über aktive Beziehungen weitergegeben werden.
• Die Beziehungseigenschaft Sicherheitsfilter in beide Richtungen anwenden ist nicht ordnungsgemäß gesetzt. Weitere Informationen finden Sie im Leitfaden zu bidirektionalen Beziehungen.
• Tabellen enthalten keine Daten.
• In Tabellen werden falsche Werte geladen.
• Der Benutzer ist mehreren Rollen zugeordnet.
• Das Modell umfasst Aggregationstabellen, und Aggregationen und Details werden nicht einheitlich von RLS-Regeln gefiltert. Weitere Informationen finden Sie unter Verwenden von Aggregationen in Power BI Desktop (Sicherheit auf Zeilenebene für Aggregationen).

Wenn ein bestimmter Benutzer keine Daten anzeigen kann, liegt es möglicherweise daran, dass sein UPN nicht gespeichert oder falsch eingegeben wurde. Dies kann abrupt geschehen, weil das Benutzerkonto aufgrund einer Namensänderung geändert wurde.

Tipp

Fügen Sie zu Testzwecken ein Measure hinzu, das die DAX-Funktion USERNAME zurückgibt. Sie können einen Namen wie „Wer bin ich“ wählen. Fügen Sie das Measure dann zu einem visuellen Kartenelement in einem Bericht hinzu, und veröffentlichen Sie es in Power BI.

Ersteller und Consumer, die nur über eine Leseberechtigung für das semantische Modell verfügen, können nur die Daten anzeigen, die sie anzeigen dürfen (basierend auf ihrer RLS-Rollenzuordnung).

Wenn ein Benutzer einen Bericht in einem Arbeitsbereich oder einer App anschaut, kann RLS je nach den Berechtigungen des semantischen Modells erzwungen werden oder nicht. Aus diesem Grund ist es wichtig, dass Nutzer und Ersteller von Inhalten nur dann die Berechtigung „Lesen“ für das zugrunde liegende Semantikmodell besitzen, wenn RLS erzwungen werden muss. Ausführliche Informationen zu den Berechtigungsregeln, mit denen bestimmt wird, ob RLS erzwungen wird, finden Sie im Artikel Report consumer security planning (Bericht zur Planung der Consumersicherheit).

Zugehöriger Inhalt

Weitere Informationen zu diesem Artikel finden Sie in den folgenden Ressourcen:

• Sicherheit auf Zeilenebene (Row-Level Security, RLS) mit Power BI
• Einschränken des Datenzugriffs mit Sicherheit auf Zeilenebene (RLS) für Power BI Desktop
• Modellieren von Beziehungen in Power BI Desktop
• Power BI implementation planning: Report consumer security planning (Power BI-Implementierungsplanung: Bericht zur Planung der Consumersicherheit)
• Haben Sie Fragen? Stellen Sie Ihre Frage in der Power BI-Community.
• Vorschläge? Einbringen von Ideen zur Verbesserung von Power BI