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 altre 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 quando esegui 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.

È possibile concedere a qualsiasi utente l'accesso al filtro TRUE, incluso un account di servizio.

Ecco alcuni esempi di operazioni non di 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à che funzionano con il filtro TRUE

Job di copia

Per copiare una tabella con uno o più criteri di accesso a livello di riga, devi prima concedere l'accesso al filtro TRUE per la 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 dispone di criteri di accesso a livello di riga, 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".

Sono consentite copie tra regioni e tutti i criteri vengono copiati. Le query successive potrebbero non funzionare dopo il completamento della copia se le query contengono riferimenti a tabelle non validi nei criteri di 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 provoca 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 in una tabella con criteri di accesso a livello di riga, devi disporre dell'accesso con filtro TRUE.

DML

Per eseguire un'istruzione DML che aggiorna una tabella con criteri di accesso a livello di riga, devi disporre dell'accesso al 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 disporre dell'accesso con filtro TRUE 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 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 necessarie per copiare una tabella con un criterio di accesso a livello di riga.

Il viaggio cronologico non è supportato per le tabelle di base che hanno 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 nelle colonne JSON. Per scoprire di più sulle limitazioni della sicurezza a livello di riga, vedi 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, ma 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 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 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 la colonna è denominata nei criteri di accesso a livello di riga dell'istruzione SELECT o della sottoquery, riceverai 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 e per eseguirne l'esecuzione di 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 di colore giallo
4 limetta verde

La sicurezza

Vuoi che Alice possa visualizzare tutte le righe con numeri dispari nella colonna rank, ma non quelle con numeri pari. Non vuoi che Mario veda righe, anche dispari. Non vuoi che nessuno veda alcun dato nella colonna fruit.

  • Per impedire ad Alice di visualizzare le righe con numeri pari, puoi creare un criterio di accesso a livello di riga che ha un'espressione di filtro basata sui dati visualizzati nella colonna rank. Per evitare che Mario veda 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 fruit, crei un tag di criteri di sicurezza a livello di colonna che impedisce a tutti gli utenti di accedere ai relativi dati.

Infine, limiti 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 impedisce l'accesso completo a chiunque ed è interessata da un criterio di accesso a livello di riga, che filtra alcuni dati delle righe 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 Roberto

Se il collega di Alice, Roberto, tenta di eseguire query sui dati di my_dataset.my_table, non vedrà alcuna riga, perché Roberto non è nell'elenco dei beneficiari per nessun criterio di accesso a livello di riga della 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 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. Di conseguenza, questa query riesce, ma non vengono restituiti dati di riga.

Viene mostrato un messaggio a Roberto 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 risultati dipendono dalla query che esegue 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 sono interessati dal criterio di accesso alle righe only_green.

SELECT rank FROM my_dataset.my_table


Vengono restituite 2 righe dispari.		 Alice è nell'elenco dei beneficiari del criterio di accesso a livello di riga only_odd per i dati nella colonna di 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 in base al criterio di accesso alle righe.

SELECT fruit FROM my_dataset.my_table


access denied

Alla colonna fruit è stato assegnato un nome esplicito nella query.

Viene applicata la sicurezza a livello di colonna.

Accesso negato.

SELECT color FROM my_dataset.my_table


access denied

Alla colonna color è stato assegnato un nome esplicito nella query.

La sicurezza a livello di colonna si applica 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 si applica 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 menzionata esplicitamente nella query

Si applica la sicurezza a livello di colonna nella colonna color, prima che i criteri di accesso a livello di riga ai dati nelle colonne rank e color vengano coinvolti.

Accesso negato.

SELECT fruit, color FROM my_dataset.my_table


access denied


access denied

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

Viene applicata la sicurezza a livello di colonna nelle colonne fruit e color prima che venga attivato il 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 denominate implicitamente utilizzando "SELECT *" nella query.

Viene applicata la sicurezza a livello di colonna nelle colonne fruit e color, prima che vengano coinvolti i criteri di accesso a livello di riga per i dati nelle colonne rank o color.

Accesso negato.

Accesso al filtro TRUE

Infine, come spiegato nella sezione sull'accesso con filtro TRUE, se Alice o Roberto hanno accesso con filtro TRUE, possono visualizzare tutte le righe della tabella e utilizzarle in job non di query. Tuttavia, se la tabella prevede una protezione a livello di colonna, viene comunque applicata e può influire sui risultati.

Estrazione dei job

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 la versione precedente di SQL. 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, 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 operi sulla colonna di partizione. Allo stesso modo, i criteri di accesso a livello di riga stessi non offrono vantaggi in termini di prestazioni per le query sulle tabelle in cluster, 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 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 ha un criterio di accesso a livello di riga, consulta i job di copia della tabella 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 precedentemente avuto criteri di accesso a livello di riga. Gli altri utenti ricevono un errore access denied se utilizzano un decoratore di viaggi nel tempo in una tabella con accesso a livello di riga. Per ulteriori informazioni, vedi 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 deriva da una tabella sottostante con criteri 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 offre una 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.

Non puoi fare riferimento alle viste o alle 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 hanno esito negativo e restituiscono un errore INVALID_INPUT.

Passaggi successivi