Introduzione al mascheramento dei dati
BigQuery supporta mascheramento dei dati a livello di colonna livello. Puoi utilizzare il mascheramento dei dati per oscurare selettivamente i dati delle colonne per gruppi di utenti, pur consentendo loro di accedere alla colonna. Mascheramento dei dati le funzionalità si basano su controllo dell'accesso a livello di colonna, quindi ti consigliamo di acquisire familiarità con questa funzione prima di procedere.
Quando utilizzi il mascheramento dei dati in combinazione con il controllo dell'accesso a livello di colonna, puoi configurare un intervallo di accesso ai dati delle colonne, dall'accesso completo all'accesso, in base alle esigenze di diversi gruppi di utenti. Ad esempio: per i dati dell'ID fiscale, puoi concedere al tuo gruppo contabile accesso completo, l'accesso mascherato del gruppo di analisti e quello del gruppo di vendita.
Vantaggi
Il mascheramento dei dati offre i seguenti vantaggi:
- Semplifica il processo di condivisione dei dati. Puoi mascherare le colonne sensibili per condividere le tabelle con gruppi più grandi.
- A differenza del controllo dell'accesso a livello di colonna, non è necessario modificare le impostazioni query escludendo le colonne a cui l'utente non può accedere. Quando configurare il mascheramento dei dati; le query esistenti mascherano automaticamente i dati della colonna sui ruoli assegnati all'utente.
- Puoi applicare criteri di accesso ai dati su larga scala. Puoi scrivere dati criterio, associalo a un tag di criteri e applicalo a qualsiasi e il numero di colonne.
- Consente il controllo dell'accesso basato su attributi. Un tag di criteri associato a un fornisce l'accesso ai dati contestuali, che è determinato dal criterio dei dati e le entità associate a quel 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:
- Imposta una tassonomia e uno o più tag di criteri.
Configura le norme sui dati per i tag di criteri. Un criterio dei dati mappa un regola di mascheramento dei dati e una o più entità, che che rappresentano utenti o gruppi.
Quando creazione di un criterio dei dati utilizzando la console Google Cloud, crei di mascheramento dei dati e specificare le entità in un solo passaggio. Quando crei un utilizzando l'API BigQuery Data Policy. Tu crei il criterio dei dati. e la regola di mascheramento dei dati in un solo passaggio e specificare le entità in un secondo passaggio.
Assegna i tag di criteri alle colonne delle tabelle BigQuery a e applicare i criteri relativi ai dati.
Assegna gli utenti che devono avere accesso ai dati mascherati al Ruolo Lettore mascherato BigQuery. Come best practice, assegna 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 tutti i criteri dei dati nell'ambito del progetto, il che può causare problemi autorizzazioni in eccesso.
Il tag di criteri associato a un criterio dei dati può essere utilizzata per il controllo dell'accesso a livello di colonna. In questo caso, anche il tag di criteri associati a una o più entità a cui viene concesso Ruolo Lettore granulare Data Catalog. Ciò consente a questi per accedere ai dati della colonna originali, non mascherati.
La figura 2 mostra come funzionano il controllo dell'accesso a livello di colonna e il mascheramento dei dati insieme:
Figura 2. Componenti di mascheramento dei dati.
Per ulteriori informazioni sull'interazione del ruolo, consulta Come interagiscono i ruoli Lettore mascherato e Lettore granulare. Per ulteriori informazioni sull'ereditarietà dei tag di criteri, consulta Gerarchia di ruoli e tag di criteri.
Regole di mascheramento dei dati
Quando utilizzi il mascheramento dei dati, a una colonna in fase di query viene applicata una regola di mascheramento dei dati runtime, in base al ruolo dell'utente che esegue la query. Il mascheramento richiede la precedenza a qualsiasi altra operazione relativa alla 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 un funzione definita dall'utente alla colonna. Le autorizzazioni della routine sono necessarie per gestire la regola di mascheramento. Per impostazione predefinita, questa regola supporta Tipi di dati BigQuery tranne il tipo di dati
STRUCT
. Tuttavia, il supporto per tipi di dati diversi daSTRING
eBYTES
è 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 aver troncato il valore al suo anno, impostando tutte le parti non annuali del valore all'inizio dell'anno. Tu può utilizzare questa regola solo con le colonne che usano gli attributi
DATE
,DATETIME
eTIMESTAMP
tipi di dati. 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 Valore di mascheramento predefinito. Restituisce un valore di mascheramento predefinito per la colonna in base al tipo di dati della colonna. Da utilizzare per nascondere il valore ma rivelano il tipo di dati. Quando questi dati una regola di mascheramento viene applicata a una colonna, la rende meno utile
JOIN
per gli utenti con accesso di tipo 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
STRUCT
tipo di dati, ma possono essere associati a i campi foglia di queste colonne.JSON
null Maschera email. Restituisce il valore della colonna dopo aver sostituito il nome utente di un un indirizzo email valido con
XXXXX
. Se il valore della colonna non è un indirizzo email valido, restituisce il valore della colonna dopo aver esaminato Hash SHA-256 personalizzata. Puoi utilizzare questa regola solo con le colonne che usano l'STRING
tipo di dati. Ad esempio:Originale Mascherato abc123@gmail.com
XXXXX@gmail.com
randomtext
jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
test@gmail@gmail.com
Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=
Primi quattro caratteri. Restituisce i primi 4 caratteri della colonna sostituendo il resto della stringa con
XXXXX
. Se il valore della colonna è uguale o inferiore a 4 caratteri, restituisce il valore dopo che è stato eseguito Hash SHA-256 personalizzata. Puoi utilizzare questa regola solo con le colonne che usano i datiSTRING
di testo.Hash (SHA-256). Restituisce il valore della colonna dopo che è stata eseguita. L'hash SHA-256 personalizzata. Usa questa quando vuoi che l'utente finale possa usare questa colonna in una Operazione
JOIN
per una query. Puoi utilizzare questa regola solo con le colonne che usano l'STRING
oBYTES
tipi di dati.La funzione SHA-256 utilizzata nel mascheramento dei dati preserva il tipo, quindi l'hash restituisce lo stesso tipo di dati del valore della colonna. Ad esempio, il valore hash per un valore di colonna
STRING
ha anche un valore di datiSTRING
di testo.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 a o meno di 4 caratteri, restituisce il valore della colonna dopo che è stato esaminato Hash SHA-256 personalizzata. Puoi utilizzare questa regola solo con le colonne che usano i datiSTRING
di testo.Nullify. Restituisce
NULL
anziché il valore della colonna. Usa questa opzione quando vuoi nascondere sia il valore sia il tipo di dati della colonna. Quando questi dati una regola di mascheramento viene applicata a una colonna, la rende meno utileJOIN
per gli utenti con accesso di tipo Lettore mascherato. Il motivo è cheNULL
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 un a una regola di mascheramento dei dati diversa associata. Uno di questi i criteri sono riservati a impostazioni di controllo dell'accesso a livello di colonna. In questo modo è possibile applicare diversi criteri dei dati a un nella query di un utente, in base ai gruppi di cui l'utente è membro. In questi casi, BigQuery sceglie la regola di mascheramento dei dati da applicare si applicano in base alla seguente gerarchia:
- Routine di mascheramento personalizzata
- Hash (SHA-256)
- Maschera email
- Ultimi quattro caratteri
- Primi quattro caratteri
- Maschera anno della data
- Valore di mascheramento predefinito
- Annulla
Ad esempio, l'utente A fa parte sia dei dipendenti che del reparto contabilità
gruppi. L'utente A esegue una query che include il campo sales_total
, che
ha il tag di criteri confidential
applicato. Il tag di criteri confidential
ha
due criteri dei dati associati: uno con il ruolo di dipendenti
dell'entità e applica la regola di mascheramento dei dati annullabile, nonché una regola che
come entità e applica il mascheramento dei dati hash (SHA-256)
personalizzata. In questo caso, la regola di mascheramento dei dati hash (SHA-256) ha la priorità su
annulla la regola di mascheramento dei dati, in modo che la regola hash (SHA-256) venga applicata
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
Devi avere il ruolo Amministratore tag criteri di Data Catalog per creare e gestire tassonomie e tag di criteri.
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:
|
Ruoli per la creazione e la gestione dei criteri dei dati
Per creare e gestire, devi avere uno dei seguenti ruoli BigQuery norme sui dati:
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 Questo ruolo consente di:
|
datacatalog.taxonomies.get
, che puoi richiedere
molti dei
Ruoli predefiniti di Data Catalog.
Ruoli per collegare tag di criteri alle colonne
Sono necessari datacatalog.taxonomies.get
e bigquery.tables.setCategory
delle autorizzazioni necessarie per collegare tag di criteri alle colonne.
datacatalog.taxonomies.get
è incluso in
Ruoli di amministratore e visualizzatore dei tag di criterio di Data Catalog.
bigquery.tables.setCategory
è incluso in
Amministratore BigQuery (roles/bigquery.admin
) e
Ruoli 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 un 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 che è associato a un criterio dei dati. Inoltre, un utente deve disporre delle autorizzazioni appropriate per eseguire query sulla tabella. Per ulteriori informazioni, vedi 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 lettore mascherato BigQuery che consente di leggere i dati mascherati, alcuni utenti con Ruolo Lettore granulare di Data Catalog che consente per leggere dati non mascherati, alcuni utenti con entrambi e alcuni utenti con nessuno dei due. Questi i ruoli interagiscono nel seguente modo:
- Utente con il ruolo Lettore granulare e Lettore mascherato: cosa vede l'utente dipende da dove nella gerarchia dei tag di criteri viene concesso ciascun ruolo. Per maggiori informazioni le informazioni, vedi Eredità 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,
mascherato, per eseguire un'istruzione SELECT * FROM
su quella tabella,
un utente deve essere membro di gruppi appropriati in modo che gli venga concesso
Lettore mascherato o Lettore granulare in tutte queste colonne.
Un utente a cui non sono stati concessi questi ruoli deve invece specificare solo le colonne che
a cui ha accesso nell'istruzione SELECT
o usa SELECT * EXCEPT
(restricted_columns) FROM
per escludere
per le colonne mascherate.
Eredità di autorizzazione in una gerarchia di tag di criteri
I ruoli vengono valutati a partire dal tag di criteri associato a una colonna. e successivamente controllato a ogni livello crescente della tassonomia, finché l'utente sia determinato che disponga delle autorizzazioni appropriate o che la parte superiore del tag di criteri viene raggiunta la gerarchia.
Ad esempio, considera il tag di criteri e la configurazione del criterio dei dati mostrati 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 sia di ftes@example.com che di analyst@example.com
gruppi. Quando questo utente esegue una query che include la colonna annotata, il suo
l'accesso è determinato dalla gerarchia definita nel
tassonomia dei tag di criteri. Poiché all'utente viene concesso
il ruolo Lettore granulare Data Catalog da Financial
di tag di criteri, la query restituisce i dati della colonna non mascherati.
Se un altro utente
solo un membro del ruolo ftes@example.com esegue una query che include
annotata, la query restituisce i dati della colonna che sono stati sottoposti ad hashing utilizzando
l'algoritmo SHA-256, perché all'utente viene concesso BigQuery
Ruolo Lettore mascherato in base al tag di criteri Confidential
, che è l'elemento padre di
il tag di criteri Financial
.
Un utente che non fa parte di nessuno di questi ai ruoli viene visualizzato un errore di accesso negato se tentano di eseguire query sulla colonna annotata.
A differenza dello scenario precedente, prendi in considerazione il tag di criteri e il criterio dei dati configurazione mostrata nella Figura 5:
Figura 5. Tag di criteri e configurazione dei criteri dei dati.
La situazione è la stessa della Figura 4, ma all'utente viene concesso il il ruolo Lettore granulare a un livello superiore della gerarchia dei tag di criteri. 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 ruolo più in alto nella gerarchia dei tag, perché il servizio utilizza il primo il ruolo assegnato che incontra mentre sale nella gerarchia dei tag di criteri per controllare per l'accesso degli utenti.
Se vuoi creare un'unica norma relativa ai dati e applicarla a più livelli di una gerarchia di tag di criteri, puoi impostare i criteri dei dati nel tag di criteri che rappresenta il livello gerarchico più alto a cui deve essere applicata. Ad esempio: prendere una tassonomia con la seguente struttura:
- Tag criterio 1
- Tag criterio 1a
- Tag criterio 1ai
- Tag criterio 1b
- Tag criterio 1bi
- Tag criterio 1bii
- Tag criterio 1a
Se vuoi che un criterio dei dati venga applicato a tutti questi tag di criteri, imposta i dati sul tag di criteri 1. Se vuoi che un criterio dei dati venga applicato al tag di criteri 1b e impostare i criteri dei 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 solo l'accesso 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
.
un utente membro del gruppo analyst@example.com. Quando questo utente prova
per accedere alla colonna annotata attraverso una delle funzioni incompatibili,
ricevi un errore di accesso negato. Questo perché viene concesso loro
Lettore mascherato BigQuery per tag di criteri Financial
, ma in questo
nel caso specifico, devono avere il ruolo Lettore granulare 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 vedere come tag, entità e ruoli funzionano insieme, considera quanto segue: esempio.
Su example.com, l'accesso di base viene concesso tramite data-users@example.com gruppo. Tutti i dipendenti che hanno bisogno di accedere regolarmente ai dati di 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 maschere di colonne dove questo è richiesto per il loro lavoro. Tutti i membri di questi altri gruppi sono anche membri di data-users@example.com. 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,
SELECT * FROM Accounts;
conduce a
seguenti risultati per i diversi gruppi:
data-users@example.com: a questo gruppo è stato concesso il Ruolo Lettore mascherato BigQuery sia in
PII
che inConfidential
i tag di criteri. 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 accounting@example.com: a questo gruppo è stato concesso il Ruolo Lettore granulare Data Catalog in
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 sales-exec@example.com: a questo gruppo è stato concesso il Ruolo Lettore granulare Data Catalog in
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 fin-dev@example.com: a questo gruppo è stata concessa la classe Ruolo Lettore mascherato BigQuery in
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 degli elenchi elencati ai gruppi viene visualizzato un errore di accesso negato perché non è stato concesso loro Lettore granulare o Ruoli di lettura mascherati BigQuery. Per eseguire query sul
Accounts
, devono invece specificare solo le colonne a cui hanno accesso nelSELECT * EXCEPT (restricted_columns) FROM Accounts
per escludere con colonne protette o mascherate.
Considerazioni sui costi
Il mascheramento dei dati può influire indirettamente sul numero di byte elaborati. influisce quindi sul costo della query. Se un utente esegue una query su una colonna mascherato con le regole di mascheramento o annullamento 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 alcune versioni di BigQuery. Per ulteriori informazioni quali funzioni sono 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 i criteri sono riservati a impostazioni di controllo dell'accesso a livello di colonna.
- Criteri relativi ai dati, relativi tag di criteri associati ed eventuali routine che li utilizzano devono trovarsi 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 può trovarsi al massimo a cinque livelli di profondità dal nodo principale al sottotag di livello più basso, come mostrato nello screenshot seguente:
Imposta il controllo dell'accesso
Dopo che una tassonomia ha un criterio dei dati associato ad almeno uno dei suoi criteri tag, controllo dell'accesso viene applicata automaticamente. Se vuoi disattivare il controllo dell'accesso, devi eliminare prima tutti i criteri dei dati associati alla tassonomia.
Viste materializzate e query di mascheramento dei record ripetute
Se esistono già viste materializzate, le query di mascheramento dei record ripetute sulla tabella di base associata non riesce. Per risolvere il problema, elimina il vista materializzata. Se la vista materializzata è necessaria per altri motivi, possono crearlo in un altro set di dati.
Query su colonne mascherate nelle tabelle partizionate
Query che includono il mascheramento dei dati nelle istanze partizionate o in cluster le colonne 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
Tipi di dati BigQuery
tranne
STRUCT
, perché il mascheramento dei dati può essere applicato solo ai campi foglia del tipo di datiSTRUCT
. - L'eliminazione di una routine di mascheramento personalizzata non elimina tutti i criteri dei dati che utilizzano
li annotino. Tuttavia, i criteri relativi ai dati che utilizzano la routine di mascheramento eliminata vengono lasciati
con una regola di mascheramento vuota. Utenti con il ruolo Lettore mascherato per altri dati
i criteri con lo stesso tag possono vedere i dati mascherati. Altre persone vedono il messaggio
Permission denied.
I riferimenti pendenti a regole di mascheramento vuote possono essere vengono ripulite da processi automatizzati dopo sette giorni.
Compatibilità con altre funzionalità di BigQuery
API BigQuery
Non compatibile con
tabledata.list
. A
chiama tabledata.list
, devi avere l'accesso completo a tutte le colonne restituite
questo metodo. Le concessioni del ruolo Lettore granulare Data Catalog
l'accesso appropriato.
Tavoli BigLake
Compatibile. I criteri di mascheramento dei dati vengono applicati su BigLake tabelle.
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 un mascheramento dei dati attivo non vengono accelerate e BI Engine. L'utilizzo di queste query in Looker Studio potrebbe possono rallentare e rendere più costosi i report o le dashboard correlati.
BigQuery Omni
Compatibile. I criteri di mascheramento dei dati vengono applicati 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: per avere accesso completo a tutte le colonne della tabella di origine. La 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 disponi di Data Catalog nel ruolo Lettore granulare, 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
è presente un criterio di accesso alle righe applicato a location = "US"
e location
è
vengono mascherati, gli utenti possono vedere le righe in cui location = "US"
ma
il campo della località è mascherato.
Cerca in BigQuery
Parzialmente compatibile. Puoi chiamare il
SEARCH
funzione 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,
è necessario utilizzare criteri di ricerca compatibili con il proprio livello di accesso. Ad esempio:
Se disponi dell'accesso Masked Reader con una regola di mascheramento dei dati Hash (SHA-256),
userebbe il valore hash nella clausola SEARCH
, simile al seguente:
SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");
Se disponi dell'accesso granulare, utilizzerai la colonna effettiva.
nella clausola SEARCH
, simile al seguente:
SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "jane.doe@example.com");
La ricerca ha meno probabilità di essere utile se hai
Accesso di lettura 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 NULL
o ""
, non sono sufficientemente univoci per essere
utile.
Durante la ricerca in una colonna indicizzata contenente dati mascherato, l'indice di ricerca viene utilizzato solo se disponi di Lettore granulare l'accesso alla colonna.
Snapshot
Non compatibile. Per creare lo snapshot di una tabella, devi disporre dell'accesso completo a tutti i nelle colonne della tabella di origine. L'analisi dettagliata di Data Catalog Il ruolo Lettore concede l'accesso appropriato.
Ridenominazione delle tabelle
Compatibile. La ridenominazione delle tabelle non è interessata dal mascheramento dei dati.
Viaggio nel tempo
Compatibile con entrambi
decoratori del tempo e
FOR SYSTEM_TIME AS OF
nelle istruzioni SELECT
. I tag di criteri per lo schema del set di dati attuale
vengono applicate 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 le modifiche vengono ai dati o allo schema della tabella prima di allora. Nella seguente circostanza, è possibile che un utente che non ha Il ruolo Lettore granulare Data Catalog concesso per una colonna può ma continueranno a vedere i dati della colonna quando eseguono una query:
- A un utente è stato concesso il lettore granulare di Data Catalog in una colonna.
- L'utente esegue una query che include la colonna con restrizioni e i dati vengono memorizzati nella cache.
- Entro 24 ore dal passaggio 2, all'utente viene concesso Lettore mascherato e ha il Lettore granulare Data Catalog è stato revocato.
- Entro 24 ore dal passaggio 2, l'utente esegue la stessa query e vengono restituiti i dati.
Query tabella con caratteri jolly
Non compatibile. Devi disporre dell'accesso completo a tutte le colonne di riferimento in tutti le tabelle corrispondenti alla query con caratteri jolly. Data Catalog Il ruolo Lettore granulare concede l'accesso appropriato.
Passaggi successivi
- Ricevi istruzioni dettagliate per attivare mascheramento dei dati.