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 .

Preferisce TO/EXCEPT per la destinazione principale

Quando possibile, usare le clausole TO e EXCEPT dei criteri per definire a quali utenti e gruppi si applicano i criteri. 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 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

Argomento Description
Considerazioni sulle prestazioni In che modo la progettazione dei criteri ABAC influisce sulle prestazioni delle query e come ottimizzare e testare i criteri.
Quando usare ABAC contro filtri di riga a livello di tabella e maschere di colonna Differenze nell'ambito, nella proprietà e nella modalità di scelta tra i due approcci.
Delta Sharing e controllo degli accessi basato sugli attributi Come condividere tabelle protette con controllo degli accessi basato sugli attributi tramite Delta Sharing, gestire i criteri lato destinatario e configurare le visualizzazioni locali dei destinatari.