Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.
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.
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.
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. Dies liegt daran, dass Direct Lake auf SQL-Endpunkten vom SQL Analytics-Endpunkt der Zieldatenquelle abhängt, während Direct Lake auf OneLake die OneLake-APIs für Berechtigungsprüfungen verwendet.
Direct Lake auf SQL-Endpunkten
Direct Lake auf SQL-Endpunkten führt Berechtigungsprüfungen über den SQL-Analyseendpunkt durch, um festzustellen, ob die effektive Identität, die versucht, auf die Daten zuzugreifen, über die erforderlichen Datenzugriffsberechtigungen verfügt. Bemerkenswerterweise benötigt die effektive Identität nicht die Berechtigung, Delta-Tabellen direkt in OneLake zu lesen. Es reicht aus, über seinen SQL-Analyseendpunkt Lesezugriff auf das Fabric-Artefakt zu haben, z. B. ein Seehaus, und SELECT-Berechtigungen für eine Tabelle. Das liegt daran, dass Fabric dem semantischen Modell die erforderlichen Berechtigungen zum Lesen der Delta-Tabellen und zugeordneter Parkettdateien gewährt (um Spaltendaten in den Speicher zu laden). Das semantische Modell verfügt über die Berechtigung, den SQL-Analyseendpunkt regelmäßig zu lesen, um zu überprüfen, auf welche Daten der abfrageende Benutzer (oder eine feste Identität) zugreifen kann.
Direkter See auf OneLake
Direct Lake auf OneLake verwendet keinen SQL-Analyseendpunkt für Berechtigungsprüfungen. Es verwendet OneLake Security. Wenn die OneLake-Sicherheit aktiviert ist, verwendet Direct Lake auf OneLake den aktuellen Benutzer (oder eine feste Identität), um OneLake-Sicherheitsrollen aufzulösen und OLS sowie RLS für das Zielartefakt in Fabric durchzusetzen. Wenn OneLake Security nicht aktiviert ist, erfordert Direct Lake auf OneLake die effektive Identität, um Lese- und ReadAll-Berechtigungen für das Ziel-Fabric-Artefakt für den Zugriff auf die Delta-Tabellen in OneLake zu besitzen. Weitere Informationen zu Lese- und ReadAll-Berechtigungen finden Sie im Abschnitt "Elementberechtigungen" im OneLake-Sicherheitsübersichtsartikel.
Hinweis
Mitwirkende (oder höher) verfügen über Lese- und ReadAll-Berechtigungen in OneLake. Zuschauer und Benutzer, die keine Mitglieder einer Arbeitsbereichsrolle sind, müssen über Lese- und 'ReadAll'-Berechtigungen verfügen oder zu 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, erteilen Sie Benutzern mindestens Leseberechtigungen für das Ziel-Fabric-Artefakt 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, erteilen Sie Benutzern mindestens die Leseberechtigung für das Fabric-Zielartefakt, und fügen Sie sie einer OneLake-Sicherheitsrolle hinzu, oder erteilen Sie ihnen die Berechtigung "ReadAll ". |
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, erteilen Sie Benutzern mindestens Leseberechtigungen für dem Ziel-Fabric-Artefakt und SELECT-Berechtigungen für die Tabellen. |
– Erteilen Sie die Build-Berechtigung für das semantische Modell. – Wenn Direct Lake SSO verwendet, erteilen Sie Benutzern mindestens die Leseberechtigung für das Fabric-Zielartefakt, und fügen Sie sie einer OneLake-Sicherheitsrolle hinzu, oder erteilen Sie ihnen die Berechtigung "ReadAll ". |
Benutzer können nur Berichte zu den Tabellen und Spalten erstellen, auf die sie Zugriff haben. Dies kann eine Teilmenge der vollständigen Gruppe 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. – Erteilen Sie der festen Identität mindestens Leserechte für das Ziel-Fabric-Artefakt und SELECT-Rechte für die Tabellen. – Erteilen Sie Benutzern keine Berechtigung für das Ziel-Fabric-Artefakt. |
– Binden Sie das Direct Lake-Modell an eine Cloudverbindung mit einer festen Identität, und lassen Sie SSO deaktiviert. – Erteilen Sie der festen Identität mindestens Leseberechtigung für das Zielartefakt in Fabric und fügen Sie sie einer OneLake-Sicherheitsrolle hinzu, oder erteilen Sie ihr ReadAll-Berechtigung. – Erteilen Sie Benutzern keine Berechtigung für das Ziel-Fabric-Artefakt. |
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 Sie Lese- und ReadData-Berechtigungen für das Ziel-Fabric-Artefakt. | Nicht zutreffend. | Wichtig: An den SQL-Analyseendpunkt gesendete Abfragen umgehen die vom semantischen Modell erzwungenen Datenzugriffsberechtigungen. |
| 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
Neben der effektiven Identität (aktueller Benutzer oder fester Identität) erfordert Direct Lake auch den Lesezugriff auf die Quelltabellen, damit Direct Lake das Semantikmodell als Teil der Datenaktualisierung framen 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
Verknüpfungen sind OneLake-Objekte, die Sie einem Fabric Lakehouse oder einem anderen Fabric-Artefakt hinzufügen, um auf interne oder externe Speicherorte zu verweisen. In einem Direct Lake-Modell werden Delta-Tabellen, die durch Verknüpfungen hinzugefügt werden, im verbundenen Fabric-Artefakt als systemeigene Tabellen angezeigt, da Verknüpfungen transparent sind, wenn Sie über die OneLake-API auf Daten zugreifen.
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. Bei internen Verknüpfungen verwendet Direct Lake nach Bestehen dieser Überprüfung die Identität des Datenquellenbesitzers, um die Delta-Tabelle über die Verknüpfung im Fabric-Artefakt 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.
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 oneLake Security- als auch Direct Lake-Modelle unterstützen OLS und RLS. OLS ermöglicht Artefaktbesitzern und Administratoren das Sichern bestimmter Tabellen oder Spalten. RLS kann verwendet werden, um den Datenzugriff auf Zeilenebene basierend auf Filtern einzuschränken. Sie können OLS und RLS in OneLake Security, in einem Direct Lake-Modell oder an beiden Standorten definieren.
Von Bedeutung
Direct Lake unterstützt keinen SQL Analytics-Endpunkt OLS/RLS. Um korrekte Daten zurückzugeben, greift Direct Lake über SQL-Endpunkte auf den DirectQuery-Modus zurück, wenn ein Fabric-Artefakt OLS oder RLS verwendet. Wenn DirectQuery-Fallback deaktiviert ist, schlagen Abfragen über SQL-Endpunkte fehl, wenn OLS/RLS am SQL Analytics-Endpunkt definiert ist. Direct Lake über OneLake vermeidet diese Einschränkung.
Direkter See auf OneLake OLS/RLS mit OneLake Security OLS/RLS
Direct Lake auf OneLake wertet den Zugriff auf OLS/RLS-gesicherte Objekte aus, indem die OneLake-Sicherheitsrollen der effektiven Identität aufgelöst und die definierten OLS/RLS-Regeln angewendet werden. Die OneLake-Sicherheitsrollen werden genauso behandelt wie Direct Lake-Rollen. Wenn die effektive Identität zu mehreren Rollen in OneLake Security und Direct Lake gehört, verknüpft Direct Lake zuerst die OneLake-Sicherheitsrollen und überschneidet das Ergebnis mit den Direct Lake-Rollen.
In dieser Tabelle sind häufige Problembehandlungssituationen aufgeführt, die durch widersprüchliche OneLake-Sicherheitsregeln 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 in der Regel auf, wenn Objektberechtigungen nach dem Anwenden von OneLake-Sicherheitsrollen fehlen. |
OLS/RLS-Bereichsunterschiede
Das Erzwingen von OLS und RLS in OneLake Security wendet die Regeln für alle Rechenmodule an und stellt eine einheitliche Zugriffssteuerung zugunsten der Benutzer sicher. Dies bedeutet, dass OneLake-Sicherheitsregeln den Datenzugriff des Benutzers unabhängig von der Rechen-Engine steuern – sei es ein Lakehouse, Warehouse, Semantikmodell oder ein anderes Artefakt. 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 Sie sowohl OneLake Security OLS/RLS als auch Direct Lake OLS/RLS verwenden, können Benutzer, die über OneLake-Zugriff verfügen, weiterhin Daten abrufen und damit arbeiten – auch wenn Direct Lake-Modellregeln die Daten weiter einschränken, da Regeln auf Modellebene nicht über das Modell hinausgehen. Verwenden Sie OneLake Security für eine umfassende Zugriffssteuerung über alle Rechen-Engines.
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 vertrauliche Tabellen- und Spaltennamen in OneLake mit OneLake OLS zu schützen, denken Sie daran, dass OneLake Security nur für Mitglieder der Arbeitsbereich-Viewer-Rolle gilt. OneLake OLS verhindert nicht, dass Mitglieder der Arbeitsbereichsrolle "Contributor" (oder höher) gesicherte Tabellen oder Spalten erkennen, da sie bereits über Schreibberechtigungen für alle Artefakte im Arbeitsbereich verfügen. 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 im gleichen Arbeitsbereich wie das Quellartefakt oder in einem separaten Arbeitsbereich vorhanden sein. 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 behält die Arbeitsbereichsstruktur bei, einschließlich aller unterstützten Artefakte. 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?
Ü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.
- Weisen Sie Arbeitsbereichsanzeigen OneLake-Sicherheitsrollen zu, die Lesezugriff auf die Quell-Fabric-Artefakte gewähren. Wenn ein Quellartefakt Verknüpfungen zu einem anderen Fabric-Artefakt aufweist, benötigt der Benutzer auch Lesezugriff auf das Fabric-Zielartefakt jeder Verknüpfung.
- Verwenden Sie eine feste Identität, um Benutzer von einem Fabric-Quellartefakt 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-Semantikmodelle, die auf Fabric OneLake-Sicherheit für das Quellartefakt basieren, unterstützen keine Sicherungsvorgänge.
- Bidirektionale Beziehungen werden in einem Direct Lake-Modell nicht unterstützt, wenn das Fabric-Quellartefakt auf OneLake-Sicherheits-RLS basiert.
- Während der öffentlichen Vorschau unterstützt OneLake-Sicherheit nur statische RLS in einer einzelnen Tabelle.
- Während der öffentlichen Vorschau unterstützt OneLake-Sicherheit 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 Sicherheitskonfiguration von OneLake ändert, z. B. aufgrund von Verknüpfungsänderungen im Zielartefakt, aktualisieren Sie Direct Lake auf OneLake-Modellen, die auf dieses Artefakt zugreifen. Wenn autosync aktiviert ist, aktualisiert der Dienst sie in der Regel automatisch. Andernfalls aktualisieren Sie die Modelle manuell.
- 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.