Berechtigungen in Power BI verstehen

Berechtigungen in Power BI wirken oft einfacher, als sie sind. Ein Nutzer bekommt Zugriff auf einen Bericht, eine Gruppe wird einem Workspace hinzugefügt, Row-Level Security wird eingerichtet – und schon scheint das Thema erledigt. In kleinen Umgebungen funktioniert das manchmal eine Weile. In gewachsenen Power-BI-Landschaften wird es schnell riskant.

Denn „Zugriff auf einen Bericht“, „Zugriff auf einen Workspace“, „Zugriff auf ein semantisches Modell“ und „Zugriff auf bestimmte Daten“ sind unterschiedliche Dinge. Wer diese Ebenen vermischt, baut kein belastbares Berechtigungskonzept, sondern eine Rechtevergabe, die irgendwann niemand mehr sauber erklären kann.

Genau deshalb lohnt sich der Blick auf die wichtigsten Bausteine: Workspace-Rollen, App- und Berichtsfreigaben, Berechtigungen auf semantische Modelle, Row-Level Security und Object-Level Security. RLS ist dabei ein wichtiger Sicherheitsmechanismus. Aber RLS allein macht eine Power-BI-Umgebung noch nicht sicher.

Berechtigungen in Power BI sind mehr als Report-Zugriff

Viele Diskussionen starten mit der Frage: „Wer darf diesen Report sehen?“ Das ist verständlich, greift aber zu kurz. In Power BI geht es nicht nur darum, ob jemand einen Bericht öffnen darf. Es geht darum, ob jemand Inhalte bearbeiten, semantische Modelle verwenden, eigene Reports auf bestehenden Modellen bauen oder bestimmte Daten überhaupt sehen darf.

Diese Unterscheidung ist wichtig, weil jede Ebene ein anderes Problem löst. Workspace-Rollen regeln Zusammenarbeit. App- und Berichtsfreigaben regeln Konsum. Semantikmodell-Berechtigungen regeln die Nutzung eines Datenmodells. RLS filtert Datenzeilen. OLS schützt Tabellen, Spalten und Metadaten.

Ein regionaler Vertriebsleiter braucht in der Regel keine Bearbeitungsrechte im Workspace. Ein BI-Entwickler braucht dagegen Zugriff auf Modelle, Datenflüsse und Reports. Ein Controller mit Self-Service-Aufgabe benötigt möglicherweise Build-Berechtigungen auf ein zentrales semantisches Modell. Und ein HR-Dashboard braucht eine deutlich feinere Sicherheitslogik als ein allgemeines Management-Reporting.

RLS, OLS und Workspace-Rollen im schnellen Vergleich

Die wichtigste Orientierung lautet: Workspace-Rollen steuern Zusammenarbeit, RLS steuert Zeilensichtbarkeit, OLS steuert Objektsichtbarkeit. Build-Berechtigungen kommen hinzu, wenn Nutzer eigene Inhalte auf Basis eines semantischen Modells erstellen sollen.

Situation	Passende Berechtigungsebene
Fachbereich soll fertige Reports ansehen	App-Freigabe oder Viewer-Rolle
BI-Team soll Reports und Modelle entwickeln	Workspace-Rolle Contributor, Member oder Admin
Nutzer sollen nur ihre eigene Region sehen	Row-Level Security
Gesellschaften sollen nur eigene Daten sehen	Row-Level Security
Marge, Gehalt oder sensible Spalten sollen nicht sichtbar sein	Object-Level Security
Fachbereiche sollen eigene Reports auf einem Modell bauen	Build-Berechtigung
Berechtigungen sollen wartbar bleiben	Gruppen, Namenskonventionen und Governance
Daten sollen bereits auf Plattformebene geschützt werden	Fabric-/OneLake-/Datenquellen-Security prüfen

In der Praxis werden diese Ebenen kombiniert. Ein Vertriebsreport kann über eine App verteilt werden, RLS für regionale Datensicht nutzen und OLS für sensible Margeninformationen einsetzen. Gleichzeitig braucht das BI-Team höhere Workspace-Rechte, um das Modell weiterzuentwickeln.

Workspace-Rollen: Nicht jeder Nutzer gehört in den Workspace

Workspace-Rollen sind wichtig, aber sie sind kein Ersatz für Datensicherheit. Sie regeln vor allem, wer in einem Arbeitsbereich mitarbeiten darf. Genau deshalb sollten produktive Workspaces nicht wie Verteilerlisten behandelt werden.

Viewer können Inhalte ansehen. Diese Rolle passt für Nutzer, die Reports konsumieren, aber nicht bearbeiten sollen. Contributors können Inhalte erstellen, bearbeiten und löschen. Diese Rolle passt eher zu Entwicklern. Members können darüber hinaus Apps veröffentlichen oder aktualisieren und sollten deshalb bewusster vergeben werden. RADACAD beschreibt die Member-Rolle deshalb sinngemäß als Deployment-Rolle, nicht als allgemeine Teamrolle.  Admins verwalten Workspace und Berechtigungen und sollten entsprechend knapp vergeben werden.

Der entscheidende Punkt: RLS greift nicht für Workspace-Admins, Members und Contributors. Microsoft weist klar darauf hin, dass diese Rollen Bearbeitungsrechte für das semantische Modell haben und RLS deshalb nicht auf sie angewendet wird. Wenn RLS für Nutzer innerhalb eines Workspaces gelten soll, müssen sie Viewer sein; alternativ werden Inhalte über Apps oder Freigaben verteilt.

Das ist einer der häufigsten Fehler in Power-BI-Umgebungen: RLS wird technisch eingerichtet, aber Fachanwender bekommen gleichzeitig zu hohe Workspace-Rechte. Dann ist die Sicherheitslogik zwar gedacht, aber praktisch ausgehebelt. Genau solche Themen gehören in eine klare Power BI Governance im Self Service, weil Berechtigungen, Verantwortlichkeiten und Veröffentlichungsprozesse zusammen betrachtet werden müssen.

Row-Level Security: Wenn Nutzer nur bestimmte Daten sehen sollen

Row-Level Security ist der richtige Mechanismus, wenn verschiedene Nutzer denselben Report verwenden, aber unterschiedliche Ausschnitte der Daten sehen sollen. Typische Beispiele sind Regionen, Niederlassungen, Gesellschaften, Kostenstellen, Kundengruppen oder Mandanten.

Ein Vertriebsreport kann für alle Regionalleiter gleich aussehen. Regionalleiter Nord sieht nur Daten aus Nord, Regionalleiter Süd nur Daten aus Süd, die Geschäftsführung alle Regionen. Der Bericht bleibt identisch, die Datensicht wird über RLS gesteuert.

Bei statischer RLS werden feste Rollen definiert, etwa „Region Nord“, „Region Süd“ oder „Controlling“. Das ist verständlich und für einfache Szenarien ausreichend. Es wird aber unübersichtlich, wenn viele Regionen, Kostenstellen oder häufig wechselnde Verantwortlichkeiten hinzukommen.

Bei dynamischer RLS wird die Sichtbarkeit über Nutzereigenschaften und Zuordnungstabellen gesteuert. Häufig wird dafür USERPRINCIPALNAME() genutzt, um den angemeldeten Nutzer mit einer Berechtigungstabelle abzugleichen. RADACAD hebt hervor, dass dynamische RLS besonders bei vielen Nutzern oder Rollen sinnvoll ist, weil statische Rollenmodelle sonst kaum wartbar bleiben.

Der kritische Punkt: Dynamische RLS steht und fällt mit dem Datenmodell. Wenn die Beziehung zwischen Nutzertabelle, Berechtigungstabelle und Faktentabellen nicht sauber modelliert ist, können Filter unvollständig wirken. Deshalb sollte RLS nicht als nachträglicher Sicherheitspatch verstanden werden, sondern als Teil einer sauberen Datenmodellierung in Power BI.

RLS hat Grenzen

RLS filtert Zeilen. RLS schützt keine Tabellen, Spalten oder Measures als Objekte. Microsoft beschreibt RLS ausdrücklich als Filterung von Tabellenzeilen und nicht als Mechanismus, um Modellobjekte wie Tabellen, Spalten oder Measures zu beschränken.

Das bedeutet: Wenn der Vertrieb dieselben Kundenzeilen sehen darf, aber keine Marge, reicht RLS nicht aus. Dann geht es nicht um andere Zeilen, sondern um sensible Spalten oder Kennzahlenlogik. Dafür ist OLS der passendere Baustein – oder eine vorgelagerte Modell- beziehungsweise Plattformentscheidung.

Auch DAX-Logik kann durch RLS anspruchsvoller werden. So kann es beispielsweise dazukommen, dass es bei RLS Einschränkungen rund um USERELATIONSHIP und inaktive Beziehungen geben kann. Das ist kein Alltagsproblem für jeden Report, aber ein guter Hinweis: Sicherheitslogik ist Modellierungslogik. Wer komplexe Modelle baut, sollte RLS nicht erst am Ende draufsetzen.

Das ist auch ein Performance-Thema. Sicherheitsfilter können Auswirkungen auf Abfragen, Modellstruktur und Nutzererlebnis haben. Wenn Power-BI-Berichte ohnehin langsam reagieren, sollte RLS nicht isoliert betrachtet werden, sondern gemeinsam mit Modellstruktur, DAX und Ladeverhalten. Eine strukturierte Analyse zur Power BI Performance hilft, solche Zusammenhänge nicht zu übersehen.

Object-Level Security: Spalten/Tabellen schützen

Object-Level Security schützt Objekte im semantischen Modell. Während RLS Zeilen filtert, kann OLS Tabellen oder Spalten für bestimmte Rollen vollständig ausblenden. Tabular Editor beschreibt OLS als Mechanismus, mit dem Spalten und ganze Tabellen je nach Sicherheitsrolle vollständig verschwinden können.

Ein typischer Fall ist ein Controlling-Modell mit Umsatz, Kosten, Deckungsbeitrag und Marge. Der Vertrieb soll Umsatz und Kundenentwicklung sehen, aber keine detaillierten Margeninformationen. RLS wäre hier nur dann passend, wenn der Vertrieb andere Zeilen sehen soll. Wenn es um sensible Spalten geht, ist OLS fachlich näher am Problem.

Ein weiteres Beispiel ist HR-Reporting. Allgemeine Kennzahlen wie Headcount, Fluktuation oder Organisationsstruktur können für Führungskräfte relevant sein. Gehaltsdaten oder personenbezogene Details dürfen dagegen nur einem kleinen Kreis zugänglich sein. Hier kann OLS sinnvoll sein – allerdings nur mit sauberer Modellierung und gründlichem Testing.

Wichtig: OLS ist kein „Spalte im Bericht nicht anzeigen“. Eine im Visual nicht verwendete Spalte ist weiterhin Teil des Modells. OLS setzt auf Modellebene an. Dadurch können Nutzer ohne Berechtigung das Objekt nicht einfach über ein anderes Visual, Excel oder eigene Auswertungen verwenden.

OLS ist stark, aber nicht bequem

OLS ist fachlich wertvoll, bringt aber Nebenwirkungen mit. Wenn ein Report auf eine Spalte zugreift, die für eine Rolle per OLS nicht sichtbar ist, kann das Visual brechen. Tabular Editor beschreibt genau diesen Effekt: Für den betroffenen Nutzer ist das Objekt so, als würde es im Modell nicht existieren.

Auch die Pflege ist anspruchsvoller als bei einfachen RLS-Szenarien. Seit der Einführung der TMDL-Ansicht ist OLS in Power BI Desktop grundsätzlich möglich, aber nicht besonders komfortabel. Tabular Editor bleibt deshalb in vielen professionellen Szenarien weiterhin das praktischere Werkzeug für Pflege, Kontrolle und Testing von OLS-Konfigurationen.

Zusätzlich müssen Mehrfachrollen sauber geplant werden. Bei OLS kann die Kombination mehrerer Rollen dazu führen, dass Nutzer Zugriff auf Objekte erhalten, die in mindestens einer Rolle erlaubt sind. Kombinationen aus OLS und RLS über mehrere Rollen sind nicht beliebig möglich. Für produktive Umgebungen ist deshalb eine einfache Rollenlogik oft besser als ein kunstvoll verschachteltes Berechtigungsmodell.

Semantikmodell-Rechte: Build ist kein simples Zusatzrecht

Neben Workspace-Rollen, RLS und OLS werden Berechtigungen auf semantische Modelle häufig unterschätzt. Besonders wichtig ist die Build-Berechtigung.

Build bedeutet: Nutzer dürfen auf einem vorhandenen semantischen Modell eigene Inhalte erstellen. Das ist für Self-Service BI wertvoll. Fachbereiche können eigene Reports bauen, ohne Kopien des Datenmodells anzulegen oder eigene Excel-Schattenlogiken zu pflegen.

Genau deshalb ist Build aber kein harmloses Komfortrecht. Microsoft beschreibt Build als Voraussetzung, um neue Inhalte wie Reports, Dashboards, Q&A-Inhalte oder paginierte Reports auf Basis eines semantischen Modells zu erstellen; außerdem wird Build für Szenarien wie Analyze in Excel, Export zugrunde liegender Daten oder XMLA-Zugriff relevant.

Die Governance-Frage lautet also nicht: „Wer möchte Build?“ Sondern: Welche semantischen Modelle sind offiziell für Self-Service freigegeben? Welche Kennzahlen sind belastbar? Welche Sicherheitslogik gilt? Wer dokumentiert Änderungen? Und wer überprüft, ob Fachbereiche auf denselben Definitionen arbeiten?

Gerade zentrale semantische Modelle in Power BI brauchen deshalb klare Spielregeln. Sonst wird Wiederverwendung zwar technisch möglich, aber fachlich unscharf.

Fabric & OneLake: Power BI Security ist nicht alles

Mit Microsoft Fabric wird die Sicherheitsfrage breiter. RLS und OLS im Power-BI-Semantikmodell bleiben wichtig, aber sie sind nicht automatisch die einzige Stelle, an der Sicherheit geregelt werden sollte.

Tabular Editor ordnet sauber ein, dass Datensicherheit sowohl im Power-BI-Semantikmodell als auch auf Fabric-/OneLake-Ebene umgesetzt werden kann. Für Direct-Lake-Szenarien und Delta-Parquet-Tabellen werden Security-Konzepte in OneLake relevant, die alle Abfragen gegen diese Daten betreffen können.

Für die Praxis heißt das: In klassischen Power-BI-Szenarien ist das semantische Modell oft die zentrale Sicherheitsebene. In Fabric-Architekturen muss zusätzlich geprüft werden, welche Regeln bereits auf Plattform-, Lakehouse-, Warehouse- oder OneLake-Ebene gelten sollen. Sonst entsteht dieselbe Berechtigungslogik mehrfach – im schlechtesten Fall widersprüchlich.

Typische Fehler bei Berechtigungen in Power BI

Der erste Fehler ist zu viel Workspace-Zugriff. Workspaces sind Arbeitsbereiche für Entwicklung und Betrieb, keine normalen Verteilerlisten für Fachbereiche. Konsumenten sollten fertige Inhalte meist über Apps oder Freigaben erhalten.

Der zweite Fehler ist die Annahme, RLS löse alle Sicherheitsfragen. RLS ist stark für zeilenbasierte Filterung. Für sensible Tabellen oder Spalten braucht es OLS, ein anderes Modell-Design oder Sicherheit auf einer vorgelagerten Plattformebene.

Der dritte Fehler ist eine schlechte Gruppenstrategie. Einzelpersonen direkt zu Rollen hinzuzufügen, funktioniert im Kleinen. In größeren Umgebungen braucht es Microsoft-Entra-Gruppen, Namenskonventionen und regelmäßige Reviews. Gleichzeitig muss berücksichtigt werden, welche Gruppentypen für RLS unterstützt werden. Microsoft nennt Distribution Groups, mail-enabled Groups und Microsoft Entra Security Groups; Microsoft 365 Groups werden für RLS-Rollen nicht unterstützt.

Der vierte Fehler ist fehlendes Testing. Viele Teams testen, ob ein Report fachlich funktioniert. Weniger Teams testen konsequent, was unterschiedliche Rollen tatsächlich sehen. Microsoft weist beim Testen von Rollen außerdem auf Einschränkungen hin, etwa bei Dashboards, bestimmten Reportfunktionen und DirectQuery-Modellen mit SSO.

Der fünfte Fehler ist fehlende Verantwortung. Wenn niemand fachlich für Datenzugriff zuständig ist, entscheidet am Ende die Person, die den Report veröffentlicht. Das ist keine Governance, sondern Zufall mit hübscher Oberfläche.

Ein sauberes Berechtigungskonzept beginnt vor der Technik

Gute Berechtigungen entstehen nicht erst in Power BI Desktop. Sie beginnen mit fachlichen Entscheidungen. Welche Daten sind sensibel? Welche Nutzergruppen gibt es wirklich? Wer konsumiert nur? Wer entwickelt? Wer darf veröffentlichen? Wer darf auf zentrale Modelle aufbauen? Welche Daten müssen zeilenweise gefiltert werden? Welche Spalten oder Tabellen dürfen bestimmte Rollen gar nicht sehen? Wer pflegt Gruppen? Wer prüft Änderungen? Wie werden neue Organisationseinheiten abgebildet?

Diese Fragen betreffen nicht nur IT oder BI. Sie betreffen Controlling, Vertrieb, HR, Geschäftsführung und Fachbereiche. Denn Berechtigungen entscheiden darüber, ob Power BI skaliert oder irgendwann aus Misstrauen ausgebremst wird.

Für reifere Power-BI-Umgebungen gehört das Thema deshalb in eine breitere Governance- und Datenstrategie. Wer Rollen, Verantwortlichkeiten und Plattformlogik nicht sauber trennt, wird mit jedem neuen Report mehr Aufwand erzeugen. In solchen Situationen hilft es, Power BI nicht nur technisch zu prüfen, sondern die Reporting-Landschaft und Rollenlogik im Rahmen einer Power BI Beratung sauber einzuordnen.

Praxisbeispiele: Welche Berechtigungslogik passt?

Vertriebsreport nach Region:Ein zentraler Report wird über eine App verteilt. Regionalleiter sehen per RLS nur ihre Region. Die Geschäftsführung erhält Gesamtsicht. Fachanwender bekommen keine Member- oder Contributor-Rechte im Workspace.

Controlling-Report mit sensibler Marge: Der Vertrieb darf Umsatz und Kundenentwicklung sehen, aber keine detaillierten Margen. RLS reicht hier nicht aus, weil es nicht um andere Zeilen, sondern um sensible Spalten geht. OLS ist der passendere Baustein.

HR-Dashboard: Allgemeine HR-Kennzahlen können für Führungskräfte relevant sein. Personenbezogene Details oder Gehaltsdaten brauchen strengere Regeln. Je nach Szenario gehören bestimmte Daten gar nicht erst in ein breit genutztes Power-BI-Modell.

Zentrales semantisches Modell für Self-Service: Ein BI-Team stellt ein qualitätsgesichertes Modell bereit. Fachbereiche dürfen eigene Reports darauf bauen und erhalten Build-Berechtigungen. Gleichzeitig müssen RLS, OLS, Kennzahlenlogik und Dokumentation sauber geregelt sein.

Fabric-Architektur mit Direct Lake: Wenn Power BI auf Daten aus Fabric zugreift, muss entschieden werden, welche Sicherheit im semantischen Modell und welche bereits auf Plattformebene umgesetzt wird. Das ist keine reine Power-BI-Frage mehr, sondern eine Architekturentscheidung.

Checkliste für bessere Berechtigungen in Power BI

Ein gutes Berechtigungskonzept beantwortet mindestens diese Fragen:

Wer soll Inhalte nur konsumieren? Wer soll entwickeln? Wer darf veröffentlichen? Wer darf Berechtigungen verwalten? Welche semantischen Modelle sind für Self-Service freigegeben? Wer erhält Build? Welche Daten müssen per RLS gefiltert werden? Welche Tabellen oder Spalten brauchen OLS? Werden Gruppen statt Einzelpersonen genutzt? Sind die Gruppentypen geeignet? Gibt es getrennte Entwicklungs-, Test- und Produktivbereiche? Werden RLS und OLS mit echten Rollen getestet? Gibt es regelmäßige Reviews?

Wenn diese Fragen heute nicht sauber beantwortet sind, ist das kein ungewöhnlicher Zustand. Es ist ein Zeichen dafür, dass Power BI gewachsen ist und mehr Struktur braucht.

---

Fazit: Berechtigungen in Power BI brauchen Architektur

Berechtigungen in Power BI sind kein einzelner Schalter. Sie sind ein Zusammenspiel aus Workspace-Rollen, App-Verteilung, Semantikmodell-Berechtigungen, RLS, OLS und Governance.

RLS ist stark, wenn Nutzer nur bestimmte Datenzeilen sehen sollen. OLS ist wichtig, wenn Tabellen oder Spalten geschützt werden müssen. Workspace-Rollen regeln Zusammenarbeit, ersetzen aber keine Datensicherheit. Build-Berechtigungen ermöglichen Self-Service, müssen aber bewusst vergeben werden. Und mit Fabric kommt eine zusätzliche Plattformebene hinzu, die sauber von Power-BI-Modelllogik getrennt werden sollte.

Die beste Lösung ist selten die komplizierteste. Sie ist die, die fachlich sauber unterscheidet: Wer arbeitet an Inhalten? Wer konsumiert Inhalte? Wer baut auf zentralen Modellen weiter? Wer darf welche Daten sehen? Und wer trägt Verantwortung dafür, dass diese Regeln dauerhaft stimmen?

---

Der nächste sinnvolle Schritt

Wenn eure Power-BI-Landschaft wächst, lohnt sich eine strukturierte Prüfung. Die Daten-WG kann euch dabei unterstützen, Power-BI-Berechtigungen gemeinsam einzuordnen, Risiken sichtbar zu machen und ein tragfähiges Rollenmodell für Reporting, Self-Service und Governance aufzubauen.

Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich u.a. mit:

• Power BI Training – für einen sauberen, praxisnahen Einstieg

• Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX oder Performance

• Power BI Visual Standards – für konsistentes Finance-Reporting mit klaren Standards

• Data Strategy Check – um eure Analytics-Organisation ganzheitlich einzuordnen

So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.