Integrieren von Direct Lake-Sicherheit

Die Sicherheit von Direct Lake stellt sicher, dass nur autorisierte Benutzer Delta-Tabellen in OneLake abfragen können. Sie können Datenzugriffsberechtigungen über Arbeitsbereichsrollen verwalten. Arbeitsbereichsmitwirkende, Mitglieder und Administratoren können Daten in OneLake lesen. Sie können auch über Berechtigungen auf Elementebene und Rechenberechtigungen Zugriff auf die Daten in OneLake gewähren. Die dritte Option besteht darin, OneLake-Sicherheit zu nutzen, um eine differenzierte rollenbasierte Sicherheit für alle Fabric-Computing-Engines zu implementieren. In diesem Artikel wird erläutert, wie Sie Berechtigungsmodelle ausrichten, einmaliges Anmelden (Single Sign-On, SSO) oder feste Identitäten auswählen und OLS (Object-Level Security) und Sicherheit auf Zeilenebene (RLS) nutzen. Weitere Informationen finden Sie in der OneLake-Sicherheitsübersicht.

Kernkonzepte und Terminologie

In diesem Artikel wird davon ausgegangen, dass Sie mit diesen Konzepten vertraut sind:

  • Direct Lake verwendet freigegebene M-Ausdrücke in den Semantikmodellmetadaten, um über Power Query-Datenzugriffsfunktionen auf Datenquellen zu verweisen: AzureStorage.DataLake für Direct Lake auf OneLake und Sql.Database für Direct Lake auf SQL-Endpunkten. Direct Lake verwendet diese Funktionen jedoch nicht zum Lesen der Delta-Quelltabellen. Sie liest die Delta-Tabellen direkt über OneLake-APIs.
  • Um sicherzustellen, dass nur autorisierte Benutzer die Daten abfragen, überprüft Direct Lake die Datenzugriffsberechtigungen der effektiven Identität. Die effektive Identität hängt von der Datenverbindungskonfiguration ab. Standardmäßig verwendet Direct Lake SSO (Microsoft Entra ID) und verwendet die Identität des aktuellen Benutzers, der das semantische Modell abfragt. Sie können ein Direct Lake-Modell auch an eine explizite Cloudverbindung binden, um eine feste Identität bereitzustellen.
  • Wenn Sie Datenzugriffsberechtigungen über Arbeitsbereichsrollen erteilen, können nur Mitglieder der Rolle "Mitwirkende" (oder höher) Daten in OneLake lesen. Arbeitsbereichsanzeigen verfügen jedoch nicht über Leseberechtigungen in OneLake. Zuschauer und Benutzer, die keine Mitglieder einer Arbeitsbereichsrolle sind, können Lesezugriff über eine Kombination aus Elementberechtigungen, Berechnungsberechtigungen oder OneLake-Sicherheitsrollen erhalten.
  • Mit der OneLake-Sicherheit können Mitglieder der Rollen "Arbeitsbereichsadministrator" und "Arbeitsbereichsmitglied" eine differenzierte rollenbasierte Sicherheit für Benutzer in der Rolle "Viewer" definieren. Geben Sie die Tabellen an, auf die ein Viewer oder Benutzer mit expliziter Leseberechtigung zugreifen kann, und schließen Sie bestimmte Zeilen oder Spalten aus. Weitere Informationen zu OneLake-Sicherheitsrollen finden Sie unter Tabellensicherheit in OneLake, Sicherheit auf Spaltenebene in OneLake und RLS in OneLake.

Verbindungskonfiguration

Konfigurieren Sie Datenverbindungen für ein Direct Lake-Modell auf die gleiche Weise wie andere semantische Modelltypen. Ausführliche Informationen finden Sie unter Herstellen einer Verbindung mit Clouddatenquellen des Power BI-Dienstes.

Da Direct Lake nur eine Verbindung mit Fabric-Datenquellen herstellt, funktioniert die Standardkonfiguration von SSO (Microsoft Entra ID) normalerweise, sodass Sie keine Semantikmodelle an explizite Datenverbindungen binden müssen. Dieser Ansatz reduziert die Konfigurationskomplexität und verringert den Verwaltungsaufwand.

Mit SSO (Microsoft Entra ID) überprüft Direct Lake, ob der aktuelle Benutzer, der das semantische Modell abfragt, Lesezugriff auf die Daten hat. Nur Benutzer mit Lesezugriff können die Daten abfragen. Der folgende Screenshot zeigt ein Direct Lake-Modell mit der Standardmäßigen SSO-Konfiguration.

Screenshot der Verbindungseinstellungen des Direct Lake-Modells, das standardmäßig mit Microsoft Entra ID SSO für den Datenzugriff aktiviert ist.

Wenn Sie eine explizite Datenverbindung mit einer festen Identität anstelle von SSO verwenden, erfordert Direct Lake nicht, dass jeder Benutzer über Leseberechtigungen für die zugrunde liegenden Daten verfügt. Wenn Microsoft Entra SSO in der Datenverbindung deaktiviert bleibt, bestimmen die Berechtigungen der festen Identität, auf welche Daten Direct Lake zugreifen kann.

Screenshot der Direct Lake-Modellverbindungseinstellungen mit deaktivierter Microsoft Entra ID SSO und ausgewählter fester Identität.

Hinweis

Sie können eine Datenverbindung so konfigurieren, dass SSO und eine feste Identität verwendet werden. Direct Lake überprüft die Berechtigungen des aktuellen Benutzers während der Abfragezeit und verwendet die feste Identität zum Umrahmen und der Transcodierung während der Aktualisierungszeit. Um eine feste Identität für Abfragen und Aktualisierungen zu verwenden, stellen Sie sicher, dass SSO in der Datenverbindungskonfiguration deaktiviert ist.

Tipp

Verwenden Sie SSO für interaktive Szenarien, in denen die Benutzerautorisierung erforderlich ist. Verwenden Sie eine Cloud-Verbindung mit fester Identität für eingebettete oder schreibgeschützte Verbraucherszenarien, bei denen der Zugriff auf Quellenebene auf ein einzelnes Dienstkonto beschränkt ist. Wenden Sie die Prinzipien der geringsten Rechte sowohl auf quell- als auch auf Arbeitsbereichsebene an, und testen und überprüfen Sie das Verhalten für beide Authentifizierungsmodi vor der Produktionsbereitstellung.

Authentifizierungsanforderungen

Direct Lake-Modelle verwenden die Microsoft Entra ID-Authentifizierung. Wählen Sie in der Datenverbindungskonfiguration OAuth 2.0, Dienstprinzipal oder Arbeitsbereichsidentität als Authentifizierungsmethode aus. Andere Methoden, z. B. Schlüssel- oder SAS-Authentifizierung, werden möglicherweise in der Konfigurations-UI angezeigt, werden jedoch für Direct Lake-Modelle nicht unterstützt.

Berechtigungsanforderungen

Die Berechtigungsanforderungen unterscheiden sich zwischen Direct Lake auf SQL-Endpunkten und Direct Lake auf OneLake. Dieser Unterschied besteht darin, dass Direct Lake auf SQL-Endpunkten auf den SQL Analytics Endpoint der Zieldatenquelle angewiesen ist, während Direct Lake auf OneLake die OneLake-APIs für Berechtigungsprüfungen verwendet.

Direct Lake auf SQL-Endpunkten

Direct Lake auf SQL-Endpunkten überprüft die Berechtigungen über den SQL-Analytics-Endpunkt, um zu sehen, ob die effektive Identität, die auf die Daten zugriffen will, die richtigen Berechtigungen hat. Die effektive Identität benötigt keine Erlaubnis, um Delta-Tabellen direkt in OneLake zu lesen. Es benötigt lediglich Lesezugriff auf ein Fabric-Element, beispielsweise ein Lakehouse, sowie die SELECT-Berechtigung für eine Tabelle über dessen SQL-Analyseendpunkt. Fabric gewährt dem semantischen Modell die Berechtigungen, die es benötigt, um die Delta-Tabellen und zugehörigen Parquet-Dateien zu lesen, um Spaltendaten in den Speicher zu laden. Das semantische Modell kann regelmäßig den SQL-Analytics-Endpunkt lesen, um zu prüfen, auf welche Daten der abfragende Nutzer (oder die feste Identität) zugreifen kann.

Direkter See auf OneLake

Direct Lake auf OneLake verwendet keinen SQL-Analytics-Endpunkt zur Überprüfung der Berechtigungen. Es nutzt OneLake-Sicherheit. Wenn die OneLake-Sicherheit aktiviert ist, verwendet Direct Lake auf OneLake den aktuellen Benutzer (oder die feste Identität), um OneLake-Sicherheitsrollen zu ermitteln und OLS sowie RLS auf dem Ziel-Fabric-Element durchzusetzen. Wenn die OneLake-Sicherheit nicht aktiviert ist, benötigt Direct Lake auf OneLake die effektive Identität, um Read- und ReadAll-Berechtigungen für das Ziel-Fabric-Element zu haben, um auf seine Delta-Tabellen in OneLake zuzugreifen. Weitere Informationen zu Read- und ReadAll-Berechtigungen finden Sie unter Elemente teilen und Berechtigungen auf Item-Ebene festlegen.

Hinweis

Mitwirkende (oder höher) verfügen über Lese- und ReadAll-Berechtigungen in OneLake. Betrachter und Benutzer, die keiner Workspace-Rolle angehören, müssen die Berechtigungen Read und ReadAll erhalten oder einer OneLake-Sicherheitsgruppe hinzugefügt werden. Weitere Informationen zum Verwalten von OneLake-Sicherheitsgruppen finden Sie unter OneLake-Datenzugriffssteuerungsmodell.

Direct Lake-Benutzer

In den folgenden Szenarien werden mindestberechtigungsanforderungen aufgeführt.

Scenario Direct Lake auf SQL-Endpunkten Direkter See auf OneLake Kommentare
Benutzer können Berichte anzeigen – Erteilen Sie leseberechtigungen für die Berichte und die Leseberechtigung für das semantische Modell.
- Wenn Direct Lake SSO verwendet, gewähren Sie den Benutzern mindestens die Leseberechtigung für das Ziel-Fabric-Element und SELECT-Berechtigungen für die Tabellen.		 – Erteilen Sie leseberechtigungen für die Berichte und die Leseberechtigung für das semantische Modell.
- Wenn Direct Lake SSO verwendet, erteile den Nutzern mindestens die Leserberechtigung für das Ziel-Fabric-Element und füge es einer OneLake-Sicherheitsrolle hinzu oder erteile ihnen die ReadAll-Berechtigung.		 Berichte müssen nicht zum gleichen Arbeitsbereich wie das semantische Modell gehören. Weitere Informationen finden Sie unter Strategie für schreibgeschützte Consumer.
Benutzer können Berichte erstellen – Erteilen Sie die Erstellungsberechtigung für das semantische Modell.
- Wenn Direct Lake SSO verwendet, gewähren Sie Benutzern mindestens die Read-Berechtigung für das Ziel-Fabric-Element und SELECT-Berechtigungen für die Tabellen.		 – Erteilen Sie die Erstellungsberechtigung für das semantische Modell.
- Wenn Direct Lake SSO verwendet, erteile den Nutzern mindestens die Leserberechtigung für das Ziel-Fabric-Element und füge es einer OneLake-Sicherheitsrolle hinzu oder erteile ihnen die ReadAll-Berechtigung.		 Benutzer können nur Berichte zu den Tabellen und Spalten erstellen, auf die sie Zugriff haben. Diese Bedingung könnte eine Teilmenge der vollständigen Menge von Tabellen und Spalten im Modell sein. Weitere Informationen finden Sie unter Strategie für Inhaltsersteller.
Benutzern wird das Abfragen des Lakehouse- oder SQL-Analyseendpunkts verweigert, aber sie können das semantische Modell abfragen. – Binden Sie das Direct Lake-Modell an eine Cloudverbindung mit einer festen Identität, und lassen Sie SSO deaktiviert.
- Gewähre der festen Identität mindestens Leserberechtigung für das Ziel-Fabric-Element und SELECT-Berechtigungen für die Tabellen.
- Erteile den Nutzern keine Erlaubnis für das Ziel-Fabric-Objekt.		 – Binden Sie das Direct Lake-Modell an eine Cloudverbindung mit einer festen Identität, und lassen Sie SSO deaktiviert.
- Erteile der festen Identität mindestens die Leserberechtigung für das Ziel-Fabric-Element und füge sie einer OneLake-Sicherheitsrolle hinzu oder erteile ihr die ReadAll-Berechtigung.
- Erteile den Nutzern keine Erlaubnis für das Ziel-Fabric-Objekt.		 Nur geeignet, wenn die Cloudverbindung eine feste Identität verwendet.
Benutzer können das semantische Modell und den SQL-Analyseendpunkt abfragen, aber das Abfragen des Lakehouse wird verweigert. - Gewähren von Read- und ReadData-Berechtigungen für das Ziel-Fabric-Objekt. Nicht zutreffend. Wichtig: Abfragen, die an den SQL-Analytics-Endpunkt gesendet werden, umgehen die Datenzugriffsberechtigungen, die das semantische Modell erzwingt.
Verwalten des semantischen Modells, einschließlich Aktualisierungseinstellungen – Erfordert den Besitz des semantischen Modells. – Erfordert den Besitz des semantischen Modells. Weitere Informationen finden Sie unter Besitz von Semantikmodellen.

Von Bedeutung

Testen Sie immer Berechtigungen, bevor Sie Ihr semantisches Modell und Berichte für die Produktion freigeben.

Weitere Informationen finden Sie unter Berechtigungen des semantischen Modells.

Direct Lake-Besitzer

Zusätzlich zur effektiven Identität (aktueller Benutzer oder feste Identität) verlangt Direct Lake, dass der Inhaber des semantischen Modells Lesezugriff auf die Quelltabellen hat, damit Direct Lake das semantische Modell als Teil der Datenaktualisierung rahmen kann. Unabhängig davon, wer ein Direct Lake-Modell aktualisiert, überprüft Direct Lake die Berechtigung des Besitzers, um sicherzustellen, dass das Modell auf die Daten zugreifen darf. Die Datenzugriffsberechtigungsanforderungen des Besitzers sind identisch mit benutzern, die das Modell abfragen.

Wenn der Besitzer des semantischen Modells nicht über die erforderlichen Datenzugriffsberechtigungen verfügt, löst Direct Lake während des Rahmens den folgenden Fehler aus: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

Kurzbefehle zu Quelltabellen

Abkürzungen sind OneLake-Objekte, die man einem Fabric Lakehouse oder einem anderen Fabric-Gegenstand hinzufügt, um auf interne oder externe Lagerorte hinzuweisen. In einem Direct Lake-Modell erscheinen Delta-Tabellen, die über Shortcuts hinzugefügt wurden, als native im verbundenen Fabric-Element, da Shortcuts transparent sind, wenn man Daten über die OneLake-API abruft.

Wenn Sie über SQL-Endpunkte mit Direct Lake auf Schnellzugriffe zugreifen, validiert Direct Lake zunächst, ob die effektive Identität (aktueller Benutzer oder feste Identität) auf die Tabelle in der Datenquelle des semantischen Modells zugreifen kann. Für interne Verknüpfungen verwendet Direct Lake nach erfolgreicher Prüfung die Identität des Datenquellenbesitzers, um die Delta-Tabelle über die Verknüpfung im Fabric-Element der Tabelle zu lesen. Der Datenquellenbesitzer muss über Zugriffsberechtigungen im OneLake-Zielspeicherort verfügen. Für externe Verknüpfungen benötigt der Datenquellenbesitzer auch die Berechtigung "Verwenden" für die Cloudverbindung mit dem externen System, das die Delta-Tabelle hostet. Weitere Informationen finden Sie unter OneLake-Verknüpfungen.

Screenshot des Diagramms, das die Überprüfung der effektiven Identität von Direct Lake zeigt, gefolgt von der Nutzung der Identität des Datenquellenbesitzers für den Zugriff auf interne oder externe Verknüpfungsziele.

Direct Lake über OneLake weist unterschiedliche Berechtigungsanforderungen auf, da der SQL Analytics-Endpunkt nicht beteiligt ist. Wenn ein Benutzer über eine interne Verknüpfung zu einem anderen OneLake-Speicherort auf Daten zugreift, muss die effektive Identität (aktueller Benutzer oder feste Identität) über die Berechtigung am Zielspeicherort verfügen. Die effektive Identität muss ein Mitwirkender (oder höher) sein, über die Berechtigungen Lesen und Lesen alle verfügen oder in einer OneLake-Sicherheitsrolle sein, die Lesen-Zugriff gewährt.

Sicherheit auf Objektebene (OLS) und Sicherheit auf Zeilenebene (RLS)

Sowohl die OneLake-Sicherheits- als auch die Direct Lake-Modelle unterstützen OLS und RLS. OLS ermöglicht es Item-Besitzern und Administratoren, bestimmte Tabellen oder Spalten zu sichern. RLS kann verwendet werden, um den Datenzugriff auf Zeilenebene basierend auf Filtern einzuschränken. Man kann OLS und RLS in OneLake-Sicherheit definieren, in einem Direct Lake-Modell oder an beiden Standorten.

Von Bedeutung

Direct Lake unterstützt OLS/RLS im SQL-Analyseendpunkt nicht im Arbeitsspeicher. Direct Lake über SQL-Endpunkte behandelt diese Einschränkungen je nach Typ unterschiedlich. Wenn eine Abfrage eine Tabelle oder Spalte berührt, die durch SQL Analytics Endpoint OLS oder Column-Level Security (CLS) eingeschränkt ist, liefert die Abfrage einen Fehler. Wenn eine Abfrage auf eine Tabelle verweist, die RLS oder eine Ansicht am SQL-Analytics-Endpunkt erzwingt, fällt die Abfrage in den DirectQuery-Modus zurück. Wenn der DirectQuery-Fallback deaktiviert ist, scheitern Abfragen, die von RLS oder Ansichten über SQL-Endpunkten abhängen. Direct Lake über OneLake umgeht diese Einschränkungen. Details finden Sie unter Wie Abfragen in Direct Lake in SQL ausgewertet werden.

Direct Lake auf OneLake OLS/RLS mit OneLake Sicherheits-OLS/RLS

Direct Lake auf OneLake bewertet den Zugriff auf OLS/RLS-gesicherte Objekte, indem die OneLake-Sicherheitsrollen der effektiven Identität ermittelt und die definierten OLS/RLS-Regeln angewendet werden. Die OneLake-Sicherheitsrollen werden genauso gehandhabt wie die von Direct Lake. Wenn die effektive Identität mehreren Rollen in der OneLake-Sicherheit und in Direct Lake angehört, vereinigt Direct Lake zunächst die Rollen der OneLake-Sicherheit und bildet dann die Schnittmenge des Ergebnisses mit den Direct Lake-Rollen.

Diese Tabelle listet häufige Fehlerbehebungssituationen auf, die durch widersprüchliche OneLake-Sicherheits- und Direct Lake-Regeln verursacht werden.

Scenario Kommentare
Aufgrund der RLS-Filterung wurden keine Zeilen zurückgegeben. Wenn die effektive Identität keine Zugriffsberechtigungen auf Zeilenebene aufweist, können Abfragen leere Ergebnisse zurückgeben. Dieses Verhalten wird erwartet, wenn RLS-Filter alle Zeilen für den aktuellen Benutzer ausschließen.
Tabelle kann nicht gefunden werden
Spalte kann nicht gefunden werden
Fehler beim Auflösen des Namens.
Kein gültiger Tabellen-, Variablen- oder Funktionsname		 Diese Fehler treten normalerweise auf, wenn Objektberechtigungen fehlen, nachdem OneLake-Sicherheitsrollen angewendet wurden.

OLS/RLS-Bereichsunterschiede

Die Durchsetzung von OLS und RLS in OneLake-Sicherheit wendet die Regeln über alle Rechenmaschinen an und gewährleistet eine einheitliche Zugriffskontrolle für die Nutzer. Das bedeutet, dass unabhängig von der Rechen-Engine – Lakehouse, Warehouse, semantisches Modell oder ein anderes Element – OneLake-Sicherheitsregeln den Datenzugriff des Nutzers steuern. Im Gegensatz dazu gelten OLS/RLS, die innerhalb eines Direct Lake-Semantikmodells definiert sind, nur im Rahmen dieses Modells. Andere Computing-Engines wenden diese Direct Lake-Sicherheitsregeln nicht an. Dies kann zu unterschiedlichen Ergebnissen führen, wenn Benutzer über andere Wege auf die Daten zugreifen.

Von Bedeutung

Wenn man sowohl OneLake-Sicherheits-OLS/RLS als auch Direct Lake OLS/RLS verwendet, können Nutzer mit OneLake-Zugriff die Daten trotzdem abrufen und mit ihnen arbeiten – auch wenn die Modellregeln die Daten weiter einschränken – weil die Regeln auf Modellebene nicht über das Modell hinausgehen. Nutzen Sie OneLake-Sicherheit für eine umfassende Zugriffskontrolle über alle Rechenmaschinen hinweg.

OneLake OLS- und Semantikmodellmetadaten

Metadaten des semantischen Modells umfassen Definitionen von Tabellen, Spalten, Beziehungen und anderen Schemaelementen. Benutzer mit Build - oder höheren Berechtigungen können die Modellmetadaten über XML for Analysis (XMLA) und REST-APIs anzeigen. Weitere Informationen finden Sie unter Berechtigungen des semantischen Modells.

Um sensible Tabellen- und Spaltennamen in OneLake mit OneLake OLS zu schützen, denken Sie daran, dass die OneLake-Sicherheit nur für Mitglieder der Workspace-Viewer-Rolle gilt. OneLake OLS verhindert nicht, dass Mitglieder der Arbeitsbereichsrolle „Mitwirkender“ (oder einer höheren Rolle) gesicherte Tabellen oder Spalten finden, da sie bereits Schreibzugriff auf alle Arbeitsbereichselemente haben. Mitglieder der Viewer-Rolle mit Build - oder höheren Berechtigungen für ein Direct Lake-Modell können vertrauliche Schemainformationen über die Semantikmodellmetadaten ermitteln. Diese höher privilegierten Benutzer haben weiterhin keinen Datenzugriff, aber sie können sehen, dass die gesicherten Tabellen und Spalten vorhanden sind.

Ein Direct Lake-Modell kann sich im selben Arbeitsbereich wie das Quellenelement oder in einem separaten Arbeitsbereich befinden. Gewähren Sie einem Viewer im selben Arbeitsbereich Build (oder höher) Zugriff auf ein Direct Lake Modell über Elementberechtigungen. In einem separaten Arbeitsbereich kann ein Benutzer ein Beitragender (oder höher) sein oder über Build (oder höhere) Elementberechtigungen verfügen, um auf die Modellmetadaten zuzugreifen.

OneLake OLS- und Git-Integration

Die Git-Integration ermöglicht Es Entwicklern, ihre ALM-Prozesse (Application Lifecycle Management) in die Fabric-Plattform zu integrieren. Das Git-Repository bewahrt die Arbeitsbereichsstruktur, einschließlich aller unterstützten Elemente. Entwickler haben vollständige Sichtbarkeit für die Metadaten aller elemente im Git-Repository. Mithilfe von Direct Lake-Modellmetadaten können sie sehen, dass gesicherte Tabellen oder Spalten vorhanden sind, auch wenn sie keinen Zugriff auf die Zieldatenquelle in einem anderen Arbeitsbereich haben. Weitere Informationen finden Sie unter Was ist die Git-Integration von Microsoft Fabric?

Wie Abfragen in Direct Lake in SQL ausgewertet werden

Der Grund für die Entwicklung von Direct Lake-Semantikmodellen besteht darin, hochleistungsfähige Abfragen über große Datenmengen in OneLake zu erzielen. Daher sollten Sie sich bemühen, eine Lösung zu entwerfen, die die Chancen einer In-Memory-Abfrage maximiert.

In den folgenden Schritten wird beschrieben, wie Direct Lake SQL-Abfragen ausgewertet werden (und ob sie fehlschlagen). Die Vorteile des Direct Lake-Speichermodus sind nur möglich, wenn der fünfte Schritt erreicht wird.

  1. Wenn die Abfrage eine Tabelle oder Spalte enthält, die durch das semantische Modell OLS eingeschränkt ist, wird ein Fehlerergebnis zurückgegeben (berichtsvisuale Elemente können nicht gerendert werden).
  2. Wenn die Abfrage eine Spalte enthält, die vom SQL-Analyseendpunkt CLS eingeschränkt ist (oder die Tabelle verweigert wird), wird ein Fehlerergebnis zurückgegeben (berichtsvisuale Elemente können nicht gerendert werden).
    1. Wenn die Cloudverbindung SSO (Standard) verwendet, wird CLS durch die Zugriffsebene des Berichtsanwenders bestimmt.
    2. Wenn die Cloudverbindung eine feste Identität verwendet, wird CLS durch die Zugriffsebene der festen Identität bestimmt.
  3. Wenn das semantische Modell Direct Lake in SQL-Endpunkten verwendet und die Abfrage eine beliebige Tabelle im SQL-Analytics-Endpunkt enthält, die RLS erzwingt oder eine Ansicht verwendet wird, greift die Abfrage auf den DirectQuery-Modus zurück.
    1. Wenn die Cloudverbindung SSO (Standard) verwendet, wird RLS durch die Zugriffsebene des Berichtsanwenders bestimmt.
    2. Wenn die Cloudverbindung eine feste Identität verwendet, wird RLS durch die Zugriffsebene der festen Identität bestimmt.
  4. Wenn die Abfrage die Schutzmaßnahmen der Kapazität überschreitet, wird ein Fallback auf den DirectQuery-Modus ausgeführt.
  5. Andernfalls wird die Abfrage aus dem Speichercache erfüllt. Spaltendaten werden bei Bedarf in den Arbeitsspeicher geladen .

Von Bedeutung

Direct Lake auf OneLake unterstützt keinen Fallback in den DirectQuery-Modus. Wenn eine Tabelle im SQL-Analyseendpunkt RLS erzwingt oder die Abfrage die Grenzwerte der Kapazität überschreitet, wird ein Fehlerergebnis zurückgegeben (Berichtsvisualisierungen können nicht gerendert werden).

Datenzugriffsregeloptionen

Sie können Datenzugriffsregeln wie folgt festlegen:

  • Das semantische Modell.
  • Der SQL-Analyseendpunkt (nur Direct Lake auf SQL-Endpunkten).
  • OneLake-Sicherheit.

Regeln im semantischen Modell

Wenn Sie Datenzugriffsregeln durchsetzen müssen, tun Sie dies in OneLake-Sicherheit, damit die Regeln über alle Rechen-Engines angewendet werden und eine einheitliche Zugriffskontrolle für Nutzer gewährleistet ist. Verwenden Sie das semantische Modell RLS oder OLS, wenn den Verbrauchern keine Berechtigung zum Abfragen des Lakehouses oder Warehouses gewährt wird, und die Cloud-Verbindung eine feste Identität anstelle von SSO verwendet. SSO impliziert, dass Endbenutzer direkt auf die Datenquelle zugreifen können und daher Sicherheitsregeln im semantischen Modell umgehen können.

Von Bedeutung

Berechtigungen für Semantikmodellelemente können explizit über Power BI-Apps festgelegt oder implizit über Arbeitsbereichsrollen erworben werden.

Bemerkenswert ist, dass die Datenzugriffsregeln für semantische Modelle für Nutzer mit Schreibberechtigung für das semantische Modell nicht durchgesetzt werden. Umgekehrt gelten Datenzugriffsregeln für Benutzer, die der Arbeitsbereichsrolle Viewer zugewiesen sind. Benutzer, die der Rolle Admin, Mitglied oder Beitragsarbeitsbereich zugewiesen sind, haben jedoch implizit die Schreibberechtigung für das semantische Modell, sodass Datenzugriffsregeln nicht durchgesetzt werden. Weitere Informationen finden Sie unter Rollen in Arbeitsbereichen.

Regeln auf mehreren Ebenen

Man kann Datenzugriffsregeln auf allen Ebenen durchsetzen. Dieser Ansatz erfordert jedoch zusätzliche Komplexität und Verwaltungsaufwand. In diesem Fall verwenden Sie eine feste Identität für die Cloud-Verbindung anstelle von SSO.

Vergleichen von Datenzugriffsregeloptionen

In der folgenden Tabelle werden die Datenzugriffseinrichtungsoptionen für Direct Lake auf SQL-Endpunkten und Direct Lake auf OneLake verglichen.

Anwenden von Datenzugriffsregeln Direct Lake auf SQL Direkter See auf OneLake Kommentar
Nur semantisches Modell Unterstützt Unterstützt Verwenden Sie diese Option, wenn Benutzenden keine Elementberechtigungen zum Abfragen von Lakehouses oder Warehouses erteilt werden. Richten Sie die Cloudverbindung ein, um eine feste Identität zu verwenden. Erreichen Sie eine hohe Abfrageleistung aus dem In-Memory-Cache.
Nur SQL-Analyseendpunkt Unterstützt (fällt auf DirectQuery zurück) Nicht anwendbar Hängt vom Fabric-Datenelement (z. B. Lakehouse oder Warehouse) mithilfe des delegierten Identitätsmodus ab. Verwenden Sie diese Option, wenn Benutzer auf Daten aus dem Warehouse oder dem semantischen Modell und mit konsistenten Datenzugriffsregeln zugreifen müssen. Stellen Sie sicher, dass SSO für die Cloudverbindung aktiviert ist. Die Abfrageleistung kann aufgrund von DirectQuery-Fallback langsam sein.
Nur OneLake-Sicherheit Nicht anwendbar Unterstützt Verwenden Sie diese Option für die vereinheitlichte Zugriffssteuerung über alle Fabric-Computing-Engines. Die OneLake-Sicherheit erzwingt OLS und RLS für alle Benutzer, die über einen beliebigen Pfad auf die Daten zugreifen. Erreichen Sie eine hohe Abfrageleistung aus dem In-Memory-Cache.
Mehrere Ebenen (Semantikmodell und SQL-Endpunkt) Unterstützt Nicht anwendbar Diese Option erfordert zusätzlichen Verwaltungsaufwand. Richten Sie die Cloudverbindung ein, um eine feste Identität zu verwenden.
Mehrere Ebenen (Semantikmodell und OneLake-Sicherheit) Nicht anwendbar Unterstützt Zuerst werden OneLake-Sicherheitsregeln angewendet, dann semantische Modellregeln. Erwägen Sie, Regeln auf einer Ebene zu konsolidieren, um die Komplexität zu reduzieren.

Überlegungen und Einschränkungen

Berücksichtigen Sie diese Direct Lake-Sicherheitsbeschränkungen.

Hinweis

Die Funktionen und Features von Direct Lake-Semantikmodellen und OneLake-Sicherheit entwickeln sich schnell. Überprüfen Sie regelmäßig nach Updates.

  • Workspace-Viewern OneLake-Sicherheitsrollen zuweisen, die Lesezugriff auf die Quell-Fabric-Elemente gewähren. Wenn ein Quellobjekt Shortcuts zu einem anderen Fabric-Item hat, benötigt der Benutzer auch Lesezugriff auf das Ziel-Fabric-Item jeder Verknüpfung.
  • Verwenden Sie eine feste Identität, um Benutzer von einem Quell-Fabric-Item zu isolieren. Binden Sie das Direct Lake-Modell an eine Cloudverbindung. Lassen Sie SSO für die Cloudverbindung deaktiviert, um die feste Identität für Aktualisierungen und Abfragen zu verwenden.
  • Direct Lake semantische Modelle, die auf Fabric OneLake-Sicherheit für das Quellobjekt angewiesen sind, unterstützen keine Backup-Operationen.
  • Bidirektionale Beziehungen werden in einem Direct Lake-Modell nicht unterstützt, wenn das Quell-Fabric-Element auf OneLake-Sicherheits-RLS angewiesen ist.
  • Die OneLake-Sicherheit unterstützt keine dynamischen Definitionen oder komplexen Rollenkonfigurationen, z. B. das Kombinieren mehrerer OLS- und RLS-Rollen über verwandte Tabellen hinweg.
  • Konsolidieren Sie OneLake-Sicherheits-RLS- und OLS-Berechtigungen in einer Rolle pro Benutzer, anstatt mehrere Rollen zuzuweisen.
  • Wenn sich die OneLake-Sicherheitskonfiguration ändert, zum Beispiel aufgrund von Shortcut-Änderungen im Zielobjekt, aktualisieren Sie Direct Lake auf OneLake-Modellen, die auf dieses Element zugreifen. Sie müssen die Modelle manuell oder mithilfe von Aktualisierungs-APIs aktualisieren.
  • Wenn ein Lakehouse über OneLake-Sicherheit verfügt:
    • Der SQL-Analyseendpunkt hat standardmäßig eine feste Identität, die dem Besitzer des Lakehouse zugeordnet ist. Dadurch entspricht die OneLake-Sicherheit des SQL-Analyseendpunkts der des Besitzers (ohne Einschränkungen). Direct Lake auf SQL bleibt bei der Verwendung von Direct Lake, außer es werden zusätzliche SQL-feingranulare Zugriffsrollen hinzugefügt.
    • Der SQL-Analyseendpunkt kann in SSO geändert werden. In diesem Fall werden OneLake-Sicherheitsrollen als SQL granulare Zugriffssteuerungsregeln hinzugefügt, und der Benutzer wird daran gehindert, sie direkt auf dem SQL-Analyseendpunkt zu bearbeiten. Zu diesem Zeitpunkt wechselt Direct Lake auf SQL zu 100 % der Zeit auf DirectQuery zurück.
  • Last updated on