Row Level Security Power BI (RLS): So steuerst du Datenzugriff sauber

Definition

Row-Level Security (RLS) in Power BI beschränkt den Datenzugriff, indem Datenzeilen anhand von Rollen und DAX-Filtern gefiltert werden. RLS ist keine Verschlüsselung und keine eigene Benutzerverwaltung, sondern eine Filterlogik auf dem semantischen Modell.

Einleitung

Wenn du einen zentralen Power-BI-Report bauen willst, aber nicht jeder alle Zahlen sehen darf, wird Row Level Security Power BI zum Pflichtprogramm. RLS verhindert, dass Mitarbeitende „aus Versehen“ in andere Regionen, Teams oder Mandanten schauen – ohne dass du zig Reports duplizierst. Ergebnis: weniger Wildwuchs, weniger manuelles Filtern und mehr Vertrauen in den zentralen Report.

Warum RLS in Power BI sich fast immer lohnt

RLS ist dann sinnvoll, wenn viele Benutzer auf denselben Report zugreifen, aber unterschiedliche Datensätze sehen sollen. Typische Situationen sind Vertrieb nach Region, mehrere Tochtergesellschaften, Kostenstellen-Reporting oder Partner-/Kundenportale. Der ROI entsteht vor allem durch weniger Pflegeaufwand: ein Datenmodell, ein Bericht, klare Rollen statt separater Dateien und Excel-Schattenwelten.

• Weniger Betriebsaufwand: keine Report-Kopien pro Zielgruppe.
• Weniger Risiko: geringere Chance auf falsche Freigaben.
• Mehr Self-Service: Nutzer können im gleichen Report analysieren, ohne Datenschutz-Bauchschmerzen.

Statische vs. dynamische RLS: der entscheidende Unterschied

Statische RLS bedeutet: Benutzer werden festen Rollen zugeordnet, und die Rolle filtert immer gleich (z. B. „Region Nord“). Das ist schnell für kleine Teams, wird aber unhandlich, sobald häufig Personen wechseln oder viele Regionen entstehen.

Dynamische RLS bedeutet: Die Rolle nutzt die Identität des Benutzers (User Principal Name, UPN) und leitet daraus automatisch die passende Filterung ab. Kern ist eine Users-/UserGroup-Tabelle, in der steht, welcher Benutzer auf welche Region, Kostenstelle oder Organisation zugreifen darf. Dynamische RLS skaliert deutlich besser, weil du eher Stammdaten pflegst als Rollenlisten.

Voraussetzungen und Datenmodell-Setup für RLS

RLS steht und fällt mit dem Datenmodell. Du brauchst eine saubere Beziehungskette von der „Security-Tabelle“ bis zu den Fakten (z. B. Umsatz, Buchungen, Tickets). Häufiges Muster: eine Users- oder UserGroup-Tabelle mit UPN (Mail-Adresse) und einem Schlüssel wie RegionID, Kostenstelle oder Mandant.

• Eine eindeutige Spalte für Benutzer, typischerweise UPN.
• Eine Zuordnungstabelle (Users, UserGroup, Roles), die den Zugriff definiert.
• Beziehungen, damit der Security-Filter bis zu den relevanten Tabellen wirkt.

Wichtig: Bidirektionale Kreuzfilterrichtung ist verführerisch, aber riskant. Wenn sie nötig ist, dann gezielt und mit Verständnis, wie sich der Security filter im Modell ausbreitet.

DAX-Filterlogik: das Herzstück von RLS

Rollen in Power BI sind am Ende DAX-Filter pro Tabelle. Für dynamische RLS ist USERPRINCIPALNAME() der Standard, weil er den UPN des angemeldeten Benutzers liefert. Eine klassische Logik ist: „Zeige nur Datensätze, deren Region in der User-Zuordnung für meinen UPN steht.“

Beispielhafte Denkweise (kein Feature-Feuerwerk): RLS funktioniert, indem DAX in einer Rolle definiert, welche Zeilen einer Tabelle sichtbar sind. Diese Filterung propagiert über Beziehungen ins Datenmodell und wirkt damit auf alle Visuals im Report.

Rollen in Power BI Desktop definieren und testen

In Power BI Desktop erstellst du Rollen unter „Modellierung“ und „Rollen verwalten“ (Rollen / Role Management). Dort definierst du pro Rolle, auf welchen Tabellen welche Filter gelten. Danach testest du direkt mit „Als Rollen anzeigen (View as role)“: du siehst den Report so, wie ihn ein Benutzer dieser Rolle sehen würde.

Das spart Zeit, weil du Logikfehler früh findest: falsche Beziehung, falsche Spalte, oder eine Zuordnung, die zu viele Datensätze freigibt. Gerade bei komplexen Datenmodellen ist dieser Schritt der schnellste „Kostenhebel“ gegen spätere Debugging-Stunden.

Implementierung im Power BI Service: Benutzer und Gruppen zuordnen

Nach dem Veröffentlichen richtest du RLS im Power BI Service (powerbi.com) am semantischen Modell/Dataset ein: Sicherheitsbereich öffnen, Rolle auswählen, Benutzer oder Azure-AD-Gruppen hinzufügen. Gruppen sind oft besser als Einzelzuordnungen, weil die IT dann nur Gruppenmitgliedschaften pflegt.

Praxis-Detail, das gerne übersehen wird: RLS gilt nicht für Admins/Owner mit umfassenden Rechten im Workspace. Für echte Validierung solltest du mit einem Testbenutzer arbeiten, der nur Konsumentenrechte hat.

RLS validieren: Desktop vs. Service

Tests gehören doppelt gemacht: einmal in Power BI Desktop (View as role) und einmal im Service („Test as role“). So stellst du sicher, dass UPN, Zuordnung und Veröffentlichungszustand zusammenpassen. Prüfe dabei auch Drilldown, Export und Detailseiten, denn Nutzer „sehen“ Daten oft erst dort.

• Stimmt der UPN exakt (Mail-Adresse) und ist er in der Users-Tabelle vorhanden?
• Wirkt der Filter wirklich bis in alle relevanten Tabellen?
• Gibt es Ausnahmen durch falsche Modellbeziehungen?

Use Cases und Best Practices

Mini-Story: Ein Unternehmen will einen zentralen Sales-Report für alle Regionen. Ohne RLS entstehen pro Region eigene Reports, die unterschiedlich aktualisiert werden. Mit dynamischer RLS nutzt jeder denselben Report, und die Users-Tabelle steuert den Zugriff je Region. Ergebnis: weniger Pflege, weniger Rückfragen, schnellerer Rollout neuer Kennzahlen.

Best Practices für RLS in Power BI:

• Dynamische RLS bevorzugen, wenn viele Benutzer oder häufige Änderungen erwartet werden.
• Security-Logik dokumentieren (Rollen, DAX, Zuordnungstabellen) und versionieren.
• RLS früh einplanen: nachträglich „dranflanschen“ führt oft zu Modellumbau.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn RLS mit mehreren Dimensionen kombiniert wird (z. B. Mandant + Region + Produktlinie), wenn das Datenmodell unklar ist oder wenn Performance leidet. Auch wenn Governance und Rollout (Workspaces & Apps) sauber sitzen müssen, spart ein strukturierter Aufbau Zeit und reduziert Risiko. Gute Unterstützung liefert nicht nur DAX, sondern ein Rollen- und Berechtigungskonzept, das im Betrieb wartbar bleibt.

Fazit

Row Level Security Power BI ist der pragmatische Weg, zentrale Reports sicher zu teilen: ein Report, viele Rollen, klare Zugriffe. Statische RLS ist schnell, dynamische RLS ist skalierbar. Entscheidend sind ein sauberes Datenmodell, eine nachvollziehbare DAX-Filterlogik und konsequentes Testen in Desktop und Service.