OneLake-Sicherheit für SQL-Analyseendpunkte

Durch die Nutzung von OneLake-Sicherheit können Administratoren zwischen zentraler Verwaltung über OneLake oder granulärer SQL-basierter Steuerung innerhalb des SQL-Analyse-Endpunkts 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: Gewährleistet Sicherheit durch die Verwendung 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. Dieser Modus unterstützt SQL-Berechtigungen für Nicht-Datenobjekte wie Ansichten, gespeicherte Prozeduren und Funktionen und gewährleistet so eine konsistente Verwaltung über Werkzeuge wie Power BI, Notebooks und Lakehouse.

• Delegierter Identitätsmodus: Bietet vollzugriff über SQL. In diesem Modus verbindet sich der SQL-Analytics-Endpunkt mit OneLake, indem er die Identität des Arbeitsbereichs- oder Item-Besitzers verwendet, und die Sicherheit wird ausschließlich durch SQL-Berechtigungen in der Datenbank festgelegt. Dieses Modell unterstützt traditionelle Sicherheitsansätze, darunter GRANT, REVOKE, benutzerdefinierte Rollen, Zeilensicherheit und Dynamic Data Masking.

Jeder Modus unterstützt unterschiedliche Governancemodelle. Verstehen Sie deren Auswirkungen, damit Sie den richtigen Ansatz für Ihr Fabric-Umfeld wählen können.

Von Bedeutung

Der Item-Zugriff ist erforderlich, um den SQL-Analytics-Endpunkt zu nutzen. Um sich mit einem SQL-Analytics-Endpunkt zu verbinden und Daten abzufragen, müssen Benutzer die Leseberechtigung für das mit dem Endpunkt verbundene Element haben. Wenn ein Benutzer keinen Zugriff auf die Steuerungsebene für das Element hat (zum Beispiel Zugriff über eine Arbeitsbereichsrolle oder eine explizite Elementberechtigung), wird die Verbindung mit dem SQL-Analytics-Endpunkt abgelehnt, ungeachtet aller SQL-Berechtigungen, die diesem Benutzer möglicherweise erteilt wurden.

Vergleichen von 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:

Sicherheitsziel	Benutzeridentitätsmodus	Delegierter Identitätsmodus
Tables	OneLake-Sicherheitsrollen kontrollieren den Zugriff. SQL GRANT/REVOKE ist nicht zulässig.	Vollzugriff mit SQL GRANT/REVOKE.
Views	Verwenden Sie SQL GRANT/REVOKE , um Berechtigungen zuzuweisen.	Verwenden Sie SQL GRANT/REVOKE , um Berechtigungen zuzuweisen.
Gespeicherten Prozeduren	Verwenden Sie SQL GRANT EXECUTE , um Berechtigungen zuzuweisen.	Verwenden Sie SQL GRANT EXECUTE , um Berechtigungen zuzuweisen.
Funktionen	Verwenden Sie SQL GRANT EXECUTE , um Berechtigungen zuzuweisen.	Verwenden Sie SQL GRANT EXECUTE , um Berechtigungen zuzuweisen.
Sicherheit auf Zeilenebene (RLS)	Definiert als Teil der Sicherheitsrollen von OneLake.	Definiert mithilfe von SQL CREATE SECURITY POLICY.
Sicherheit auf Spaltenebene (CLS)	Definiert als Teil der Sicherheitsrollen von OneLake.	Definiert mithilfe von SQL GRANT SELECT mit Spaltenliste.
Dynamische Datenformatierung (Dynamic Data Masking, DDM)	Nicht in der OneLake-Sicherheit unterstützt.	Definiert mithilfe von SQL ALTER TABLE mit MASKED Option.

Ändern Sie den OneLake-Zugangsmodus

Der Zugriffsmodus bestimmt, wie der Datenzugriff authentifiziert und erzwungen wird, wenn OneLake über den SQL-Analyseendpunkt abgefragt wird. Neu erstellte SQL-Analytics-Endpunkte starten standardmäßig im Delegierten-Identitätszugriffsmodus. Bevor Sie OneLake-Sicherheit mit einem Endpunkt nutzen können, muss ein Administrator oder Mitglied diesen in den Benutzer-Identitätszugriffsmodus wechseln.

Hinweis

Um OneLake-Sicherheit zu nutzen, müssen Sie pro SQL-Analyse-Endpunkt nur einmal in den Benutzer-Identitätszugriffsmodus wechseln. Endpunkte, die Sie nicht in den Benutzer-Identitätszugriffsmodus wechseln, verwenden weiterhin eine delegierte Identität, um die Berechtigungen zu bewerten.

1. Gehe zum SQL-Analytics-Endpunkt.

2. Wählen Sie in der SQL Analytics-Endpunktoberfläche die Registerkarte "Sicherheit " aus.

3. Wählen Sie Datenzugriffsmodus anzeigen>Einstellungen für den Datenzugriffsmodus aus.

   

4. Wählen Sie den Identitätszugriffsmodus des Benutzers , um die angemeldete Identität des angemeldeten Benutzers zu verwenden und OneLake-Sicherheitsrollen durchzusetzen, oder wählen Sie den Modus Delegierte Identitätszugriff , um die Identität des Item-Besitzers zu verwenden und nur SQL-Berechtigungen zu erwirken. Wählen Sie dann Anwenden aus.

   

5. Wählen Sie "Weiter" aus, um Ihre Auswahl zu bestätigen.

Von Bedeutung

Die Änderung des Sicherheitsmodus macht SQL-Analytics-Endpunkte vorübergehend im gesamten Arbeitsbereich unverfügbar. Diese Aktion bricht alle ausgeführten und in die Warteschlange gestellten Abfragen an allen SQL-Analyseendpunkten in diesem Arbeitsbereich ab. Ändern Sie Modi nur bei Bedarf und vorzugsweise außerhalb der Geschäftszeiten, um Ausfallzeiten zu vermeiden.

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.

• Die OneLake-Erfahrung definiert RLS (Zeilensicherheit), CLS (Spaltensicherheit) und Objektsicherheit.

• 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).

Von Bedeutung

1:1-Identitätszuordnung zwischen Produzenten und Verbrauchern (Hub-and-Spoke). Wenn OneLake-Sicherheitsrichtlinien von einem Produzenten (dem Quellobjekt, in dem die Rolle definiert ist) an einen Verbraucher übertragen werden (ein Zielobjekt, das über eine Verknüpfung auf die Daten zugreift), müssen die Identitäten, die OneLake-Sicherheitsrollen am Produzenten zugewiesen sind, genau 1:1 für den Verbraucher zugeordnet werden. Demselben Sicherheitsprinzipal – also entweder einem Benutzer oder einer Gruppe – muss für das Consumerartefakt die Fabric-Leseberechtigung gewährt werden wie demjenigen, auf den in der Sicherheitsrolle des Produzenten verwiesen wird. Geschachtelte oder effektive Gruppenmitgliedschaften werden über diese Grenze nicht aufgelöst.

Wenn beispielsweise die OneLake-Sicherheitsrolle beim Produzenten auf user123@microsoft.com verweist, muss user123@microsoft.com (genau diese Objekt-ID) ebenfalls Fabric-Leseberechtigung für das Verbraucher-Lakehouse besitzen. Ebenso gilt: Wenn die Produzentenrolle auf Group A verweist, dann muss Group A selbst die Fabric-Read-Berechtigung für den Consumer erhalten – nur einem Mitglied der Gruppe A diese Berechtigung zu erteilen, erfüllt die Übereinstimmung nicht.

Weitere Informationen zum Berechtigungsmodell im Benutzeridentitätsmodus finden Sie unter Wie die OneLake-Sicherheit den Datenzugriff kontrolliert.

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

Scenario	Verhalten im Benutzeridentitätsmodus	Verhalten im delegierten Modus	Korrekturmaßnahme	Hinweise
RLS-Richtlinie verweist auf eine gelöschte oder umbenannte Spalte	Fehler: Die Sicherheitsrichtlinie auf Zeilenebene verweist auf eine Spalte, die nicht mehr vorhanden ist. Die Datenbank gibt den Fehlerstatus ein, bis die Richtlinie behoben ist.	Fehler: Ungültiger Spaltenname <>	Aktualisieren oder Entfernen einer oder mehrerer betroffener Rollen oder Wiederherstellen der fehlenden Spalte.	Das Update muss im Lakehouse vorgenommen werden, in dem die Rolle erstellt worden ist.
CLS-Richtlinie verweist auf eine gelöschte oder umbenannte Spalte	Fehler: Die Sicherheitsrichtlinie auf Spaltenebene verweist auf eine Spalte, die nicht mehr vorhanden ist. Die Datenbank gibt den Fehlerstatus ein, bis die Richtlinie behoben ist.	Fehler: Ungültiger Spaltenname <>	Aktualisieren oder Entfernen einer oder mehrerer betroffener Rollen oder Wiederherstellen der fehlenden Spalte.	Das Update muss im Lakehouse vorgenommen werden, in dem die Rolle erstellt worden ist.
RLS/CLS-Richtlinie verweist auf eine gelöschte oder umbenannte Tabelle	Fehler: Die Sicherheitsrichtlinie verweist auf eine Tabelle, die nicht mehr vorhanden ist.	Es wurde kein Fehler angezeigt; Abfrage schlägt im Hintergrund fehl, wenn die Tabelle fehlt.	Aktualisieren oder Entfernen einer oder mehrerer betroffener Rollen oder Wiederherstellen der fehlenden Tabelle.	Das Update muss im Lakehouse vorgenommen werden, in dem die Rolle erstellt worden ist.
DDM-Richtlinie (Dynamic Data Masking) verweist auf eine gelöschte oder umbenannte Spalte	DDM wird von OneLake-Sicherheit nicht unterstützt; muss über SQL implementiert werden.	Fehler: Ungültiger Spaltenname <>	Aktualisieren oder entfernen Sie eine oder mehrere betroffene DDM-Regeln, oder stellen Sie die fehlende Spalte wieder her.	Aktualisieren Sie die DDM-Richtlinie im SQL-Analyseendpunkt.
Systemfehler (unerwarteter Fehler)	Fehler: Unerwarteter Systemfehler. Versuchen Sie es erneut, oder wenden Sie sich an den Support.	Fehler: Beim Anwenden von Tabellenänderungen auf SQL ist ein interner Fehler aufgetreten.	Wiederholen Sie den Vorgang; Wenn das Problem weiterhin besteht, wenden Sie sich an Microsoft-Support.	N/A
Der Benutzerprinzipal wird nicht unterstützt.	Fehler: User Principal wird von dem System nicht unterstützt.	Fehler: User Principal wird von dem System nicht unterstützt.	Benutzer {username} aus Rolle DefaultReaderentfernen .	Dieser Fehler tritt auf, wenn der Benutzer keine gültige Entra-ID mehr ist (z. B. der Benutzer hat die Organisation verlassen oder wurde gelöscht). Entfernen Sie sie aus der Rolle, um den Fehler zu beheben.

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.

Dieses Design wahrt die Sicherheitsintegrität über Lakehouse-Grenzen hinweg und reduziert die Notwendigkeit, Identitätszuweisungen über Produzenten- und Verbraucherelemente hinweg zu duplizieren.

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. Man definiert und setzt Sicherheit auf der SQL-Engine-Ebene durch, und OneLake-Sicherheitsrollen sowie Zugriffsrichtlinien werden nicht auf Tabellenzugriff übertragen. Sie müssen alle Filter- und Zugriffskontrollen definieren – einschließlich Zugriff auf Schemata und Tabellen, Zeilensicherheit (RLS), Spaltensicherheit (CLS) und Dynamic Data Masking (DDM) – mithilfe von SQL-Konstrukten (GRANT/REVOKE, Sicherheitsrichtlinien usw.).

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 über die Identität des Item-Besitzers mit OneLake verbunden ist, funktionieren Shortcuts nur, wenn der Besitzer uneingeschränkten Zugriff auf die gesamte Quelltabelle hat. Wenn in der Quelltabelle eine OneLake-Sicherheitsregel angewendet wird – wie z. B. Zeilensicherheit (RLS) oder Spaltensicherheit (CLS) – blockiert der SQL-Analytics-Endpunkt 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.

Überlegungen beim Wechseln zwischen Modi

Von Bedeutung

Der Wechsel zwischen Benutzeridentität und delegierten Modi (in beiden Richtungen) entfernt derzeit Inlinemetadatenobjekte, einschließlich Tabellenwertfunktionen (TVFs) und skalarwertigen Funktionen. Dieses Verhalten wirkt sich nur auf Metadatendefinitionen aus. Zugrunde liegende Daten in OneLake sind nicht betroffen.

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.

• Abhängigkeit von Kontrollebene und effektive Identitätsbewertung: Benutzer müssen die erforderliche Fabric-Artefaktberechtigung haben, bevor sie sich mit dem SQL-Analyse-Endpunkt verbinden können. Die Datenautorisierung bewertet dann den angemeldeten Benutzer und dessen effektive Mitgliedschaft in unterstützten Microsoft Entra-Gruppen anhand der OneLake-Sicherheitsrichtlinien an der Quelle.

• 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.

• Entwurf der Sicherheit auf Spaltenebene (CLS): CLS verwaltet eine strikte Liste zulässiger 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.

  Hinweis

  Im SQL-Analyseendpunkt gilt die OneLake-Sicherheit für den Datenzugriff, während die Schemametadaten weiterhin dem Verhalten der SQL-Engine folgen. Nutzer könnten Spalten im Objekt-Explorer sehen oder sys.columns sogar wenn die Sicherheit auf Spaltenebene ihnen das Lesen dieser Spalten verbietet. Dieses Verhalten wird erwartet und beabsichtigt.

• 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.

• Warehouse-SQL-Sicherheit und Abkürzungen: Sicherheitsrichtlinien, die mit SQL-Konstrukten in einem Warehouse definiert werden – wie Zeilensicherheit (RLS), Spaltensicherheit (CLS) oder Objektsicherheit (OLS) – werden nur im SQL-Ausführungskontext des Lagers (TDS-Endpunkt) durchgesetzt.

Von Bedeutung

Wenn Sie Daten aus einem Warehouse über Shortcuts in OneLake abrufen, werden diese SQL-Sicherheitssemantiken nicht in OneLake-Sicherheitsrichtlinien übersetzt. Daher könnten Nutzer, die über eine Verknüpfung auf die Daten zugreifen, die vollständigen Warehouse-Daten sehen, unabhängig davon, welche SQL-Sicherheitsrichtlinien im Produzentenlager konfiguriert sind.

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 die Zeilenebenen-Sicherheit (RLS) im Benutzeridentitätsmodus konfiguriert ist, werden die definierten Sicherheitsregeln für alle Benutzer durchgesetzt, einschließlich der Rollen Admin, Mitglied und Mitwirkender.

• Schemasichtbarkeit in Objektmetadaten: Der SQL Analytics-Endpunkt gibt immer alle Schemanamen in Objektmetadaten zurück, unabhängig von den Berechtigungen auf Tabellenebene des Benutzers. Tabellen, für die der Benutzer keine Berechtigung besitzt, werden herausgefiltert und nicht in der Auflistung angezeigt.

  • Daher werden Benutzern möglicherweise Schemas angezeigt, die keine sichtbaren Tabellen im Objekt-Explorer oder in INFORMATION_SCHEMA/sys Katalogabfragen enthalten.

• Sicherheitssynchronisationsabhängigkeit: Im Benutzeridentitätsmodus synchronisiert der Sicherheitssynchronisationsprozess OneLake-Sicherheitsrollen mit dem SQL-Analytics-Endpunkt. Bis die Synchronisation abgeschlossen ist, kann SQL den Zugriff vorübergehend evaluieren, indem es den bestehenden SQL-Rechtestatus für alle Tabellen verwendet, einschließlich Shortcut-Tabellen von anderen Elementen. Nach Abschluss der Synchronisierung spiegelt der SQL-Endpunkt die OneLake-Sicherheitskonfiguration wider.

• 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.

• Sicherheitsbeschränkungen auf Zeilenebene (RLS):

  • Es werden nur Tabellen mit einem einzigen Ausdruck unterstützt. Dynamische RLS und RLS mit mehreren Tabellen 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.

Verwandte Inhalte

• Bewährte Methoden zum Sichern von Daten in OneLake
• Wie die Sicherheit von OneLake den Datenzugriff kontrolliert