Grundläggande begrepp för attributbaserad åtkomstkontroll (ABAC)

Den här sidan introducerar ABAC, hur den använder reglerade taggar, principer och användardefinierade funktioner för att styra vilka rader som användare kan se och hur kolumnvärden presenteras och dess fördelar. På den här sidan beskrivs även de behörigheter som krävs för att konfigurera ABAC och de ansvarsfördelningar som möjliggörs mellan teamen.

Se Attributbaserad åtkomstkontroll i Unity Catalog för en översikt över alla ABAC-ämnen, inklusive självstudier, principhantering, metodtips och begränsningar.

Vad är ABAC?

Attributbaserad åtkomstkontroll (ABAC) är en modell för dynamisk åtkomstkontroll där åtkomstbeslut baseras på principer som utvärderas mot attribut som är associerade med skyddsbara objekt. I Unity Catalog representeras dessa attribut via reglerade taggar. Dessa reglerade taggar används i principvillkor för att matcha dataobjekt inom ett visst omfång, till exempel en katalog eller ett schema. På så sätt kan en enskild princip tillämpas automatiskt på flera dataobjekt som uppfyller dess villkor.

En ABAC-princip kan till exempel maskera alla kolumner som är taggade PII för tabeller i scheman som är taggade HR. När nya dataobjekt skapas och taggas tillämpas principen automatiskt utan att det krävs separata principdefinitioner för varje objekt.

ABAC stöder säkerhet på rad- och kolumnnivå via radfilterprinciper och kolumnmaskprinciper för tabeller, materialiserade vyer och strömmande tabeller. Radfilterprinciper begränsar vilka rader en användare kan se. Kolumnmaskprinciper styr hur kolumnvärden visas för användare.

En jämförelse med radfilter och kolumnmasker på tabellnivå finns i När du ska använda ABAC jämfört med radfilter på tabellnivå och kolumnmasker.

Reglerade taggar

I Unity Catalog implementeras attribut som reglerade taggar. Reglerade taggar är nyckel/värde-par som definierats på kontonivå och tillämpas på Skyddsbara objekt i Unity Catalog, till exempel kataloger, scheman, tabeller och kolumner, utöver arbetsyteobjekt. De representerar egenskaper som känslighet, klassificering eller affärsdomän.

Som standard ärver taggar från överordnade kataloger och scheman till tabeller, men inte från tabeller till kolumner. Du kan åsidosätta ärvda taggar på valfri nivå, men taggar på kolumnnivå måste tillämpas direkt.

Reglerade taggar kan refereras i principvillkor med hjälp av inbyggda funktioner som has_tag() och has_tag_value(), som kontrollerar om en viss tagg finns på måldataobjektet, antingen direkt eller via taggarv.

Reglerade taggar definieras på kontonivå. Det innebär att du kan använda samma taggtaxonomi i hela dataegendomen i ett konto, inklusive i flera metaarkiv.

Mer information finns i Reglerade taggar och Tillämpa taggar på skyddsbara objekt i Unity Catalog.

Policies

Principer är kopplade till skyddsbara objekt i Unity Catalog för att definiera åtkomstkontrollregler baserat på taggvillkor. Nedan visas ett exempel:

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;

Varje princip anger:

• Omfång: Den skyddbara enheten där policyn är kopplad, som anges av ON-satsen. Att fästa en policy till ett säkerställbart objekt innebär att policyns villkor utvärderas för alla objekt av den typ som anges i FOR-satsen, för den säkerställbara och alla dess underordnade objekt.
  • Principomfattningar som stöds idag är CATALOG, SCHEMAeller TABLE.
  • Tabeller, inklusive strömmande tabeller och materialiserade vyer, är för närvarande den enda skyddsbara typen som anges med hjälp av FOR TABLES -satsen.
  • En princip som är kopplad till en katalog utvärderas mot alla tabeller i katalogen. En princip som är kopplad till ett schema utvärderas mot alla tabeller i schemat. En princip som är kopplad till en tabell utvärderas endast mot den tabellen.

• Principaler: Vem policyn gäller för och vem som är undantagen. Satsen TO anger vilka användare, grupper eller tjänsthuvudnamn som omfattas av principen. Den valfria EXCEPT satsen exkluderar specifika principer från den här policyn.
• Åtgärder: Om principen tillämpar ett radfilter eller en kolumnmask. Åtgärden implementeras av en användardefinierad funktion (UDF) som definierar logiken för filtrering eller maskering. Se Principtyper.
• Villkor: Taggbaserade uttryck som avgör vilka tabeller eller kolumner som principmålen ska vara. Se Villkor och inbyggda funktioner.

Principer skapas och hanteras via användargränssnittet eller programmatiskt med SQL-instruktioner, till exempel CREATE POLICY, DROP POLICY, SHOW POLICIESeller DESCRIBE POLICY, REST-API:er, Databricks SDK:er eller Terraform. Se Skapa och hantera ABAC-principer för fullständig syntax och exempel.

Policytyper

ABAC har stöd för två principtyper: radfilterprinciper och kolumnmaskprinciper. Båda kräver UDF:er för att implementera filtrerings- eller maskeringslogik.

Principer för radfilter

Radfilterprinciper begränsar vilka rader en användare kan se i en tabell baserat på värden i kolumner som identifieras av taggar som matchar villkor och inbyggda funktioner. Principen refererar till en UDF som utvärderar varje rad. Rader där funktionen returnerar FALSE undantas från frågeresultat. Argument skickas till UDF via USING COLUMNS -satsen.

Exempel på användningsfall: För en försäljningskatalog kontrollerar du att EMEA-teamet endast ser EMEA-försäljningsposter i alla tabeller som har en kolumn taggad region.

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

Principer för kolumnmaskering

Kolumnmaskprinciper styr vilka värden en användare ser för specifika kolumner som identifieras av taggar som matchar villkor och inbyggda funktioner. Principen refererar till en UDF som tar kolumnvärdet som indata och returnerar det ursprungliga värdet eller en maskerad version. Det maskerade kolumnvärdet binds automatiskt som det första argumentet från ON COLUMN -satsen, och ytterligare argument kan skickas via USING COLUMNS. Returtypen måste matcha eller kan typomvandlas till kolumnens datatyp.

Exempel på användningsfall: Maskera SSN-kolumner taggade med pii : ssn så att användarna ser ***-**-XXXX (endast de fyra sista siffrorna) om de inte finns i en efterlevnadsgrupp som är undantagen från principen.

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

Satsen USING COLUMNS skickar argument till UDF. Den accepterar alias för kolumner som matchar ett taggbaserat uttryck eller konstanta värden (citerade strängar, numeriska literaler, booleska värden (TRUE/FALSE) eller NULL), som anges i den ordning som funktionen förväntar sig dem. För kolumnmaskprinciper är dessa ytterligare argument utanför den maskerade kolumnen (som automatiskt binds från ON COLUMN). Detta gör att en enda UDF kan återanvändas mellan principer med olika parametrar.

SQL UDF:er rekommenderas för bättre prestanda. Python UDF:er som registrerats i Unity Catalog stöds också, men frågeoptimeraren kan inte infoga eller optimera dem på det sätt som sql-UDF:er kan användas. Se Prestandaöverväganden för vägledning om val av UDF-språk.

Villkor och inbyggda funktioner

Villkor är taggbaserade uttryck som avgör vilka tabeller och kolumner som en princip har som mål inom dess omfång.

• Tabellvillkor (WHEN sats): Booleska uttryck som matchar tabeller baserat på deras taggar. Om det utelämnas används standardvärdet TRUE, vilket innebär att principen gäller för alla tabeller i omfånget.
• Kolumnvillkor (MATCH COLUMNS sats): Ett eller flera kommaavgränsade booleska uttryck som identifierar vilka kolumner som principmålen är. Varje uttryck kan vara en enda inbyggd funktion som has_tag('pii'), eller en kombination med logiska operatorer som has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Varje uttryck kan tilldelas ett alias (som anges efter AS) som refereras i ON COLUMN och USING COLUMNS-satserna. En princip kan innehålla upp till 3 kolumnuttryck och alla måste matcha för att principen ska gälla.

Båda satstyperna använder följande inbyggda funktioner som utvärderas av Unity Catalog mot säkra metadata:

Taggar sprids inte från tabeller till kolumner. Att använda has_tag() i en MATCH COLUMNS villkor matchar bara taggar på kolumnnivå, inte taggar på föräldertabellen eller dess föregångare.

Exempel: använda två kolumnvillkor. Ett customers schema har tabeller med en e-postkolumn taggad pii : email och en medgivandekolumn taggad consent_to_contact. Principen maskerar e-postadresser om inte kunden har samtyckt till att bli kontaktad. Den använder två kolumnvillkor:

1. has_tag_value('pii', 'email') identifierar kolumnen som innehåller e-postadresser (kolumnen som ska maskeras).
2. has_tag('consent_to_contact') identifierar kolumnen som innehåller medgivandeinformation (som används av UDF för att avgöra om den ska maskeras).

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

Den här principen gäller endast för tabeller som har både en kolumn taggad pii : email och en kolumn taggad consent_to_contact. Om en tabell inte har kolumner som matchar båda villkoren gäller inte principen och data returneras avmaskerade.

Användardefinierade funktioner (UDF:er)

Principer för radfilter och kolumnmask använder användardefinierade funktioner (UDF: er) för att implementera filtrerings- eller maskeringslogik. Se Användardefinierade funktioner (UDF: er) i Unity Catalog för hur du skapar och hanterar UDF:er och Vanliga mönster för radfiltrering och kolumnmaskning .

Uppdelning av uppgifter och behörigheter

Att konfigurera ABAC omfattar flera steg, var och en med sina egna behörighetskrav. Organisationer kan distribuera dessa uppgifter mellan specialiserade grupper beroende på hur de väljer att separera uppgifter. Till exempel kan en organisation definiera en taggtaxonomi centralt, sedan låta dataförvaltare klassificera data, styrningsadministratörer skriva principer, skapa dataskapare skapa objekt inom reglerade omfång och datakonsumenter köra frågor mot resultaten.

1. Skapa taggtaxonomi. Definiera de reglerade taggnycklarna och deras tillåtna värden innan någon tillämpar dem eller skriver principer. Skapa till exempel en sensitivity tagg med kontrollerade värden (public, , internalconfidential, restricted) eller en pii tagg med värden som ssn, emailoch phone_number. Se Standardisera attribut och namngivning för rekommendationer om namngivningskonventioner och taxonomidesign.

   • Nödvändiga behörigheter: Kontoadministratör eller en användare med CREATE behörighet för taggar på kontonivå.

2. Tagga datatillgångar. Ett dataförvaltare, dataskapare eller AI-klassificeringssystem tillämpar reglerade taggar på kataloger, scheman, tabeller eller kolumner. Tagga till exempel kolumner som innehåller personligt identifierbar information med pii : ssn. Korrekt taggning är det viktigaste första steget för att ABAC-principer ska tillämpas.

   • Nödvändiga behörigheter: ASSIGN på taggen och APPLY TAG på objektet.

3. Skapa en policy. En styrningsadministratör skapar en policy i ett omfång, till exempel en katalog eller ett schema. Principen anger vem den gäller för, vilka villkor den utvärderar och den UDF som implementerar logiken för filtrering eller maskering.

   • Nödvändiga behörigheter: MANAGE behörighet eller objektägarskap på säkerhetsobjektet där policy är kopplad (katalog, schema eller tabell) och EXECUTE privilegier på UDF.

4. Skapa dataobjekt. Dataskapare skapar tabeller inom de omfång som de har beviljats åtkomst till. Nya tabeller ärver taggar från överordnade objekt som kataloger och scheman. Dataskapare har APPLY TAG också automatiskt på objekt som de skapar, så att de kan använda ytterligare taggar. De kan också förlita sig på automatisk dataklassificering för att hantera taggning. Om en organisation förlitar sig på att dataskapare ska tagga sina egna objekt bör den upprätta tydliga taggningsmetoder. Dataskapare behöver inte konfigurera några åtkomstkontroller om principer anges på högre nivåer, vilket Azure Databricks rekommenderar.

   • Nödvändiga behörigheter: CREATE TABLE eller andra relevanta skaparbehörigheter på det överordnade objektet.

5. Fråga efter data. När en datakonsument frågar en tabell inom principens omfång utvärderas principen automatiskt. Om tabellen eller kolumnerna matchar principens villkor och användaren inte är undantagen ser konsumenten filtrerade eller maskerade data.

   • Nödvändiga behörigheter: Användare måste beviljas behörigheter i tabellen, till exempel SELECT, via ett direkt objektbidrag. ABAC-radfilter- och kolumnmaskeringsprinciper beviljar inte behörigheter på egen hand. De filtrerar bara poster eller maskerar kolumner för tabeller som en användare redan kan komma åt.

Fördelar med ABAC

• Återanvändbara principer baserat på attribut: En enskild princip kan tillämpas på flera dataobjekt som matchar samma attributbaserade villkor i stället för att vara knutna till ett specifikt objekt.

• Automatiskt program till nya objekt: När nya dataobjekt skapas inom omfånget och taggas med relevanta attribut gäller befintliga ABAC-principer utan ytterligare konfiguration. Principer fungerar som framtida bidrag, vilket innebär att åtkomstkontroller tillämpas automatiskt när nya data skapas och taggas på lämpligt sätt.

• Konsekvent tillämpning inom ett omfång: Principer som är kopplade på katalog- eller schemanivå utvärderas dynamiskt mot matchande dataobjekt i det omfånget, vilket tar bort skillnader i hur liknande data filtreras eller maskeras.

• Lägre löpande underhåll: Ändringar kan göras genom att uppdatera principlogik eller styrda taggar, i stället för att gå tillbaka till varje enskilt objekt som krävs med radfilter på tabellnivå och kolumnmasker.

• Centraliserad styrning: Eftersom principer kan definieras en gång och tillämpas på många matchande dataobjekt kan styrningsteam hantera kontroller över större delar av dataegendomen med färre principdefinitioner.

Mer information

• Styrda taggar
• SKAPA PRINCIP
• Hantera behörigheter i Unity Catalog
• Radfilter och kolumnmasker
• Tabellreferens för granskningsloggsystem
• ABAC-krav, kvoter och begränsningar