Introduzione al mascheramento dei dati

Nota: questa funzionalità potrebbe non essere disponibile quando si utilizzano prenotazioni create con determinate versioni di BigQuery. Per saperne di più su quali funzionalità sono abilitate in ogni versione, consulta la guida 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, pur consentendo loro di accedere alla colonna. La funzionalità di mascheramento dei dati si basa sul controllo dell'accesso a livello di colonna, per cui 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 o senza accesso, in base alle esigenze dei diversi gruppi di utenti. Ad esempio, per i dati dell'ID fiscale, è consigliabile concedere al gruppo di contabilità l'accesso completo, l'accesso mascherato del gruppo di analisti e l'impossibilità di accedere al gruppo di vendite.

Vantaggi

Il mascheramento dei dati offre i seguenti vantaggi:

• Semplifica il processo di condivisione dei dati. Puoi mascherare le colonne sensibili per consentire la condivisione di 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 concessi all'utente.
• Puoi applicare i criteri di accesso ai dati su larga scala. Puoi scrivere un criterio relativo ai dati, associarlo a un tag di criteri e applicare il tag di criteri a un numero qualsiasi 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 per il 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. Configura una tassonomia e uno o più tag criterio.

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 relativo ai dati utilizzando la console Google Cloud, crei la regola di mascheramento dei dati e specifichi le entità in un solo passaggio. Quando crei un criterio relativo ai dati utilizzando l'API BigQuery Data Policy, devi creare il criterio dei dati e la regola di mascheramento dei dati in un solo passaggio e specificare le entità per il criterio sui dati in un secondo passaggio.

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

4. Assegna al ruolo Lettore mascherato BigQuery gli utenti che dovrebbero avere accesso ai dati mascherati. Come best practice, assegna il ruolo di 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 relativi ai dati nel progetto, il che può causare problemi causati da autorizzazioni eccessive.

   Il tag di criteri associato a un criterio di 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 Data Catalog. Ciò consente a queste entità di accedere ai dati delle colonne originali non mascherati.

La Figura 2 mostra l'interazione tra controllo dell'accesso a livello di colonna e il mascheramento dei dati:

Figura 2. Componenti di mascheramento dei dati.

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

Regole di mascheramento dei dati

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

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

• Maschera anno della data. Restituisce il valore della colonna dopo averlo troncato in base 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 modificarlo, modifica il fuso orario predefinito utilizzando la @@time_zone variabile di sistema.

• Valore predefinito di mascheramento. Restituisce un valore di mascheramento predefinito per la colonna in base al tipo di dati della colonna. Consente di 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 con lettore mascherato. Questo perché un valore predefinito non è sufficientemente univoco per essere utile durante l'unione delle tabelle.

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

  Tipo di dati	Valore predefinito di mascheramento
  STRING	""
  BYTES	b''
  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	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 indirizzo email valido con XXXXX. Se il valore della colonna non è un indirizzo email valido, verrà restituito il valore della colonna dopo che è stato eseguito tramite la funzione hash SHA-256. Puoi utilizzare questa regola solo con 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, viene restituito il valore della colonna dopo che è stata analizzata tramite la funzione hash SHA-256. Puoi utilizzare questa regola solo con colonne che utilizzano 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 quando vuoi che l'utente finale possa usare 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 nel mascheramento dei dati preserva il tipo, quindi 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 un tipo di dati STRING.

  Importante: SHA-256 è una funzione di hashing deterministica; un valore iniziale viene sempre risolto con lo stesso valore hash. Tuttavia, non richiede 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 osservando quale produce un hash corrispondente a quello 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 è pari o inferiore a 4 caratteri, restituisce il valore della colonna dopo che è stata eseguita tramite la funzione hash SHA-256. Puoi utilizzare questa regola solo con colonne che utilizzano il tipo di dati STRING.

• Annulla. Restituisce NULL anziché il valore della colonna. Utilizza questa opzione 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 con 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 di dati per un tag di criteri, ciascuno con una regola di mascheramento dei dati diversa associata. Uno di questi criteri è riservato per le impostazioni di controllo dell'accesso a livello di colonna. Ciò consente di applicare più criteri relativi ai dati a una colonna nella query di un utente, in base ai gruppi di cui l'utente è membro. In questo caso, BigQuery sceglie la regola di mascheramento dei dati da 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 e anno
7. Valore di mascheramento predefinito
8. Annulla

Ad esempio, l'utente A fa parte sia dei dipendenti che dei gruppi contabili. 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 sui dati: uno con il ruolo "dipendenti" come entità e che applica la regola di mascheramento dei dati nullify, mentre l'altro ha il ruolo di accounting 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 nullify, 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 criteri di Data Catalog.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore tag criteri 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 concede l'autorizzazione per: 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 relativi ai dati

Per creare e gestire i criteri relativi ai dati, devi disporre di 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 relativo ai dati. Questo ruolo concede l'autorizzazione per: Creare, leggere, aggiornare ed eliminare i criteri relativi ai dati. Ottieni e imposta i criteri IAM sui criteri relativi ai dati.

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

Ruoli per il collegamento dei tag di criteri alle colonne

Per associare i tag di criteri alle colonne, devi disporre delle autorizzazioni datacatalog.taxonomies.get e bigquery.tables.setCategory. datacatalog.taxonomies.get è incluso nei ruoli Amministratore e Visualizzatore tag 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 di lettore mascherato BigQuery per eseguire query sui dati di una colonna a cui è applicato il mascheramento dei dati.

Ruolo/ID	Autorizzazioni	Descrizione
Lettore mascherato/bigquerydatapolicy.maskedReader	bigquery.dataPolicies.maskedGet	Si applica a livello delle norme sui dati. Questo ruolo concede la possibilità 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 Autorizzazioni richieste.

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

• Utente con ruoli di lettore granulare e di lettore mascherato: ciò che visualizza dipende da dove viene concesso ciascun ruolo all'interno della gerarchia dei tag di criteri. Per ulteriori informazioni, consulta Eredità delle autorizzazioni in una gerarchia di tag di criteri.
• Utente con ruolo di lettore granulare: può visualizzare i dati delle colonne non mascherati (non oscurati).
• Utente con ruolo di lettore mascherato: può visualizzare i dati delle colonne oscurate.
• Utente senza nessuno dei due ruoli: autorizzazione negata.

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

Un utente a cui non vengono 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 controllati a ogni livello crescente della tassonomia, finché l'utente non dispone delle autorizzazioni appropriate o non viene raggiunta la parte superiore della gerarchia dei tag di criteri.

Ad esempio, prendiamo in considerazione il tag di criteri e la configurazione dei criteri dei dati mostrati nella Figura 4:

Figura 4. Configurazione dei criteri dei dati e del tag di criteri.

Hai una colonna della tabella annotata con il tag di criteri Financial e un utente che è membro di entrambi i 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 delle colonne non mascherati.

Se un altro utente che è solo 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 Lettore mascherato BigQuery dal tag di criteri Confidential, che è l'elemento principale del tag di criteri Financial.

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

A differenza dello scenario precedente, prendi in considerazione la configurazione dei tag di criteri e dei criteri dei dati come mostrato nella Figura 5:

Figura 5. Configurazione dei criteri dei dati e del tag di criteri.

La situazione è la stessa 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 nella gerarchia dei tag di criteri. Per questo motivo, la query restituisce i dati delle colonne mascherate per questo utente. Questo avviene anche se all'utente viene concesso il ruolo di lettore granulare a un livello più alto della gerarchia dei tag, in quanto il servizio utilizza il primo ruolo assegnato che incontra mentre sale la gerarchia dei tag di criteri per controllare l'accesso degli utenti.

Se vuoi creare un singolo criterio relativo ai dati e applicarlo a più livelli di una gerarchia di tag di criteri, puoi impostare il criterio relativo ai dati sul 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 criterio 1
  • Tag di criterio 1a
    • Tag di criterio 1ai
  • Tag di criterio 1b
    • Tag di criterio 1bi
    • Tag di criterio 1bii

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

Mascheramento dei dati con funzionalità non compatibili

Quando utilizzi funzionalità di 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 di lettore granulare di Data Catalog.

Ad esempio, prendiamo in considerazione il tag di criteri e la configurazione dei criteri dei dati mostrati nella Figura 6:

Figura 6. Configurazione dei criteri dei dati e del tag di criteri.

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 prova ad accedere alla colonna annotata tramite una delle funzionalità non compatibili, riceve un errore di accesso negato. Il motivo è che agli utenti viene concesso il tag di criteri Lettore mascherato BigQuery tramite Financial, ma in questo caso devono avere il ruolo Lettore granulare di Data Catalog. Poiché il servizio ha già determinato un ruolo applicabile per l'utente, non continua a controllare ulteriormente la gerarchia dei tag di criteri per trovare autorizzazioni aggiuntive.

Esempio di mascheramento dei dati con output

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

Su example.com, l'accesso di base è concesso tramite il gruppo [e-mail]. Tutti i dipendenti che hanno bisogno dell'accesso regolare ai dati BigQuery sono membri 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 a colonne protette o mascherate dove è richiesto per il loro lavoro. Tutti i membri di questi gruppi aggiuntivi sono anche membri di [e-mail]. Puoi vedere in che modo questi gruppi sono associati ai ruoli appropriati nella Figura 7:

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

I tag di criteri vengono quindi associati alle colonne della tabella, come mostrato 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; genera i seguenti risultati per i diversi gruppi:

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

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

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

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

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

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

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

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

• Tutti gli altri utenti: tutti gli utenti che non appartengono a uno dei gruppi elencati ricevono un errore di accesso negato perché non sono stati concessi i ruoli Lettore granulare di Data Catalog o Lettore mascherato BigQuery. Per eseguire query sulla tabella Accounts, deve invece specificare solo le colonne a cui ha accesso in 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, quella colonna non viene analizzata affatto, con un conseguente numero inferiore di byte elaborati.

Limitazioni e limitazioni

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

Gestione dei criteri relativi ai dati

• Questa funzionalità potrebbe non essere disponibile quando si utilizzano le prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni su quali funzionalità sono 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 per le impostazioni di controllo dell'accesso a livello di colonna.
• I criteri relativi ai dati, i tag di criteri associati e le eventuali routine che li utilizzano devono essere nello stesso progetto.

Tag di criteri

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

• Una gerarchia di tag di criteri non può superare i cinque livelli dal nodo principale al sottotag di livello inferiore, come mostrato nello screenshot seguente:

  

Imposta controllo dell'accesso

Quando un criterio relativo ai dati di una tassonomia è 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 viste materializzate, le query ripetute sul mascheramento dei record nella tabella di base associata non riescono. 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 sulle colonne mascherate nelle tabelle partizionate

Le query che includono il mascheramento dei dati sulle 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 ad eccezione di 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 sui dati che la utilizzano. Tuttavia, ai criteri dei dati che utilizzano la routine di mascheramento eliminata viene lasciata una regola di mascheramento vuota. Gli utenti con il ruolo di lettore mascherato su altri criteri relativi ai dati con lo stesso tag possono visualizzare i dati mascherati. Altre persone vedono il messaggio Permission denied. I riferimenti ripetuti alle regole di mascheramento vuoto potrebbero essere ripuliti da processi automatizzati dopo sette giorni.

Compatibilità con altre funzionalità di BigQuery

API BigQuery

Non compatibile con il metodo tabledata.list. Per chiamare tabledata.list, devi avere l'accesso completo a tutte le colonne restituite da questo metodo. Il ruolo Lettore granulare di Data Catalog concede l'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 per cui è attivo il mascheramento dei dati non vengono accelerate da BI Engine. L'utilizzo di queste query in Looker Studio potrebbe far diventare più lenti e costosi i report o le dashboard correlati.

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 avere accesso completo a tutte le colonne della tabella di origine. Il ruolo di lettore granulare di Data Catalog concede l'accesso appropriato.

Esportazione dei dati

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

Sicurezza a livello di riga

Compatibile. Il mascheramento dei dati viene applicato in alto alla sicurezza a livello di riga. Ad esempio, se su location = "US" è applicato un criterio di accesso alle righe e il criterio 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 sulle 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 come lettore mascherato con una regola di mascheramento dei dati hash (SHA-256), dovresti utilizzare il valore hash nella clausola SEARCH, in modo simile al seguente:

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

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

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

La ricerca ha meno probabilità di essere utile se hai accesso come lettore mascherato a una colonna in cui la regola di mascheramento dei dati utilizzata è NULLA o Valore di mascheramento predefinito. Questo perché i risultati mascherati che utilizzeresti come criteri di ricerca, come NULL o "", non sono sufficientemente univoci per essere utili.

Durante la ricerca in una colonna indicizzata a cui è 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 lo snapshot di una tabella, devi avere l'accesso completo a tutte le colonne nella tabella di origine. Il ruolo Lettore granulare di Data Catalog concede l'accesso appropriato.

Ridenominazione della tabella

Compatibile. Il mascheramento dei dati non influisce sulla ridenominazione della tabella.

Viaggio nel tempo

Compatibile con entrambi i decoratori temporali e l'opzione FOR SYSTEM_TIME AS OF nelle istruzioni SELECT. Ai dati recuperati vengono applicati i tag di criteri per lo schema attuale del set di dati.

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. Nei seguenti casi, è possibile che un utente a cui non è stato concesso il ruolo di lettore granulare di Data Catalog per una colonna possa comunque visualizzare i dati della colonna quando esegue una query:

1. A un utente è stato concesso il ruolo di lettore granulare di Data Catalog per una colonna.
2. L'utente esegue una query che include la colonna con restrizioni e i dati vengono memorizzati nella cache.
3. Entro 24 ore dal passaggio 2, all'utente viene concesso il ruolo di lettore mascherato BigQuery e il ruolo di 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 sulla tabella con caratteri jolly

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

Passaggi successivi

• Ottieni istruzioni dettagliate per attivare il mascheramento dei dati.