Použití RBAC s ABAC

Important

RBAC je ve veřejném náhledu. ABAC je obecně dostupný. Tato stránka popisuje, jak oba spolupracují.

Řízení přístupu na základě role (RBAC) a řízení přístupu na základě atributů (ABAC) v katalogu Unity jsou doplňkové ovládací prvky navržené tak, aby spolupracovaly. Odpovídají na různé otázky:

• RBAC určuje, která identita uživatele se použije pro relaci. Uživatel převezme roli a jedná s oprávněními této role namísto svých vlastních oprávnění. RBAC použijte k tomu, aby jeden uživatel mohl explicitně přepínat mezi různými sadami oprávnění – například oddělení přístupu mezi klinickými studiemi, projekty nebo úrovněmi citlivosti.
• ABAC určuje , jaká data může aktivní identita zobrazit, řádek podle řádku nebo sloupce podle sloupce. Zásady se připojují k datům prostřednictvím řídicích značek a vztahují se na to, která identita spouští dotaz. ABAC slouží k konzistentnímu filtrování nebo maskování v mnoha tabulkách řízených atributy dat.

RBAC určuje aktivní identitu pro danou relaci a ABAC vůči této identitě vyhodnocuje své zásady. Tato stránka popisuje, jak se tato interakce hraje v praxi, chování funkcí SQL souvisejících s identitami a vzory kombinovaného použití.

Jak se funkce identit chovají při převzetí role

SQL funkce související s identitou v Unity Catalog se vyhodnocují vůči aktivní identitě relace, nikoli vůči uživateli, který se skutečně ověřil. Když uživatel převezme roli, identita aktivní relace se stane touto rolí:

Function	Když uživatel jedná pod svou uživatelskou identitou	Když uživatel převezme roli
current_user()	Vrátí uživatelské jméno uživatele.	Vrátí název předpokládané role.
is_member(group)	Vrátí true , pokud je uživatel členem skupiny (místní skupina pracovního prostoru nebo skupina účtů přiřazená k pracovnímu prostoru).	Vrátí true pouze v případě, že předpokládaná role je členem group. Vrátí false pro skupiny, jejichž členem je základní uživatel, ale převzatá role nikoli.
is_account_group_member(group)	Vrátí true , pokud je uživatel členem skupiny na úrovni účtu.	Stejné jako is_member: vrátí true pouze na základě členství ve skupinách převzaté role, nikoli původního uživatele.

Zásady ABAC, které odkazují na tyto funkce, se vyhodnocují proti předpokládané roli, nikoli uživateli. Převzatá role je aktivní identita pro vyhodnocování zásad ABAC, určování oprávnění v Unity Catalog a přiřazování auditních záznamů. V důsledku toho převzetí role mění chování stávajících zásad a zobrazení, které byly vytvořeny na základě identity jednotlivých uživatelů.

Note

Role není automaticky členem sebe sama. Když uživatel převezme roli G, current_user() vrátí G, ale is_member('G') a is_account_group_member('G') vracejí false, pokud G nebyl explicitně přidán jako člen sebe sama. Chcete-li v zásadě porovnávat s převzatou rolí, porovnávejte s current_user() namísto ověřování členství pomocí is_member nebo is_account_group_member.

Běžné nástrahy: zobrazení zabezpečení na úrovni řádků postavená na current_user()

Běžným vzorem pro filtry řádků na úrovni tabulky a ABAC je filtrování řádků spojením se zřizovací tabulkou (označovanou také jako mapovací tabulka nebo seznam řízení přístupu) s klíčem k uživatelskému jménu vrácenému uživatelem current_user(). Příklady:

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

Pokud stejný uživatel převezme roli, current_user() už nevrátí jeho uživatelské jméno. Vrátí název role. Protože role není v tabulce provisioningu, filtr nevrátí žádné řádky a uživatel pak vypadá, jako by přišel o přístup k datům, k nimž mu byl přístup udělen.

Přidejte roli do tabulky provisioningu

S rolí zacházejte jako s dalším objektem zabezpečení ve svých datech pro zřizování: pro každou roli vložte jeden řádek s oprávněními (nebo jinými atributy), které má role vidět. Filtr pak určuje, zda je aktivní identita uživatel, nebo převzatá role.

Kombinované vzory použití

Tady jsou příklady toho, jak zákazníci používají RBAC a ABAC společně k řešení skutečných problémů s řízením přístupu. Jedná se o výchozí body, ne vyčerpávající recepty.

Filtry řádků pro jednotlivé projekty založené na převzaté roli

Filtrování řádků podle projektu je běžnou potřebou při výzkumu klinických studií, smluvním marketingu, klientském poradenství a v dalších prostředích, kde jeden tým pracuje na několika vzájemně oddělených projektech. Následující příklad používá klinické studie, ale vzor generalizuje jakoukoli izolaci dat podle projektu.

Organizace klinického výzkumu provozuje několik souběžných studií, z nichž každá má vlastní přístupovou roli. Označte každou tabulku identifikátorem projektu. Uživatelé vidí pouze řádky projektu, pro který mají právě převzatou roli.

Nastavení:

• Tabulky pod clinical_trials.* mají sloupec project_id opatřený klíčem governed tagproject.
• Každý projekt má odpovídající přístupovou roli s názvem role-<project> (například role-alpha, ). role-beta
• Uživatelé mají oprávnění „Assume“ pouze pro role v projektech, na kterých pracují.

UDF filtru řádků:

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

Politika:

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);

Tato UDF přiřazuje aktivní identitu k hodnotě tagu project v každém řádku, takže to nelze vyjádřit pomocí klauzulí zacílených na principály, jako jsou TO / EXCEPT — ty cílí na principály, nikoli na obsah řádku. Jak vysvětlují pokyny pro cílení na identity, pro jednoduché vymezení rozsahu identit upřednostněte TO / EXCEPT a funkce identity uvnitř UDF si vyhraďte pro případy, jako je tento, kdy jedno pravidlo závisí jak na aktivní identitě, tak na obsahu řádku.

Jedna zásada se vztahuje na každý projekt: USING COLUMNS (project) předává hodnotu tagu project z každého řádku do funkce definované uživatelem (UDF), takže nepotřebujete samostatnou zásadu pro každý projekt. Obecná forma této techniky – řízení přístupu k řádkům z vyhledávací tabulky místo porovnávání názvů rolí – viz Použití mapovacích tabulek pro dynamické řízení přístupu.

Chování:

• Uživatel, který vystupuje pod svou uživatelskou identitou, nevidí v žádné tabulce clinical_trials. current_user() vrací uživatelské jméno, které nikdy neodpovídá vzoru pojmenování role-*. Toto je zamýšlené implicitní odmítnutí.
• Uživatel s rolí role-alpha vidí pouze řádky, kde se project_id rovná alpha. Přepnutí na role-beta vymění zobrazená data, aniž by se znovu dotazovalo na cokoli jiného.

Zmírněné maskování PII pro uživatele vystupující v určené roli

Ve výchozím nastavení se sloupce PII (SSN, e-mail, telefon) zobrazují maskované pro všechny. Chce-li uživatel zobrazit nezpracované hodnoty, musí výslovně převzít určenou roli s oprávněním pro práci s PII. Protokoly auditu zaznamenávají událost převzetí role, takže z „Potřeboval jsem se podívat na skutečné PII“ se stane auditovatelné vědomé přihlášení namísto trvalého oprávnění.

Nastavení:

• Citlivé sloupce jsou označené klíčem řízené značkypii (povolené hodnoty, například ssn, email, phone).
• Přístupová role s názvem role-pii-cleared uděluje oprávnění převzít tuto roli uživatelům, kteří mají oprávnění zobrazovat nezpracované osobní údaje.

UDF pro maskování sloupců (statické – zásady určují, které identity se mají maskovat):

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

Politika:

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;

Klauzule EXCEPT zcela vylučuje role-pii-cleared ze zásad, takže se uživatelsky definovaná funkce nikdy nespustí, pokud je tato role aktivní identitou. Viz Upřednostnění TO/EXCEPT pro cílení na objekty zabezpečení, kde najdete obecné pokyny k cílení na objekty zabezpečení prostřednictvím TO / EXCEPT.

Chování:

• Uživatel jednající pod svou uživatelskou identitou vidí *** v každém sloupci PII. Toto je výchozí stav pro všechny, včetně uživatelů, kteří mají oprávnění Assume k objektu role-pii-cleared.
• Po předpokladu role-pii-cleareduž zásady neplatí pro relaci a stejný uživatel uvidí nezpracované hodnoty.
• Položky protokolu auditu relace zaznamenávají identity_metadata.run_as = role-pii-cleared, takže kontroloři mohou přesně vidět, kdy byly údaje PII odkryty a kým.

Zásady úrovně citlivosti, které se liší podle předpokládané role

Data se klasifikují do úrovní citlivosti (internal, confidential, restricted). Každá úroveň má odpovídající přístupovou roli, přičemž restricted zahrnuje také přístup k confidential a internal. Jedna uživatelsky definovaná funkce (UDF) pro filtrování řádků řídí viditelnost řádků porovnáním úrovně každého řádku s předpokládanou rolí uživatele.

Nastavení:

• Tabulky mají sloupec sensitivity_level označený klíčem governed tagsensitivity (povolené hodnoty: internal, confidential, restricted).
• Tři přístupové role: role-sens-internal, role-sens-confidential, role-sens-restricted.

UDF filtru řádků:

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

Politika:

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);

Protože role není členem sama sebe, porovnává tato uživatelsky definovaná funkce (UDF) current_user() s názvem každé role namísto testování členství pomocí is_account_group_member(). Podívejte se na výše uvedenou poznámku , proč se testy členství neshodovaly s předpokládanou rolí. Viz Otázky výkonu pro zásady filtrování řádků a maskování sloupců, kde najdete informace o výkonových charakteristikách identitních funkcí v UDF.

Chování:

• Uživatel, který vystupuje pod svou uživatelskou identitou, nevidí žádné řádky. Větev ELSE FALSE odpovídá všemu, co není jednou ze tří rolí. Stejně jako v příkladu pro každý projekt výše jde o zamýšlený výchozí zákaz.
• Za předpokladu, že role-sens-internal se zobrazí jenom internal řádky.
• Za předpokladu, že role-sens-confidential zobrazí řádky internal a confidential.
• Za předpokladu, že role-sens-restricted zobrazí všechny řádky.

Uživatelé předpokládají nejvyšší úroveň, kterou potřebují pro relaci; filtr automaticky vyloučí vše nad danou úrovní, aniž by uživatel musel zjistit, které tabulky obsahují klasifikace.

Přiřazení auditu

Jak hodnocení zásad ABAC, tak podkladové dotazy respektují atribuci RBAC run_as / run_by. Záznamy protokolu auditu se zaznamenávají identity_metadata.run_by jako ověřovací uživatel a identity_metadata.run_as jako předpokládaná role bez ohledu na to, které zásady ABAC byly použity během vyhodnocení. Úplné schéma protokolu auditování najdete v referenčních informacích k systémové tabulce protokolu auditu.

Další kroky

• Výhradní přístup k modelu: Použijte vzory pro nastavení výhradního přístupu pomocí místní skupiny účtu nebo skupiny synchronizované z Microsoft Entra ID. Podívejte se na exkluzivní přístup k modelu.
• Přepínání rolí: Převezměte roli prostřednictvím přepínače rolí, clusterů s vyhrazeným režimem přístupu, rozhraní příkazového řádku, rozhraní API nebo nástrojů BI třetích stran. Viz Přepnutí rolí.
• Spravovat oprávnění k převzetí role: Udělte nebo odeberte skupině oprávnění k převzetí role, aby uživatelé mohli převzít odpovídající roli. Viz Správa oprávnění ve skupině.
• Seznamte se se základními principy ABAC: Zjistěte, jak fungují spravované značky, zásady a vyhodnocování zásad. Viz Řízení přístupu na základě atributů v katalogu Unity.