Utilizzare la sicurezza a livello di riga con altre funzionalità di BigQuery
Questo documento descrive come utilizzare la sicurezza dell'accesso a livello di riga con altre funzionalità di BigQuery.
Prima di leggere questo documento, per acquisire familiarità con la sicurezza a livello di riga consulta gli articoli Introduzione alla sicurezza a livello di riga di BigQuery e Utilizzo della sicurezza a livello di riga.
Il filtro TRUE
I criteri di accesso a livello di riga possono filtrare i dati dei risultati che vengono visualizzati durante l'esecuzione delle query. Per eseguire operazioni non basate su query, ad esempio DML, devi disporre dell'accesso completo a tutte le righe della tabella. L'accesso completo viene concesso utilizzando un criterio di accesso alle righe con l'espressione di filtro impostata su TRUE
. Questo criterio di accesso a livello di riga è chiamato filtro TRUE
.
A qualsiasi utente può essere concesso l'accesso al filtro TRUE
, incluso un account di servizio.
Esempi di operazioni non basate su query:
- Altre API BigQuery, come l'API BigQuery Storage Read.
- Alcuni comandi dello strumento a riga di comando
bq
, come il comandobq head
. - Copia di 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 contenente uno o più criteri di accesso a livello di riga, devi prima disporre dell'accesso TRUE
ai filtri nella tabella di origine. Nella nuova tabella di destinazione vengono copiati anche tutti i criteri di accesso a livello di riga nella tabella di origine. Se copi una tabella di origine senza criteri di accesso a livello di riga in una tabella di destinazione che dispone di criteri di accesso a livello di riga, questi vengono rimossi dalla tabella di destinazione, a meno che non venga utilizzato il flag --append_table
o non sia impostato "writeDisposition": "WRITE_APPEND"
.
Le copie tra regioni sono consentite e tutti i criteri vengono copiati. Le query successive potrebbero non funzionare al termine della copia se contengono riferimenti alla tabella non validi nei criteri delle sottoquery.
I criteri di accesso a livello di riga in una tabella devono avere nomi univoci. Un conflitto nei nomi dei criteri di accesso a livello di riga durante la copia genera un errore di 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 alle 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
Devi disporre dell'accesso con filtro TRUE
per utilizzare il metodo tabledata.list
nell'API BigQuery su una tabella con criteri di accesso a livello di riga.
DML
Per eseguire un'istruzione DML che aggiorni una tabella che dispone di criteri di 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 disporre di
TRUE
accesso ai filtri per la tabella di destinazione. - Se una tabella di origine contiene criteri di accesso a livello di riga, l'istruzione
MERGE
agisce solo sulle righe visibili all'utente.
Snapshot tabella
Gli snapshot delle tabelle supportano la 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 descritte in Autorizzazioni richieste per copiare una tabella con un criterio di accesso a livello di riga.
Lo spostamento nel tempo non è supportato per le tabelle di base con uno o più criteri di sicurezza a livello di riga.
Tabella BigQuery con colonne JSON
I criteri di accesso a livello di riga non possono essere applicati alle colonne JSON. Per scoprire di più sulle limitazioni della sicurezza a livello di riga, consulta Limitazioni.
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
La sicurezza a livello di riga e di colonna, che include sia il controllo dell'accesso a livello di colonna sia il 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 in quella colonna.
- I tentativi di accedere a queste colonne con il criterio di accesso a livello di riga della sottoquery generano un errore che indica che l'accesso è negato. Queste colonne non sono considerate colonne con riferimento al sistema.
- I tentativi di accedere a queste colonne con il criterio di accesso a livello di riga non sottoquery ignorano la sicurezza a livello di colonna.
- Se la colonna è limitata a causa della sicurezza a livello di colonna e ha un nome nell'istruzione
SELECT
o nei criteri di accesso a livello di riga della query, viene visualizzato un errore. - La sicurezza a livello di colonna si applica anche con un'istruzione di query
SELECT *
.SELECT *
viene considerato come una query che nomina esplicitamente una colonna con restrizioni.
Esempio di interazione di sicurezza a livello di riga e di sicurezza a livello di colonna
Questo esempio illustra i passaggi per proteggere una tabella ed eseguire 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 | frutta | colore |
---|---|---|
1 | apple | red |
2 | orange | orange |
3 | limone | di colore giallo |
4 | limetta | verde |
La sicurezza
Vuoi che Alice possa vedere tutte le righe che contengono numeri dispari nella
colonna rank
, ma non le righe dispari. Non vuoi che Mario veda righe
pari o dispari. Non vuoi che nessuno veda dati nella colonna fruit
.
Per impedire ad Alice di visualizzare le righe con numero pari, crea un criterio di accesso a livello di riga con un'espressione di filtro basata sui dati visualizzati nella colonna
rank
. Per evitare che Roberto visualizzi righe pari o dispari, non includerlo 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
, crea un tag di criteri di sicurezza a livello di colonna che impedisce a tutti gli utenti di accedere ai suoi dati.
Infine, limiti anche l'accesso alla colonna denominata color
in due modi: la colonna è regolata entrambi da un tag di criteri di sicurezza a livello di colonna che vieta l'accesso a chiunque, ed è interessata da un criterio di accesso a livello di riga, che filtra alcuni dati della riga nella colonna color
.
Questo secondo criterio di accesso a livello di riga mostra solo le righe con il 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 una query sui dati di my_dataset.my_table
, non vede alcuna riga perché non è nell'elenco dei beneficiari di nessun criterio di accesso a livello di riga 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 di criteri 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, questa query ha esito positivo, ma non vengono restituiti dati di riga. Mostra a Roberto un messaggio che informa che i suoi risultati potrebbero essere filtrati in base al criterio di accesso alle righe. |
Query di Alice
Quando Alice esegue query per accedere ai dati di my_dataset.my_table
, i suoi 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 di criteri 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 ) |
||
|
(2) Vengono restituite le righe con numero dispari. |
Alice è nell'elenco dei beneficiari del criterio di accesso a livello di riga only_odd sui dati nella colonna Ranking. Pertanto, Alice vede
solo i dati delle righe con numero dispari. Le righe con numero pari sono nascoste dal criterio di accesso a livello di riga denominato only_odd . Alice mostra un messaggio che informa che i suoi risultati potrebbero essere filtrati in base al criterio di accesso alle righe. |
||
|
|
La colonna fruit è stata denominata in modo esplicito nella query. Viene applicata la sicurezza a livello di colonna. Accesso negato. |
||
|
|
La colonna color è stata denominata in modo esplicito nella query. La sicurezza a livello di colonna viene applicata, prima che venga applicato il criterio di accesso a livello di riga sui dati nella colonna color .Accesso negato. |
||
|
|
La colonna "fruit " è stata denominata in modo esplicito nella query. La sicurezza a livello di colonna viene applicata, prima che venga applicato il criterio di accesso a livello di riga sui dati nella colonna rank .Accesso negato. |
||
|
|
La colonna color è stata denominata in modo esplicito nella queryLa sicurezza a livello di colonna nella colonna color viene applicata prima che vengano applicati i criteri di accesso a livello di riga ai dati nelle colonne rank e color . Accesso negato. |
||
|
|
|
Le colonne fruit e color sono state
assegnate in modo esplicito alla query. Prima che venga applicato il criterio di accesso a livello di riga per i dati nella colonna color , viene applicata la sicurezza a livello di colonna nelle colonne fruit e color .Accesso negato. |
|
|
|
|
Le colonne fruit e color sono state assegnate implicitamente
utilizzando "SELECT * " nella query. La sicurezza a livello di colonna nelle colonne fruit e color viene applicata, prima che vengano applicati i criteri di accesso a livello di riga sui dati nelle colonne rank o color .
Accesso negato. |
Accesso filtro TRUE
Infine, come spiegato nella sezione relativa all'accesso ai filtri TRUE
, se Alice o Roberto dispone dell'accesso al filtro TRUE
, possono visualizzare tutte le righe della tabella e utilizzarle nei job che non riguardano query. Tuttavia, se la tabella ha una sicurezza a livello di colonna, viene comunque applicata e può influire sui risultati.
Estrai job
Se una tabella dispone di criteri di accesso a livello di riga, quando esegui un job di estrazione vengono esportati solo i dati che puoi visualizzare in Cloud Storage.
SQL precedente
I criteri di accesso a livello di riga non sono compatibili con l'SQL precedente. Le query sopra le tabelle con criteri di accesso a livello di riga devono utilizzare GoogleSQL. Le query SQL legacy sono state rifiutate.
Tabelle partizionate e in cluster
La sicurezza a livello di riga non partecipa all'eliminazione delle query, che è una funzionalità delle tabelle partizionate.
Sebbene la sicurezza a livello di riga sia compatibile con le tabelle partizionate e in cluster, i criteri di accesso a livello di riga che filtrano i dati delle righe non vengono applicati durante l'eliminazione delle partizioni. Puoi comunque utilizzare l'eliminazione delle partizioni su una tabella che utilizza la sicurezza a livello di riga specificando una clausola WHERE
che opera sulla colonna di partizione. Allo stesso modo, i criteri di accesso a livello di riga non creano vantaggi in termini di prestazioni per le query sulle tabelle in cluster, ma non interferiscono con gli altri filtri applicati.
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 uno o più criteri di accesso alle righe. Puoi rinominare una tabella con un'istruzione DDL.
In alternativa, puoi anche copiare una tabella e assegnare un nome diverso alla tabella di destinazione. Se la tabella di origine include un criterio di accesso a livello di riga, consulta i job di copia della tabella in questa pagina per ulteriori informazioni.
Aggiornamenti sullo streaming
Per eseguire operazioni sulla tabella di inserimento di flussi UPDATE
o DELETE
con Change Data Capture, devi avere accesso al filtro TRUE
.
Viaggio nel tempo
Solo un amministratore della tabella può accedere ai dati storici per una tabella che dispone o ha avuto in precedenza criteri di accesso a livello di riga. Gli altri utenti ricevono un errore access
denied
se utilizzano un decorator dei viaggi nel tempo su una tabella che dispone dell'accesso a livello di riga. Per ulteriori informazioni, consulta Viaggio nel tempo e accesso a livello di riga.
Viste e viste materializzate
I dati mostrati in una vista o in una vista materializzata vengono filtrati in base ai criteri di accesso a livello di riga della tabella di origine sottostante.
Inoltre, quando una vista materializzata viene derivata da una tabella sottostante che dispone di criteri di accesso a livello di riga, le prestazioni della query sono le stesse di quelle quando si esegue una query direttamente sulla tabella di origine. In altre parole, se la tabella di origine ha una sicurezza a livello di riga, non vedrai 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
Le query con caratteri jolly su tabelle con criteri di accesso a livello di riga non vanno a buon fine e viene restituito 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.