Procedure consigliate per i criteri di controllo degli accessi in base al ruolo

Prendere in considerazione le procedure consigliate seguenti per la progettazione dei criteri ABAC e la governance dei tag.

Standardizzare attributi e denominazione

Stabilire una tassonomia di assegnazione di tag coerente prima di creare criteri. Accettare i nomi delle chiavi dei tag, i valori consentiti e le convenzioni di denominazione tra i team. Un piccolo set di tag ben definito è più facile da gestire rispetto a una proliferazione di tag ad hoc.

Ad esempio, usare un singolo sensitivity tag con valori controllati (public, internal, confidential, restricted) anziché più tag sovrapposti come is_sensitive, data_classe pii_level.

Controllare chi può impostare i tag

L'assegnazione di tag è un limite di sicurezza nel controllo degli accessi basato sugli attributi. Se un utente può modificare i tag in un asset di dati, può modificare i criteri applicati. I tag errati o mancanti possono lasciare i dati non protetti o inaccessibili perché i criteri si applicano solo quando sono presenti tag corretti.

• Limitare la creazione e la modifica dei tag agli amministratori di governance o agli amministratori autorizzati dei dati. Per informazioni su come configurare le autorizzazioni per i tag, vedere Tag regolamentati .
• Verifica regolarmente le modifiche ai tag utilizzando la tabella di sistema del registro di verifica.

Impostare regole di fallback per i dati non classificati

Non presupporre che tutti gli oggetti siano contrassegnati correttamente. Usare l'automazione per applicare gli standard di assegnazione di tag e implementare meccanismi di fallback per i dati non classificati:

• Applicare un tag restrittivo predefinito (ad esempio classification : unverified) ai nuovi oggetti fino a quando un amministratore dei dati non li esamina.
• Creare un criterio che limita l'accesso agli oggetti con il tag predefinito.

Per un esempio dettagliato, vedere Impedire l'accesso fino a quando non vengono contrassegnate le colonne sensibili.

Definire i criteri nell'ambito più alto applicabile

Allegare criteri a livello di catalogo o schema, quando possibile. I criteri a livello di tabella sono rari e devono essere l'eccezione.

I criteri con ambito catalogo valutano in base a tutte le tabelle nel catalogo e i criteri con ambito schema valutano in base a tutte le tabelle nello schema. Quando si aggiungono nuove tabelle, i criteri esistenti vengono applicati purché i tag corrispondano alle condizioni dei criteri.

Evitare lo sprawl delle politiche

Il controllo degli accessi basato sugli attributi è progettato per ridurre il numero di regole di controllo di accesso, non aumentarle. Se i team creano troppi tag e criteri, il risultato è difficile da gestire e controllare.

• Analizzare i requisiti di governance prima di creare criteri.
• Iniziare con un numero ridotto di criteri generali, ad esempio mascheramento delle informazioni personali in un catalogo o in un filtro di righe a livello di area.
• Evitare di creare politiche separate per ogni caso eccezionale.
• Esaminare periodicamente i criteri e consolidare quelli sovrapposti.

Un numero elevato di criteri e condizioni complesse può rallentare i controlli di autorizzazione. Per informazioni dettagliate, vedere Considerazioni sulle prestazioni .

Verificare insieme le assegnazioni dirette e i criteri ABAC GRANT

Preferisce TO/EXCEPT per la destinazione principale

Per i criteri dei filtri di riga e delle maschere di colonna, utilizzare le clausole TO e EXCEPT del criterio per definire a quali utenti e gruppi si applica il criterio. In questo modo la logica definita dall'utente è semplice. La EXCEPT clausola esclude completamente utenti specifici dai criteri in modo che non siano soggetti ad alcun filtro o mascheramento. Quando è necessaria una logica condizionale complessa, le funzioni di identità come is_account_group_member() all'interno delle funzioni definite dall'utente rimangono un'opzione valida.

Per i criteri GRANT, TO e EXCEPT sono gli unici meccanismi per indirizzare i principal perché i criteri GRANT non utilizzano UDF.

Puoi anche indirizzare gli utenti tramite un attributo identità come department. Quando l'attributo esiste già nel tuo fornitore di identità, una politica maschera a colonna copre ogni valore dell'attributo, così eviti di creare un gruppo e una policy separati per ciascuno. Assicurati che gli utenti senza valore per l'attributo non abbiano accesso di default. Vedi Mascherare una colonna basata sugli attributi dell'utente che fa la query.

Per informazioni dettagliate, vedere Approccio ai soggetti principali.

Pianificare la valutazione dinamica dei criteri

Le politiche di ABAC sono dinamiche. A differenza dei filtri di riga a livello di tabella e delle maschere di colonna, che sono direttamente visibili nella definizione della tabella, i criteri ABAC valutano in fase di query in base all'identità dell'utente e alle appartenenze ai gruppi e ai tag dell'oggetto dati nell'ambito dei criteri. Ciò può rendere più difficile per i consumer di dati e i proprietari di tabelle comprendere quali regole di accesso si applicano a una determinata tabella.

• Utilizzare SHOW EFFECTIVE POLICIES per determinare cosa si applica a una tabella specifica.
• Documentare l'approccio alla tassonomia, ai criteri e alla gestione dei gruppi per consentire ai team di comprendere il modello di governance senza esaminare singolarmente ogni criterio.
• Se la trasparenza è fondamentale per una tabella specifica, è consigliabile usare invece filtri di riga a livello di tabella e maschere di colonna per tale caso isolato. Assicurarsi di risolvere prima i possibili conflitti.

Altre informazioni