Utilizzo della sicurezza a livello di riga con altre funzionalità di BigQuery
Questo documento descrive come utilizzare la sicurezza dell'accesso a livello di riga con altri Funzionalità di BigQuery.
Prima di leggere questo documento, acquisisci familiarità con la sicurezza a livello di riga leggendo Introduzione alla sicurezza a livello di riga di BigQuery e Utilizzo della sicurezza a livello di riga.
Filtro TRUE
I criteri di accesso a livello di riga possono filtrare i dati dei risultati visualizzati durante l'esecuzione
query. Per eseguire operazioni diverse dalle query, come la DML, è necessario avere accesso completo a tutte le righe della tabella. Accesso completo concesso
utilizzando un criterio di accesso alle righe con l'espressione di filtro impostata su TRUE
. Questo
il criterio di accesso a livello di riga è chiamato filtro TRUE
.
A qualsiasi utente può essere concesso l'accesso ai filtri TRUE
, incluso un account di servizio.
Ecco alcuni esempi di operazioni non di query:
- Altre API BigQuery, come l'API BigQuery Storage Read.
- Alcune
i comandi dello strumento a riga di comando
bq
, comebq head
. - Copiare una tabella
Esempio
Crea il filtro TRUE
CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);
Funzionalità compatibili con il filtro TRUE
Job di copia
Per copiare una tabella con uno o più criteri di accesso a livello di riga, devi prima disporre dell'accesso ai filtri TRUE
sulla tabella di origine. Anche tutti i criteri di accesso a livello di riga nella tabella di origine vengono copiati nella nuova tabella di destinazione. Se copi una tabella di origine senza
criteri di accesso a livello di riga su una tabella di destinazione con livello di riga
criteri di accesso,
i criteri di accesso a livello di riga
vengono rimossi dalla tabella di destinazione.
a meno che non venga usato il flag --append_table
o "writeDisposition": "WRITE_APPEND"
è impostata.
Sono consentite copie tra regioni e tutti i criteri vengono copiati. Query successive potrebbe non funzionare al termine della copia se le query contengono una tabella non valida nei criteri delle sottoquery.
I criteri di accesso a livello di riga in una tabella devono avere nomi univoci. Si è verificata una collisione i nomi dei criteri di accesso a livello di riga durante la copia restituiscono un input non valido .
Autorizzazioni richieste per copiare una tabella con un criterio di accesso a livello di riga
Per copiare una tabella con uno o più criteri di accesso a livello di riga: devi disporre delle seguenti autorizzazioni, oltre alla autorizzazioni necessarie per copiare una tabella senza un criterio di accesso a livello di riga.
Autorizzazione | Risorsa |
---|---|
bigquery.rowAccessPolicies.list
|
La tabella di origine. |
bigquery.rowAccessPolicies.getIamPolicy
|
La tabella di origine. |
Il filtro TRUE
|
La tabella di origine. |
bigquery.rowAccessPolicies.create
|
La tabella di destinazione. |
bigquery.rowAccessPolicies.setIamPolicy
|
La tabella di destinazione. |
Tabledata.list nell'API BigQuery
Per utilizzare il metodo tabledata.list
nell'API BigQuery su una tabella con criteri di accesso a livello di riga, devi disporre dell'accesso ai filtri TRUE
.
DML
Eseguire un'istruzione DML che aggiorna una tabella con accesso a livello di riga
devi disporre dell'accesso ai filtri TRUE
per la tabella.
In particolare, le istruzioni MERGE
interagiscono con i criteri di accesso a livello di riga come segue:
- Se una tabella di destinazione contiene criteri di accesso a livello di riga, devi
TRUE
accesso al filtro alla tabella di destinazione. - Se una tabella di origine contiene criteri di accesso a livello di riga,
MERGE
agisce solo sulle righe visibili all'utente.
Snapshot tabella
Supporto per gli snapshot delle tabelle sicurezza a livello di riga. Le autorizzazioni necessarie per la tabella di base (tabella di origine) e lo snapshot della tabella (tabella di destinazione) sono descritti in Autorizzazioni necessarie per copiare una tabella con un criterio di accesso a livello di riga.
Tabella BigQuery con colonne JSON
I criteri di accesso a livello di riga non possono essere applicati nelle colonne JSON. Per scoprire di più sulle limitazioni della sicurezza a livello di riga, consulta Limiti.
BigQuery BI Engine e Looker Studio
BigQuery BI Engine non accelera le query eseguite su tabelle con uno o più criteri di accesso a livello di riga. Queste query vengono eseguite come query standard in BigQuery.
I dati in una dashboard di Looker Studio vengono filtrati in base ai criteri di accesso a livello di riga della tabella di origine sottostante.
Sicurezza a livello di colonna
Sicurezza a livello di riga e sicurezza a livello di colonna, che include sia controllo dell'accesso a livello di colonna e mascheramento dinamico dei dati, sono completamente compatibili.
I punti chiave sono:
- Puoi applicare un criterio di accesso a livello di riga per filtrare i dati in qualsiasi colonna, anche
se non hai accesso ai dati di quella colonna.
- Tenta di accedere a queste colonne con il criterio di accesso a livello di riga della sottoquery restituisce un errore che indica che l'accesso è stato negato. Queste colonne non sono considerate colonne riferite al sistema.
- Tenta di accedere a queste colonne con il criterio di accesso a livello di riga non di sottoquery per bypassare la sicurezza a livello di colonna.
- Se la colonna è limitata per via della sicurezza a livello di colonna e viene
denominato nei criteri di accesso a livello di riga dell'istruzione
SELECT
o della sottoquery, ricevi un messaggio di errore. - La sicurezza a livello di colonna si applica anche con un'istruzione di query
SELECT *
.SELECT *
viene trattato come una query che nomina esplicitamente una colonna con limitazioni.
Esempio di interazione di sicurezza a livello di riga e di sicurezza a livello di colonna
Questo esempio illustra la procedura per proteggere un tavolo eseguendo una query.
I dati
Supponi di avere il ruolo DataOwner per un set di dati denominato
my_dataset
che include una tabella con tre colonne, denominata my_table
.
La tabella contiene i dati riportati nella seguente tabella.
In questo esempio, un utente è Alice, il cui indirizzo email è
alice@example.com
. Un secondo utente è Bob, un collega di Alice.
rank | frutto | colore |
---|---|---|
1 | apple | red |
2 | orange | orange |
3 | limone | giallo |
4 | limetta | verde |
La sicurezza
Vuoi che Alice possa vedere tutte le righe con numeri dispari nella colonnarank
, ma non le righe con numeri pari. Non vuoi che Mario veda righe,
pari o dispari. Non vuoi che nessuno veda i dati nella colonna fruit
.
Per impedire ad Alice di vedere le righe con numeri pari, crea una il criterio di accesso a livello di riga che ha un'espressione di filtro basata sui dati visualizzato nella colonna
rank
. Per evitare che Bob veda elementi pari o dispari righe, non lo includi nell'elenco dei beneficiari.CREATE ROW ACCESS POLICY only_odd ON my_dataset.my_table GRANT TO ('user:alice@example.com') FILTER USING (MOD(rank, 2) = 1);
Per impedire a tutti gli utenti di visualizzare i dati nella colonna denominata
fruit
: crei un tag di criteri di sicurezza a livello di colonna che impedisce a tutti gli utenti di accederà a uno qualsiasi dei suoi dati.
Infine, limiti anche l'accesso alla colonna denominata color
in due modi:
la colonna è regolata sia da un tag criterio di sicurezza a livello di colonna che vieta
l'accesso a chiunque, e è interessata da un criterio di accesso a livello di riga, che
filtra alcuni dei dati di riga nella colonna color
.
Questo secondo criterio di accesso a livello di riga mostra solo le righe con valore
green
nella colonnacolor
.CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table GRANT TO ('user:alice@example.com') FILTER USING (color="green");
Query di Roberto
Se Roberto, un collega di Alice, tenta di eseguire query sui dati di my_dataset.my_table
,
non vede righe perché Roberto non è nell'elenco dei beneficiari per nessuna riga a livello di riga
di accesso al criterio di accesso
nella tabella.
Query | my_dataset.my_table
|
Commenti | ||
---|---|---|---|---|
rank Alcuni dati sono interessati dal criterio di accesso alle righe only_odd ) |
fruit (tutti i dati sono protetti da un tag criterio CLS) |
color (tutti i dati sono protetti da un tag di criteri CLS e alcuni dati sono interessati dal criterio di accesso alle righe only_green ) |
||
SELECT rank FROM my_dataset.my_table
|
(0) righe restituite. |
Roberto non è nell'elenco dei beneficiari del criterio di accesso a livello di riga;
pertanto la query ha esito positivo, ma non vengono restituiti dati di riga. Viene mostrato un messaggio a Roberto che informa che i suoi risultati potrebbero essere filtrati in base a il criterio di accesso alle righe. |
Query di Alice
Quando Alice esegue query per accedere ai dati di my_dataset.my_table
, i risultati dipendono dalla query eseguita e dalla sicurezza, come mostrato nella tabella seguente.
Query | my_dataset.my_table
|
Commenti | ||
---|---|---|---|---|
rank Alcuni dati sono interessati dal criterio di accesso alle righe only_odd ) |
fruit (tutti i dati sono protetti da un tag criterio CLS) |
color Tutti i dati sono protetti da un tag di criteri CLS e alcuni sono interessati. dal criterio di accesso alle righe only_green ). |
||
|
(2) vengono restituite righe dispari. |
Alice è nell'elenco dei beneficiari per il criterio di accesso a livello di riga only_odd
relativo ai dati nella colonna ranking. Di conseguenza, Alice vede
solo i dati delle righe dispari. Le righe con numeri pari sono nascoste dal
criterio di accesso a livello di riga denominato only_odd . Alice viene mostrato un messaggio che indica che i suoi risultati potrebbero essere filtrati dal criterio di accesso alle righe. |
||
|
|
Alla colonna fruit è stato assegnato un nome esplicito nella query. Viene applicata la sicurezza a livello di colonna. Accesso negato. |
||
|
|
Alla colonna color è stato assegnato un nome esplicito nella query. La sicurezza a livello di colonna si applica prima del criterio di accesso a livello di riga ai dati nella colonna color è coinvolto.Accesso negato. |
||
|
|
La colonna "fruit " è stata denominata esplicitamente nella query. La sicurezza a livello di colonna si applica prima del criterio di accesso a livello di riga ai dati nella colonna rank è coinvolto.Accesso negato. |
||
|
|
La colonna color è stata denominata esplicitamente nella queryLa sicurezza a livello di colonna nella colonna color viene applicata prima che i criteri di accesso a livello di riga per i dati nelle colonne rank e color vengano attivati. Accesso negato. |
||
|
|
|
Le colonne fruit e color erano esplicitamente
denominato nella query. La sicurezza a livello di colonna in fruit e
color colonne, prima del criterio di accesso a livello di riga su
dati nella colonna color sono coinvolti.Accesso negato. |
|
|
|
|
Le colonne fruit e color erano implicitamente
denominato utilizzando "SELECT * " nella query. La sicurezza a livello di colonna in fruit e
Si applicano color colonne prima dei criteri di accesso a livello di riga
dei dati nelle colonne rank o color sono coinvolti.
Accesso negato. |
Accesso al filtro TRUE
Infine, come spiegato in
la sezione sull'accesso ai filtri TRUE
,
Se Alice o Bob hanno accesso ai filtri TRUE
, possono
vedere tutte le righe della tabella e utilizzarlo in job non di query. Tuttavia, se
tabella ha una sicurezza a livello di colonna, viene comunque applicata e può influire
che consentono di analizzare i dati
e visualizzare i risultati.
Job di estrazione
Se una tabella include criteri di accesso a livello di riga, vengono utilizzati solo i dati che puoi viene esportata in a Cloud Storage quando esegui un job di estrazione.
SQL precedente
I criteri di accesso a livello di riga non sono compatibili con la versione precedente di SQL. Query superiori a le tabelle con criteri di accesso a livello di riga devono utilizzare GoogleSQL. Le query SQL legacy vengono rifiutate.
Tabelle partizionate e in cluster
La sicurezza a livello di riga non partecipa alla query potatura, una funzionalità di tabelle partizionate.
Sebbene la sicurezza a livello di riga sia compatibile con le istanze partizionate e in cluster,
tabelle, i criteri di accesso a livello di riga che filtrano i dati delle righe non vengono applicati
durante l'eliminazione della partizione. Puoi comunque usare l'eliminazione delle partizioni su una tabella
che utilizza la sicurezza a livello di riga specificando una clausola WHERE
che funziona
nella colonna di partizione. Analogamente, i criteri di accesso
a livello di riga
che non apportano vantaggi in termini di prestazioni
per le query sulle tabelle in cluster,
ma non interferiscono con gli altri filtri che applichi.
L'eliminazione delle query viene eseguita durante l'esecuzione dei criteri di accesso a livello di riga utilizzando i filtri con i criteri.
Rinominare una tabella
Non è necessario l'accesso al filtro TRUE
per rinominare una tabella con accesso a una o più righe
criteri su di esso. Puoi
rinominare una tabella con un'istruzione DDL.
In alternativa, puoi anche copiare una tabella e assegnare alla tabella di destinazione un nome diverso. Se la tabella di origine include un criterio di accesso a livello di riga, consulta job di copia di tabelle in questa pagina per ulteriori informazioni.
Aggiornamenti in streaming
Per eseguire operazioni UPDATE
o DELETE
della tabella di flusso con Change Data Capture, devi disporre dell'accesso ai filtri TRUE
.
Viaggio nel tempo
Solo un amministratore della tabella può accedere ai dati storici di una tabella che ha o ha avuto in precedenza criteri di accesso a livello di riga. Gli altri utenti ricevono un errore access
denied
se utilizzano un decoratore di viaggi nel tempo su una tabella con
a livello di riga. Per ulteriori informazioni, consulta Spostamento nel tempo e livello di riga
l'accesso alle app.
Viste e viste materializzate
I dati visualizzati in una vista o in una vista materializzata vengono filtrati in base alla i criteri di accesso a livello di riga per la tabella di origine sottostante.
Inoltre, quando una vista materializzata deriva da una tabella sottostante con criteri di accesso a livello di riga, le prestazioni delle query sono le stesse di quando esegui una query sull'origine direttamente dalla tabella. In altre parole, se la tabella di origine prevede una sicurezza a livello di riga, non vedo i tipici vantaggi in termini di prestazioni dell'esecuzione di query su una vista materializzata rispetto all'esecuzione di query sulla tabella di origine.
Non puoi fare riferimento a viste o viste materializzate nei criteri di accesso a livello di riga.
Query con caratteri jolly
Query con caratteri jolly rispetto a
le tabelle con criteri di accesso a livello di riga hanno esito negativo con un errore INVALID_INPUT
.
Passaggi successivi
- Per informazioni sulle best practice per i criteri di accesso a livello di riga, consulta Best practice per la sicurezza a livello di riga in BigQuery.