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:

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

SELECT rank FROM my_dataset.my_table


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

SELECT fruit FROM my_dataset.my_table


access denied

La colonna fruit è stata denominata in modo esplicito 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 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.

SELECT rank, fruit FROM my_dataset.my_table


access denied

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.

SELECT rank, color FROM my_dataset.my_table


access denied

La colonna color è stata denominata in modo esplicito nella query

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

SELECT fruit, color FROM my_dataset.my_table


access denied


access denied

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.

SELECT * FROM my_dataset.my_table


access denied


access denied

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