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.

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. Accesso completo concesso utilizzando un criterio di accesso alle righe con l'espressione di filtro impostata su TRUE. Questo il 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 diverse dalle query:

• Altre API BigQuery, come l'API BigQuery Storage Read.
• Alcuni comandi dello bqstrumento a riga di comando, come il comando bq head.
• Copiare 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 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".

Sono consentite copie tra regioni e tutti i criteri vengono copiati. Le query successive potrebbero essere danneggiate 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.

Tabledata.list nell'API BigQuery

Devi disporre dell'accesso ai filtri TRUE per utilizzare il metodo tabledata.list nella API BigQuery in una tabella con criteri di accesso a livello di riga.

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 tabella

Supporto per gli snapshot delle tabelle 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 nelle 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

Sicurezza a livello di riga e sicurezza a livello di colonna, che include sia controllo dell'accesso a livello di colonna e 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 di 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 riferite al 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 *. La SELECT * viene considerato come una query che nomina esplicitamente una query colonna.

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 seguente tabella.

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

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 evitare che Bob veda elementi pari o dispari righe, 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, puoi anche limitare 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 chiunque abbia accesso a tutti, e è interessato da un criterio di accesso a livello di riga, che filtra alcuni dei dati delle righe nella colonna color.

• Questo secondo criterio di accesso a livello di riga mostra solo le righe con 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, 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 di Alice

Quando Alice esegue query per accedere ai dati di my_dataset.my_table, la sua dipendono dalla query che esegue e dalla sicurezza, come nella tabella seguente.

Accesso al filtro TRUE

Infine, come spiegato in la sezione sull'accesso ai filtri TRUE, Se Alice o Bob hanno accesso ai filtri TRUE, possono vedere tutte le righe della tabella e utilizzarlo in job non di query. Tuttavia, se tabella ha una sicurezza a livello di colonna, viene comunque applicata e può influire che consentono di analizzare i dati e visualizzare i risultati.

Job di estrazione

Se una tabella include criteri di accesso a livello di riga, vengono utilizzati solo i dati che puoi viene esportata in a 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, che è una funzionalità delle tabelle partizionate.

Sebbene la sicurezza a livello di riga sia compatibile con le istanze partizionate e in cluster, tabelle, i criteri di accesso a livello di riga che filtrano i dati delle righe non vengono applicati durante l'eliminazione della partizione. Puoi comunque usare l'eliminazione delle partizioni su una tabella che utilizza la sicurezza a livello di riga specificando una clausola WHERE che funziona nella colonna di partizione. Allo stesso modo, i criteri di accesso a livello di riga che non apportano vantaggi in termini di prestazioni per le query sulle tabelle in cluster, ma non interferiscono con gli altri filtri che applichi.

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 accesso a una o più righe criteri su di esso. 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 i job di copia delle tabelle 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 avuto in precedenza criteri di accesso a livello di riga. Gli altri utenti ricevono un errore access denied se utilizzano un decoratore di viaggi nel tempo su una tabella con 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 alla i criteri di accesso a livello di riga per la 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 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 non vanno a buon fine con 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.