OneLake-Sicherheit für SQL-Analyseendpunkte

Mit OneLake-Sicherheit erweitert Microsoft Fabric die Möglichkeiten von Organisationen, den Datenzugriff über Workloads hinweg zu verwalten und durchzusetzen. Dieses Sicherheitsframework bietet Administratoren mehr Flexibilität beim Konfigurieren von Berechtigungen. Administratoren können zwischen zentraler Governance über OneLake oder granularer SQL-basierter Steuerung innerhalb des SQL-Analyseendpunkts wählen.

Access Modi im SQL-Analyseendpunkt

Bei Verwendung des SQL-Analyseendpunkts bestimmt der ausgewählte Zugriffsmodus, wie Datensicherheit erzwungen wird. Fabric unterstützt zwei unterschiedliche access Modelle, die je nach Betrieblichen und Compliance-Anforderungen unterschiedliche Vorteile bieten:

• Benutzeridentitätsmodus: Erzwingt die Sicherheit mithilfe von OneLake-Rollen und -Richtlinien. In diesem Modus übergibt der SQL-Analyseendpunkt die Identität des angemeldeten Benutzers an OneLake, und der Lesezugriff wird vollständig von den in OneLake definierten Sicherheitsregeln gesteuert. BERECHTIGUNGEN auf SQL-Ebene für Nichtdatenobjekte (Ansichten, gespeicherte Prozeduren, Funktionen) werden unterstützt, wodurch eine konsistente Governance über Tools wie Power BI, Notizbücher und Lakehouse hinweg gewährleistet wird.

• Delegierter Identitätsmodus: Bietet vollzugriff über SQL. In diesem Modus stellt der SQL-Analyseendpunkt mithilfe der Identität des Arbeitsbereichs- oder Elementbesitzers eine Verbindung mit OneLake in Verbindung, und die Sicherheit unterliegt ausschließlich sql-Berechtigungen , die innerhalb der Datenbank definiert sind. Dieses Modell unterstützt herkömmliche Sicherheitsansätze wie GRANT, REVOKE, benutzerdefinierte Rollen, Row-Level Sicherheit und dynamische Datenmasken.

Jeder Modus unterstützt unterschiedliche Governancemodelle. Das Verständnis ihrer Auswirkungen ist für die Auswahl des richtigen Ansatzes in Ihrer Fabric-Umgebung unerlässlich.

Vergleich zwischen Zugriffsmodi

In der folgenden Tabelle wird verglichen, wie und wo Sie die Sicherheit im Benutzeridentitätsmodus im Vergleich zum delegierten Identitätsmodus festlegen, aufgeschlüsselt nach Objekttyp- und Datenzugriffsrichtlinien:

Benutzeridentitätsmodus in OneLake-Sicherheit

Im Benutzeridentitäts-Modus verwendet der SQL-Analyseendpunkt einen passthrough-Authentifizierungsmechanismus zum Erzwingen des Datenzugriffs. Wenn ein Benutzer eine Verbindung mit dem SQL-Analyseendpunkt herstellt, wird seine Entra-ID-Identität an OneLake übergeben, wodurch die Berechtigungsprüfung ausgeführt wird. Alle Lesevorgänge für Tabellen werden mithilfe der im OneLake Lakehouse definierten Sicherheitsregeln ausgewertet, nicht durch SQL-Ebene GRANT oder REVOKE -Anweisungen.

Mit diesem Modus können Sie die Sicherheit zentral verwalten und eine konsistente Durchsetzung über alle Fabric-Umgebungen hinweg sicherstellen, einschließlich Power BI, Notizbücher, Lakehouse- und SQL-Analyseendpunkt. Es wurde für Governance-Modelle entwickelt, bei denen der Zugriff einmal in OneLake definiert und überall automatisch beachtet werden sollte.

Im Benutzeridentitätsmodus:

• Der Zugriff auf Tabellen wird vollständig von der OneLake-Sicherheit gesteuert. SQL-Anweisungen GRANT/REVOKE für Tabellen werden ignoriert.

• RLS (Row-Level Security), CLS (Column-Level Security) und Object-Level Security sind alle in der OneLake-Umgebung definiert.

• SQL-Berechtigungen sind für Nichtdatenobjekte wie Ansichten, gespeicherte Prozeduren und Funktionen zulässig, wodurch Flexibilität beim Definieren von benutzerdefinierter Logik oder benutzerdefinierten Einstiegspunkten zu Daten ermöglicht wird.

• Schreibvorgänge werden am SQL-Analyseendpunkt nicht unterstützt. Alle Schreibvorgänge müssen über die Lakehouse-Seite im Fabric-Portal erfolgen und unterliegen arbeitsbereichsrollen (Administrator, Mitglied, Mitwirkender).

Weitere Informationen zum Berechtigungsmodell mit dem Identitätsmodus des Benutzers finden Sie im Datenzugriffssteuerungsmodell für OneLake-Sicherheit.

Sicherheitssynchronisierung zwischen OneLake- und SQL-Analyseendpunkt

Eine wichtige Komponente des Benutzeridentitätsmodus ist der Sicherheitssynchronisierungsdienst. Dieser Hintergrunddienst überwacht Änderungen, die an Sicherheitsrollen in OneLake vorgenommen wurden, und stellt sicher, dass diese Änderungen im SQL-Analyseendpunkt widerzuspiegeln sind.

Der Sicherheitssynchronisierungsdienst ist für Folgendes verantwortlich:

• Erkennen von Änderungen an OneLake-Rollen, einschließlich neuer Rollen, Updates, Benutzerzuweisungen und Änderungen an Tabellen.

• Übersetzen von OneLake-definierten Richtlinien (RLS, CLS, OLS) in gleichwertige SQL-kompatible Datenbankrollenstrukturen.

• Damit Verknüpfungsobjekte (Tabellen, die aus anderen Lakehouses stammen) ordnungsgemäß geprüft werden, werden die ursprünglichen OneLake-Sicherheitseinstellungen berücksichtigt, auch wenn remote darauf zugegriffen wird.

Diese Synchronisierung stellt sicher, dass OneLake-Sicherheitsdefinitionen autoritativ bleiben und die Notwendigkeit eines manuellen Eingriffs auf SQL-Ebene zum Replizieren des Sicherheitsverhaltens eliminiert. Da Sicherheit zentral erzwungen wird:

• Sie können RLS, CLS oder OLS nicht direkt mit T-SQL in diesem Modus definieren.

• Sie können sql-Berechtigungen weiterhin auf Ansichten, Funktionen und gespeicherte Prozeduren mithilfe GRANT oder EXECUTE Anweisungen anwenden.

Erneutes Zurücksetzen der Sicherheitssynchronisierung

Die Sicherheitssynchronisierung enthält einen Wiederholungs-Backoff-Mechanismus, um die Systemstabilität zu schützen und unnötigen Rechenverbrauch zu vermeiden:

• Wenn beim Anwenden von OneLake-Sicherheitsrollen auf den SQL Analytics-Endpunkt wiederholte Fehler auftreten, kann das System vorübergehend automatische Synchronisierungsversuche anhalten.

• Die Synchronisierung wird automatisch fortgesetzt, wenn eine vorhandene OneLake-Sicherheitsrolle geändert oder eine neue erstellt wird.

Sicherheitssynchronisierungsfehler und -lösung

Funktionsweise von Tastaturkürzeln mit Sicherheitssynchronisierung

OneLake-Sicherheit wird an der Quelle der Wahrheit erzwungen, sodass die Sicherheitssynchronisierung die Besitzverkettung für Tabellen und Ansichten mit Verknüpfungen deaktiviert. Dadurch wird sichergestellt, dass Quellsystemberechtigungen immer ausgewertet und berücksichtigt werden, auch für Abfragen aus einer anderen Datenbank.

Dies führt zu folgendem Ergebnis:

• Benutzer müssen über gültigen Zugriff auf both verfügen, sowohl die Verknüpfung source (aktueller Lakehouse oder SQL-Analyseendpunkt) and die destination, wo sich die Daten physisch befinden.

• Wenn der Benutzer auf beiden Seiten keine Berechtigung besitzt, schlagen Abfragen mit einem Zugriffsfehler fehl.

• Stellen Sie beim Entwerfen von Anwendungen oder Ansichten, die auf Verknüpfungen verweisen, sicher, dass Rollenzuweisungen auf beiden Enden der Verknüpfungsbeziehung ordnungsgemäß konfiguriert sind.

Dieser Entwurf bewahrt die Sicherheitsintegrität über die Grenzen des Lakehouse hinweg, führt jedoch Szenarien ein, in denen Zugriffsfehler auftreten können, wenn Lakehouse-übergreifende Rollen nicht abgestimmt sind.

Delegierter Modus in OneLake-Sicherheit

Im delegierten Identitätsmodus behält der SQL-Analyseendpunkt die Abwärtskompatibilität mit dem herkömmlichen SQL-Sicherheitsmodell bei. Sicherheit wird auf sql-Modulebene definiert und erzwungen, und OneLake-Sicherheitsrollen und Zugriffsrichtlinien werden nicht auf Tabellenebene übertragen. Alle Filter- und Zugriffssteuerungen – einschließlich Zugriff auf Schemas und Tabellen, Row-Level Security (RLS), Column-Level Security (CLS) und Dynamic Data Masking (DDM) – müssen mithilfe von SQL-Konstrukten (GRANT/REVOKE, Sicherheitsrichtlinien usw.) definiert werden.

Da OneLake-Sicherheitsrollen für den Endbenutzer nicht direkt erzwungen werden, gelten alle in OneLake definierten Sicherheitsregeln (z. B. regeln, die von Spark oder anderen Engines erzwungen werden, die durch OneLake gelesen werden) nicht , wenn dieselben Daten über den SQL-Analyseendpunkt abgefragt werden. Wählen Sie diesen Modus, wenn die Arbeitsauslastung von SQL-nativer Sicherheitssemantik abhängt oder wenn vorhandene T-SQL-Tools eine vollständige Kompatibilität erfordern.

Wenn ein Benutzer eine Verbindung mit dem SQL-Analyseendpunkt herstellt und eine Abfrage ausgibt:

• SQL überprüft die Abfrage anhand der berechtigungen, die auf der SQL-Ebene definiert sind.

• Wenn die Abfrage autorisiert wurde, fährt das System mit dem Zugriff auf Daten fort, die in OneLake gespeichert sind.

• Dieser Datenzugriff wird mithilfe der Identität des Lakehouse- oder SQL-Analyseendpunktbesitzers, auch als Elementkonto bezeichnet, und nicht mit dem angemeldeten Benutzer ausgeführt.

Der Elementbesitzer ist daher dafür verantwortlich, über ausreichende Berechtigungen in OneLake zum Lesen der zugrunde liegenden Dateien im Auftrag der Workload zu verfügen. Jede Fehlausrichtung zwischen SQL-Berechtigungen, die Endbenutzern gewährt werden, und dem OneLake-Zugriff des Elementbesitzers führt zu Abfragefehlern.

Dieser Modus unterstützt vorhandene T-SQL-Tools und -Methoden, die von DBAs oder Anwendungen verwendet werden, mit vollständiger Kompatibilität für SQL GRANT/REVOKE auf allen Objektebenen und SQL-definierten RLS, CLS und DDM.

Verhalten von Tastenkombinationen im Modus für Delegierung

Da der delegierte Modus mithilfe der Identität des Elementbesitzers eine Verbindung mit OneLake herstellt, funktionieren Verknüpfungen nur, wenn der Besitzer uneingeschränkten Zugriff auf die gesamte Quelltabelle hat. Wenn die Quelltabelle eine Sicherheitsregel auf OneLake-Ebene angewendet hat , z. B. Row-Level Security (RLS), Column-Level Security (CLS) – blockiert der SQL-Analyseendpunkt den Zugriff auf diese Verknüpfung.

Dies führt zu folgendem Ergebnis:

• Verknüpfungen, die auf Quelltabellen verweisen, funktionieren im delegierten Modus normal, wenn es keine Sicherheitsregeln auf Datenebene gibt.

• Verknüpfungen, die auf Quelltabellen mit RLS oder CLS in der OneLake-Sicherheit des Produzenten verweisen, sind im delegierten Modus über den SQL-Analyseendpunkt nicht zugänglich, selbst wenn der Endbenutzer über SQL-Berechtigungen für das Verknüpfungsobjekt verfügt.

• Um Verknüpfungen zu nutzen, deren Quelle Über OneLake-Sicherheitsrichtlinien verfügt, verwenden Sie den Benutzeridentitätsmodus am Verbraucherendpunkt, damit die Identität des Endbenutzers anhand der OneLake-Sicherheitsregeln der Quelle ausgewertet wird.

So ändern Sie den OneLake-access-Modus

Der Zugriffsmodus bestimmt, wie der Datenzugriff authentifiziert und erzwungen wird, wenn OneLake über den SQL-Analyseendpunkt abgefragt wird. Sie können mithilfe der folgenden Schritte zwischen dem Benutzeridentitätsmodus und dem delegierten Identitätsmodus wechseln:

1. Navigieren Sie zu Ihrem Fabric-Arbeitsbereich, und öffnen Sie Ihr Seehaus. Gehen Sie von der oberen rechten Ecke von Lakehouse zum SQL Analytics-Endpunkt über.

2. Wechseln Sie in der oberen Navigationsleiste zur Registerkarte "Sicherheit ", und wählen Sie einen der folgenden OneLake-Zugriffsmodi aus:

   • Benutzeridentität – Verwendet die Identität des angemeldeten Benutzers. Erzwingt OneLake-Rollen.

   • Delegierte Identität – Verwendet die Identität des Elementbesitzers. Erzwingt nur SQL-Berechtigungen.

3. Ein Popup wird gestartet, um Ihre Auswahl zu bestätigen. Wählen Sie "Ja " aus, um die Änderung zu bestätigen.

Überlegungen beim Wechseln zwischen Modi

Wechseln zum Benutzeridentitätsmodus

• SQL-RLS-, CLS- und Tabellenebenenberechtigungen werden ignoriert.

• OneLake-Rollen müssen für Benutzer konfiguriert werden, um den Zugriff aufrechtzuerhalten.

• Nur Benutzer mit Anzeigeberechtigungen oder freigegebenem schreibgeschütztem Zugriff unterliegen der OneLake-Sicherheit.

• Vorhandene SQL-Rollen werden gelöscht und können nicht wiederhergestellt werden.

Wechseln zum delegierten Identitätsmodus

• OneLake-Rollen und Sicherheitsrichtlinien werden nicht mehr angewendet.

• SQL-Rollen und Sicherheitsrichtlinien werden aktiv.

• Der Elementbesitzer muss über gültige OneLake-Zugang verfügen, oder alle Abfragen können fehlschlagen.

Bemerkungen

• SQL-Objekte erben keinen Besitz: Shortcuts funktionieren als Tabellen im SQL-Analyseendpunkt, weichen jedoch absichtlich von der standardmäßigen SQL-Besitzverkettung ab, um einheitliche Sicherheitsmaßnahmen aufrechtzuerhalten.

  • Regel ohne Vererbung: Abgeleitete SQL-Objekte (Ansichten, gespeicherte Prozeduren oder Funktionen) erben keine Berechtigungen vom Objektbesitzer.

  • Laufzeitüberprüfung: Berechtigungen werden zur Ausführungszeit anhand der Identität des Aufrufers überprüft, um sicherzustellen, dass SQL-Abstraktionen keine Richtlinien auf OneLake-Ebene umgehen können.

  • Security by design: Sicherheitsrichtlinien bleiben konsistent, unabhängig davon, ob auf Daten über SQL, Spark oder Power BI zugegriffen wird.

• Abhängigkeit auf der Kontrollebene (strikter Identitätsabgleich): Die OneLake-Sicherheit erfordert, dass die Identität, die Zugriff beim Produzenten erhalten hat, dieselbe Identität sein muss, die während der Zugriffsauswertung auf der Datenebene des Verbrauchers anerkannt wird. Das System überprüft den spezifischen Prinzipal, dem Zugriff am Ursprungsort gewährt wurde, und erweitert keine geschachtelte Gruppenmitgliedschaft oder schließt nicht auf effektiven Zugriff durch indirekte Mitgliedschaft.

  • Literale Prinzipal-Übereinstimmung: Der Zugriff wird anhand der genauen Objekt-ID bewertet, die vom Erzeuger gewährt wurde.

  • Keine geschachtelte/effektive Auflösung: Die geschachtelte Gruppenmitgliedschaft oder die indirekte Vererbung wird nicht als ausreichend zur Durchsetzung betrachtet. Sehen Sie sich den Hinweis im Benutzeridentitätsmodus der OneLake-Sicherheit für ein ausgearbeitetes Beispiel an.

• Verhalten der Berechtigungsauswertung: Die Berechtigungsauswertung variiert je nach Tabellentyp basierend auf dem aktuellen Erzwingungsmodell.

  • Verknüpfungstabellen: Der Zugriff kann verweigert werden, wenn die erforderlichen Autorisierungsbedingungen nicht erfüllt sind. Dies ist ein restriktives Durchsetzungsergebnis, keine rollenbasierte Verweigerungsfunktion in der OneLake-Sicherheit.

  • Allgemeine Regel: Wenn die Durchsetzung den Zugriff nicht eindeutig überprüfen kann, wendet das System das restriktivste Ergebnis an.

• Column-Level Security (CLS)-Design: CLS verwaltet eine strenge Erlaubnisliste mit Spalten.

  • Durch das Umbenennen oder Entfernen einer zulässigen Spalte wird die Sicherheitsregel ungültig. Obwohl die Regel im System verbleibt, bleibt sie inaktiv – und es wird der Zugriff auf die Ressource verweigert, bis die ursprüngliche Spaltenbenennung wiederhergestellt ist.

  • Synchronisierungsschutz: Wenn eine Richtlinie ungültig ist, wird die Metadatensynchronisierung entwurfsfähig blockiert, bis die Regel im OneLake-Sicherheitsbereich korrigiert wird.

  • Schemaüberprüfung: Das Umbenennen von Spalten ohne Aktualisierung von Sicherheitsrichtlinien löst UI-Fehler aus, die angeben, dass die Spalte "nicht vorhanden" ist, bis die Konfiguration synchronisiert wird.

• Rollenverteilung und -synchronisierung (SLA):

  • OneLake-Sicherheitssynchronisierung: Wenn sich eine OneLake-Sicherheitsrolle im Benutzeridentitätsmodus ändert, ist das Update nicht sofort. Normalerweise geht es schnell, aber es kann bis zu 5 Minuten dauern, bis die Synchronisation mit dem SQL-Analyseendpunkt erfolgt.

  • Automatische Präfixierung: OneLake-Sicherheitsrollen werden mit dem OLS_ Präfix an den SQL-Analyseendpunkt weitergegeben.

  • Synchronisierungspriorität: Der Sicherheitssynchronisierungsprozess aktualisiert regelmäßig den Status der OLS_ Rollen. Manuelle Änderungen an diesen Rollen werden nicht unterstützt und werden während des nächsten Synchronisierungszyklus überschrieben. Wenn keine Änderungen zur Synchronisierung vorhanden sind, überschreibt die Sicherheitssynchronisierung keine manuellen Änderungen.

• SQL-Sicherheit und Abkürzungen im Warehouse: Sicherheitsrichtlinien, die mithilfe von SQL-Konstrukten in einem Warehouse definiert sind, wie zum Beispiel Row-Level Security (RLS), Column-Level Security (CLS) oder Object-Level Security (OLS), werden nur innerhalb des SQL-Ausführungskontexts des Warehouses (TDS-Endpunkt) erzwungen.

Einschränkungen

• Gilt nur für Leser: Die OneLake-Sicherheit wird in erster Linie für Benutzer erzwungen, die über arbeitsbereichs- oder Elementzugriff auf Viewerebene auf Daten zugreifen. Benutzer mit umfassenderen Arbeitsbereichsrollen wie Administrator, Mitglied oder Mitwirkender behalten erhöhten Zugriff und sind nicht das primäre Ziel der OneLake-Sicherheitserzwingung.

  • Ausnahmen:

    • Verhalten bei Verweigerung von Verknüpfungen: Bei Tabellen mit Verknüpfungen kann die Durchsetzungsrichtlinie weiterhin in bestimmten Fällen den Zugriff für Administratoren, Mitglieder oder Mitwirkende verweigern.

    • Fälle von Sicherheitssynchronisierungsfehlern: Wenn die Sicherheitssynchronisierung für bestimmte Tabellen oder Rollen fehlschlägt und die Sicherheit nicht ordnungsgemäß angewendet wird, können Benutzer in den Rollen Administrator, Mitglied oder Mitwirkender, die Teil dieser betroffenen Rollen sind, auch einen eingeschränkten Zugriff erfahren.

    • RLS im Benutzeridentitätsmodus: Wenn Row-Level Sicherheit (RLS) im Benutzeridentitätsmodus konfiguriert ist, werden die definierten Sicherheitsregeln für alle Benutzer erzwungen, einschließlich derjenigen in Administrator-, Mitglieds- und Mitwirkendenrollen.

• Abhängigkeit der Sicherheitssynchronisierung: Im Benutzeridentitätsmodus werden OneLake-Sicherheitsrollen über den Sicherheitssynchronisierungsprozess mit dem SQL Analytics-Endpunkt synchronisiert. Bis die Synchronisierung abgeschlossen ist, kann SQL den Zugriff vorübergehend mithilfe des vorhandenen SQL-Berechtigungsstatus auswerten. Nach Abschluss der Synchronisierung spiegelt der SQL-Endpunkt die OneLake-Sicherheitskonfiguration wider.

• Grenzerkennung für Shortcut: Der SQL-Analyse-Endpunkt kann anfangs shortcutgestützte Tabellen mithilfe der standardmäßigen SQL-Objektsemantik auswerten. Nachdem die Sicherheitssynchronisierung erfolgt, werden OneLake-Sicherheitsrichtlinien angewendet, um sicherzustellen, dass die Zugriffserzwingung mit Artefakt- und Arbeitsbereichsgrenzen übereinstimmt.

• Zeitpunkt der Erzwingung für artefaktübergreifenden Zugriff: Der Zugriff auf Tabellen, die durch OneLake-Verknüpfungen gestützt sind, die auf Daten aus anderen Artefakten verweisen, wird über synchronisierte OneLake-Sicherheitsrollen erzwungen. Bis zur Synchronisierung kann die SQL-Autorisierung vorübergehend den vorherigen Berechtigungsstatus widerspiegeln.

• Besitzeränderungen in Verknüpfungstabellen: Verknüpfungsbasierte Tabellen werden als SQL-Objekte im SQL-Analyseendpunkt dargestellt und unterstützen daher standardmäßige SQL-Besitzvorgänge. Administrative Befehle, z. B. ALTER AUTHORIZATION, können den Besitzer einer verknüpften Tabelle ändern. In bestimmten Szenarien kann dies das Verhalten der Besitzkette ermöglichen, das OneLake-Sicherheitsrichtlinien umgeht und unbeabsichtigten Zugriff auf die zugrunde liegenden Daten gewährt. Bis zusätzliche Erzwingungsmechanismen eingeführt werden, sollten Administratoren das Ändern des Besitzes bei tabellengestützten Verknüpfungen vermeiden.

• Ausfallzeit der Zielüberprüfung: Wenn sich ein Verknüpfungsziel ändert (z. B. Umbenennen oder URL-Update), wechselt die Datenbank kurz in den Einzelbenutzermodus , während das System das neue Ziel überprüft. Während dieses Zeitraums werden Abfragen blockiert. Diese Vorgänge sind in der Regel schnell, können jedoch je nach internen Prozessen bis zu 5 Minuten dauern, bis sie synchronisiert werden.

  • Das Erstellen von Schemaverknüpfungen kann einen bekannten Fehler verursachen, der sich auf die Überprüfung auswirkt und die Metadatensynchronisierung verzögert.

• Token-Zwischenspeicherung im delegierten Modus: Im delegierten Modus speichert der SQL Analytics-Endpunkt im Auftrag der Besitzeridentität das Speicherzugriffstoken zwischen, das zum Abrufen von Daten aus OneLake verwendet wird. Wenn sich die Berechtigungen des Besitzers ändern, kann ein zuvor ausgestelltes Token bis zum Ablauf gültig bleiben. Daher werden Zugriffsänderungen, die an die Besitzeridentität gebunden sind, möglicherweise nicht sofort wirksam und können bis zum Ablauf des Tokens beibehalten werden, in der Regel bis zu 30 bis 60 Minuten.

• Änderungen an OneLake Security GRANT/DENY-Richtlinien werden sofort erzwungen und werden nicht durch das Zwischenspeichern von Speichertoken verzögert.

• Abbruch aktiver Abfragen: Um die Datenintegrität und -sicherheit aufrechtzuerhalten, werden aktive Abfragen möglicherweise automatisch abgebrochen, wenn sich eine Verknüpfungskonfiguration während der Ausführung ändert.

• Row-Level Sicherheitseinschränkungen (RLS):

  • Für die öffentliche Vorschau werden nur Tabellen mit einem einzigen Ausdruck unterstützt. Dynamische RLS und Mehrtabellen-RLS sind nicht verfügbar.

  • Das Entfernen einer Spalte, die in einem Filterausdruck verwendet wird, verzögert die Metadatensynchronisation, bis das RLS im OneLake-Sicherheitspanel behoben wurde.

• Rollenkomplexität und Metadatensynchronisierung: Hohe Komplexität in Sicherheitsrollen – insbesondere bei zahlreichen Schnittmengen und Union-Semantik mit RLS – kann dazu führen, dass die Sicherheitssynchronisierung fehlschlägt. Eine fehlgeschlagene Sicherheitssynchronisierung verhindert, dass Sicherheitsrichtlinien angewendet werden, und blockiert die Möglichkeit, Metadaten zu synchronisieren.

• Schema- und Rolleneinschränkungen:

  • Umbenennen: OneLake-Sicherheitsrollen sind an den Tabellennamen gebunden. Durch das Umbenennen einer Tabelle wird die Zuordnung unterbrochen, und Richtlinien werden nicht automatisch migriert. Dies kann zu unbeabsichtigter Datenexposition führen, bis Richtlinien erneut angewendet werden.

  • Zeichenbeschränkungen: OneLake-Sicherheitsrollennamen dürfen 124 Zeichen nicht überschreiten; andernfalls schlägt die Rollenerstellung oder -synchronisierung auf dem SQL-Analyseendpunkt fehl.

  • OLS_ Rollenänderungen: Benutzeränderungen für OLS_ Rollen werden nicht unterstützt und können zu unerwarteten Verhaltensweisen führen.

• Nicht unterstützte Identitäten: E-Mail-aktivierte Sicherheitsgruppen und Verteilerlisten werden derzeit nicht unterstützt.

• Anforderungen des Lakehouse-Eigentümers:

  • Der Besitzer des Seehauses muss Mitglied der Arbeitsbereichsrollen "Administrator", "Mitglied" oder "Mitwirkender" sein. andernfalls wird die Sicherheit nicht auf den SQL-Analyseendpunkt angewendet.

  • Der Besitzer des Seehauses kann kein Dienstprinzipal sein, damit die Sicherheitssynchronisierung funktioniert.

Verwandte Inhalte

• Bewährte Methoden zum Sichern von Daten in OneLake
• OneLake-Sicherheitszugriffskontrollmodell