.png){kind=small}
Berechtigungen in Power BI verstehen
Aktualisiert: 27. Aug.
Berechtigungen in Power BI wirken oft einfacher, als sie sind. Ein Nutzer bekommt Zugriff auf einen Bericht, eine Gruppe wird einem Workspace hinzugefügt oder Row-Level Security eingerichtet – und damit scheint das Thema erledigt. Das Problem: Reportzugriff, Workspace-Rolle, Rechte auf einem semantischen Modell und Zugriff auf einzelne Daten sind völlig unterschiedliche Dinge. Wer diese Ebenen vermischt, erzeugt schnell eine Sicherheitsarchitektur, die sicher aussieht, aber nicht sicher ist.
Die wichtigste Regel lautet deshalb: Power-BI-Berechtigungen funktionieren als Zugriffskette. Entscheidend ist nicht nur eine einzelne Rolle, sondern welche Rechte ein Nutzer über Workspace, Freigaben, Apps, semantische Modelle und die darunterliegende Datenplattform insgesamt besitzt.
Fünf Berechtigungsebenen – fünf unterschiedliche Fragen
Ein belastbares Berechtigungskonzept sollte fünf Ebenen unterscheiden. Jede Ebene beantwortet eine andere Sicherheitsfrage – und keine davon ersetzt die anderen.
Diese Ebenen ergänzen sich. Eine Power BI App kann beispielsweise sehr gut steuern, welcher Fachbereich welchen Bericht angeboten bekommt. Sie ist deshalb aber noch keine Datensicherheitsregel. Dafür sind unter anderem RLS, OLS oder Berechtigungen auf der Datenplattform zuständig.
Workspace-Rollen: Wer darf im Arbeitsbereich arbeiten?
Power BI kennt vier Workspace-Rollen: Admin, Member, Contributor und Viewer. Workspaces sind Orte der Zusammenarbeit und Inhaltserstellung – und sollten deshalb nicht wie allgemeine Verteilerlisten für Reportkonsumenten behandelt werden.
Admins verwalten Workspace und Zugriffe. Members dürfen Inhalte und Apps umfangreich verwalten. Contributors können Inhalte erstellen und bearbeiten. Viewer konsumieren Inhalte, ohne sie zu bearbeiten.
Der sicherheitsrelevante Unterschied: RLS wird bei Workspace Viewern angewendet, nicht bei Admins, Members oder Contributors. Wer einen regionalen Vertriebsleiter sauber per RLS einschränkt und ihn anschließend zum Contributor macht, hat den eigentlichen Sicherheitsmechanismus praktisch ausgehebelt.
Genau solche Fragen gehören in eine klare Power BI Governance im Self Service, weil Rollen, Verantwortlichkeiten und Veröffentlichungsprozesse zusammen betrachtet werden müssen.
Semantikmodell-Rechte: Read, Build, Reshare und Write
Neben Workspace-Rollen besitzt Power BI eine zweite, oft unterschätzte Berechtigungsebene: Rechte auf dem semantischen Modell. Microsoft unterscheidet Read, Build, Reshare und Write.
Recht | Was es im Kern erlaubt |
Read | Daten des Modells über freigegebene Inhalte konsumieren und mit ihnen interagieren |
Build | Neue Inhalte auf Basis des Modells erstellen und das Modell über weitere Werkzeuge nutzen |
Reshare | Anderen Zugriff auf das Modell gewähren |
Write | Modell verändern, aktualisieren und administrativ bearbeiten |
Der Owner ist keine fünfte Berechtigung, sondern eine besondere Rolle mit allen Rechten und zusätzlichen Eigentümerfunktionen. Diese Unterscheidung ist wesentlich genauer als die häufige Frage: „Hat der Nutzer Build oder nicht?“
Build ist ein Self-Service-Recht – keine Sicherheitsgrenze
Build ist besonders relevant für Self-Service BI. Es ermöglicht unter anderem das Erstellen neuer Berichte auf einem bestehenden semantischen Modell, Analyze in Excel, Composite Models und Zugriff über den XMLA Endpoint.
Trotzdem wäre eine zweite Schlussfolgerung falsch: Kein Build bedeutet nicht automatisch, dass sensible Daten geschützt sind.
Microsoft weist ausdrücklich darauf hin, dass Read ohne Build nicht als Schutzmechanismus für vertrauliche Daten verwendet werden sollte. Build ist primär ein Recht für Auffindbarkeit, Wiederverwendung und Authoring. Echte Datensicherheit braucht RLS, OLS oder eine vorgelagerte Plattformregel.
Viewer + Build + RLS: sinnvoller Self-Service-Fall
Ein häufig sinnvolles Muster lautet: Viewer im Workspace + Build auf ausgewählten semantischen Modellen + RLS. Ein solcher Nutzer kann auf einem zentral freigegebenen Sales-Modell eigene Berichte erstellen oder Analyze in Excel verwenden; seine Datensicht bleibt trotzdem durch RLS eingeschränkt.
Die entscheidende Betriebsregel lautet: Beurteilt nie nur die gewünschte Berechtigung. Prüft immer die höchste wirksame Berechtigung eines Nutzers über alle Zugriffspfade.
Row-Level Security: Welche Zeilen darf ein Nutzer sehen?
Row-Level Security begrenzt, welche Datensätze ein Nutzer innerhalb eines semantischen Modells sehen darf. Ein Vertriebsreport kann deshalb für alle Regionen technisch identisch sein, während Regionalleiter Nord nur Nord, Regionalleiter Süd nur Süd und das zentrale Management alle Regionen sieht.
Statische RLS arbeitet mit festen Rollen und ist für wenige klar getrennte Nutzergruppen gut verständlich. Dynamische RLS gleicht die Identität des angemeldeten Nutzers typischerweise über USERPRINCIPALNAME() mit einer Berechtigungstabelle ab und skaliert besser bei vielen Nutzern, Gesellschaften oder Kostenstellen.
Der kritische Punkt: Dynamische RLS steht und fällt mit dem Datenmodell. Sicherheitslogik sollte deshalb nicht als nachträglicher Patch verstanden werden, sondern als Teil einer sauberen Datenmodellierung in Power BI.
Externe Nutzer machen dynamische RLS anspruchsvoller
Bei externen Microsoft-Entra-B2B-Gastnutzern kann USERPRINCIPALNAME() je nach Tenant-Konfiguration unterschiedliche Identitätsformate zurückgeben. Eine Mapping-Tabelle, die ein anderes Format erwartet, kann deshalb zu falscher oder leerer Datensicht führen.
Für externe Freigaben gilt deshalb: Nicht nur eine Rolle simulieren – die tatsächliche Identität mit einem realen Gastkonto testen.
RLS schützt Zeilen, nicht Spalten oder Tabellen
RLS beantwortet die Frage „Welche Zeilen darf ein Nutzer sehen?“. Es beantwortet nicht die Frage „Welche Modellobjekte darf er überhaupt kennen?“. Wenn der Vertrieb alle Kunden sehen darf, aber keine Gehalts-, Kosten- oder Margenspalten, ist das kein klassischer RLS-Fall.
Object-Level Security: Tabellen und Spalten wirklich ausblenden
Object-Level Security kann Tabellen oder Spalten für bestimmte Rollen sperren. Dabei werden nicht nur die Daten verborgen; auch die zugehörigen Metadaten werden geschützt. Für den betroffenen Nutzer verhält sich ein gesperrtes Objekt damit weitgehend so, als existiere es nicht.
Ein typischer Fall ist HR-Reporting: Das Management soll Headcount, Fluktuation und Organisationsstruktur analysieren dürfen, individuelle Gehaltsinformationen dagegen nicht. Oder im Controlling: Der Vertrieb soll Umsatzentwicklung analysieren, aber keine detaillierten Kosten- und Margenspalten sehen.
Wichtig: OLS ist kein „Spalte im Bericht nicht anzeigen“. Eine im Visual nicht verwendete Spalte bleibt Bestandteil des Modells. OLS setzt auf Modellebene an.
OLS muss nicht mehr nur über externe Tools gepflegt werden
Tabular Editor bleibt für professionelle Modellpflege sehr nützlich. Power BI selbst bietet inzwischen mit der TMDL View eine native Möglichkeit, Modellmetadaten per Tabular Model Definition Language zu bearbeiten. Die TMDL View in Power BI Desktop ist mittlerweile allgemein verfügbar.
OLS bleibt trotzdem ein Mechanismus, der gründlich getestet werden muss. Wenn ein Report ein Objekt erwartet, das für einen Nutzer durch OLS nicht existiert, können Visualisierungen entsprechend fehlschlagen.
Apps, Freigaben und Audiences sind Distribution – nicht Datensicherheit
Power BI Apps und Audiences sind für die Verteilung fertiger Inhalte sehr sinnvoll. Verschiedene Zielgruppen können steuern, dass Vertrieb andere Berichte angeboten bekommt als Controlling oder Management. Das ist saubere Content-Distribution – aber noch keine Datensicherheit.
Die einfache Regel lautet: „Nicht im Menü sichtbar“ ist keine Security Policy.
Fabric und OneLake: Die fünfte Sicherheitsebene
Mit Microsoft Fabric endet die Sicherheitsarchitektur nicht mehr zwingend am Power-BI-Semantikmodell. OneLake Security kann Zugriff auf Tabellen beziehungsweise Ordner, Spalten und Zeilen bereits auf der Datenplattform steuern. Das ist insbesondere bei Direct-Lake-Architekturen relevant.
Je nach Architektur können Sicherheit auf OneLake-Ebene, RLS/OLS im semantischen Modell oder beide Ebenen zusammenspielen. Entscheidend ist, dass andere Zugriffswege auf dieselben Daten mitgeprüft werden – etwa Fabric-, SQL- oder Workspace-Rechte.
Daraus folgt die Architekturregel: Sicherheit muss entlang des tatsächlichen Zugriffspfads geprüft werden – nicht nur dort, wo der Report entsteht.
Welche Berechtigung ist für welchen Fall sinnvoll?
Szenario | Typischer Ansatz |
Management soll fertigen Bericht sehen | App/Freigabe + Read |
Nutzer soll nur eigene Region sehen | RLS |
Nutzer soll eigene Reports auf zentralem Modell erstellen | Build + RLS bei Bedarf |
Sensible Tabellen oder Spalten sollen unsichtbar sein | OLS |
Nutzer soll Inhalte im Workspace entwickeln | Contributor |
Nutzer soll App oder Berechtigungen verwalten | Member/Admin bewusst vergeben |
Nutzer soll Modell administrieren oder verändern | Write bzw. passende Workspace-Rolle |
Daten müssen bereits vor Power BI geschützt werden | Datenquellen-/OneLake-Security |
Externe Partner mit dynamischer RLS | Tatsächliche B2B-Identität und UPN testen |
Die häufigsten Fehler bei Power BI Berechtigungen
Zu viel Workspace-Zugriff: RLS ist sauber eingerichtet, Fachanwender bekommen aber gleichzeitig Contributor-, Member- oder Admin-Rechte.
Build als Sicherheitsgrenze missverstehen: Fehlendes Build schützt sensible Daten nicht zuverlässig.
Distribution mit Datensicherheit verwechseln: Apps, Audiences oder ausgeblendete Reports ersetzen keine RLS-/OLS-Regel.
Schlechte Gruppenstrategie: Einzelpersonen werden jahrelang direkt zu Rollen hinzugefügt, statt Gruppen und regelmäßige Reviews zu verwenden.
Nur Power BI absichern: Über Fabric, OneLake, SQL oder andere Zugriffspfade bestehen weiterreichende Rechte auf dieselben Daten.
Die technische Kernfrage lautet deshalb nicht: „Welche Rolle haben wir vergeben?“ Sondern: „Welcher Zugriff ist für diese Identität am Ende tatsächlich wirksam?“
Ein sauberes Berechtigungskonzept beginnt vor Power BI
Bevor Rollen eingerichtet werden, sollten fachliche Entscheidungen getroffen werden: Wer konsumiert nur? Wer entwickelt? Wer darf Modelle wiederverwenden? Wer darf sie verändern? Welche Datensätze unterscheiden sich nach Nutzer? Welche Tabellen oder Spalten sind sensibel? Welche Zugriffswege existieren außerhalb von Power BI? Wer verantwortet Rollen und Gruppen? Und wie wird regelmäßig überprüft, ob die Rechte noch stimmen?
Genau hier wird Berechtigungsmanagement zu Governance. Gute Power-BI-Sicherheit besteht nicht darin, möglichst viele Rollen anzulegen. Sie besteht darin, möglichst wenige, klar abgegrenzte und erklärbare Zugriffspfade zu schaffen.
Gerade zentrale semantische Modelle in Power BI brauchen deshalb klare Spielregeln, wenn Fachbereiche sie für Self-Service wiederverwenden.
Fazit: Berechtigungen sind eine Zugriffskette
Power BI bietet mit Workspace-Rollen, Read, Build, Reshare, Write, RLS und OLS sehr differenzierte Mechanismen. Microsoft Fabric erweitert diese Architektur zusätzlich um Sicherheit auf OneLake- und Datenplattformebene. Die Herausforderung besteht deshalb nicht im Fehlen von Funktionen, sondern darin, sie sauber voneinander zu trennen.
Workspace-Rollen steuern Zusammenarbeit. Semantikmodell-Rechte steuern Nutzung und Wiederverwendung. RLS steuert Zeilen. OLS steuert Modellobjekte. OneLake und die Datenquelle schützen den darunterliegenden Datenzugriff.
Erst wenn diese Ebenen zusammengedacht werden, lässt sich zuverlässig beantworten, was ein Nutzer tatsächlich sehen und tun darf.
Der nächste sinnvolle Schritt
Wenn eure Power-BI-Landschaft gewachsen ist und niemand mehr sicher erklären kann, warum einzelne Personen oder Gruppen bestimmte Daten sehen, ist das kein einzelnes RLS-Problem mehr. Dann lohnt sich eine strukturierte Betrachtung von Workspace-Struktur, Rollen, Semantic-Model-Rechten, RLS/OLS, Self-Service und Datenplattform gemeinsam. Die Daten-WG unterstützt dabei im Rahmen einer Power BI Beratung.
