Warum Ihre Power BI-RLS im Desktop funktioniert, in Fabric aber Daten preisgibt

Von Mirko Peters · 2026-08-11

Willkommen zurück im Blog zu Data Engineering und Analytics! Wenn Sie schon einmal ein beeindruckendes Dashboard erstellt, Ihre Row-Level Security lokal in Power BI Desktop geprüft, das Ganze in die Cloud veröffentlicht und dann einen Schreckmoment erlebt haben, weil ein Standardbenutzer Informationen sehen konnte, für die er keine Berechtigung hat, sind Sie damit garantiert nicht allein. Die Sich

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Titelbild: Why Your Power BI RLS Works in Desktop But Leaks in Fabric

In diesem Beitrag gehen wir detailliert darauf ein, warum Ihre Power BI-RLS nach der Bereitstellung möglicherweise Daten preisgibt, wie sich die Identitätszuordnung zwischen den Umgebungen unterscheidet und wie Sie robuste, cloudnative Sicherheitsmuster umsetzen. Schauen wir uns gemeinsam die Architektur hinter der Datensicherheit im Unternehmen an.

In diesem Beitrag gehen wir detailliert darauf ein, warum Ihre Power BI-RLS nach der Bereitstellung möglicherweise Daten preisgibt, wie sich die Identitätszuordnung zwischen den Umgebungen unterscheidet und wie Sie robuste, cloudnative Sicherheitsmuster implementieren können. Wir schauen uns die Architektur hinter der Datensicherheit im Unternehmen genau an.

Bevor Sie auch nur eine Zeile Data Analysis Expressions bzw. DAX schreiben, brauchen Sie das richtige mentale Modell für Sicherheit. Viele Entwickler behandeln Row-Level Security als einfaches Kontrollkästchen oder als schnelle Verwaltungseinstellung am Ende eines Projekts. Tatsächlich ist Sicherheit ein zusammenhängendes System.

Bevor Sie auch nur eine Zeile Data Analysis Expressions, kurz DAX, schreiben, benötigen Sie das richtige Denkmodell für Sicherheit. Viele Entwickler behandeln die zeilenbasierte Sicherheit (Row-Level Security) als einfaches Kontrollkästchen oder als schnelle Verwaltungseinstellung am Ende eines Projekts. Tatsächlich ist Sicherheit ein zusammenhängendes System.

Rollendesign: Wenige, zweckgerichtete Rollen sind besser als eine wuchernde Menge sich überschneidender Rollen. Hundert statische Rollen für einzelne Benutzer werden schnell zum administrativen Albtraum.
Rollendesign: Wenige, zweckgerichtete Rollen sind besser als unübersichtliche, sich überschneidende. Hundert statische Rollen für einzelne Benutzer werden schnell zu einem administrativen Albtraum.
Dynamischer Kontext: Die Sicherheit muss darauf reagieren, wer den Bericht betrachtet und in welcher Beziehung diese Person innerhalb des Unternehmens zu den Daten steht.
Cloud-Realität: Die Identitätsauflösung und die Mandanteneinstellungen in Fabric können das Verhalten im Vergleich zu Ihrem lokalen Rechner grundlegend verändern. Zu verstehen, wie die Cloud Ihre Benutzeridentität zuordnet, ist unverzichtbar.

Sichere DAX-Ausdrücke für Ihre Rollen sind das Fundament einer wirksamen Datenisolation. Je nach Organisationsstruktur und Umfang werden Sie sich wahrscheinlich für statische oder dynamische Filtermuster entscheiden.

Gut geschriebene DAX-Ausdrücke für Ihre Rollen sind die Grundlage für eine wirksame Datenisolation. Je nach Aufbau und Größe Ihrer Organisation werden Sie sich wahrscheinlich für ein statisches oder ein dynamisches Filtermuster entscheiden.

Statische RLS (einfach, feste Zielgruppen)

Beispiel für DimRegion:
DimRegion[Region] = "US"

Dynamische RLS über eine Brückentabelle (empfohlen)

Tabellen: Users (UPN, UserKey), UserRegion (UserKey, RegionKey), DimRegion (RegionKey, Region)
Rollenfilter auf Users:
Users[UPN] = USERPRINCIPALNAME()
Optional können Sie DimRegion über eine Beziehung von Users > UserRegion > DimRegion einschränken.

Vermeiden

Sicherheit auf Basis berechneter Spalten, die beim Datenaktualisieren ausgewertet wird und nicht dynamisch pro Benutzerkontext.
USERNAME() in Fabric (verwenden Sie immer USERPRINCIPALNAME(); testen Sie Mailformate und UPN-Suffixe gründlich).
Einzelne E-Mail-Adressen oder Domänen direkt in Ihre Filterausdrücke fest codieren.

Hilfreiche dynamische Muster

Mehrmandantenmodelle: Ordnen Sie TenantId aus Ihrer zentralen Users-Tabelle direkt den Faktentabellen und Dimensionstabellen zu.
Hierarchien: Speichern Sie die Beziehungen zwischen Vorgesetzten und Mitarbeitenden, materialisieren Sie eine Zugriffstabelle und filtern Sie nach allen strukturellen Untergebenen des aktuellen Betrachters.

Die Form Ihres Datenmodells bestimmt Ihre Sicherheitsgrenzen. Verwenden Sie nach Möglichkeit einseitig gerichtete Filter, um mehrdeutige n:m-Pfade zu vermeiden, die Sicherheitsvorgaben unbemerkt umgehen. Erstellen Sie dedizierte Sicherheitsdimensionen, etwa Brückentabellen von Benutzer zu Zugriff, statt komplexe Geschäftslogik direkt in Ihre Faktentabellen einzubetten. Setzen Sie immer auf wenige wiederverwendbare Rollen mit dynamischen Filtern statt auf Dutzende statische Rollen.

Die Struktur Ihres Datenmodells bestimmt Ihre Sicherheitsgrenzen. Verwenden Sie nach Möglichkeit Filter mit einer einzigen Richtung, um mehrdeutige Viele-zu-Viele-Pfade zu vermeiden, die Sicherheitsbeschränkungen unbeabsichtigt umgehen könnten. Erstellen Sie eigene Sicherheitsdimensionen, etwa Brückentabellen zwischen Benutzern und Zugriffen, anstatt komplexe Geschäftslogik direkt in Ihre Faktentabellen einzubetten. Setzen Sie stets auf wenige wiederverwendbare Rollen mit dynamischen Filtern statt auf Dutzende statische Rollen.

Zuweisungen ohne Überraschungen (Benutzer und Gruppen)

Die effiziente Verwaltung von Zuweisungen ist entscheidend für die langfristige Betriebsstabilität. Ordnen Sie Ihre Rollen immer Azure AD-Gruppen statt einzelnen Benutzerkonten zu, damit Ihr System beim Wechsel von Mitarbeitenden in andere Teams problemlos skaliert. Beugen Sie veralteten Mitgliedschaften vor, indem Sie quartalsweise Zugriffsüberprüfungen mit den Gruppenbesitzern planen. Achten Sie auf überlappende Gruppenmitgliedschaften: Benutzer, die mehreren Sicherheitsgruppen angehören, können ungewollt ihren Datenzugriff erweitern.

Desktop vs. Fabric: Was sich nach der Veröffentlichung ändert

Hier passieren die meisten Sicherheitslecks. In Power BI Desktop arbeiten Sie in einer kontrollierten lokalen Testumgebung. Sobald Sie in Microsoft Fabric veröffentlichen, übernimmt die Cloud die Identitätsverwaltung. USERPRINCIPALNAME() gibt in Fabric die Cloud-E-Mail-Adresse zurück, während sich Vorschauen in Desktop je nach lokalen Anmeldeinformationen anders verhalten können. Darüber hinaus können der Besitzer des Datasets, die Aktualisierungsanmeldeinformationen, die Arbeitsbereichseinstellungen und die Verzögerung der Gruppensynchronisierung in Azure AD beeinflussen, was ein Benutzer letztlich sehen darf.

Tests, die Sicherheitslecks tatsächlich aufdecken

Verlassen Sie sich für die Freigabe der Produktionssicherheit niemals allein auf die Funktion „Anzeigen als“ in Power BI Desktop. Sie ist für schnelle Plausibilitätsprüfungen nützlich, dennoch müssen Sie in Fabric testen. Validieren Sie mit echten Sicherheitsgruppen und echten Benutzerkonten in einem Nicht-Produktionsarbeitsbereich. Testen Sie jede einzelne Rolle auf zentralen Berichtsseiten und bei sensiblen Visuals. Erwägen Sie, Stichproben über XMLA-Endpunkte oder Automatisierungstools zu skripten, um kleine Ergebnismengen für bekannte Testkonten zu exportieren.

Governance & Betrieb

Die Sicherheit über die Zeit aufrechtzuerhalten erfordert eine konsequente Governance. Katalogisieren Sie Ihre Rollen, dokumentieren Sie ihre DAX-Filter, listen Sie betroffene Tabellen auf und halten Sie die vorgesehenen Zielgruppen fest. Setzen Sie Änderungskontrollen über Pull Requests durch, bei denen RLS-Testnachweise vor dem Zusammenführen von Modelländerungen erforderlich sind. Definieren Sie klare Datenverträge, die festlegen, welche Dimensionen und Fakten an RLS teilnehmen müssen. Führen Sie quartalsweise Rezertifizierungen der Gruppenmitgliedschaften durch und überwachen Sie Ihre risikoreichen Berichte auf Auffälligkeiten.

Typische Fehlermuster (und Lösungen)

Wenn Probleme auftreten, prüfen Sie Ihre Konfiguration anhand dieser typischen Fehlermuster:

Funktioniert in Desktop, gibt in Fabric Daten preis: Ursache ist die Verwendung von USERNAME() oder nicht übereinstimmende Identitätsformate. Lösung: Verwenden Sie einheitlich USERPRINCIPALNAME() und gleichen Sie Ihre Users[UPN]-Werte ab.
Benutzer sieht zu viel: Ursache ist ein Many-to-Many-Pfad, der die Sicherheit umgeht. Lösung: Fügen Sie eine Sicherheitsdimension hinzu und schränken Sie die Beziehungen ein.
Früherer Teamzugriff bleibt bestehen: Ursache sind veraltete Azure AD-Gruppenmitgliedschaften. Lösung: Automatisieren Sie die Rezertifizierungs- und Entfernungsprozesse.
Berechnete Spalte zur Identifizierung verwendet: Führt zu keiner benutzerspezifischen Wirkung. Lösung: Verschieben Sie die Logik in DAX-Rollenfilter über die Modelltabellen.

Checkliste für den schnellen Start (diese Woche)

Fügen Sie eine Tabelle Users hinzu, die über USERPRINCIPALNAME() identifiziert wird, und verknüpfen Sie sie mit Ihren Zugriffstabellen.
Wandeln Sie fest codierte Filter, wo sinnvoll, in dynamische, tabellengesteuerte Filter um.
Ersetzen Sie jede Logik mit USERNAME() durch USERPRINCIPALNAME() und testen Sie erneut in Fabric.
Ordnen Sie Rollen Azure AD-Gruppen zu und planen Sie eine Zugriffsüberprüfung mit den Gruppenbesitzern.
Veröffentlichen Sie in einem Testarbeitsbereich, validieren Sie mit echten Benutzern und beheben Sie Identitätslücken.
Dokumentieren Sie Ihre Rollen, DAX-Ausdrücke und Tabellen in der README-Datei Ihres Modells.

Vorgeschlagene SEO-Elemente

URL-Slug: power-bi-row-level-security-architecture
Meta-Titel: Power BI Row-Level Security: Architektur, DAX-Muster und cloudbereite Governance
Meta-Beschreibung: Gehen Sie über das RLS-Kontrollkästchen hinaus. Lernen Sie dynamische DAX-Muster, Rollendesign, die Zuordnung zu Azure AD und fabric-spezifische Tests kennen, um sensible Daten wirklich zu schützen.
Schlüsselwörter: Power BI, Row-Level Security, RLS, USERPRINCIPALNAME, Azure AD-Gruppen, Fabric, dynamische RLS, Datengovernance

Fazit

Row-Level Security ist keine Funktion, die Sie einmal konfigurieren und dann vergessen können. Sie ist ein lebendiges System aus Datenmodellen, Beziehungen, DAX-Formeln, Identitätszuordnung und Cloud-Governance-Einstellungen. Wenn Sie sich von starren statischen Rollen lösen, auf robuste dynamische Brückentabellen setzen und gründlich in Microsoft Fabric testen, bleiben Ihre Daten sicher, egal wie Ihre Organisation wächst und sich verändert.

Um dieses Thema noch tiefer zu erkunden und praktische Umsetzungsstrategien kennenzulernen, sollten Sie sich unbedingt unsere passende Podcast-Folge anhören: Implement Power BI Row-Level Security in Microsoft Fabric. Sichern Sie Ihre Daten nicht nur ab, sondern entwickeln Sie eine widerstandsfähige Sicherheitsarchitektur, die sich mit Ihrer Organisation weiterentwickelt!