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

Il controllo degli accessi in base all'attributo è un modello di controllo di accesso che usa tag e criteri regolati per concedere autorizzazioni in base agli attributi degli oggetti anziché alle concessioni per oggetto. Questa pagina definisce i blocchi predefiniti: tag regolati, i tre tipi di criteri ABAC (filtro di riga, maschera di colonna e GRANT criteri), le autorizzazioni necessarie per configurarle e la separazione dei compiti ABAC consente a tutti i 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 in base all'attributo è un modello di controllo di accesso dinamico in cui le decisioni di accesso sono basate sui criteri valutati rispetto agli attributi associati agli oggetti a protezione diretta. 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.

ABAC supporta inoltre l'assegnazione dinamica dei privilegi tramite GRANT criteri (Beta), sui tipi di oggetti proteggibili supportati. Vedi le politiche ABAC GRANT (Beta).

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 a oggetti a protezione diretta del catalogo Unity, ad esempio cataloghi, schemi, tabelle, colonne, modelli e volumi, oltre agli oggetti dell'area di lavoro. Rappresentano caratteristiche quali riservatezza, classificazione o dominio aziendale.

Per impostazione predefinita, gli oggetti proteggibili ereditano i tag dal catalogo o dallo schema padre. È possibile eseguire l'override dei tag ereditati a ogni livello, ad eccezione del livello di colonna: i tag di colonna non ereditano dalla tabella padre e 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 proteggibile a cui è associato il criterio, specificato dalla clausola ON. Associare una policy a un oggetto proteggibile significa che le condizioni della policy vengono valutate per tutti gli oggetti del tipo specificato nella clausola FOR, per quell'oggetto e per tutti i relativi discendenti.
  • Per i criteri di filtro di riga e maschera di colonna, gli ambiti dei criteri supportati sono CATALOG, SCHEMAo TABLE. Per GRANT i criteri (Beta), gli ambiti dei criteri supportati sono CATALOG e SCHEMA.
  • Le tabelle, incluse le tabelle streaming e le viste materializzate, sono l'unico tipo di sicurezza supportato per le policy di filtro riga e maschera di colonna, specificate tramite la clausola FOR TABLES . GRANT I criteri (Beta) si applicano ai modelli, ai servizi di modello, ai servizi dei provider di modelli, ai servizi MCP e ai servizi agente e utilizzano la clausola GRANT <privilege> FOR <securable_type>. Per l'elenco completo dei tipi e privilegi di securable supportati, vedi Tipi e privilegi di securable supportati.
  • 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: specifica se la policy applica un filtro di riga, una maschera di colonna o un'assegnazione di privilegi. Le policy di filtro delle righe e di mascheramento delle colonne usano una funzione definita dall'utente (UDF) per implementare la logica di filtraggio o mascheramento. GRANT criteri (Beta) non usano UDF. 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

ABAC supporta tre tipi di criteri: criteri di filtro delle righe, criteri di mascheramento delle colonne e criteri GRANT (Beta). I criteri di filtro di riga e di mascheramento delle colonne richiedono UDFs per applicare la logica di filtro o di mascheramento. GRANT le policy non utilizzano UDF e concedono invece privilegi quando la loro condizione basata su tag corrisponde agli attributi dell'oggetto di destinazione.

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. Supporta anche funzioni di introspezione dei tag, che estraggono il valore di un tag al momento della query e lo passano alla UDF. 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 .

GRANT criteri (Beta)

GRANT Le policy conferiscono dinamicamente un privilegio di Unity Catalog quando la relativa condizione basata su tag corrisponde ai tag di un oggetto proteggibile. Ogni volta che un utente tenta di accedere a un oggetto a protezione diretta, Unity Catalog identifica tutti i GRANT criteri il cui ambito copre l'oggetto, controlla se l'utente si trova nell'elenco TO e non nell'elenco EXCEPT e valuta la condizione del WHEN criterio rispetto ai tag nell'entità a protezione diretta, inclusi i tag ereditati. Se il criterio si applica, Unity Catalog concede il privilegio. GRANT criteri utilizzano lo stesso modello di valutazione dei criteri di filtro delle righe e di mascheramento delle colonne, tranne per il fatto che non utilizzano UDF. La condizione è espressa in linea nella definizione del criterio.

I privilegi effettivi su un oggetto sono l'unione delle autorizzazioni concesse direttamente e di eventuali GRANT criteri applicabili. Un soggetto dispone del privilegio se a quel soggetto si applica un criterio GRANT applicabile oppure se si applica un GRANT diretto dello stesso privilegio. GRANT i criteri aggiungono solo l'accesso. Non possono revocare l'accesso concesso direttamente.

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:

Per eseguire la corrispondenza in base agli attributi dell'utente che esegue la query, anziché ai tag delle risorse, vedere Funzioni degli attributi di identità.

Per corrispondere al contesto di una richiesta, come l'applicazione chiamante, vedi Funzioni di attributo contestuale.

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 degli attributi di identità (Beta)

Le funzioni di attributo identità valutano le proprietà dell'utente che esegue la query, come dipartimento, paese o ruolo di lavoro. Questi attributi possono essere forniti dal tuo fornitore di identità e riferiti direttamente nelle condizioni della polizza. Questo permette di esprimere condizioni più flessibili senza creare gruppi separati per ogni combinazione di proprietà identità. Quando le informazioni di identità cambiano nel tuo fornitore di identità, le policy utilizzano i valori degli attributi aggiornati, così come utilizzano l'appartenenza aggiornata al gruppo.

Queste funzioni sono supportate nella clausola WHEN dei criteri di mascheramento delle colonne.

Tieni a mente il seguente comportamento quando scrivi policy che li utilizzano:

• Un attributo mancante si risolve in false. Se l'utente non ha valore per l'attributo, non ha alcun attributo, o l'attributo non esiste, la funzione restituisce false invece di generare un errore. Condizioni di frase in modo che questo false risultato limiti l'accesso. Vedi Condizioni dell'attributo identità.
• Le chiavi e i valori degli attributi distinguono tra maiuscole e minuscole e vengono confrontati in modo esatto: Finance e finance non corrispondono.
• I cambiamenti degli attributi non sono istantanei. Le modifiche al tuo provider di identità non vengono sincronizzate immediatamente con Azure Databricks. Vedi attributi di identità per maggiori informazioni.

Per gli attributi supportati da Azure Databricks e come sono stati provisionati, vedi attributi identità. Per esempi di come utilizzare gli attributi identità nelle policy, vedi Mascherare una colonna basata sugli attributi dell'utente che fa la query.

Funzioni di attributo contestuale (Beta)

Gli attributi di contesto sono utilizzati per limitare l'accesso ai dati per richieste effettuate per conto di un utente tramite un'applicazione OAuth. Questa configurazione può essere utilizzata per limitare l'accesso ai dati agli agenti quando agiscono per conto di un utente, mantenendo però quegli stessi dati accessibili se l'utente li interroga direttamente nello spazio di lavoro.

Copre qualsiasi applicazione OAuth, sia che sia un'app integrata come la CLI di Azure Databricks sia un'app OAuth personalizzata. Ci sono due attributi contestuali diversi:

• request.is_on_behalf_of: la stringa 'true' o 'false'. Indica se la richiesta viene eseguita per conto di un utente tramite un'app OAuth. Qualsiasi richiesta da un'app OAuth ha questo valore impostato su 'true'.
• request.client_id: l'ID client OAuth. Questo può essere utilizzato per mirare a un client OAuth specifico, sia un'app OAuth integrata (ad esempio, databricks-cli) sia un'app OAuth personalizzata. È possibile osservare client_id nella pagina Connessioni app nella console dell’account. Per le app Databricks, può essere osservato anche nella pagina dettagli di autorizzazione dell'app, sotto OAuth2 App Client ID. Oppure, si può effettuare una query dal campo identity_metadata.acting_resource nei log di audit.

Questi attributi non sono modificabili dall'utente e sono esplicitamente forniti dal sistema; Un chiamante li influenza solo in base a come si autenticano. Questi attributi possono essere usati per identificare agenti esterni, non agenti Genie.

Gli attributi di contesto possono essere utilizzati tramite le seguenti funzioni:

Le chiavi degli attributi non distinguono tra maiuscole e minuscole, e i valori invece le distinguono.

Per imparare come utilizzare questi attributi di contesto per controllare l'accesso da agenti esterni, vedi Restringere l'accesso per agenti esterni che agiscono per conto di un utente.

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 SQL e Python 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 di righe e la maschera di colonna per esempi.

Funzioni di introspezione dei tag

Le funzioni di introspezione dei tag estraggono il valore di un tag governato e lo passano a una funzione definita dall'utente (UDF) attraverso la clausola USING COLUMNS. Poiché la funzione definita dall'utente (UDF) riceve il valore del tag come argomento, un singolo criterio e una singola funzione definita dall'utente possono gestire più valori del tag, anziché richiedere un criterio separato per ciascun valore del tag. Queste funzioni sono disponibili solo per i criteri di filtro delle righe e di mascheramento delle colonne, perché i criteri GRANT non utilizzano UDF.

La creazione di un criterio che usa queste funzioni richiede Databricks Runtime 18 LTS o versione successiva. Questo requisito si applica solo alla creazione di criteri, non all'esecuzione di query sulle tabelle regolate.

In fase di query, Il catalogo Unity valuta queste funzioni rispetto ai tag nella tabella o alle colonne corrispondenti ai criteri: get_tag_value() legge dalla tabella che soddisfa la WHEN condizione e get_column_tag_value() legge dalle colonne identificate da MATCH COLUMNS. Possono essere visualizzati solo nella USING COLUMNS clausola , non in WHEN o MATCH COLUMNS condizioni.

Entrambe le funzioni accettano la chiave del tag come stringa letterale. Il tag deve essere un tag regolamentato e get_column_tag_value() deve fare riferimento a un alias presente nella clausola del MATCH COLUMNS criterio. Se il tag non è regolato o l'alias non è valido, la creazione dei criteri non riesce. Se un tag a cui si fa riferimento non è più regolato quando viene eseguita una query, le query sulle tabelle di destinazione dei criteri hanno esito negativo in fase di esecuzione.

Esempio: un criterio per tutti i tipi di informazioni personali

Senza l'introspezione dei tag, mascherare ciascun tipo di informazione personale identificabile (e-mail, SSN, numero di telefono) richiede un criterio separato e una UDF per ogni valore del tag. Con get_column_tag_value(), un singolo criterio passa il valore del tag pii della colonna corrispondente a una UDF. La UDF si dirama in base a quel valore:

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

Per ogni colonna mascherata, get_column_tag_value(col, 'pii') si risolve nel valore del tag della pii colonna (email, , ssnphonee così via) e mask_pii applica la trasformazione corrispondente. Un nuovo valore di tag richiede solo un nuovo ramo nell'UDF, non un nuovo criterio.

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 accedono agli oggetti regolati.

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 oggetti a protezione diretta di Unity Catalog, ad esempio cataloghi, schemi, tabelle, colonne, modelli e volumi. Ad esempio, contrassegnare le colonne che contengono informazioni personali con pii : ssno contrassegnare un modello con lifecycle : production. 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. Il criterio specifica a chi si applica, quali condizioni valuta e quale azione applicare, ad esempio un filtro di riga, una maschera di colonna o una concessione di privilegi.

   • Autorizzazioni necessarie: autorizzazione MANAGE oppure proprietà dell'oggetto a protezione diretta a cui è associato il criterio. Per i criteri di filtro delle righe e di mascheramento delle colonne, è richiesto anche il privilegio EXECUTE sulla UDF.

4. Creare oggetti dati. Gli autori di dati creano oggetti a protezione diretta, ad esempio tabelle, modelli o volumi all'interno degli ambiti a cui sono stati concessi l'accesso. I nuovi oggetti ereditano tag da cataloghi e schemi padre. 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. Accedere a oggetti regolati. Quando un utente tenta di accedere a un oggetto a protezione diretta all'interno dell'ambito di un criterio, Unity Catalog valuta automaticamente i criteri applicabili. Per i criteri di filtro di riga e maschera di colonna, l'utente visualizza i dati filtrati o mascherati se la tabella o le colonne corrispondono alle condizioni dei criteri e l'utente non è esente. Per i criteri GRANT (Beta), l'utente ottiene il privilegio concesso se le condizioni sono soddisfatte e l'utente si trova in TO e non in EXCEPT.

   • Autorizzazioni necessarie: per i criteri di filtro delle righe e di mascheramento delle colonne, gli utenti devono disporre di autorizzazioni sulla tabella, ad esempio SELECT, tramite una concessione diretta sull'oggetto. Questi criteri filtrano i record o mascherano le colonne per le tabelle a cui l'utente può già accedere. Non concedono le autorizzazioni autonomamente. GRANT i criteri (Beta) concedono direttamente il privilegio e si combinano con eventuali concessioni dirette sullo stesso securable.

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.

Risorse aggiuntive

• 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 per i criteri di filtro di riga e maschera di colonna