Row-Level Security in Power BI: Einrichten und Einsatz

Row-Level Security (RLS) legt fest, welche Zeilen eines Reports jeder Nutzer sieht, auf Basis einer Rolle, die Sie einmal im Datenmodell definieren. Nutzen Sie sie, wenn verschiedene Personen denselben Report brauchen, aber nur ihren eigenen Ausschnitt der Daten, etwa ein Regionalleiter, der nur seine Region sehen soll, neben einem Länderleiter, der alles sieht.

Statische RLS

Statische RLS wendet einen festen Filter auf eine Rolle an. Alle, die dieser Rolle zugewiesen sind, sehen dieselben Zeilen, egal wer sie sind. Sie erstellen sie in Power BI Desktop unter Modeling > Manage Roles, dann schreiben Sie einen DAX-Filter für die Tabelle, die Sie einschränken wollen:

[Region] = "West"

Manage Roles in Power BI Desktop, mit einem statischen Filter auf der Tabelle Orders.

Öffnen Sie nach dem Veröffentlichen des Reports den Workspace, wählen Sie beim Semantic Model die Option Security und fügen Sie die E-Mail-Adressen der Nutzer hinzu, die zu jeder Rolle gehören. Prüfen Sie mit Test as Role, ob der Filter wie erwartet funktioniert, bevor Sie den Report teilen.

Dynamische RLS

Dynamische RLS filtert Zeilen danach, wer angemeldet ist, statt nach einem festen Wert pro Rolle. Die einfachste Variante vergleicht eine Spalte direkt mit dem aktuellen Nutzer:

[SalesRepEmail] = USERPRINCIPALNAME()

Häufiger ist ein Muster mit separater Zuordnungstabelle, sodass sich der Zugriff ändern lässt, ohne das Modell zu bearbeiten. Wenn eine Tabelle UserRegion jede E-Mail-Adresse einer Region zuordnet:

[Region] = LOOKUPVALUE (
    'UserRegion'[Region],
    'UserRegion'[Email], USERPRINCIPALNAME()
)

So ist die Änderung, wer welche Region sehen darf, eine Datenänderung in der Zuordnungstabelle und keine Modelländerung. USERPRINCIPALNAME() liefert im Power-BI-Dienst die E-Mail-Adresse des angemeldeten Nutzers; in Power BI Desktop liefert sie den lokalen Windows-Kontonamen. Testen Sie daher mit Test as Role statt dem zu vertrauen, was Sie beim Bearbeiten sehen.

RLS im Power-BI-Dienst validieren

Prüfen Sie nach dem Einrichten der Rollen in Desktop und dem Zuweisen der Mitglieder im Dienst, ob jede Rolle tatsächlich einschränkt, was sie soll. Öffnen Sie die Sicherheitseinstellungen des Semantic Models, wählen Sie neben einer Rolle More options und dann Test as Role.

Test as Role im Power-BI-Dienst, aufgerufen über die Sicherheitseinstellungen des Semantic Models.

RLS wird nur für Nutzer mit der Rolle Viewer im Workspace durchgesetzt. Wer Admin-, Member- oder Contributor-Zugriff auf den Workspace hat, sieht ungefilterte Daten, unabhängig davon, welcher RLS-Rolle er zusätzlich zugewiesen ist, weil diese Rollen Bearbeitungszugriff auf die zugrunde liegenden Inhalte haben. Testen Sie RLS, indem Sie einen Viewer hinzufügen oder Test as Role nutzen, nicht anhand dessen, was Sie als Bearbeiter des Reports sehen.

Warum Row-Level Security nutzen

• Datenschutz. Sensible Zeilen sind nur für die Personen sichtbar, die sie sehen sollen.

• Weniger Fehler. Nutzer sehen nur die Daten, die für ihre Aufgabe relevant sind, was die Gefahr senkt, dass ein Leser eine Zahl falsch deutet, die nie für ihn gedacht war.

• Compliance. Viele Organisationen müssen den Datenzugriff aus regulatorischen Gründen rollenbasiert einschränken, und RLS ist der Weg, diese Vorgabe in einem Power-BI-Report durchzusetzen.

Best Practices

• Weisen Sie Rollen Active-Directory-Gruppen statt einzelner Nutzer zu, damit der Wechsel einer Person ins oder aus dem Team keine Modelländerung erfordert.

• Halten Sie den DAX-Filter jeder Rolle einfach. Ein komplexer Filter ist schwerer zu prüfen und kann den Report verlangsamen; wie die Modellstruktur die Filter-Performance beeinflusst, steht in unserem Leitfaden zu Best Practices der Datenmodellierung.

• Prüfen Sie Rollen und ihre Mitglieder nach Zeitplan, nicht erst, wenn jemand fragt, warum er eine Seite nicht sehen kann.

• Testen Sie immer mit Test as Role, für jede Rolle, bevor Sie einen Report teilen.

Haben Sie den zugrunde liegenden Report noch nicht gebaut, beginnen Sie mit unserem Leitfaden zum Erstellen von Power-BI-Reports, und kommen Sie zurück, um RLS zu ergänzen, sobald das Modell steht.

RLS steuert, welche Daten eine Person sieht, sobald sie im Report ist. Wer den Report überhaupt öffnen, bearbeiten oder teilen darf, steuert sie nicht; das legt die Workspace-Rolle fest. Wie beides zusammenspielt, steht in unserem Leitfaden zu Workspace-Rollen, und welche Lizenzstufe jede Workspace-Rolle verlangt, in unserem Lizenzleitfaden.

FAQs

Kann ein Nutzer mehr als einer Rolle angehören?

Ja. Power BI kombiniert Rollen mit ODER-Logik: Gehört ein Nutzer sowohl einer Rolle „Finance“ als auch einer Rolle „Management“ an, sieht er jede Zeile, die eine der beiden Rollen erlaubt, nicht nur die Zeilen, die beide gemeinsam haben. Denken Sie daran, wenn Sie jemanden einer zweiten Rolle zuweisen. Sie erweitert, was er sieht, und schränkt es nicht ein.

Was, wenn ich früher Rollen und Regeln für ein Semantic Model im Power-BI-Dienst erstellt habe? Funktionieren sie weiter, wenn ich nichts tue?

Nein. Das bezieht sich auf einen alten Weg, bei dem Rollen direkt im Dienst erstellt werden konnten. Rollen werden heute in Power BI Desktop definiert, oder in der Webmodellierung des Dienstes für unterstützte Datenquellen, und die Mitglieder werden danach im Power-BI-Dienst diesen Rollen zugewiesen. Hat ein Semantic Model nur Rollen aus dem alten dienstbasierten Weg, erstellen Sie sie in Desktop neu und veröffentlichen erneut.

Quellen

• Row-level security (RLS) with Power BI - Microsoft Learn