När du ska använda ABAC jämfört med radfilter på tabellnivå och kolumnmasker

Unity Catalog stöder två metoder för säkerhet på radnivå och kolumnnivå: ABAC-principer och radfilter på tabellnivå och kolumnmasker. Ingen av metoderna ger åtkomst till data på egen hand – båda lägger till begränsningar utöver befintliga behörigheter på objektnivå. Du måste bevilja bastabellåtkomst separat via behörigheter på objektnivå (GRANT).

Den viktigaste skillnaden är var begränsningarna definieras. Radfilter på tabellnivå och kolumnmasker tillämpar känslighetskontroller direkt på enskilda tabeller med hjälp av ALTER TABLE. Tabellägare hanterar sitt eget dataskydd utan att behöva ett styrt taggsystem. Detta är enkelt för ett litet antal tabeller, men varje tabell måste konfigureras individuellt, och tabellägare kan ändra eller ta bort sina egna filter och masker.

ABAC-principer bifogas på katalog-, schema- eller tabellnivå och matchar tabeller och kolumner dynamiskt baserat på reglerade taggar. En princip som definierats på katalognivå gäller för alla tabeller i katalogen och enskilda tabellägare kan inte ta bort, ändra eller kringgå den. Regeln finns i katalogen och utvärderas av Unity Catalog innan frågan når körtiden. På så sätt kan administratörer på högre nivå tillämpa organisationsomfattande regler och se till att administratörer och ägare på lägre nivå inte kan kringgå dem.

Detaljerad jämförelsesammanfattning

Den här tabellen sammanfattar skillnaderna mellan ABAC-principer och radfilter på tabellnivå och kolumnmasker.

Att tänka på	ABAC-principer	Radfilter och kolumnmasker på tabellnivå
SQL-syntax	CREATE POLICY ... ON CATALOG/SCHEMA/TABLE	ALTER TABLE ... SET ROW FILTER / ALTER TABLE ... ALTER COLUMN ... SET MASK
Scope	Alla tabeller inom policyomfånget (katalog, schema eller tabell) och deras underordnade. Nya taggade tabeller täcks automatiskt.	En enda tabell där filtret eller masken har konfigurerats. Varje tabell måste konfigureras individuellt.
Dynamisk matchning	Tabeller och kolumner matchas dynamiskt baserat på reglerade taggar med hjälp av has_tag() och has_tag_value().	Ingen dynamisk matchning. Filter och masker är bundna till specifika tabeller och kolumner.
Målobjekt	TO / EXCEPT klausuler i principdefinitionen, förutom identitetsfunktionerna i UDF.	Identitetsfunktioner som current_user() i UDF.
Policyförvaltning	Principer kan anges av katalog- eller schemaägare. När de har ställts in på en nivå kan tabellägare inte åsidosätta, ändra eller ta bort dem.	Hanteras av tabellägare, som kan ändra eller ta bort filter och masker i sina egna tabeller.
Funktioner som inte stöds	Icke-stödda operationer som kloning och OpenSharing kan köras av principer i klausulen EXCEPT . Se Fail-closed design.	Ingen EXCEPT sats, så funktioner som inte stöds förblir otillgängliga för skyddade tabeller.
Effektiva principer	SHOW EFFECTIVE POLICIES för att se vilka principer som gäller för en viss tabell och användare.	Direkt synlig i tabelldefinitionen.
Granskningsbarhet	DESCRIBE POLICY och SHOW POLICIES för att granska principdefinitioner.	INFORMATION_SCHEMA.ROW_FILTERS och INFORMATION_SCHEMA.COLUMN_MASKS.

I allmänhet använder du ABAC-principer när:

• Du behöver konsekventa åtkomstregler för många tabeller, scheman eller kataloger.
• Din organisation separerar uppgifter. Principförfattare definierar till exempel regler och dataförvaltare klassificerar data med taggar.
• Din dataegendom växer och du vill att nya tabeller ska täckas automatiskt när de taggas.
• Du behöver klausulen EXCEPT för att tillåta icke-stödda operationer som OpenSharing eller fullständig frågeoptimering för specifika principer. Se Icke-stödda operationer på skyddad data

I allmänhet använder du radfilter på tabellnivå och kolumnmasker när:

• Varje tabell har strikt, specifik logik som inte generaliseras till andra tabeller.
• Tabellägare bör hantera sina egna filter och masker direkt, utan ett centraliserat taggsystem.
• Du har en liten, stabil uppsättning tabeller som ändras sällan.

Kombinera ABAC och radfilter på tabellnivå och kolumnmasker

ABAC och radfilter på tabellnivå och kolumnmasker kan samexistera i samma tabell. Vid frågetillfället utvärderas principerna oberoende för den frågande användaren med följande regler:

• Endast ett distinkt radfilter kan användas.
• Endast en distinkt kolumnmask kan lösas upp per kolumn.

Azure Databricks utvärderar konflikter genom att jämföra de funktioner som tillämpas, inte datautdata. Om både en ABAC-princip och ett filter eller en mask på tabellnivå använder samma radfilter eller kolumnmaskfunktion för samma användare, tillåter Azure Databricks utförandet. Om de använder olika funktioner blockerar Azure Databricks åtkomsten och returnerar ett fel, även om dessa funktioner ger identiska datautdata.

För detaljer om konfliktlösning och felsökning, se Konflikterande filter och masker.

Säkerhet på radnivå och kolumnnivå med dynamiska vyer

Dynamiska vyer kan också implementera säkerhet på radnivå och kolumnnivå genom att bädda in identitetsfunktioner som current_user() och is_account_group_member() direkt i vydefinitionen. Dynamiska vyer, radfilter och kolumnmasker tillämpar alla filtrerings- eller transformeringslogik vid frågetillfället, men de skiljer sig åt i hur de hanteras, begränsas och exponeras för användare.

Feature	Gäller för	Så här hanteras den	Används bäst för
Dynamiska vyer	Views	SQL-logik i vydefinitionen	Detaljerad åtkomstkontroll som omfattar flera källtabeller eller omformar data för delning
Radfilter och kolumnmasker	Tabeller och kolumner	ABAC-principer eller tilldelning på tabellnivå	Åtkomstkontroll på radnivå och kolumnnivå utan att introducera nya objekt

Använd dynamiska vyer när du behöver detaljerad åtkomstkontroll som omfattar flera källtabeller eller omformar data för delning. Använd radfilter och kolumnmasker när du vill styra åtkomsten till enskilda tabeller utan att introducera nya objekt.

En dynamisk vy kan till exempel maskera en e-postkolumn för icke-granskare:

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE
    WHEN is_account_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END AS email,
  country,
  product,
  total
FROM sales_raw

Dynamiska vyer har fullt stöd för frågeoptimering och predikatnedtryckning, och kan erbjuda bättre frågeprestanda än radfilter och kolumnmasker. De hindrar också användare från att ändra de underliggande tabellerna.

Dynamiska vyer har dock två nackdelar med datastyrning:

• Begränsad granskning: Dynamiska vyer saknar semantiska metadata, till exempel taggar eller principdefinitioner i systemtabeller, vilket gör dem svårare att granska i stor skala.
• Sårbarhet för avsökning: Eftersom de saknar en SecureView barriär skyddar de inte mot avsökningsattacker, där en användare skapar ett predikat med biverkningar för att härleda information om filtrerade rader. Se Förståelse för predikatnedtryckning på skyddade tabeller.