Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questa pagina illustra i requisiti, le quote e le limitazioni per i criteri di filtro di riga e maschera di colonna. Per le GRANT politiche, vedi le politiche ABACGRANT.
Questa pagina elenca i requisiti, le quote dei criteri e le limitazioni correnti per i criteri di filtro di riga EBAC e maschera di colonna in Unity Catalog.
Requisiti di calcolo
Per usare i criteri di controllo degli accessi basati sugli attributi, è necessario usare una delle seguenti configurazioni di calcolo:
- Calcolo senza server (serverless)
- Calcolo standard in Databricks Runtime 16.4 o versione successiva
- Calcolo dedicato in Databricks Runtime 16.4 o versione successiva con filtri di controllo di accesso con granularità fine abilitata
Per indicazioni sull'esecuzione di carichi di lavoro che richiedono runtime meno recenti, vedere Accesso da runtime meno recenti.
Requisito dei tag regolati
I criteri di controllo degli accessi in base al ruolo usano tag regolati, non tag non governativi. I tag regolamentati vengono definiti a livello di account con controlli di accesso che determinano chi può creare, assegnare e gestirli. Per informazioni dettagliate, vedere Tag regolamentati.
Annotazioni
Dopo l'assegnazione o la modifica di un tag, l'applicazione della modifica può richiedere alcuni minuti.
Quote dei criteri
| risorsa | Limite |
|---|---|
| Policy per metastore (tutti gli oggetti) | 10.000 |
| Policy per metastore, allegate direttamente (Beta) | 100 |
| Politiche per catalogo | 100 |
| Policy per schema | 100 |
| Criteri per tabella | 50 |
Principali per politica (applicabile a TO clausole e EXCEPT di E) |
20 |
Condizioni di colonna per clausola MATCH COLUMNS (politiche di filtro per righe) |
6 |
Condizioni di colonna per clausola MATCH COLUMNS (politiche di maschera a colonna) |
3 |
Per altri dettagli, incluse le quote di tag regolati, vedere Limiti del servizio.
Limitazioni del controllo degli accessi in base al ruolo
Attributi di identità in condizioni di policy
Le has_identity_attribute_value funzioni e has_identity_attribute_tag_match valutano gli attributi identità dell'utente che esegue la query. Sono supportate dalla WHEN clausola delle politiche sulle mascherine a colonna. Si applicano le limitazioni seguenti:
- Non sono supportate dalla
MATCH COLUMNSclausola delle politiche sulle mascherine a colonna. - Non sono supportati nelle
GRANTpolitiche di nessunoDENY. - L'interfaccia di creazione delle policy in Catalog Explorer non supporta funzioni di attributi. Usa SQL per creare queste policy.
Per i modelli di utilizzo, vedi Mascherare una colonna basata sugli attributi dell'utente che fa la query.
Accesso da runtime meno recenti
Le risorse di calcolo standard e dedicate nelle versioni di Databricks Runtime precedenti alla 16.4 non possono accedere alle tabelle protette con controllo degli accessi in base al ruolo. Se sono necessari determinati carichi di lavoro per continuare l'esecuzione in un runtime precedente, definire l'ambito dei criteri di controllo degli accessi in base al ruolo a un gruppo specifico anziché applicarlo su larga scala. Aggiungere solo gli utenti o le entità da applicare al gruppo e escludere l'entità che esegue il carico di lavoro di runtime precedente usando la EXCEPT clausola . Gli utenti esterni al gruppo mantengono l'accesso completo alle tabelle sottostanti. Ciò consente al carico di lavoro di continuare ad accedere alle tabelle durante la transizione a un runtime supportato.
Politiche ABAC sulle opinioni
Importante
L'applicazione delle politiche ABAC alle visualizzazioni è in Beta. Per utilizzarlo, un amministratore dello spazio di lavoro deve abilitare l'anteprima ABAC on Views dalla pagina delle Anteprime delle impostazioni dello spazio di lavoro, e devi utilizzare Databricks Runtime 19 o superiore. Vedere Gestire le anteprime a livello di area di lavoro.
I seguenti requisiti e limitazioni si applicano alle politiche sulle visualizzazioni:
- Le visualizzazioni metriche non sono supportate: non puoi applicare politiche ABAC alle viste metriche.
- Una singola query può stratificare al massimo 20 policy: una tabella base può avere una policy, e ogni vista costruita sopra di essa può avere la propria policy. Quando una query legge una vista, si applicano tutte le policy applicabili, a ogni livello della gerarchia. Se si applicano più di 20 politiche, la query fallisce.
-
CREATE OR REPLACE VIEWelimina i tag governati e le policy direttamente collegate: Sostituire una vista con un'istruzioneCREATE OR REPLACEcancella i metadati della vista, insieme ai tag governati e a eventuali policy direttamente collegate. Per preservare i metadati, usaALTER VIEWinvece. Se usiCREATE OR REPLACE, riapplica i tag e le politiche regolate dopo. - Le colonne con tag governati non possono essere eliminate finché i tag non vengono rimossi: Come per le tabelle base, i tag governati devono essere rimossi dalla colonna di una vista prima di essere eliminata. Altrimenti, le policy che dipendono dal tag potrebbero cadere involontariamente.
- Le policy ABAC non possono essere applicate a una vista condivisa sul lato del destinatario: quando condividi una vista tramite OpenSharing, il destinatario non può applicare le policy ABAC a quella view condivisa. Per far rispettare le policy sul lato del destinatario, condividi invece le tabelle base e fai in modo che il destinatario crei viste locali del destinatario su di esse, con le policy ABAC sulle tabelle condivise. Vedi Visualizzazioni destinatari-locali sopra le tabelle condivise.
Criteri di controllo degli accessi in base al ruolo nelle viste materializzate e nelle tabelle di streaming
Quando una pipeline aggiorna una visualizzazione materializzata o una tabella di streaming, valuta le policy utilizzando l'identità del proprietario o run-as della pipeline. Se quell'identità è soggetta a una policy ABAC, la visualizzazione materializzata o la tabella di streaming contiene permanentemente dati mascherati o filtrati. Per evitare ciò, aggiungi il proprietario della pipeline o l'identità run-as alla EXCEPT clausola delle policy ABAC associate a tutte le tabelle lette durante l'aggiornamento della pipeline. Usare la TO clausola per specificare quali utenti e gruppi ricevono dati mascherati o filtrati.
Tabelle OpenSharing con criteri o viste ABAC che vi fanno riferimento
Le tabelle con criteri o viste ABAC che fanno riferimento a tabelle con criteri ABAC possono essere condivise solo tramite OpenSharing se il proprietario della condivisione è esente dai criteri elencati nella EXCEPT clausola . I criteri non regolano l'accesso del destinatario. I destinatari possono applicare i propri criteri di controllo degli accessi in base al ruolo alle tabelle condivise per applicare il controllo di accesso sul proprio lato.
- Per i provider di condivisione, vedere Aggiungere tabelle e schemi protetti dai criteri di controllo degli accessi basati su attributi (ABAC) a una condivisione.
- Per i destinatari di condivisione, vedere Leggere i dati protetti dal controllo degli accessi in base agli attributi e applicare i criteri di controllo degli accessi in base agli attributi.
Per informazioni dettagliate su come usare OpenSharing con il controllo degli accessi in base al ruolo, vedere OpenSharing e ABAC.
Tabelle di clonazione con politiche ABAC
Cloni profondi e superficiali non sono supportati su tabelle con politiche ABAC. Per clonare una tabella, si utilizza un principale o un gruppo di servizio elencato nella EXCEPT clausola di ogni policy che si applica alla tabella.
Importante
Le entità esentate visualizzano dati non filtrati e non mascherati. Esentare solo le identità attendibili, ad esempio le entità servizio usate per i carichi di lavoro ETL o pipeline.
Ad esempio, la seguente policy maschera le colonne PII per tutti gli utenti tranne che per etl_service_principal, che può clonare la tabella:
CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;
Indici di ricerca di intelligenza artificiale e criteri di controllo degli accessi in base al ruolo
I criteri di controllo degli accessi in base al ruolo in una tabella di origine non si applicano agli indici di ricerca di intelligenza artificiale creati da tale tabella. L'indice sincronizza tutte le righe della tabella di origine e non applica criteri di filtro di riga o maschera di colonna durante la gestione delle query.
Per le tabelle con maschere di colonna, è possibile escludere colonne mascherate dall'indice usando le colonne da sincronizzare .
Più criteri nella stessa tabella o colonna per lo stesso utente
Solo un filtro di riga distinto può essere risolto in fase di esecuzione per una determinata tabella e un determinato utente e una sola maschera di colonna distinta può risolvere per una determinata colonna e un determinato utente. È possibile definire più criteri, ma quando un utente esegue una query sulla tabella, è necessario che corrispondano solo le condizioni di un criterio. Se più filtri di riga o maschere di colonna distinti si applicano allo stesso utente e tabella o colonna, Azure Databricks blocca l'accesso e restituisce un errore. Se si risolvono nello stesso filtro di riga o nella stessa funzione definita dall'utente della maschera di colonna con gli stessi argomenti, sono consentiti più criteri.
Per dettagli, vedi Filtri e maschere in conflitto.
Controllo degli accessi in base al ruolo nel calcolo dedicato
Per le limitazioni del controllo degli accessi basato sugli attributi nei calcoli dedicati, vedere Limitazioni.
Limitazioni comuni ai filtri di riga a livello di tabella e alle maschere di colonna
Per limitazioni generali dei filtri di riga e delle maschere di colonna applicabili sia ai filtri di riga a livello di tabella che alle maschere di colonna, vedere Limitazioni.