OneLake Security richtig aufbauen

Dirk Müller
15. Juli
7 Min. Lesezeit

Aktualisiert: 15. Juli

Microsoft Fabric verändert nicht nur, wo Unternehmen ihre Daten speichern. Die Plattform verändert auch, wie Daten bereitgestellt, verarbeitet und konsumiert werden.

Eine Vertriebstabelle kann heute gleichzeitig über Power BI ausgewertet, über einen SQL Analytics Endpoint abgefragt, in einem Spark Notebook verarbeitet oder über einen Shortcut in einem anderen Workspace genutzt werden. Genau hier stößt ein klassisches Berechtigungskonzept schnell an Grenzen.

Row-Level Security in einem Power-BI-Modell schützt den Zugriff innerhalb dieses Modells. Sie verhindert aber nicht automatisch, dass dieselben Daten über einen anderen Zugriffspfad sichtbar werden.

Mit OneLake Security bringt Microsoft granulare Datensicherheit näher an die gespeicherten Daten. Tabellen, Ordner, Zeilen und Spalten lassen sich über zentrale Rollen schützen. Das Produkt heißt korrekt OneLake Security. Häufig wird jedoch auch nach „One Lake Security“ gesucht – gemeint ist dieselbe Sicherheitsfunktion in Microsoft Fabric.

OneLake Security ist kein zentraler Sicherheitsschalter. Ein belastbares Berechtigungskonzept entsteht erst, wenn Workspace-Rollen, Item-Rechte, OneLake-Rollen, Identitäten und Zugriffspfade gemeinsam geplant werden

Warum Fabric neue Sicherheit braucht

In klassischen Power-BI-Umgebungen liegt die Sicherheitslogik häufig im semantischen Modell. RLS entscheidet beispielsweise, welche Vertriebsregion ein Nutzer sehen darf. OLS kann Tabellen oder Spalten vollständig ausblenden. Das funktioniert gut, solange Power BI der einzige Zugang zu den Daten ist.

In Fabric greifen jedoch Power BI, Direct Lake, SQL, Spark, APIs, Shortcuts und zunehmend auch KI-Anwendungen auf gemeinsame Datenbestände zu. Eine Regel im semantischen Modell schützt nur diesen Modellzugriff.

Wer die vorhandenen Ebenen zunächst grundsätzlich einordnen möchte, findet in unserer Übersicht zu Power-BI-Berechtigungen die Abgrenzung zwischen Workspace-Rollen, Freigaben, Build-Rechten, RLS und OLS.

OneLake Security ergänzt diese Modell- und Berichtsebene um eine Sicherheitsschicht direkt an den Daten. Dadurch kann eine Regel über mehrere unterstützte Zugriffspfade hinweg wirken – aber nur, wenn Engine, Identität und Berechtigungsmodell dazu passen.

Was OneLake Security leistet

OneLake Security ist das Data-Plane-Sicherheitsmodell für Daten in Microsoft OneLake. Über rollenbasierte Zugriffssteuerung lässt sich festlegen, welche Tabellen oder Ordner eine Rolle verwenden darf, ob Daten gelesen oder geschrieben werden dürfen und welche Zeilen oder Spalten sichtbar bleiben.

Tabellen und Ordner gezielt freigeben
Zeilen über Row-Level Security filtern
Sensible Spalten über Column-Level Security ausblenden
Nutzer und Entra-ID-Gruppen Rollen zuweisen
In unterstützten Lakehouse-Szenarien gezielte Schreibrechte vergeben

Die Sicherheitslogik rückt damit näher an die Daten und wird nicht ausschließlich in der konsumierenden Anwendung gepflegt. Das ist besonders relevant, wenn ein zentraler Datenbestand von mehreren Teams, Workloads oder Datenprodukten verwendet wird.

OneLake Security unterstützt jedoch nicht automatisch jedes Fabric-Element und jede Engine in identischem Umfang. Die Aussage „einmal definieren, überall sicher“ beschreibt ein Zielbild, keine pauschale Garantie.

Diese Einschränkung passt zur grundsätzlichen Einordnung von Microsoft Fabric zwischen Vision und Realität: Die Plattform reduziert technische Brüche, nimmt Unternehmen aber keine Architektur- und Betriebsentscheidungen ab.

Vier Sicherheitsebenen in Fabric

Die größte Verwirrung entsteht, wenn unterschiedliche Berechtigungsarten miteinander vermischt werden. Workspace-Rollen, Item-Rechte, OneLake Security und Power BI RLS erfüllen verschiedene Aufgaben.

Workspace-Rollen regeln, wer entwickeln, verwalten und veröffentlichen darf.
Item-Berechtigungen regeln den grundsätzlichen Zugang zu einem Fabric-Element.
OneLake Security regelt, welche konkreten Daten gelesen oder geschrieben werden dürfen.
Power BI RLS und OLS regeln den Zugriff innerhalb eines semantischen Modells.

Admins, Members und Contributors besitzen im Workspace weitreichende Rechte. OneLake Security ist deshalb nicht dafür gedacht, privilegierte Workspace-Rollen nachträglich auf einzelne Datensätze einzuschränken.

Die granulare Steuerung richtet sich vor allem an Viewer und Nutzer mit direkten Leserechten. Ein häufiger Praxisfehler besteht darin, Fachanwender aus Bequemlichkeit zu Contributors zu machen. Damit erhalten sie meist deutlich mehr Rechte als fachlich notwendig.

Daten granular schützen

Tabellen- und Ordnerrechte eignen sich für klar getrennte Datenbereiche. Ein Marketing-Team kann beispielsweise Kampagnen- und Lead-Daten verwenden, ohne Zugriff auf Finanz- oder Personaldaten zu erhalten.

Row-Level Security ist sinnvoll, wenn mehrere Nutzer dieselbe Tabelle verwenden, aber unterschiedliche Datenausschnitte sehen dürfen. Eine Regionalleitung sieht dann nur Datensätze ihrer Region, während die Geschäftsführung alle Regionen auswerten kann.

Column-Level Security schützt sensible Attribute. Ein externer Partner kann Kunden, Produkte und Umsätze sehen, aber keine Einkaufspreise, Margen oder internen Klassifizierungen.

Gezielte ReadWrite-Rechte sind sicherer als pauschale Contributor-Rechte. Sie erhöhen jedoch die Verantwortung für Datenqualität, Ownership und Monitoring. Schreibrechte brauchen deshalb klare Regeln zur Datenbereitstellung.

An dieser Stelle werden Data Contracts relevant. Sie halten nicht nur technische Strukturen fest, sondern auch Zuständigkeiten, Qualitätsanforderungen und Erwartungen an ein Datenprodukt.

OneLake Security oder Power BI RLS?

Die Frage ist nicht, welche Lösung grundsätzlich besser ist. Entscheidend ist, auf welcher Ebene die Sicherheitsregel gelten muss.

Nur ein Power-BI-Modell betroffen: Power BI RLS oder OLS prüfen.
Schutz über Power BI, SQL und Spark hinweg: OneLake Security prüfen.
Importiertes Power-BI-Modell: Sicherheit im semantischen Modell bleibt zentral.
Direct Lake on OneLake: Zusammenspiel mit der Nutzeridentität bewusst planen.
SQL-spezifische Views und Rollen: SQL-Sicherheitsmodell einbeziehen.

Nicht jede bestehende RLS-Regel muss nach OneLake verschoben werden. Wenn Nutzer ausschließlich Berichte konsumieren und keinen direkten Datenzugriff besitzen, kann Power BI RLS weiterhin die einfachere und passendere Lösung sein.

Power BI RLS und OneLake RLS können kombiniert werden. Doppelte Regeln führen aber schnell zu unerwartet leeren Ergebnissen, schwer nachvollziehbaren Filterketten und unklaren Verantwortlichkeiten.

Doppelte Sicherheit ist nicht automatisch bessere Sicherheit. Jede Regel braucht einen klaren Zweck und eine eindeutige Verantwortung.

Der Identitätsmodus entscheidet

Beim SQL Analytics Endpoint entscheidet der Identitätsmodus darüber, welche Sicherheitslogik tatsächlich ausgewertet wird.

Im User’s Identity Mode wird die Identität des angemeldeten Nutzers an OneLake weitergegeben. OneLake kann dadurch prüfen, zu welchen Gruppen und Rollen der Nutzer gehört und welche Tabellen, Zeilen oder Spalten sichtbar sein dürfen.

Im Delegated Identity Mode greift der SQL Endpoint mit einer delegierten Eigentümer- oder Systemidentität auf OneLake zu. Die Endnutzersteuerung erfolgt dann stärker über SQL-Berechtigungen.

Ein korrekt definiertes OneLake-Rollenmodell kann scheinbar wirkungslos sein, wenn der Zugriffspfad nicht mit der tatsächlichen Nutzeridentität arbeitet. Der Identitätsmodus ist deshalb keine technische Randnotiz, sondern eine Architekturentscheidung.

Praxisbeispiel Vertrieb

Ein Unternehmen speichert zentrale Vertriebsdaten in einem Fabric Lakehouse. Die Tabelle enthält Kunden, Regionen, Produkte, Umsätze, Rabatte, Einkaufspreise und Margen.

Die Geschäftsführung soll alle Regionen sehen. Regionalleitungen sehen nur ihre Region, Vertriebsmitarbeiter nur ihre Kunden. Externe Partner erhalten Umsatzzahlen, aber keine Margen. Data Engineers dürfen Daten in einem definierten Eingangsbereich aktualisieren.

Fachanwender erhalten Viewer- oder direkte Item-Read-Rechte.
Entra-ID-Gruppen werden nach stabilen Fachrollen aufgebaut.
OneLake RLS filtert die Tabelle nach Region oder Verantwortungsbereich.
CLS blendet Margen und Einkaufspreise für externe Nutzer aus.
Das Engineering-Team erhält gezielte ReadWrite-Rechte auf einen Ordner.
Jede Rolle wird mit einem eigenen Testnutzer über Power BI, SQL und Spark geprüft.

Der entscheidende Test lautet nicht nur: Funktioniert der Bericht? Geprüft werden muss, ob dieselbe Person über jeden vorgesehenen Zugriffspfad genau die erlaubten Daten sieht.

Typische Fehler

Zu hohe Workspace-Rechte: Admins, Members und Contributors besitzen weitreichenden Zugriff. Eine eingeschränkte OneLake-Rolle hebt diese privilegierten Rechte nicht einfach auf.

DefaultReader bleibt aktiv: Wird ein Nutzer einer eingeschränkten Rolle zugeordnet, bleibt aber über DefaultReader oder ReadAll breit berechtigt, ändert sich sein effektiver Zugriff möglicherweise nicht.

Mehrere Rollen erweitern Rechte: OneLake-Rollen werden grundsätzlich zusammengeführt. Eine zusätzliche Rolle kann den Zugriff erweitern, obwohl sie isoliert betrachtet restriktiv wirkt.

Falscher Identitätsmodus: Arbeitet eine Engine nicht mit der erwarteten Nutzeridentität, greifen OneLake-Regeln anders als geplant.

Änderungen sind noch nicht wirksam: Rollen- und Gruppenänderungen können durch Caches verzögert sichtbar werden. Nicht jede scheinbare Fehlkonfiguration ist sofort ein Modellierungsfehler.

Best Practices für OneLake Security

Ein gutes Rollenmodell orientiert sich an stabilen fachlichen Verantwortlichkeiten – nicht an einzelnen Berichten, Personen oder spontanen Ausnahmen.

Entra-ID-Gruppen statt einzelner Nutzer verwenden
Workspace-Rollen und Datenrollen klar trennen
Privilegierte Rechte auf wenige Personen begrenzen
Sensible Daten möglichst nah an der Quelle schützen
Rollen mit echten Testidentitäten prüfen
Zugriffe regelmäßig rezertifizieren
Änderungen und Verantwortlichkeiten dokumentieren

Technische Rollen allein reichen nicht. Eine belastbare Power BI Governance verbindet Berechtigungen mit Workspace-Strukturen, Freigabeprozessen, Ownership und Monitoring.

OneLake Security ist damit nicht nur ein technisches Fabric-Thema, sondern Teil eines übergreifenden Governance- und Betriebsmodells.

Was OneLake Security nicht löst

OneLake Security repariert keine ungeordnete Datenlandschaft. Das Feature verhindert nicht automatisch zu viele privilegierte Nutzer, unkontrollierte Freigaben, schlecht gepflegte Gruppen, fehlende Datenverantwortung oder widersprüchliche Regeln.

Ein neues Sicherheitsfeature löst keine organisatorischen Probleme, die bereits vor Microsoft Fabric bestanden haben. Auch Security, Kapazität und Betrieb sollten nicht getrennt geplant werden. Unser Überblick zu den Kosten von Microsoft Fabric zeigt, warum Architekturentscheidungen zugleich technische und wirtschaftliche Folgen besitzen.

OneLake Security pragmatisch einführen

Kritische Daten und sensible Attribute identifizieren.
Zugriffspfade über Power BI, SQL, Spark, APIs und Shortcuts erfassen.
Stabile Nutzergruppen und fachliche Rollen definieren.
Sicherheitsregeln bewusst OneLake, Power BI oder SQL zuordnen.
Einen überschaubaren, aber relevanten Pilotfall auswählen.
Mit echten Testidentitäten über alle vorgesehenen Engines prüfen.
Ownership, Genehmigungen und Rezertifizierung dokumentieren.
Erst nach erfolgreichem Pilot auf weitere Datenprodukte skalieren.

Ein kleines, sauber getestetes Rollenmodell ist wertvoller als ein unternehmensweiter Rollenkatalog, dessen effektive Berechtigungen niemand mehr nachvollziehen kann.

Fazit: Sicherheit braucht Architektur

OneLake Security ist ein wichtiger Baustein für Microsoft Fabric. Granulare Regeln können näher an den Daten definiert und über mehrere unterstützte Zugriffspfade hinweg verwendet werden.

Der eigentliche Nutzen entsteht aber nicht durch das Feature allein. Entscheidend ist, ob Unternehmen verstehen, welche Identität über welche Engine auf welches Element zugreift und welche Workspace-, Item- und Datenrechte bereits bestehen.

Wer OneLake Security nur aktiviert und einige Rollen anlegt, kann sich schnell in falscher Sicherheit wiegen. Wer das Thema dagegen mit Datenarchitektur, Power-BI-Security, Governance und klaren Verantwortlichkeiten verbindet, schafft eine belastbare Grundlage für Fabric.

Wenn ihr OneLake Security in einem konkreten Szenario bewerten und mit einem tragfähigen Pilotfall verbinden möchtet, bietet der Microsoft Fabric Kick Start einen pragmatischen Einstieg in Zielarchitektur, Zugriffspfade und Umsetzung.

Sind bereits mehrere Plattformen, Workspaces und Verantwortungsmodelle betroffen, setzt der Data Strategy Check früher an und ordnet Datenlandschaft, Governance, Risiken und Zielbild gemeinsam ein.

Der nächste sinnvolle Schritt

Wenn ihr OneLake Security nicht nur aktivieren, sondern als tragfähiges Berechtigungsmodell aufsetzen wollt, sollte der nächste Schritt kein Rollenbau auf Verdacht sein. Sinnvoller ist eine kompakte Bestandsaufnahme: Welche Daten sind schützenswert, über welche Wege wird darauf zugegriffen und auf welcher Ebene sollen die Regeln künftig greifen? So wird aus einem technischen Feature ein nachvollziehbares Sicherheitsmodell, das auch im laufenden Betrieb funktioniert.

Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:

Data Strategy Check – um eure Analytics-Organisation ganzheitlich einzuordnen
Consulting Abo – für kontinuierliche Unterstützung bei Migration, Betrieb und Governance
Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX oder Performance
Fabric Kick Start – für einen praxisnahen Einstieg in Architektur, Zielbild und erste Use Cases

So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

FAQ zu OneLake Security

Ist OneLake Security allgemein verfügbar? Die Kernfunktionen für Tabellen-, Ordner-, Zeilen- und Spaltensicherheit sind allgemein verfügbar. Einzelne Integrationen und Zugriffspfade können sich dennoch unterscheiden.

Ersetzt OneLake Security Power BI RLS? Nein. OneLake Security schützt Daten auf der OneLake-Ebene. Power BI RLS schützt Daten innerhalb eines semantischen Modells. Je nach Architektur kann eine der beiden Ebenen oder eine geplante Kombination sinnvoll sein.

Warum greift eine OneLake-Rolle nicht? Häufige Ursachen sind zu hohe Workspace-Rechte, DefaultReader, ein ungeeigneter Identitätsmodus, zusätzliche Rollen oder noch nicht vollständig verarbeitete Gruppenänderungen.

Funktioniert OneLake Security mit Direct Lake? Bei Direct Lake on OneLake können OneLake-Rollen mit der effektiven Nutzeridentität ausgewertet werden. Andere Verbindungs- und Identitätsmodelle können einer abweichenden Berechtigungslogik folgen.

Sollte Sicherheit immer in OneLake liegen? Nein. Wenn Nutzer ausschließlich einen Power-BI-Bericht konsumieren und keinen direkten Zugriff auf die zugrunde liegenden Daten besitzen, kann Power BI RLS die einfachere Lösung sein. Die Ebene sollte nach Zugriffspfad und Risiko gewählt werden – nicht nach dem neuesten Feature.