Utilizzo della sicurezza a livello di riga con altre funzionalità di BigQuery

Questo documento descrive come utilizzare la sicurezza di accesso a livello di riga con altre funzionalità di BigQuery.

Prima di leggere questo documento, familiarizza 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.

Il filtro TRUE

Le policy di accesso a livello di riga possono filtrare i dati dei risultati visualizzati durante l'esecuzione delle query. Per eseguire operazioni non di query, come DML, devi disporre dell'accesso completo a tutte le righe della tabella. L'accesso completo viene concesso utilizzando una policy di accesso alle righe con l'espressione di filtro impostata su TRUE. Questa policy di accesso a livello di riga è chiamata filtro TRUE.

A qualsiasi utente, incluso un account di servizio, può essere concesso l'accesso al filtro TRUE.

Ecco alcuni esempi di operazioni non di query:

Esempio di filtro TRUE

CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);

Funzionalità che funzionano con il filtro TRUE

Quando utilizzi un'operazione DML su una tabella protetta da policy di accesso alle righe, devi utilizzare un filtro TRUE che implica l'accesso all'intera tabella. Le operazioni che non modificano lo schema della tabella mantengono le policy di accesso alle righe nella tabella.

Ad esempio, l'istruzione ALTER TABLE RENAME TO copia le policy di accesso alle righe dalla tabella originale alla nuova tabella. Un altro esempio è l'TRUNCATE TABLE istruzione che rimuove tutte le righe da una tabella, ma mantiene lo schema della tabella e le policy di accesso alle righe.

Job di copia

Per copiare una tabella con una o più policy di accesso a livello di riga, devi prima disporre dell'accesso al filtro TRUE nella tabella di origine. Tutte le policy di accesso a livello di riga nella tabella di origine vengono copiate anche nella nuova tabella di destinazione. Se copi una tabella di origine senza policy di accesso a livello di riga in una tabella di destinazione che le ha, le policy di accesso a livello di riga vengono rimosse dalla tabella di destinazione, a meno che non venga utilizzato il flag --append_table o non sia impostato "writeDisposition": "WRITE_APPEND".

Sono consentite le copie tra regioni e tutte le policy vengono copiate. Le query successive potrebbero non funzionare dopo il completamento della copia se contengono riferimenti a tabelle non validi nelle policy delle sottoquery.

Le policy di accesso a livello di riga in una tabella devono avere nomi univoci. Una collisione nei nomi delle policy di accesso a livello di riga durante la copia genera un errore di input non valido.

Autorizzazioni richieste per copiare una tabella con una policy di accesso a livello di riga

Per copiare una tabella con una o più policy di accesso a livello di riga, devi disporre delle seguenti autorizzazioni, oltre ai ruoli per copiare tabelle e partizioni.

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 TRUE nell'API BigQuery su una tabella con criteri di accesso a livello di riga, devi disporre dell'accesso ai filtri tabledata.list.

DML

Per eseguire un'istruzione DML che aggiorna una tabella con policy di accesso a livello di riga, devi disporre dell'accesso al filtro TRUE per la tabella.

In particolare, le istruzioni MERGE interagiscono con le policy di accesso a livello di riga nel seguente modo:

  • Se una tabella di destinazione contiene policy di accesso a livello di riga, devi disporre dell'accesso al filtro TRUE per la tabella di destinazione.
  • Se una tabella di origine contiene policy 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 una policy di accesso a livello di riga.

Tabella BigQuery con colonne JSON

Le policy di accesso a livello di riga non possono essere applicate alle colonne JSON. Per saperne di più sulle limitazioni della sicurezza a livello di riga, consulta Limitazioni.

BigQuery BI Engine e Data Studio

BigQuery BI Engine non accelera le query eseguite su tabelle con una o più policy di accesso a livello di riga; queste query vengono eseguite come query standard in BigQuery.

I dati in una dashboard di Data Studio vengono filtrati in base alle policy di accesso a livello di riga della tabella di origine sottostante.

Sicurezza a livello di colonna

La sicurezza a livello di riga e la sicurezza a livello 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 una policy 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 la policy di accesso a livello di riga della sottoquery generano un errore che indica che l'accesso è negato. Queste colonne non sono considerate colonne con riferimenti di sistema.
    • I tentativi di accedere a queste colonne con la policy di accesso a livello di riga non di sottoquery ignorano la sicurezza a livello di colonna.
  • Se la colonna è limitata a causa della sicurezza a livello di colonna e la colonna è denominata nell'istruzione SELECT della query o nelle policy di accesso a livello di riga della sottoquery, ricevi un errore.
  • La sicurezza a livello di colonna si applica anche con un'istruzione di query SELECT *. L'istruzione SELECT * viene trattata come una query che nomina esplicitamente una colonna limitata.

Esempio di interazione tra sicurezza a livello di riga e sicurezza a livello di colonna

Questo esempio illustra i passaggi per proteggere una tabella e poi eseguirne una query.

I dati

Supponiamo che tu abbia il ruolo Proprietario dati per un set di dati denominato my_dataset che include una tabella con tre colonne, denominata my_table. La tabella contiene i dati mostrati nella tabella seguente.

In questo esempio, un utente è Alice, il cui indirizzo email è alice@example.com. Un secondo utente è Bob, collega di Alice.

rank fruit color
1 apple red
2 orange orange
3 lime green
4 lemon yellow

La sicurezza

Vuoi che Alice possa vedere tutte le righe con numeri dispari nella colonna rank, ma non le righe con numeri pari. Non vuoi che Bob 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, crei una policy di accesso a livello di riga con un'espressione di filtro basata sui dati visualizzati nella colonna rank. Per impedire a Bob di vedere righe pari o dispari, non lo includi nell'elenco dei destinatari.

    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 vedere i dati nella colonna denominata fruit, crei un tag di criteri di sicurezza a livello di colonna che impedisce a tutti gli utenti di accedere a tutti i dati.

Infine, limiti l'accesso anche alla colonna denominata color in due modi: la colonna è regolata sia da un tag di criteri di sicurezza a livello di colonna che vieta l'accesso a chiunque, sia è interessata da una policy di accesso a livello di riga, che filtra alcuni dei dati delle righe nella colonna color.

  • Questa seconda policy di accesso a livello di riga mostra solo le righe con il valore green nella colonna color.

    CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table
GRANT TO ('user:alice@example.com') FILTER USING (color="green");

La query di Bob

Se il collega di Alice, Bob, tenta di eseguire una query sui dati di my_dataset.my_table, non vede alcuna riga perché Bob non è nell'elenco dei destinatari di alcuna policy di accesso a livello di riga nella tabella.

Query my_dataset.my_table Commenti
rank

(Alcuni dati sono interessati dalla policy 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 dalla policy di accesso alle righe only_green)
SELECT rank FROM my_dataset.my_table
(0) righe restituite.		 Bob non è nell'elenco dei destinatari della policy di accesso a livello di riga; pertanto, questa query viene eseguita correttamente, ma non vengono restituiti dati delle righe.

A Bob viene visualizzato un messaggio che indica che i risultati potrebbero essere filtrati dalla policy di accesso alle righe.

Le 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 dalla policy 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 dalla policy di accesso alle righe only_green)

SELECT rank FROM my_dataset.my_table


Viene restituita (1) riga.		 Alice è nell'elenco dei destinatari delle policy di accesso alle righe only_odd e only_green. Pertanto, Alice vede solo i ranghi dispari e i colori verdi. Di conseguenza, Alice vede la seguente riga:

rank: 3, color: green.

Alice non vede la colonna fruit perché è limitata da una policy di sicurezza a livello di colonna.

Ad Alice viene visualizzato un messaggio che indica che i risultati potrebbero essere filtrati dalla policy di accesso alle righe.

SELECT fruit FROM my_dataset.my_table


access denied

La colonna fruit è stata denominata esplicitamente nella query.

Si applica la sicurezza a livello di colonna.

L'accesso è negato.

SELECT color FROM my_dataset.my_table


Viene restituita (1) riga.		 Alice è nell'elenco dei destinatari delle policy di accesso alle righe only_odd e only_green. Pertanto, Alice vede solo i ranghi dispari e i colori verdi. Di conseguenza, Alice vede la seguente riga:

rank: 3, color: green.

Alice non vede la colonna fruit perché è limitata da una policy di sicurezza a livello di colonna.

Ad Alice viene visualizzato un messaggio che indica che i risultati potrebbero essere filtrati dalla policy di accesso alle righe.

SELECT rank, fruit FROM my_dataset.my_table


access denied

La colonna fruit è stata denominata esplicitamente nella query.

La sicurezza a livello di colonna si applica prima dell'applicazione della policy di accesso a livello di riga ai dati nella colonna rank.

L'accesso è negato.

SELECT rank, color FROM my_dataset.my_table


Viene restituita (1) riga.		 Alice è nell'elenco dei destinatari delle policy di accesso alle righe only_odd e only_green. Pertanto, Alice vede solo i ranghi dispari e i colori verdi. Di conseguenza, Alice vede la seguente riga:

rank: 3, color: green.

Alice non vede la colonna fruit perché è limitata da una policy di sicurezza a livello di colonna.

Ad Alice viene visualizzato un messaggio che indica che i risultati potrebbero essere filtrati dalla policy di accesso alle righe.

SELECT fruit, color FROM my_dataset.my_table


access denied

La colonna fruit è stata denominata esplicitamente nella query.

La sicurezza a livello di colonna nella colonna fruit si applica prima dell'applicazione della policy di accesso a livello di riga ai dati nella colonna color.

L'accesso è negato.

SELECT * FROM my_dataset.my_table


Viene restituita (1) riga.		 Alice è nell'elenco dei destinatari delle policy di accesso alle righe only_odd e only_green. Pertanto, Alice vede solo i ranghi dispari e i colori verdi. Di conseguenza, Alice vede la seguente riga:

rank: 3, color: green.

Alice non vede la colonna fruit perché è limitata da una policy di sicurezza a livello di colonna.

Ad Alice viene visualizzato un messaggio che indica che i risultati potrebbero essere filtrati dalla policy di accesso alle righe.

Accesso al filtro TRUE

Infine, come spiegato in la sezione relativa all'accesso al filtro TRUE, se Alice o Bob hanno accesso al filtro TRUE, possono vedere tutte le righe della tabella e utilizzarla nei job non di query. Tuttavia, se la tabella ha la sicurezza a livello di colonna, questa si applica comunque e può influire sui risultati.

Grafico di esecuzione

Non puoi utilizzare il grafico di esecuzione delle query per i job con policy di accesso a livello di riga.

Job di estrazione

Se una tabella ha policy di accesso a livello di riga, quando esegui un job di estrazione, in Cloud Storage vengono esportati solo i dati che puoi visualizzare.

SQL precedente

Le policy di accesso a livello di riga non sono compatibili con l'SQL precedente. Le query sulle tabelle con policy di accesso a livello di riga devono utilizzare GoogleSQL. Le query SQL precedenti vengono rifiutate.

Tabelle partizionate e in cluster

La sicurezza a livello di riga non partecipa al pruning delle query , una funzionalità delle tabelle partizionate.

Sebbene la sicurezza a livello di riga sia compatibile con le tabelle partizionate e in cluster, le policy di accesso a livello di riga che filtrano i dati delle righe non vengono applicate durante il pruning delle partizioni. Puoi comunque utilizzare il pruning delle partizioni su una tabella che utilizza la sicurezza a livello di riga specificando una clausola WHERE che opera sulla colonna di partizionamento. Allo stesso modo, le policy di accesso a livello di riga non creano alcun vantaggio in termini di prestazioni per le query sulle tabelle in cluster, ma non interferiscono con altri filtri applicati.

Il pruning delle query viene eseguito durante l'esecuzione delle policy di accesso a livello di riga utilizzando i filtri con le policy.

Rinominare una tabella

Non è necessario l'accesso al filtro TRUE per rinominare una tabella con una o più policy di accesso alle righe. 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 ha una policy di accesso a livello di riga, consulta la sezione relativa ai job di copia delle tabelle in questa pagina per ulteriori informazioni.

Aggiornamenti al flusso di dati

Per eseguire operazioni UPDATE o DELETE della tabella di streaming con l'acquisizione dei dati delle modifiche, devi disporre dell'accesso al filtro TRUE.

Viaggio nel tempo

Solo un amministratore della tabella può accedere ai dati storici di una tabella che ha o ha avuto in precedenza policy di accesso a livello di riga. Gli altri utenti ricevono un access denied errore se utilizzano un decoratore di viaggio nel tempo su una tabella che ha avuto accesso a livello di riga. Per ulteriori informazioni, consulta Viaggio nel tempo e accesso a livello di riga.

Viste logiche, materializzate e autorizzate

Questa sezione descrive i diversi tipi di viste BigQuery e il modo in cui interagiscono con la sicurezza a livello di riga.

Viste logiche o materializzate

Le viste logiche o materializzate vengono create da query sulle tabelle. I risultati della query sono in genere un sottoinsieme dei dati della tabella.

I dati visualizzati in entrambi i tipi di viste vengono filtrati in base alle policy di accesso a livello di riga della tabella di origine sottostante. Tuttavia, non puoi fare riferimento a viste o viste materializzate nelle policy di accesso a livello di riga.

Prestazioni per le viste materializzate

Inoltre, quando una vista materializzata viene derivata da una tabella sottostante con policy di accesso a livello di riga, le prestazioni della query sono le stesse di quando esegui una query direttamente sulla tabella di origine. In altre parole, se la tabella di origine ha la sicurezza a livello di riga, non vedrai i vantaggi in termini di prestazioni tipici dell'esecuzione di query su una vista materializzata rispetto all'esecuzione di query sulla tabella di origine.

Visualizzazioni autorizzate

Puoi anche autorizzare una vista logica o materializzata, il che significa condividere la vista con utenti o gruppi (entità) specifici. Le entità possono quindi eseguire query su una vista, ma non hanno accesso alla tabella sottostante. Per ulteriori informazioni, consulta Visualizzazioni autorizzate.

Query con caratteri jolly

Le query con caratteri jolly sulle tabelle con policy di accesso a livello di riga non riescono a essere eseguite e generano un errore INVALID_INPUT.

Passaggi successivi