Sicherheit auf Zeilenebene in Power BI: Mandantenfähiger Datenzugriff

Sicherheit auf Zeilenebene (RLS) ist der Mechanismus, der sicherstellt, dass jeder Benutzer nur die Daten sieht, zu deren Zugriff er berechtigt ist. In einer Umgebung mit mehreren Mandanten oder mehreren Abteilungen ist RLS nicht optional – es ist der Unterschied zwischen einer verwalteten Analyseplattform und einer Datenpanne, die darauf wartet, passiert zu werden. Dennoch deuten Microsofts eigene Nutzungstelemetrie darauf hin, dass weniger als 30 Prozent der Unternehmen mit Power BI Premium RLS in ihren Produktionsdatensätzen implementiert haben.

Der Grund liegt nicht darin, dass RLS konzeptionell schwierig ist. Der Grund dafür ist, dass die Implementierungsdetails nuanciert sind, der Testprozess manuell erfolgt und die Interaktion zwischen RLS und anderen Power BI-Funktionen (DirectQuery, zusammengesetzte Modelle, Einbettung, Aggregationen) Grenzfälle schafft, die Teams überraschen. Dieser Leitfaden deckt jeden Aspekt der RLS-Implementierung ab, von der einfachsten statischen Rolle bis hin zu komplexer dynamischer Sicherheit mit Azure Active Directory-Integration.

---

Wichtige Erkenntnisse

– Die Sicherheit auf Zeilenebene in Power BI filtert Daten auf Modellebene mithilfe von DAX-Ausdrücken und stellt so sicher, dass Benutzer die Sicherheit nicht durch Ändern von Berichten oder Visuals umgehen können – Statisches RLS codiert Filterwerte fest (geeignet für kleine, stabile Benutzergruppen), während dynamisches RLS DAX-Funktionen wie USERNAME() und USERPRINCIPALNAME() verwendet, um dynamisch basierend auf dem angemeldeten Benutzer zu filtern – RLS funktioniert nur im Import- und DirectQuery-Modus – es gilt nicht für Live-Verbindungen zu Analysis Services (die über ein eigenes RLS verfügen).

• Die Sicherheit auf Objektebene (OLS) verbirgt ganze Tabellen oder Spalten und ergänzt RLS für Szenarien, in denen Benutzer nicht einmal wissen sollten, dass bestimmte Daten vorhanden sind – Zum Testen von RLS ist die Funktion „Anzeigen als“ in Power BI Desktop und Service erforderlich. Gehen Sie niemals davon aus, dass RLS ohne explizite Tests für jede Rolle funktioniert – RLS in eingebetteten Szenarien (Power BI Embedded) erfordert die Übergabe der effektiven Identität im Einbettungstoken, was eine häufige Ursache für Implementierungsfehler ist – Die Auswirkungen von RLS auf die Leistung betragen bei gut gestalteten Modellen normalerweise weniger als 5 Prozent, aber schlecht geschriebene DAX-Filter können die Leistung um 50 Prozent oder mehr beeinträchtigen

---

Grundlegendes zur Sicherheit auf Zeilenebene

Was RLS macht

RLS wendet DAX-Filterausdrücke auf eine oder mehrere Tabellen in einem Power BI-Datenmodell an. Wenn ein Benutzer einen Bericht öffnet, wertet Power BI die RLS-Regeln aus und filtert stillschweigend Zeilen heraus, für deren Anzeige der Benutzer keine Berechtigung hat. Der Benutzer erhält einen normalen Bericht – er kann einfach keine Daten außerhalb seines Bereichs sehen.

Entscheidend ist, dass RLS auf der Datenmodellebene und nicht auf der Berichtsebene arbeitet. Das bedeutet:

– Benutzer können RLS nicht umgehen, indem sie ihre eigenen Berichte für denselben Datensatz erstellen

• RLS-Filter verbreiten sich über Beziehungen (ein Filter auf Dim_Region filtert Fact_Sales automatisch über die Beziehung).
• DAX-Maßnahmen berücksichtigen den RLS-Kontext (CALCULATE, SUMX und andere Funktionen arbeiten mit der gefilterten Teilmenge)
• Beim Export nach Excel, CSV oder PowerPoint werden nur die Daten exportiert, zu deren Anzeige der Benutzer berechtigt ist

RLS im Vergleich zu anderen Sicherheitsmechanismen

RLS ist der einzige Mechanismus, der steuert, auf welche spezifischen Datenzeilen ein Benutzer zugreifen kann. Die anderen Mechanismen steuern den Zugriff auf Arbeitsbereichs-, Berichts- oder Objektebene.

---

Statische Sicherheit auf Zeilenebene

Statisches RLS weist Benutzer Rollen mit fest codierten Filterwerten zu. Dies ist die einfachste Implementierung und eignet sich gut für Szenarien mit einer kleinen Anzahl fester Regionen, Abteilungen oder Geschäftseinheiten.

Erstellen einer statischen Rolle

In Power BI Desktop:

1. Gehen Sie zu Modellierung und dann zu Rollen verwalten
2. Klicken Sie auf Erstellen, um eine neue Rolle hinzuzufügen
3. Benennen Sie die Rolle (z. B. „Nordamerika-Vertrieb“).
4. Wählen Sie die zu filternde Tabelle aus (z. B. Dim_Region).
5. Schreiben Sie den DAX-Filterausdruck:

[Region] = "North America"

Dieser Ausdruck bedeutet: Wenn einem Benutzer die Rolle „Nordamerika-Vertrieb“ zugewiesen wird, zeigt jede Tabelle, die sich auf Dim_Region bezieht, nur Zeilen an, deren Region Nordamerika ist. Ein Benutzer, der einen Verkaufsbericht ansieht, sieht nur nordamerikanische Verkäufe. Ein Benutzer, der ein HR-Dashboard anzeigt (wenn es über eine regionale Dimension verbunden ist), sieht nur nordamerikanische Mitarbeiter.

Mehrere Rollen

Sie können mehrere Rollen mit unterschiedlichen Filtern erstellen:

• EMEA-Verkäufe: [Region] = "EMEA"
• APAC-Verkäufe: [Region] = "APAC"
• Global Executive: Kein Filter (sieht alle Daten)

Einem Benutzer können mehrere Rollen zugewiesen werden. Bei der Zuweisung zu mehreren Rollen werden die Filter mit der ODER-Logik kombiniert – der Benutzer sieht die Vereinigung aller Rollendaten. Beispielsweise sieht ein Benutzer, der sowohl „Nordamerika-Verkäufe“ als auch „EMEA-Verkäufe“ zugewiesen ist, Daten aus beiden Regionen.

Einschränkungen von statischem RLS

Statisches RLS wird unkontrollierbar, wenn:

• Sie haben mehr als 10–15 unterschiedliche Filterwerte (das Erstellen und Verwalten von mehr als 15 Rollen ist mühsam)
• Benutzer-zu-Rollen-Zuweisungen ändern sich häufig (jede Änderung erfordert einen Power BI-Administrator)
• Die Filterlogik ist komplexer als eine einfache Gleichheit (z. B. sollten Manager die Daten ihres Teams plus ihre eigenen sehen)
• Sie haben Hunderte von Benutzern in Dutzenden von Geschäftsbereichen

Für diese Szenarien ist dynamisches RLS die Lösung.

---

Dynamische Sicherheit auf Zeilenebene

Dynamic RLS verwendet DAX-Funktionen, die zur Laufzeit auswerten, um den angemeldeten Benutzer zu ermitteln und entsprechende Filter anzuwenden. Die beiden Schlüsselfunktionen sind:

• USERNAME() – Gibt den Domänen\Benutzernamen oder UPN des aktuellen Benutzers zurück
• USERPRINCIPALNAME() – Gibt die E-Mail/UPN des aktuellen Benutzers zurück (empfohlen für Cloud-Bereitstellungen)

Dynamisches RLS einrichten

Schritt 1: Erstellen Sie eine Sicherheitszuordnungstabelle

Diese Tabelle ordnet Benutzer ihrem autorisierten Datenbereich zu. Es kann in der Datenquelle (Datenbank), einer SharePoint-Liste oder einer Excel-Datei gespeichert werden:

Importieren Sie diese Tabelle als SecurityMapping in Ihr Power BI-Modell.

Schritt 2: Erstellen Sie die RLS-Rolle

Erstellen Sie eine einzelne Rolle (z. B. „DynamicSecurity“) mit einem DAX-Filter für die Sicherheitszuordnungstabelle:

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

Schritt 3: Beziehungen erstellen

Stellen Sie Beziehungen von SecurityMapping zu Ihren Dimensionstabellen her:

• SecurityMapping[Region] zu Dim_Region[Region]
• SecurityMapping[Abteilung] zu Dim_Department[Abteilung]
• SecurityMapping[CompanyId] zu Dim_Company[CompanyId]

Diese Beziehungen müssen von der Dimension zur Sicherheitszuordnungstabelle eine Eins-zu-viele-Beziehung sein, oder Sie können einen bidirektionalen Kreuzfilter verwenden. Bidirektionale Filter haben jedoch Auswirkungen auf die Leistung – ein besserer Ansatz verwendet CROSSFILTER oder TREATAS im DAX-Ausdruck.

Schritt 4: Alternative ohne Beziehungen (TREATAS-Ansatz)

Anstatt Beziehungen aus der Sicherheitszuordnungstabelle zu erstellen, können Sie TREATAS im RLS-Ausdruck direkt in der Faktentabelle verwenden:

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

Dieser Ansatz vermeidet die Komplexität zusätzlicher Beziehungen und hält die Sicherheitslogik in sich geschlossen.

Dynamisches RLS mit Managerhierarchie

Eine häufige Anforderung besteht darin, dass Manager Daten für ihre gesamte Berichtskette sehen müssen. Dies erfordert eine Eltern-Kind-Hierarchie in der Mitarbeiter- oder Benutzertabelle.

Ansatz 1: PATH-Funktion

Wenn Ihre Benutzertabelle eine ManagerId-Spalte enthält, verwenden Sie die PATH-Funktion von DAX:

UserPath = PATH(Users[UserId], Users[ManagerId])

Dann im RLS-Ausdruck:

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

Dieser Ausdruck gibt TRUE für die eigenen Daten des aktuellen Benutzers und alle Daten zurück, die zu seinen direkten und indirekten Berichten gehören.

Ansatz 2: Abgeflachte Sicherheitstabelle

Berechnen Sie die Hierarchie in Ihrem ETL-Prozess vorab und erstellen Sie eine flache Sicherheitszuordnung, in der jeder Manager mit allen Datenbereichen seiner Berichte aufgeführt ist. Dies ist zur Abfragezeit leistungsfähiger, da der Overhead der PATH-Auswertung vermieden wird.

---

Sicherheit auf Objektebene (OLS)

Die Sicherheit auf Objektebene verbirgt ganze Tabellen oder Spalten vor Benutzern. Im Gegensatz zu RLS, das Zeilen filtert, macht OLS Tabellen oder Spalten vollständig unsichtbar – sie erscheinen nicht in der Feldliste und jede visuelle Referenzierung eines ausgeblendeten Felds zeigt einen Fehler an.

Wann man OLS verwendet

• Ausblenden von Gehaltsspalten in HR-Datensätzen für Nicht-HR-Benutzer
• Ausblenden kostenbezogener Tabellen für Vertriebsteams, die nur Einnahmen sehen sollten
• Verbergen der personenbezogenen Daten des Kunden (E-Mail, Telefon, Adresse) vor Analysten, die nur aggregierte Daten benötigen
• Ausblenden strategischer Preisspalten für allgemeine Benutzer

OLS konfigurieren

OLS wird über den Tabelleneditor (ein externes Tool) oder XMLA-Endpunkte konfiguriert, nicht über die Power BI Desktop-Benutzeroberfläche.

Im Tabelleneditor:

1. Öffnen Sie das Modell über die Multifunktionsleiste der externen Werkzeuge
2. Navigieren Sie zu der Tabelle oder Spalte, die Sie einschränken möchten
3. Suchen Sie im Bereich „Eigenschaften“ unter jeder Rolle nach „Tabellenberechtigungen“ oder „Spaltenberechtigungen“.
4. Setzen Sie die Berechtigung auf „Keine“ (Standard ist „Lesen“).

Um beispielsweise die Spalte „Gehalt“ in der Tabelle „Mitarbeiter“ für die Rolle „Vertrieb“ auszublenden:

• Rolle: Vertrieb
• Tabelle: Mitarbeiter
• Spalte: Gehalt
• Erlaubnis: Keine

Benutzern, denen die Rolle „Vertrieb“ zugewiesen ist, wird die Spalte „Gehalt“ in der Feldliste nicht angezeigt und sie können in DAX-Berechnungen nicht darauf verweisen.

OLS-Einschränkungen

– OLS erfordert Power BI Premium oder Pro mit aktivierten XMLA-Endpunkten – OLS kann nicht in der nativen Benutzeroberfläche von Power BI Desktop konfiguriert werden

• OLS ist nur auf Metadatenebene verfügbar – es filtert keine Zeilen – Wenn eine Kennzahl auf eine ausgeblendete Spalte verweist, führt die Kennzahl selbst für eingeschränkte Benutzer zu einem Fehler

---

RLS mit DirectQuery

RLS funktioniert mit DirectQuery, das Verhalten unterscheidet sich jedoch in wichtigen Punkten vom Importmodus.

Wie es funktioniert

Im DirectQuery-Modus übersetzt Power BI den RLS-DAX-Filter in eine SQL-WHERE-Klausel und sendet sie an die Datenquelle. Die Datenquelle führt die Filterung durch und es werden nur autorisierte Zeilen zurückgegeben.

Single Sign-On (SSO) Pass-Through

Wenn Sie DirectQuery mit SSO für eine Datenbank wie Azure SQL oder Azure Synapse verwenden, übergibt Power BI die Identität des Benutzers an die Datenbank. Wenn die Datenbank über eine eigene Sicherheit auf Zeilenebene verfügt (z. B. CREATE SECURITY POLICY von SQL Server), gilt diese Sicherheit zusätzlich zum RLS von Power BI.

Wichtig: Wenn Sie SSO-Passthrough aktivieren, wird das RLS von Power BI umgangen, da die Datenbank die Sicherheit übernimmt. Sie müssen sich für das eine oder andere entscheiden:

• Power BI RLS (definiert in DAX, verwaltet in Power BI)
• RLS auf Datenbankebene (in SQL definiert, in der Datenbank verwaltet)
• Beides (Power BI RLS UND Datenbank RLS gelten --- der Benutzer sieht die Schnittmenge)

Leistungsüberlegungen

RLS-Filter in DirectQuery fügen jeder Abfrage WHERE-Klauseln hinzu. Wenn die Filterspalten nicht in der Datenbank indiziert sind, kann die Leistung erheblich beeinträchtigt werden. Stellen Sie sicher, dass:

• RLS-Filterspalten verfügen über Datenbankindizes – Der DAX-Filterausdruck ist einfach genug, um in effizientes SQL übersetzt zu werden
• Sie testen die Abfrageleistung mit dem „Performance Analyzer“ in Power BI Desktop

---

RLS in Power BI Embedded

Für Power BI Embedded (Einbetten von Berichten in benutzerdefinierte Anwendungen) gelten besondere RLS-Anforderungen, da die Endbenutzer möglicherweise nicht über Power BI- oder Azure AD-Konten verfügen.

App besitzt Datenszenario

Beim Einbettungsmuster „App besitzt Daten“ authentifiziert sich ein Dienstprinzipal oder Hauptkonto bei Power BI und die Anwendung übergibt die Identität des Benutzers im Einbettungstoken.

Generieren eines Einbettungstokens mit RLS:

Wenn Sie die Power BI-REST-API aufrufen, um ein Einbettungstoken zu generieren, schließen Sie den Parameter identities ein:

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

Der Wert username ist das, was USERPRINCIPALNAME() im DAX-Ausdruck zurückgibt. Das Array roles gibt an, welche RLS-Rollen angewendet werden sollen. Sie können eine beliebige Zeichenfolge als Benutzernamen übergeben – es muss sich nicht unbedingt um ein echtes Azure AD-Konto handeln.

Häufige Einbettungsfehler

Fehler 1: Die effektive Identität wird nicht übergeben. Wenn Sie ein Einbettungstoken ohne den Parameter identities generieren, zeigt der eingebettete Bericht alle Daten an. Dies ist der häufigste RLS-Einbettungsfehler.

Fehler 2: Rollen übergeben, aber keinen Benutzernamen. Der Benutzername ist für dynamisches RLS erforderlich. Ohne diese Angabe gibt USERPRINCIPALNAME() einen leeren Wert zurück und der DAX-Filter stimmt mit keinen Zeilen überein – der Bericht erscheint leer.

Fehler 3: Verwendung der Identität des Dienstprinzipals. Der Dienstprinzipal ist ein Arbeitsbereichsadministrator und umgeht RLS. Sie müssen die Identität des Endbenutzers explizit übergeben.

Fehler 4: Rollen im Einbettungstoken für dynamisches RLS fest codieren. Wenn Sie dynamisches RLS mit einer einzelnen Rolle verwenden (z. B. „DynamicSecurity“), übergeben Sie immer diesen Rollennamen. Erstellen Sie keine separaten Rollen für jeden Benutzer – das würde den Zweck des dynamischen RLS zunichte machen.

---

Sicherheit auf Zeilenebene testen

Als Rolle anzeigen (Power BI Desktop)

Gehen Sie in Power BI Desktop zu „Modellierung“ und dann zu „Anzeigen als“:

1. Wählen Sie die Rolle(n) aus, die Sie testen möchten
2. Geben Sie optional einen Benutzernamen ein, um dynamisches RLS zu testen (dies simuliert den Wert USERPRINCIPALNAME()).
3. Klicken Sie auf OK

Der Bericht zeigt nun Daten an, als ob Sie der angegebene Benutzer mit der angegebenen Rolle wären. Überprüfen Sie:

• KPI-Karten zeigen die korrekten gefilterten Summen
• Tabellen zeigen nur Zeilen innerhalb des Benutzerbereichs an
• Diagramme spiegeln die gefilterten Daten wider
• Die Kreuzfilterung zwischen Bildern respektiert die RLS-Grenzen
• Drill-Through-Seiten behalten den RLS-Kontext bei

Anzeigen als (Power BI-Dienst)

Öffnen Sie im Power BI-Dienst die Datensatzeinstellungen und wählen Sie Sicherheit aus. Sie können Rollen direkt testen, indem Sie „Als Rolle testen“ auswählen und einen Benutzernamen eingeben.

Checkliste für automatisierte Tests

Erstellen Sie eine Testmatrix mit den folgenden Szenarien:

---

Leistungsoptimierung für RLS

Messen Sie die Wirkung

Verwenden Sie vor und nach der Implementierung von RLS den Performance Analyzer in Power BI Desktop, um die Abfragezeiten zu messen. Öffnen Sie den Bereich „Leistungsanalyse“, starten Sie die Aufzeichnung, interagieren Sie mit dem Bericht und vergleichen Sie DAX-Abfragezeiten mit und ohne RLS.

Eine gut konzipierte RLS-Implementierung verursacht weniger als 5 Prozent Mehraufwand. Wenn Sie eine Verschlechterung von mehr als 10 Prozent feststellen, untersuchen Sie die DAX-Filterausdrücke.

Optimierungstechniken

Halten Sie Filterausdrücke einfach. Der ideale RLS-Ausdruck ist ein Einzelspaltenvergleich:

[Region] = USERPRINCIPALNAME()

Vermeiden Sie komplexe Ausdrücke mit mehreren CALCULATE-, FILTER- oder LOOKUPVALUE-Aufrufen im RLS-Filter selbst.

Verwenden Sie Ganzzahlschlüssel anstelle von Textvergleichen. Die Filterung nach [CompanyId] = 1 ist schneller als nach [CompanyName] = "ECOSIRE Private Limited". Ordnen Sie Benutzer-E-Mails ganzzahligen Schlüsseln in der Sicherheitszuordnungstabelle zu.

Minimieren Sie die Anzahl der Tabellen mit RLS-Filtern. Wenden Sie RLS auf Dimensionstabellen an und lassen Sie die Beziehungsweitergabe Faktentabellen verarbeiten. Die direkte Anwendung von RLS auf große Faktentabellen zwingt Power BI dazu, den Filter für jede Zeile der Faktentabelle auszuwerten.

Wenn möglich vorab aggregieren. Wenn ein Benutzer nur Daten auf Zusammenfassungsebene benötigt, sollten Sie die Erstellung einer vorab aggregierten Tabelle mit dem während ETL angewendeten Sicherheitsfilter in Betracht ziehen. Dadurch wird das Datenvolumen reduziert, das Power BI zum Zeitpunkt der Abfrage filtern muss.

Vermeiden Sie bidirektionale Kreuzfilter. Bidirektionale Beziehungen erhöhen die Abfragekomplexität und können zu Konflikten mit RLS führen. Verwenden Sie unidirektionale Beziehungen (von der Dimension zum Fakt) und wenden Sie RLS auf der Dimensionsseite an.

---

Häufige Fallstricke und Lösungen

Falle 1: RLS wird nicht auf Workspace-Administratoren angewendet

Workspace-Administratoren und Mitglieder mit Bearbeitungsberechtigung umgehen RLS. Sie sehen immer alle Daten. Dies ist beabsichtigt – Administratoren benötigen vollen Zugriff, um den Arbeitsbereich zu verwalten.

Lösung: Verwenden Sie die Rolle „Viewer“ für Geschäftsbenutzer, die RLS unterliegen sollen. Gewähren Sie dem BI-Team nur die Rollen „Administrator/Mitglied/Mitwirkender“.

Fallstrick 2: ALL() RLS-Filter entfernen

Die DAX ALL()-Funktion entfernt alle Filter aus einer Tabelle, einschließlich RLS-Filter. Wenn eine Kennzahl ALL() für eine RLS-gefilterte Tabelle verwendet, werden möglicherweise Daten angezeigt, die der Benutzer nicht sehen sollte.

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

Lösung: Verwenden Sie ALLSELECTED() anstelle von ALL(), wenn Sie Slicer-/visuelle Filter entfernen, aber RLS-Filter beibehalten möchten:

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

Fallstrick 3: BERECHNEN Sie das Überschreiben von RLS

CALCULATE mit expliziten Filterargumenten kann RLS in bestimmten Szenarios außer Kraft setzen, insbesondere bei REMOVEFILTERS:

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

Lösung: Überprüfen Sie alle DAX-Kennzahlen auf die Verwendung von ALL, REMOVEFILTERS und ALLEXCEPT. Stellen Sie sicher, dass sie nicht auf RLS-gefilterte Spalten verweisen.

Fallstrick 4: Zusammengesetzte Modelle und RLS

In zusammengesetzten Modellen (Mischung von Import und DirectQuery) muss RLS separat für Importtabellen und DirectQuery-Tabellen definiert werden. Eine einzelne RLS-Rolle kann Filter für beide enthalten, das Verhalten unterscheidet sich jedoch:

• Tabellen importieren: RLS-Filter wird von der Power BI-Engine ausgewertet
• DirectQuery-Tabellen: RLS-Filter wird in SQL übersetzt und an die Quelle gesendet

Wenn die DirectQuery-Quelle die im RLS-Filter verwendete DAX-Funktion nicht unterstützt, schlägt die Abfrage fehl.

Falle 5: Paginierte Berichte ignorieren RLS

Paginierte Power BI-Berichte (erstellt in Report Builder) können Datensatz-RLS umgehen, wenn sie direkt mit der Datenquelle verbunden sind. Um RLS zu erzwingen, müssen paginierte Berichte über das Power BI-Dataset (nicht direkt mit der Datenbank) verbunden werden und dem Benutzer muss eine RLS-Rolle zugewiesen sein.

---

Enterprise RLS-Architekturmuster

Für große Organisationen empfiehlt ECOSIRE eine standardisierte RLS-Architektur:

Design der Sicherheitsschicht

1. Sicherheitszuordnungstabelle, gespeichert in einer zentralen Datenbank (Azure SQL oder SharePoint-Liste)
2. Einzelne RLS-Rolle mit dem Namen „DynamicSecurity“ unter Verwendung von USERPRINCIPALNAME()
3. Azure AD-Gruppensynchronisierung, die die Sicherheitszuordnungstabelle basierend auf der Gruppenmitgliedschaft automatisch füllt
4. Hierarchieunterstützung mithilfe einer vorab vereinfachten Eltern-Kind-Tabelle
5. Audit-Trail Protokollierung, welche Benutzer auf welche Daten zugegriffen haben (über Power BI-Aktivitätsprotokolle und die REST-API)

Governance-Prozess

1. Datenverwalter pflegen die Sicherheitszuordnungstabelle
2. Änderungen werden durch einen Änderungsmanagementprozess überprüft und genehmigt
3. Monatliche Audits vergleichen Power BI RLS-Zuweisungen mit dem HR-Datensatzsystem
4. Vierteljährliche Penetrationstests überprüfen die Wirksamkeit von RLS

Diese Architektur lässt sich auf Tausende von Benutzern über Hunderte von Datensätzen skalieren und behält gleichzeitig einen einzigen Punkt für die Sicherheitsverwaltung bei.

---

FAQ

Funktioniert RLS mit kostenlosen Power BI-Lizenzen?

Nein. RLS erfordert Power BI Pro- oder Premium-Pro-Benutzerlizenzen für alle Benutzer, die RLS-geschützte Berichte nutzen. Benutzer einer kostenlosen Lizenz können nur in einem Arbeitsbereich mit Premium-Kapazität auf Inhalte zugreifen und benötigen selbst dann eine Pro- oder PPU-Lizenz, um RLS-Rollen zugewiesen zu bekommen. In Power BI Embedded-Szenarien benötigen die Endbenutzer keine Power BI-Lizenzen – RLS wird durch das Einbettungstoken erzwungen.

Kann ich RLS basierend auf Azure AD-Gruppen anstelle einzelner Benutzer implementieren?

Nicht direkt. RLS von Power BI wertet DAX-Ausdrücke anhand von USERPRINCIPALNAME() aus, wodurch die E-Mail-Adresse des einzelnen Benutzers zurückgegeben wird. Sie können jedoch eine Sicherheitszuordnungstabelle erstellen, die Azure AD-Gruppen Datenbereichen zuordnet, und diese mithilfe der Microsoft Graph-API oder der Azure AD-Gruppenmitgliedschaftssynchronisierung füllen. Der DAX-Ausdruck filtert weiterhin nach der E-Mail-Adresse des Benutzers, aber die Sicherheitszuordnungstabelle stellt die Gruppen-zu-Daten-Zuordnung bereit.

Was passiert, wenn ein Benutzer keiner RLS-Rolle zugewiesen ist?

Wenn RLS für einen Datensatz definiert ist und einem Benutzer keine Rolle zugewiesen ist, werden dem Benutzer keine Daten angezeigt. Der Bericht wird geladen, aber alle visuellen Elemente zeigen leer oder null an. Dies ist die sichere Standardeinstellung – Power BI geht davon aus, dass kein Zugriff erfolgt, es sei denn, dies wird ausdrücklich gewährt. Workspace-Administratoren und Mitglieder mit Bearbeitungsberechtigung umgehen jedoch RLS und sehen unabhängig von Rollenzuweisungen immer alle Daten.

Kann RLS Daten in Echtzeit-Dashboards filtern?

Ja. RLS funktioniert sowohl im Import- als auch im DirectQuery-Modus. Im DirectQuery-Modus wird der RLS-Filter in eine SQL-WHERE-Klausel übersetzt und bei jeder Abfrage an die Datenbank gesendet, sodass die Filterung in Echtzeit erfolgt. Im Importmodus wird die Filterung im Speicher angewendet, wenn der Benutzer den Bericht öffnet. Beide Modi bieten die gleiche Sicherheitsgarantie: Der Benutzer sieht nur autorisierte Daten.

Wie überprüfe ich, wer über RLS auf welche Daten zugegriffen hat?

Power BI stellt Aktivitätsprotokolle über das Microsoft 365 Admin Center und die Power BI REST API bereit. Diese Protokolle zeichnen Berichtsansichten, Datensatzaktualisierungen und Exportvorgänge auf, einschließlich der Identität des Benutzers. Die Protokolle zeichnen jedoch nicht auf, welche spezifischen Zeilen ein Benutzer angezeigt hat. Für eine detaillierte Überwachung des Datenzugriffs aktivieren Sie die Überwachung auf Datenbankebene (z. B. PostgreSQL pgaudit oder Azure SQL-Überwachung), um die tatsächlichen Abfragen zu protokollieren, die von DirectQuery mit angewendeten RLS-Filtern generiert werden.