Kurz gesagt: Power BI Sicherheit auf Zeilenebene (RLS) ist eine modellbasierte Zugriffskontrolle: Sie teilen einen Bericht, und jeder Nutzer sieht nur die Zeilen seiner Rolle. KMU verhindern mit Rollen, DAX-Filtern und einer Workspace-Publish-Checkliste Datenlecks nach Region, Filiale oder Kunde — ohne Dashboards zu klonen.
Vertrieb soll nur die eigene Region sehen; Finanzen oft alle Filialen; Außendienst nur zugewiesene Händler. Ein Dashboard-Klon pro Zielgruppe erhöht den Wartungsaufwand und lässt Kennzahlen auseinanderlaufen. Power BI Sicherheit auf Zeilenebene hält einen Datensatz und einen Bericht und schneidet Zeilen per Rolle.
Dieser Leitfaden erklärt, was RLS ist, wie sich Rollen und DAX-Filter unterscheiden und welche Publish-Checkliste KMU vor dem Go-live brauchen.
Warum ist Power BI Sicherheit auf Zeilenebene wichtig?
Je mehr Self-Service-BI, desto mehr Personen öffnen dieselben Workspace-Berichte. Ohne Filter sieht ein Verkäufer Preise oder Bestände einer anderen Region, ein Filialleiter Kosten einer anderen Filiale. Das ist ein Datenschutz- und Entscheidungsrisiko. Self-Service BI braucht zertifizierte Datensätze und Workspace-Disziplin; Power BI Sicherheit auf Zeilenebene ist die Zeilenschicht dieser Disziplin.
Microsofts Leitfaden zu Row-Level Security in Power BI beschreibt Rollen im Modell, Filter in DAX und die Zuweisung von Nutzern zu Rollen im Power-BI-Dienst nach dem Veröffentlichen. Nach dem KPI-Aufbau (Power BI Dashboard für KMU-KPIs) macht RLS die Freigabe sicher.
Was ist RLS? Rollen, Filter und Workspace
Sicherheit auf Zeilenebene (RLS) wendet rollenbasierte Filter auf Modelltabelle an, sodass Abfragen nur erlaubte Zeilen zurückgeben. Es ist kein Ausblenden von Visuals, sondern ein Schnitt im Modell.
Eine Rolle bündelt Filterregeln unter einem Namen wie „Verkauf_Marmara“ oder „Finanzen_Alle“. Ein Nutzer kann einer oder mehreren Rollen angehören.
Ein DAX-Filter legt fest, welche Zeilen die Rolle sieht. Statische Filter nutzen einen festen Regionscode; dynamische Filter mappen den angemeldeten Nutzer (UPN) über eine Sicherheits-Brückentabelle.
| Konzept | Aufgabe | Wo definiert? | Praxis-Tipp für KMU |
|---|---|---|---|
| Rolle | Gruppiert denselben Filtersatz | Power BI Desktop Modellansicht | Namen in Fachsprache (Region / Filiale) |
| DAX-Filter | Schneidet sichtbare Zeilen | Tabellenfilter unter der Rolle | Zuerst statisch, dann dynamisches User-Mapping |
| Benutzerzuweisung | Wer welche Rolle erhält | Power BI-Dienst (Workspace) | Nach Publish; nicht nur in Desktop speichern |
| Workspace-Rolle | Bearbeiten / Veröffentlichen | Workspace-Mitgliedschaft | RLS gilt für Viewer; Admins können das Modell umgehen |
Schritt für Schritt: Power BI RLS einführen
1. Klären, welche Zeilen bei wem bleiben
Dimensionen wie Region, Filiale, Kundengruppe oder Produktfamilie aufschreiben. Beispielzeilen pro Rolle fixieren. Ohne Inventar wächst DAX beliebig. Ist das Modell unübersichtlich, Dimensionen zuerst im Rahmen einer Business-Intelligence-Beratung vereinfachen.
2. Rollen in Power BI Desktop anlegen
In der Modellansicht unter Rollen verwalten je Zielgruppe eine Rolle anlegen. Klare Fachnamen verwenden. Wer denselben Bericht öffnet, aber andere Zeilen sehen darf, braucht eine eigene Rolle.
3. DAX-Filter auf die richtige Tabelle setzen
Filter an die Tabelle mit der Körnung hängen (z. B. Verkauf oder Kunde). Statisch: Region gleich fester Wert. Dynamisch: Benutzer-E-Mail über eine Brückentabelle zuordnen. Microsoft Learn dokumentiert USERNAME-/USERPRINCIPALNAME-Muster; Spaltennamen vor dem Übernehmen anpassen.
4. Mit „Als Rolle anzeigen“ testen
Im Desktop jede Rolle prüfen. Sind noch alle Zeilen sichtbar, sitzt der Filter an der falschen Tabelle oder Beziehung. Diesen Schritt zu überspringen ist die häufigste Ursache für Lecks in Produktion.
5. Datensatz veröffentlichen und Benutzer zuweisen
Nach dem Publish im Power-BI-Dienst unter Datensatzsicherheit Mitglieder zu Rollen hinzufügen. Workspace-Admins, Mitglieder und Mitwirkende umgehen RLS; nur Viewer unterliegen den Zeilenfiltern. Freigaben entsprechend planen.
6. Publish-Checkliste betrieblich machen
Bei neuen Spalten oder Beziehungen RLS erneut testen. Bei Personalwechseln Zuweisungen aktualisieren. Als monatliche Routine im Rahmen der Reporting-Beratung bleibt die einmalige Einrichtung lebendig.
Häufige Fehler
- Nur Seitenfilter: Ein Visual-Filter ist kein RLS; freigegebene Viewer erreichen weiter andere Zeilen.
- Falsche Tabelle: Falsche Beziehungsrichtung → Filter wirkt nicht oder entfernt alles.
- Als Admin testen: Workspace-Admins umgehen RLS; immer als Viewer prüfen.
- Zuweisung vergessen: Desktop-Rollen kommen im Dienst leer an, bis Nutzer ergänzt sind.
- Berichte klonen: Ein pbix pro Region multipliziert Updates; RLS hält ein Modell.
Checkliste Power BI Sicherheit auf Zeilenebene
- Ist das Rolleninventar (Region/Filiale/Kanal) dokumentiert?
- Hat jede Rolle einen Desktop-DAX-Filter und „Als Rolle anzeigen“-Test?
- Ist der Datensatz im richtigen Workspace veröffentlicht?
- Sind Viewer im Dienst Rollen zugewiesen?
- Ist klar, dass Admin/Mitglied-Konten RLS umgehen?
- Gibt es einen Regressionstest bei Modelländerungen?
Mit korrekt eingerichteter Power BI Sicherheit auf Zeilenebene teilen Sie ein Dashboard sicher, senken Wartung und stoppen Zeilenlecks im Modell. ÇAP Teknoloji plant RLS mit Ihnen von Rollendesign und DAX-Filtern bis zur Publish-Checkliste im Rahmen Ihrer BI-Arbeit. Sehen Sie unsere Business-Intelligence-(BI-)Beratung oder kontaktieren Sie uns, um Ihr Power-BI-Modell zu prüfen.
Häufig gestellte Fragen
Worin unterscheidet sich Power BI Sicherheit auf Zeilenebene von einem Visual-Filter?
Seiten- oder Visual-Filter blenden nur auf dem Bildschirm aus; ohne Modellrolle können freigegebene Nutzer andere Zeilen erreichen. RLS schneidet Zeilen im Modell per DAX, sodass Abfragen nur erlaubte Zeilen liefern.
Sehen Workspace-Admins die RLS-Filter?
Nein. Workspace-Admins, Mitglieder und Mitwirkende können Dataset-RLS umgehen. Prüfen Sie immer mit einem Viewer-Konto, ob der Zeilenfilter greift.
Was ist der Unterschied zwischen statischem und dynamischem RLS?
Statisches RLS schneidet mit einem festen Wert (z. B. ein Regionscode). Dynamisches RLS mappt UPN oder E-Mail des angemeldeten Nutzers über eine Sicherheitstabelle, sodass jeder andere Zeilen sieht. Microsoft Learn dokumentiert beide Muster.
Reicht es, Rollen nur in Desktop zu definieren?
Nein. Rollen und DAX entstehen in Desktop, die Zuweisung Nutzer zu Rolle erfolgt nach dem Publish im Power-BI-Dienst. Ohne Zuweisung bleiben Rollen leer und der Filter greift nicht.
