Delegated OneLake Shortcuts

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.

OneLake Security, Verbindungsidentitäten, Workspace-Rollen, RLS, CLS und die verwendete Abfrage-Engine wirken nicht automatisch als ein durchgängiges Sicherheitsmodell zusammen. 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 wurden dagegen im Juli 2026 als Preview veröffentlicht.

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. Das Consumer-Team darf nicht darauf vertrauen, dass es eine zu weitreichende Quellberechtigung später vollständig durch eigene Rollen korrigiert. Besonders bei Zeilenfiltern ist diese Annahme derzeit riskant.

RLS und CLS sind nicht gleichwertig

Column-Level Security ist bei delegierten Shortcuts vergleichsweise klar dokumentiert. CLS kann sowohl am Ziel als auch am Shortcut wirken. Der Nutzer erhält nur die Spalten, die nach Anwendung beider Ebenen übrig bleiben. Eine zusätzliche Einschränkung ist möglich; eine Erweiterung über den Quellzugriff hinaus nicht.

Bei RLS bleibt ein Dokumentationskonflikt

Stand 11. August 2026 besteht dieser Widerspruch in der Microsoft-Dokumentation weiterhin. Die Dokumentation zur Erstellung eines OneLake Shortcuts beschreibt RLS auf den Zieldaten als unterstützt. Die dedizierte Shortcut-Security-Dokumentation bezeichnet RLS für Delegated Shortcuts dagegen weiterhin als nicht unterstützt. Beide Seiten wurden zuletzt am 1. Juli aktualisiert. Für produktive Architekturentscheidungen sollte RLS deshalb derzeit nicht als verlässliche Consumer-seitige Sicherheitsfunktion eines Delegated Shortcuts eingeplant werden.

Wenn ein Consumer ausschließlich Datensätze eines Landes oder Geschäftsbereichs sehen darf, sollte dieser Schutz nicht allein auf einem delegierten Shortcut beruhen. Belastbarer sind Passthrough mit zentraler RLS, ein getrenntes Datenprodukt oder ein kontrollierter Pilot mit negativen Zugriffstests über alle relevanten Abfragepfade.

Die Unterscheidung zwischen Berechtigungen und tatsächlicher Datensicherheit wird 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 über die Identität des Item Owners auf OneLake zu. Die fachliche Sicherheit wird anschließend mit SQL-Berechtigungen, SQL-RLS, SQL-CLS oder Dynamic Data Masking umgesetzt. OneLake-Sicherheitsrollen des Endnutzers werden auf dieser Ebene nicht direkt durchgesetzt. Ein erfolgreicher Test im Lakehouse beweist nicht, dass SQL, Spark und Power BI dieselbe Datensicht liefern.

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 begrenzte Verbindungsidentität. Das Consumer-Team verwaltet die Nutzer innerhalb seines eigenen Workspace- und OneLake-Sicherheitsmodells. Dieses Modell passt zu großen Fachbereichen, Tochtergesellschaften und Cross-Tenant-Szenarien. Es funktioniert aber nur mit einem klaren Übergabepunkt und einer Identität, die nicht pauschal auf ein gesamtes Lakehouse zugreifen darf.

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 Ziel mit seiner eigenen Identität autorisiert, sodass die Quelle die verbindliche Sicherheitsinstanz bleibt. Bei Delegated Shortcuts verändert sich die Arbeitsteilung: Eine konfigurierte Verbindungsidentität definiert, auf welchen maximalen Datenumfang der Consumer überhaupt zugreifen kann. Die Security des Consumers kann diesen Zugriff anschließend weiter begrenzen; eine zu weit gefasste Verbindungsidentität sollte aber 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.

Vier Grenzen, die im Betrieb schnell übersehen werden

• RLS und CLS wirken nicht auf Admins, Members und Contributors. Granulare OneLake Security ist deshalb kein Ersatz für restriktive Workspace-Rollen.

• RLS und CLS sollten innerhalb derselben OneLake-Rolle kombiniert werden. Verteilt sich RLS und CLS für dieselbe Tabelle auf unterschiedliche Rollen eines Nutzers, können Abfragen fehlschlagen.

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

• Berechtigungsänderungen greifen nicht immer sofort. Änderungen an Rollendefinitionen benötigen ungefähr fünf Minuten; Änderungen an Entra-Gruppen können etwa eine Stunde benötigen. Hinzu kommen mögliche Engine-Caches.

Gerade der letzte Punkt ist praktisch relevant: Ein vermeintlich fehlerhaftes Security-Modell kann schlicht noch nicht vollständig propagiert sein. Bei Security-Tests sollten Änderungen deshalb dokumentiert und nach Ablauf der relevanten Caches erneut mit derselben Testidentität geprüft werden.

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 bereitstellen, ohne jede Consumer-Identität einzeln an der Quelle verwalten zu müssen. Besonders für große Fachdomänen, Tochtergesellschaften und Cross-Tenant-Szenarien ist das architektonisch interessant.

Passthrough bleibt die bessere Ausgangsbasis, wenn zentrale Autorisierung und RLS unverzichtbar sind. Delegierte Shortcuts passen, wenn Zugriffsverwaltung bewusst übertragen werden soll und die Sicherheitsgrenze klar definiert ist.

Solange Delegated OneLake Shortcuts Preview sind und die Dokumentation zu RLS widersprüchlich bleibt, gehört ein technischer Pilot mit realen Rollen, echten Engines und negativen Tests zwingend vor die Produktionsfreigabe.

---

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.