Delegated OneLake Shortcuts: Security mit RLS und CLS richtig planen

Ein zentrales Datenteam stellt in Microsoft Fabric ein kuratiertes Finance-Datenprodukt bereit. Controlling, Vertrieb und mehrere Landesgesellschaften sollen darauf zugreifen, die Daten aber nicht kopieren. Mit klassischen OneLake Shortcuts funktioniert das technisch schnell – bis der zentrale Data Owner Berechtigungen für Hunderte oder Tausende einzelne Nutzer an der Quelle verwalten muss.

Delegated OneLake Shortcuts sollen genau dieses Problem lösen. Statt die Identität jedes Nutzers an das Ziel weiterzureichen, greift eine konfigurierte Verbindungsidentität auf die Quelldaten zu. Das Consumer-Team kann anschließend den Zugriff seiner eigenen Nutzer verwalten.

Die entscheidende Frage lautet nicht, ob Delegated Shortcuts funktionieren, sondern wo nach der Delegation die wirksame Sicherheitsgrenze liegt.

Microsoft hat eine entscheidende Grenze inzwischen eindeutig dokumentiert: RLS kann bei Delegated OneLake Shortcuts auf der Producer-Seite wirken, auf der Consumer-/Shortcut-Seite aber nicht zusätzlich konfiguriert werden. CLS kann dagegen auf beiden Seiten eingesetzt werden. OneLake Security, Connection Identity, Workspace-Rollen und die verwendete Abfrage-Engine bleiben trotzdem unterschiedliche Ebenen. Wer delegierte Shortcuts produktiv einsetzen möchte, braucht deshalb eine Architekturentscheidung – nicht nur eine neue Verbindung.

Delegated Shortcuts sind eine Governance-Entscheidung

OneLake Shortcuts verweisen auf Daten in einem anderen Fabric-Element oder einem externen Speichersystem. Die Daten bleiben am Ursprungsort und müssen nicht für jeden Consumer erneut geladen oder gespeichert werden. Das reduziert Datenkopien, Latenzen und zusätzliche Ladeprozesse.

Mit OneLake Security lassen sich Berechtigungen auf Ordner-, Tabellen-, Zeilen- und Spaltenebene definieren. OneLake Security und die zugehörigen Datenzugriffsrollen sind seit Mai 2026 allgemein verfügbar. Delegated OneLake Shortcuts befinden sich weiterhin in Preview.

Delegation verschiebt nicht nur den technischen Zugriff, sondern auch einen Teil der organisatorischen Verantwortung. Der Datenproduzent entscheidet weiterhin, auf welche Quelldaten die delegierte Identität grundsätzlich zugreifen darf. Das Consumer-Team entscheidet, welche eigenen Nutzer innerhalb dieses Rahmens Zugriff erhalten. Ohne klar benannte Verantwortliche entsteht leicht eine Lücke zwischen beiden Ebenen.

Das Thema gehört deshalb in eine belastbare Power-BI- und Fabric-Governance – nicht als zusätzliches Regelwerk, sondern als Teil der Rollen-, Workspace- und Datenproduktarchitektur.

Passthrough oder Delegated Authentication?

OneLake-to-OneLake-Shortcuts unterstützen zwei Authentifizierungsmodelle. Die Wahl bestimmt, welche Identität gegenüber dem Ziel ausgewertet wird.

Passthrough: Die Quelle autorisiert den Nutzer

Bei Passthrough verwendet Fabric die Identität des angemeldeten Nutzers für den Zugriff auf das Shortcut-Ziel. Jeder Nutzer benötigt passende Rechte an der Quelle. Der Datenproduzent behält damit die unmittelbare Kontrolle darüber, welche Person welche Daten sehen darf. Passthrough eignet sich besonders für sensible Daten, zentrale Autorisierung sowie Datenprodukte, bei denen RLS oder CLS entscheidend sind.

Passthrough ist das robustere Standardmodell, wenn die Quelle die verbindliche Autorisierungsinstanz bleiben soll. Der Nachteil liegt im administrativen Aufwand. Bei vielen Fachbereichen, Domänen oder Gesellschaften muss das Produzenten-Team eine große Zahl einzelner Berechtigungen oder Gruppen am Ziel verwalten.

Delegated Authentication: Eine Verbindung repräsentiert den Consumer

Bei Delegated Authentication verwendet der Shortcut eine konfigurierte Identität. Microsoft nennt dafür Organisationskonten, Service Principals und Workspace Identities. Die Endnutzer benötigen dadurch nicht zwingend eigene Berechtigungen an der Quelle. Der Nutzer sieht die Schnittmenge aus seinen Berechtigungen am Shortcut-Pfad und den Berechtigungen der delegierten Identität am Ziel.

Delegated Authentication skaliert die Benutzerverwaltung, verlagert aber einen Teil der Zugriffssteuerung zum Consumer. Das Modell passt besonders zu großen Fachdomänen, Tochtergesellschaften, Cross-Tenant-Szenarien sowie zur Trennung von Test- und Produktions-Tenants. Das Hauptrisiko ist eine Verbindungsidentität mit zu weitreichenden Rechten.

Ein Praxisbeispiel aus dem Finance-Bereich

Ein zentrales Fabric-Team stellt eine Tabelle mit Umsatz, Deckungsbeitrag, Kostenstellen und Mitarbeitendeninformationen bereit. Die deutsche Vertriebsgesellschaft soll Umsatz- und Deckungsbeitragsdaten nutzen, aber keine personenbezogenen Kosteninformationen sehen.

Mit Passthrough erhält jeder Nutzer der Vertriebsgesellschaft passende Berechtigungen am zentralen Datenprodukt. Die Quelle entscheidet für jede Person, welche Tabellen, Zeilen und Spalten sichtbar sind. Mit einem delegierten Shortcut könnte stattdessen eine Identität für die deutsche Vertriebsgesellschaft eingerichtet werden. Der zentrale Data Owner begrenzt diese Identität auf die freigegebenen Tabellen und Spalten. Die Vertriebsgesellschaft verwaltet anschließend selbst, welche ihrer Nutzer über den Shortcut zugreifen dürfen.

Die delegierte Identität muss bereits am Ursprung auf den maximal zulässigen Datenumfang begrenzt sein. Für Zeilen ist das besonders wichtig: Producer-seitige RLS kann den Datenraum der Connection Identity begrenzen; eine zusätzliche Consumer-seitige OneLake-RLS ist bei Delegated Shortcuts nicht konfigurierbar. CLS kann der Consumer dagegen weiter einschränken.

RLS und CLS: Die Sicherheitsgrenze ist jetzt klar

Microsoft dokumentiert die Security-Grenze für Delegated OneLake Shortcuts inzwischen eindeutig. Tabellen- und Pfadzugriff können auf Producer- und Consumer-Seite eingeschränkt werden. CLS wird ebenfalls auf beiden Seiten unterstützt. Der effektive Zugriff bleibt die Schnittmenge aus den Berechtigungen der Connection Identity am Target und den Berechtigungen des Nutzers am Shortcut.

CLS kann damit auf beiden Ebenen weiter einschränken: Der Producer definiert den maximal freigegebenen Spaltenumfang, der Consumer kann diesen nochmals reduzieren. Eine Erweiterung über den Zugriff der Connection Identity hinaus ist nicht möglich.

RLS bleibt eine Producer-Aufgabe

Bei RLS gilt eine andere Grenze: RLS wird auf der Producer-/Target-Seite unterstützt, auf der Consumer-/Shortcut-Seite kann sie für Delegated Shortcuts nicht konfiguriert werden. Consumer-seitige OneLake-RLS ist damit kein zusätzlicher Sicherheitslayer für den Shortcut.

Wenn ein Consumer ausschließlich Datensätze eines Landes oder Geschäftsbereichs sehen darf, muss diese Zeilengrenze beim Producer entstehen – beispielsweise über RLS für die Connection Identity. Benötigt der Consumer anschließend eine individuelle RLS je Endnutzer oder Region, sind Passthrough, getrennte Datenprodukte beziehungsweise Connection Identities oder eine geeignete engine-spezifische Sicherheitsschicht zu prüfen. CLS kann dagegen auf der Consumer-Seite weiter einschränken.

Die Unterscheidung zwischen Berechtigungen und tatsächlicher Datensicherheit ist auch bei der Power BI Governance im Self-Service relevant. Workspace- und Build-Rechte ersetzen keine RLS-, CLS- oder OneLake-Sicherheitsregeln.

Shortcut-Authentifizierung und SQL-Modus nicht verwechseln

Delegated Authentication am Shortcut ist nicht dasselbe wie der Delegated-Identity-Modus eines SQL Analytics Endpoint. Beide verwenden zwar eine zwischengeschaltete Identität, greifen aber an unterschiedlichen Stellen der Architektur.

Im User-Identity-Modus des SQL Analytics Endpoint wird die Identität des Nutzers gegenüber OneLake ausgewertet. Im Delegated-Identity-Modus greift der Endpoint dagegen über die Identität des Item Owners auf OneLake zu. Die fachliche Autorisierung des Endnutzers erfolgt dort über SQL-Berechtigungen, SQL-RLS, SQL-CLS oder Dynamic Data Masking; die OneLake-Sicherheitsrollen des Endnutzers werden auf dieser Ebene nicht direkt durchgesetzt. Bei Shortcut-Tabellen mit Producer-seitiger OneLake-RLS oder -CLS kann der Delegated-Identity-Modus den Zugriff sogar blockieren. Soll die OneLake-Security des Producers verbindlich bleiben, ist der User-Identity-Modus die konsistentere Architektur.

Direct Lake over OneLake ist auf eine direkte Durchsetzung von OneLake Security ausgelegt. Direct Lake over SQL kann dagegen vom Identitätsmodus des SQL Analytics Endpoint abhängen. T-SQL-Abfragen können wiederum ein anderes Sicherheitsmodell verwenden als Spark-Abfragen. Architekturtests dürfen deshalb nicht nur mit einem Administrator oder dem Item Owner durchgeführt werden.

Drei belastbare Architekturmodelle

1. Zentrales Datenprodukt mit Passthrough

Das zentrale Team besitzt und schützt das Datenprodukt. Consumer-Workspaces greifen über Passthrough-Shortcuts darauf zu, die Endnutzer werden an der Quelle autorisiert. Dieses Modell ist die erste Wahl für sensible Daten, zentrale RLS und verbindliche Datenprodukte. Der Nachteil ist die aufwendigere Benutzerverwaltung.

2. Delegiertes Datenprodukt für eine Domäne

Das zentrale Team autorisiert eine bewusst begrenzte Connection Identity. Producer-seitige RLS kann dabei den maximal zulässigen Zeilenumfang für eine Fachdomäne oder Tochtergesellschaft festlegen. Das Consumer-Team verwaltet anschließend seine eigenen Nutzer und kann Tabellen-, Pfad- und Spaltenzugriffe weiter einschränken. Das Modell funktioniert besonders gut, solange der Consumer keine zusätzliche individuelle OneLake-RLS benötigt. Für Cross-Tenant-Szenarien ist diese Grenze besonders wichtig, weil mandantenübergreifende OneLake Shortcuts Delegated Authentication verwenden.

Eine dazu passende Workspace-Strategie mit klarer Arbeitsteilung hilft, zentrale Datenverantwortung und dezentrale Nutzung sauber voneinander zu trennen.

3. Kontrollierte Datenkopie

Zero-Copy ist kein Selbstzweck. Eine physische Datenübernahme kann sinnvoller sein, wenn der Consumer ein anderes Schutzmodell benötigt, Daten stark transformiert oder historisiert werden, Quell- und Consumer-Lebenszyklen stark voneinander abweichen oder regulatorische Vorgaben eine klare Systemgrenze verlangen. Eine zusätzliche Kopie ist nicht automatisch schlechte Architektur – manchmal schafft sie die klarere Sicherheitsgrenze.

Zero-Copy bedeutet nicht Zero-Governance

Microsoft beschreibt für OneLake inzwischen ein klares Architekturpattern: Ein primärer Workspace besitzt das zentrale Datenprodukt und definiert dort die OneLake-Sicherheitsregeln. Nachgelagerte Workspaces verwenden Shortcuts, um dieselben Daten zu konsumieren, ohne weitere physische Kopien anzulegen. Security bleibt damit möglichst nah am Datenprodukt, während Nutzung und Weiterverarbeitung dezentral organisiert werden können.

Für Passthrough-Shortcuts passt dieses Modell unmittelbar. Der Endnutzer wird am Target mit seiner eigenen Identität autorisiert, sodass der Producer die verbindliche Sicherheitsinstanz bleibt. Bei Delegated Shortcuts definiert dagegen eine Connection Identity den maximalen Datenraum. Der Consumer kann Tabellen-, Pfad- und Spaltenzugriffe innerhalb dieses Rahmens weiter einschränken; eine zusätzliche Consumer-seitige OneLake-RLS ist nicht konfigurierbar. Eine zu weit gefasste Connection Identity sollte deshalb nicht durch nachgelagerte Regeln „repariert“ werden müssen.

Delegation sollte deshalb Benutzerverwaltung übertragen, nicht die Verantwortung für den maximal zulässigen Datenumfang. Der Producer bleibt verantwortlich dafür, was eine Connection Identity grundsätzlich erreichen darf. Der Consumer verantwortet, welche eigenen Nutzer innerhalb dieses Rahmens Zugriff erhalten.

Das ist insbesondere bei Cross-Tenant-Szenarien wichtig. Mandantenübergreifende OneLake Shortcuts verwenden delegierte Authentifizierung; damit wird die Connection Identity zu einer echten Architektur- und Governance-Komponente und nicht nur zu einem technischen Verbindungsparameter.

Die Engine entscheidet weiterhin mit

OneLake Security ist inzwischen deutlich breiter als eine reine Lakehouse-Berechtigung. Lakehouse-Zugriffe, Spark Notebooks, der SQL Analytics Endpoint im User-Identity-Modus und Semantic Models mit Direct Lake on OneLake können RLS und CLS aus OneLake durchsetzen. Bei Eventhouse ist aktuell nur RLS in Preview unterstützt; autorisierte Drittanbieter-Engines können Sicherheitsdefinitionen über OneLake APIs übernehmen, befinden sich aber ebenfalls noch in Preview.

Damit wird die Security zwar konsistenter, aber nicht automatisch unabhängig vom Zugriffspfad. Besonders der SQL Analytics Endpoint zeigt die Grenze: Im Delegated-Identity-Modus wird die OneLake-Security des Endnutzers nicht direkt durchgesetzt. SQL-Rollen, SQL-RLS, CLS und weitere SQL-Sicherheitsmechanismen übernehmen dort die Kontrolle. Bei Shortcuts auf Tabellen mit OneLake RLS oder CLS kann dieser Modus den Zugriff sogar blockieren; für solche Szenarien ist der User-Identity-Modus die belastbarere Wahl.

Ein Security-Test darf deshalb nicht nur prüfen, ob ein Benutzer den Lakehouse Explorer öffnen kann. Derselbe Benutzer sollte über alle vorgesehenen Wege getestet werden – etwa Spark, SQL Analytics Endpoint, Direct Lake und gegebenenfalls externe Engines. Nur so lässt sich feststellen, ob das effektive Berechtigungsmodell tatsächlich der geplanten Architektur entspricht.

Governance für Delegated Shortcuts

Für jeden delegierten Shortcut sollten mindestens drei Verantwortlichkeiten benannt werden: Der Data Owner verantwortet das Quelldatenprodukt und den maximal freigegebenen Datenumfang. Der Connection Owner verantwortet die Identität, Authentifizierung, Rotation, Monitoring und Offboarding. Der Access Owner im Consumer-Bereich entscheidet, welche Nutzer oder Gruppen über den Shortcut zugreifen dürfen. Keine dieser Rollen darf davon ausgehen, dass die jeweils andere Ebene Sicherheitslücken automatisch ausgleicht.

Dokumentiert werden sollten mindestens der fachliche Zweck, Produzent und Consumer, Ziel- und Shortcut-Pfad, Authentifizierungsmodell, Besitzer der Verbindungsidentität, maximal freigegebener Datenumfang, eingesetzte RLS-, CLS- oder OLS-Regeln, relevante Abfrage-Engines, letzte Rezertifizierung und der Fallback bei Preview-Änderungen. Wo diese Grundlagen fehlen, hilft ein Data Strategy Check, technische Entscheidungen mit Datenverantwortung, Zielbild und Prioritäten zu verbinden.

Fünf Betriebsregeln, die schnell übersehen werden

• Prüft DefaultReader und andere parallel wirksame Rollen. OneLake Security arbeitet mit einem Grant-/Union-Modell: Ein breiter zusätzlicher Grant kann eine restriktive Rolle faktisch wieder erweitern.

• Admins, Members und Contributors werden für lokale Daten eines Items nicht wie reine Viewer durch granulare OneLake-RLS oder -CLS eingeschränkt. Restriktive Datensicherheit braucht deshalb auch restriktive Workspace-Rollen.

• RLS und CLS für dieselbe Tabelle sollten innerhalb einer gemeinsamen OneLake-Rolle modelliert werden. Nicht unterstützte Kombinationen mehrerer Rollen können zu Abfragefehlern führen.

• ReadWrite-Rollen können nicht gleichzeitig RLS oder CLS enthalten. Schreibrechte und granulare Lesefilter müssen bewusst getrennt modelliert werden.

• Security-Änderungen sind nicht über alle Zugriffspfade im selben Moment sichtbar. Rollendefinitionen können kurze Propagationszeiten haben, Änderungen an Entra-Gruppenmitgliedschaften deutlich länger; zusätzlich können Engine-Caches wirken.

Bei Security-Tests sollten Zeitpunkt und Art jeder Berechtigungsänderung dokumentiert und nach Ablauf relevanter Synchronisationszeiten nochmals mit derselben Testidentität geprüft werden. Ein Sicherheitstest ist aber erst vollständig, wenn nicht nur der erlaubte Zugriff funktioniert, sondern auch der unerlaubte Zugriff nachweislich scheitert.

Best Practices für Einführung und Betrieb

Ein delegierter Shortcut sollte zunächst für ein klar abgegrenztes Datenprodukt und nicht sofort für eine unternehmensweite Datenbasis eingeführt werden. Die Verbindungsidentität erhält nur Zugriff auf die tatsächlich benötigten Tabellen, Ordner und Spalten. Persönliche Organisationskonten benötigen ein belastbares Betriebs-, Vertretungs- und Offboarding-Modell.

Die Testmatrix sollte Endnutzer, delegierte Identität und Item Owner sowie erlaubte, gesperrte und überschneidende Rollen abdecken. Getestet werden Spark, SQL Analytics Endpoint und Direct Lake auf Tabellen-, Spalten- und Zeilenebene.

Ein Sicherheitstest ist erst vollständig, wenn auch der unerlaubte Zugriff nachweislich scheitert.

Änderungen an Authentifizierung, Pfaden, Identitäten oder Sicherheitsrollen gehören in einen kontrollierten Deployment-Prozess mit Test, Freigabe, Dokumentation und Rückfalloption. Da Delegated OneLake Shortcuts weiterhin Preview sind, sollten kritische Finanz-, Personal- oder regulatorische Daten nur nach eigener Validierung und mit einem alternativen Bereitstellungsmuster darüber veröffentlicht werden.

Fazit: Delegation braucht klare Sicherheitsgrenzen

Delegated OneLake Shortcuts lösen ein reales Skalierungsproblem. Ein zentrales Team kann ein kuratiertes Datenprodukt Zero-Copy bereitstellen, ohne jeden Consumer-Nutzer einzeln am Target verwalten zu müssen. Besonders für große Fachdomänen, Tochtergesellschaften und Cross-Tenant-Szenarien ist das architektonisch attraktiv.

Die zentrale Security-Regel ist inzwischen eindeutig: CLS kann auf Producer- und Consumer-Seite wirken. RLS kann bei Delegated OneLake Shortcuts dagegen nur auf der Producer-Seite definiert werden.

Passthrough bleibt die bessere Ausgangsbasis, wenn der Producer jeden Endnutzer individuell autorisieren und benutzerspezifische RLS zentral durchsetzen soll. Delegated Authentication passt dagegen, wenn der Producer einen maximal zulässigen Datenraum für eine Domäne freigibt und der Consumer Benutzer-, Tabellen-, Pfad- und Spaltenberechtigungen innerhalb dieses Rahmens selbst verwalten soll.

Delegated OneLake Shortcuts befinden sich weiterhin in Preview. Für kritische Finanz-, Personal- oder regulatorische Daten bleibt deshalb ein Pilot mit realen Identitäten, sämtlichen vorgesehenen Engines und ausdrücklich auch negativen Zugriffstests notwendig.

Die entscheidende Architekturfrage lautet nicht nur „Passthrough oder Delegated?“, sondern: Welche Identität definiert den maximal zulässigen Datenraum – und wo muss die individuelle Benutzersegmentierung stattfinden?

Nächste Schritte

OneLake Security sollte nicht isoliert konfiguriert werden. Je nach Ausgangslage führen unterschiedliche nächste Schritte schneller zu einer belastbaren Architektur.

Microsoft Fabric Beratung: OneLake Security, Shortcuts, Identitäten und Zielarchitektur für ein konkretes Datenprodukt gemeinsam einordnen.

Data Strategy Check: Datenverantwortung, Governance-Reifegrad und Prioritäten klären, bevor technische Berechtigungsmodelle skaliert werden.

Power BI Consulting: Direct Lake, semantische Modelle und die tatsächlichen Zugriffspfade von Power BI in die Sicherheitsarchitektur integrieren.

Consulting Abo: Fabric und Power BI kontinuierlich weiterentwickeln und Architektur-, Governance- und Sicherheitsfragen laufend im Sparring lösen.

Der sinnvollste Startpunkt ist ein Review eines realen Datenprodukts mit den tatsächlichen Nutzerrollen, Engines und Sicherheitsanforderungen.