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

Mit OneLake-Sicherheit erweitert Microsoft Fabric die Möglichkeiten von Organisationen, den Datenzugriff über Workloads hinweg zu verwalten und durchzusetzen. Dieses neue 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 read-access 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 Daten access Richtlinien:

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 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 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 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-Seite im Fabric-Portal erfolgen und unterliegen arbeitsbereichsrollen (Administrator, Mitglied, Mitwirkender).

Rollenverhalten im Arbeitsbereich

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:

• Weisen Sie den Benutzern im Arbeitsbereich die Rolle Viewer zu, oder

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

Rollenpriorität: Der am meisten zugelassene Zugriff gewinnt

Wenn ein Benutzer zu mehreren OneLake-Rollen gehört, definiert die Rolle mit den meisten Berechtigungen ihren effektiven Zugriff. Beispiel:

• Wenn eine Rolle einer Tabelle vollständigen Zugriff gewährt und eine andere RLS zum Einschränken von Zeilen anwendet, wird das RLS nicht angewendet.

• Die breitere 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 gegenseitig exklusiv zu halten, wenn Zugriffssteuerungselemente auf Zeilen- oder Spaltenebene durchgesetzt werden.

Weitere Informationen finden Sie im Zugriffssteuerungsmodell für Daten für die Sicherheit von OneLake.

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 weiterhin SQL-Berechtigungen auf Ansichten, Funktionen und gespeicherte Prozeduren mithilfe von GRANT- oder EXECUTE-Anweisungen anwenden.

Sicherheits-Synchronisierungsfehler 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 dem Benutzer auf einer der beiden Seiten die Berechtigung fehlt, schlägt Abfragen mit einem 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.

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 verwendet der SQL-Analyseendpunkt dasselbe Security-Modell, das heute vorhanden ist in Microsoft Fabric. Sicherheit und Berechtigungen werden vollständig auf der SQL-Ebene verwaltet, und OneLake-Rollen oder access-Richtlinien werden nicht erzwungen für access auf Tabellenebene. Wenn ein Benutzer eine Verbindung mit dem SQL-Analyseendpunkt herstellt und eine Abfrage ausgibt:

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

• 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-Analytics-Endpunktbesitzers durchgeführt, auch bekannt als Item-Konto.

In diesem Modell:

• Der angemeldete Benutzer wird nicht an OneLake übergeben.

• Es wird davon ausgegangen, dass alle Zugriffskontrollen auf der SQL-Ebene erfolgen.

• 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-access für den Besitzer zu Abfragefehlern. Dieser Modus bietet vollständige Kompatibilität mit:

• SQL GRANT/REVOKE auf allen Objektebenen

• SQL-definierte Row-Level Security, Column-Level Security und Dynamic Data Masking

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

So ändern Sie den OneLake-access-Modus

Der Zugriffsmodus bestimmt, wie der Datenzugriff authentifiziert und durchgesetzt 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 oben rechts von Lakehouse zum SQL Analytics-Endpunkt.

2. Wechseln Sie in der oberen Navigationsleiste zur Registerkarte Security und wählen Sie einen der folgenden OneLake-access Modi 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 Viewer-Berechtigungen oder freigegebenem schreibgeschützten 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.

Einschränkungen

• Gilt nur für Leser: Die Sicherheit von OneLake steuert benutzer, die als Viewer auf Daten zugreifen. Benutzer in anderen Arbeitsbereichsrollen (Administrator, Mitglied oder Beitragender) umgehen die OneLake-Sicherheit und behalten den vollständigen Zugriff.

• 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 sind nicht sofort wirksam. 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 der Steuerebene: Berechtigungen können nicht auf Benutzer oder Gruppen angewendet werden, die in der Steuerebene des Arbeitsbereichs noch nicht existieren. Sie müssen entweder das Quellobjekt freigeben, oder der Benutzer muss Mitglied der Arbeitsbereichsrolle Viewer 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.

• Zugriff mit den meisten Berechtigungen hat Vorrang: Wenn Benutzer mehreren Gruppen oder Rollen angehören, wird die effektivste Berechtigung Beispiel berücksichtigt: Wenn ein Benutzer sowohl DENY durch eine Rolle als auch GRANT durch eine andere hat, hat das GRANT Vorrang.

• Delegierte Moduseinschränkungen: Im delegierten Modus kann die Metadatensynchronisierung in Verknüpfungstabellen fehlschlagen, wenn das Quellelement über OneLake-Sicherheitsrichtlinien verfügt, die dem Elementbesitzer keine vollständigen Tabellenzugang gewähren.

• DENY-Verhalten: Wenn mehrere Rollen auf eine einzelne Zuordnungstabelle angewendet werden, folgt die Überschneidung der Berechtigungen der SQL Server-Semantik: VERWEIGERN überschreibt GEWÄHREN. Dies kann zu unerwarteten Zugriffsergebnissen führen.

• Erwartete Fehlerbedingungen: Benutzer können Fehler in Szenarien wie solchen begegnen.

  • Verknüpfungsziel umbenannt oder ungültig

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

  • RLS (Zeilenebene-Sicherheit) fehlkonfiguriert

    • Einige Ausdrücke für die RLS-Filterung werden in OneLake nicht unterstützt und können möglicherweise unbefugten Datenzugriff zulassen.

    • Wenn Sie die für den Filterausdruck verwendete Spalte entfernen, wird die RLS ungültig, und die Metadatensynchronisierung läuft veraltet, bis die RLS im Sicherheitsbereich von OneLake behoben ist.

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

  • Sicherheitsbeschränkungen auf Spaltenebene (CLS)

    • CLS arbeitet, indem eine Erlaubnisliste 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-Sicherheitsrollen (OLS) auf Schemaebene definiert sind, bleiben diese Rollen nur dann wirksam, wenn 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-Sicherheitszugriffskontrollmodell