Wie die Sicherheit von OneLake den Datenzugriff kontrolliert

OneLake-Sicherheit ist ein rollenbasiertes System, das bestimmt, wer auf die Daten in OneLake zugreifen kann und welche Maßnahmen sie auf diese Daten ausführen können. Das Verständnis des Datenzugriffskontrollmodells hilft Ihnen, den Nutzern nur den Zugriff zu gewähren, den sie benötigen, sodass Sie sensible Daten schützen können und gleichzeitig die richtigen Personen damit arbeiten lassen.

Dieser Artikel erklärt, wie OneLake-Sicherheitsrollen strukturiert sind, wie sie sich mit Arbeitsbereichs- und Artikelberechtigungen integrieren, wie OneLake Zugriff auf Ihre Daten anwendet und löst sowie welche Grenzen Sie beachten sollten.

OneLake-Sicherheitsrollen

Die OneLake-Sicherheit verwendet ein rollenbasiertes Zugriffskontrollmodell (RBAC), um den Zugriff auf Daten in OneLake zu verwalten. In der OneLake-Sicherheitserfahrung hat jede Rolle folgende Komponenten:

  • Berechtigungen: Die Berechtigungen, die die Rolle für die Daten erteilt, z. B. Lesen oder Lesen/Schreiben.
  • Typ: Der Rollentyp. Die Sicherheit von OneLake unterstützt ausschließlich Grant-Rollen, die den Mitgliedern Zugang zu den Daten in der Rolle gewähren. Es unterstützt keine Deny-Rollen, die den Zugriff entziehen.
  • Daten in der Rolle: Die Tabellen , Ordner oder Schemata, auf die die Rolle Zugriff gewährt. Sie können auch Datenzugriff mit Zeilen- und Spaltensicherheit auf Tabellen definieren.
  • Mitglieder in der Rolle: Die Microsoft Entra-Identitäten, die der Rolle zugewiesen sind, wie Benutzer-, Gruppen- oder Nichtbenutzer-Identitäten. Wenn Sie eine Microsoft Entra-Gruppe zuweisen, weist die OneLake-Sicherheit die Rolle allen Gruppenmitgliedern zu.

Die OneLake-Sicherheit verwendet ein Deny-by-Default-Modell, sodass Nutzer ohne Zugriff auf Daten starten, es sei denn, eine OneLake-Sicherheitsrolle gewährt ausdrücklich den Zugriff. Einige Fabric-Elemente beginnen mit Standardrollen, die den Nutzern grundlegenden Zugriff basierend auf ihren Arbeitsbereichsberechtigungen geben.

Berechtigungen und unterstützte Elemente

OneLake-Sicherheitsrollen unterstützen die folgenden Berechtigungen:

  • Lesen: Gewährt dem Benutzer die Möglichkeit, Daten aus einer Tabelle zu lesen und die zugehörigen Tabellen- und Spaltenmetadaten anzuzeigen. In SQL-Terminologie entspricht diese Berechtigung sowohl VIEW_DEFINITION als auch SELECT. Weitere Informationen finden Sie unter Metadatensicherheit.
  • ReadWrite: Gewährt dem Benutzer die Möglichkeit, Daten in einer Tabelle oder einem Ordner zu lesen und zu schreiben und die zugehörigen Tabellen- und Spaltenmetadaten einzusehen. In SQL-Begriffen ist diese Berechtigung äquivalent zu ALTER, DROP, UPDATE, und INSERT. Weitere Informationen finden Sie unter ReadWrite-Erlaubnis.

Sie können OneLake-Sicherheitsrollen für die folgenden Fabric-Artikel erstellen:

Fabric-Element Unterstützte Berechtigungen
Lakehouse Lesen, LesenSchreiben
Azure Databricks gespiegelt­er Katalog Lesen
Gespiegelte Datenbanken Lesen
Gespiegelte Kataloge Lesen

Lese-/Schreibberechtigung

Verwenden Sie die ReadWrite-Berechtigung, um ReadNur-Nutzern Schreibzugriff auf bestimmte Daten in einem Element zu geben.

ReadWrite gilt nur für Benutzer mit der Leserberechtigung für ein Element, wie z. B. Nutzer mit der Viewer-Workspace-Rolle. Die Zuweisung von ReadWrite an einen Workspace-Administrator, Mitglied oder Contributor hat keine Auswirkung, da diese Workspace-Rollen bereits Schreibzugriff haben.

ReadWrite umfasst alle durch die Lesberechtigung gewährten Privilegien und gewährt zudem Schreibzugriff auf das ausgewählte Objekt und dessen Inhalte. Zum Beispiel gewährt die ReadWrite-Berechtigung für einen Ordner Schreibzugriff sowohl auf den Ordner als auch auf die darin enthaltenen Daten.

Benutzer mit ReadWrite-Berechtigung können folgende Aktionen ausführen:

  • Einen Ordner oder eine Tabelle erstellen, löschen oder umbenennen.
  • Lade eine Datei hoch oder bearbeite sie.
  • Erstellen Sie, löschen Sie oder benennen Sie eine Verknüpfung.

Benutzer können Schreiboperationen über Spark-Notizbücher, den OneLake-Dateiexplorer oder OneLake-APIs durchführen. Da Fabric nur Schreibvorgänge mit einer einzigen Engine für Daten unterstützt, können Benutzer mit ReadWrite-Berechtigung nur über OneLake in diese Daten schreiben. Alle Abfrage-Engines erzwingen weiterhin konsequent Leseoperationen.

OneLake-Sicherheitsrollen, die ReadWrite-Berechtigungen erteilen, dürfen keine Zeilenebenen-Sicherheitsbeschränkungen (RLS) oder Spaltenebenen-Sicherheitsbeschränkungen (CLS) enthalten.

OneLake-Sicherheits- und Arbeitsbereichsberechtigungen

Workspace-Rollen sind die erste Sicherheitsgrenze für Daten in OneLake. Sie verwalten die Steuerungsebene – durch das Erstellen und Verwalten von Fabric-Elementen und -Berechtigungen – und gelten für alle Elemente im Arbeitsbereich. Für die spezifischen OneLake-Berechtigungen, die jede Workspace-Rolle gewährt, siehe Zugriff mit Workspace-Rollen gewähren. Um mehr über Workspace-Rollen zu erfahren, siehe Rollen in Workspaces in Fabric.

Über den Zugriff auf die Kontrollebene hinaus können Arbeitsbereichsrollen auch Zugriff auf Datenelemente über OneLake-Sicherheitsstandardrollen bieten. (Standardrollen gelten nur für Viewer, da die Rollen Admin, Member und Contributor durch die Berechtigung „Schreiben“ erweiterten Zugriff haben.) Eine Standardrolle ist eine normale OneLake-Sicherheitsrolle, die Fabric automatisch für jedes neue Element erstellt. Es gibt Benutzern mit bestimmten Arbeitsbereichs- oder Elementberechtigungen eine Standardstufe des Zugriffs auf Daten in diesem Element. Beispielsweise verfügen Lakehouse-Elemente über eine DefaultReader-Rolle, mit der Benutzer mit der Berechtigung „ReadAll“ Daten im Lakehouse einsehen können. Dieser Standardzugriff stellt sicher, dass Nutzer, die mit einem neu erstellten Teil arbeiten, einen grundlegenden Zugriff haben. Alle Standardrollen verwenden eine Mitgliedervirtualisierungsfunktion, sodass die Mitglieder der Rolle alle Benutzer in diesem Arbeitsbereich mit der erforderlichen Berechtigung sind. Beispielsweise alle Benutzer mit der ReadAll-Berechtigung für das Lakehouse.

Die folgende Tabelle zeigt die Standardrollen. Gegenstände könnten spezielle Standardrollen haben, die nur für diesen Gegenstandstyp gelten.

Fabric-Element Rollenname Erteilte Erlaubnis Zugewiesene Mitglieder
Lakehouse DefaultReader Lesen Alle Benutzer mit ReadAll-Berechtigung
Azure Databricks gespiegelt­er Katalog DefaultReader Lesen Alle Benutzer mit Leseberechtigung
Gespiegelter Katalog DefaultReader Lesen Alle Benutzer mit Leseberechtigung
Gespiegelte Datenbank DefaultReader Lesen Alle Benutzer mit ReadAll-Berechtigung

Du kannst die Standardrolle eines Fabric-Objekts ändern oder entfernen, um den Zugriff für Nutzer in dieser Mitgliedergruppe zu ändern.

Maschinen- und Benutzerzugriff auf Daten

Die OneLake-Sicherheit ist standardmäßig auf den am wenigsten privilegierten Zugriff eingestellt. Einige Speicher-Operationen können RLS oder CLS nicht durchsetzen, daher blockiert OneLake sie vollständig, wenn eine Abfrage nicht sicher gefiltert werden kann, anstatt das Risiko einzugehen, Daten freizugeben, die der Benutzer nicht sehen darf. Ob eine Abfrage gefiltert oder blockiert wird, hängt vom Zugriffspfad ab – einer unterstützten Abfrage-Engine oder direktem Benutzerzugriff.

Welche Engines die RLS- und CLS-Filterung unterstützen und welche Anforderungen jeweils gelten, finden Sie unter Mit OneLake-Sicherheit geschützte Daten lesen.

Anwendungsbereiche und Durchsetzung

Dieser Abschnitt enthält Details dazu, wie OneLake-Sicherheitsrollen Zugriff auf bestimmte Bereiche gewähren, wie dieser Zugriff funktioniert und wie der Zugriff über mehrere Rollen und Zugriffstypen hinweg aufgelöst wird.

Sicherheit auf Tabellenebene

OneLake repräsentiert alle Tabellen als Ordner, aber aus Sicht der OneLake-Sicherheits- und Abfrage-Engines in Fabric sind nicht alle Ordner Tabellen. Um eine gültige Tabelle zu sein, muss ein Ordner die folgenden Bedingungen erfüllen:

  • Der Ordner befindet sich im Tables/ Verzeichnis eines Elements. Bei schemafähigen Elementen muss sich der Ordner auch in einem gültigen Schemaordner befinden.
  • Der Ordner enthält einen _delta_log Ordner mit den entsprechenden JSON-Dateien für die Tabellenmetadaten.
  • Der Ordner enthält keine kindlichen Verknüpfungen.

Wenn Sie RLS oder CLS auf einer Tabelle konfigurieren, verweigert OneLake den Zugriff, wenn der Ordner der Tabelle diese Kriterien nicht erfüllt. Ohne RLS oder CLS behandelt OneLake einen Ordner, der diese Kriterien nicht erfüllt, als Ordner und wendet die Sicherheit auf Ordnerebene an.

Sicherheit auf Zeilen- und Spaltenebene

Innerhalb einer Rolle können Sie den Zugriff auf bestimmte Zeilen und Spalten einer Tabelle beschränken, indem Sie Zeilen- und Spaltensicherheit verwenden. Weitere Informationen darüber, was jede Kontrolle macht und wie OneLake sie durchsetzt, finden Sie unter Tabellen-, Spalten- und Zeilensicherheit in OneLake. Informationen darüber, wie RLS und CLS aufgelöst werden, wenn ein Benutzer mehreren Rollen angehört, finden Sie unter Mehrere OneLake-Sicherheitsrollen auswerten.

Metadatensicherheit

Die Berechtigung "Lesen" von OneLake gewährt vollzugriff auf die Daten und Metadaten in einer Tabelle. Für Benutzer ohne Zugriff auf eine Tabelle werden die Daten nie verfügbar gemacht. Diese Regel gilt auch für die Sicherheit auf Spaltenebene und die Fähigkeit eines Benutzers, eine Spalte in dieser Tabelle zu sehen oder nicht. Die Sicherheit von OneLake garantiert jedoch nicht, dass die Metadaten einer Tabelle nicht zugänglich sind. Bestimmte Fehlermeldungen und Erfahrungen können Spaltennamen anzeigen.

Vererbung und Durchlauf von Ordnerberechtigungen

Ordnerberechtigungen beeinflussen eine Hierarchie in zwei Richtungen:

  • Vererbung: Berechtigungen, die einem Ordner gewährt werden, gelten nach unten für seine Dateien und Unterordner.
  • Durchlauf und Auflistung: Wenn Nutzer Berechtigungen für ein Kind-Element haben, erlaubt die OneLake-Sicherheit ihnen, die Elternordner aufzulisten und zu durchlaufen, damit sie die Daten entdecken und navigieren können, auf die sie zugreifen können. Der Durchlauf gewährt keinen Zugriff auf Geschwisterdateien oder -ordner.

Betrachten Sie die folgende Hierarchie eines Seehauses in OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt
│   
└───folder2
    │   file21.txt

Du erstellst eine Rolle, Role1, die die Leseberechtigung für subfolder11 gewährt. Durch Vererbung können Mitglieder dieser Rolle file111.txt und alles in subfolder111 lesen. Mitglieder können folder1 anzeigen und zu subfolder11 navigieren, aber sie können file11.txt nicht sehen, weil es ein Geschwisterelement von subfolder11 ist, und sie können Tables nicht sehen, weil es ein Geschwisterelement von Files ist.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Sie erstellen eine weitere Rolle, Role2, die Leseberechtigung für folder2 gewährt. Durch Vererbung können Mitglieder file21.txt lesen. Mitglieder können über folder2 und Files darauf zugreifen, aber sie können weder folder1 noch eines seiner untergeordneten Elemente sehen.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Bei Abkürzungen ist das Verhalten leicht anders. Verknüpfungen zu externen Datenquellen verhalten sich genauso wie Ordner. Abkürzungen zu anderen OneLake-Standorten weisen jedoch ein spezielles Verhalten auf. Die Zielberechtigungen der Verknüpfung bestimmen den Zugriff auf eine OneLake-Verknüpfung. Beim Auflisten von Abkürzungen ruft OneLake nicht an, um den Zielzugang zu überprüfen. Daher gibt OneLake beim Auflisten eines Verzeichnisses alle internen Verknüpfungen zurück, unabhängig davon, ob Sie Zugriff auf das Ziel haben. Die Zugriffsprüfung wird durchgeführt, sobald du versuchst, die Verknüpfung zu öffnen, und anschließend werden dir nur die Daten angezeigt, für die du die erforderlichen Berechtigungen hast.

Tastenkombinationen

OneLake-Sicherheit integriert sich mit Abkürzungen, um Daten innerhalb und außerhalb von OneLake zu sichern. Kurzbefehle verwenden einen von zwei Authentifizierungsmodi:

  • Passthrough: Die Verknüpfung verwendet die Identität des anfragenden Benutzers, um auf das Ziel zuzugreifen. Passthrough ist die Standardeinstellung für OneLake-zu-OneLake-Shortcuts.
  • Delegiert: Die Verknüpfung verwendet eine konfigurierte Verbindungsidentität oder Zugangsdaten, um auf das Ziel zuzugreifen. OneLake-zu-OneLake-Shortcuts können delegierte Authentifizierung verwenden, und Shortcuts zu externen Systemen verwenden immer delegierte Authentifizierung.

Das Erstellen einer Verknüpfung erfordert Berechtigungen sowohl für den Pfad, auf dem die Verknüpfung erstellt wird, als auch für den Zielpfad. Für die Anforderungen zum Erstellen und Zugriff auf jeden Verknüpfungstyp siehe OneLake-Shortcut-Sicherheit.

OneLake-Sicherheit in Passthrough-Verknüpfungen

Wenn ein Benutzer über eine Durchgangsabkürzung von OneLake zu OneLake auf Daten zugreift, verwendet OneLake die Identität des anrufenden Benutzers, um den Zugriff auf den Zielpfad zu autorisieren. Der effektive Zugriff des Nutzers wird durch seine Berechtigungen sowohl für den Kurzstreckenpfad als auch für den Zielpfad eingeschränkt.

Hinweis

Abfrage-Engine-Identität und Shortcut-Authentifizierung sind separate Einstellungen. Ein Passthrough-Shortcut verwendet normalerweise die Identität des anrufenden Nutzers, um auf das Ziel zuzugreifen. Power BI-semantische Modelle, die Direct Lake über SQL- und SQL-Analyse-Endpunkte im delegierten Identitätsmodus verwenden, verwenden jedoch die Eigentümeridentität des Verbraucherprodukts oder der Datenquelle. Dieses Verhalten ändert nicht den konfigurierten Authentifizierungsmodus der Verknüpfung. Für das End-to-End-User-Identitäts-Passthrough verwenden Sie Direct Lake über OneLake oder konfigurieren Sie den SQL-Analytics-Endpunkt so, dass er den Benutzer-Identitätszugriffsmodus nutzt.

Du kannst OneLake-Sicherheitsberechtigungen nicht direkt auf einer OneLake-zu-OneLake-Abkürzung definieren. Berechtigungen für den Ordner, der die Verknüpfung enthält, werden mit Berechtigungen für den Zielpfad kombiniert. Wenn das Zielobjekt OneLake-Sicherheit unterstützt, benötigt der Benutzer Zugriff über eine OneLake-Sicherheitsrolle. Wenn das Zielobjekt die OneLake-Sicherheit nicht unterstützt, benötigt der Benutzer die Fabric ReadAll-Berechtigung für das Zielobjekt. Der Benutzer benötigt keine Leseberechtigung in Fabric für das Zielelement, um allein über die Verknüpfung auf dessen Daten zuzugreifen.

OneLake-Sicherheit in delegierten Tastenkombinationen

Delegierte Shortcuts verwenden eine konfigurierte Verbindungsidentität oder Zugangsdaten anstelle der Identität des anrufenden Benutzers, um auf das Ziel zuzugreifen. Die Sicherheit von OneLake begrenzt, worauf der anrufende Nutzer über diese Verbindung zugreifen kann.

Delegierte OneLake-Tastenkombinationen

Bei einer delegierten OneLake-zu-OneLake-Verknüpfung sieht der aufrufende Benutzer die Schnittmenge seiner Zugriffsrechte für den Verknüpfungspfad und der Zugriffsrechte der konfigurierten Verbindungsidentität für den Zielpfad. Die Sicherheit auf Spaltenebene (CLS) wird in beiden Pfaden unterstützt. Row-Level Security (RLS) wird auf dem Zielpfad unterstützt, aber man kann RLS nicht auf dem Shortcut-Pfad definieren.

Delegierte externe Abkürzungen

Verknüpfungen zu externen Systemen wie ADLS, Amazon S3 und Dataverse verwenden konfigurierte Verbindungsanmeldeinformationen, um auf die externe Quelle zuzugreifen. Die OneLake-Sicherheit wird zusätzlich zu dem Zugriff angewendet, der durch diese Zugangsberechtigung gewährt wird.

Angenommen, Benutzer1 erstellt eine Lakehouse-Verknüpfung zu einem Ordner in einem Amazon S3-Bucket, und Benutzer2 greift vom Lakehouse aus auf die Verknüpfung zu. User2 kann nur auf die S3-Daten zugreifen, wenn die Anmeldeinformationen der konfigurierten S3-Verbindung Zugriff auf die Quelle haben und die OneLake-Sicherheit User2 den Zugriff auf den Verknüpfungspfad erlaubt.

Sie können OneLake Sicherheitszugriff auf die gesamte externe Verknüpfung oder auf ausgewählte Unterpfade gewähren. Berechtigungen für einen Ordner werden rekursiv an alle seine Unterordner vererbt, einschließlich der Ordner innerhalb der Verknüpfung. Ein Nutzer, der eine externe Abkürzung über eine andere OneLake-Abkürzung erreicht, muss weiterhin von der OneLake-Sicherheit autorisiert sein, die auf die ursprüngliche externe Verknüpfung angewendet wurde.

Der Zugriff auf eine externe Verknüpfung über Spark oder einen direkten OneLake-API-Aufruf erfordert außerdem die Fabric Read-Berechtigung für das Element, das die externe Verknüpfung enthält. Diese Berechtigung ist erforderlich, um die Verbindung zum externen System sicher zu lösen.

Bewerten Sie mehrere OneLake-Sicherheitsrollen

Ein Benutzer kann mehreren OneLake-Sicherheitsrollen angehören. OneLake kombiniert den von diesen Rollen gewährten Zugriff zu einer effektiven Rolle, die bestimmt, auf welche Daten der Nutzer zugreifen kann. OneLake bewertet die effektive Rolle stufenweise.

Zugriff für jede Rolle festlegen

OneLake löst zunächst jede Rolle unabhängig voneinander auf. Innerhalb einer Rolle kann ein Benutzer nur auf die Daten zugreifen, die von allen drei Sicherheitskomponenten erlaubt sind:

  • Die Objektsicherheit (OLS) bestimmt, auf welche Tabellen oder Ordner die Rolle Zugriff hat.
  • Die Zeilensicherheit (RLS) begrenzt, auf welche Zeilen einer bestimmten Tabelle die Rolle zugriffen kann.
  • Column-Level Security (CLS) begrenzt, auf welche Spalten einer bestimmten Tabelle die Rolle zugriffen kann.

Da alle drei Komponenten zutreffen, nimmt OneLake ihre Schnittpunkte. Wenn zum Beispiel Rolle1 Zugriff auf Tabelle1 gewährt und deren Zeilen und Spalten einschränkt, lautet der aufgelöste Zugriff für Rolle1:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Das Schnittmengenzeichen (∩) bedeutet, dass der Benutzer nur Zugriff auf den durch OLS, RLS und CLS in dieser Rolle gewährten Zugriff erhält.

Kombinieren Sie den Zugang über verschiedene Rollen hinweg

Nachdem jede Rolle aufgelöst wurde, kombiniert OneLake die Rollen mithilfe eines Vereinigungsmodells, also des am wenigsten restriktiven Modells. Das Union-Symbol (∪) bedeutet, dass der von jeder Rolle gewährte Zugang Teil der effektiven Rolle wird. Wenn Rolle1 Zugriff auf Tabelle A gewährt und Rolle2 Zugriff auf TabelleB, kann ein Benutzer, der beiden Rollen angehört, auf beide Tabellen zugreifen.

Für zwei Rollen ist die effektive Rolle:

Effective role = Role1 ∪ Role2

Wenn mehrere Rollen Zugriff auf dieselbe Tabelle gewähren, werden Sicherheitsregeln auf Zeilenebene mit einem Operator OR kombiniert. Zum Beispiel werden Prädikate, die city = 'Redmond' und city = 'New York' zulassen, zu city = 'Redmond' OR city = 'New York' kombiniert.

Sicherheitsregeln auf Spaltenebene kombinieren sich ebenfalls als Vereinigung, außer im SQL-Analytics-Endpunkt. Im SQL-Analytics-Endpunkt verwendet CLS eine strengere Deny-Semantik. Wenn eine Rolle eine Spalte verbirgt, blockiert der Endpunkt den Zugriff auf diese Spalte. Infolgedessen schneidet der Endpunkt CLS-Listen über alle Rollen des Benutzers hinweg, anstatt sie als Union zu kombinieren.

Wichtig

Behalte RLS- und CLS-Regeln, die in derselben Rolle zusammen gelten müssen. OneLake unterstützt keine Rollenkombination, bei der zwei Rollen unterschiedliche Spaltensätze für eine Tabelle erlauben und beide Rollen auch RLS auf diese Tabelle anwenden. Zum Beispiel kann ein Benutzer nicht zu Rolle1 gehören, das die Spalten c1 und c2 sowie eine Teilmenge von Zeilen erlaubt, und zu Rolle2, das die Spalten c2 und c3 erlaubt.

Kombination, Abkürzung und Zielzugriff

Für eine Abkürzung bewertet OneLake die Rollen am Abkürzungsstandort und am Abkürzungsziel getrennt. Die Zielrollen werden am Abkürzungsort zu abgeleiteten Rollen . OneLake bildet dann die Schnittmenge aus dem kombinierten Zugriff der Shortcut-Rollen und dem kombinierten Zugriff der abgeleiteten Zielrollen. Dieser Schritt verhindert, dass der am Shortcut-Standort geerbte Zugriff die Beschränkungen des Ziels überschreibt.

Für zwei Abkürzungsrollen und zwei abgeleitete Zielrollen ist der effektive Zugang:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

In diesem Ausdruck bezeichnen ShortcutRole1 und ShortcutRole2 Rollen am Verknüpfungsspeicherort. InferredRole1 und InferredRole2 sind die entsprechenden abgeleiteten Rollen aus dem Abkürzungsziel. Jede Rolle wird aus ihren OLS-, RLS- und CLS-Komponenten gelöst, bevor OneLake die Rollen zusammenführt.

Einschränkungen von OneLake-Sicherheit

  • Wenn Sie ein B2B-Gastbenutzenden OneLake-Sicherheitsrollen zuweisen, müssen Sie Ihre externen Zusammenarbeitseinstellungen für B2B in Microsoft Entra External ID konfigurieren. Stellen Sie die Einstellung Gastbenutzerzugriff auf Gastbenutzer haben denselben Zugriff wie Mitglieder (am inklusivsten) ein.

  • Wenn Sie einer Rolle in oneLake-Sicherheit eine Verteilerliste hinzufügen, kann der SQL-Analyseendpunkt die Mitglieder der Liste nicht auflösen, um den Zugriff zu erzwingen. Daher scheinen Benutzer beim Zugriff auf den SQL Analytics-Endpunkt keine Mitglieder der Rolle zu sein. Direct Lake bei SQL-semantischen Modellen unterliegt ebenfalls dieser Einschränkung.

  • Spark-Notebooks erfordern, dass die Umgebung 3,5 oder höher ist und Fabric Runtime 1.3 verwendet.

  • Lakehouses ohne Schema unterstützen keine Datenvorschau für RLS- und CLS-gesicherte Tabellen. Verwenden Sie schema-fähige Seehäuser mit OneLake-Sicherheit.

  • OneLake-Sicherheit funktioniert nicht mit Azure Data Share oder Purview Data Share. Weitere Informationen finden Sie unter Azure Data Share.

  • Die folgende Tabelle listet die Einschränkungen der OneLake-Sicherheitsrollen auf.

    Szenario Begrenzung
    Maximale Anzahl von OneLake-Sicherheitsrollen pro Fabric-Element 250 Rollen pro Element (siehe Hinweis)
    Maximale Anzahl von Mitgliedern pro OneLake-Sicherheitsrolle 500 Benutzende oder Benutzergruppen pro Rolle
    Maximale Anzahl von Berechtigungen pro OneLake-Sicherheitsrolle 500 Berechtigungen pro Rolle

    Hinweis

    Du kannst eine Erhöhung der Rollen pro Artikel auf 1.000 beantragen. Um eine Erhöhung anzufordern, wenden Sie sich an Azure Support.

Wartezeiten

Änderungen an Rollendefinitionen werden innerhalb von etwa 5 Minuten übernommen.

Bei Änderungen an einer Benutzergruppe in einer OneLake-Sicherheitsrolle, dauert es etwa eine Stunde bis OneLake die Berechtigungen der Rolle auf die aktualisierte Benutzergruppe anwendet. Einige Fabric-Engines verfügen über eine eigene Cacheebene, daher ist möglicherweise eine zusätzliche Stunde erforderlich, um den Zugriff in allen Systemen zu aktualisieren.

Verwandte Inhalte

  • Last updated on