Użyj RBAC z ABAC

Kontrola dostępu oparta na rolach (RBAC) ustala aktywną tożsamość dla sesji. Kontrola dostępu oparta na atrybutach (ABAC) w Unity Catalog stosuje filtry wierszy i maski kolumn na podstawie tej tożsamości:

• RBAC: Użytkownik przyjmuje rolę, aby działać z uprawnieniami tej roli, a nie własnymi. Użyj ról, aby oddzielić dostęp między projektami lub poziomami wrażliwości.
• Polityki filtrowania wierszy i maskowania kolumn ABAC: Filtruj wiersze lub maskuj wartości kolumn dla tabel, do których aktywna tożsamość ma już dostęp. Polityki są definiowane na obiektach zabezpieczanych, takich jak katalogi czy schematy, i wykorzystują tagi nadzorowane do identyfikacji pasujących tabel i kolumn. Zobacz Podstawowe pojęcia dotyczące kontroli dostępu opartej na atrybutach (ABAC).

Jak działają funkcje tożsamości podczas przyjmowania roli

Funkcje SQL związane z tożsamością w Unity Catalog są rozstrzygane względem aktywnej tożsamości sesji, a nie użytkownika uwierzytelniającego się. Gdy użytkownik przejmuje rolę, tożsamość aktywnej sesji staje się tą rolą:

Przyjęta rola stanowi aktywną tożsamość na potrzeby oceny zasad ABAC, rozstrzygania uprawnień w Unity Catalog oraz przypisywania zdarzeń audytowych. Przyjęcie roli może więc zmienić zachowanie istniejących polityk i widoków opartych na tożsamości użytkownika.

Dokumentacja referencyjna SQL zaleca session_user() zamiast przestarzałego aliasu current_user(). Użyj is_account_group_member() do testowania członkostwa w grupie kont. Zobacz session_user funkcję i is_member funkcję.

Typowa pułapka: widoki zabezpieczeń na poziomie wierszy oparte na session_user()

Typowym wzorcem zarówno w ABAC, jak i w filtrach wierszy na poziomie tabeli, jest filtrowanie wierszy poprzez sprzężenie z tabelą aprowizowania (nazywaną również tabelą mapowania lub listą kontroli dostępu), gdzie kluczem jest nazwa użytkownika zwracana przez session_user(). Przykład:

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = session_user()
    AND p.facility_id = facility_filter.facility_id
);

To facility_filter.facility_id odwołanie identyfikuje parametr funkcji. Bez nazwy funkcji facility_id jest rozwiązywane do kolumny tabeli aprowizacji. Zobacz rozpoznawanie nazw.

Gdy ten sam użytkownik przyjmuje rolę, session_user() nie zwraca już nazwy użytkownika. Zwraca ona nazwę roli. Ponieważ rola nie znajduje się w tabeli provisioning, filtr nie zwraca żadnych wierszy i użytkownik wydaje się tracić dostęp do danych, do których przyznano mu dostęp.

Dodawanie roli do tabeli aprowizacji

Traktuj rolę jako kolejny podmiot zabezpieczeń w danych aprowizacji: wstaw jeden wiersz dla każdej roli z uprawnieniami (lub innymi atrybutami), do których rola powinna mieć dostęp. Następnie filtr sprawdza, czy aktywna tożsamość jest użytkownikiem czy przyjętą rolą.

Wzorce połączonego użycia

Poniższe przykłady łączą RBAC z filtrami wierszowymi ABAC i maskami kolumnowymi.

Requirements

Zanim użyjesz przykładów, wykonaj następujące kroki:

• Użyj zasobów obliczeniowych obsługujących ABAC.
• Twórz zarządzane tagi i przyznaj uprawnienia potrzebne do ich stosowania, tworzenia funkcji definiowanych przez użytkownika (UDF) oraz zarządzania politykami. Zobacz rozdzielenie obowiązków i uprawnienia.
• Nadaj tożsamościom wykonującym zapytania USE CATALOG, USE SCHEMA oraz SELECT dostęp do odpowiednich danych. Filtry wierszowe i maski kolumnowe nie przyznają tych uprawnień. Zobacz Uprawnienia użycia.
• Stwórz każdy przykładowy UDF w schemacie, do którego masz uprawnienia, i użyj tego schematu jako aktualnego schematu przy tworzeniu jego polityki, lub w pełni zakwalifikuj nazwę funkcji. Pełny instruktaż znajdziesz w Samouczek: konfigurowanie ABAC przy użyciu SQL.

Filtry wierszy dla poszczególnych projektów oparte na przyjętej roli

Organizacja badań klinicznych prowadzi kilka równoległych badań, z których każde ma własną rolę dostępu. Filtr wierszowy ogranicza każdą rolę do danych z jej badania. Ten sam schemat dotyczy innych projektów, które wymagają osobnego dostępu do danych. Oznacz kolumnę project_id w każdej tabeli kluczem zarządzanego tagu project. Wartości w kolumnie identyfikują projekt dla każdego wiersza.

Przezbrajanie:

• Tabele w obszarze clinical_trials.* mają kolumnę oznaczoną project_id kluczem project .
• Każdy projekt ma odpowiednią rolę dostępu o nazwie role-<project> (na przykład role-alpha, role-beta).
• Użytkownicy mają uprawnienie „Assume” tylko w odniesieniu do ról w projektach, nad którymi pracują.

UDF filtru wierszy:

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN session_user() = CONCAT('role-', project_id);

Zasady:

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

Ten UDF porównuje aktywną tożsamość z wartością kolumny project_id każdego wiersza. MATCH COLUMNS używa tagu zarządzanego, aby znaleźć tę kolumnę. Klauzule TO i EXCEPT wybierają podmioty, do których ma zastosowanie zasada. Nie porównują wartości wierszy. Jak wyjaśniono w wytycznych dotyczących określania głównej wartości docelowej , preferuj TO / EXCEPT proste funkcje określania zakresu podmiotu zabezpieczeń i rezerwowania tożsamości wewnątrz funkcji zdefiniowanej przez użytkownika w przypadkach takich jak ta, gdzie pojedyncza reguła zależy zarówno od aktywnej tożsamości, jak i zawartości wiersza.

Jedna polityka obejmuje każdy projekt: USING COLUMNS (project) przekazuje wartość każdego wiersza z dopasowanej kolumny do UDF. Alias project nazywa dopasowaną kolumnę, a nie wartość tagu. Przykład, który wykorzystuje tabelę wyszukiwania do określania dostępu do wiersza, można znaleźć w artykule Używaj tabel mapowania do dynamicznej kontroli dostępu.

Zachowanie:

• Użytkownik działający z użyciem swojej tożsamości użytkownika nie widzi żadnych wierszy w żadnej tabeli clinical_trials. session_user() wyświetla ich nazwę użytkownika. Wybierz nazwy ról, które nie mogą odpowiadać nazwie użytkownika ani identyfikatorowi aplikacji jednostki usługi.
• Użytkownik zakładając, że role-alpha widzi tylko wiersze, w których project_id jest równa alpha. Po przełączeniu do role-beta, uruchom ponownie zapytanie, aby zobaczyć wiersze, w których project_id jest równe beta.

Maskuj dane osobowe, chyba że przypisano rolę

W tym przykładzie dane osobowe (PII), takie jak numery ubezpieczenia społecznego i adresy e-mail, są domyślnie maskowane. Aby zobaczyć wartości surowe, użytkownik musi przyjąć role-pii-cleared. Zdarzenia audytowe identyfikują rolę użytą do dostępu do danych oraz tożsamość, która zainicjowała zdarzenie.

Przezbrajanie:

• Oznacz kolumny wrażliwe za pomocą klucza tagu pii (dozwolone wartości, takie jak ssn, email, phone).
• Stwórz grupę role-pii-cleared bez członków. Udziel uprawnienia Assume dla tej grupy.
  • Użytkownicy upoważnieni do przeglądania surowych danych osobowych (PII) mogą przejąć tę rolę dostępu do przeglądania niezamaskowanych danych. Nie dodawaj członków do grupy, ponieważ klauzula EXCEPT polityki pozwoliłaby im zobaczyć niezamaskowane dane bez przyjmowania tej roli.

Stwórz UDF maski kolumny, używając tego SQL:

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
DETERMINISTIC
RETURN '***';

Zasady:

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

Klauzula EXCEPT całkowicie wyłącza role-pii-cleared spod tej zasady, więc funkcja zdefiniowana przez użytkownika nigdy nie jest wywoływana, gdy ta rola jest aktywną tożsamością. Zobacz Preferuj TO/EXCEPT do określania elementu docelowego podmiotu zabezpieczeń, aby uzyskać ogólne wskazówki dotyczące określania elementu docelowego podmiotu zabezpieczeń przy użyciu TO / EXCEPT.

Zachowanie:

• Użytkownik działający z własną tożsamością użytkownika widzi *** w każdej kolumnie PII. To jest stan domyślny dla wszystkich, w tym dla użytkowników posiadających uprawnienia Assume na role-pii-cleared.
• Po założeniu role-pii-clearedzasady nie mają już zastosowania do sesji, a ten sam użytkownik widzi nieprzetworzone wartości.
• Zdarzenia audytowe dla tych zapytań identyfikują rolę autoryzującą w identity_metadata.run_as i jej nazwę w identity_metadata.run_as_display_name. Zobacz Atrybucja audytu.

Zasady poziomu poufności, które różnią się w zależności od przejmowanej roli

Dane są klasyfikowane w warstwach poufności (internal, confidential, restricted). Każda warstwa ma odpowiednią rolę dostępu, co restricted oznacza również dostęp do confidential i internal . Funkcja UDF filtra pojedynczego wiersza kontroluje widoczność wierszy przez porównanie poziomu każdego wiersza z domniemaną rolą użytkownika.

Przezbrajanie:

• Tabele mają kolumnę oznaczoną sensitivity_level kluczem sensitivity (dozwolone wartości: internal, confidential, restricted).
• Trzy role dostępu: role-sens-internal, role-sens-confidential, role-sens-restricted.

UDF filtru wierszy:

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN session_user() = 'role-sens-restricted' THEN TRUE
  WHEN session_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN session_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

Zasady:

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

Ponieważ rola nie jest członkiem samej siebie, ta funkcja UDF porównuje session_user() z każdą nazwą roli, zamiast sprawdzać przynależność za pomocą is_account_group_member(). Zobacz notatkę w artykule Jak funkcje tożsamościowe zachowują się podczas przyjmowania roli, aby dowiedzieć się, dlaczego testy członkostwa nie odpowiadają przyjętej roli. Zobacz Informacje o wydajności zasad filtrowania wierszy i maskowania kolumn, aby zapoznać się z charakterystyką wydajności funkcji identycznościowych w funkcjach UDF.

Zachowanie:

• Użytkownik działający z własną tożsamością użytkownika nie widzi żadnych wierszy. Gałąź ELSE FALSE odpowiada wszystkim, co nie jest jedną z trzech ról.
• Zakładając, że role-sens-internal wyświetla tylko internal wierszy.
• Zakładając, że role-sens-confidential pokazuje internal i confidential wiersze.
• Zakładając, że role-sens-restricted ujawnia wszystkie wiersze.

Użytkownicy wybierają poziom, którego potrzebują na sesję. Filtr stosuje się do tabel z oznaczoną kolumną i zwraca wiersze, do których ta rola ma dostęp.

Przypisanie audytu

W tabeli systemu dzienników audytowych identity_metadata.run_by identyfikuje, kto zainicjował zdarzenie, oraz identity_metadata.run_as identyfikuje tożsamość użytą do autoryzacji. Pola run_by_display_name i run_as_display_name zawierają nazwy czytelne dla człowieka. W przypadku zapytań wykonywanych interaktywnie, po przyjęciu roli, identyfikują one odpowiednio użytkownika i rolę. Obciążenie zadania może mieć innego inicjatora. Zobacz Set Run as to a group (Ustaw uruchom jako na grupę).

Używaj zdarzeń audytowych do przeglądu aktywności w ramach roli. Aby sprawdzić, które polityki mają zastosowanie do tabeli, użyj SHOW EFFECTIVE POLICIES zgodnie z opisem w dokumencie Planowanie dynamicznej oceny zasad. Informacje o dostępie do audytu, schemacie i dostępności można znaleźć w sekcji Weryfikowanie przypisania audytu.

Dodatkowe zasoby