OneLake Security richtig aufbauen

OneLake Security schützt Tabellen, Zeilen und Spalten in Microsoft Fabric. Ob eine Person tatsächlich nur die vorgesehenen Daten sieht, hängt auch von ihren übrigen Rechten, der verwendeten Engine und der übergebenen Identität ab. Besonders sorgfältig musst du planen, wenn mehrere Rollen zusammenwirken.

Eine Vertriebstabelle kann gleichzeitig in Power BI ausgewertet, über einen SQL Analytics Endpoint abgefragt, in einem Spark Notebook verarbeitet oder über einen Shortcut in einem anderen Workspace genutzt werden. Eine Sicherheitsregel im Power-BI-Modell deckt diese Zugriffswege nicht automatisch ab.

OneLake Security bringt granulare Berechtigungen näher an die gespeicherten Daten. Damit daraus ein belastbares Sicherheitsmodell wird, brauchst du eine klare Zuordnung: Wer darf über welchen Weg welche Daten lesen oder verändern? Rollenlisten allein beantworten diese Frage noch nicht.

Warum Fabric neue Sicherheit braucht

In klassischen Power-BI-Umgebungen liegt die Sicherheitslogik häufig im semantischen Modell. Row-Level Security, kurz RLS, begrenzt beispielsweise die sichtbaren Vertriebsregionen. Object-Level Security, kurz OLS, kann Tabellen oder Spalten aus dem Modellzugriff ausschließen.

Sobald ein Team dieselben Daten zusätzlich über SQL oder Spark nutzt, entsteht ein weiterer Zugang. Deshalb gehört zu einem Berechtigungskonzept neben der Modellregel auch eine Bestandsaufnahme der tatsächlich verwendeten Engines, Verbindungen und Identitäten.

Die Unterscheidung zwischen Workspace-Rollen, Freigaben, Build-Rechten und Modellregeln bildet die Grundlage für nachvollziehbare Power-BI-Berechtigungen. OneLake Security ergänzt diese Ebenen um Berechtigungen an den Daten. Unterstützte Engines können dadurch dieselben zentral definierten Regeln auswerten; Voraussetzungen und Ausnahmen bleiben je Zugriffspfad zu prüfen.

Vier Sicherheitsebenen in Fabric

Workspace-Rollen bestimmen unter anderem, wer Elemente entwickeln und verwalten darf. Item-Berechtigungen regeln den Zugang zu einem einzelnen Fabric-Element. OneLake-Rollen steuern den Zugriff auf dessen Daten. RLS und OLS im semantischen Modell schützen wiederum die Nutzung innerhalb dieses Modells.

Diese Ebenen sind keine austauschbaren Varianten derselben Einstellung. Wer ein Item sehen und öffnen darf, hat damit noch nicht automatisch Zugriff auf dessen Tabellen. Umgekehrt bringt eine passende Datenrolle wenig, wenn der notwendige Zugang zum verwendeten Item fehlt.

Admins, Members und Contributors besitzen über ihre Schreibrechte weitreichenden Datenzugriff. Eine eingeschränkte OneLake-Rolle begrenzt diese privilegierten Rechte nicht nachträglich. Für Fachanwender mit begrenztem Datenbedarf sind deshalb Viewer- oder direkte Item-Read-Rechte der geeignete Ausgangspunkt, ergänzt um passende Datenrollen.

Eine klare Workspace-Strategie trennt Entwicklung, Verantwortung und Konsum bereits organisatorisch. Das reduziert den Druck, fehlende Strukturen durch immer neue Berechtigungsausnahmen auszugleichen.

Tabellen, Zeilen und Spalten gezielt schützen

Tabellen- und Ordnerrechte trennen Datenbereiche: Ein Marketing-Team erhält beispielsweise Kampagnendaten, ohne damit auch Finanz- oder Personaldaten freizugeben. RLS begrenzt innerhalb einer Tabelle die sichtbaren Datensätze. CLS, also Column-Level Security, beschränkt die freigegebenen Spalten.

Soll eine Person nur ihre Region und zugleich keine Einkaufspreise sehen, gehören beide Anforderungen in dieselbe OneLake-Rolle. Das erleichtert auch die fachliche Abnahme: Die Rolle beschreibt einen vollständigen Datenzugriff, den der Verantwortliche nachvollziehen kann.

Für gezielte Schreibzugriffe im Lakehouse gibt es ReadWrite-Rechte auf ausgewählte Tabellen oder Ordner. ReadWrite-Rollen dürfen keine RLS- oder CLS-Einschränkungen enthalten. Plane Datenanlieferung und eingeschränkte Analyse deshalb als getrennte Aufgaben. Ein Ordner mit Schreibrecht braucht eine klare Zuständigkeit für Qualität, Änderungen und Wiederherstellung.

Wie mehrere OneLake-Rollen zusammenwirken

Die Wirkung mehrerer Rollen hängt von ihrer Kombination und der Engine ab. Die folgende Tabelle gilt für Zugriffe, die über OneLake-Rollen autorisiert werden.

Rollenkonstellation	Wirkung auf den Datenzugriff
RLS und CLS innerhalb einer Rolle	Tabellen-, Zeilen- und Spaltenfreigaben begrenzen den Zugriff gemeinsam.
Mehrere Rollen mit RLS und gleichen Spaltenfreigaben	Erlaubte Zeilen werden über ODER verknüpft, etwa Nord oder Süd.
Mehrere Rollen nur mit CLS	Grundsätzlich werden Spaltenfreigaben vereinigt. Der SQL Analytics Endpoint verwendet dagegen ihre Schnittmenge.
Unterschiedliche Spaltenfreigaben auf derselben Tabelle und RLS in mindestens einer Rolle	Diese Kombination wird nicht unterstützt und kann zu Abfragefehlern führen.

Ein problematisches Beispiel: Rolle A erlaubt Region Nord und die Spalten Kunde, Region und Umsatz. Rolle B erlaubt auf derselben Tabelle Kunde, Region, Umsatz und Marge ohne Regionsfilter. Beide Rollen zusammen sind keine verlässliche Methode, eine Sonderberechtigung zu ergänzen.

Prüfe deshalb alle tatsächlichen Mitgliedschaften. Auch Gruppen, die für einen anderen Zweck vergeben wurden, können dieselbe Tabelle betreffen. Ein erfolgreicher Test jeder Rolle für sich belegt noch nicht, dass ihre Kombination funktioniert.

OneLake Security oder Power BI RLS?

Wähle die Ebene danach, wo die Regel gelten muss. Wenn Nutzer ausschließlich ein importiertes Power-BI-Modell konsumieren, bleibt dessen Sicherheitsmodell zentral. Eine nachträglich geänderte OneLake-Regel filtert nicht automatisch die bereits importierten Daten bei jeder Berichtsabfrage.

Wenn derselbe Datenbestand über mehrere unterstützte Engines genutzt wird, ist OneLake Security ein sinnvoller Prüfpunkt. Für semantische Modelle mit direkter OneLake-Sicherheitsauswertung ist Direct Lake on OneLake relevant. Andere Verbindungs- und Identitätsmodelle benötigen eine eigene Betrachtung.

Eine Kombination aus Modell- und OneLake-Regeln kann fachlich sinnvoll sein. Dokumentiere dann, welchen Zweck jede Ebene erfüllt und wer Änderungen verantwortet. Sonst werden leere Ergebnisse und widersprüchliche Freigaben schnell zum gemeinsamen Problem von Fachbereich, BI-Team und Plattformbetrieb.

Der Identitätsmodus entscheidet

Beim SQL Analytics Endpoint legt der Zugriffsmodus fest, wo die Datenberechtigungen ausgewertet werden:

• Im User Identity Mode wird die Identität des angemeldeten Nutzers an OneLake weitergegeben. OneLake-Rollen bestimmen den Tabellenzugriff. SQL-Rechte bleiben für Objekte wie Views, Funktionen oder Stored Procedures relevant.

• Im Delegated Identity Mode verwendet der Endpunkt die Identität des Workspace- oder Item-Eigentümers. Die Berechtigungen der Endnutzer werden in diesem Modus ausschließlich über SQL gesteuert.

Ein Wechsel des Modus gehört in ein geplantes Änderungsfenster. Er kann SQL Analytics Endpoints im gesamten Workspace vorübergehend unterbrechen und laufende sowie wartende Abfragen abbrechen. Ein vermeintlicher Berechtigungsfix sollte keine ungeplante Betriebsunterbrechung auslösen.

Auch bei Shortcuts musst du zwei Einstellungen unterscheiden: die Identität der abfragenden Engine und die Authentifizierung des Shortcuts. Ein Passthrough-Shortcut garantiert für sich allein noch keine durchgängige Endnutzeridentität. Bei delegierten OneLake Shortcuts kommt zusätzlich die konfigurierte Verbindungsidentität hinzu.

Im User Identity Mode prüft OneLake die Datenrechte des Nutzers. Im Delegated Identity Mode steuert SQL den Endnutzerzugriff; OneLake wird mit der Eigentümeridentität angesprochen.

Praxisbeispiel: Vertrieb mit regionalen Partnern

Ein Unternehmen speichert Kunden, Regionen, Produkte, Umsätze, Einkaufspreise und Margen in einem Lakehouse. Die Geschäftsführung benötigt alle Regionen. Regionalleitungen benötigen ihre Region. Ein Vertriebspartner für Region Nord soll ausschließlich Nord-Daten und keine Einkaufspreise oder Margen sehen.

Für diesen Partner wird eine gemeinsame Rolle definiert: passende Tabellenfreigabe, RLS für Nord und CLS für Kunde, Region, Produkt und Umsatz. Eine separate allgemeine Rolle „Partner ohne Margen“ zusätzlich zur Rolle „Region Nord“ wäre kein sauberer Ersatz für diese kombinierte Regel.

Vor der Abnahme wird geprüft, ob das Partnerkonto über weitere Gruppen zusätzliche Rollen oder breite Leserechte besitzt. Beim SQL-Zugang werden außerdem Item-Zugang und User Identity Mode kontrolliert. Für externe Gastkonten sind zusätzlich die unterstützte B2B-Konfiguration und die auflösbaren Gruppen zu prüfen. Ein Berichtstest mit einem Administrator sagt über diesen Partnerzugriff wenig aus.

Die Datenanlieferung erhält bei Bedarf gezielte ReadWrite-Rechte auf einen separaten Eingangsordner. Diese Aufgabe gehört nicht in die eingeschränkte Partnerrolle. So lassen sich Analysefreigabe und Datenänderung unabhängig verantworten und prüfen.

Die erlaubte Datensicht ergibt sich im Beispiel aus Region Nord und der Spaltenfreigabe innerhalb derselben Rolle. Weitere Berechtigungen werden zusätzlich geprüft.

Zugriffstests müssen auch verbotene Daten prüfen

Ein belastbarer Test beginnt mit einem erwarteten Ergebnis. Lege für jede Testidentität fest, welche Zeilen und Spalten sichtbar sein sollen und welche Zugriffe scheitern müssen. Verwende dabei die tatsächlichen Gruppenmitgliedschaften und den vorgesehenen Verbindungsmodus.

Für das Partnerkonto aus dem Beispiel ergeben sich sechs konkrete Prüfungen:

1. Erlaubte Daten lesen: Kunden und Umsätze aus Region Nord sind über die vorgesehenen Zugänge verfügbar.

2. Fremde Region ausschließen: Eine gezielte Abfrage nach Süd liefert keine Süd-Datensätze.

3. Sensible Spalten prüfen: Einkaufspreise und Margen sind nicht lesbar, auch bei einer direkten Spaltenabfrage.

4. Rollenkombination testen: Zusätzliche Gruppenmitgliedschaften werden in einer kontrollierten Testumgebung einbezogen; unerwartete Freigaben und Abfragefehler werden dokumentiert.

5. Weitere Zugriffswege prüfen: SQL, Spark, Power BI und verwendete Shortcuts werden jeweils mit ihrer wirksamen Identität getestet. Nicht vorgesehene direkte Datenzugriffe dürfen die Beschränkungen nicht umgehen.

6. Entzug nachtesten: Nach dem Entfernen einer Berechtigung wird erneut geprüft, ob der zuvor erlaubte Zugriff tatsächlich endet. Berücksichtige Synchronisierung und Caches; dokumentiere den Änderungszeitpunkt und den nachgewiesenen Entzug.

Erwarte nicht bei jeder Engine dieselbe Ergebnisform. Bei CLS kann Spark auf SELECT * nur die erlaubten Spalten zurückgeben, während der SQL Analytics Endpoint einen Fehler meldet. Für positive SQL-Tests sind explizit benannte, erlaubte Spalten deshalb aussagekräftiger.

Eine Sperre kann korrektes Sicherheitsverhalten sein. Für die fachliche Abnahme zählt zusätzlich, dass der geplante erlaubte Arbeitsablauf funktioniert. Ein ausschließlich fehlschlagender Zugriff ist noch kein erfolgreich eingeführter Analyseprozess.

OneLake Security pragmatisch einführen

Beginne mit einem überschaubaren Datenprodukt und einer konkreten Entscheidung, etwa der Freigabe regionaler Vertriebsdaten. Erfasse zuerst die sensiblen Attribute, benötigten Zugriffswege und fachlichen Verantwortlichen. Daraus entstehen Rollen und Abnahmekriterien.

Prüfe bestehende Rechte vor dem Anlegen neuer Rollen. Im Lakehouse kann eine unveränderte DefaultReader-Rolle Nutzern mit ReadAll weiterhin breiten Zugriff geben. Die eingeschränkte Rolle nimmt diese breitere Freigabe nicht zurück. Bestehende Freigaben müssen deshalb Bestandteil des Reviews sein.

Nach erfolgreichem Pilot gehören Genehmigung, regelmäßige Überprüfung und Entzug von Zugriffsrechten in den Betrieb. Halte außerdem fest, wer bei Schemaänderungen die betroffenen Regeln und Tests anpasst. Eine umbenannte Spalte kann eine Sicherheitsregel ungültig machen und Abfragen blockieren.

Verlässliche Data Contracts verbinden Datenstrukturen mit Zuständigkeiten und Qualitätsanforderungen. Für Security ist das praktisch: Eine Tabellenänderung wird damit auch als Änderung an einem gemeinsam genutzten Datenprodukt behandelt.

FAQ zu OneLake Security

Sind RLS und CLS über alle Zugriffswege gleich verfügbar? Nein. Unterstützte Fabric-Engines können die Regeln auswerten; Umfang und Voraussetzungen unterscheiden sich. Bei eingeschränktem Zugriff kann eine nicht autorisierte externe Engine vollständig blockiert werden.

Kann eine eingeschränkte Rolle Contributor-Rechte begrenzen? Nein. Privilegierte Workspace-Rechte müssen im Berechtigungskonzept separat bewertet und auf die notwendigen Personen begrenzt werden.

Warum scheitert eine Abfrage nach einer Rollenänderung? Prüfe die vollständige Rollenkombination, referenzierte Spalten, Identitätsmodus und Synchronisierung. Erweitere nicht vorschnell die Rechte, nur um den Fehler zu beseitigen.

Ist jede leere Ergebnismenge ein erfolgreicher RLS-Test? Nein. Prüfe zusätzlich bekannte erlaubte Datensätze. Nur so unterscheidest du eine korrekte Einschränkung von einem unbrauchbaren Zugriff.

---

Fazit: Sicherheit braucht überprüfbare Regeln

OneLake Security kann Berechtigungen in Microsoft Fabric näher an den Daten bündeln. Belastbar wird das Konzept, wenn Rollen, Identitäten und Zugriffspfade zusammen geprüft werden.

Plane zusammengehörige Zeilen- und Spaltenregeln gemeinsam, berücksichtige weitere Mitgliedschaften und teste erlaubte sowie gesperrte Zugriffe. Damit entsteht ein Sicherheitsmodell, dessen Wirkung Fachbereich und Plattformteam nachvollziehen können.

---

Nächste Schritte

Wenn du OneLake Security in eurer Fabric-Landschaft einführen oder ein bestehendes Rollenmodell prüfen möchtest, starte mit einem konkreten Datenprodukt und seinen Zugriffswegen. Im Microsoft Fabric Kick Start verbinden wir diese Bestandsaufnahme mit Zielarchitektur und einem passenden Pilotfall. So wird klar, welche Regeln ihr braucht und wie ihr ihre Wirkung vor dem breiten Einsatz überprüft.