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.

Erwägen Sie ein Modell mit zwei Rollen: Die erste Rolle mit dem Namen Worker beschränkt den Zugriff auf alle Payroll Tabellenzeilen mithilfe des folgenden Regelausdrucks:

FALSE()

Hinweis

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

Eine zweite Rolle namens "Manager" ermöglicht jedoch den Zugriff auf alle Payroll Tabellenzeilen mithilfe des folgenden Regelausdrucks:

TRUE()

Bitte beachten Sie: Sollte ein Berichtbenutzer beiden Rollen zugeordnet sein, werden alle Payroll Tabellenzeilen angezeigt.

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 oft effizienter, RLS-Filter für Bemaßungstabellen zu erzwingen und keine 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 den Semantikmodellrollen 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. Es umfasst die Verwaltung von Sicherheitsgruppenmitgliedschaften in der Microsoft Entra-ID. 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“. Manager können alle Zeilen sehen, Aber Mitarbeiter können nur Zeilen sehen, in denen der Type Spaltenwert intern ist.

Es wurde der folgende Regelausdruck definiert:

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

Das Problem mit diesem Regelausdruck besteht darin, dass alle Werte außer Worker alle Tabellenzeilen zurückgeben. Ein versehentlicher Wert wie Wrker gibt also unbeabsichtigt alle Tabellenzeilen zurück. 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 Salesperson Tabelle wird eine Zeile pro Verkäufer gespeichert. Sie enthält die Spalte, in der EmailAddress die E-Mail-Adresse für jeden Verkäufer gespeichert wird. Diese Tabelle ist ausgeblendet.
  • Die Sales Tabelle speichert eine Zeile pro Reihenfolge. Es umfasst das Revenue % All Region Maß, das dazu ausgelegt ist, das Verhältnis der Einnahmen der Region des Berichtsbenutzers zu den Einnahmen aller Regionen zurückzugeben.
  • Die Date Tabelle speichert eine Zeile pro Datum und ermöglicht das Filtern und Gruppieren von Jahr und Monat.
  • Dies SalesRevenueSummary ist eine berechnete Tabelle. In dieser Tabelle wird der Gesamtumsatz für jedes Auftragsdatum gespeichert. Diese Tabelle ist ausgeblendet.

Der folgende Ausdruck definiert die SalesRevenueSummary berechnete Tabelle:

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 Salesperson Tabelle angewendet:

[EmailAddress] = USERNAME()

In der folgenden Tabelle werden die drei Modellbeziehungen beschrieben:

Beziehung BESCHREIBUNG
Terminator 1 des Flussdiagramms: Es gibt eine viele-zu-viele-Beziehung zwischen den Tabellen Salesperson und Sales. Die RLS-Regel filtert die EmailAddress Spalte der ausgeblendeten Salesperson Tabelle mithilfe der USERNAME DAX-Funktion. Der Region Spaltenwert (für den Berichtsbenutzer) wird an die Sales Tabelle weitergegeben.
Terminator 2 des Flussdiagramms: Es gibt eine eins-zu-viele-Beziehung zwischen den Date- und Sales-Tabellen.
Terminator 3 des Flussdiagramms: Es gibt eine 1:n-Beziehung zwischen den Tabellen Date und SalesRevenueSummary.

Der folgende Ausdruck definiert das Revenue % All Region Maß:

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:

  • Verbesserte Abfrageleistung: Sie kann aufgrund weniger Filter zu einer verbesserten Leistung führen.
  • Kleinere Modelle: Obwohl es zu mehr Modellen führt, sind sie kleiner in der Größe. 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: Power BI-Features, die nicht mit RLS funktionieren, z. B. " Im Web veröffentlichen", können verwendet werden.

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

  • Mehrere Arbeitsbereiche: Für jede Benutzergruppe des Berichts 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 hohen Berechtigungen: Benutzer mit hohen Berechtigungen, die zu mehreren Benutzergruppen des Berichts gehö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:

  • Last updated on