Berechtigungen für Microsoft Fabric-Verknüpfungen: interne und externe Sicherheitsregeln

Von Mirko Peters · 2026-10-30

Erfahren Sie, wie Berechtigungen für Microsoft Fabric-Verknüpfungen funktionieren. Der Artikel vergleicht die Weitergabe der Identität interner Benutzer mit den Sicherheitsregeln für gespeicherte externe Verbindungen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Berechtigungen für Microsoft Fabric-Verknüpfungen bestimmen, wie Benutzer arbeitsbereichsübergreifend und über mehrere Clouds hinweg auf Daten zugreifen, ohne Dateien zu kopieren. Interne Verknüpfungen setzen auf die Weitergabe der Benutzeridentität, externe Cloud-Quellen dagegen auf gespeicherte Verbindungsidentitäten. Wer diese Sicherheitsgrenzen versteht, verhindert unautorisierte Datenoffenlegung und behebt lästige Abfragefehler in nachgelagerten Prozessen.

Das Wichtigste in Kürze

• Interne Verknüpfungen geben die Identität des abfragenden Benutzers weiter. Dafür sind direkte Zugriffsrechte am Zielpfad erforderlich.
• Externe Cloud-Verknüpfungen verwenden gespeicherte Verbindungsanmeldedaten. Damit erhält jeder Zugriff, der das Lakehouse lesen darf.
• Stehen die Berechtigungsstufen von Verknüpfungspfad und Zielpfad im Konflikt, setzt sich immer die strengere Sicherheitsregel durch.
• Schreibbare Verknüpfungen bergen ein erhebliches Risiko kaskadierender Datenlöschungen, wenn die Berechtigungen am Ziel falsch konfiguriert sind.
• Eine sorgfältige Planung der Sicherheitsgrenzen verhindert unerwartete Zugriffsfehler beim Skalieren multi-cloudübergreifender Architekturen.

So funktionieren Berechtigungen für Microsoft Fabric-Verknüpfungen

Wenn Sie in OneLake Verweise auf verschiedene Datenquellen einrichten, ist Sicherheit selten eine Konfiguration, die man einrichtet und dann vergisst. Anders als bei klassischen Data-Warehouse-Modellen, in denen Berechtigungen zentral verwaltet und einheitlich auf kopierte Tabellen angewendet werden, führen Fabric-Verknüpfungen zu einem Split-Brain-Identitätsproblem. Es gibt einen Verknüpfungspfad, über den der Benutzer eine Abfrage startet, und einen Zielpfad, unter dem die physischen Daten liegen. Fabric prüft beide Endpunkte, bevor eine einzige Datenzeile zurückgegeben wird. Deshalb ist die Sicherheitsarchitektur eine zentrale Entwurfsvoraussetzung für Cloud-Administratoren.

Das Grundprinzip der Fabric-Sicherheit beruht auf dem Least-Privilege-Prinzip. Verknüpfungen durchbrechen jedoch die Regeln des klassischen Datenzugriffs. Da Daten beim Einrichten einer Verknüpfung nicht verschoben werden, müssen die Berechtigungen des zugrunde liegenden Speicherkontos, des externen Amazon S3-Buckets oder des übergeordneten Lakehouse sorgfältig abgebildet werden. Hat ein Benutzer Lesezugriff auf den Arbeitsbereich mit der Verknüpfung, aber keinen Zugriff auf den Quellcontainer, schlägt die Abfrage fehl. Umgekehrt können zu weit gefasste Berechtigungen für eine gespeicherte Verbindungsidentität sensible externe Dateien unbeabsichtigt für unautorisierte Power-User freigeben.

Interne Verknüpfungen und die Weitergabe der Benutzeridentität

Interne Verknüpfungen – also Verweise von einem Fabric-Element auf ein anderes, etwa von einem Lakehouse im Vertriebsarbeitsbereich auf eine gemeinsam genutzte Kundentabelle – arbeiten mit Ihrer exakten Entra ID-Identität. Wenn Sie eine interne Verknüpfung abfragen, prüft Fabric, ob Ihr Konto explizite Leseberechtigungen für den Zielarbeitsbereich und das Zielelement besitzt. Fehlt Ihnen die Berechtigung, die Quelltabellen anzuzeigen, gibt die Verknüpfung einen Fehler zurück.

Dieses Verhalten orientiert sich bewusst an der klassischen Zugriffssteuerung. Es verhindert, dass Power-User Arbeitsbereichsgrenzen umgehen, indem sie einfach Verknüpfungen zu eingeschränkten Datasets anlegen. Allerdings bedeutet das auch, dass Berichtersteller über mehrere Arbeitsbereiche hinweg passend berechtigt werden müssen. Das erhöht den administrativen Aufwand für die Verwaltung kollaborativer Analyseteams.

Externe Verknüpfungen und gespeicherte Verbindungsidentitäten

Externe Verknüpfungen verändern die Sicherheitslage grundlegend. Wenn Sie ein Fabric-Lakehouse auf ein Azure Data Lake Storage Gen2-Konto, Amazon S3, Google Cloud Storage oder einen lokalen Netzwerkspeicherort über ein Datengateway zeigen lassen, endet die Weitergabe der Benutzeridentität an der Fabric-Grenze. Stattdessen authentifizieren sich externe Verknüpfungen über eine gespeicherte Verbindungsidentität.

Dieser Unterschied im Betrieb hat weitreichende Sicherheitsfolgen. Wer Lesezugriff auf das Fabric-Lakehouse mit der externen Verknüpfung hat, kann die zugrunde liegende Datenquelle darüber abfragen, unabhängig davon, ob er direkte Anmeldedaten für den externen Cloud-Bucket besitzt. Administratoren sollten Lakehouses mit externen Verknüpfungen als Zonen mit hoher Vertraulichkeit behandeln und die Arbeitsbereichsrollen streng einschränken, um eine unbefugte Datenabfluss zu verhindern.

Die Regel des strengeren Berechtigungsmodells

Wenn Sie in Microsoft Fabric Zugriffsfehler beheben, stoßen Administratoren häufig auf die maßgebliche Regel für Verknüpfungsberechtigungen: Die strengere der beiden Berechtigungen gilt.

Um diese Regel auszuwerten, müssen Sie beide Enden des Verweises betrachten:

• Berechtigungen am Verknüpfungspfad: Die Rollenzuweisungen (Admin, Mitglied, Mitwirkender, Anzeigender) für den Arbeitsbereich und das Lakehouse, in dem sich die Verknüpfung befindet.
• Berechtigungen am Zielpfad: Die Zugriffssteuerungslisten (ACLs), IAM-Richtlinien oder Datenbankberechtigungen, die direkt auf die Quelldateien oder Tabellen angewendet werden.

Ist ein Benutzer Mitwirkender im Arbeitsbereich, der die Verknüpfung hostet, hat aber nur Anzeigeberechtigungen auf dem Zielspeicherkonto, kann er die Daten nur lesen. Hat ein Benutzer dagegen volle Adminrechte auf das Quell-Dataset, seine Arbeitsbereichsrolle ist aber auf Anzeigender beschränkt, kann er die Konfiguration der Verknüpfung nicht ändern oder verwalten. Diese zweistufige Durchsetzung stellt sicher, dass keine einzelne Fehlkonfiguration die gesamte Sicherheitsarchitektur Ihrer Organisation vollständig öffnen kann. Sie erfordert jedoch eine sorgfältige Dokumentation, wenn Sie sich mit getrennten IT-Abteilungen abstimmen.

Risiken schreibbarer Verknüpfungen und kaskadierender Löschvorgänge

Sicherheitsberechtigungen legen nicht nur fest, wer Daten lesen darf, sondern auch, was Benutzer zerstören können. Eine der gefährlichsten Fallen für unerfahrene Administratoren sind schreibbare Verknüpfungen in Kombination mit zu großzügig konfigurierten Identitätseinstellungen.

Fabric-Verknüpfungen führen keine kaskadierenden Löschvorgänge auf den zugrunde liegenden Daten aus, wenn Sie das Verknüpfungsobjekt selbst löschen. Ihre Zieldaten bleiben also vollständig erhalten. Wenn eine Verknüpfung jedoch schreibbar ist und ein Benutzer Löschberechtigungen auf dem Zielpfad hat, werden beim Löschen von Dateien oder Ordnern über den Verknüpfungspfad die Daten an der Quelle dauerhaft entfernt. Die Verknüpfung wirkt wie eine direkte Tür in das Zielspeichersystem. Ein fehlerhaftes Bereinigungsskript oder eine versehentliche Aktion eines Benutzers kann tragende Strukturen schneller einreißen, als es klassische Datenpipelines jemals könnten.

Fazit

Die Berechtigungen für Verknüpfungen in Microsoft Fabric erfordern ein grundlegend anderes Denken beim Thema Datenzugriff und Governance. Indem Sie die Weitergabe der Benutzeridentität für interne Workloads mit streng kontrollierten, gespeicherten Anmeldedaten für Multi-Cloud-Quellen ausbalancieren, schaffen Sie eine reaktionsschnelle, kopierfreie Analyseumgebung, ohne die Sicherheit zu gefährden. Um breitere Architekturstrategien, Datenformate und Abwägungen zu erkunden, hören Sie sich die vollständige Episode an für eine umfassende Analyse des modernen Cloud-Datenmanagements.

Häufige Fragen

Übernehmen Microsoft Fabric-Verknüpfungen automatisch Benutzerberechtigungen?

Interne Verknüpfungen verwenden Ihre persönliche Entra ID-Identität. Das bedeutet, Sie benötigen explizite Leseberechtigungen sowohl für den Verknüpfungs-Arbeitsbereich als auch für den Ziel-Arbeitsbereich. Externe Verknüpfungen hingegen verwenden eine gespeicherte Verbindungsidentität, sodass jeder mit Zugriff auf das Lakehouse die externen Daten lesen kann.

Was passiert mit Daten, wenn ich eine Microsoft Fabric-Verknüpfung lösche?

Das Löschen des Shortcut-Objekts selbst löscht die Daten am Zielpfad nicht. Die physischen Dateien oder Tabellen bleiben vollständig erhalten, es sei denn, der Shortcut wurde als beschreibbar konfiguriert und der Benutzer hat über den Shortcut-Pfad mit ausreichenden Berechtigungen am Ziel explizit Dateien gelöscht.

Wie handhaben externe Cloud-Shortcuts die Authentifizierung für AWS S3 oder Google Cloud Storage?

Externe Cloud-Shortcuts authentifizieren sich über eine gespeicherte Verbindung, die während der Einrichtung konfiguriert wird, und nicht über individuelle Benutzeranmeldedaten. Daher fungieren die Zugriffssteuerungslisten des Workspaces als primäre Sicherheitsbarriere für Benutzer, die multi-cloud-Daten abfragen.

Was bedeutet die Sicherheitsregel „Stricter-wins“ in Fabric?

Die Regel „Stricter-wins“ besagt, dass Fabric bei der Zugriffsprüfung den restriktivsten Berechtigungssatz durchsetzt, der sowohl im Shortcut-Pfad als auch im Zielpfad gilt. Verweigert einer der beiden Standorte den Zugriff oder schränkt er Funktionen ein, gelten diese Einschränkungen für den Endbenutzer.