Jak OneLake zabezpieczenia kontrolują dostęp do danych

Bezpieczeństwo OneLake to system oparty na rolach, który decyduje, kto może uzyskać dostęp do danych w OneLake i jakie działania może podjąć na tych danych. Zrozumienie modelu kontroli dostępu do danych pozwala użytkownikom przyznać tylko taki dostęp, jakiego potrzebują, dzięki czemu możesz chronić wrażliwe dane, jednocześnie pozwalając właściwym osobom z nimi pracować.

Ten artykuł wyjaśnia, jak zorganizowane są role bezpieczeństwa OneLake, jak integrują się z uprawnieniami do przestrzeni roboczej i elementów, jak OneLake stosuje i rozwiązuje dostęp do Twoich danych oraz jakie ograniczenia należy mieć na uwadze.

Role zabezpieczeń usługi OneLake

Bezpieczeństwo OneLake wykorzystuje model kontroli dostępu oparty na rolach (RBAC) do zarządzania dostępem do danych w OneLake. W doświadczeniu bezpieczeństwa OneLake każda rola składa się z następujących elementów:

• Uprawnienia: Uprawnienia, jakie rola przyznaje względem danych, takie jak Odczyt lub Odczyt i zapis.
• Typ: Typ roli. Zabezpieczenia OneLake obsługują tylko role typu Grant, które zapewniają członkom dostęp do danych przypisanych do tej roli. Nie obsługuje ról typu Deny, które usuwają dostęp.
• Dane w roli: Tabele, foldery lub schematy, do których dana rola daje dostęp. Możesz także zdefiniować dostęp do danych z zabezpieczeniami na poziomie wiersza i kolumny w tabelach.
• Członkowie roli: Tożsamości Microsoft Entra przypisane do roli, takie jak użytkownicy, grupy lub tożsamości inne niż użytkownicy. Jeśli przypiszesz grupę Microsoft Entra, zabezpieczenia OneLake nadają tę rolę wszystkim członkom grupy.

Bezpieczeństwo OneLake stosuje domyślny model odmowy, więc użytkownicy zaczynają bez dostępu do danych, chyba że rola bezpieczeństwa OneLake wyraźnie przyznaje dostęp. Niektóre elementy Fabric zaczynają się od domyślnych ról, które dają użytkownikom podstawowy dostęp na podstawie uprawnień do ich przestrzeni roboczej.

Uprawnienia i obsługiwane elementy

Role bezpieczeństwa OneLake obsługują następujące uprawnienia:

• Czytać: Przyznaje użytkownikowi możliwość odczytywania danych z tabeli i wyświetlania skojarzonych metadanych tabeli i kolumny. W terminach SQL to uprawnienie jest równoważne zarówno VIEW_DEFINITION, jak i SELECT. Więcej informacji można znaleźć w sekcji Bezpieczeństwo metadanych.
• ReadWrite: Daje użytkownikowi możliwość odczytu i zapisu danych w tabeli lub folderze oraz przeglądania powiązanych metadanych tabeli i kolumn. W terminologii SQL to uprawnienie jest równoważne ALTER, DROP, UPDATE oraz INSERT. Więcej informacji można znaleźć w artykule ReadWrite permission.

Możesz tworzyć role bezpieczeństwa OneLake dla następujących elementów Fabric:

Uprawnienie do odczytu i zapisu

Użyj uprawnienia ReadWrite, aby przyznać użytkownikom z uprawnieniami tylko do odczytu prawo zapisu do określonych danych w elemencie.

ReadWrite dotyczy tylko użytkowników posiadających uprawnienia do odczytu elementu, takich jak osoby z rolą przestrzeni roboczej Viewer. Przypisanie ReadWrite administratorowi, członkowi lub współtwórcy przestrzeni roboczej nie ma wpływu, ponieważ te role w przestrzeni roboczej mają już dostęp do zapisu.

ReadWrite obejmuje wszystkie uprawnienia przyznane przez uprawnienia do odczytu, a także umożliwia dostęp do zapisu do wybranego obiektu i jego zawartości. Na przykład uprawnienia do ReadWrite na folderze dają dostęp do zapisu zarówno do folderu, jak i do danych w nim zawartych.

Użytkownicy posiadający uprawnienia do ReadWrite mogą wykonywać następujące czynności:

• Utwórz, usuń lub zmienij nazwę folderu lub tabeli.
• Prześlij lub edytuj plik.
• Stwórz, usuń lub zmienij nazwę skrótu.

Użytkownicy mogą wykonywać operacje zapisu za pomocą notatników Spark, eksploratora plików OneLake lub API OneLake. Ponieważ Fabric obsługuje zapisywanie danych tylko przez jeden silnik, użytkownicy z uprawnieniami ReadWrite mogą zapisywać te dane wyłącznie za pośrednictwem usługi OneLake. Wszystkie silniki zapytań nadal konsekwentnie wymuszają operacje odczytu.

Role bezpieczeństwa OneLake, które przyznają uprawnienia do ReadWrite, nie mogą zawierać ograniczeń bezpieczeństwa na poziomie wiersza (RLS) ani na poziomie kolumn (CLS).

Uprawnienia dotyczące zabezpieczeń i obszaru roboczego OneLake

Role w przestrzeniach roboczych to pierwsza granica bezpieczeństwa dla danych w OneLake. Zarządzają płaszczyzną sterowania – tworzą i zarządzają elementami Fabric oraz uprawnieniami – i stosują je do wszystkich elementów w przestrzeni roboczej. Aby poznać konkretne uprawnienia OneLake przyznawane przez każdą rolę w obszarze roboczym, zobacz Przyznawanie dostępu za pomocą ról obszaru roboczego. Aby dowiedzieć się więcej o rolach w obszarach roboczych, zobacz Role w obszarach roboczych w usłudze Fabric.

Oprócz dostępu do płaszczyzny sterowania role obszaru roboczego mogą również zapewniać dostęp do elementów danych za pomocą domyślnych ról zabezpieczeń usługi OneLake. (Domyślne role dotyczą tylko Widzów, ponieważ role Administratora, Członka i Współtwórcy mają podwyższony dostęp dzięki uprawnieniu do zapisu.) Rola domyślna to zwykła rola bezpieczeństwa OneLake, którą Fabric automatycznie tworzy przy każdym nowym elemencie. Zapewnia użytkownikom z określonym obszarem roboczym lub elementem uprawnienia domyślnego poziomu dostępu do danych w tym elemencie. Na przykład elementy lakehouse mają rolę DefaultReader, która umożliwia użytkownikom z uprawnieniem ReadAll wyświetlanie danych w lakehouse. Ten domyślny dostęp zapewnia, że użytkownicy pracujący z nowo utworzonym elementem mają podstawowy poziom dostępu. Wszystkie domyślne role korzystają z funkcji wirtualizacji członków, tak aby członkami tej roli byli wszyscy użytkownicy w danej przestrzeni roboczej z wymaganymi uprawnieniami. Na przykład wszyscy użytkownicy z uprawnieniami ReadAll w lakehouse.

Poniższa tabela przedstawia standardowe role domyślne. Przedmioty mogą mieć specjalistyczne role domyślne, które dotyczą tylko tego typu przedmiotu.

Możesz zmodyfikować lub usunąć domyślną rolę z elementu Fabric, aby zmienić dostęp dla użytkowników w tej grupie członkowskiej.

Silnik oraz dostęp użytkownika do danych

Zabezpieczenia usługi OneLake domyślnie opierają się na dostępie z minimalnymi uprawnieniami. Niektóre operacje na poziomie pamięci masowej nie są w stanie wymuszać RLS lub CLS, więc gdy zapytanie nie może być bezpiecznie przefiltrowane, OneLake całkowicie je blokuje, aby nie ryzykować ujawnienia danych, których użytkownik nie może zobaczyć. To, czy zapytanie jest filtrowane czy blokowane, zależy od ścieżki dostępu – obsługiwanego silnika zapytań lub bezpośredniego dostępu użytkownika.

Aby poznać silniki obsługujące filtrowanie RLS i CLS oraz wymagania dla każdego z nich, zobacz Odczyt danych zabezpieczonych zabezpieczeniem OneLake.

Zakres i egzekwowanie

Ta sekcja zawiera szczegółowe informacje na temat tego, jak role zabezpieczeń w usłudze OneLake przyznają dostęp do określonych zakresów, jak ten dostęp działa oraz jak rozwiązywane są kwestie dostępu w kontekście wielu ról i typów dostępu.

Zabezpieczenia na poziomie tabeli

OneLake reprezentuje wszystkie tabele jako foldery, ale z perspektywy bezpieczeństwa i silników zapytań OneLake w Fabric, nie wszystkie foldery są tabelami. Aby być tabelą poprawną, teczka musi spełniać następujące warunki:

• Folder znajduje się w katalogu Tables/ elementu. W przypadku elementów z obsługą schematu folder musi również znajdować się w prawidłowym folderze schematu.
• W folderze znajduje się folder _delta_log z odpowiadającymi mu plikami JSON zawierającymi metadane tabeli.
• Folder nie zawiera żadnych skrótów podrzędnych.

Jeśli skonfigurujesz RLS lub CLS na tabeli, OneLake odmawia dostępu, gdy folder tabeli nie spełnia tych kryteriów. Bez RLS lub CLS OneLake traktuje folder, który nie spełnia tych kryteriów, jako folder i stosuje zabezpieczenia na poziomie folderu.

Zabezpieczenia na poziomie wiersza i na poziomie kolumny

W ramach roli możesz ograniczyć dostęp do konkretnych wierszy i kolumn tabeli, stosując zabezpieczenia na poziomie wiersza i na poziomie kolumn. Aby uzyskać więcej informacji o tym, co robi każda kontrola i jak OneLake ją egzekwuje, zobacz bezpieczeństwo na poziomie tabeli, kolumn i wierszy w OneLake. Aby uzyskać informacje o tym, jak RLS i CLS rozwiązują, gdy użytkownik należy do wielu ról, zobacz Ocena wielu ról bezpieczeństwa OneLake.

Zabezpieczenia metadanych

Zezwolenie odczytu zabezpieczeń OneLake przyznaje pełny dostęp do danych i metadanych w tabeli. W przypadku użytkowników bez dostępu do tabeli dane nigdy nie są ujawniane. Ta zasada dotyczy również bezpieczeństwa na poziomie kolumn oraz możliwości użytkownika do zobaczenia lub niezobaczenia kolumny w tej tabeli. Jednak bezpieczeństwo OneLake nie gwarantuje, że metadane tabeli nie są dostępne. Niektóre komunikaty o błędach i doświadczenia mogą pokazywać nazwy kolumn.

Dziedziczenie i przeszukiwanie uprawnień do folderów

Uprawnienia folderów wpływają na hierarchię w dwóch kierunkach:

• Dziedziczenie: Uprawnienia przyznane folderowi obowiązują w dół do jego plików i podfolderów.
• Przechodzenie i wyświetlanie: Gdy użytkownicy mają uprawnienia do elementu podrzędnego, zabezpieczenia OneLake umożliwiają im wyświetlanie i przechodzenie przez foldery nadrzędne, aby mogli odnajdywać dane, do których mają dostęp, i przechodzić do nich. Poruszanie się nie daje dostępu do plików ani folderów rodzeństwa.

Rozważmy następującą hierarchię domku nad jeziorem w OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt
│   
└───folder2
    │   file21.txt

Tworzysz rolę, Role1, która daje uprawnienia do odczytu na subfolder11. Dzięki dziedziczeniu członkowie tej roli mogą czytać file111.txt i wszystko w subfolder111. Członkowie mogą wyświetlać i przechodzić przez folder1, aby dotrzeć do subfolder11, ale nie widzą file11.txt, ponieważ jest elementem równorzędnym względem subfolder11, i nie widzą Tables, ponieważ jest elementem równorzędnym względem Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Tworzysz kolejną rolę, Role2, która nadaje uprawnienie Odczyt do folder2. Poprzez dziedziczenie członkowie mogą czytać file21.txt. Członkowie mogą przechodzić przez folder2 i Files, aby do niego dotrzeć, ale nie widzą folder1 ani żadnych jego elementów podrzędnych.

Files/
│
└───folder2 <-- READ
    │   file21.txt

W przypadku skrótów zachowanie jest nieco inne. Skróty do zewnętrznych źródeł danych zachowują się tak samo jak foldery. Jednak skróty do innych lokalizacji OneLake działają w szczególny sposób. Uprawnienia docelowe skrótu decydują o dostępie do skrótu OneLake. Podczas wyświetlania skrótów usługa OneLake nie wysyła żądania sprawdzenia uprawnień dostępu do obiektu docelowego. W rezultacie, gdy wyświetlasz zawartość katalogu, OneLake zwraca wszystkie skróty wewnętrzne niezależnie od tego, czy masz dostęp do elementu docelowego. Kontrola dostępu ocenia się po próbie otwarcia skrótu i wtedy widzisz tylko dane, do których masz wymagane uprawnienia.

Skróty

Bezpieczeństwo OneLake integruje się ze skrótami do zabezpieczenia danych wewnątrz i na zewnątrz OneLake. Skróty wykorzystują jeden z dwóch trybów uwierzytelniania:

• Przejście: Skrót wykorzystuje tożsamość użytkownika zapytującego, aby uzyskać dostęp do celu. Passthrough jest domyślnym sposobem dla skrótów OneLake-to-OneLake.
• Delegowany: Skrót wykorzystuje skonfigurowaną tożsamość połączenia lub dane uwierzytelniające do uzyskania dostępu do celu. Skróty OneLake-to-OneLake mogą korzystać z uwierzytelniania delegowanego, a skróty do systemów zewnętrznych zawsze korzystają z uwierzytelniania delegowanego.

Utworzenie skrótu wymaga uprawnień zarówno na ścieżce, na której skrót jest tworzony, jak i na ścieżce docelowej. Aby uzyskać wymagania dotyczące tworzenia i dostępu do każdego typu skrótu, zobacz bezpieczeństwo skrótów OneLake.

Zabezpieczenia usługi OneLake w skrótach przekazywania

Gdy użytkownik uzyskuje dostęp do danych za pomocą skrótu przejściowego OneLake-to-OneLake, OneLake wykorzystuje tożsamość użytkownika dzwoniącego do autoryzacji dostępu do docelowej ścieżki. Efektywny dostęp użytkownika jest ograniczony przez jego uprawnienia zarówno do ścieżki skrótowej, jak i docelowej.

Nie możesz bezpośrednio zdefiniować uprawnień bezpieczeństwa OneLake za pomocą skrótu OneLake-to-OneLake. Uprawnienia w folderze zawierającym skrót łączą się z uprawnieniami na docelowej ścieżce. Jeśli element docelowy obsługuje zabezpieczenia OneLake, użytkownik musi mieć dostęp za pośrednictwem roli zabezpieczeń OneLake. Jeśli celowy element nie obsługuje zabezpieczeń OneLake, użytkownik potrzebuje uprawnień Fabric ReadAll dla tego elementu. Użytkownik nie potrzebuje zgody Fabric Read na docelowym elemencie tylko po to, aby uzyskać dostęp do jego danych przez skrót.

Zabezpieczenia OneLake w delegowanych skrótach

Skróty delegowane wykorzystują skonfigurowaną tożsamość połączenia lub dane uwierzytelniające zamiast tożsamości użytkownika wywołującego, aby uzyskać dostęp do celu. Bezpieczeństwo OneLake ogranicza, do czego użytkownik dzwoniący może uzyskać dostęp przez to połączenie.

Skróty delegowane OneLake

Dla delegowanego skrótu OneLake-to-OneLake, użytkownik wywołujący widzi przecięcie swojego dostępu na ścieżce skrótu oraz dostępu skonfigurowanej tożsamości połączenia na docelowej ścieżce. Bezpieczeństwo na poziomie kolumn (CLS) jest obsługiwane na obu ścieżkach. Bezpieczeństwo na poziomie wiersza (RLS) jest obsługiwane na docelowej ścieżce, ale nie można zdefiniować RLS na ścieżce skrótów.

Delegowane skróty zewnętrzne

Skróty do systemów zewnętrznych, takich jak ADLS, Amazon S3 i Dataverse, wykorzystują skonfigurowany identyfikator połączenia do dostępu do zewnętrznego źródła. Zabezpieczenia OneLake są stosowane dodatkowo do dostępu przyznanego przez to poświadczenie.

Na przykład załóżmy, że użytkownik1 tworzy w lakehouse skrót do folderu w zasobniku Amazon S3, a użytkownik2 uzyskuje dostęp do tego skrótu z poziomu lakehouse. Użytkownik2 może uzyskać dostęp do danych S3 tylko wtedy, gdy skonfigurowane dane połączenia S3 umożliwiają dostęp do źródła, a zabezpieczenia OneLake upoważniają użytkownika2 do dostępu do ścieżki skrótu.

Możesz przyznać dostęp zabezpieczeń OneLake do całego skrótu zewnętrznego lub do wybranych podścieżek. Uprawnienia folderu są dziedziczone rekursywnie przez wszystkie jego podfoldery, w tym foldery wewnątrz skrótu. Użytkownik, który dotrze do zewnętrznego skrótu przez inny skrót OneLake, musi nadal być autoryzowany przez zabezpieczenia OneLake zastosowane do oryginalnego skrótu zewnętrznego.

Dostęp do zewnętrznego skrótu przez Spark lub bezpośrednie wywołanie API OneLake wymaga również zgody Fabric Read na element zawierający skrót zewnętrzny. To pozwolenie jest wymagane do bezpiecznego rozwiązania połączenia z systemem zewnętrznym.

Ocena wielu ról bezpieczeństwa w OneLake

Użytkownik może pełnić wiele ról bezpieczeństwa OneLake. OneLake łączy dostęp przyznany przez te role w efektywną rolę, która decyduje o danych, do których użytkownik może mieć dostęp. OneLake ocenia efektywną rolę etapowo.

Ustal dostęp dla każdej roli

OneLake najpierw rozpatruje każdą rolę niezależnie. W ramach roli użytkownik może uzyskać dostęp tylko do danych dozwolonych przez wszystkie trzy komponenty bezpieczeństwa:

• Bezpieczeństwo na poziomie obiektowym (OLS) określa, do których tabel lub folderów rola może mieć dostęp.
• Bezpieczeństwo na poziomie wiersza (RLS) ogranicza, do których wierszy danej tabeli rola może mieć dostęp.
• Bezpieczeństwo na poziomie kolumn (CLS) ogranicza, do których kolumn danej tabeli rola może mieć dostęp.

Ponieważ wszystkie trzy składniki mają zastosowanie, usługa OneLake uwzględnia ich część wspólną. Na przykład, jeśli Role1 przyznaje dostęp do Tabeli 1 i ogranicza jej wiersze oraz kolumny, rozstrzygany dostęp dla Role1 to:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Symbol przecięcia (∩) oznacza, że użytkownik otrzymuje tylko dostęp dozwolony przez OLS, RLS i CLS w tej roli.

Łącz dostęp między rolami

Po rozstrzygnięciu każdej roli OneLake łączy role, stosując model zjednoczenia lub najmniej restrykcyjny. Symbol unii (∪) oznacza, że dostęp przyznany przez dowolną rolę staje się częścią roli efektywnej. Jeśli Role1 przyznaje dostęp do Tabeli A, a Rola2 do Tabeli B, użytkownik należący do obu ról może uzyskać dostęp do obu tabel.

Dla dwóch ról efektywna rola to:

Effective role = Role1 ∪ Role2

Gdy wiele ról daje dostęp do tej samej tabeli, reguły bezpieczeństwa na poziomie wiersza łączą się z operatorem OR . Na przykład predykaty, które dopuszczają city = 'Redmond' i city = 'New York', łączą się w postaci city = 'Redmond' OR city = 'New York'.

Reguły zabezpieczeń na poziomie kolumn są również łączone w formie sumy, z wyjątkiem punktu końcowego analiz SQL. W punkcie końcowym analizy SQL mechanizm CLS stosuje bardziej rygorystyczną semantykę odmowy. Jeśli jakaś rola ukrywa kolumnę, punkt końcowy blokuje dostęp do tej kolumny. W rezultacie punkt końcowy przecina listy dozwolonych CLS dla wszystkich ról użytkownika, zamiast łączyć je jako unię.

Połącz dostęp do skrótu i elementu docelowego

Dla skrótu usługa OneLake sprawdza role osobno w lokalizacji skrótu oraz w miejscu docelowym skrótu. Role docelowe stają się rolami wnioskowanymi w lokalizacji skrótu. OneLake następnie łączy łączony dostęp z ról skrótów z łącznym dostępem z wywnioskowanych ról docelowych. Ten krok uniemożliwia, aby dostęp dziedziczony w lokalizacji skrótu zastąpił ograniczenia dla elementu docelowego.

Dla dwóch ról skrótów i dwóch wywnioskowanych ról docelowych efektywny dostęp jest następujący:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

W tym wyrażeniu ShortcutRole1 i ShortcutRole2 są rolami w lokalizacji skrótu. InferredRole1 oraz InferredRole2 są odpowiadającymi rolami wywnioskowanymi z celu skrótu. Każda rola jest rozwiązywana na podstawie komponentów OLS, RLS i CLS, zanim OneLake połączy te role.

Ograniczenia zabezpieczeń usługi OneLake

• Jeśli przypiszesz rolę zabezpieczeń OneLake do użytkownika-gościa B2B, musisz skonfigurować ustawienia współpracy zewnętrznej B2B w usłudze Tożsamość zewnętrzna Microsoft Entra. Ustaw ustawienie Dostęp użytkowników-gości na Użytkownicy-goście mają taki sam dostęp jak członkowie (najszerszy dostęp).

• Jeśli dodasz listę dystrybucyjną do roli w zabezpieczeniach OneLake, punkt końcowy analizy SQL nie będzie mógł ustalić członków tej listy, aby egzekwować kontrolę dostępu. W rezultacie użytkownicy wydają się nie być członkami tej roli, gdy korzystają z punktu końcowego analityki SQL. Direct Lake na modelach semantycznych SQL również podlega temu ograniczeniu.

• Notesy Spark wymagają środowiska w wersji 3.5 lub nowszej oraz korzystania ze środowiska uruchomieniowego Fabric 1.3.

• Lakehouse’y bez schematu nie obsługują podglądu danych dla tabel zabezpieczonych za pomocą mechanizmów RLS i CLS. Korzystaj z lakehouse’ów z obsługą schematów i zabezpieczeniami OneLake.

• Bezpieczeństwo OneLake nie działa z Azure Data Share ani Purview Data Share. Aby uzyskać więcej informacji, zobacz Azure Data Share.

• Poniższa tabela przedstawia ograniczenia ról bezpieczeństwa OneLake.

  Scenariusz	Ograniczenie
  Maksymalna liczba ról zabezpieczeń usługi OneLake na jeden element struktury danych	250 ról na element (patrz przypis)
  Maksymalna liczba członków na każdą rolę zabezpieczeń w OneLake	500 użytkowników lub grup użytkowników na rolę
  Maksymalna liczba uprawnień dla roli zabezpieczeń usługi OneLake	500 uprawnień na rolę

  Uwaga

  Możesz poprosić o zwiększenie liczby ról na element do 1 000. Aby poprosić o zwiększenie, skontaktuj się z pomocą techniczną platformy Azure.

Opóźnienia

Zastosowanie zmian definicji ról trwa około 5 minut.

Zmiany w grupie użytkowników w ramach roli zabezpieczeń OneLake zajmują około godziny, zanim OneLake zastosuje uprawnienia roli do zaktualizowanej grupy użytkowników. Niektóre silniki Fabric mają własną warstwę buforowania, w związku z tym może być wymagane dodatkowe zaktualizowanie dostępu we wszystkich systemach.

Treści powiązane

• Rozpocznij pracę z zabezpieczeniami OneLake
• Role w przestrzeniach roboczych w Microsoft Fabric
• Zabezpiecz dane dzięki bezpieczeństwu na poziomie wiersza i kolumny
• Omówienie integracji zabezpieczeń usługi OneLake
• Punkt końcowy analizy SQL i zabezpieczenia OneLake
• Zabezpieczenia skrótów OneLake