Dynamic Row-Level Security in Power BI und Microsoft Fabric implementieren: Architektur, DAX-Muster und Governance auf Enterprise-Niveau

Von Mirko Peters · 2025-11-21 · Aktualisiert 2025-11-26

Dynamic Row-Level Security in Power BI und Microsoft Fabric implementieren, um den Datenzugriff einzelner Benutzer zu steuern, die Compliance sicherzustellen und sich an organisatorische Veränderungen anzupassen.

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

Dynamic Row-Level Security sollten Sie als ein System betrachten, das sich verändern kann. Es wächst und ändert sich mit Ihrer Organisation. Datenmodellentwurf, DAX-Ausdrücke, Benutzeridentität und Governance bestimmen gemeinsam, wie die Sicherheit in Power BI und Microsoft Fabric funktioniert. Wenn Sie es richtig aufsetzen, legen Sie fest, wer bestimmte Daten sehen darf.

Das Wichtigste in Kürze

• Dynamic Row-Level Security passt sich an die Anforderungen Ihres Unternehmens an. Sie legen damit fest, wer bestimmte Daten sehen darf. Dafür wird die Identität jedes Benutzers geprüft.

• Verwenden Sie USERPRINCIPALNAME() für die Sicherheit in der Cloud. Diese Funktion sorgt dafür, dass Benutzer nur ihre eigenen Daten sehen. So bleiben Ihre Informationen geschützt.

• Überprüfen Sie Ihre Sicherheitseinstellungen und Benutzergruppen regelmäßig. So verhindern Sie, dass Personen Daten sehen, die sie nicht sehen dürfen. Das hilft, Ihre Daten zu schützen.

• Erstellen Sie klare Sicherheitstabellen für die Verwaltung von Berechtigungen. So behalten Sie die Kontrolle darüber, wer was sehen darf, während Ihr Unternehmen wächst.

• Testen Sie Ihre Sicherheitsregeln in der Cloud mit echten Benutzern. So stellen Sie sicher, dass Ihre Daten geschützt sind. Benutzer sehen dann nur die Daten, für die sie berechtigt sind.

Row-Level-Security-Systeme neu denken

Security als modellgesteuertes System

Row-Level Security ist ein System, das verschiedene Teile Ihrer Analyseplattform miteinander verbindet. Wenn Sie Ihr Datenmodell entwerfen, beginnen Sie bereits mit dem Aufbau der Datensicherheit. Wie Sie Tabellen anlegen, miteinander verknüpfen und Rollen definieren, bestimmt, wie Personen Daten sehen. Wenn Ihr Unternehmen wächst oder neue Teams hinzukommen, müssen Sie Ihre Sicherheitsregeln anpassen. Row-Level Security ist keine Aufgabe, die Sie einmal einrichten und dann vergessen. Sie verändert sich mit Ihrem Geschäft und den neuen Anforderungen.

Tipp: Überprüfen Sie Ihr Datenmodell regelmäßig. Ein gutes Modell vereinfacht die Sicherheit und hilft Ihnen, Fehler zu vermeiden.

Ihr Modell sollte klare Beziehungen und spezielle Sicherheitstabellen enthalten. So steuern Sie, wer bestimmte Daten sehen darf, und schützen vertrauliche Informationen. Dynamic Row-Level Security kann die Ansicht eines Benutzers an seine Gruppe oder Funktion in Fabric koppeln. So können Sie Berechtigungen schnell anpassen, wenn sich Ihr Unternehmen verändert.

Statische vs. dynamische Row-Level Security

Es gibt zwei grundlegende Ansätze für die Datensicherheit: statische und dynamische Row-Level Security. Statische Sicherheit arbeitet mit festen Regeln. Sie erstellen Rollen und Filter für jede Gruppe. Das eignet sich für kleine Teams oder wenn sich der Zugriff kaum ändert. Dynamische Row-Level Security nutzt den angemeldeten Benutzer und Zuordnungstabellen. Sie prüft den Benutzer und passt die angezeigten Daten sofort an. Das ist besser für große Unternehmen mit vielen Benutzern und wechselnden Regeln.

Hier finden Sie eine Tabelle mit den Unterschieden:

Dynamic Row-Level Security bietet mehr Möglichkeiten, den Zugriff zu steuern. Dafür nutzt es Funktionen wie USERPRINCIPALNAME() und Zuordnungstabellen, um Benutzer den richtigen Daten zuzuordnen. Statische Sicherheit ist einfach umzusetzen, stößt aber an Grenzen, wenn Ihr Unternehmen wächst oder sich stark verändert.

• Statische Row-Level Security begrenzt Daten über feste Regeln.

• Dynamische Row-Level Security passt an, welche Daten ein Benutzer sieht, abhängig davon, wer er ist.

• Dynamische Sicherheit eignet sich am besten für große Unternehmen mit vielen Regeln.

Wählen Sie den Ansatz, der zu Ihren Anforderungen passt. Gute Planung und ein solides Modell helfen Ihnen, vertrauliche Daten zu schützen und Ihre Analysen abzusichern.

Dynamische Row-Level-Security-Muster in Fabric

DAX-Funktionen: USERPRINCIPALNAME() vs. USERNAME()

Es ist wichtig zu verstehen, wie Identitäten in Fabric funktionieren. Zwei Funktionen sind für Row-Level Security zentral: USERPRINCIPALNAME() und USERNAME(). Beide ermitteln, wer den Bericht gerade öffnet. USERPRINCIPALNAME() liefert die E-Mail-Adresse des Benutzers aus der Cloud. USERNAME() liefert häufig einen lokalen Kontonamen, vor allem in Power BI Desktop. Wenn Sie USERNAME() in der Cloud verwenden, funktioniert es unter Umständen nicht richtig. Das kann Ihre Daten weniger sicher machen.

Tipp: Verwenden Sie für dynamische Zeilensicherheit in Fabric immer USERPRINCIPALNAME(). Diese Funktion gleicht die Cloud-E-Mail-Adresse des Benutzers ab und schützt so Ihre Daten.

Wenn Sie die falsche Funktion verwenden, können Benutzer Daten sehen, die sie nicht sehen dürfen. Sie müssen Ihre Sicherheit in der Cloud testen, nicht nur in Desktop.

Sichere DAX-Muster und Anti-Muster

Ihre Daten sollen geschützt bleiben. Dafür benötigen Sie belastbare DAX-Muster für dynamische Zeilensicherheit. Am besten arbeiten Sie mit Zuordnungstabellen und dynamischen Regeln. So steuern Sie, wer welche Daten sehen darf.

• Zeilenfilter begrenzen, was Benutzer sehen können. Sie können Daten nach Region, Abteilung oder Konto sperren.

• Spaltenmasken blenden Daten aus oder verändern sie in Abhängigkeit davon, wer der Benutzer ist.

Ein gutes DAX-Muster verwendet eine Suche, um Benutzer ihrer Gruppe zuzuordnen. Das funktioniert gut in Unternehmen mit vielen Gruppen. Hier ist ein gutes Beispiel:

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

Dieses Muster prüft die E-Mail-Adresse des Benutzers und ermittelt seine Gruppe. Damit zeigen Sie nur die richtigen Daten an. Dieser Ansatz ist besser als ein reiner Abgleich von E-Mail-Adressen. Er funktioniert auch mit wachsendem Unternehmen und schützt Ihre Daten.

Hinweis: Fest codierte E-Mail-Adressen oder berechnete Spalten für Zugriffe sollten Sie nicht verwenden. Diese Ansätze können brechen, wenn sich Benutzer ändern oder Ihr Unternehmen wächst.

Einige schlechte Muster können zu Datenlecks führen:

• Verwendung von USERNAME() in der Cloud.

• Fest codierte Benutzer-E-Mail-Adressen oder Domänen.

• Sicherheitslogik in berechneten Spalten.

Verwenden Sie immer dynamische Regeln und Zuordnungstabellen. So bleibt Ihr Datenmodell einfach und Ihre Daten bleiben geschützt.

Hierarchien und die Funktion PATH()

Manchmal benötigen Sie Sicherheit für Führungskräfte, Teams oder Abteilungen. Hierarchien helfen dabei. Mit der Funktion PATH() in DAX erstellen Sie Eltern-Kind-Beziehungen. So steuern Sie, wer auf welcher Ebene was sehen darf.

Sie können beispielsweise eine Tabelle mit Mitarbeiter- und Vorgesetzten-IDs anlegen. PATH() erstellt eine Kette von jedem Mitarbeiter bis zu seiner Führungskraft. Anschließend können Sie mit DAX die Daten für jede Ebene filtern.

PATH(Employee[EmployeeID], Employee[ManagerID])

Diese Funktion hilft Ihnen, dynamische Zeilensicherheit für große Unternehmen einzurichten. Sie können Führungskräften den Blick auf die Daten ihres Teams ermöglichen. Außerdem verhindern Sie, dass einfache Mitarbeiter zu viel sehen.

Tipp: Verwenden Sie PATH() für Sicherheit in Hierarchien. Das macht Ihr Datenmodell flexibel und schützt Ihre Daten.

Sie können Zeilenfilter, Spaltenmasken und Hierarchiefunktionen gemeinsam einsetzen. Das schützt vertrauliche Daten und steuert den Zugriff, während Ihr Unternehmen wächst.

Rollen- und Beziehungsarchitektur

Gestaltung der Sicherheitstabellen

Für dynamische Zeilensicherheit benötigen Sie Sicherheitstabellen. Diese Tabellen zeigen, welche Benutzer welche Daten sehen dürfen. Verwenden Sie Spalten für E-Mail-Adresse, Gruppe und Zugriffsstufe. So bleiben Ihre Daten auch bei wachsendem Unternehmen geschützt.
Beim Erstellen von Rollen sollten Sie restriktive und offene Rollen getrennt halten. Wenn eine Rolle jemandem den Zugriff auf alles erlaubt, funktionieren andere Rollen mit Zeilensicherheit unter Umständen nicht richtig. Damit Ihre Daten geschützt bleiben, müssen Sie verhindern, dass sich Rollen gegenseitig in die Quere kommen.

• Erstellen Sie Sicherheitstabellen mit klaren Spalten für Benutzer und Berechtigungen.

• Halten Sie Rollen getrennt, damit sie sich nicht überschneiden und Probleme verursachen.

• Prüfen Sie Ihre Sicherheitstabellen regelmäßig, um Änderungen nachzuverfolgen.

Beziehungen im Datenmodell

Wie Sie Ihr Datenmodell aufbauen, bestimmt, wie Sie den Zugriff steuern. Verwenden Sie einseitige Beziehungen zwischen Tabellen. So bleibt Ihr Modell einfach und Fehler lassen sich leichter vermeiden.
Es ist besser, spezielle Sicherheitstabellen zu verwenden, als Berechtigungen in Faktentabellen abzulegen. Sie können Ihre Sicherheitstabelle mit anderen Tabellen wie Abteilung oder Region verknüpfen. So lassen sich die Daten für jeden Benutzer oder jede Gruppe filtern.

Tipp: Verwenden Sie Brückentabellen, um Benutzer mit Daten zu verknüpfen. Das unterstützt die dynamische Zeilensicherheit und schützt Ihre Daten.

Rollengranularität: kleine vs. große Rollen

Sie müssen festlegen, wie detailliert Ihre Rollen sein sollen. Kleine Rollen geben Ihnen mehr Kontrolle. Sie können den Zugriff nach Aufgabe oder Gruppe vergeben. Große Rollen decken mehr Personen ab, können aber riskant sein, wenn sich Dinge ändern.
Überprüfen Sie regelmäßig, wer welche Rolle hat. So bleiben Ihre Daten sicher, und Sie können bei Bedarf Anpassungen vornehmen.
Wählen Sie kleine Rollen für mehr Kontrolle und einfache Aktualisierungen. Große Rollen können für einfache Gruppen funktionieren, verursachen in großen Unternehmen aber oft Probleme.

Benutzer- und Gruppenzuweisungen in Fabric

Azure AD-Gruppen vs. einzelne Benutzer

Sie vergeben Zugriff in Fabric, indem Sie Benutzer in Azure AD-Gruppen aufnehmen. So können Sie die Daten vieler Personen gleichzeitig steuern. Es ist sicherer, mit Gruppen zu arbeiten, als jede Person einzeln hinzuzufügen. Gruppen erleichtern die Verwaltung Ihres Systems und verringern den Aufwand. Wenn sich Ihr Team ändert, können Sie Gruppen schnell aktualisieren. Die Verknüpfung von Gruppen mit Rollen vereinfacht die Datenmodellierung. Ihre Regeln für Sicherheit auf Zeilenebene bleiben übersichtlich und einfach.

Tipp: Verwenden Sie Azure AD-Gruppen für die Zugriffssteuerung. Das hilft Ihnen, weniger Fehler zu machen, und spart Zeit.

Überlappende Gruppen und verdeckter Zugriff

Achten Sie auf überlappende Gruppen. Manchmal ist ein Benutzer in mehr als einer Gruppe. Dadurch kann er Daten sehen, die er nicht sehen sollte. Verdeckter Zugriff entsteht, wenn dieser Fehler dazu führt, dass Benutzer zusätzliche Daten sehen. Prüfen Sie Gruppenlisten regelmäßig, um dies zu verhindern. Verwenden Sie Tabellen, um nachzuverfolgen, welche Benutzer in welcher Gruppe sind. Eine gute Datenmodellierung hilft, Probleme frühzeitig zu erkennen. Entfernen Sie Benutzer aus Gruppen, die sie nicht mehr benötigen, um Ihre Daten zu schützen.

Hinweis: Verdeckter Zugriff kann private Daten offenlegen. Beheben Sie Überschneidungen zwischen Gruppen, um Ihr System sicher zu halten.

Geplante Zugriffsüberprüfungen

Sie sollten regelmäßige Zugriffsüberprüfungen planen. Prüfen Sie in festen Abständen, wer in welcher Gruppe ist. Bitten Sie die Gruppenbesitzer, festzulegen, wer Zugriff haben sollte. So bleibt Ihre dynamische Sicherheit auf Zeilenebene auch mit wachsendem Unternehmen wirksam. Nutzen Sie Fabric-Tools, um diese Prüfungen zu unterstützen. Entfernen Sie alte Benutzerkonten, damit Ihre Daten sicherer sind. So bleibt Ihr Analysesystem übersichtlich und sicher. Machen Sie Zugriffsüberprüfungen zu einem selbstverständlichen Teil Ihrer Business-Intelligence-Arbeit.

• Legen Sie Termine fest, an denen alle Gruppen überprüft werden.

• Nutzen Sie Fabric-Tools, um Gruppen zu prüfen.

• Lassen Sie die Besitzer bestätigen, wer in welcher Gruppe ist.

Warnung: Regelmäßige Überprüfungen helfen Ihnen, Fehler zu erkennen, bevor sie Probleme verursachen.

Identitätsauflösung: Desktop vs. Fabric

Identitätsfunktionen und Unterschiede in der Cloud

Es ist wichtig zu wissen, wie Identitäten in Power BI Desktop und Microsoft Fabric funktionieren. In Power BI Desktop zeigt USERNAME() meist Ihren Computernamen an. In Microsoft Fabric liefert USERPRINCIPALNAME() dagegen Ihre Cloud-E-Mail-Adresse. Dieser Unterschied ist für den Schutz Ihrer Daten entscheidend. Wenn Sie USERNAME() in der Cloud verwenden, sehen unter Umständen die falschen Personen Daten. Verwenden Sie für Cloud-Berichte immer USERPRINCIPALNAME(). So bleiben Ihre Daten geschützt und passen zum Identitätssystem Ihres Unternehmens.

Tipp: Testen Sie Ihre Regeln für Sicherheit auf Zeilenebene in der Cloud. Tests auf dem Desktop zeigen nicht den tatsächlichen Benutzerzugriff.

Dataset-Besitzer und Mandanteneinstellungen

Sie sollten wissen, wer Besitzer Ihres Datasets ist. Der Besitzer kann die Aktualisierungseinstellungen ändern und dadurch beeinflussen, wer Daten sieht. Wenn Sie den Besitzer wechseln, können Sie unter Umständen ändern, wer auf private Daten zugreifen kann. Auch die Mandanteneinstellungen sind wichtig. Sie legen fest, wie Identitäten in Ihrem Unternehmen funktionieren. Prüfen Sie die Mandanteneinstellungen, bevor Sie Berichte veröffentlichen. Stellen Sie sicher, dass Ihr Datenmodell den Sicherheitsregeln Ihres Unternehmens entspricht.

Häufige Ursachen für RLS-Lecks

Sie können die Kontrolle über die Sicherheit auf Zeilenebene verlieren, wenn Sie nicht in der Cloud testen. Manchmal sehen Benutzer mehr Daten, als sie sollten. Das kann passieren, wenn Sie die falsche Identitätsfunktion verwenden oder vergessen, Gruppenmitgliedschaften zu aktualisieren. Lecks können auch entstehen, wenn Sie Ihr Datenmodell ändern, ohne die Sicherheitstabellen zu prüfen. Überprüfen Sie Ihre Datensicherheitskonfiguration nach jeder Änderung. Nutzen Sie Cloud-Tests und regelmäßige Audits, um Probleme frühzeitig zu finden.

Warnung: Datensicherheitslecks können private Informationen offenlegen. Überprüfen Sie Ihre Konfiguration regelmäßig, um Ihr Unternehmen zu schützen.

Testing, Auditing und Governance

Cloud-basiertes RLS-Testing

Sie müssen Row-Level Security in der Cloud testen. Nur so stellen Sie sicher, dass Ihre Daten für echte Benutzer geschützt sind. Das Tool „Anzeigen als“ in Desktop zeigt nur eine Vorschau. Es zeigt nicht, wie die Regeln in Microsoft Fabric tatsächlich greifen. Testen Sie nach der Veröffentlichung Ihres Berichts mit echten Benutzern und Gruppen. So sehen Sie, welche Daten jede Person tatsächlich anzeigen kann. Verwenden Sie Testkonten, um zu prüfen, ob Benutzer nur ihre eigenen Daten sehen. Testen Sie immer erneut, wenn Sie Rollen ändern oder Ihr Modell aktualisieren. Tests in der Cloud helfen Ihnen, Probleme zu finden, bevor sie Ihrem Unternehmen schaden.

Tipp: Testen Sie immer mit echten Benutzern in der Cloud und nicht nur in Desktop. So bleibt Ihre Datensicherheit stark.

Automatisierung für Audits und Überprüfungen

Sie können Automatisierung nutzen, um Audits und Überprüfungen in Fabric zu erleichtern. Automatisierung prüft Berechtigungen für Arbeitsbereiche, Datenflüsse und Vertraulichkeitsbezeichnungen nach einem Zeitplan. Microsoft Purview bietet Dashboards, mit denen Sie Richtlinien über Ihre Plattform hinweg nachverfolgen können. Sie können Aktivitätsprotokolle und Admin-APIs nutzen, um Compliance-Probleme zu finden. Automatisierung hilft Ihnen, Probleme früh zu erkennen und spart Zeit. Prüfer können den vollständigen Weg sensibler Spalten vom Ursprung bis zum Bericht nachvollziehen. Das macht Überprüfungen schneller und präziser. Automatisierung erleichtert außerdem die Einhaltung von Vorgaben wie DSGVO und HIPAA und senkt dabei den Aufwand.

• Richten Sie automatische Prüfungen für Berechtigungen und Datenflüsse ein.

• Nutzen Sie Dashboards, um Änderungen an Sicherheitsrichtlinien im Blick zu behalten.

• Prüfen Sie Aktivitätsprotokolle, um Probleme schnell zu finden.

Dokumentation und Änderungsmanagement

Gute Aufzeichnungen sind nötig, damit Ihr Datensicherheitssystem übersichtlich bleibt. Halten Sie Ihre Sicherheitsregeln, Gruppenlisten und Rollenänderungen schriftlich fest. Aktualisieren Sie Ihre Notizen, wenn Sie das Modell ändern oder neue Benutzer hinzufügen. Klare Aufzeichnungen helfen Ihnen nachzuvollziehen, wer welche Daten sehen kann. Außerdem erleichtern sie neuen Teammitgliedern das Verständnis Ihres Systems. Änderungsmanagement bedeutet, Aktualisierungen vor der Veröffentlichung zu prüfen und zu genehmigen. So bleibt Ihr Row-Level Security auch dann sicher, wenn Ihr Unternehmen wächst.

Hinweis: Halten Sie Ihre Aufzeichnungen auf dem neuesten Stand. Das schützt Ihre Daten und hilft Ihnen, Probleme schnell zu beheben.

Row-Level Security sollten Sie als etwas betrachten, das sich mit Ihren Daten und Ihrem Unternehmen weiterentwickelt. Ein solides Setup hilft, private Informationen zu schützen. Gut durchdachte DAX-Muster und ein sauberes Identitätsmanagement schützen Ihre Daten zusätzlich. Wenn Sie Ihre Sicherheitseinstellungen regelmäßig prüfen und Änderungen dokumentieren, erkennen Sie Probleme frühzeitig. Wer vorausplant, kontrolliert besser, wer Daten sieht, und hält seine Analysen sicher.

• Prüfen Sie Ihre Sicherheitseinstellungen regelmäßig.

• Passen Sie Regeln an, um Daten besser zu schützen.

• Stellen Sie den Datenschutz immer an erste Stelle.

Häufige Fragen

Was ist dynamische Row-Level Security in Power BI und Fabric?

Dynamische Row-Level Security steuert den Datenzugriff abhängig davon, wer den Bericht aufruft. Mithilfe von DAX-Funktionen und Zuordnungstabellen ordnen Sie Benutzer den passenden Daten zu.

Warum sollten Sie USERPRINCIPALNAME() statt USERNAME() verwenden?

USERPRINCIPALNAME() liefert die Cloud-E-Mail-Adresse des Benutzers. Das funktioniert in Power BI und Fabric am zuverlässigsten. USERNAME() kann dagegen einen lokalen Namen liefern, was in der Cloud zu Sicherheitsproblemen führen kann.

Wie helfen Azure AD-Gruppen bei der Sicherheit?

Mit Azure AD-Gruppen verwalten Sie den Zugriff für viele Benutzer gleichzeitig. Sie fügen Benutzer Gruppen hinzu und weisen diesen Rollen zu. Das macht Ihre Sicherheitseinstellungen einfacher und sicherer.

Was ist eine Sicherheitstabelle, und warum brauchen Sie eine?

Eine Sicherheitstabelle listet Benutzer, Gruppen und Berechtigungen auf. Damit steuern Sie, wer bestimmte Daten sehen darf. So bleiben Ihre Daten auch mit wachsendem Unternehmen geschützt.

Wie oft sollten Sie Row-Level Security in der Cloud testen?

Testen Sie Row-Level Security jedes Mal, wenn Sie Rollen, Gruppen oder Ihr Datenmodell ändern. Tests in der Cloud zeigen, was echte Benutzer sehen, und helfen Ihnen, Probleme früh zu erkennen.