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 altri 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 durante l'esecuzione query. Per eseguire operazioni non basate su query, ad esempio DML, è necessario e l'accesso 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 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 ai filtri TRUE attivo la tabella di origine. Anche tutti i criteri di accesso a livello di riga nella tabella di origine sono copiato nella nuova tabella di destinazione. Se copi una tabella di origine senza criteri di accesso a livello di riga su una tabella di destinazione con livello di riga criteri di accesso, i criteri di accesso a livello di riga vengono rimossi dalla tabella di destinazione. a meno che non venga usato il flag --append_table o "writeDisposition": "WRITE_APPEND" è impostata.

Sono consentite copie tra regioni e tutti i criteri vengono copiati. Query successive potrebbe non funzionare al termine della copia se le query contengono una tabella non valida nei criteri delle sottoquery.

I criteri di accesso a livello di riga in una tabella devono avere nomi univoci. Si è verificata una collisione i nomi dei criteri di accesso a livello di riga durante la copia restituiscono un 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 alla 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 ai filtri TRUE per utilizzare il metodo tabledata.list nella API BigQuery in una tabella con criteri di accesso a livello di riga.

DML

Eseguire un'istruzione DML che aggiorna una tabella con 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 che segue:

  • Se una tabella di destinazione contiene criteri di accesso a livello di riga, devi TRUE accesso al filtro alla tabella di destinazione.
  • Se una tabella di origine contiene criteri di accesso a livello di riga, 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 lo snapshot della tabella (tabella di destinazione) sono descritti 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 con una o più righe a livello di riga criteri di sicurezza.

Tabella BigQuery con colonne JSON

I criteri di accesso a livello di riga non possono essere applicati nelle colonne JSON. Per scoprire di più sui limiti 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; queste query vengono eseguite come query standard in BigQuery.

I dati di una dashboard di Looker Studio vengono filtrati in base alla i criteri di accesso a livello di riga per la 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.
    • Tenta di accedere a queste colonne con il criterio di accesso a livello di riga della sottoquery restituisce un errore che indica che l'accesso è stato negato. Queste colonne non sono considerate colonne riferite al sistema.
    • Tenta di accedere a queste colonne con il criterio di accesso a livello di riga non di sottoquery per bypassare la sicurezza a livello di colonna.
  • Se la colonna è limitata per via della sicurezza a livello di colonna e viene denominato nei criteri di accesso a livello di riga dell'istruzione SELECT o della sottoquery, ricevi un messaggio di 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 di sicurezza a livello di riga e di sicurezza a livello di colonna

Questo esempio illustra la procedura per proteggere un tavolo eseguendo una 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 giallo
4 limetta verde

La sicurezza

Vuoi che Alice veda tutte le righe che hanno numeri dispari rank, ma non nelle righe con numeri pari. Non vuoi che Mario veda righe, pari o dispari. Non vuoi che nessuno veda alcun dato nella colonna fruit.

  • Per impedire ad Alice di vedere le righe con numeri pari, crea una il criterio di accesso a livello di riga che ha un'espressione di filtro basata sui dati visualizzato 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: crei un tag di criteri di sicurezza a livello di colonna che impedisce a tutti gli utenti di accederà a uno qualsiasi dei suoi 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, ed è 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 Roberto, un collega di Alice, tenta di eseguire query sui dati di my_dataset.my_table, non vede righe perché Roberto non è nell'elenco dei beneficiari per nessuna riga a livello di riga di accesso al criterio di accesso 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 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 la query ha esito positivo, ma non vengono restituiti dati di riga.

Viene mostrato un messaggio a Roberto che informa che i suoi risultati potrebbero essere filtrati in base a il criterio di accesso alle righe.

Query di Alice

Quando Alice esegue query per accedere ai dati di my_dataset.my_table, la sua dipendono dalla query eseguita e dalla sicurezza, come illustrato 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


(2) vengono restituite righe dispari.		 Alice è nell'elenco dei beneficiari dell'only_odd il criterio di accesso a livello di riga sui dati nella colonna 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 dal 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 del criterio di accesso a livello di riga ai dati nella colonna color è coinvolto.

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 del criterio di accesso a livello di riga ai dati nella colonna rank è coinvolto.

Accesso negato.

SELECT rank, color FROM my_dataset.my_table


access denied

La colonna color è stata denominata esplicitamente nella query

Si applica la sicurezza a livello di colonna nella colonna color. prima dei criteri di accesso a livello di riga sui dati rank e le colonne color sono attive.

Accesso negato.

SELECT fruit, color FROM my_dataset.my_table


access denied


access denied

Le colonne fruit e color erano esplicitamente denominato nella query.

La sicurezza a livello di colonna in fruit e color colonne, prima del criterio di accesso a livello di riga su dati nella colonna color sono coinvolti.

Accesso negato.

SELECT * FROM my_dataset.my_table


access denied


access denied

Le colonne fruit e color erano implicitamente denominato utilizzando "SELECT *" nella query.

La sicurezza a livello di colonna in fruit e Si applicano color colonne prima dei criteri di accesso a livello di riga dei dati nelle colonne rank o color sono coinvolti.

Accesso negato.

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.

Estrazione dei job

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. Query superiori a le 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 alla query potatura, una funzionalità di 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. Analogamente, 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 include un criterio di accesso a livello di riga, consulta job di copia di 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 con aveva 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 Spostamento nel tempo e livello di riga l'accesso alle app.

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 deriva da una tabella sottostante con criteri di accesso a livello di riga, le prestazioni delle query sono le stesse di quando esegui una query sull'origine direttamente dalla tabella. In altre parole, se la tabella di origine prevede una sicurezza a livello di riga, non vedo 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 alle viste o alle viste materializzate nei criteri di accesso a livello di riga.

Query con caratteri jolly

Query con caratteri jolly rispetto a le tabelle con criteri di accesso a livello di riga hanno esito negativo con un errore INVALID_INPUT.

Passaggi successivi