Introduzione al mascheramento dei dati

Nota: questa funzionalità potrebbe non essere disponibile quando si utilizzano prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni sulle funzionalità attivate in ogni versione, consulta Introduzione alle versioni di BigQuery.

BigQuery supporta la mascheratura dei dati a livello di colonna. Puoi utilizzare il mascheramento dei dati per oscurare in modo selettivo i dati delle colonne per i gruppi di utenti, continuando a consentire loro di accedere alla colonna. La funzionalità di mascheramento dei dati si basa sul controllo dell'accesso a livello di colonna, pertanto ti consigliamo di acquisire familiarità con questa funzionalità prima di procedere.

Quando utilizzi il mascheramento dei dati in combinazione con controllo dell'accesso a livello di colonna, puoi configurare un intervallo di accesso ai dati delle colonne, dall'accesso completo all'assenza di accesso, in base alle esigenze di diversi gruppi di utenti. Ad esempio, per i dati dell'ID fiscale, potresti concedere al gruppo di contabilità l'accesso completo, al gruppo di analisti l'accesso mascherato e al gruppo di vendita nessun accesso.

Vantaggi

La mascheratura dei dati offre i seguenti vantaggi:

• Semplifica il processo di condivisione dei dati. Puoi mascherare le colonne sensibili per consentire la condivisione delle tabelle con gruppi più grandi.
• A differenza del controllo dell'accesso a livello di colonna, non è necessario modificare le query esistenti escludendo le colonne a cui l'utente non può accedere. Quando configurerai la mascheratura dei dati, le query esistenti maschereranno automaticamente i dati delle colonne in base ai ruoli concessi all'utente.
• Puoi applicare i criteri di accesso ai dati su larga scala. Puoi scrivere una policy di dati, associarla a un tag di criteri e applicare il tag di criteri a un qualsiasi numero di colonne.
• Consente il controllo dell'accesso basato su attributi. Un tag di criteri collegato a una colonna fornisce l'accesso ai dati contestuali, che viene determinato dal criterio relativo ai dati e dagli entità associati a quel tag di criteri.

Flusso di lavoro di mascheramento dei dati

La figura 1 mostra il flusso di lavoro per la configurazione della mascheratura dei dati:

Figura 1. Componenti di mascheramento dei dati.

Per configurare il mascheramento dei dati, svolgi i seguenti passaggi:

1. Configura una tassonomia e uno o più tag di criteri.

2. Configura i criteri dei dati per i tag dei criteri. Un criterio relativo ai dati mappa una regola di mascheramento dei dati e uno o più principali, che rappresentano gli utenti o i gruppi, al tag di criteri.

   Quando crei un criterio relativo ai dati utilizzando la console Google Cloud, crei la regola di mascheramento dei dati e specifichi i principali in un solo passaggio. Quando crei una norma sui dati utilizzando l'API BigQuery Data Policy, crei la norma sui dati e la regola di mascheramento dei dati in un unico passaggio e specifichi i principali per la norma sui dati in un secondo passaggio.

3. Assegna i tag di criteri alle colonne delle tabelle BigQuery per applicare i criteri dei dati.

4. Assegna agli utenti che devono avere accesso ai dati mascherati il ruolo Lettore mascherato BigQuery. Come best practice, assegna il ruolo Lettore mascherato BigQuery a livello di criteri dei dati. L'assegnazione del ruolo a livello di progetto o superiore concede agli utenti le autorizzazioni per tutti i criteri relativi ai dati del progetto, il che può causare problemi dovuti a autorizzazioni eccessive.

   Il tag di criteri associato a un criterio relativo ai dati può essere utilizzato anche per controllo dell'accesso a livello di colonna. In questo caso, il tag di criteri è associato anche a uno o più entità a cui è stato assegnato il ruolo Lettore granulare Data Catalog. In questo modo, questi agenti possono accedere ai dati originali delle colonne non mascherate.

La Figura 2 mostra come controllo dell'accesso a livello di colonna e il mascheramento dei dati agiscono insieme:

Figura 2. Componenti di mascheramento dei dati.

Per ulteriori informazioni sull'interazione dei ruoli, consulta Come interagiscono i ruoli Lettore mascherato e Lettore granulare. Per ulteriori informazioni sull'ereditarietà dei tag di criteri, consulta Ruoli e tag di criteri dei criteri.

Regole di mascheramento dei dati

Quando utilizzi la mascheratura dei dati, una regola di mascheramento dei dati viene applicata a una colonna al momento dell'esecuzione della query, in base al ruolo dell'utente che esegue la query. La maschera ha la precedenza su qualsiasi altra operazione coinvolta nella query. La regola di mascheramento dei dati determina il tipo di mascheramento dei dati applicato ai dati della colonna.

Puoi utilizzare le seguenti regole di mascheramento dei dati:

• Routine di mascheramento personalizzata. Restituisce il valore della colonna dopo aver applicato una funzione definita dall'utente (UDF) alla colonna. Per gestire la regola di mascheramento sono necessarie le autorizzazioni di routine. Per impostazione predefinita, questa regola supporta tutti i tipi di dati BigQuery tranne il tipo di dati STRUCT. Tuttavia, il supporto per i tipi di dati diversi da STRING e BYTES è limitato. L'output dipende dalla funzione definita.

  Per saperne di più sulla creazione di funzioni definite dall'utente per le routine di mascheramento personalizzate, consulta Creare routine di mascheramento personalizzate.

• Maschera anno data. Restituisce il valore della colonna dopo averlo troncato all'anno, impostando tutte le parti del valore diverse dall'anno all'inizio dell'anno. Puoi utilizzare questa regola solo con le colonne che utilizzano i tipi di dati DATE, DATETIME e TIMESTAMP. Ad esempio:

  Tipo	Originale	Mascherato
  DATE	2030-07-17	2030-01-01
  DATETIME	2030-07-17T01:45:06	2030-01-01T00:00:00
  TIMESTAMP	2030-07-17 01:45:06	01-01-2030 00:00:00

  Nota: il troncamento avviene in base al fuso orario UTC. Per modificare questa impostazione, aggiusta il fuso orario predefinito utilizzando la variabile di sistema @@time_zone.

• Valore di mascheramento predefinito. Restituisce un valore di mascheramento predefinito per la colonna in base al tipo di dati della colonna. Utilizzalo quando vuoi nascondere il valore della colonna, ma mostrare il tipo di dati. Quando questa regola di mascheramento dei dati viene applicata a una colonna, la rende meno utile nelle operazioni di query JOIN per gli utenti con accesso Lettore mascherato. Questo perché un valore predefinito non è sufficientemente univoco per essere utile quando si uniscono le tabelle.

  La seguente tabella mostra il valore di mascheramento predefinito per ogni tipo di dati:

  Tipo di dati	Valore di mascheramento predefinito
  STRING	""
  BYTES	b''
  INTEGER	0
  FLOAT	0.0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	1970-01-01 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	POINT(0 0)
  BIGNUMERIC	0
  ARRAY	[]
  STRUCT	NOT_APPLICABLE I tag di criteri non possono essere applicati alle colonne che utilizzano il tipo di dati STRUCT, ma possono essere associati ai campi foglia di queste colonne.
  JSON	null

• Maschera email. Restituisce il valore della colonna dopo aver sostituito il nome utente di un'email valida con XXXXX. Se il valore della colonna non è un indirizzo email valido, viene restituito il valore della colonna dopo che è stato eseguito tramite la funzione di hashing SHA-256. Puoi utilizzare questa regola solo con le colonne che utilizzano il tipo di dato STRING. Ad esempio:

  Originale	Mascherato
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• Primi quattro caratteri. Restituisce i primi 4 caratteri del valore della colonna, sostituendo il resto della stringa con XXXXX. Se il valore della colonna è uguale o inferiore a 4 caratteri, restituisce il valore della colonna dopo che è stato eseguito tramite la funzione di hashing SHA-256. Puoi utilizzare questa regola solo con le colonne che utilizzano il tipo di dato STRING.

• Hash (SHA-256). Restituisce il valore della colonna dopo che è stato eseguito tramite la funzione di hashing SHA-256. Utilizza questa opzione quando vuoi che l'utente finale possa utilizzare questa colonna in un'operazione JOIN per una query. Puoi utilizzare questa regola solo con le colonne che utilizzano i tipi di dati STRING o BYTES.

  La funzione SHA-256 utilizzata nella mascheratura dei dati mantiene il tipo, pertanto il valore hash che restituisce ha lo stesso tipo di dati del valore della colonna. Ad esempio, il valore hash per un valore della colonna STRING ha anche un tipo di dato STRING.

  Importante: SHA-256 è una funzione di hashing deterministica; un valore iniziale si risolve sempre nello stesso valore hash. Tuttavia, non richiede chiavi di crittografia. In questo modo, un malintenzionato può utilizzare un attacco di forza bruta per determinare il valore originale, sottoponendo tutti i valori originali possibili all'algoritmo SHA-256 e verificando quale produce un hash corrispondente all'hash restituito dalla mascheratura dei dati.

• Ultimi quattro caratteri. Restituisce gli ultimi 4 caratteri del valore della colonna, sostituendo il resto della stringa con XXXXX. Se il valore della colonna è uguale o inferiore a 4 caratteri, restituisce il valore della colonna dopo che è stato eseguito tramite la funzione di hashing SHA-256. Puoi utilizzare questa regola solo con le colonne che utilizzano il tipo di dato STRING.

• Annulla. Restituisce NULL anziché il valore della colonna. Utilizzalo quando vuoi nascondere sia il valore sia il tipo di dati della colonna. Quando questa regola di mascheramento dei dati viene applicata a una colonna, la rende meno utile nelle operazioni di query JOIN per gli utenti con accesso Lettore mascherato. Questo perché un valore NULL non è sufficientemente univoco per essere utile durante l'unione di tabelle.

Gerarchia delle regole di mascheramento dei dati

Puoi configurare fino a nove criteri dei dati per un tag di criteri, ciascuno con una distinta regola di mascheramento dei dati associata. Uno di questi criteri è riservato alle impostazioni di controllo dell'accesso a livello di colonna. In questo modo è possibile applicare più criteri dei dati a una colonna nella query di un utente in base ai gruppi di cui fa parte. In questo caso, BigQuery sceglie quale regola di mascheramento dei dati applicare in base alla seguente gerarchia:

1. Routine di mascheramento personalizzata
2. Hash (SHA-256)
3. Maschera email
4. Ultimi quattro caratteri
5. Primi quattro caratteri
6. Maschera data anno
7. Valore di mascheramento predefinito
8. Annulla

Ad esempio, l'utente A è membro sia del gruppo dei dipendenti sia del gruppo contabile. L'utente A esegue una query che include il campo sales_total, al quale è applicato il tag di criteri confidential. Al tag di criteri confidential sono associati due criteri dei dati: uno con il ruolo dipendenti come entità e che applica la regola di mascheramento dei dati che annulla e uno con il ruolo contabile come entità e che applica la regola di mascheramento dei dati con hash (SHA-256). In questo caso, la regola di mascheramento dei dati con hash (SHA-256) ha la priorità sulla regola di annullamento del mascheramento dei dati, pertanto la regola di hash (SHA-256) viene applicata al valore del campo sales_total nella query dell'utente A.

La Figura 3 mostra questo scenario:

Figura 3. Priorità delle regole di mascheramento dei dati.

Ruoli e autorizzazioni

Ruoli per la gestione di tassonomie e tag di criteri

Per creare e gestire le tassonomie e i tag di criteri, devi disporre del ruolo Amministratore dei tag di criteri del catalogo di dati.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore tag criterio Data Catalog/datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	Si applica a livello di progetto. Questo ruolo consente di: Crea, leggi, aggiorna ed elimina tassonomie e tag di criteri. Recupera e imposta i criteri IAM sui tag di criterio.

Ruoli per la creazione e la gestione dei criteri dei dati

Per creare e gestire le norme relative ai dati, devi disporre di uno dei seguenti ruoli BigQuery:

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore BigQuery Data Policy/bigquerydatapolicy.admin Amministratore BigQuery/bigquery.admin Proprietario dei dati BigQuery/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	Le autorizzazioni bigquery.dataPolicies.create e bigquery.dataPolicies.list si applicano a livello di progetto. Le altre autorizzazioni si applicano a livello di criteri dei dati. Questo ruolo consente di: Crea, leggi, aggiorna ed elimina i criteri dei dati. Recupera e imposta i criteri IAM sui criteri dei dati.

Inoltre, devi disporre dell'autorizzazione datacatalog.taxonomies.get, che puoi ottenere da diversi ruoli predefiniti di Data Catalog.

Ruoli per l'associazione di tag di criteri alle colonne

Per associare i tag di criteri alle colonne, sono necessarie le autorizzazioni datacatalog.taxonomies.get e bigquery.tables.setCategory. datacatalog.taxonomies.get è incluso nei ruoli Amministratore e Visualizzatore dei tag delle norme di Data Catalog. bigquery.tables.setCategory è incluso nei ruoli BigQuery Admin (roles/bigquery.admin) e BigQuery Data Owner (roles/bigquery.dataOwner).

Ruoli per l'esecuzione di query sui dati mascherati

Per eseguire query sui dati di una colonna a cui è stato applicato il mascheramento dei dati, devi disporre del ruolo Lettore mascherato BigQuery.

Ruolo/ID	Autorizzazioni	Descrizione
Masked Reader/bigquerydatapolicy.maskedReader	bigquery.dataPolicies.maskedGet	Si applica a livello di norme relative ai dati. Questo ruolo concede la possibilità di visualizzare i dati mascherati di una colonna associata a un criterio di dati. Inoltre, un utente deve disporre delle autorizzazioni appropriate per eseguire query sulla tabella. Per ulteriori informazioni, consulta Autorizzazioni richieste.

Interazione tra i ruoli Lettore con mascheramento e Lettore granulare

Il mascheramento dei dati si basa sul controllo dell'accesso a livello di colonna. Per una determinata colonna, è possibile avere alcuni utenti con il ruolo Lettore mascherato BigQuery che consente loro di leggere i dati mascherati, altri utenti con il ruolo Lettore granulare del catalogo di dati che consente loro di leggere i dati non mascherati, altri utenti con entrambi i ruoli e altri utenti con nessuno dei due. Questi ruoli interagiscono nel seguente modo:

• Utente con i ruoli Lettore granulare e Lettore mascherato: ciò che vede l'utente dipende da dove nella gerarchia dei tag di criteri viene concesso ciascun ruolo. Per ulteriori informazioni, consulta Eredità dell'autorizzazione in una tag di criteri criteri.
• Utente con ruolo Lettore granulare: può vedere i dati delle colonne non mascherati (non oscurati).
• Utente con il ruolo Lettore mascherato: può vedere i dati delle colonne mascherati (oscurati).
• Utente senza alcun ruolo: autorizzazione negata.

Se una tabella contiene colonne protette o protette e mascherate, per eseguire un'istruzione SELECT * FROM su quella tabella, un utente deve essere membro di gruppi appropriati in modo che gli vengano assegnati i ruoli Lettore mascherato o Lettore granulare su tutte queste colonne.

Un utente a cui non sono stati concessi questi ruoli deve invece specificare solo le colonne a cui ha accesso nell'istruzione SELECT o utilizzare SELECT * EXCEPT (restricted_columns) FROM per escludere le colonne protette o mascherate.

Ereditarietà delle autorizzazioni in una gerarchia di tag di criteri

I ruoli vengono valutati a partire dal tag di criteri associato a una colonna, poi controllati a ogni livello crescente della tassonomia, fino a quando non viene stabilito che l'utente dispone delle autorizzazioni appropriate o viene raggiunta la parte superiore della gerarchia del tag di criteri.

Ad esempio, prendi il tag di criteri e la configurazione dei criteri relativi ai dati mostrati nella Figura 4:

Figura 4. Configurazione del tag di criteri e delle norme relative ai dati.

Hai una colonna della tabella annotata con il tag di criteri Financial e un utente che fa parte sia dei gruppi [e-mail] sia di [e-mail]. Quando questo utente esegue una query che include la colonna annotata, il suo accesso viene determinato dalla gerarchia definita nella tassonomia dei tag di criteri. Poiché all'utente è stato assegnato il ruolo Lettore granulare del catalogo di dati dal tag di criteri Financial, la query restituisce i dati delle colonne non mascherati.

Se un altro utente che è solo un membro del ruolo [e-mail] esegue una query che include la colonna annotata, la query restituisce i dati della colonna sottoposti ad hashing utilizzando l'algoritmo SHA-256, perché all'utente è stato assegnato il ruolo Lettore mascherato BigQuery dal tag di criteri Confidential, che è il tag di criteri principale del tag Financial.

Un utente che non è membro di nessuno di questi ruoli riceve un errore di accesso negato se tenta di eseguire query sulla colonna annotata.

A differenza dello scenario precedente, prendi in considerazione il tag di criteri e la configurazione del criterio relativo ai dati mostrati nella Figura 5:

Figura 5. Configurazione del tag di criteri e delle norme relative ai dati.

Si verifica la stessa situazione mostrata nella Figura 4, ma all'utente viene concesso il ruolo Lettore granulare a un livello superiore della gerarchia dei tag di criteri e il ruolo Lettore mascherato a un livello inferiore della gerarchia dei tag di criteri. Per questo motivo, la query restituisce i dati delle colonne mascherati per questo utente. Questo accade anche se all'utente è stato concesso il ruolo Lettore granulare più in alto nella gerarchia dei tag, perché il servizio utilizza il primo ruolo assegnato che incontra mentre risale la gerarchia tag di criteri per verificare l'accesso utente.

Se vuoi creare un singolo criterio dei dati e applicarlo a più livelli di una gerarchia di tag di criteri, puoi impostare il criterio dei dati sul tag di criteri che rappresenta il livello di gerarchia più elevato a cui deve essere applicato. Ad esempio, consideriamo una tassonomia con la seguente struttura:

• Tag di criteri 1
  • Tag di criteri 1a
    • Tag di criteri 1ai
  • Tag di criteri 1b
    • Tag di criteri 1bi
    • Tag di criteri 1bii

Se vuoi che un criterio relativo ai dati venga applicato a tutti questi tag di criterio, impostalo sul tag di criteri 1. Se vuoi che un criterio relativo ai dati venga applicato al tag di criteri 1b e ai suoi figli, impostalo sul tag di criteri 1b.

Mascheramento dei dati con funzionalità incompatibili

Quando utilizzi funzionalità BigQuery non compatibili con il mascheramento dei dati, il servizio tratta la colonna mascherata come una colonna protetta e concede l'accesso solo agli utenti che dispongono del ruolo Lettore granulare di Data Catalog.

Ad esempio, prendi il tag di criteri e la configurazione delle norme relative ai dati mostrati nella Figura 6:

Figura 6. Configurazione del tag di criteri e delle norme relative ai dati.

Hai una colonna della tabella annotata con il tag di criteri Financial e un utente che fa parte del gruppo [e-mail]. Quando questo utente tenta di accedere alla colonna annotata tramite una delle funzionalità incompatibili, riceve un errore di accesso negato. Questo perché viene concesso il ruolo Lettore mascherato BigQuery tramite tag di criteri Financial, ma in questo caso deve avere il ruolo Lettore granulare Data Catalog. Poiché il servizio ha già determinato un ruolo applicabile per l'utente, non continua a controllare più in alto nella gerarchia tag di criteri per verificare se sono presenti autorizzazioni aggiuntive.

Esempio di mascheramento dei dati con output

Per capire come interagiscono tag, entità e ruoli, considera questo esempio.

In example.com, l'accesso di base viene concesso tramite il gruppo [e-mail]. Tutti i dipendenti che hanno bisogno di accedere regolarmente ai dati BigQuery fanno parte di questo gruppo, a cui sono assegnate tutte le autorizzazioni necessarie per leggere dalle tabelle, nonché il ruolo Lettore mascherato BigQuery.

I dipendenti vengono assegnati a gruppi aggiuntivi che forniscono l'accesso alle colonne protette o nascoste, se necessario per il loro lavoro. Tutti i membri di questi gruppi aggiuntivi sono anche membri di [e-mail]. Puoi vedere come questi gruppi sono associati ai ruoli appropriati nella Figura 7:

Figura 7. Tag criterio e norme relative ai dati per example.com.

I tag dei criteri vengono poi associati alle colonne della tabella, come mostrato nella Figura 8:

Figura 8. Tag di criteri di Example.com associati alle colonne della tabella.

Dati i tag associati alle colonne, l'esecuzione di SELECT * FROM Accounts; porta ai seguenti risultati per i diversi gruppi:

• [e-mail]: a questo gruppo è stato concesso il ruolo Lettore mascherato BigQuery sia per i tag di criteri PII sia per i tag di criteri Confidential. Vengono restituiti i seguenti risultati:

  SSN	Priorità	Lifetime value	Data di creazione	Email
  NULL	""	0	8 marzo 1983	NULL
  NULL	""	0	29 dicembre 2009	NULL
  NULL	""	0	14 luglio 2021	NULL
  NULL	""	0	5 maggio 1997	NULL

• [e-mail]: a questo gruppo è stato concesso il ruolo Lettore granulare Data Catalog per il tag di criteri SSN. Vengono restituiti i seguenti risultati:

  SSN	Priorità	Lifetime value	Data di creazione	NULL
  123-45-6789	""	0	8 marzo 1983	NULL
  234-56-7891	""	0	29 dicembre 2009	NULL
  345-67-8912	""	0	14 luglio 2021	NULL
  456-78-9123	""	0	5 maggio 1997	NULL

• [e-mail]: a questo gruppo è stato concesso il ruolo Lettore granulare Data Catalog per il tag di criteri Confidential. Vengono restituiti i seguenti risultati:

  SSN	Priorità	Lifetime value	Data di creazione	Email
  NULL	Alta	90.000	8 marzo 1983	NULL
  NULL	Alta	84.875	29 dicembre 2009	NULL
  NULL	Medio	38.000	14 luglio 2021	NULL
  NULL	Bassa	245	5 maggio 1997	NULL

• [e-mail]: a questo gruppo è stato assegnato il ruolo Lettore mascherato BigQuery per il tag di criteri Financial. Vengono restituiti i seguenti risultati:

  SSN	Priorità	Lifetime value	Data di creazione	Email
  NULL	""	Zmy9vydG5q=	8 marzo 1983	NULL
  NULL	""	GhwTwq6Ynm=	29 dicembre 2009	NULL
  NULL	""	B6y7dsgaT9=	14 luglio 2021	NULL
  NULL	""	Uh02hnR1sg=	5 maggio 1997	NULL

• Tutti gli altri utenti: a qualsiasi utente che non appartiene a uno dei gruppi elencati viene visualizzato un errore di accesso negato perché non gli sono stati concessi i ruoli Lettore granulare di Data Catalog o Lettore mascherato di BigQuery. Per eseguire query sulla tabella Accounts, devono invece specificare solo le colonne a cui hanno accesso in SELECT * EXCEPT (restricted_columns) FROM Accounts per escludere le colonne protette o mascherate.

Considerazioni sui costi

La mascheratura dei dati potrebbe influire indirettamente sul numero di byte elaborati e quindi sul costo della query. Se un utente esegue una query su una colonna che è nascosta per lui con le regole Nullify o Valore maschera predefinito, la colonna non viene nemmeno scansionata, con un conseguente calo dei byte elaborati.

Restrizioni e limitazioni

Le sezioni seguenti descrivono le categorie di restrizioni e limitazioni a cui è soggetto il mascheramento dei dati.

Gestione delle norme relative ai dati

• Questa funzionalità potrebbe non essere disponibile se utilizzi prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni su le funzionalità abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.
• Puoi creare fino a nove criteri relativi ai dati per ogni tag di criteri. Uno di questi criteri è riservato alle impostazioni di controllo dell'accesso a livello di colonna.
• I criteri dei dati, i relativi tag di criteri e le eventuali routine che li utilizzano devono essere nello stesso progetto.

Tag di criteri

• Il progetto contenente la tassonomia dei tag di criteri deve appartenere a un'organizzazione.

• Una gerarchia di tag di criteri non può avere più di cinque livelli di profondità dal nodo principale al sottotag di livello più basso, come mostrato nello screenshot seguente:

  

Impostare controllo dell'accesso

Una volta che a una tassonomia è associata una norma relativa ai dati ad almeno uno dei suoi tag, il controllo dell'accesso viene applicato automaticamente. Se vuoi disattivare controllo dell'accesso, devi prima eliminare tutti i criteri dei dati associati alla tassonomia.

Viste materializzate e query di mascheramento dei record ripetute

Se esistono viste materializzate, le query di mascheramento dei record ripetute sulla tabella di base associata non vanno a buon fine. Per risolvere il problema, elimina la vista materializzata. Se la vista materializzata è necessaria per altri motivi, puoi crearla in un altro set di dati.

Esegui query sulle colonne mascherate nelle tabelle partizionate

Le query che includono il mascheramento dei dati nelle colonne suddivise o raggruppate non sono supportate.

Dialetti SQL

L'SQL precedente non è supportato.

Routine di mascheramento personalizzate

Le routine di mascheramento personalizzate sono soggette alle seguenti limitazioni:

• La mascheratura dei dati personalizzata supporta tutti i tipi di dati BigQuery tranne STRUCT, perché la mascheratura dei dati può essere applicata solo ai campi di primo livello del tipo di dati STRUCT.
• L'eliminazione di una routine di mascheramento personalizzata non comporta l'eliminazione di tutte le norme relative ai dati che la utilizzano. Tuttavia, i criteri dei dati che utilizzano la routine di mascheramento eliminata rimangono con una regola di mascheramento vuota. Gli utenti con il ruolo Lettore con mascheramento in altri criteri di dati con lo stesso tag possono visualizzare i dati mascherati. Gli altri vedono il messaggio Permission denied. I riferimenti inutilizzati a regole di mascheramento vuote potrebbero essere eliminati da procedure automatiche dopo sette giorni.

Compatibilità con altre funzionalità di BigQuery

API BigQuery

Non compatibile con il metodo tabledata.list. Per chiamare tabledata.list, devi disporre dell'accesso completo a tutte le colonne restituite da questo metodo. Il ruolo Lettore granulare Data Catalog concede accesso appropriato.

Tabelle BigLake

Compatibile. I criteri di mascheramento dei dati vengono applicati alle tabelle BigLake.

API BigQuery Storage Read

Compatibile. I criteri di mascheramento dei dati vengono applicati nell'API BigQuery Storage Read.

BigQuery BI Engine

Compatibile. I criteri di mascheramento dei dati vengono applicati in BI Engine. Le query con il mascheramento dei dati attivo non vengono accelerate da BI Engine. L'utilizzo di queste query in Looker Studio potrebbe causare un rallentamento e un aumento dei costi dei report o delle dashboard correlati.

BigQuery Omni

Compatibile. I criteri di mascheramento dei dati vengono applicati alle tabelle BigQuery Omni.

Regole di confronto

Non compatibile. L'ordinamento non è supportato nelle colonne mascherate.

Job di copia

Non compatibile. Per copiare una tabella dall'origine alla destinazione, devi avere accesso completo a tutte le colonne della tabella di origine. Il ruolo Lettore granulare Data Catalog concede l'accesso appropriato.

Esportazione dei dati

Compatibile. Se disponi del ruolo Lettore mascherato BigQuery, i dati esportati vengono mascherati. Se disponi del ruolo Lettore granulare Data Catalog, i dati esportati non vengono mascherati.

Sicurezza a livello di riga

Compatibile. Il mascheramento dei dati viene applicato sopra la sicurezza a livello di riga. Ad esempio, se è applicato un criterio di accesso alle righe a location = "US" e location è mascherato, gli utenti possono vedere le righe in cui è presente location = "US", ma il campo posizione è mascherato.

Ricerca in BigQuery

Parzialmente compatibile. Puoi chiamare la funzione SEARCH su colonne indicizzate o non indicizzate a cui è stato applicato il mascheramento dei dati.

Quando chiami la funzione SEARCH nelle colonne a cui è stata applicata la mascheratura dei dati, devi utilizzare criteri di ricerca compatibili con il tuo livello di accesso. Ad esempio, se disponi dell'accesso come Lettore mascherato con una regola di mascheramento dei dati Hash (SHA-256), devi utilizzare il valore hash nella clausola SEARCH, in modo simile al seguente:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

Se disponi dell'accesso Lettura dettagliata, devi utilizzare il valore della colonna effettivo nella clausola SEARCH, in modo simile al seguente:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "[e-mail]");

La ricerca è meno utile se disponi dell'accesso come Lettore mascherato a una colonna in cui la regola di mascheramento dei dati utilizzata è Annulla o Valore mascheramento predefinito. Questo perché i risultati mascherati che utilizzeresti come criteri di ricerca, ad esempio NULL o "", non sono sufficientemente univoci per essere utili.

Quando esegui una ricerca in una colonna indicizzata a cui è stato applicato il mascheramento dei dati, l'indice di ricerca viene utilizzato solo se disponi dell'accesso come lettore granulare alla colonna.

Snapshot

Non compatibile. Per creare uno snapshot di una tabella, devi disporre dell'accesso completo a tutte le colonne della tabella di origine. Il ruolo Lettore granulare Data Catalog concede l'accesso appropriato.

Ridenominazione delle tabelle

Compatibile. Il rinominazione delle tabelle non è interessata dal mascheramento dei dati.

Viaggio nel tempo

Compatibile sia con i decoratori di tempo sia con l'opzione FOR SYSTEM_TIME AS OF nelle istruzioni SELECT. I tag di criteri per lo schema del set di dati corrente vengono applicati ai dati recuperati.

Memorizzazione nella cache delle query

Parzialmente compatibile. BigQuery memorizza nella cache i risultati delle query per circa 24 ore, anche se la cache viene invalidata se vengono apportate modifiche ai dati o allo schema della tabella prima di questo periodo. Nella seguente circostanza, è possibile che un utente a cui non è stato concesso il ruolo Lettore granulare del catalogo di dati su una colonna possa ancora visualizzare i dati della colonna quando esegue una query:

1. A un utente è stato concesso il ruolo Lettore granulare Data Catalog su una colonna.
2. L'utente esegue una query che include la colonna con limitazioni e i dati vengono memorizzati nella cache.
3. Entro 24 ore dal passaggio 2, all'utente viene concesso il ruolo Lettore mascherato di BigQuery e viene revocato il ruolo Lettore granulare del Catalogo di dati.
4. Entro 24 ore dal passaggio 2, l'utente esegue la stessa query e vengono restituiti i dati memorizzati nella cache.

Query sulle tabelle con caratteri jolly

Non compatibile. Devi disporre dell'accesso completo a tutte le colonne a cui viene fatto riferimento in tutte le tabelle corrispondenti alla query con caratteri jolly. Il ruolo Lettore granulare Data Catalog concede l'accesso appropriato.

Passaggi successivi

• Visualizza istruzioni dettagliate per attivare il mascheramento dei dati.