Podstawowe pojęcia dotyczące kontroli dostępu opartej na atrybutach (ABAC)

Kontrola dostępu oparta na atrybutach (ABAC) jest modelem kontroli dostępu, który wykorzystuje zarządzane tagi i zasady do przyznawania uprawnień na podstawie atrybutów obiektów, a nie uprawnień przyznawanych poszczególnym obiektom. Ta strona definiuje podstawowe elementy: tagi zarządzane, cztery typy zasad ABAC (filtr wierszy, maskowanie kolumn, zasady GRANT i DENY (Beta)), uprawnienia wymagane do ich skonfigurowania oraz rozdzielenie obowiązków, które ABAC umożliwia między zespołami.

Zobacz Kontrola dostępu oparta na atrybutach w Unity Catalog, aby zapoznać się z omówieniem wszystkich tematów usługi ABAC, w tym samouczków, zarządzania zasadami, najlepszych praktyk i ograniczeń.

Co to jest ABAC?

Kontrola dostępu oparta na atrybutach (ABAC) to dynamiczny model kontroli dostępu, w którym decyzje dotyczące dostępu są oparte na zasadach ocenianych względem atrybutów skojarzonych z zabezpieczanymi obiektami. W Unity Catalog te atrybuty są reprezentowane za pomocą tagów kontrolowanych. Te zarządzane tagi są używane w warunkach zasad w celu dopasowania obiektów danych w danym zakresie, takich jak wykaz lub schemat. Dzięki temu pojedyncze zasady mają być stosowane automatycznie w wielu obiektach danych spełniających jego warunki.

Na przykład zasady ABAC mogą maskować wszystkie kolumny oznaczone PII w tabelach w ramach schematów oznaczonych HR. W miarę tworzenia i oznaczania nowych obiektów danych zasady są stosowane automatycznie bez konieczności oddzielnych definicji zasad dla każdego obiektu.

ABAC wspiera bezpieczeństwo na poziomie wierszy i kolumn poprzez polityki filtrowania wierszy oraz polityki masek kolumnowych w tabelach. Zasady filtrowania wierszy ograniczają wiersze, które użytkownik może zobaczyć. Zasady maskowania kolumn kontrolują sposób prezentowania użytkownikom wartości kolumn. Aby zapoznać się z porównaniem filtrów wierszy na poziomie tabeli i masek kolumn, zobacz Kiedy używać funkcji ABAC a filtrów wierszy na poziomie tabeli i masek kolumn.

ABAC obsługuje również dynamiczne nadawanie uprawnień za pomocą GRANT zasad dla obsługiwanych typów obiektów zabezpieczanych. Zobacz zasady ABACGRANT.

ABAC może również jawnie odrzucać przywileje za pomocą zasad DENY (wersja beta), obecnie ograniczonych do przywileju MANAGE ACCESS CONTROL. Polisa DENY zawsze ma pierwszeństwo przed jakimkolwiek grantem. Zobacz zasady ABAC DENY (Beta).

Tagi zarządzane

W katalogu Unity atrybuty są implementowane jako tagi regulowane. Tagi zarządzane to pary klucz-wartość definiowane na poziomie konta i przypisywane do obiektów zabezpieczalnych Unity Catalog, takich jak katalogi, schematy, tabele, kolumny, modele i woluminy, a także do obiektów obszaru roboczego. Reprezentują one cechy, takie jak czułość, klasyfikacja lub domena biznesowa.

Domyślnie obiekty zabezpieczane dziedziczą tagi z nadrzędnego katalogu lub schematu. Odziedziczone tagi można zastępować na wszystkich poziomach z wyjątkiem poziomu kolumn: tagi kolumn nie są dziedziczone z tabeli nadrzędnej i muszą być przypisywane bezpośrednio.

Tagi zarządzane mogą być przywoływane w warunkach zasad przy użyciu wbudowanych funkcji, takich jak has_tag() i has_tag_value(), które sprawdzają, czy dany tag jest obecny w obiekcie danych docelowych, bezpośrednio lub za pośrednictwem dziedziczenia tagów.

Tagi zarządzane są definiowane na poziomie konta. Oznacza to, że można użyć tej samej taksonomii tagów na całym koncie, w tym w wielu magazynach metadanych.

Aby uzyskać więcej informacji, zapoznaj się z tagami zarządzanymi i stosowaniem tagów do zabezpieczalnych obiektów w katalogu Unity.

Policies

Zasady są dołączane do zabezpieczanych obiektów w katalogu Unity w celu zdefiniowania reguł kontroli dostępu na podstawie kondycji tagów. Poniżej przedstawiono przykład:

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

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Każda zasada określa:

• Zakres: zabezpieczany obiekt, w którym są dołączone zasady, określone przez klauzulę ON . Dołączanie zasad do zabezpieczanego obiektu oznacza, że warunki zasad są oceniane dla wszystkich obiektów typu określonego w FOR klauzuli w obrębie tego obiektu i wszystkich jego obiektów podrzędnych.
  • W przypadku zasad filtrowania wierszy i maski kolumn obsługiwane zakresy zasad to CATALOG, SCHEMAlub TABLE. Dla GRANT zasad obsługiwane zakresy zasad to CATALOG, SCHEMA lub obsługiwany niekontenerowy typ zabezpieczalny. Możesz też dołączyć dowolny typ polityki na tym poziomie METASTORE , aby dotyczył wszystkich katalogów w metastore. Zobacz Zasady ABAC na poziomie magazynu metadanych (Beta).
  • Tabele, w tym tabele strumieniowe, widoki materializowane oraz widoki (Beta), są obsługiwanym typem zabezpieczonym dla polityk filtrów wierszowych i masek kolumn, określanymi za pomocą klauzuli FOR TABLES . GRANT dotyczy modeli, usług modelowych, usług dostawców modeli, usług MCP, usług agentów (Beta) oraz umiejętności (Beta) i obejmuje klauzulę GRANT <privilege> FOR <securable_type>. Pełną listę obsługiwanych zabezpieczonych typów i uprawnień można znaleźć w artykule Wspierane zabezpieczone typy i uprawnienia.
  • Polityka dołączona do metastore jest oceniana względem wszystkich obiektów zabezpieczalnych typu określonego w klauzuli FOR we wszystkich katalogach w metastore. Polityka dołączona do katalogu ocenia wszystkie zabezpieczenia tego typu w tym katalogu. Polityka przypisana do schematu jest oceniana względem wszystkich obiektów zabezpieczalnych tego typu w obrębie tego schematu. Zasada dołączona do tabeli ocenia tylko względem tej tabeli.

• Podmioty polityki: Kogo dotyczą zasady i kto jest z nich zwolniony. Klauzula TO określa użytkowników, grupy lub jednostki usługi podlegające zasadom. Opcjonalna klauzula EXCEPT wyklucza określone podmioty z tej polityki.
• Akcje: Określa, czy zasada stosuje filtr wierszy, maskowanie kolumn czy nadaje uprawnienia. Zasady filtrowania wierszy i maskowania kolumn używają funkcji zdefiniowanej przez użytkownika (UDF) do implementowania logiki filtrowania lub maskowania. GRANT zasady nie korzystają z funkcji zdefiniowanych przez użytkownika. Zobacz Typy zasad.
• Warunki: wyrażenia oparte na tagach, które określają, które tabele lub kolumny obejmuje zasada. Zobacz Warunki i wbudowane funkcje.

Zasady są tworzone i zarządzane za pośrednictwem interfejsu użytkownika lub programowo za pomocą instrukcji SQL, takich jak CREATE POLICY, DROP POLICYSHOW POLICIES, lub DESCRIBE POLICY, interfejsy API REST, zestawy SDK usługi Databricks lub narzędzie Terraform. Aby uzyskać pełną składnię i przykłady, zobacz Tworzenie zasad ABAC i zarządzanie nimi .

Typy polis

ABAC obsługuje cztery typy zasad: zasady filtrowania wierszy, zasady maskowania kolumn, zasady GRANT oraz zasady DENY (Beta). Zasady filtrowania wierszy i maskowania kolumn wymagają użycia UDF do implementacji logiki filtrowania lub maskowania. polityki GRANT i DENY nie używają funkcji UDF, lecz zamiast tego przyznają lub odmawiają uprawnień, gdy ich warunek oparty na tagach pasuje do atrybutów obiektu docelowego.

Zasady filtrowania wierszy

Zasady filtrowania wierszy ograniczają wiersze, które użytkownik może zobaczyć w tabeli na podstawie wartości w kolumnach zidentyfikowanych przez tagi zgodne z warunkami i wbudowanymi funkcjami. Polityka odwołuje się do funkcji zdefiniowanej przez użytkownika, która ocenia każdy wiersz. Wiersze, dla których funkcja zwraca FALSE, są wykluczane z wyników zapytania. Argumenty są przekazywane do funkcji zdefiniowanej przez użytkownika za pośrednictwem sekcji USING COLUMNS.

Przykładowy przypadek użycia: Aby uzyskać wykaz sprzedaży, upewnij się, że zespół EMEA widzi tylko rekordy sprzedaży w regionie EMEA we wszystkich tabelach, które mają otagowane regionkolumny .

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Zasady maski kolumn

Zasady maskowania kolumn określają, jakie wartości widzi użytkownik dla określonych kolumn zidentyfikowanych przez tagi zgodne z warunkami i wbudowanymi funkcjami. Polityka odnosi się do funkcji zdefiniowanej przez użytkownika, która przyjmuje wartość kolumny jako dane wejściowe i zwraca oryginalną wartość lub zmaskowaną wersję. Wartość maskowanej kolumny jest powiązana automatycznie jako pierwszy argument z klauzuli ON COLUMN , a dodatkowe argumenty można przekazać za pośrednictwem metody USING COLUMNS. Typ zwracany musi być zgodny lub rzutowalny do typu danych kolumny.

Przykładowy przypadek użycia: Maskuj kolumny SSN oznaczone tagiem pii : ssn, aby użytkownicy widzieli ***-**-XXXX (tylko cztery ostatnie cyfry), chyba że należą do grupy zgodności, która jest zwolniona z zasady.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

Klauzula USING COLUMNS przekazuje argumenty do funkcji zdefiniowanej przez użytkownika. Akceptuje aliasy dla kolumn, które pasują do wyrażenia opartego na tagach lub wartości stałych (ciągi cytowane, literały liczbowe, wartości logiczne (TRUE/FALSE) lub NULL), podane w kolejności, w których funkcja ich oczekuje. Akceptuje również funkcje introspekcji tagów, które wyodrębniają wartość tagu w czasie wykonywania zapytania i przekazują ją do funkcji UDF. W przypadku zasad maskowania kolumn są to dodatkowe argumenty poza kolumną zamaskowaną (która jest automatycznie wiązana z elementem ON COLUMN). Umożliwia to ponowne użycie pojedynczej funkcji zdefiniowanej przez użytkownika (UDF) w ramach różnych zasad z odmiennymi parametrami.

Zaleca się użycie SQL UDF (funkcji definiowanych przez użytkownika) dla lepszej wydajności. Funkcje zdefiniowane przez użytkownika w Pythonie zarejestrowane w Unity Catalog są również obsługiwane, jednak optymalizator zapytań nie może ich wstawiać ani optymalizować w taki sposób, jak funkcje UDF SQL. Zobacz Zagadnienia dotyczące wydajności, aby uzyskać wskazówki dotyczące wyboru języka UDF.

GRANT Polityka

GRANT zasady dynamicznie przyznają uprawnienie w Unity Catalog, gdy oparty na tagach warunek jest zgodny z tagami zabezpieczanego obiektu. Za każdym razem, gdy użytkownik próbuje uzyskać dostęp do obiektu podlegającego zabezpieczeniu, Unity Catalog identyfikuje wszystkie zasady GRANT, których zakres obejmuje ten obiekt, sprawdza, czy użytkownik znajduje się na liście TO, a nie na liście EXCEPT, oraz ocenia warunek zasady WHEN w odniesieniu do tagów przypisanych do tego obiektu, w tym tagów dziedziczonych. Jeśli zasada ma zastosowanie, Unity Catalog nadaje uprawnienie. GRANT zasady używają tego samego modelu ewaluacji co zasady filtrowania wierszy i zasady maskowania kolumn, z tą różnicą, że nie używają funkcji zdefiniowanych przez użytkownika. Warunek jest określony bezpośrednio w definicji zasad.

Efektywne uprawnienia obiektu są sumą uprawnień przyznanych bezpośrednio oraz wszelkich mających zastosowanie zasad GRANT. Podmiot zabezpieczeń ma uprawnienie, jeśli ma do niego zastosowanie objęta zakresem zasada GRANT lub jeśli ma do niego zastosowanie bezpośrednie GRANT tego samego uprawnienia. GRANT zasady zapewniają wyłącznie dostęp. Nie mogą odwołać dostępu przyznanego bezpośrednio.

DENY zasady (Beta)

DENY polityki jednoznacznie odmawiają podmiotom uprawnienia w Unity Catalog do obiektów zabezpieczanych objętych ich zakresem i zawsze mają pierwszeństwo przed każdym nadaniem tego samego uprawnienia, niezależnie od tego, czy jest ono bezpośrednie, odziedziczone, czy wynika z własności obiektu. Podobnie jak polityki GRANT , DENY polityki są dołączane na poziomie katalogu lub schematu, używają warunków opartych na tagach i nie używają UDF. Gdy wiele zasad DENY ma zastosowanie do tego samego podmiotu, ich efekty są łączone i żadne uprawnienie nie może zastąpić aktywnego DENY. Zobacz zasady ABAC DENY (Beta).

Warunki i wbudowane funkcje

Warunki to wyrażenia oparte na tagach, które określają, które tabele i kolumny są obiektami docelowymi zasad w ramach ich zakresu.

• Warunki tabeli (WHEN klauzula): wyrażenia logiczne, które pasują do tabel na podstawie ich tagów. W przypadku pominięcia wartość domyślna to TRUE, co oznacza, że zasady mają zastosowanie do wszystkich tabel w zakresie.
• Warunki kolumn (MATCH COLUMNS klauzula): jedno lub więcej wyrażeń logicznych oddzielonych przecinkami, które identyfikują, które kolumny są celem polityki. Każde wyrażenie może być pojedynczą wbudowaną funkcją, na przykład has_tag('pii'), lub kombinacją przy użyciu operatorów logicznych, takich jak has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Każdemu wyrażeniu można przypisać alias (określony po AS), do którego można się odwołać w klauzulach ON COLUMN i USING COLUMNS. Polityka filtrów wierszowych może zawierać do sześciu wyrażeń kolumnowych, a polityka masek kolumnowych do trzech. Wszystkie wyrażenia muszą się zgadzać, aby zasada miała zastosowanie.

Oba typy klauzul używają następujących wbudowanych funkcji, które są oceniane przez katalog Unity względem zabezpieczalnych metadanych.

Aby dopasować atrybuty użytkownika wykonującego zapytanie zamiast tagów zasobów, zobacz Funkcje atrybutów tożsamości.

Aby dopasować na podstawie kontekstu żądania, na przykład aplikacji wywołującej, zobacz Funkcje atrybutu context.

Tagi nie są propagowane z tabel do kolumn. Użycie has_tag() w klauzuli MATCH COLUMNS pasuje tylko do tagów na poziomie kolumny, a nie tagów w tabeli nadrzędnej lub jej elementów nadrzędnych.

Przykład: użycie dwóch warunków kolumn. customers Schemat zawiera tabele z otagowaną pii : email kolumną wiadomości e-mail i otagowaną consent_to_contact kolumną zgody. Zasady maskuje adresy e-mail, chyba że klient wyraził zgodę na kontakt. Używa dwóch warunków kolumny:

1. has_tag_value('pii', 'email') identyfikuje kolumnę zawierającą adresy e-mail (kolumnę do maskowania).
2. has_tag('consent_to_contact') Identyfikuje kolumnę zawierającą informacje o zgodzie (używana przez funkcję zdefiniowaną przez użytkownika do decydowania, czy ma być maskowane).

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Ta zasada dotyczy tylko tabel, które mają zarówno kolumnę otagowaną pii : email, jak i kolumnę otagowaną consent_to_contact. Jeśli tabela nie ma kolumn pasujących do obu warunków, zasady nie mają zastosowania, a dane są zwracane bez maskowania.

Funkcje atrybutów tożsamości (Beta)

Funkcje atrybutów tożsamości oceniają właściwości użytkownika wykonującego zapytanie, takie jak dział, kraj lub rola pracy. Te atrybuty mogą być udostępniane przez dostawcę tożsamości i używane bezpośrednio w warunkach zasad. Pozwala to wyrażać bardziej elastyczne warunki bez tworzenia oddzielnych grup dla każdej kombinacji właściwości tożsamości. Gdy informacje o tożsamości zmieniają się u dostawcy tożsamości, zasady używają zaktualizowanych wartości atrybutów, podobnie jak zaktualizowanego członkostwa w grupach.

Funkcje te są obsługiwane w klauzuli WHEN zasad maskowania kolumn.

Pamiętaj o następujących zachowaniach, pisząc polityki, które je wykorzystują:

• Brakujący atrybut jest rozpoznawany jako false. Jeśli użytkownik nie ma przypisanej wartości dla atrybutu, nie ma żadnych atrybutów lub atrybut nie istnieje, funkcja zwraca false zamiast zgłaszać błąd. Sformułuj warunki tak, aby ten false wynik ograniczał dostęp. Zobacz warunki atrybutów tożsamości.
• Klucze i wartości atrybutów rozróżniają wielkość liter i są porównywane dokładnie: Finance i finance nie są zgodne.
• Zmiany atrybutów nie są natychmiastowe. Zmiany w dostawcy tożsamości nie są natychmiast synchronizowane z Azure Databricks. Zobacz atrybuty tożsamości, aby uzyskać więcej informacji.

Aby poznać atrybuty obsługiwane przez Azure Databricks oraz sposób ich konfiguracji, zobacz atrybuty tożsamości. Przykłady wykorzystania atrybutów tożsamości w politykach można znaleźć w kolumnie Maskuj kolumnę opartą na atrybutach użytkownika zapytującego.

Funkcje atrybutów kontekstu (Beta)

Atrybuty kontekstu służą do ograniczenia dostępu do danych dla żądań składanych w imieniu użytkownika za pośrednictwem aplikacji OAuth. Takie rozwiązanie może ograniczać dostęp agentów do danych, gdy działają w imieniu użytkownika, jednocześnie utrzymując te same dane dostępne, jeśli użytkownik zapyta je bezpośrednio w przestrzeni roboczej.

Obejmuje każdą aplikację OAuth, czy to wbudowaną aplikację, taką jak Azure Databricks CLI, czy niestandardową aplikację OAuth. Istnieją dwa różne atrybuty kontekstu:

• request.is_on_behalf_of: ciąg 'true' lub 'false'. Wskazuje, czy żądanie jest realizowane w imieniu użytkownika za pośrednictwem aplikacji OAuth. Każde żądanie z aplikacji OAuth ma tę wartość ustawioną na .'true'
• request.client_id: identyfikator klienta OAuth. Może to być używane do targetowania konkretnego klienta OAuth, czy to wbudowanej aplikacji OAuth (na przykład, databricks-cli), lub niestandardowej aplikacji OAuth. Można to client_id zobaczyć w ustawieniach>Połączenia z aplikacją w konsoli konta. W przypadku aplikacji Databricks można to również zobaczyć na stronie Szczegóły autoryzacji aplikacji, w ramach ID klienta aplikacji OAuth2. Alternatywnie można to odczytać z pola identity_metadata.acting_resource w rejestrach audytu.

Te atrybuty nie są modyfikowalne przez użytkownika i są wyraźnie udostępniane przez system. Dzwoniący wpływa na niego wyłącznie przez sposób uwierzytelniania. Te atrybuty mogą być używane do identyfikacji zewnętrznych agentów, nie dla Genie.

Atrybuty kontekstu mogą być używane za pomocą następujących funkcji:

Klucze atrybutów są nieczułe na wielkość liter, a wartości na wielkość liter.

Aby dowiedzieć się, jak używać tych atrybutów kontekstu do kontroli dostępu agentów zewnętrznych, zobacz Ogranicz dostęp dla agentów zewnętrznych działających w imieniu użytkownika.

Funkcje zdefiniowane przez użytkownika (UDF)

Zasady filtrowania wierszy i maskowania kolumn używają funkcji zdefiniowanych przez użytkownika (UDF) do implementowania logiki filtrowania lub maskowania. Zobacz funkcje definiowane przez użytkownika SQL i Python (UDF) w Unity Catalog, aby dowiedzieć się, jak tworzyć UDF i nimi zarządzać, oraz Typowe wzorce filtrowania wierszy i maskowania kolumn, aby zapoznać się z przykładami.

Funkcje introspekcji tagów

Funkcje introspekcji znaczników wyodrębniają wartość zarządzanego znacznika i przekazują ją do UDF poprzez klauzulę USING COLUMNS. Ponieważ funkcja UDF otrzymuje wartość tagu jako argument, pojedyncza zasada i funkcja UDF mogą obsługiwać wiele wartości tagu, zamiast wymagać oddzielnej zasady dla każdej wartości tagu. Te funkcje są dostępne tylko dla zasad filtrowania wierszy i maskowania kolumn, ponieważ zasady GRANT nie używają funkcji UDF.

Tworzenie zasad korzystających z tych funkcji wymaga środowiska Databricks Runtime 18 LTS lub nowszego. To wymaganie dotyczy tylko tworzenia zasad, a nie wykonywania zapytań dotyczących tabel podlegających.

Podczas wykonywania zapytania Unity Catalog ocenia te funkcje na podstawie tagów w tabeli lub kolumnach, do których pasuje zasada: get_tag_value() odczytuje z tabeli spełniającej warunek WHEN, a get_column_tag_value() odczytuje z kolumn zidentyfikowanych przez MATCH COLUMNS. Mogą pojawiać się tylko w klauzuli USING COLUMNS, a nie w warunkach WHEN lub MATCH COLUMNS.

Obie funkcje przyjmują klucz tagu jako literał ciągu. Tag musi być tagiem zarządzanym i get_column_tag_value() musi odwoływać się do aliasu, który istnieje w klauzuli MATCH COLUMNS zasad. Jeśli tag nie jest objęty zasadami lub alias jest nieprawidłowy, utworzenie zasady zakończy się niepowodzeniem. Jeśli tag, do którego istnieje odwołanie, nie jest już objęty regułami w czasie wykonywania zapytania, zapytania do tabel docelowych zasady kończą się błędem w czasie wykonywania.

Aby uzyskać krok po kroku samouczek, który wykorzystuje jedną politykę maskującą wiele typów PII, zobacz Maskuj kolumny PII według typu z introspekcją tagów.

Rozdzielenie obowiązków i uprawnień

Skonfigurowanie funkcji ABAC obejmuje kilka kroków, z których każdy ma własne wymagania dotyczące uprawnień. Organizacje mogą dystrybuować te zadania w wyspecjalizowanych grupach w zależności od tego, jak decydują się na oddzielenie obowiązków. Na przykład organizacja może centralnie zdefiniować taksonomię tagów, a następnie klasyfikować dane, administratorzy ładu piszą zasady, twórcy danych tworzą obiekty w zakresach podlegających, a konsumenci danych uzyskują dostęp do zarządzanych obiektów.

1. Utwórz taksonomię tagów. Zdefiniuj zarządzane klucze tagów i ich dozwolone wartości, zanim każda osoba zastosuje je lub zapisze zasady. Na przykład utwórz sensitivity tag z kontrolowanymi wartościami (public, internal, confidential, restricted) lub pii tag z wartościami takimi jak ssn, emaili phone_number. Zobacz Standaryzacja atrybutów i nazewnictwa , aby uzyskać zalecenia dotyczące konwencji nazewnictwa i projektowania taksonomii.

   • Wymagane uprawnienia: administrator konta lub użytkownik z CREATE uprawnieniami do tagów na poziomie konta.

2. Tagowanie zasobów danych. Steward danych, twórca danych lub system klasyfikacji AI przypisuje nadzorowane tagi do obiektów zabezpieczanych w Unity Catalog, takich jak katalogi, schematy, tabele, kolumny, modele i woluminy. Na przykład oznacz kolumny zawierające dane osobowe za pomocą znacznika pii : ssn lub oznacz model za pomocą znacznika lifecycle : production. Poprawne tagowanie jest pierwszym krokiem do zastosowania zasad ABAC.

   • Wymagane uprawnienia: ASSIGN na tagu i APPLY TAG w obiekcie.

3. Utwórz zasady. Administrator zarządzania tworzy politykę w obszarze, takim jak katalog lub schemat. Zasada określa, kogo dotyczy, jakie warunki ocenia oraz jakie działanie ma zostać zastosowane, takie jak filtr wierszy, maska kolumn lub przyznanie uprawnień.

   • Wymagane uprawnienia: uprawnienie MANAGE lub prawo własności obiektu zabezpieczalnego, do którego jest dołączona zasada. W przypadku zasad filtrowania wierszy i maskowania kolumn wymagane jest również uprawnienie EXECUTE do funkcji zdefiniowanej przez użytkownika.

4. Tworzenie obiektów danych. Twórcy danych tworzą zabezpieczane obiekty, takie jak tabele, modele lub woluminy w zakresach, do których udzielono im dostępu. Nowe obiekty dziedziczą tagi z katalogów nadrzędnych i schematów. Twórcy danych mają APPLY TAG również automatycznie tworzone obiekty, dzięki czemu mogą zastosować dodatkowe tagi. Alternatywnie mogą polegać na automatycznej klasyfikacji danych do obsługi tagowania. Jeśli organizacja korzysta z twórców danych do tagowania własnych obiektów, powinna ustanowić jasne praktyki tagowania. Twórcy danych nie muszą konfigurować żadnych mechanizmów kontroli dostępu, jeśli zasady są ustawione na wyższych poziomach, co Azure Databricks zaleca.

   • Wymagane uprawnienia: CREATE TABLE lub inne odpowiednie uprawnienia do tworzenia w obrębie obiektu nadrzędnego.

5. Uzyskaj dostęp do zarządzanych obiektów. Gdy użytkownik próbuje uzyskać dostęp do zabezpieczanego obiektu objętego zakresem obowiązywania zasad, Unity Catalog automatycznie ocenia odpowiednie zasady. W przypadku zasad filtrowania wierszy i maski kolumn użytkownik widzi dane filtrowane lub maskowane, jeśli tabela lub kolumny są zgodne z warunkami zasad, a użytkownik nie jest wykluczony. W przypadku zasad GRANT użytkownik uzyskuje przyznany przywilej, jeśli warunki są spełnione oraz użytkownik należy do TO, a nie do EXCEPT.

   • Wymagane uprawnienia: w przypadku zasad filtrowania wierszy i zasad maskowania kolumn użytkownicy muszą mieć przyznane uprawnienia do tabeli, na przykład SELECT, poprzez bezpośrednie nadanie uprawnień do obiektu. Te zasady filtrują rekordy lub maskują kolumny w tabelach, do których użytkownik ma już dostęp. Nie udzielają uprawnień samodzielnie. GRANT Zasady same przyznają to uprawnienie i są sumowane ze wszystkimi uprawnieniami przyznanymi bezpośrednio do tego samego zabezpieczalnego obiektu.

Korzyści wynikające z usługi ABAC

• Zasady wielokrotnego użytku oparte na atrybutach: Pojedyncze zasady mogą być stosowane do wielu obiektów danych, które pasują do tych samych warunków opartych na atrybutach, zamiast być powiązane z jednym określonym obiektem.

• Automatyczna aplikacja do nowych obiektów: Gdy nowe obiekty danych są tworzone w zakresie i oznaczone odpowiednimi atrybutami, istniejące zasady ABAC mają zastosowanie bez dodatkowej konfiguracji. Zasady działają jak przyszłe dotacje, co oznacza, że mechanizmy kontroli dostępu są stosowane automatycznie, gdy nowe dane są tworzone i odpowiednio oznakowane.

• Spójne wymuszanie w zakresie: Zasady dołączone na poziomie wykazu lub schematu są oceniane dynamicznie względem pasujących obiektów danych w tym zakresie, co eliminuje różnice w sposobie filtrowania lub maskowania podobnych danych.

• Niższe bieżące koszty konserwacji: Zmiany można wprowadzać, aktualizując logikę zasad lub zarządzane tagi, zamiast ponownie przeglądać poszczególne obiekty, co jest wymagane przy użyciu filtrów wierszy na poziomie tabeli i masek kolumn.

• Scentralizowany nadzór: Ponieważ zasady można definiować raz i stosować w wielu pasujących obiektach danych, zespoły nadzoru mogą zarządzać kontrolkami w większych częściach majątku danych z mniejszą liczbą definicji zasad.

Dodatkowe zasoby

• Tagi zarządzane
• TWORZENIE ZASAD
• Zarządzanie uprawnieniami w Unity Catalog
• Filtry wierszy i maski kolumn
• Dokumentacja tabeli systemu dzienników inspekcji
• Wymagania, limity przydziału i ograniczenia dotyczące zasad filtrowania wierszy i maski kolumn