Concetti di base per il controllo degli accessi in base agli attributi

Questa pagina introduce ABAC, il modo in cui utilizza tag governati, criteri e funzioni definite dall'utente per controllare quali righe gli utenti possono vedere e come vengono presentati i valori delle colonne, e i suoi benefici. Questa pagina illustra anche le autorizzazioni necessarie per configurare il controllo degli accessi basato sugli attributi (ABAC) e la separazione dei compiti che consente all'interno dei team.

Per una panoramica di tutti gli argomenti relativi al controllo degli accessi basato sugli attributi in Unity Catalog, vedere Controllo degli accessi basato sugli attributi, inclusi tutorial, gestione delle politiche, migliori pratiche e limitazioni.

Che cos'è ABAC (Controllo dell'accesso basato sugli attributi)?

Il controllo degli accessi basato sugli attributi (ABAC) è un modello di controllo di accesso dinamico in cui le decisioni di accesso sono basate su politiche valutate rispetto agli attributi associati agli oggetti protetti. In Unity Catalog questi attributi sono rappresentati tramite tag regolati. Questi tag regolati vengono usati nelle condizioni dei criteri per trovare le corrispondenze con gli oggetti dati all'interno di un determinato ambito, ad esempio un catalogo o uno schema. In questo modo, un singolo criterio può essere applicato automaticamente tra più oggetti dati che soddisfano le relative condizioni.

Ad esempio, un criterio ABAC potrebbe mascherare tutte le colonne contrassegnate PII per le tabelle all'interno degli schemi con tag HR. Man mano che vengono creati e contrassegnati nuovi oggetti dati, il criterio viene applicato automaticamente senza richiedere definizioni di criteri separate per ogni oggetto.

ABAC supporta la sicurezza a livello di riga e di colonna tramite politiche di filtro di riga e politiche di maschera di colonna su tabelle, viste materializzate e tabelle di streaming. I criteri di filtro delle righe limitano le righe che un utente può visualizzare. I criteri della maschera di colonna controllano la modalità di presentazione dei valori delle colonne agli utenti.

Per un confronto con i filtri di riga a livello di tabella e le maschere di colonna, vedere Quando utilizzare ABAC rispetto ai filtri di riga a livello di tabella e alle maschere di colonna.

Tag controllati

In Unity Catalog gli attributi vengono implementati come tag regolati. I tag regolati sono coppie chiave-valore definite a livello di account e applicate alle entità a protezione diretta del catalogo Unity, ad esempio cataloghi, schemi, tabelle e colonne, oltre agli oggetti dell'area di lavoro. Rappresentano caratteristiche quali riservatezza, classificazione o dominio aziendale.

Per impostazione predefinita, i tag ereditano da cataloghi e schemi padre a tabelle, ma non da tabelle a colonne. È possibile eseguire l'override dei tag ereditati a qualsiasi livello, ma i tag a livello di colonna devono essere applicati direttamente.

È possibile fare riferimento ai tag regolati nelle condizioni dei criteri usando funzioni predefinite come has_tag() e has_tag_value(), che controllano se un determinato tag è presente nell'oggetto dati di destinazione, direttamente o tramite ereditarietà dei tag.

I tag regolati vengono definiti a livello di account. Ciò significa che è possibile usare la stessa tassonomia dei tag nell'intero patrimonio di dati in un account, inclusi più metastore.

Per ulteriori informazioni, vedere Tag governati e Applica tag agli oggetti di sicurezza nel catalogo Unity.

Criteri

I criteri vengono associati a oggetti a protezione diretta in Unity Catalog per definire le regole di controllo di accesso in base alle condizioni dei tag. Di seguito è riportato un esempio:

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;

Ogni criterio specifica:

• Ambito: l'oggetto securable a cui è associato il criterio, specificato dalla ON clausola. L'associazione di un criterio a una risorsa protetta indica che le condizioni del criterio vengono valutate per tutti gli oggetti del tipo specificato nella clausola FOR, in quella risorsa protetta e in tutti i relativi discendenti.
  • Gli ambiti dei criteri supportati sono attualmente CATALOG, SCHEMA o TABLE.
  • Le tabelle, incluse le tabelle di streaming e le viste materializzate, sono attualmente l'unico tipo proteggibile supportato, specificato usando la clausola FOR TABLES.
  • Un criterio associato a un catalogo viene valutato in relazione a tutte le tabelle di quel catalogo. Un criterio associato a uno schema valuta in base a tutte le tabelle in tale schema. Un criterio associato a una tabella valuta solo rispetto a tale tabella.

• Destinatari: a chi si applica la politica e a chi è esente. La TO clausola specifica gli utenti, i gruppi o le entità servizio soggetti ai criteri. La clausola facoltativa EXCEPT esclude entità specifiche da questo criterio.
• Azioni: indica se il criterio applica un filtro di riga o una maschera di colonna. L'azione viene implementata da una funzione definita dall'utente che definisce la logica di filtro o maschera. Vedere Tipi di criteri.
• Condizioni: espressioni basate su tag che determinano le tabelle o le colonne a cui viene applicata la politica. Vedere Condizioni e funzioni predefinite.

I criteri vengono creati e gestiti tramite l'interfaccia utente o a livello di codice con istruzioni SQL, ad esempio CREATE POLICY, DROP POLICYSHOW POLICIES, o DESCRIBE POLICY, API REST, SDK di Databricks o Terraform. Consulta Creare e gestire i criteri di controllo degli accessi basati sugli attributi (ABAC) per la sintassi completa ed esempi.

Tipo di criteri

Il controllo degli accessi basato su attributi (ABAC) supporta due tipi di criteri: criteri di filtro delle righe e criteri di maschera di colonna. Entrambi richiedono UDF per implementare la logica di filtro o mascheramento.

Criteri di filtro delle righe

I criteri di filtro delle righe limitano le righe che un utente può visualizzare in una tabella in base ai valori nelle colonne identificate da tag che corrispondono alle funzioni Condizioni e predefinite. La politica fa riferimento a una funzione definita dall'utente che valuta ogni riga. Le righe in cui la funzione restituisce FALSE vengono escluse dai risultati della query. Gli argomenti vengono passati alla funzione definita dall'utente tramite la clausola USING COLUMNS.

Caso d'uso di esempio: Per un catalogo vendite, assicurarsi che il team EMEA veda solo i record di vendita EMEA in tutte le tabelle con una colonna con tag 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');

Politiche della maschera di colonna

I criteri della maschera di colonna controllano i valori visualizzati da un utente per colonne specifiche identificate da tag che corrispondono alle funzioni Condizioni e predefinite. La politica fa riferimento a una funzione definita dall'utente che accetta il valore della colonna come input e restituisce il valore originale o una versione mascherata. Il valore della colonna mascherata viene associato automaticamente come primo argomento della ON COLUMN clausola e gli argomenti aggiuntivi possono essere passati tramite USING COLUMNS. Il tipo restituito deve corrispondere o essere convertibile al tipo di dati della colonna.

Caso d'uso di esempio: Mascherare le colonne SSN contrassegnate con pii : ssn in modo che gli utenti visualizzino ***-**-XXXX (solo ultime quattro cifre) a meno che non si trovino in un gruppo di conformità esentato dai criteri.

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

La USING COLUMNS clausola passa argomenti alla funzione definita dall'utente. Accetta alias per le colonne che corrispondono a un'espressione basata su tag o valori costanti (stringhe tra virgolette, valori letterali numerici, valori booleani (TRUE/FALSE) o NULL), forniti nell'ordine previsto dalla funzione. Per i criteri della maschera di colonna, si tratta di argomenti aggiuntivi oltre la colonna mascherata (associata automaticamente da ON COLUMN). In questo modo, una singola funzione definita dall'utente può essere riutilizzata tra le politiche con parametri diversi.

Le funzioni definite dall'utente SQL (UDF) sono consigliate per migliorare le prestazioni. Le funzioni definite dall'utente in Python registrate nel Catalogo Unity sono supportate, anche se il query optimizer non può inlinerizzarle o ottimizzarle nel modo in cui può fare con le funzioni definite dall'utente in SQL. Per indicazioni sulla selezione del linguaggio UDF, vedere Considerazioni sulle prestazioni .

Condizioni e funzioni predefinite

Le condizioni sono espressioni basate sui tag che determinano quali tabelle e colonne sono presi di mira da un criterio all'interno del suo ambito.

• Condizioni di tabella (WHEN clausola): espressioni booleane che corrispondono alle tabelle in base ai relativi tag. Se omesso, il valore predefinito è TRUE, ovvero il criterio si applica a tutte le tabelle nell'ambito.
• Condizioni di colonna (MATCH COLUMNS clausola): una o più espressioni booleane separate da virgole che identificano le colonne a cui sono destinati i criteri. Ogni espressione può essere una singola funzione predefinita, ad esempio has_tag('pii'), o una combinazione usando operatori logici come has_tag_value('pii', 'ssn') AND has_tag('sensitive'). A ogni espressione può essere assegnato un alias (specificato dopo AS) a cui è possibile fare riferimento nelle ON COLUMN clausole e USING COLUMNS . I criteri possono includere fino a 3 espressioni di colonna e tutti devono corrispondere al criterio da applicare.

Entrambi i tipi di clausola usano le funzioni predefinite seguenti, valutate dal catalogo Unity rispetto ai metadati a protezione diretta:

I tag non vengono propagati dalle tabelle alle colonne. L'uso has_tag() in una MATCH COLUMNS clausola corrisponde solo ai tag a livello di colonna, non ai tag nella tabella padre o ai relativi predecessori.

Esempio: uso di due condizioni di colonna. Uno customers schema include tabelle con una colonna di posta elettronica contrassegnata pii : email e una colonna di consenso con tag consent_to_contact. Il criterio maschera gli indirizzi di posta elettronica a meno che il cliente non abbia acconsentito a essere contattato. Utilizza due condizioni relative alle colonne:

1. has_tag_value('pii', 'email') identifica la colonna contenente gli indirizzi di posta elettronica (la colonna da mascherare).
2. has_tag('consent_to_contact') identifica la colonna che contiene informazioni sul consenso (utilizzate dall'UDF per decidere se mascherare).

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

Questo criterio si applica solo alle tabelle che hanno sia una colonna con tag pii : email che una colonna con tag consent_to_contact. Se una tabella non dispone di colonne che corrispondono a entrambe le condizioni, il criterio non viene applicato e i dati vengono restituiti senza maschera.

Funzioni definite dall'utente

I criteri di filtro di riga e maschera di colonna usano funzioni definite dall'utente (UDF) per implementare la logica di filtro o mascheramento. Vedere Funzioni definite dall'utente (UDF) in Unity Catalog per informazioni su come creare e gestire funzioni definite dall'utente e modelli comuni per il filtro delle righe e la maschera di colonna per esempi.

Separazione dei compiti e delle autorizzazioni

La configurazione del controllo degli accessi basato sugli attributi prevede diversi passaggi, ognuno con i propri requisiti di autorizzazione. Le organizzazioni possono distribuire queste attività tra gruppi specializzati a seconda di come scelgono di separare i compiti. Ad esempio, un'organizzazione può definire una tassonomia dei tag centralmente, quindi gli amministratori dei dati classificano i dati, gli amministratori della governance scrivono criteri, gli autori di dati creano oggetti all'interno di ambiti regolamentati e i consumer di dati eseguono query sui risultati.

1. Creare la tassonomia dei tag. Definire le chiavi dei tag regolate e i relativi valori consentiti prima che chiunque li applichi o scriva i criteri. Ad esempio, creare un sensitivity tag con valori controllati (public, internal, confidential, restricted) o un pii tag con valori come ssn, emaile phone_number. Vedere Standardizzare gli attributi e la denominazione per consigli sulle convenzioni di denominazione e sulla progettazione della tassonomia.

   • Autorizzazioni necessarie: amministratore dell'account o utente con CREATE autorizzazione per i tag a livello di account.

2. Contrassegna le risorse di dati. Un amministratore dei dati, un creatore di dati o un sistema di classificazione di intelligenza artificiale applica tag regolati a cataloghi, schemi, tabelle o colonne. Ad esempio, contrassegnare le colonne che contengono informazioni personali con pii : ssn. L'assegnazione corretta dei tag è il primo passaggio essenziale per l'applicazione dei criteri di controllo degli accessi basati sugli attributi.

   • Autorizzazioni necessarie: ASSIGN sul tag e APPLY TAG sull'oggetto .

3. Creare una politica. Un amministratore della governance crea una politica in un ambito, ad esempio un catalogo o uno schema. La politica specifica a chi si applica, quali condizioni valuta e l'UDF che implementa la logica di filtraggio o mascheramento.

   • Autorizzazioni necessarie: MANAGE autorizzazione o proprietà dell'oggetto sul sicurabile in cui il criterio è associato (catalogo, schema o tabella) e EXECUTE privilegio sulla funzione definita dall'utente.

4. Creare oggetti dati. Gli autori di dati creano tabelle all'interno degli ambiti a cui sono stati concessi l'accesso. Le nuove tabelle ereditano tag da oggetti padre, ad esempio cataloghi e schemi. Gli autori di dati hanno APPLY TAG anche automaticamente sugli oggetti creati, in modo da poter applicare tag aggiuntivi. In alternativa, possono basarsi sulla classificazione automatica dei dati per gestire l'assegnazione di tag. Se un'organizzazione si basa su creatori di dati per contrassegnare i propri oggetti, deve stabilire procedure di assegnazione di tag chiare. Gli autori di dati non devono configurare controlli di accesso se i criteri sono impostati a livelli più elevati, che Azure Databricks consiglia.

   • Autorizzazioni necessarie: CREATE TABLE o altri privilegi di creazione pertinenti per l'oggetto padre.

5. Eseguire query sui dati. Quando un consumatore di dati esegue una query su una tabella all'interno dell'ambito della policy, questa viene valutata automaticamente. Se la tabella o le colonne corrispondono alle condizioni dei criteri e l'utente non è esente, il consumer visualizza i dati filtrati o mascherati.

   • Autorizzazioni necessarie: agli utenti devono essere concesse autorizzazioni per la tabella, ad esempio SELECT, tramite una concessione diretta di oggetti. I criteri di filtro di riga e maschera di colonna ABAC non concedono le autorizzazioni autonomamente. Filtrano solo i record o le colonne mascherate per le tabelle a cui un utente può già accedere.

Vantaggi del controllo degli accessi basato sugli attributi

• Criteri riutilizzabili in base agli attributi: Un singolo criterio può essere applicato a più oggetti dati che corrispondono alle stesse condizioni basate su attributi, anziché essere associati a un oggetto specifico.

• Applicazione automatica a nuovi oggetti: Quando vengono creati nuovi oggetti dati nell'ambito e contrassegnati con gli attributi pertinenti, i criteri ABAC già esistenti si applicano senza configurazione aggiuntiva. I criteri fungono da concessioni future, il che significa che i controlli di accesso vengono applicati automaticamente quando vengono creati nuovi dati e contrassegnati in modo appropriato.

• Applicazione coerente all'interno di un ambito: I criteri associati a livello di catalogo o schema vengono valutati in modo dinamico rispetto agli oggetti dati corrispondenti in tale ambito, che rimuove le differenze nel modo in cui i dati simili vengono filtrati o mascherati.

• Manutenzione in corso inferiore: Le modifiche possono essere apportate aggiornando la logica dei criteri o i tag regolati, invece di rivedere ogni singolo oggetto come richiesto con i filtri di riga a livello di tabella e le maschere di colonna.

• Governance centralizzata: Poiché i criteri possono essere definiti una sola volta e applicati in molti oggetti dati corrispondenti, i team di governance possono gestire i controlli in parti più grandi del patrimonio di dati con un minor numero di definizioni di criteri.

Altre informazioni

• Tag regolamentati
• CREATE POLICY
• Gestire i privilegi nel catalogo unity
• Filtri di riga e maschere di colonna
• Informazioni di riferimento sulla tabella di sistema del log di controllo
• Requisiti, quote e limitazioni del controllo degli accessi basato sugli attributi