OneLake-Governance & -Sicherheit: Domänen und Zugriff

Microsoft Fabric führt Data Engineering, Warehousing, Echtzeit-Analytics, Data Science und Business Intelligence auf einem einzigen logischen Data Lake namens OneLake zusammen. Diese Konsolidierung ist die größte Stärke der Plattform und zugleich ihr schärfstes Governance-Risiko. Wenn jedes Team, jeder Workload und zunehmend jeder KI-Agent aus demselben Lake liest und schreibt, bleibt ein nachlässiges Zugriffsmodell nicht lokal — es wird zu einer organisationsweiten Gefährdung.

Dieser Beitrag ist ein Praxisleitfaden zu OneLake-Governance und OneLake-Sicherheit: wie Sie mit Fabric-Domänen, Arbeitsbereichen und einem geschichteten Zugriffsmodell einen schnell wachsenden Datenbestand zugleich nutzbar und verteidigbar halten. Er beruht darauf, wie wir bei CC Conceptualise Fabric-Plattformen entwerfen — nicht auf Marketing-Diagrammen.

TL;DR / Die wichtigsten Erkenntnisse

Governance in Fabric ist geschichtet: Domänen delegieren Verantwortung nach Geschäftsbereich, Arbeitsbereiche sind die Sicherheitsgrenze, und OneLake-Zugriffsrollen erzwingen Ordner- und Tabellensicherheit nach dem Prinzip geringster Rechte im Lakehouse.
Domänen entwerfen Sie top-down aus dem Betriebsmodell, Arbeitsbereiche bottom-up aus den Lieferteams. Der eine gemeinsame Mega-Arbeitsbereich ist das häufigste und schädlichste Antimuster.
OneLake-Verknüpfungen sind bequem, überschreiten aber eine Vertrauensgrenze — behandeln Sie jede als dokumentierte Datenfreigabe-Entscheidung mit benanntem Verantwortlichen.
Fabric-Domänen und Microsoft Purview ergänzen sich: Domänen organisieren Governance innerhalb von Fabric, Purview liefert bestandsübergreifende Klassifizierung, Lineage und Vertraulichkeitsbezeichnungen.
Die Struktur aus Domäne, Arbeitsbereich und Zugriff ist dieselbe Nachweisbasis, die DSGVO-, EU-AI-Act-, DORA- und NIS2-Prüfer erwarten. Entwerfen Sie sie ab dem ersten Tag konformitätsgerecht.

Warum OneLake das Governance-Problem verändert

In einer klassischen Landschaft hatte jedes System eigenen Speicher, ein eigenes Zugriffsmodell und einen eigenen Schadensradius. Eine fehlkonfigurierte Berechtigung in der CRM-Datenbank gefährdete nicht das Finanz-Warehouse. OneLake hebt diese Mauern bewusst auf. Die Daten jedes Arbeitsbereichs sind ein Ordner in einem mandantenweiten Lake, über einen einzigen Namensraum adressierbar und von jeder Engine lesbar — Spark, T-SQL, KQL, Power BI und der neuen Generation von Fabric Data Agents, die Daten autonom abfragen.

Genau diese Vereinheitlichung ist der Grund, warum Unternehmen Fabric einführen. Sie ist auch der Grund, warum Governance bewusst gestaltet sein muss statt zufällig zu entstehen. Die zu beantwortenden Fragen lauten nicht mehr „welche Datenbank enthält das“, sondern „wer verantwortet diesen Datenbestand, wer darf welchen Ausschnitt berühren, und wie weise ich nach, dass die Antwort korrekt ist“. Domänen, Arbeitsbereiche und Zugriffsrollen sind die drei Instrumente dafür.

Die drei Ebenen der OneLake-Governance

Es hilft, Fabric-Governance als Hierarchie zu denken, in der jede Ebene eine Aufgabe hat.

Loading diagram...

Ebene	Geltungsbereich	Hauptzweck	Verantwortung
Domäne	Gruppe von Arbeitsbereichen je Geschäftsbereich	Verantwortung delegieren, mandantenweite Richtlinien, OneLake-Datenhub prägen	Mandanten-Admin + Domänen-Admins
Arbeitsbereich	Sammlung von Elementen (Lakehouses, Warehouses, Modelle, Berichte)	Kollaborations- und Sicherheitsgrenze; Lebenszyklusphase	Arbeitsbereichs-Admins
Element- & OneLake-Zugriffsrolle	Einzelnes Element bzw. Ordner/Tabellen im Lakehouse	Zugriff nach geringsten Rechten; Zeilen-/Spaltensicherheit	Elementverantwortliche, Data Engineers

Der häufigste Fehler ist das Vermischen dieser Ebenen — Arbeitsbereiche wie Domänen zu nutzen oder arbeitsbereichsweite Rollen zu vergeben, wo eine Element- oder Ordnerberechtigung genügt hätte. Jede Ebene existiert gerade, damit Sie auf der darüberliegenden nicht überberechtigen müssen.

Domänen: Ordnung nach geschäftlicher Bedeutung

Eine Fabric-Domäne ist eine logische Gruppierung von Arbeitsbereichen, die einem Teil Ihres Betriebsmodells entspricht — Finanzen, Lieferkette, Kunde, Fertigung. In Domänen delegieren Sie Governance: Ein Domänen-Admin kann Standard-Vertraulichkeitsbezeichnungen setzen, steuern, wer Arbeitsbereiche in der Domäne anlegen darf, und kuratieren, welche Datenprodukte im OneLake-Datenhub des Geschäftsbereichs erscheinen. Subdomänen bilden organisatorische Tiefe ohne Wildwuchs ab.

Entwerfen Sie Domänen top-down. Beginnen Sie bei Ihrer Geschäftsfähigkeitslandkarte oder Ihrer Datenprodukt-Taxonomie, nicht bei den heute zufällig bestehenden Teams. Eine Domäne sollte eine Reorganisation überdauern; ein Arbeitsbereich oft nicht.

Arbeitsbereiche: die eigentliche Sicherheitsgrenze

In einem Arbeitsbereich liegen die Elemente, und hier werden die meisten Zugriffsentscheidungen über vier integrierte Rollen erzwungen:

Rolle	Kann ansehen	Kann erstellen/bearbeiten	Kann Zugriff verwalten	Typische Zuordnung
Admin	Ja	Ja	Ja	Plattform-/Datenproduktverantwortlicher
Mitglied	Ja	Ja	Ja (andere hinzufügen)	Senior Engineers
Mitwirkender	Ja	Ja	Nein	Engineers, bauende Analysten
Betrachter	Ja	Nein	Nein	Fachliche Konsumenten

Da der Arbeitsbereich die Sicherheitsgrenze ist, bestimmt seine Granularität den Schadensradius. Unser Muster in der Lieferung ist ein Arbeitsbereich je Datenprodukt und Lebenszyklusphase — etwa vertrieb-dev und vertrieb-prod — gruppiert unter der für Vertriebsdaten verantwortlichen Domäne. Das hält Bereitstellungspipelines sauber, macht Zugriffsüberprüfungen handhabbar und sorgt dafür, dass ein Fehler im Entwicklungsarbeitsbereich nie Produktionsdaten berührt. Wie diese Lakehouse-Schichtung auf Bronze-/Silber-/Gold-Zonen abbildet, zeigt unser Leitfaden zur Fabric-Medaillon-Architektur.

OneLake-Zugriffsrollen: geringste Rechte im Lake

Arbeitsbereichsrollen sind grob — ein Betrachter sieht alles im Arbeitsbereich. Reale Daten respektieren diese Granularität selten. OneLake-Datenzugriffsrollen erlauben Sicherheit auf Ordner- und Tabellenebene innerhalb eines Lakehouse: Eine Rolle gewährt etwa Lesezugriff auf die kuratierten Tabellen des gold-Schemas und verweigert zugleich den Zugriff auf die rohe bronze-Landezone mit noch unmaskierten personenbezogenen Daten.

Diese Speicherschicht-Sicherheit kombinieren Sie mit den bekannten Steuerungen der Abfrageschicht:

OneLake-Datenzugriffsrollen — Lesezugriff auf Ordner-/Tabellenebene im Lakehouse.
Zeilensicherheit (RLS) — Zeilen je Benutzeridentität im SQL-Endpunkt und semantischen Modell beschränken.
Spaltensicherheit (CLS) — sensible Spalten verbergen oder maskieren.
Objektsicherheit (OLS) — ganze Tabellen oder Spalten im semantischen Modell verbergen.
Vertraulichkeitsbezeichnungen — Klassifizierung, die mit den Daten wandert und den Export steuert.

Die Disziplin lautet geringste Rechte auf jeder Ebene statt einer pauschalen Gewährung an der Spitze. Ein Konsument eines Gold-Datensatzes sollte nie Mitwirkender-Rechte im produzierenden Arbeitsbereich benötigen.

Verknüpfungen und die Vertrauensgrenze

OneLake-Verknüpfungen (Shortcuts) gehören zu den nützlichsten Funktionen von Fabric — und zu den leisesten Risiken. Eine Verknüpfung ist ein Verweis — auf ein anderes Lakehouse, auf ADLS Gen2 oder einen externen Speicher wie S3 — der entfernte Daten lokal erscheinen lässt, ohne sie zu kopieren. Der Zugriff wird sowohl gegen das OneLake-Berechtigungsmodell als auch gegen die Zugriffssteuerung der Quelle geprüft.

Zwei Fehlermodi treten wiederholt auf. Der erste ist Überoffenlegung: Eine Verknüpfung legt Quelldaten einem breiteren Arbeitsbereichspublikum offen, als die Quelle je vorsah. Der zweite ist unklare Autorität: Niemand kann mehr sagen, wo die autoritative Kopie eines Datensatzes liegt, was die Lineage untergräbt und regulatorische Herkunftsnachweise bricht. Behandeln Sie jede Verknüpfung als bewusste, dokumentierte Datenfreigabe-Entscheidung mit benanntem Verantwortlichen und festgehaltener Begründung — nie als schnelle Abkürzung um eine Pipeline herum.

Dieselbe Vorsicht gilt für KI-Zugriffe. Wenn ein Data Agent oder eine Eventhouse-Abfrageschicht arbeitsbereichsübergreifend zugreift — etwa über die Muster in unserem Beitrag zu Fabric Eventhouse und dem Remote-MCP — erbt sie die Identität und die Berechtigungen, unter denen sie läuft. Governance muss nicht-menschliche Konsumenten ebenso berücksichtigen wie Personen.

Domänen vs. Purview: Wer macht was

CISOs fragen häufig, ob Fabric-Domänen Microsoft Purview ersetzen. Das tun sie nicht; sie ergänzen es.

Fähigkeit	Fabric-Domänen	Microsoft Purview
Arbeitsbereiche nach Geschäftsbereich ordnen	Ja	Nein
Governance an Domänenverantwortliche delegieren	Ja	Teilweise
Bestandsübergreifender Datenkatalog	Nur Fabric	Ja (Fabric + darüber hinaus)
Vertraulichkeitsbezeichnungen & Klassifizierung	Konsumiert Bezeichnungen	Definiert & vergibt Bezeichnungen
Lineage über Systeme hinweg	Innerhalb von Fabric	Durchgängig
Data Loss Prevention / Richtlinien	Begrenzt	Ja

In der Praxis definieren Sie Klassifizierung, Vertraulichkeitsbezeichnungen und DLP-Richtlinien in Purview, und diese Bezeichnungen fließen in Fabric-Elemente und jeden nachgelagerten Export ein. Domänen nutzen Sie dann, um die tägliche Governance-Erfahrung innerhalb von Fabric zu organisieren und zu delegieren. Klassifizieren Sie einmal und erzwingen Sie überall.

Eine praxistaugliche Einführungsreihenfolge

Wenn wir OneLake-Governance für ein Unternehmen aufsetzen, ist die Reihenfolge ebenso wichtig wie der Entwurf:

Domänen auf das Betriebsmodell abbilden, bevor ein einziger Arbeitsbereich entsteht. Verantwortliche festlegen.
Arbeitsbereichsmuster definieren — einer je Datenprodukt und Lebenszyklusphase — und vorlagenbasiert ausrollen.
Purview integrieren, damit Vertraulichkeitsbezeichnungen und DLP existieren, bevor sensible Daten landen.
Zugriff kodifizieren — Arbeitsbereichsrollen und OneLake-Datenzugriffsrollen über Bereitstellungspipelines oder APIs statt Portalklicks.
Verknüpfungen steuern über ein Freigabe- und Verantwortungsregister.
Zugriffsüberprüfungen je Domänenverantwortlichem in festem Rhythmus einplanen, um Drift zu erkennen.

Diese Reihenfolge macht Governance zu einer Eigenschaft der Plattform statt zu einem Sanierungsprojekt nach dem ersten Prüfbefund.

Governance ist Ihre Nachweisbasis für Compliance

Für europäische Unternehmen ist das nicht abstrakt. Die DSGVO verlangt Wissen darüber, wo personenbezogene Daten liegen und wer zugreifen darf. Der EU AI Act erwartet Herkunft und Zugriffssteuerung über Trainings- und Grounding-Daten. DORA und NIS2 fordern nachweisbare Kontrolle über kritische Datenbestände und ihre Lieferkette — einschließlich Nachweispflichten gegenüber Geschäftsleitung und Aufsicht. Jede dieser Anforderungen wird durch dieselben Artefakte erfüllt: eine klare Domänen-Verantwortungslandkarte, sauber geschnittene Arbeitsbereiche, Zugriffsrollen nach geringsten Rechten und Purview-gestützte Klassifizierung und Lineage. Bauen Sie die Struktur einmal, und sie dient Ihren Engineers ebenso wie Ihren Prüfern.

FAQ

Worin unterscheiden sich Fabric-Domäne und Arbeitsbereich aus Governance-Sicht?

Eine Domäne ist eine organisatorische Gruppierung von Arbeitsbereichen, die einem Geschäftsbereich entspricht — Finanzen, Lieferkette, Kunde — und die Einheit, in der Sie Verantwortlichkeit delegieren und mandantenweite Governance-Richtlinien anwenden. Ein Arbeitsbereich ist die eigentliche Sicherheits- und Kollaborationsgrenze, in der Elemente liegen und Rollen vergeben werden. Domänen beantworten, wer einen Datenbestand verantwortet; Arbeitsbereiche, wer welche Elemente berühren darf. Domänen entwerfen Sie top-down aus dem Betriebsmodell, Arbeitsbereiche bottom-up aus den Lieferteams.

Wie funktioniert die OneLake-Zugriffssteuerung konkret?

Der Zugriff ist geschichtet. Arbeitsbereichsrollen (Admin, Mitglied, Mitwirkender, Betrachter) gewähren groben Zugriff auf alles in einem Arbeitsbereich. Elementberechtigungen schränken dies auf ein einzelnes Lakehouse, Warehouse oder semantisches Modell ein. OneLake-Datenzugriffsrollen erzwingen anschließend Ordner- und Tabellensicherheit innerhalb eines Lakehouse, kombiniert mit Zeilen- und Spaltensicherheit in der SQL- und semantischen Schicht. Das Prinzip ist geringste Rechte auf jeder Ebene, nicht eine pauschale Gewährung an der Spitze.

Sollte jedes Team einen eigenen Arbeitsbereich in Fabric erhalten?

In der Regel ja, aber strukturiert. Da der Arbeitsbereich die Sicherheitsgrenze ist, zwingt das Zusammenlegen vieler Teams in einen gemeinsamen Arbeitsbereich zur Übervergabe von Rechten. Unser Muster ist ein Arbeitsbereich pro Team und Lebenszyklusphase — etwa ein Entwicklungs- und ein Produktionsarbeitsbereich je Datenprodukt — gruppiert unter der verantwortlichen Domäne. Das hält den Schadensradius klein und macht Bereitstellungspipelines und Zugriffsüberprüfungen handhabbar.

Wie verhalten sich Fabric-Domänen zu Microsoft Purview?

Sie ergänzen sich, statt sich zu doppeln. Fabric-Domänen organisieren und delegieren Governance innerhalb von Fabric und prägen den OneLake-Datenhub. Microsoft Purview liefert den bestandsübergreifenden Katalog, Datenklassifizierung, Vertraulichkeitsbezeichnungen, Lineage und Richtlinien über Fabric und die übrige Datenlandschaft hinweg. In Purview vergebene Vertraulichkeitsbezeichnungen fließen in Fabric-Elemente und nachgelagerte Exporte ein — Sie klassifizieren einmal und erzwingen überall.

Können OneLake-Verknüpfungen eine Sicherheitslücke schaffen?

Ja, wenn die Vertrauensgrenze ignoriert wird. Eine Verknüpfung (Shortcut) ist ein Verweis auf Daten, die anderswo liegen — ein anderes Lakehouse, ADLS Gen2 oder S3 — und der Zugriff wird sowohl gegen die Quelle als auch gegen das OneLake-Berechtigungsmodell geprüft. Das Risiko ist, Quelldaten breiter als beabsichtigt offenzulegen oder den Überblick über den autoritativen Datenbestand zu verlieren. Behandeln Sie jede Verknüpfung als dokumentierte Datenfreigabe-Entscheidung mit benanntem Verantwortlichen, nicht als Bequemlichkeit.

Was hat OneLake-Governance mit EU-Regulierung zu tun?

Data Governance ist die Grundlage, auf die DSGVO, EU AI Act, DORA und NIS2 gleichermaßen aufbauen. Rechtmäßige Verarbeitung, Datenminimierung oder die Herkunft von KI-Trainingsdaten lassen sich ohne Wissen darüber, wo Daten liegen, wer zugreift und wie klassifiziert wird, nicht nachweisen. Die Struktur aus Domänen, Arbeitsbereichen und Zugriffsrollen in OneLake ist genau die Nachweisbasis, die Prüfer und Aufsichtsbehörden erwarten — daher lohnt es sich, sie von Beginn an konformitätsgerecht zu entwerfen.

Wie behalten wir OneLake-Zugriffe bei wachsender Plattform unter Kontrolle?

Behandeln Sie Zugriff als Code und überprüfen Sie ihn regelmäßig. Definieren Sie Arbeitsbereichsrollen und OneLake-Datenzugriffsrollen über Bereitstellungspipelines oder APIs statt über manuelle Portalklicks, vergeben Sie konsequent geringste Rechte und führen Sie je Domänenverantwortlichem periodische Zugriffsüberprüfungen durch. Kombiniert mit Vertraulichkeitsbezeichnungen und Purview-Lineage wird Drift — verwaiste Berechtigungen, zu breite Verknüpfungen, unklassifizierte sensible Daten — sichtbar, bevor daraus ein Vorfall wird.

Sie entwerfen oder härten eine Microsoft-Fabric-Plattform und wollen das Governance- und Sicherheitsmodell ab dem ersten Arbeitsbereich richtig aufsetzen? Entdecken Sie unsere Leistungen für KI & Data-Platform-Engineering oder nehmen Sie Kontakt auf — wir haben das geliefert.