Använd RBAC med ABAC

Rollbaserad åtkomstkontroll (RBAC) och attributbaserad åtkomstkontroll (ABAC) i Unity Catalog är kompletterande kontroller som är utformade för att fungera tillsammans. De svarar på olika frågor:

• RBAC styr vilken identitet en användare fungerar som för en session. En användare antar en roll för att agera med den rollens behörigheter i stället för sin egen. Använd RBAC för att ge en användare flera distinkta behörighetsuppsättningar som de växlar mellan explicit – till exempel att separera åtkomst mellan kliniska prövningar, projekt eller känslighetsnivåer.
• ABAC styr vilka data den aktiva identiteten kan se, rad för rad eller kolumn efter kolumn. Policyer kopplas till data via styrda taggar och gäller för den identitet som kör frågan. Använd ABAC för konsekvent filtrering eller maskering i många tabeller som drivs av dataattribut.

RBAC anger den aktiva identiteten för sessionen och ABAC utvärderar sina principer mot den identiteten. Den här sidan beskriver hur interaktionen utspelar sig i praktiken, beteendet för identitetsrelaterade SQL-funktioner och mönster för kombinerad användning.

Hur identiteter fungerar när de tar på sig en roll

Identitetsrelaterade SQL-funktioner i Unity Catalog tolkas utifrån den aktiva identiteten för sessionen, inte utifrån den underliggande autentiserade användaren. När en användare antar en roll blir den aktiva sessionsidentiteten rollen:

ABAC-principer som refererar till dessa funktioner utvärderas mot den antagna rollen, inte användaren. Den övertagna rollen är den aktiva identiteten för utvärdering av ABAC-policyer, tolkning av beviljade behörigheter i Unity Catalog och attribuering i granskningsloggar. Därför ändrar antagandet av en roll beteendet för befintliga principer och vyer som har byggts kring identitet per användare.

Vanliga fallgropar: säkerhetsvyer på radnivå som bygger på current_user()

Ett vanligt mönster i ABAC och radfilter på tabellnivå är att filtrera rader genom att sammanfoga med en provisioneringstabell (även kallad en mappningstabell eller åtkomstkontrollista) med användarnamnet som returneras av current_user() som nyckel. Ett exempel:

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

När samma användare antar en roll current_user() returnerar de inte längre sitt användarnamn. Den returnerar rollens namn. Eftersom rollen inte finns i etableringstabellen returnerar filtret inga rader och användaren verkar förlora åtkomsten till data som de har beviljats.

Lägg till rollen i provisioneringstabellen

Behandla rollen som ett annat huvudnamn i dina etableringsdata: infoga en rad per roll med de resurser (eller andra attribut) som rollen ska se. Filtret matchar sedan om den aktiva identiteten är användaren eller den antagna rollen.

Mönster för kombinerad användning

Följande är exempel på hur kunder använder RBAC och ABAC tillsammans för att lösa verkliga problem med åtkomstkontroll. Det här är utgångspunkter, inte uttömmande recept.

Radfilter per projekt som är viktiga för den antagna rollen

Att filtrera rader efter projekt är ett vanligt behov inom forskning om kliniska prövningar, kontraktsmarknadsföring, klientrådgivning och andra inställningar där ett team arbetar i flera isolerade projekt. I följande exempel används kliniska prövningar, men mönstret generaliseras till all dataisolering per projekt.

En klinisk forskningsorganisation driver flera samtidiga försök, var och en i sin egen åtkomstroll. Tagga varje tabell med projektidentifieraren. Användarna ser bara raderna för projektet vars roll de för närvarande har antagit.

Inställning:

• Tabeller under clinical_trials.* har en project_id kolumn med taggnyckeln governed tagproject.
• Varje projekt har en motsvarande åtkomstroll med namnet role-<project> (till exempel role-alpha, role-beta).
• Användarna har endast behörighet att överta roller i de projekt de arbetar med.

UDF för radfilter:

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

Policy:

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

Den här UDF:n kopplar den aktiva identiteten till värdet för taggen project i varje rad, så satser som riktar sig till identiteter, som TO / EXCEPT, kan inte uttrycka detta — de riktar sig mot identiteter, inte mot radinnehåll. Som vägledningen om målstyrning för säkerhetsobjekt förklarar bör du föredra TO / EXCEPT för enkel avgränsning av säkerhetsobjekt och endast använda identitetsfunktioner i en UDF för fall som detta, där en enda regel beror på både den aktuella identiteten och radens innehåll.

En enskild princip omfattar varje projekt: USING COLUMNS (project) skickar varje rads project taggvärde till UDF, så du behöver ingen separat princip per projekt. Den allmänna formen av den här tekniken – körning av radåtkomst från en uppslagstabell i stället för matchning av rollnamn – finns i Använda mappningstabeller för dynamisk åtkomstkontroll.

Beteende:

• En användare som agerar som sin användaridentitet ser inga rader i någon av clinical_trials tabellerna. current_user() returnerar sitt användarnamn, vilket aldrig matchar namngivningsmönstret role-* . Detta är den avsedda standardnekanden.
• En användare som antar rollen role-alpha ser endast de rader där project_id är lika med alpha. Om du byter till role-beta växlar du synliga data utan att fråga om något annat.

PII-maskering lättad för användare som agerar i en utsedd roll

Som standard visas PII-kolumner (SSN, e-post, telefon) maskerade för alla. Om du vill se råvärdena måste en användare uttryckligen anta en angiven PII-rensad roll. Granskningsloggar registrerar händelsen när en roll antas, så "Jag behövde titta på faktiska personuppgifter" blir ett granskningsbart aktivt val i stället för en ständigt närvarande behörighet.

Inställning:

• Känsliga kolumner taggas med den reglerade taggnyckelnpii (tillåtna värden som ssn, email, phone).
• En åtkomstroll med namnet role-pii-cleared tilldelas behörigheten Assume för de användare som har godkänts för att visa rå PII.

Kolumnmaskering UDF (statisk – policyn anger vilka identiteter som ska maskeras):

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

Policy:

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;

EXCEPT klausulen undantar role-pii-cleared helt från policyn, så UDF:en anropas aldrig när den rollen är den aktiva identiteten. Se Föredra TO/EXCEPT för principalinriktning för allmän vägledning om principalinriktning via TO / EXCEPT.

Beteende:

• En användare som fungerar som sin användaridentitet ser *** i varje PII-kolumn. Det här är standardläget för alla, inklusive användare som har Assume-behörighet för role-pii-cleared.
• När du har antagit role-pii-clearedgäller principen inte längre för sessionen och samma användare ser rådatavärdena.
• Granskningsloggposter för sessionsposten identity_metadata.run_as = role-pii-clearedså att granskarna kan se exakt när PII avmaskerades och av vem.

Policyer för känslighetsnivåer som varierar beroende på den antagna rollen

Data klassificeras i känslighetsnivåer (internal, confidential, restricted). Varje nivå har en motsvarande åtkomstroll, vilket restricted innebär åtkomst till confidential och internal också. En UDF för filtrering av enskilda rader styr raders synlighet genom att jämföra varje rads nivå med den roll som användaren antas ha.

Inställning:

• Tabeller har en sensitivity_level kolumn taggad med den reglerade taggnyckelnsensitivity (tillåtna värden: internal, confidential, restricted).
• Tre åtkomstroller: role-sens-internal, role-sens-confidential, role-sens-restricted.

UDF för radfilter:

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;

Policy:

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

Eftersom en roll inte är medlem i sig själv jämför denna UDF current_user() med varje rollnamn i stället för att testa om den är medlem med is_account_group_member(). Se kommentaren ovan för varför medlemskapstester inte matchar den antagna rollen. Se Prestandaöverväganden för principer för radfilter och kolumnmask för prestandaegenskaper för identitetsfunktioner i UDF:er.

Beteende:

• En användare som agerar som sin användaridentitet ser inga rader. Grenen ELSE FALSE motsvarar allt som inte är någon av de tre rollerna. Precis som i exemplet per projekt ovan är detta den avsedda standardnekanden.
• Om vi antar att role-sens-internal endast visar internal rader.
• Förutsatt att role-sens-confidential visar internal och confidential rader.
• Förutsatt att role-sens-restricted visar alla rader.

Användarna antar den högsta nivån de behöver för sessionen. filtret utesluter automatiskt allt ovanför den nivån utan att användaren behöver veta vilka tabeller som innehåller vilka klassificeringar.

Tillskrivning för granskning

Både utvärderingar av ABAC-principer och underliggande frågor respekterar RBAC-attributionen run_as / run_by . Granskningsloggposter anger identity_metadata.run_by som den användare som autentiseras och identity_metadata.run_as som den antagna rollen, oavsett vilka ABAC-principer som tillämpades vid utvärderingen. Se Systemtabellreferens för granskningsloggar för det fullständiga granskningsloggschemat.

Nästa steg

• Modellexklusiv åtkomst: Använd mönster för att konfigurera exklusiv åtkomst med antingen en kontolokal grupp eller en grupp som synkroniserats från Microsoft Entra ID. Se exklusiv åtkomst till modellen.
• Växla roller: Anta en roll med hjälp av rollväxlaren, dedikerade åtkomstlägeskluster, CLI, API:et eller BI-verktyg från tredje part. Se Växla roller.
• Hantera behörigheter för att anta roller: Bevilja eller återkalla behörigheten för en grupp att anta den motsvarande rollen så att användarna kan anta den. Se Hantera behörigheter för en grupp.
• Gå igenom ABAC:s grundläggande begrepp: Lär dig hur styrda taggar, policyer och policyutvärdering fungerar. Se Attributbaserad åtkomstkontroll i Unity Catalog.