Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Zabezpieczenia usługi Direct Lake zapewniają, że tylko autoryzowani użytkownicy mogą wykonywać zapytania o tabele delty w usłudze OneLake. Uprawnienia dostępu do danych można zarządzać za pomocą ról obszaru roboczego. Użytkownicy, członkowie i administratorzy przestrzeni roboczej mogą odczytywać dane w OneLake. Możesz również udzielić dostępu do danych w usłudze OneLake za pomocą uprawnień na poziomie elementu i zasobów obliczeniowych. Trzecią opcją jest wykorzystanie zabezpieczeń OneLake do wymuszania szczegółowych zabezpieczeń opartych na rolach we wszystkich aparatach obliczeniowych Fabric. W tym artykule wyjaśniono, jak dostosować modele uprawnień, wybrać logowanie jednokrotne (SSO) lub stałe tożsamości oraz wykorzystać zabezpieczenia na poziomie obiektu (OLS) i zabezpieczenia na poziomie wiersza (RLS). Dowiedz się więcej na temat OneLake security overview (Omówienie zabezpieczeń usługi OneLake).
Kluczowe pojęcia i terminologia
W tym artykule założono, że znasz następujące pojęcia:
- Usługa Direct Lake używa udostępnionych wyrażeń języka M w metadanych modelu semantycznego do odwoływania się do źródeł danych za pośrednictwem funkcji dostępu do danych funkcji Power Query: AzureStorage.DataLake dla Direct Lake na OneLake i Sql.Database dla Direct Lake na punktach końcowych SQL. Jednak usługa Direct Lake nie używa tych funkcji do odczytywania źródłowych tabel delty. Odczytuje tabele delty bezpośrednio za pośrednictwem interfejsów API usługi OneLake.
- Aby zapewnić, że tylko autoryzowani użytkownicy wysyłają zapytania dotyczące danych, usługa Direct Lake sprawdza uprawnienia dostępu do danych obowiązującej tożsamości. Efektywna tożsamość zależy od konfiguracji połączenia danych. Domyślnie usługa Direct Lake używa logowania jednokrotnego (Microsoft Entra ID) i używa tożsamości bieżącego użytkownika wykonującego zapytanie dotyczące modelu semantycznego. Możesz również powiązać model Direct Lake z jawnym połączeniem w chmurze, aby zapewnić stałą tożsamość.
- Jeśli przyznasz uprawnienia dostępu do danych za pośrednictwem ról obszaru roboczego, tylko członkowie roli Współautorzy (lub nowsi) będą mogli odczytywać dane w usłudze OneLake. Osoby przeglądające obszary robocze nie mają jednak uprawnień do odczytu w usłudze OneLake. Osoby przeglądające i użytkownicy, którzy nie należą do żadnej roli w obszarze roboczym, mogą uzyskać dostęp do odczytu za pomocą kombinacji uprawnień elementów, uprawnień obliczeniowych lub ról zabezpieczeń OneLake.
- Zabezpieczenia OneLake umożliwiają członkom ról Administratora obszaru roboczego i Członka obszaru roboczego definiowanie szczegółowych zabezpieczeń opartych na rolach dla użytkowników w roli Przeglądającego. Określ tabele, do których osoba przeglądająca lub użytkownik z jawnym uprawnieniem do odczytu może uzyskać dostęp, oraz wyklucz określone wiersze lub kolumny. Aby dowiedzieć się więcej o rolach zabezpieczeń usługi OneLake, zobacz Zabezpieczenia tabel w usłudze OneLake, zabezpieczenia na poziomie kolumny w usłudze OneLake i RLS w usłudze OneLake.
Konfiguracja połączenia
Skonfiguruj połączenia danych dla modelu Direct Lake tak samo jak inne typy modeli semantycznych. Aby uzyskać szczegółowe informacje, zobacz Łączenie ze źródłami danych w chmurze w usłudze Power BI .
Ponieważ usługa Direct Lake łączy się tylko ze źródłami danych sieci Szkieletowej, domyślna konfiguracja logowania jednokrotnego (Microsoft Entra ID) zwykle działa, więc nie trzeba wiązać modeli semantycznych z jawnymi połączeniami danych. Takie podejście zmniejsza złożoność konfiguracji i zmniejsza obciążenie związane z zarządzaniem.
W przypadku logowania jednokrotnego (Microsoft Entra ID) usługa Direct Lake sprawdza, czy bieżący użytkownik, który wysyła zapytanie do modelu semantycznego, ma dostęp do odczytu do danych. Tylko użytkownicy z dostępem do odczytu mogą zadawać zapytania dotyczące danych. Poniższy zrzut ekranu przedstawia model usługi Direct Lake przy użyciu domyślnej konfiguracji logowania jednokrotnego.
Jeśli używasz jawnego połączenia danych ze stałą identyfikacją zamiast SSO, funkcja Direct Lake nie wymaga od każdego użytkownika uprawnienia do odczytu danych podstawowych. Jeśli usługa Microsoft Entra SSO pozostanie wyłączona w połączeniu danych, uprawnienia stałej tożsamości określają, do jakich danych może uzyskiwać dostęp usługa Direct Lake.
Uwaga / Notatka
Można skonfigurować połączenie danych, aby używało zarówno logowania jednokrotnego (SSO), jak i stałej tożsamości. Usługa Direct Lake sprawdza uprawnienia bieżącego użytkownika w momencie wykonywania zapytania i używa stałej tożsamości do ramkowania i transkodowania w momencie odświeżania. Aby użyć stałej tożsamości dla zapytań i odświeżeń, upewnij się, że logowanie jednokrotne (SSO) jest wyłączone w konfiguracji połączenia danych.
Wymagania dotyczące uwierzytelniania
Modele usługi Direct Lake używają uwierzytelniania identyfikatora Entra firmy Microsoft. W konfiguracji połączenia danych wybierz OAuth 2.0, pryncypał usługi lub tożsamość przestrzeni roboczej jako metodę uwierzytelniania. Inne metody, takie jak uwierzytelnianie klucza lub współdzielonym podpisem dostępu (SAS), mogą pojawić się w interfejsie użytkownika konfiguracji, ale nie są obsługiwane w przypadku modeli Direct Lake.
Wymagania dotyczące uprawnień
Wymagania dotyczące uprawnień różnią się między usługą Direct Lake w punktach końcowych SQL i usługą Direct Lake w usłudze OneLake. Dzieje się tak, ponieważ usługa Direct Lake w punktach końcowych SQL opiera się na punkcie końcowym analizy SQL docelowego źródła danych, natomiast usługa Direct Lake w usłudze OneLake używa interfejsów API usługi OneLake do sprawdzania uprawnień.
Usługa Direct Lake w punktach końcowych SQL
Usługa Direct Lake w punktach końcowych SQL wykonuje kontrole uprawnień za pośrednictwem punktu końcowego analizy SQL, aby określić, czy efektywna tożsamość próbująca uzyskać dostęp do danych ma niezbędne uprawnienia dostępu do danych. W szczególności efektywna tożsamość nie potrzebuje uprawnień do bezpośredniego odczytywania tabel Delta w usłudze OneLake. Wystarczy mieć dostęp odczytu do artefaktu Fabric, takiego jak lakehouse, oraz uprawnienia SELECT do tabeli poprzez jej SQL analytics endpoint. To dlatego, że Fabric przyznaje niezbędne uprawnienia modelowi semantycznemu do odczytu tabel Delta i powiązanych plików Parquet (aby załadować dane kolumn do pamięci). Model semantyczny ma uprawnienia do okresowego odczytywania punktu końcowego analizy SQL w celu sprawdzenia, do jakich danych może uzyskać dostęp użytkownik zapytań (lub stała tożsamość).
Usługa Direct Lake w usłudze OneLake
Direct Lake w OneLake nie używa punktu końcowego analizy SQL do sprawdzania uprawnień. Korzysta z usługi OneLake Security. Po włączeniu zabezpieczeń OneLake, Direct Lake na OneLake używa bieżącego użytkownika (lub stałej tożsamości), aby rozwikłać role zabezpieczeń OneLake i egzekwować zabezpieczenia OLS i RLS na docelowym artefakcie Fabric. Jeśli zabezpieczenia OneLake nie są włączone, usługa Direct Lake w OneLake wymaga, aby efektywna tożsamość miała uprawnienia Odczyt i OdczytWszystkie do docelowego artefaktu w Fabric, aby uzyskać dostęp do tabel Delta w OneLake. Aby uzyskać więcej informacji na temat uprawnień Odczyt i OdczytWszystkie, zobacz sekcję uprawnienia elementu w artykule Omówienie zabezpieczeń usługi OneLake.
Uwaga / Notatka
Współautorzy (lub nowsi) mają uprawnienia Odczyt i OdczytWszystkie w usłudze OneLake. Osoby przeglądające i użytkownicy, którzy nie są członkami żadnej roli w obszarze roboczym, muszą otrzymać uprawnienia Odczyt i OdczytWszystkie albo być dodani do grupy zabezpieczeń OneLake. Aby uzyskać więcej informacji na temat zarządzania grupami zabezpieczeń usługi OneLake, zobacz OneLake data access control model (Model kontroli dostępu do danych w usłudze OneLake).
Użytkownicy usługi Direct Lake
W poniższych scenariuszach wymieniono minimalne wymagania dotyczące uprawnień.
| Scenario | Usługa Direct Lake w punktach końcowych SQL | Usługa Direct Lake w usłudze OneLake | Comments |
|---|---|---|---|
| Użytkownicy mogą wyświetlać raporty | — Udziel uprawnień odczyt dla raportów i uprawnienia Odczyt dla modelu semantycznego. — Jeśli Direct Lake używa logowania jednokrotnego, przyznaj użytkownikom co najmniej uprawnienie odczytu dla docelowego artefaktu Fabric i uprawnienia SELECT dla tabel. |
— Udziel uprawnień odczyt dla raportów i uprawnienia Odczyt dla modelu semantycznego. — Jeśli Direct Lake wykorzystuje logowanie jednokrotne, przyznaj użytkownikom co najmniej uprawnienie Odczyt do docelowego artefaktu Fabric i a także dodaj ich do roli zabezpieczeń OneLake lub przyznaj im uprawnienie ReadAll. |
Raporty nie muszą należeć do tego samego obszaru roboczego co model semantyczny. Aby uzyskać więcej informacji, zobacz Strategia dla użytkowników w trybie tylko do odczytu. |
| Użytkownicy mogą tworzyć raporty | — Udziel uprawnień do tworzenia dla modelu semantycznego. — Jeśli Direct Lake używa SSO, przyznaj użytkownikom co najmniej uprawnienie odczyt dla docelowego artefaktu Fabric i uprawnienia SELECT dla tabel. |
— Udziel uprawnień do tworzenia dla modelu semantycznego. — Jeśli Direct Lake używa jednokrotnego logowania, przyznaj użytkownikom co najmniej uprawnienie Odczyt dla docelowego artefaktu Fabric i dodaj ich do roli zabezpieczeń OneLake lub przyznaj im uprawnienie ReadAll. |
Użytkownicy mogą tworzyć raporty tylko w tabelach i kolumnach, do których mają dostęp. Może to być podzbiór pełnego zestawu tabel i kolumn w modelu. Aby uzyskać więcej informacji, zobacz Strategia dla twórców zawartości. |
| Użytkownicy mogą wykonywać zapytania dotyczące modelu semantycznego, ale nie mają uprawnień do wykonywania zapytań dotyczących lakehouse lub punktu końcowego analizy SQL | — Wiązanie modelu Direct Lake z połączeniem w chmurze z stałą tożsamością i pozostawienie wyłączonego logowania jednokrotnego. — Przyznaj stałej tożsamości co najmniej uprawnienia do odczytu dla docelowego artefaktu Fabric i SELECT dla tabel. — Nie udzielaj użytkownikom żadnych uprawnień dla docelowego artefaktu Fabric. |
— Wiąż model Direct Lake z połączeniem w chmurze z ustaloną tożsamością i pozostaw wyłączone logowanie jednokrotne. — Przyznaj stałej tożsamości co najmniej uprawnienie Odczyt dla docelowego artefaktu Fabric i dodaj ją do roli zabezpieczeń OneLake lub przyznaj jej uprawnienie ReadAll. — Nie udzielaj użytkownikom żadnych uprawnień do docelowego artefaktu Fabric. |
Odpowiednie tylko wtedy, gdy połączenie w chmurze używa stałej tożsamości. |
| Użytkownicy mogą wykonywać zapytania dotyczące modelu semantycznego i punktu końcowego analizy SQL, ale nie mają uprawnień do wykonywania zapytań względem lakehouse | — Udziel uprawnień Odczyt i OdczytData dla docelowego artefaktu Fabric. | Nie dotyczy. | Ważne: Zapytania wysyłane do punktu końcowego analizy SQL pomijają uprawnienia dostępu do danych wymuszane przez model semantyczny. |
| Zarządzanie modelem semantycznym, w tym ustawieniami odświeżania | — Wymaga własności modelu semantycznego. | — Wymaga własności modelu semantycznego. | Aby uzyskać więcej informacji, zobacz Semantic model ownership (Własność modelu semantycznego). |
Ważne
Zawsze testuj uprawnienia przed udostępnieniem modelu semantycznego i raportów do środowiska produkcyjnego.
Aby uzyskać więcej informacji, zobacz Semantic model permissions (Uprawnienia modelu semantycznego).
Właściciele usługi Direct Lake
Oprócz efektywnej tożsamości (bieżącego użytkownika lub stałej tożsamości) Direct Lake również wymaga, aby właściciel modelu semantycznego miał dostęp do odczytu tabel źródłowych, aby Direct Lake mógł opracować model semantyczny w ramach odświeżania danych. Niezależnie od tego, kto odświeża model Direct Lake, usługa Direct Lake sprawdza uprawnienia właściciela, aby upewnić się, że model może uzyskiwać dostęp do danych. Wymagania dotyczące uprawnień dostępu do danych właściciela są takie same jak w przypadku użytkowników, którzy wysyłają zapytania do modelu.
Jeśli właściciel modelu semantycznego nie ma wymaganych uprawnień dostępu do danych, usługa Direct Lake zgłasza następujący błąd podczas tworzenia ramek: 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\>'.
Skróty do tabel źródłowych
Skróty to obiekty OneLake dodawane do usługi Fabric lakehouse lub innego artefaktu sieci szkieletowej w celu wskazywania lokalizacji magazynu wewnętrznego lub zewnętrznego. W modelu Direct Lake tabele Delta dodane za pomocą skrótów są wyświetlane jako natywne w połączonym artefakcie Fabric, ponieważ skróty są przezroczyste podczas dostępu do danych przez interfejs API OneLake.
Gdy uzyskujesz dostęp do skrótów za pośrednictwem usługi Direct Lake za pośrednictwem punktów końcowych SQL, usługa Direct Lake najpierw sprawdza, czy efektywna tożsamość (bieżący użytkownik lub stała tożsamość) może uzyskać dostęp do tabeli w źródle danych modelu semantycznego. W przypadku skrótów wewnętrznych po zakończeniu sprawdzania usługa Direct Lake używa tożsamości właściciela źródła danych do odczytania tabeli delty za pomocą skrótu w artefaktie sieci szkieletowej tabeli. Właściciel źródła danych musi mieć uprawnienia dostępu w docelowej lokalizacji OneLake. W przypadku zewnętrznych skrótów właściciel źródła danych potrzebuje również uprawnienia do korzystania z połączenia chmurowego do zewnętrznego systemu, który hostuje tabelę Delta. Aby uzyskać więcej informacji, zobacz Skróty OneLake.
Usługa Direct Lake za pośrednictwem usługi OneLake ma inne wymagania dotyczące uprawnień, ponieważ punkt końcowy usługi SQL Analytics nie jest zaangażowany. Gdy użytkownik uzyskuje dostęp do danych za pośrednictwem wewnętrznego skrótu do innej lokalizacji OneLake, obowiązująca tożsamość (bieżący użytkownik lub stała tożsamość) musi mieć uprawnienia w lokalizacji docelowej. Obowiązująca tożsamość musi być współautorem (lub wyższym), mieć uprawnienia Odczyt i OdczytWszystkie lub być w roli zabezpieczeń OneLake, która udziela dostępu do odczytu .
Zabezpieczenia na poziomie obiektu (OLS) i zabezpieczenia na poziomie wiersza (RLS)
Oba modele OneLake Security i Direct Lake obsługują OLS oraz RLS. Usługa OLS umożliwia właścicielom artefaktów i administratorom zabezpieczanie określonych tabel lub kolumn. RLS może być używane do ograniczania dostępu do danych na poziomie wiersza na podstawie filtrów. Zabezpieczenia OLS i RLS można zdefiniować w systemie OneLake Security, w modelu Direct Lake, lub w obu miejscach.
Ważne
Usługa Direct Lake nie obsługuje zabezpieczeń OLS/RLS punktu końcowego usługi SQL Analytics. Aby zwrócić poprawne dane, usługa Direct Lake za pośrednictwem punktów końcowych SQL powraca do trybu DirectQuery, jeśli artefakt sieci szkieletowej używa zabezpieczeń na poziomie wiersza lub OLS. Jeśli rezerwowa funkcja DirectQuery jest wyłączona, zapytania dotyczące punktów końcowych SQL kończą się niepowodzeniem, gdy zabezpieczenia OLS/RLS są definiowane w punkcie końcowym usługi SQL Analytics. Direct Lake w ramach OneLake unika tego ograniczenia.
Usługa Direct Lake w ramach zabezpieczeń OneLake OLS/RLS
Usługa Direct Lake w OneLake ocenia dostęp do objętych polityką OLS/RLS zabezpieczonych obiektów poprzez rozpoznanie ról zabezpieczeń OneLake dla aktualnej tożsamości i zastosowanie zdefiniowanych reguł OLS/RLS. Role zabezpieczeń w OneLake są zarządzane tak samo jak role w Direct Lake. Jeśli efektywna tożsamość należy do wielu ról w usłudze OneLake Security i Direct Lake, usługa Direct Lake najpierw łączy role OneLake Security, a następnie krzyżuje wynik tej operacji z rolami w usłudze Direct Lake.
W tej tabeli wymieniono typowe sytuacje rozwiązywania problemów spowodowane konfliktem reguł oneLake Security i Direct Lake.
| Scenario | Comments |
|---|---|
| Brak zwracanych wierszy z powodu filtrowania zabezpieczeń RLS na poziomie wiersza | Jeśli efektywna tożsamość nie ma uprawnień dostępu na poziomie wiersza, zapytania mogą zwracać puste wyniki. To zachowanie jest oczekiwane, gdy filtry RLS wykluczają wszystkie wiersze bieżącego użytkownika. |
| Nie można odnaleźć tabeli Nie można odnaleźć kolumny Nie można rozpoznać nazwy Nieprawidłowa tabela, zmienna lub nazwa funkcji |
Te błędy zwykle występują, gdy brakuje uprawnień obiektu po zastosowaniu ról zabezpieczeń OneLake. |
Różnice zakresu OLS/RLS
Egzekwowanie zabezpieczeń OLS i RLS w OneLake Security stosuje reguły we wszystkich silnikach obliczeniowych i zapewnia spójną kontrolę dostępu dla użytkowników. Oznacza to, że niezależnie od aparatu obliczeniowego — lakehouse, warehouse, semantic model lub innego artefaktu — reguły zabezpieczeń OneLake kontrolują dostęp do danych użytkownika. Z kolei zabezpieczenia OLS/RLS zdefiniowane w modelu semantycznym usługi Direct Lake mają zastosowanie tylko w zakresie tego modelu. Inne aparaty obliczeniowe nie stosują tych reguł zabezpieczeń usługi Direct Lake, które mogą generować różne wyniki, gdy użytkownicy uzyskują dostęp do danych za pośrednictwem innych ścieżek.
Ważne
W przypadku używania zabezpieczeń OneLake OLS/RLS i Direct Lake OLS/RLS użytkownicy, którzy mają dostęp do OneLake, nadal mogą bezpośrednio pobierać dane i pracować z nimi — nawet jeśli reguły modelu Direct Lake jeszcze bardziej ograniczają dane — ponieważ reguły na poziomie modelu nie są stosowane poza modelem. Użyj usługi OneLake Security, aby uzyskać kompleksową kontrolę dostępu we wszystkich aparatach obliczeniowych.
Metadane modelu semantycznego i OneLake OLS
Metadane modelu semantycznego obejmują definicje tabel, kolumn, relacji i innych elementów schematu. Użytkownicy z uprawnieniami kompilacji lub wyższymi mogą wyświetlać metadane modelu za pośrednictwem kodu XML dla Analizy (XMLA) i interfejsów REST API. Aby uzyskać więcej informacji, zobacz Semantic model permissions (Uprawnienia modelu semantycznego).
Aby chronić poufne nazwy tabel i kolumn w usłudze OneLake za pomocą usługi OneLake OLS, należy pamiętać, że zabezpieczenia OneLake mają zastosowanie tylko do członków roli Podglądacza obszaru roboczego. Usługa OneLake OLS nie uniemożliwia członkom roli obszaru roboczego Współautor (lub wyższa) odnajdywanie zabezpieczonych tabel lub kolumn, ponieważ mają już uprawnienie Zapis do wszystkich artefaktów obszaru roboczego. Członkowie roli przeglądającego z uprawnieniami kompilacji lub wyższymi do modelu Direct Lake mogą odnajdywać poufne informacje o schemacie poprzez metadane modelu semantycznego. Ci bardziej uprzywilejowani użytkownicy nadal nie mają dostępu do danych, ale widzą, że istnieją zabezpieczone tabele i kolumny.
Model usługi Direct Lake może istnieć w tym samym obszarze roboczym co artefakt źródłowy lub w osobnym obszarze roboczym. Przyznaj osobie oglądającej w tym samym obszarze roboczym dostęp do modelu Direct Lake poprzez przyznanie uprawnień do elementu na poziomie poziomu (lub wyższym). W osobnym obszarze roboczym użytkownik może być współautorem (lub wyższym) lub mieć uprawnienia do tworzenia (lub wyższego) elementu w celu uzyskania dostępu do metadanych modelu.
Integracja OneLake OLS i Git
Integracja z usługą Git umożliwia deweloperom integrowanie procesów zarządzania cyklem życia aplikacji (ALM) z platformą sieci szkieletowej. Repozytorium Git zachowuje strukturę obszaru roboczego, w tym wszystkie obsługiwane artefakty. Deweloperzy mają pełny wgląd w metadane wszystkich swoich elementów w repozytorium Git. Metadane modelu usługi Direct Lake umożliwiają im sprawdzenie, czy zabezpieczone tabele lub kolumny istnieją, nawet jeśli nie mają dostępu do docelowego źródła danych w innym obszarze roboczym. Aby uzyskać więcej informacji, zobacz Co to jest integracja z usługą Microsoft Fabric Git?
Uwagi i ograniczenia
Weź pod uwagę te ograniczenia zabezpieczeń usługi Direct Lake.
Uwaga / Notatka
Możliwości i funkcje modeli semantycznych usługi Direct Lake i zabezpieczeń usługi OneLake szybko ewoluują. Okresowo sprawdzaj aktualizacje.
- Przypisz przeglądających obszary robocze rolom zabezpieczeń OneLake, które udzielają dostępu do odczytu do źródłowych artefaktów Fabric. Jeśli artefakt źródłowy zawiera skróty do innego artefaktu sieci szkieletowej, użytkownik musi również mieć dostęp do odczytu do docelowego artefaktu sieci szkieletowej każdego skrótu.
- Użyj stałej tożsamości, aby odizolować użytkowników od artefaktu źródłowej sieci szkieletowej. Wiązanie modelu Direct Lake z połączeniem w chmurze. Pozostaw logowanie jednokrotne wyłączone w połączeniu w chmurze, aby używać stałej tożsamości na potrzeby odświeżeń i zapytań.
- Semantyczne modele usługi Direct Lake, które korzystają z zabezpieczeń usługi Fabric OneLake w artefaktzie źródłowym, nie obsługują operacji tworzenia kopii zapasowych.
- Relacje dwukierunkowe nie są obsługiwane w modelu Direct Lake, jeśli źródłowy artefakt Fabric opiera się na zabezpieczeniach OneLake.
- W publicznej wersji zapoznawczej zabezpieczenia usługi OneLake obsługują tylko statyczne zabezpieczenia na poziomie wiersza w jednej tabeli.
- W publicznej wersji zapoznawczej zabezpieczenia usługi OneLake nie obsługują definicji dynamicznych ani złożonych konfiguracji ról, takich jak łączenie wielu ról OLS i RLS między powiązanymi tabelami.
- Konsolidowanie zabezpieczeń usługi OneLake i uprawnień RLS i OLS do jednej roli na użytkownika zamiast przypisywania wielu ról.
- Jeśli konfiguracja zabezpieczeń OneLake ulegnie zmianie, na przykład ze względu na zmiany skrótów w docelowym artefakcie, odśwież modele Direct Lake w OneLake, które uzyskują dostęp do artefaktu. Jeśli funkcja automatycznego synchronizowania jest włączona, usługa zwykle odświeża je automatycznie. Inaczej zaktualizuj modele ręcznie.
- Jeśli Lakehouse ma zabezpieczenia OneLake:
- Punkt końcowy analizy SQL jest domyślnie trwale przypisany do właściciela Lakehouse, więc zabezpieczenia punktu końcowego dla analizy SQL w OneLake są takie same jak te właściciela i nie podlegają ograniczeniom. Usługa Direct Lake w usłudze SQL pozostaje przy użyciu usługi Direct Lake, chyba że dodano dodatkowe szczegółowe role dostępu SQL.
- Punkt końcowy analizy SQL można zmienić na SSO. W takim przypadku role zabezpieczeń usługi OneLake są dodawane jako reguły szczegółowej kontroli dostępu SQL, a użytkownik nie może edytować ich bezpośrednio w punkcie końcowym analizy SQL. W tym momencie usługa Direct Lake w usłudze SQL powraca do trybu DirectQuery 100% czasu.