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:

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. 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 Mitglieder Datasetrollen zugeordnet werden. Mitglieder können nur von Datasetbesitzern oder Arbeitsbereichsadministratoren zu Rollen zugeordnet werden. Weitere Informationen finden Sie unter Sicherheit auf Zeilenebene (row-level security; RLS) mit Power BI (Verwalten der Sicherheitseinstellungen Ihres Modells).

Bei Mitgliedern kann es sich um Benutzerkonten oder Sicherheitsgruppen handeln. Wenn möglich, sollten Sie Sicherheitsgruppen zu Datasetrollen zuordnen. Dies umfasst die Verwaltung der Mitgliedschaften in Sicherheitsgruppen in 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:

Abbildung eines Modelldiagramms. Es wird in den folgenden Abschnitten beschrieben.

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
Terminator 1 des Flussdiagramms: 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.
Terminator 2 des Flussdiagramms: Zwischen den Tabellen Date und Sales besteht eine 1:n-Beziehung.
Terminator 3 des Flussdiagramms: 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.

Vermeiden von Sicherheit auf Zeilenebene

Vermeiden Sie die Verwendung von Sicherheit auf Zeilenebene in Szenarien, in denen dies sinnvoll ist. Wenn Sie lediglich über eine geringe Anzahl von einfachen RLS-Regeln verfügen, die statische Filter anwenden, sollten Sie stattdessen die Veröffentlichung mehrerer Datasets in Betracht ziehen. Da jedes Dataset Daten für eine bestimmte Berichtsbenutzergruppe enthält, für die dieselben Datenberechtigungen gelten, werden durch die Datasets 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 Dataset für jede Vertriebsregion in unterschiedlichen Arbeitsbereichen. Die Datasets erzwingen keine Sicherheit auf Zeilenebene. Sie verwenden jedoch Abfrageparameter, um Quelldaten zu filtern. Auf diese Weise wird in jedem Arbeitsbereich dasselbe Modell veröffentlicht. Lediglich die Parameterwerte des Datasets 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:

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.

Wenn ein bestimmter Benutzer alle Daten sehen kann, greift er möglicherweise direkt im Arbeitsbereich auf Berichte zu, und es handelt sich möglicherweise um den Besitzer des Datasets. Sicherheit auf Zeilenebene wird nur in folgenden Fällen erzwungen:

  • Der Bericht wird in einer App geöffnet.
  • Der Bericht wird in einem Arbeitsbereich geöffnet, und dem Benutzer ist die Rolle Anzeigender Benutzer zugeordnet.

Nächste Schritte

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