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

I criteri di accesso a livello di riga possono filtrare i dati dei risultati visualizzati quando esegui le query. Per eseguire operazioni diverse dalle query, come la DML, è necessario avere 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 ai filtri TRUE, incluso un account di servizio.

Ecco alcuni esempi di operazioni diverse dalle query:

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 in una tabella di destinazione che li ha, i criteri di accesso a livello di riga 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 essere interrotte al termine della copia se contengono riferimenti alle tabelle invalidi nei criteri delle sottoquery.

I criteri di accesso a livello di riga in una tabella devono avere nomi univoci. Una collisione 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

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

Per eseguire un'istruzione DML che aggiorna una tabella con criteri di accesso a livello di riga, devi disporre dell'accesso con filtro 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 filtrare l'accesso alla 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 delle tabelle

Gli snapshot delle tabelle supportano la sicurezza a livello di riga. Le autorizzazioni necessarie per la tabella di base (tabella di origine) e per 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.

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 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

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 dei dati dinamici, 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 di sistema.
    • I tentativi di accedere a queste colonne con il criterio di accesso a livello di riga non sottoquery aggirano la sicurezza a livello di colonna.
  • Se la colonna è limitata a causa della sicurezza a livello di colonna e la colonna è menzionata nei criteri di accesso a livello di riga dell'istruzione SELECT o della sottoquery della query, viene visualizzato un 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 tra sicurezza a livello di riga e sicurezza a livello di colonna

Questo esempio illustra i passaggi per proteggere una tabella ed eseguire query su di essa.

I dati

Supponiamo che tu abbia il ruolo DataOwner per un set di dati denominato my_dataset che include una tabella con tre colonne denominate my_table. La tabella contiene i dati riportati nella tabella seguente.

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

rank fruit color
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 Bob veda alcuna riga, 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 un criterio di accesso a livello di riga con un'espressione di filtro basata sui dati che vengono visualizzati nella colonna rank. Per impedire a Bob di vedere le righe pari o dispari, 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, crea un tag di criteri di sicurezza a livello di colonna che impedisca a tutti gli utenti di accedere ai relativi dati.

Infine, limiti anche l'accesso 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, 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 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");

Query di Bob

Se il collega di Alice, Bob, tenta di eseguire query sui dati di my_dataset.my_table, non visualizza alcuna riga perché non è nell'elenco dei beneficiari per 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 riga 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.		 Bob non è nell'elenco dei beneficiari del criterio di accesso a livello di riga. Pertanto, questa query va a buon fine, ma non vengono restituiti dati sulle righe.

A Bob viene mostrato un messaggio che lo 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 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 riga 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


(2) vengono restituite le righe con numeri dispari.		 Alice è nell'elenco dei beneficiari per il criterio di accesso a livello di riga only_odd relativo ai dati nella colonna Rango. Pertanto, Alice vede solo i dati delle righe con numero dispari. Le righe con numeri pari sono nascoste dal criterio di accesso a livello di riga denominato only_odd.

Ad Alice viene mostrato un messaggio che le comunica che i suoi risultati potrebbero essere filtrati dal criterio di accesso alle righe.

SELECT fruit FROM my_dataset.my_table


access denied

La colonna fruit è stata denominata esplicitamente nella query.

Viene applicata la sicurezza a livello di colonna.

Accesso negato.

SELECT color FROM my_dataset.my_table


access denied

La colonna color è stata denominata esplicitamente nella query.

La sicurezza a livello di colonna viene applicata prima dell'attivazione del criterio di accesso a livello di riga per i dati nella colonna color.

Accesso negato.

SELECT rank, fruit FROM my_dataset.my_table


access denied

La colonna "fruit" è stata denominata esplicitamente nella query.

La sicurezza a livello di colonna viene applicata prima dell'attivazione del criterio di accesso a livello di riga per i dati nella colonna rank.

Accesso negato.

SELECT rank, color FROM my_dataset.my_table


access denied

La colonna color è stata denominata esplicitamente nella query

La 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.

SELECT fruit, color FROM my_dataset.my_table


access denied


access denied

Le colonne fruit e color sono state rinominate esplicitamente nella query.

La sicurezza a livello di colonna per le colonne fruit e color viene applicata prima dell'attivazione del criterio di accesso a livello di riga per i dati nella colonna color.

Accesso negato.

SELECT * FROM my_dataset.my_table


access denied


access denied

Le colonne fruit e color sono state implicitamente chiamate utilizzando "SELECT *" nella query.

La sicurezza a livello di colonna per le colonne fruit e color viene applicata prima dell'attivazione dei criteri di accesso a livello di riga per i dati nelle colonne rank o color.

Accesso negato.

Accesso ai filtri TRUE

Infine, come spiegato nella sezione relativa all'accesso ai filtri TRUE, se Alice o Bob hanno accesso ai filtri TRUE, possono visualizzare tutte le righe della tabella e utilizzarla in job non di query. Tuttavia, se la tabella ha la sicurezza a livello di colonna, viene applicata comunque e può influire sui risultati.

Grafico di esecuzione

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

Job di estrazione

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

SQL precedente

I criteri di accesso a livello di riga non sono compatibili con SQL precedente. Le query sulle tabelle con criteri 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 all'eliminazione delle query, che è una funzionalità delle tabelle partizionate.

Sebbene la sicurezza a livello di riga sia compatibile con le tabelle partizionate e raggruppate, 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 in una tabella che utilizza la sicurezza a livello di riga specificando una clausola WHERE che operi sulla colonna della partizione. Analogamente, i criteri di accesso a livello di riga non offrono alcun vantaggio in termini di prestazioni per le query sulle tabelle clusterizzate, ma non interferiscono con 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 ai filtri 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 alla tabella di destinazione un nome diverso. Se la tabella di origine ha un criterio di accesso a livello di riga, consulta Job di copia delle tabelle in questa pagina per ulteriori informazioni.

Aggiornamenti in streaming

Per eseguire operazioni sulle tabelle UPDATE o DELETE in streaming con Change Data Capture, devi disporre dell'accesso in base 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 criteri di accesso a livello di riga. Gli altri utenti ricevono un errore access denied 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 e viste materializzate

I dati visualizzati 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 è derivata da una tabella sottostante con criteri di accesso a livello di riga, le prestazioni delle 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 tipici delle 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 sulle tabelle con criteri di accesso a livello di riga non vanno a buon fine con un errore INVALID_INPUT.

Passaggi successivi