Zabezpieczenia usługi OneLake dla punktów końcowych analizy SQL

Dzięki zastosowaniu zabezpieczeń OneLake administratorzy mogą wybierać między scentralizowanym zarządzaniem w OneLake a szczegółową kontrolą opartą na SQL w punkcie końcowym analityki SQL.

Tryby dostępu w punkcie końcowym analizy SQL

W przypadku korzystania z punktu końcowego analizy SQL, wybrany tryb dostępu określa sposób wymuszania zabezpieczeń danych. Architektura sieciowa obsługuje dwa odrębne modele dostępu, z których każdy oferuje różne korzyści w zależności od Twoich potrzeb operacyjnych i zgodności.

• Tryb tożsamości użytkownika: Egzekwuje bezpieczeństwo poprzez wykorzystanie ról i polityk OneLake. W tym trybie punkt końcowy analizy SQL przekazuje tożsamość zalogowanego użytkownika do usługi OneLake, a dostęp do odczytu podlega całkowicie regułom zabezpieczeń zdefiniowanym w usłudze OneLake. Ten tryb obsługuje uprawnienia na poziomie SQL dla obiektów niebędących danymi, takich jak widoki, procedury przechowywane i funkcje, zapewniając spójne zarządzanie narzędziami takimi jak Power BI, notebooki i lakehouse.

• Tryb tożsamości delegowanej: umożliwia pełną kontrolę za pośrednictwem języka SQL. W tym trybie punkt końcowy analizy SQL łączy się z usługą OneLake przy użyciu tożsamości obszaru roboczego lub właściciela elementu, a zasady zabezpieczeń są określane wyłącznie przez uprawnienia SQL zdefiniowane w bazie danych. Model ten wspiera tradycyjne podejścia bezpieczeństwa, w tym GRANT, REVOKE, role niestandardowe, bezpieczeństwo na poziomie wiersza oraz dynamiczne maskowanie danych.

Każdy tryb obsługuje różne modele ładu. Zrozum ich konsekwencje, aby wybrać odpowiednie podejście dla swojego środowiska Fabric.

Porównanie trybów dostępu

W poniższej tabeli porównano sposób i miejsce ustawiania zabezpieczeń w trybie tożsamości użytkownika w porównaniu z trybem tożsamości delegowanej, podzielonym według typu obiektu i zasad dostępu do danych:

Zmień tryb dostępu do OneLake

Tryb dostępu określa sposób uwierzytelniania i wymuszania dostępu do danych podczas wykonywania zapytań w usłudze OneLake za pośrednictwem punktu końcowego analizy SQL. Nowo utworzone punkty końcowe analityki SQL są domyślnie uruchamiane w trybie dostępu z delegowaną tożsamością. Zanim będziesz mógł korzystać z zabezpieczeń OneLake na punkcie końcowym, administrator lub członek musi przełączyć go na tryb dostępu do tożsamości użytkownika.

1. Przejdź do punktu końcowego analizy SQL.

2. W środowisku punktu końcowego analizy SQL wybierz kartę Zabezpieczenia .

3. Wybierz pozycję Wyświetl tryb dostępu do danych>Ustawienia trybu dostępu do danych.

   

4. Wybierz tryb dostępu do tożsamości użytkownika , aby użyć tożsamości użytkownika zalogowanego i wymusić role bezpieczeństwa OneLake, lub wybierz tryb dostępu do tożsamości delegowanej , aby użyć tożsamości właściciela przedmiotu i wymusić tylko uprawnienia SQL. Następnie wybierz pozycję Zastosuj.

   

5. Wybierz pozycję Kontynuuj , aby potwierdzić wybór.

Tryb tożsamości użytkownika w zabezpieczeniach usługi OneLake

W trybie tożsamości użytkownika, punkt końcowy analizy SQL używa mechanizmu uwierzytelniania passthrough w celu wymuszenia dostępu do danych. Kiedy użytkownik łączy się z punktem końcowym analizy SQL, jego tożsamość Entra ID jest przekazywana do OneLake, który przeprowadza sprawdzanie uprawnień. Wszystkie operacje odczytu względem tabel są oceniane przy użyciu reguł zabezpieczeń zdefiniowanych w usłudze OneLake Lakehouse, a nie przez żadne instrukcje GRANT ani na poziomie REVOKE SQL.

Ten tryb umożliwia centralne zarządzanie zabezpieczeniami, zapewniając spójne wymuszanie we wszystkich środowiskach Fabric, w tym Power BI, notesach, lakehouse i punkcie końcowym analizy SQL. Jest ona przeznaczona dla modeli ładu, w których dostęp powinien zostać zdefiniowany raz w usłudze OneLake i automatycznie respektowany wszędzie.

W trybie tożsamości użytkownika:

• Dostęp do tabeli jest całkowicie uzależniony od zabezpieczeń usługi OneLake. Instrukcje SQL GRANT/REVOKE w tabelach są ignorowane.

• Doświadczenie OneLake definiuje RLS (bezpieczeństwo na poziomie wiersza), CLS (bezpieczeństwo na poziomie kolumn) oraz bezpieczeństwo na poziomie obiektowym.

• Uprawnienia SQL są dozwolone dla obiektów niezwiązanych z danymi, takich jak widoki, procedury składowane i funkcje, co umożliwia elastyczne definiowanie niestandardowej logiki lub punktów wejścia skierowanych do użytkownika do danych.

• Operacje zapisu nie są obsługiwane w punkcie końcowym analizy SQL. Wszystkie operacje zapisu muszą być wykonywane za pośrednictwem strony Lakehouse w portalu Fabric i podlegają rolom w obszarze roboczym (Administrator, Członek, Współpracownik).

Więcej informacji o modelu uprawnień w trybie tożsamości użytkownika znajdziesz w artykule Jak bezpieczeństwo OneLake kontroluje dostęp do danych.

Synchronizacja zabezpieczeń między punktem końcowym usługi OneLake i punktem końcowym analizy SQL

Krytycznym składnikiem trybu tożsamości użytkownika jest usługa synchronizacji zabezpieczeń. Ta usługa w tle monitoruje zmiany wprowadzone w rolach zabezpieczeń w usłudze OneLake i zapewnia, że te zmiany zostaną odzwierciedlone w punkcie końcowym analizy SQL.

Usługa synchronizacji zabezpieczeń jest odpowiedzialna za następujące kwestie:

• Wykrywanie zmian w rolach usługi OneLake, w tym nowych ról, aktualizacji, przypisań użytkowników i zmian w tabelach.

• Tłumaczenie zasad zdefiniowanych przez usługę OneLake (RLS, CLS, OLS) na równoważne struktury ról bazy danych zgodne z programem SQL.

• Upewnienie się, że obiekty skrótów skrótowych (tabele pochodzące z innych lakehouse'ów) są prawidłowo weryfikowane, tak że oryginalne ustawienia zabezpieczeń usługi OneLake są przestrzegane, nawet w przypadku dostępu zdalnego.

Ta synchronizacja gwarantuje, że definicje zabezpieczeń usługi OneLake pozostają autorytatywne, eliminując konieczność ręcznej interwencji na poziomie SQL w celu replikowania zachowania zabezpieczeń. Ponieważ zabezpieczenia są wymuszane centralnie:

• W tym trybie nie można definiować RLS, CLS ani OLS bezpośrednio przy użyciu języka T-SQL.

• Nadal można stosować uprawnienia SQL do widoków, funkcji i procedur składowanych przy użyciu instrukcji GRANT lub EXECUTE.

Ponów próbę wycofywania synchronizacji zabezpieczeń

Synchronizacja zabezpieczeń obejmuje mechanizm ponawiania prób w celu ochrony stabilności systemu i uniknięcia niepotrzebnego użycia zasobów obliczeniowych:

• Jeśli podczas stosowania ról zabezpieczeń Usługi OneLake do punktu końcowego analizy SQL wystąpią powtarzające się błędy, system może tymczasowo wstrzymać próby automatycznej synchronizacji.

• Synchronizacja jest wznawiana automatycznie po zmodyfikowaniu istniejącej roli zabezpieczeń usługi OneLake lub utworzeniu nowej.

Błędy synchronizacji zabezpieczeń i rozwiązywanie problemów

Zachowanie skrótów w synchronizacji bezpieczeństwa

Zabezpieczenia oneLake są wymuszane w źródle prawdy, dlatego synchronizacja zabezpieczeń wyłącza tworzenie łańcuchów własności dla tabel i widoków obejmujących skróty. Dzięki temu uprawnienia systemu źródłowego są zawsze oceniane i honorowane, nawet w przypadku zapytań z innej bazy danych.

W efekcie:

• Użytkownicy muszą mieć prawidłowy dostęp zarówno do skrótu źródła (aktualny Lakehouse lub punkt końcowy analizy SQL), jak i do miejsca docelowego, gdzie dane są fizycznie przechowywane.

• Jeśli użytkownik nie ma uprawnień po obu stronach, zapytania kończą się niepowodzeniem z powodu błędu dostępu.

Ten projekt zachowuje integralność bezpieczeństwa w granicach domów nad jeziorem, jednocześnie zmniejszając potrzebę powielania przypisów tożsamości między produktami producenczymi i konsumentami.

Tryb delegowany w zabezpieczeniach usługi OneLake

W trybie delegowanej tożsamości punkt końcowy analityki SQL zachowuje kompatybilność wsteczną z tradycyjnym modelem zabezpieczeń SQL. Definiujesz i egzekwujesz bezpieczeństwo na warstwie silnika SQL, a role bezpieczeństwa i polityki dostępu OneLake nie przenoszą się na dostęp na poziomie tabeli. Musisz zdefiniować całe filtrowanie i kontrolę dostępu – w tym dostęp do schematów i tabel, bezpieczeństwo na poziomie wiersza (RLS), bezpieczeństwo na poziomie kolumn (CLS) oraz dynamiczne maskowanie danych (DDM) – za pomocą konstrukcji SQL (GRANT/REVOKE, polityki bezpieczeństwa i tak dalej).

Ponieważ role zabezpieczeń w usłudze OneLake dla użytkownika końcowego nie są wymuszane bezpośrednio, żadne reguły zabezpieczeń zdefiniowane w usłudze OneLake (na przykład reguły wymuszane przez silnik Spark lub inne silniki, które odczytują dane za pośrednictwem usługi OneLake) nie będą stosowane, gdy te same dane są zapytane za pośrednictwem punktu końcowego analizy SQL. Wybierz ten tryb, gdy obciążenie zależy od semantyki zabezpieczeń natywnych dla języka SQL lub gdy istniejące narzędzia T-SQL wymagają pełnej zgodności.

Gdy użytkownik nawiązuje połączenie z punktem końcowym analizy SQL i wysyła zapytanie:

• Program SQL weryfikuje zapytanie względem uprawnień zdefiniowanych w warstwie SQL.

• Jeśli zapytanie zostanie autoryzowane, system przechodzi do dostępu do danych przechowywanych w OneLake.

• Ten dostęp do danych jest wykonywany przy użyciu tożsamości właściciela punktu końcowego usługi Lakehouse lub analizy SQL, znanego również jako konto elementu , a nie zalogowanego użytkownika.

W związku z tym właściciel elementu jest odpowiedzialny za posiadanie wystarczających uprawnień w usłudze OneLake w celu odczytania źródłowych plików w imieniu obciążenia. Wszelkie niezgodności między uprawnieniami SQL przyznanymi użytkownikom końcowym a dostępem właściciela elementu OneLake powoduje błędy zapytań.

Ten tryb obsługuje istniejące narzędzia i praktyki T-SQL używane przez administratorów baz danych lub aplikacje, z pełną zgodnością dla SQLGRANT/REVOKE na wszystkich poziomach obiektów oraz z RLS, CLS i DDM zdefiniowanymi przez SQL.

Zachowanie skrótów w trybie delegowanym

Ponieważ tryb delegowany łączy się z OneLake poprzez tożsamość właściciela elementu, skróty działają tylko wtedy, gdy właściciel ma nieograniczony dostęp do całej tabeli źródłowej. Jeśli w tabeli źródłowej zastosowano jakąkolwiek regułę bezpieczeństwa na poziomie OneLake – taką jak bezpieczeństwo na poziomie wiersza (RLS) lub bezpieczeństwo na poziomie kolumn (CLS) – punkt końcowy analityki SQL blokuje dostęp do tego skrótu.

W efekcie:

• Skróty wskazujące tabele źródłowe bez reguł zabezpieczeń na poziomie danych działają normalnie w trybie delegowanym.

• Skróty wskazujące tabele źródłowe z zabezpieczeniami na poziomie wiersza (RLS) lub CLS w zabezpieczeniach OneLake producenta nie są dostępne za pośrednictwem interfejsu analizy SQL w trybie delegowanym, nawet jeśli użytkownik końcowy ma uprawnienia SQL do obiektu skrótu.

• Aby korzystać ze skrótów, których źródło ma zasady zabezpieczeń usługi OneLake, użyj trybu tożsamości użytkownika na konsumenckim punkcie końcowym, aby tożsamość użytkownika końcowego była oceniana względem reguł zabezpieczeń OneLake źródła.

Zagadnienia dotyczące przełączania między trybami

Przełączanie do trybu tożsamości użytkownika

• Zabezpieczenia na poziomie wiersza SQL, CLS i uprawnienia na poziomie tabeli są ignorowane.

• Aby użytkownicy mogli utrzymać dostęp, należy skonfigurować role OneLake.

• Tylko użytkownicy z uprawnieniami przeglądarki lub udostępnionym dostępem tylko do odczytu podlegają bezpieczeństwu usługi OneLake.

• Istniejące role SQL są usuwane i nie można ich odzyskać.

Przełączanie do trybu tożsamości delegowanej

• Role oneLake i zasady zabezpieczeń nie są już stosowane.

• Role SQL i zasady zabezpieczeń stają się aktywne.

• Właściciel elementu musi mieć prawidłowy dostęp do OneLake, w przeciwnym razie wszystkie zapytania mogą zakończyć się niepowodzeniem.

Uwagi

• Obiekty SQL nie dziedziczą własności: Skróty działają jako tabele w punkcie końcowym analizy SQL, ale celowo odbiegają od standardowego łańcucha własności SQL w celu zachowania ujednoliconego stanu zabezpieczeń.

  • Reguła braku dziedziczenia: pochodne obiekty SQL (widoki, procedury składowane lub funkcje) nie dziedziczą uprawnień od właściciela obiektu.

  • Walidacja środowiska uruchomieniowego: uprawnienia są weryfikowane względem tożsamości osoby wywołującej w czasie wykonywania, dzięki czemu abstrakcje SQL nie mogą obejść zasad na poziomie usługi OneLake.

• Zależność w płaszczyźnie sterowania i skuteczna ocena tożsamości: Użytkownicy muszą posiadać wymagane uprawnienia do artefaktów Fabric, zanim będą mogli połączyć się z punktem końcowym analizy SQL. Następnie mechanizm autoryzacji danych ocenia zalogowanego użytkownika oraz rzeczywiste członkostwo użytkownika w obsługiwanych grupach Microsoft Entra na podstawie zasad zabezpieczeń OneLake u źródła.

• Zachowanie oceny uprawnień: Ocena uprawnień różni się w zależności od typu tabeli na podstawie bieżącego modelu egzekwowania.

  • Tabele skrótów: dostęp może zostać odrzucony, jeśli wymagane warunki autoryzacji nie są spełnione. Jest to restrykcyjny efekt egzekwowania, a nie rolowa funkcja DENY w zabezpieczeniach usługi OneLake.

  • Reguła ogólna: Jeśli wymuszanie nie może wyraźnie zweryfikować dostępu, system stosuje najbardziej restrykcyjny wynik.

• Projekt bezpieczeństwa na poziomie kolumn (CLS): CLS utrzymuje ścisłą listę dozwolonych kolumn.

  • Zmiana nazwy lub usunięcie dozwolonej kolumny powoduje unieważnienie reguły zabezpieczeń. Podczas gdy reguła istnieje w systemie, pozostaje nieaktywna — odmawiając całkowitego dostępu do zasobu — dopóki oryginalna nazwa kolumny nie zostanie przywrócona.

  • Ochrona synchronizacji: jeśli zasady są nieprawidłowe, synchronizacja metadanych jest blokowana zgodnie z projektem, dopóki reguła nie zostanie poprawiona w panelu zabezpieczeń OneLake.

  • Walidacja schematu: zmiana nazw kolumn bez aktualizowania zasad zabezpieczeń wyzwala błędy interfejsu użytkownika z informacją, że kolumna "nie istnieje", dopóki konfiguracja nie zostanie zsynchronizowana.

  Note

  W punkcie końcowym analizy danych SQL w przypadku dostępu do danych egzekwowane są zabezpieczenia usługi OneLake, natomiast metadane schematu nadal podlegają działaniu silnika SQL. Użytkownicy mogą widzieć kolumny w Eksplorator obiektów lub sys.columns nawet wtedy, gdy zabezpieczenia na poziomie kolumn uniemożliwiają odczyt tych kolumn. To zachowanie jest oczekiwane i zgodnie z projektem.

• Propagacja i synchronizacja ról (SLA):

  • Synchronizacja zabezpieczeń usługi OneLake: gdy rola zabezpieczeń oneLake zmieni się w trybie tożsamości użytkownika, aktualizacja nie jest natychmiastowa. Zazwyczaj szybka, synchronizacja z punktem końcowym analizy SQL może zająć do 5 minut.

  • Automatyczne prefiksowanie: role zabezpieczeń OneLake są propagowane do punktu końcowego analizy SQL z prefiksem OLS_ .

  • Priorytet synchronizacji: proces synchronizacji zabezpieczeń okresowo odświeża stan OLS_ ról. Ręczne zmiany tych ról nie są obsługiwane i są zastępowane podczas następnego cyklu synchronizacji. Jeśli synchronizacja nie powoduje żadnych zmian, synchronizacja zabezpieczeń nie zastępuje zmian ręcznych.

• Bezpieczeństwo SQL magazynu i skróty: Polityki bezpieczeństwa definiowane za pomocą konstrukcji SQL w magazynie – takie jak bezpieczeństwo na poziomie wiersza (RLS), bezpieczeństwo na poziomie kolumn (CLS) lub bezpieczeństwo na poziomie obiektowym (OLS) – są egzekwowane wyłącznie w kontekście wykonywania SQL magazynu (punkt końcowy TDS).

Ograniczenia

• Dotyczy tylko czytelników: Bezpieczeństwo OneLake jest głównie egzekwowane dla użytkowników uzyskujących dostęp do danych poprzez obszar roboczy lub dostęp do elementu na poziomie Viewer. Użytkownicy z szerszymi rolami obszaru roboczego, takimi jak Administrator, Członek lub Współautor , zachowują podwyższony poziom dostępu i nie są głównym celem wymuszania zabezpieczeń usługi OneLake.

  • Wyjątki:

    • Zachowanie odmowy skrótów: w przypadku tabel obsługiwanych przez skróty kontrola dostępu nadal może blokować dostęp dla administratorów, członków lub współtwórców w określonych przypadkach.

    • Przypadki niepowodzenia synchronizacji zabezpieczeń: jeśli synchronizacja zabezpieczeń nie może poprawnie zastosować zabezpieczeń dla niektórych tabel lub ról, użytkownicy w rolach Administrator, Członek lub Współautor, którzy są członkami tych ról, których dotyczy problem, mogą również mieć ograniczony dostęp.

    • RLS w trybie tożsamości użytkownika: Gdy bezpieczeństwo na poziomie wiersza (RLS) jest skonfigurowane w trybie tożsamości użytkownika, zdefiniowane reguły bezpieczeństwa są egzekwowane dla wszystkich użytkowników, w tym tych pełniących role Administratora, Członka i Współtwórcy.

• Widoczność schematu w metadanych obiektu: punkt końcowy analizy SQL zawsze zwraca wszystkie nazwy schematów w metadanych obiektu, niezależnie od uprawnień na poziomie tabeli użytkownika. Tabele, dla których użytkownik nie ma uprawnień, są filtrowane i nie są wyświetlane na liście.

  • W związku z tym użytkownicy mogą zobaczyć schematy, które nie zawierają widocznych tabel w Eksploratorze obiektów lub w INFORMATION_SCHEMA/sys zapytaniach wykazu.

• Zależność synchronizacji bezpieczeństwa: W trybie tożsamości użytkownika proces synchronizacji bezpieczeństwa synchronizuje role bezpieczeństwa OneLake z punktem końcowym analizy SQL. Do czasu zakończenia synchronizacji SQL może tymczasowo oceniać dostęp, korzystając z istniejącego stanu uprawnień SQL dla wszystkich tabel, w tym tabel skrótów z innych elementów. Po zakończeniu synchronizacji punkt końcowy SQL odzwierciedla konfigurację zabezpieczeń usługi OneLake.

• Zmiany własności w tabelach opartych na skrótach: tabele oparte na skrótach są reprezentowane jako obiekty SQL w punkcie końcowym analizy SQL i w związku z tym obsługują standardowe operacje własności SQL. Polecenia administracyjne, takie jak ALTER AUTHORIZATION , mogą zmieniać właściciela tabeli opartej na skrótach. W niektórych scenariuszach może to umożliwić zachowanie pozwalające na łańcuchowe przypisywanie właścicieli, które pomija zasady zabezpieczeń usługi OneLake i prowadzi do niezamierzonego przyznawania dostępu do danych bazowych. Dopóki nie zostaną wprowadzone dodatkowe mechanizmy wymuszania, administratorzy powinni unikać modyfikowania własności w tabelach opartych na skrótach.

• Przestój weryfikacji docelowego elementu: gdy cel skrótu ulegnie zmianie (na przykład zmiana nazwy lub aktualizacja adresu URL), baza danych na krótko przechodzi w tryb pojedynczego użytkownika, podczas gdy system weryfikuje nowy element docelowy. W tym okresie zapytania są blokowane. Te operacje są zwykle szybkie, ale w zależności od procesów wewnętrznych synchronizacja może potrwać do 5 minut.

  • Tworzenie skrótów schematu może spowodować znany błąd, który wpływa na walidację i opóźnia synchronizację metadanych.

• Buforowanie tokenów trybu delegowanego: w trybie delegowanym punkt końcowy analizy SQL buforuje token dostępu do magazynu używany do pobierania danych z usługi OneLake w imieniu tożsamości właściciela. Jeśli uprawnienia właściciela zmienią się, wcześniej wystawiony token może pozostać ważny do momentu jego wygaśnięcia. W związku z tym zmiany dostępu powiązane z tożsamością właściciela mogą nie obowiązywać natychmiast i mogą być utrwalane do momentu wygaśnięcia tokenu, zazwyczaj do 30–60 minut.

• Zmiany w zasadach GRANT/DENY zabezpieczeń usługi OneLake są stosowane natychmiastowo i nie są opóźnione przez buforowanie pamięci masowej.

• Aktywne anulowanie zapytania: aby zachować integralność danych i zabezpieczenia, aktywne zapytania mogą zostać automatycznie anulowane, jeśli podczas wykonywania zmieni się konfiguracja skrótu.

• Ograniczenia bezpieczeństwa na poziomie wiersza (RLS):

  • Obsługiwane są tylko tabele z pojedynczym wyrażeniem. Dynamiczny mechanizm RLS i mechanizm RLS dla wielu tabel nie są dostępne.

  • Usuwanie kolumny używanej w wyrażeniu filtru blokuje synchronizację metadanych, aż do naprawienia zabezpieczeń na poziomie wiersza (RLS) w panelu bezpieczeństwa OneLake.

• Złożoność ról i synchronizacja metadanych: Wysoka złożoność ról bezpieczeństwa — w szczególności tych obejmujących wiele przecięć i semantyki unii przy użyciu RLS — może spowodować niepowodzenie synchronizacji zabezpieczeń. Nieudana synchronizacja zabezpieczeń uniemożliwia stosowanie zasad zabezpieczeń i blokuje możliwość synchronizowania metadanych.

• Ograniczenia schematu i roli:

  • Zmiany nazw: role zabezpieczeń OneLake są powiązane z nazwą tabeli. Zmiana nazwy tabeli powoduje przerwanie powiązania, a zasady nie są migrowane automatycznie. Może to spowodować niezamierzone ujawnienie danych do momentu ponownego zastosowania zasad.

  • Limity znaków: nazwy ról zabezpieczeń OneLake nie mogą przekraczać 124 znaków; w przeciwnym razie tworzenie lub synchronizacja roli kończy się niepowodzeniem w punkcie końcowym analizy SQL.

  • OLS_ modyfikacje ról: Zmiana ról przez OLS_ użytkowników nie jest obsługiwana i może powodować nieoczekiwane zachowania.

• Nieobsługiwane identyfikatory: Grupy zabezpieczeń przystosowane do obsługi poczty i listy dystrybucyjne nie są obecnie wspierane.

• Wymagania posiadacza Lakehouse:

  • Właściciel lakehouse musi być członkiem ról obszaru roboczego Administrator, Członek lub Współautor; w przeciwnym razie zabezpieczenia nie są stosowane do punktu końcowego analizy SQL.

Treści powiązane

• Najlepsze rozwiązania dotyczące zabezpieczania danych w usłudze OneLake
• Jak OneLake zabezpieczenia kontrolują dostęp do danych