OneLake-Sicherheit für SQL-Analyseendpunkte (Vorschau)

Mit OneLake-Sicherheit erweitert Microsoft Fabric, wie Organisationen den Datenzugriff über Workloads hinweg verwalten und erzwingen können. Dieses neue Sicherheitsframework bietet Administratoren mehr Flexibilität beim Konfigurieren von Berechtigungen. Administratoren können zwischen zentraler Governance über OneLake oder eine präzise SQL-basierte Steuerung innerhalb des SQL-Analyseendpunkts wählen.

Zugriffsmodi im SQL-Analyseendpunkt

Bei Verwendung des SQL-Analyseendpunkts bestimmt der ausgewählte Zugriffsmodus, wie die Datensicherheit erzwungen wird. Fabric unterstützt zwei unterschiedliche Zugriffsmodelle, 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. SQL-Ebenenberechtigungen für Tabellen werden unterstützt, wodurch eine konsistente Governance über Tools wie Power BI, Notizbücher und Lakehouse hinweg sichergestellt 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

Hier ist eine klare und präzise Vergleichstabelle, die sich darauf konzentriert, 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ätsmodus verwendet der SQL-Analyseendpunkt einen Passthrough-Authentifizierungsmechanismus , um den Datenzugriff zu erzwingen. 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 GRANT- oder REVOKE-Anweisungen auf SQL-Ebene.

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 Governancemodelle entwickelt, bei denen der Zugriff einmal in OneLake definiert und überall automatisch beachtet werden sollte.

Im Benutzeridentitätsmodus:

• Der Tabellenzugriff unterliegt vollständig der OneLake-Sicherheit. SQL GRANT/REVOKE-Anweisungen 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-Benutzeroberfläche erfolgen und unterliegen arbeitsbereichsrollen (Administrator, Mitglied, Mitwirkender).

Verhalten der Arbeitsbereichsrolle

Benutzer mit der Rolle "Administrator", "Mitglied" oder "Mitwirkender" auf Arbeitsbereichsebene unterliegen nicht der OneLake-Sicherheitserzwingung. Diese Rollen verfügen über erhöhte Berechtigungen und umgehen RLS-, CLS- und OLS-Richtlinien vollständig. Befolgen Sie die folgenden Anforderungen, um sicherzustellen, dass oneLake-Sicherheit eingehalten wird:

• Zuweisen der Benutzerrolle " Viewer" im Arbeitsbereich oder

• Geben Sie den Lakehouse- oder SQL-Analyseendpunkt für Benutzer mit schreibgeschützten Berechtigungen frei. Nur Benutzer mit schreibgeschütztem Zugriff haben ihre Abfragen nach OneLake-Sicherheitsrollen gefiltert.

Rollenrangfolge: Die meisten zulässigen Zugriffsgewinne

Wenn ein Benutzer zu mehreren OneLake-Rollen gehört, definiert die zulässigste Rolle ihren effektiven Zugriff. Beispiel:

• Wenn eine Rolle vollzugriff auf eine Tabelle gewährt und eine andere RLS zum Einschränken von Zeilen anwendet, wird der RLS nicht erzwungen.

• Die umfassendere Zugriffsrolle hat Vorrang. Dieses Verhalten stellt sicher, dass Benutzer nicht unbeabsichtigt blockiert werden, aber es erfordert ein sorgfältiges Rollendesign, um Konflikte zu vermeiden. Es wird empfohlen, restriktive und zulässige Rollen beim Erzwingen von Zugriffssteuerungen auf Zeilen- oder Spaltenebene gegenseitig ausschließen zu lassen.

Weitere Informationen 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.

• Die Sicherstellung von Verknüpfungsobjekten (Tabellen, die aus anderen Seehäusern stammen) werden ordnungsgemäß überprüft, sodass die ursprünglichen OneLake-Sicherheitseinstellungen berücksichtigt werden, 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 weiterhin SQL-Berechtigungen auf Ansichten, Funktionen und gespeicherte Prozeduren mithilfe von GRANT- oder EXECUTE-Anweisungen anwenden.

Sicherheitssynchronisierungsfehler und -auflösung

Verhalten von Tastenkombinationen 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 einen gültigen Zugriff auf die Verknüpfungsquelle (aktueller Lakehouse- oder SQL-Analyseendpunkt) und das Ziel verfügen, an dem sich die Daten physisch befinden.

• Wenn der Benutzer auf beiden Seiten keine Berechtigung hat, schlägt bei Abfragen ein Zugriffsfehler fehl.

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

Dieses Design behält die Sicherheitsintegrität über Lakehouse-Grenzen hinweg bei, führt jedoch Szenarien ein, in denen Zugriffsfehler auftreten können, wenn cross-Lakehouse-Rollen nicht ausgerichtet sind.

Delegierter Modus in OneLake-Sicherheit

Im delegierten Identitätsmodus verwendet der SQL-Analyseendpunkt dasselbe Sicherheitsmodell, das heute in Microsoft Fabric vorhanden ist. Sicherheit und Berechtigungen werden vollständig auf sql-Ebene verwaltet, und OneLake-Rollen oder Zugriffsrichtlinien werden für den Zugriff auf Tabellenebene nicht erzwungen. Wenn ein Benutzer eine Verbindung mit dem SQL-Analyseendpunkt herstellt und eine Abfrage ausgibt:

• SQL überprüft den Zugriff basierend auf SQL-Berechtigungen (GRANT, REVOKE, RLS, CLS, DDM, Rollen usw.).

• Wenn die Abfrage autorisiert ist, greift das System auf in OneLake gespeicherte Daten zu.

• Dieser Datenzugriff wird mithilfe der Identität des Lakehouse- oder SQL-Analyseendpunktbesitzers ausgeführt – auch als Elementkonto bezeichnet.

In diesem Modell:

• Der angemeldete Benutzer wird nicht an OneLake übergeben.

• Es wird davon ausgegangen, dass alle Erzwingung des Zugriffs auf der SQL-Ebene behandelt wird.

• Der Elementbesitzer ist dafür verantwortlich, in OneLake über ausreichende Berechtigungen zum Lesen der zugrunde liegenden Dateien im Auftrag der Workload zu verfügen.

Da es sich um ein delegiertes Muster handelt, führt jede Fehlausrichtung zwischen SQL-Berechtigungen und OneLake-Zugriff für den Besitzer zu Abfragefehlern. Dieser Modus bietet vollständige Kompatibilität mit:

• SQL GRANT/REVOKE auf allen Objektebenen

• SQL-definierte Row-Level Sicherheit, Column-Level Sicherheit und dynamische Datenmaske

• Vorhandene T-SQL-Tools und -Methoden, die von DBAs oder Anwendungen verwendet werden

So ändern Sie den OneLake-Zugriffsmodus

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. Wechseln Sie von der oberen rechten Ecke von Lakehouse zu SQL Analytics-Endpunkt.

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. Er 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 einen gültigen OneLake-Zugriff verfügen, oder alle Abfragen können fehlschlagen.

Einschränkungen

• Gilt nur für Leser: OneLake Security steuert Benutzer, die als Viewer auf Daten zugreifen. Benutzer in anderen Arbeitsbereichsrollen (Administratormitglied oder Mitwirkender) umgehen OneLake Security und behalten vollzugriff.

• SQL-Objekte erben keinen Besitz: Verknüpfungen werden als Tabellen im SQL-Analyseendpunkt angezeigt. Beim Zugriff auf diese Tabellen, direkt oder über Ansichten, gespeicherte Prozeduren und andere abgeleitete SQL-Objekte tragen keinen Besitz auf Objektebene; Alle Berechtigungen werden zur Laufzeit überprüft, um die Sicherheitsumgehung zu verhindern.

• Verknüpfungsänderungen lösen ausfallzeiten aus: Wenn sich ein Verknüpfungsziel ändert (z. B. Umbenennen, 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 relativ schnell, aber manchmal kann es je nach unterschiedlichem internen Prozess bis zu 5 Minuten dauern, bis die Synchronisierung erfolgt.

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

• Verzögerte Berechtigungsverteilung: Berechtigungsänderungen werden nicht instanziiert. Das Wechseln zwischen Sicherheitsmodi (Benutzeridentität im Vergleich zu delegierten) erfordert möglicherweise Zeit, bevor sie wirksam wird, sollte jedoch weniger als 1 Minute dauern.

• Abhängigkeit von Steuerelementebenen: Berechtigungen können nicht auf Benutzer oder Gruppen angewendet werden, die noch nicht in der Arbeitsbereichssteuerungsebene vorhanden sind. Sie müssen entweder das Quellelement freigeben, oder der Benutzer muss Mitglied der Rolle des Viewer-Arbeitsbereichs sein. Beachten Sie, dass sich die gleiche Objekt-ID an beiden Stellen befinden muss. Eine Gruppe und ein Mitglied dieser Gruppe zählen nicht als Match.

• Der am meisten eingeschränkte Zugriff hat Vorrang: Wenn Benutzer zu mehreren Gruppen oder Rollen gehören, wird die zulässigste effektive Berechtigung berücksichtigt Beispiel: Wenn ein Benutzer sowohl denY über eine Rolle als auch GRANT durch eine andere verfügt, hat die GRANT Vorrang.

• Einschränkungen des delegierten Modus: Im delegierten Modus kann die Metadatensynchronisierung in Verknüpfungstabellen fehlschlagen, wenn das Quellelement Über OneLake-Sicherheitsrichtlinien verfügt, die dem Elementbesitzer keinen vollständigen Tabellenzugriff gewähren.

• Verweigerungsverhalten: Wenn mehrere Rollen auf eine einzelne Verknüpfungstabelle angewendet werden, folgt die Schnittmenge der Berechtigungen der SQL Server-Semantik: DENY überschreibt GRANT. Dies kann zu unerwarteten Zugriffsergebnissen führen.

• Erwartete Fehlerbedingungen: Benutzer können fehler in Szenarien wie:

  • Verknüpfungsziel umbenannt oder ungültig

    • Beispiel: Wenn die Quelle der Tabelle gelöscht wurde.

  • RLS (Row-Level Sicherheit) fehlkonfiguriert

    • Einige Ausdrücke für die RLS-Filterung werden in OneLake nicht unterstützt und ermöglichen möglicherweise nicht autorisierten Datenzugriff.

    • Durch das Ablegen der spalte, die für den Filterausdruck verwendet wird, wird die RLS- und Metadatensynchronisierung veraltet, bis der RLS im OneLake-Sicherheitsbereich behoben ist.

    • Für die öffentliche Vorschau unterstützen wir nur einzelne Ausdruckstabellen. Dynamische RLS und Mehrtabellen-RLS werden derzeit nicht unterstützt.

  • Column-Level Sicherheitsbeschränkungen (CLS)

    • CLS funktioniert, indem eine Zulassungsliste von Spalten beibehalten wird. Wenn eine zulässige Spalte entfernt oder umbenannt wird, wird die CLS-Richtlinie ungültig.

    • Wenn CLS ungültig ist, wird die Metadatensynchronisierung blockiert, bis die CLS-Regel im OneLake-Sicherheitsbereich behoben ist.

  • Fehler bei der Metadaten- oder Berechtigungssynchronisierung

    • Wenn Änderungen an der Tabelle vorhanden sind, z. B. das Umbenennen einer Spalte, wird die Sicherheit für das neue Objekt nicht repliziert, und Sie erhalten UI-Fehler, die zeigen, dass die Spalte nicht vorhanden ist.

• Tabellenbenennungen behalten keine Sicherheitsrichtlinien bei: Wenn OneLake Security (OLS)-Rollen auf Schemaebene definiert sind, bleiben diese Rollen nur wirksam, solange der Tabellenname unverändert ist. Durch das Umbenennen der Tabelle wird die Zuordnung unterbrochen, und Sicherheitsrichtlinien werden nicht automatisch migriert. Dies kann zu unbeabsichtigter Datenexposition führen, bis Richtlinien erneut angewendet werden.

• OneLake-Sicherheitsrollen dürfen keine Namen mehr als 124 Zeichen enthalten. andernfalls kann die Sicherheitssynchronisierung die Rollen nicht synchronisieren.

• OneLake-Sicherheitsrollen werden auf dem SQL-Analyseendpunkt mit dem präfix OLS_ verteilt.

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

• E-Mail-aktivierte Sicherheitsgruppen und Verteilerlisten werden nicht unterstützt.

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