Data-Governance-Strategie in 6 Schritten aufbauen

Eine Data-Governance-Strategie in Power BI und Microsoft Fabric funktioniert, wenn das Produkt die Regeln durchsetzt und sie nicht nur aufgeschrieben sind. Sechs Bausteine setzen sie durch: wer einen Workspace öffnen darf, welche Zeilen ein Semantic Model filtert, welche Inhalte ein Sensitivity Label tragen, welche Reports als vertrauenswürdig markiert sind, ob sich die Daten eines Reports bis zur Quelle zurückverfolgen lassen und ob jemand die Logs prüft. Richten Sie jeden einzelnen ein, und die Strategie hält, auch wenn niemand an ein Richtliniendokument erinnert.

Dieser Beitrag behandelt die Technik. Wo Governance unter den anderen Ebenen einer Datenstrategie steht, etwa Datenquellen, Plattform und semantische Schicht, lesen Sie in unserem Leitfaden zum Aufbau eines Frameworks für die Datenstrategie.

Schritt 1: Den Workspace als Zugriffsgrenze festlegen

Ein Fabric-Workspace ist ein einzeln absicherbarer Container. Alle, die ihn öffnen können, teilen den Zugriff auf die Semantic Models, Reports und anderen Elemente darin. Wer ihn nicht öffnen kann, sieht nichts. Vier Rollen steuern diesen Zugriff:

• Admin kann den Workspace aktualisieren oder löschen und jeden hinzufügen oder entfernen, auch andere Admins.

• Member kann Personen mit niedrigeren Berechtigungen hinzufügen und Inhalte bearbeiten, aber niemanden aus einer Rolle entfernen.

• Contributor kann Inhalte erstellen und ändern, aber nicht verwalten, wer sonst Zugriff hat.

• Viewer hat nur Lesezugriff auf die Inhalte des Workspace.

Rollen lassen sich einer einzelnen Person oder einer Sicherheitsgruppe, einer Microsoft-365-Gruppe oder einer Verteilerliste zuweisen. Verschachteln Sie Gruppen und weisen die Rolle der äußeren Gruppe zu, erben alle darin diese Rolle. Weisen Sie Rollen Gruppen statt einzelnen Personen zu, aktualisiert das Hinzufügen oder Entfernen einer Person in der Gruppe ihren Zugriff überall, wo die Gruppe verwendet wird, und Sie müssen nicht jeden Workspace von Hand bearbeiten. Was jede Rolle kann und was nicht, steht in unserem Leitfaden zu Power-BI-Workspace-Rollen.

Schritt 2: Den Zugriff unterhalb des Workspace mit Row-Level Security eingrenzen

Eine Workspace-Rolle steuert den ganzen Workspace. Row-Level Security (RLS) steuert, welche Zeilen innerhalb eines Semantic Models eine Person sieht. Beide greifen auf eine Weise ineinander, die Sie gezielt planen sollten: RLS in Power BI gilt nur für Personen mit der Rolle Viewer in diesem Workspace. Admins, Members und Contributors haben Bearbeitungsrechte am Semantic Model, deshalb filtert RLS ihre Ansicht nicht. Soll RLS laut Governance-Plan für jemanden gelten, kann diese Person im Workspace nur die Rolle Viewer erhalten.

Eine dynamische RLS-Rolle nutzt einen DAX-Filterausdruck, der den angemeldeten Benutzer in einer Zuordnungstabelle nachschlägt:

[Department] =
LOOKUPVALUE (
    'UserDepartmentMap'[Department],
    'UserDepartmentMap'[Email], USERPRINCIPALNAME ()
)

Zwei Personen mit Viewer-Zugriff auf denselben Report sehen unterschiedliche Zeilen, gefiltert nach ihrer eigenen Abteilung, ohne dass für jede ein eigener Report gebaut werden muss. Definieren Sie die Rollen in Power BI Desktop, veröffentlichen Sie und fügen Sie dann im Power BI Service jeder Rolle Mitglieder hinzu. Unser Leitfaden zu Row-Level Security in Power BI behandelt statische Rollen, das Testen einer Rolle vor der Veröffentlichung und das Verhalten von RLS bei DirectQuery- und Direct-Lake-Modellen.

Schritt 3: Inhalte mit Sensitivity Labels klassifizieren

Sensitivity Labels stammen aus Microsoft Purview Information Protection, demselben Kennzeichnungssystem, das in ganz Office genutzt wird. Sie lassen sich auf Semantic Models, Reports, Dashboards, Dataflows und Paginated Reports anwenden, in Power BI Desktop oder im Power BI Service. Auf Arbeitsmappen lassen sie sich nicht anwenden.

Zwei Dinge an ihrem Verhalten werden leicht falsch eingeschätzt:

• Ein Label schränkt den Zugriff im Power BI Service nicht ein. Dort steuern allein Workspace- und Elementberechtigungen den Zugriff. Das Label steuert, was passiert, wenn die Daten Power BI verlassen: Export nach Excel, PowerPoint oder PDF, Download als .pbix und „In Excel analysieren“ tragen die Verschlüsselungseinstellungen des Labels mit, sodass nur Personen mit ausreichenden Nutzungsrechten die exportierte Datei öffnen können.

• Labels wandern von allein weiter, sobald sie angewendet sind. Ein neuer Report auf Basis eines Semantic Models mit Label erbt dieses Label automatisch. Ein Label auf einem Semantic Model oder Report kann auch an darauf aufbauende Inhalte weitergegeben werden. Wird ein Semantic Model mit Label über eine Live-Verbindung in Excel geöffnet, geht das Label auch dort mit, und eine Excel-Datei wird nie auf ein weniger restriktives Label herabgestuft als das, das sie schon trägt.

Sensitivity Labels werden im Microsoft-Purview-Portal erstellt und verwaltet, nicht in Power BI selbst, und ein Tenant braucht die passende Lizenz, damit sie als Option erscheinen.

Schritt 4: Inhalte zertifizieren, damit alle wissen, wem sie vertrauen können

Endorsement ist der Weg, wie ein gesteuerter Inhaltskatalog zeigt, welchen Report man zuerst öffnen sollte. Fabric kennt zwei Kernstufen, die für fast jeden Elementtyp außer Power-BI-Dashboards gelten, sowie ein weiteres Kennzeichen für einen anderen Zweck:

• Promoted (hervorgehoben) sind Inhalte, die ihr Ersteller oder jeder mit Schreibrechten als gut genug zum Teilen markiert. Das signalisiert „jemand steht dahinter“, nicht „das wurde geprüft“.

• Certified (zertifiziert) sind Inhalte, die ein Prüfer, den der Fabric-Administrator ausdrücklich berechtigt hat, anhand des unternehmenseigenen Qualitätsstandards geprüft hat. Das signalisiert „das wurde geprüft“. Elementeigentümer, die keine berechtigten Prüfer sind, müssen die Zertifizierung beantragen und können sie nicht selbst vergeben.

Ein drittes Kennzeichen, Master data, markiert ein Element als die zentrale Quelle der Wahrheit des Unternehmens, etwa für eine Kundenliste oder eine Produktcode-Tabelle, und ist ebenfalls berechtigten Prüfern vorbehalten. Zertifizierte Elemente sind überall gekennzeichnet, wo Personen nach Inhalten suchen, auch in Suchergebnissen und in Excel unter „Daten abrufen“, und zertifizierte und hervorgehobene Elemente werden vor nicht zertifizierten angezeigt.

Schritt 5: Den Weg der Daten mit der Lineage-Ansicht nachvollziehbar machen

Jeder Fabric-Workspace hat eine integrierte Lineage-Ansicht. Sie zeigt jedes Element im Workspace, wie die Elemente miteinander verbunden sind, und die externen Datenquellen, die die Semantic Models und Dataflows eine Ebene weiter oben speisen. Öffnen Sie sie über die Symbolleiste des Workspace, über das Optionsmenü eines Elements oder über die Detailseite des Elements.

Jeder mit einer Rolle im Workspace kann die Lineage-Ansicht öffnen, aber ein Viewer sieht die Datenquellenkarten nicht, nur die Elemente und ihre Verbindungen. Die Lineage-Ansicht zeigt vorgelagerte Verbindungen außerhalb des Workspace, aber keine nachgelagerten in anderen Workspaces. Was über Workspace-Grenzen hinweg von einem Element abhängt, zeigt stattdessen die Impact-Analyse-Ansicht von Fabric. Stimmt ein Report nicht mehr mit den Erwartungen überein, prüfen Sie in der Lineage-Ansicht, ob er aus der richtigen Datenquelle liest.

Schritt 6: Die Logs prüfen, statt anzunehmen, dass die Regeln halten

Jedes Mal, wenn ein Sensitivity Label angewendet, geändert oder entfernt wird, hält Power BI das im Überwachungsprotokoll fest, neben Aktivitäten wie wer wann einen Report mit Label angesehen hat. Das Power-BI-Admin-Portal bietet außerdem einen Report mit Schutzmetriken, der einen tenantweiten Überblick gibt, wo sich sensible Daten tatsächlich befinden. Keines von beiden läuft von allein. Legen Sie einen Rhythmus fest, in dem jemand beide öffnet und prüft, ob die Labels dort gelandet sind, wo sie sein sollten, und ob die Endorsement-Kennzeichen noch zur Realität passen. Nehmen Sie nicht einfach an, dass die Regeln aus den Schritten 1 bis 5 noch gelten.

FAQs

Was sind die Kernbausteine einer Data-Governance-Strategie in Power BI und Fabric?

Workspace-Rollen bestimmen, wer einen Workspace öffnen darf. Row-Level Security grenzt ein, was ein Viewer in einem Semantic Model sieht. Sensitivity Labels klassifizieren Inhalte und schützen sie, sobald sie Power BI verlassen. Endorsement zeigt, welchen Inhalten man vertrauen kann, und die Lineage-Ansicht verfolgt einen Report bis zur Quelle zurück. Jeder Baustein wird vom Produkt durchgesetzt und ist keine Regel, an die sich Menschen erinnern müssen.

Wie oft sollte eine Data-Governance-Strategie überprüft werden?

Überprüfen Sie sie, wann immer ein neuer Workspace oder eine neue Kapazität angelegt wird und wann immer sich eine Richtlinie für Sensitivity Labels ändert. Legen Sie darüber hinaus einen festen Rhythmus fest, etwa einmal pro Quartal, und prüfen Sie den Report mit Schutzmetriken im Power-BI-Admin-Portal und das Überwachungsprotokoll, statt sich auf die Erinnerung an die Konfiguration zu verlassen.

Welche Rolle spielt Technologie bei Data Governance?

Sie setzt durch. Workspace-Rollen bestimmen, wer einen Workspace öffnen darf, egal was ein Richtliniendokument sagt. Sensitivity Labels wenden ihren Schutz automatisch an, sobald Inhalte Power BI über einen unterstützten Exportweg verlassen. Endorsement entscheidet, was bei der Suche nach einem Report zuerst erscheint. Nichts davon hängt davon ab, dass sich jemand an eine schriftliche Regel erinnert.

Quellen

• Roles in workspaces in Microsoft Fabric - Microsoft Learn

• Row-level security (RLS) with Power BI - Microsoft Learn

• Sensitivity labels in Power BI - Microsoft Purview Information Protection - Microsoft Learn

• Endorse Fabric and Power BI items - Microsoft Learn

• Lineage in Fabric - Microsoft Learn