Introduzione al mascheramento dei dati

Nota: questa funzionalità potrebbe non essere disponibile quando utilizzi le prenotazioni create con determinate versioni di BigQuery. Per saperne di più sulle funzionalità abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.

BigQuery supporta il mascheramento dei dati a livello di colonna. Puoi utilizzare il mascheramento dei dati per oscurare selettivamente i dati delle colonne per i gruppi di utenti, consentendo comunque loro di accedere alla colonna. La funzionalità di mascheramento dei dati si basa sul controllo dell'accesso a livello di colonna, perciò 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, da accesso completo a nessun accesso, in base alle esigenze di diversi gruppi di utenti. Ad esempio, per i dati relativi all'ID fiscale, potresti voler concedere al tuo gruppo di contabilità l'accesso completo, al tuo gruppo di analisti l'accesso mascherato e il tuo gruppo di vendita nessun accesso.

Vantaggi

Il mascheramento dei dati offre i seguenti vantaggi:

• Semplifica il processo di condivisione dei dati. Puoi mascherare le colonne sensibili per consentire di condividere le 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 configuri il mascheramento dei dati, le query esistenti mascherano automaticamente i dati delle colonne in base ai ruoli assegnati all'utente.
• Puoi applicare criteri di accesso ai dati su larga scala. Puoi scrivere un criterio di dati, associarlo a un tag di criteri e applicare il tag di criteri a qualsiasi numero di colonne.
• Consente il controllo dell'accesso basato su attributi. Un tag di criteri associato a una colonna fornisce l'accesso contestuale ai dati, che è determinato dal criterio dei dati e dalle entità associate al tag di criteri.

Flusso di lavoro di mascheramento dei dati

La figura 1 mostra il flusso di lavoro per la configurazione del mascheramento dei dati:

Figura 1. Componenti di mascheramento dei dati.

Per configurare il mascheramento dei dati:

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

2. Configura le norme sui dati per i tag di criteri. Un criterio dei dati mappa una regola di mascheramento dei dati e una o più entità, che rappresentano utenti o gruppi, al tag di criteri.

   Quando crei un criterio dei dati utilizzando la console Google Cloud, puoi creare la regola di mascheramento dei dati e specificare le entità in un solo passaggio. Quando crei un criterio dei dati utilizzando l'API BigQuery Data Policy, puoi creare il criterio dei dati e la regola di mascheramento dei dati in un passaggio e specificare le entità per il criterio dei dati in un secondo passaggio.

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

4. Assegna gli utenti che devono avere accesso ai dati mascherati al ruolo Lettore mascherato BigQuery. Come best practice, assegna il ruolo Lettore mascherato BigQuery a livello di criterio dei dati. L'assegnazione del ruolo a livello di progetto o superiore concede agli utenti le autorizzazioni per tutti i criteri dei dati nell'ambito del progetto, il che può causare problemi causati da un eccesso di autorizzazioni.

   Il tag di criteri associato a un criterio dei dati può essere utilizzato anche per controllo dell'accesso a livello di colonna. In questo caso, il tag di criteri è anche associato a una o più entità a cui viene concesso il ruolo Lettore granulare di Data Catalog. Ciò consente a queste entità di accedere ai dati della colonna originali, non mascherati.

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

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 gerarchia dei tag di criteri.

Regole di mascheramento dei dati

Quando utilizzi il mascheramento dei dati, viene applicata una regola di mascheramento dei dati a una colonna al momento dell'esecuzione della query, in base al ruolo dell'utente che la esegue. Il mascheramento 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 l'applicazione di una funzione definita dall'utente alla colonna. Per gestire la regola di mascheramento sono necessarie autorizzazioni di routine. Per impostazione predefinita, questa regola supporta tutti i tipi di dati BigQuery, ad eccezione del tipo di dati STRUCT. Tuttavia, il supporto per tipi di dati diversi da STRING e BYTES è limitato. L'output dipende dalla funzione definita.

  Per ulteriori informazioni sulla creazione di funzioni definite dall'utente per le routine di mascheramento personalizzate, consulta Creare routine di mascheramento personalizzate.

• Maschera di data e anno. Restituisce il valore della colonna dopo averlo troncato all'anno, impostando tutte le parti non annuali del valore all'inizio dell'anno. Puoi utilizzare questa regola solo con le colonne che usano 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	17-07-2030 01:45:06	01-01-2030 00:00:00

  Nota: il troncamento viene eseguito in base al fuso orario UTC. Per cambiare questa impostazione, modifica 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. Da usare se 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 durante l'unione delle tabelle.

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

  Tipo di dati	Valore di mascheramento predefinito
  STRING	""
  BYTES	"
  INTEGER	0
  FLOAT	0,0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	01-01-1970 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	PUNTO(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, restituisce il valore della colonna dopo che è stata eseguita con la funzione hash SHA-256. Puoi utilizzare questa regola solo con le colonne che utilizzano il tipo di dati 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 è stata eseguita con la funzione hash SHA-256. Puoi utilizzare questa regola solo con le colonne che usano il tipo di dati STRING.

• Hash (SHA-256). Restituisce il valore della colonna dopo che è stata eseguita tramite la funzione hash SHA-256. Da utilizzare se vuoi che l'utente finale possa utilizzare la colonna in un'operazione JOIN per una query. Puoi utilizzare questa regola solo con le colonne che usano i tipi di dati STRING o BYTES.

  La funzione SHA-256 utilizzata nel mascheramento dei dati preserva il tipo, pertanto il valore hash restituito ha lo stesso tipo di dati del valore della colonna. Ad esempio, il valore hash per il valore di una colonna STRING ha anche un tipo di dati STRING.

  Importante: l'algoritmo SHA-256 è una funzione di hashing deterministica; un valore iniziale viene sempre risolto sullo stesso valore hash. Tuttavia, non sono necessarie chiavi di crittografia. Ciò consente a un utente malintenzionato di utilizzare un attacco di forza bruta per determinare il valore originale, eseguendo tutti i possibili valori originali tramite l'algoritmo SHA-256 e vedendo quale produce un hash che corrisponde all'hash restituito dal mascheramento 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 è stata eseguita con la funzione hash SHA-256. Puoi utilizzare questa regola solo con le colonne che usano il tipo di dati STRING.

• Nullify. Restituisce NULL anziché il valore della colonna. Da utilizzare per 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 delle tabelle.

Gerarchia delle regole di mascheramento dei dati

Puoi configurare fino a nove criteri dei dati per un tag di criteri, ognuno con una regola di mascheramento dei dati diversa associata. Uno di questi criteri è riservato alle impostazioni di controllo dell'accesso a livello di colonna. In questo modo è possibile applicare diversi criteri dei dati a una colonna nella query di un utente, in base ai gruppi di cui l'utente 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 anno della data
7. Valore di mascheramento predefinito
8. Annulla

Ad esempio, l'utente A fa parte sia dei dipendenti sia dei gruppi di contabilità. L'utente A esegue una query che include il campo sales_total, a cui è applicato il tag di criteri confidential. Al tag di criteri confidential sono associati due criteri relativi ai dati: uno con il ruolo dipendenti come entità e che applica la regola di mascheramento dei dati annullato, l'altro con ruolo di contabilità come entità e applica la regola di mascheramento dei dati hash (SHA-256). In questo caso, la regola di mascheramento dei dati hash (SHA-256) ha la priorità sulla regola di mascheramento dei dati annulla, quindi la regola hash (SHA-256) viene applicata al valore del campo sales_total nella query dell'utente A.

La figura 3 mostra questo scenario:

Figura 3. Assegnazione della priorità alle regole di mascheramento dei dati.

Ruoli e autorizzazioni

Ruoli per la gestione di tassonomie e tag di criteri

Per creare e gestire tassonomie e tag di criteri, devi disporre del ruolo Amministratore tag di criteri di Data Catalog.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore tag di criteri di 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: Creare, leggere, aggiornare ed eliminare tassonomie e tag di criteri. Ottieni e imposta i criteri IAM sui tag di criteri.

Ruoli per la creazione e la gestione dei criteri dei dati

Per creare e gestire i criteri sui dati, devi avere uno dei seguenti ruoli BigQuery:

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore BigQuery/bigquery.admin Proprietario 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 criterio dei dati. Questo ruolo consente di: Creare, leggere, aggiornare ed eliminare i criteri relativi ai dati. Ottieni e imposta i criteri IAM sui criteri dei dati.

È necessaria anche l'autorizzazione datacatalog.taxonomies.get, che puoi ottenere da diversi ruoli predefiniti di Data Catalog.

Ruoli per collegare tag di criteri alle colonne

Devi disporre delle autorizzazioni datacatalog.taxonomies.get e bigquery.tables.setCategory per collegare i tag di criteri alle colonne. datacatalog.taxonomies.get è incluso nei ruoli Amministratore e Visualizzatore tag di criteri di Data Catalog. bigquery.tables.setCategory è incluso nei ruoli Amministratore BigQuery (roles/bigquery.admin) e Proprietario dati BigQuery (roles/bigquery.dataOwner).

Ruoli per l'esecuzione di query sui dati mascherati

Devi avere il ruolo Lettore mascherato BigQuery per eseguire query sui dati da una colonna a cui è applicato il mascheramento dei dati.

Ruolo/ID	Autorizzazioni	Descrizione
Lettore mascherato/bigquerydatapolicy.maskedReader	bigquery.dataPolicies.maskedGet	Si applica a livello di criterio dei dati. Questo ruolo consente di visualizzare i dati mascherati di una colonna associata a un criterio dei dati. Inoltre, un utente deve disporre delle autorizzazioni appropriate per eseguire query sulla tabella. Per maggiori informazioni, consulta la sezione Autorizzazioni obbligatorie.

Come interagiscono i ruoli Lettore mascherato 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 BigQuery Masked Reader che consente loro di leggere i dati mascherati, alcuni utenti con il ruolo Lettore granulare Data Catalog che consente di leggere dati non mascherati, alcuni utenti con entrambi e alcuni utenti con nessuno dei due. Questi ruoli interagiscono come segue:

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

Nel caso in cui una tabella abbia colonne protette o protette e mascherate, per eseguire un'istruzione SELECT * FROM su tale tabella, un utente deve essere membro dei gruppi appropriati, in modo da poter avere i ruoli Lettore mascherato o Lettore granulare per tutte queste colonne.

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

Ereditarietà dell'autorizzazione in una gerarchia di tag di criteri

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

Ad esempio, considera il tag di criteri e la configurazione del criterio dei dati mostrati nella Figura 4:

Figura 4. Tag di criteri e configurazione dei criteri dei dati.

Hai una colonna della tabella annotata con il tag di criteri Financial e un utente membro dei gruppi [e-mail] e [e-mail]. Quando questo utente esegue una query che include la colonna annotata, il suo accesso è determinato dalla gerarchia definita nella tassonomia dei tag di criteri. Poiché all'utente viene concesso il ruolo Lettore granulare di Data Catalog dal tag di criteri Financial, la query restituisce i dati della colonna 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 che sono stati sottoposti ad hashing utilizzando l'algoritmo SHA-256, perché all'utente viene concesso il ruolo di lettore mascherato BigQuery dal tag di criteri Confidential, che è il padre del tag di criterio 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 dei dati mostrati nella Figura 5:

Figura 5. Tag di criteri e configurazione dei criteri dei dati.

La situazione è la stessa di quella 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 mascherate per l'utente in questione. Questo si verifica anche se all'utente viene concesso il ruolo Lettore granulare più in alto nella gerarchia dei tag, perché il servizio utilizza il primo ruolo assegnato che rileva mentre sale nella gerarchia di 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 nel tag di criteri che rappresenta il livello gerarchico di livello più alto a cui deve essere applicato. Ad esempio, prendi una tassonomia con la seguente struttura:

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

Se vuoi che un criterio dei dati venga applicato a tutti questi tag di criteri, imposta il criterio dei dati sul tag di criteri 1. Se vuoi che un criterio dei dati venga applicato al tag di criteri 1b e ai relativi secondi, imposta il criterio dei dati sul tag di criteri 1b.

Mascheramento dei dati con funzionalità non compatibili

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 con il ruolo Lettore granulare Data Catalog.

Ad esempio, considera il tag di criteri e la configurazione del criterio dei dati mostrati nella Figura 6:

Figura 6. Tag di criteri e configurazione dei criteri dei 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à non compatibili, riceve un errore di accesso negato. Questo perché viene concesso il lettore mascherato BigQuery dal 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 eseguire controlli più in alto nella gerarchia dei tag di criteri per trovare autorizzazioni aggiuntive.

Esempio di mascheramento dei dati con output

Questo esempio mostra come interagiscono tag, entità e ruoli.

Su 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 sono membri di questo gruppo a cui sono assegnate tutte le autorizzazioni necessarie per leggere le tabelle, nonché il ruolo BigQuery Masked Reader.

I dipendenti vengono assegnati a gruppi aggiuntivi che forniscono accesso a colonne protette o mascherate dove questo è 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 di criteri e norme sui dati per example.com.

I tag di criteri vengono quindi associati alle colonne delle tabelle, come illustrato nella Figura 8:

Figura 8. Tag di criteri example.com associati alle colonne delle tabelle.

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 BigQuery Masked Reader per i tag di criterio PII e 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 di 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 di 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	Basso	245	5 maggio 1997	NULL

• [e-mail]: a questo gruppo è stato concesso il ruolo BigQuery Masked Reader 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: gli utenti che non appartengono a uno dei gruppi elencati ricevono un errore di accesso negato perché non hanno i ruoli Lettore granulare Data Catalog o Lettore mascherato BigQuery. Per eseguire query sulla tabella Accounts, devono invece specificare solo le colonne a cui ha accesso nel SELECT * EXCEPT (restricted_columns) FROM Accounts per escludere le colonne protette o mascherate.

Considerazioni sui costi

Il mascheramento dei dati potrebbe influire indirettamente sul numero di byte elaborati e di conseguenza sul costo della query. Se un utente esegue una query su una colonna mascherata con le regole Annullamento o Valore di mascheramento predefinito, la colonna non viene analizzata, con un conseguente calo dei byte elaborati.

Restrizioni e limitazioni

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

Gestione dei criteri dei dati

• Questa funzionalità potrebbe non essere disponibile quando utilizzi le prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni sulle funzionalità abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.
• Puoi creare fino a nove criteri dei 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 tag di criteri associati 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ò trovarsi più di cinque livelli dal nodo principale al sottotag di livello inferiore, come mostrato nello screenshot seguente:

  

Imposta controllo dell'accesso

Quando una tassonomia ha un criterio dei dati associato ad almeno uno dei suoi tag di criteri, 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 già viste materializzate, le ripetute query di mascheramento dei record nella tabella di base associata non riusciranno. Per risolvere il problema, elimina la vista materializzata. Se la vista materializzata è necessaria per altri motivi, puoi crearla in un altro set di dati.

Query su colonne mascherate nelle tabelle partizionate

Le query che includono il mascheramento dei dati nelle colonne partizionate o in cluster non sono supportate.

Dialetti SQL

SQL precedente non supportato.

Routine di mascheramento personalizzate

Le routine di mascheramento personalizzate sono soggette alle seguenti limitazioni:

• Il mascheramento dei dati personalizzato supporta tutti i tipi di dati BigQuery tranne STRUCT, perché il mascheramento dei dati può essere applicato solo ai campi foglia del tipo di dati STRUCT.
• L'eliminazione di una routine di mascheramento personalizzata non elimina tutti i criteri dei dati che la utilizzano. Tuttavia, i criteri relativi ai dati che utilizzano la routine di mascheramento eliminata hanno una regola di mascheramento vuota. Gli utenti con il ruolo Lettore mascherato in altri criteri relativi ai dati con lo stesso tag possono visualizzare i dati mascherati. Altri vedono il messaggio Permission denied. I riferimenti pendenti a regole di mascheramento vuote potrebbero essere eliminati dai processi automatici dopo sette giorni.

Compatibilità con altre funzionalità di BigQuery

API BigQuery

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

Tavoli 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 che hanno il mascheramento dei dati attivo non vengono accelerate da BI Engine. L'uso di queste query in Looker Studio potrebbe far sì che i report o le dashboard correlati diventino più lenti e costosi.

BigQuery Omni

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

Regole di confronto

Non compatibile. Le regole di confronto non sono supportate nelle colonne mascherate.

Job di copia

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

Esportazione dei dati

Compatibile. Se hai il ruolo Lettore mascherato BigQuery, i dati esportati sono mascherati. Se hai il ruolo Lettore granulare di Data Catalog, i dati esportati non vengono mascherati.

Sicurezza a livello di riga

Compatibile. Il mascheramento dei dati viene applicato in aggiunta alla sicurezza a livello di riga. Ad esempio, se è stato applicato un criterio di accesso alle righe in location = "US" e location è mascherato, gli utenti possono visualizzare le righe in cui location = "US" ma il campo della località è mascherato.

Cerca in BigQuery

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

Quando chiami la funzione SEARCH sulle colonne a cui è applicato il mascheramento dei dati, devi utilizzare criteri di ricerca compatibili con il tuo livello di accesso. Ad esempio, se disponi dell'accesso Masked Reader con una regola di mascheramento dei dati Hash (SHA-256), dovresti utilizzare il valore hash nella clausola SEARCH, come in questo caso:

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

Se disponi dell'accesso di tipo Lettore granulare, devi utilizzare il valore effettivo della colonna nella clausola SEARCH, in modo simile a quanto segue:

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

La ricerca ha meno probabilità di essere utile se disponi dell'accesso Lettore mascherato a una colonna in cui la regola di mascheramento dei dati utilizzata è Nullify o Valore di mascheramento predefinito. Questo perché i risultati mascherati che useresti 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 è applicato il mascheramento dei dati, l'indice di ricerca viene utilizzato solo se alla colonna disponi dell'accesso Lettore granulare.

Snapshot

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

Ridenominazione delle tabelle

Compatibile. La ridenominazione delle tabelle non è interessata dal mascheramento dei dati.

Viaggio nel tempo

Compatibile sia con i decoratori del tempo sia con l'opzione FOR SYSTEM_TIME AS OF nelle dichiarazioni 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 della tabella o allo schema prima di questa data. Nei seguenti casi, è possibile che un utente a cui non è stato concesso il ruolo Lettore granulare di Data Catalog su una colonna possa comunque 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 il ruolo Lettore granulare di Data Catalog viene revocato.
4. Entro 24 ore dal passaggio 2, l'utente esegue la stessa query e vengono restituiti i dati memorizzati nella cache.

Query tabella con caratteri jolly

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

Passaggi successivi

• Visualizza istruzioni dettagliate per attivare il mascheramento dei dati.