Introduzione alla sicurezza a livello di riga di BigQuery

Questo documento spiega il concetto di sicurezza a livello di riga, come funziona in BigQuery, quando utilizzare la sicurezza a livello di riga per proteggere i dati e altri dettagli.

Che cos'è la sicurezza a livello di riga?

La sicurezza a livello di riga consente di filtrare i dati e di accedere a righe specifiche di una tabella in base a condizioni utente idonee.

BigQuery supporta già i controlli dell'accesso a livello di progetto, set di dati e tabella, nonché la sicurezza a livello di colonna tramite tag di criteri. La sicurezza a livello di riga estende il principio del privilegio minimo abilitando un controllo dell'accesso granulare a un sottoinsieme di dati in una tabella BigQuery mediante criteri di accesso a livello di riga.

Una tabella può avere più criteri di accesso a livello di riga. I criteri di accesso a livello di riga possono coesistere in una tabella con controlli di accesso a livello di colonna e di accesso a livello di set di dati, a livello di tabella e a livello di progetto.

Come funziona la sicurezza a livello di riga

A livello generale, la sicurezza a livello di riga prevede la creazione di criteri di accesso a livello di riga in una tabella BigQuery di destinazione. Questi criteri fungono da filtri per nascondere o visualizzare determinate righe di dati, a seconda che un utente o un gruppo faccia parte di un elenco di utenti autorizzati. A tutti gli utenti o gruppi non inclusi specificamente nell'elenco di utenti autorizzati viene negato l'accesso.

Un utente autorizzato, con i ruoli Identity and Access Management (IAM) Amministratore BigQuery o Proprietario dati BigQuery, può creare criteri di accesso a livello di riga in una tabella BigQuery.

Quando crei un criterio di accesso a livello di riga, specifichi la tabella per nome e quali utenti o gruppi (chiamati grantee-list) possono accedere a determinati dati di riga. Il criterio include anche i dati in base ai quali vuoi filtrare, chiamati filter_expression. filter_expression funziona come una clausola WHERE in una query tipica.

Per istruzioni su come creare e utilizzare un criterio di accesso a livello di riga, vedi Utilizzo della sicurezza a livello di riga.

Consulta la documentazione di riferimento DDL per informazioni sulla sintassi, l'utilizzo e le opzioni complete durante la creazione dei criteri di accesso a livello di riga.

Esempi di casi d'uso

Filtra i dati delle righe in base alla regione

Considera il caso in cui una tabella dataset1.table1 contiene righe appartenenti ad regioni diverse (indicate dalla colonna region).

La sicurezza a livello di riga consente a un proprietario o un amministratore dei dati di implementare criteri come "Gli utenti in group:apac possono vedere solo i partner della regione APAC".

Caso d'uso della sicurezza a livello di riga per le regioni

Il comportamento risultante è che gli utenti nel gruppo sales-apac@example.com possono visualizzare solo le righe in cui Region = "APAC". Allo stesso modo, gli utenti nel gruppo sales-us@example.com possono visualizzare solo le righe nella regione US. Gli utenti non appartenenti a gruppi APAC o US non vedono le righe.

Il criterio di accesso a livello di riga denominato us_filter concede l'accesso a più entità, tra cui il responsabile delle vendite degli Stati Uniti jon@example.com, che può ora accedere alle righe appartenenti alla regione US.

Filtra i dati delle righe in base a dati sensibili

Ora consideriamo un caso d'uso diverso, in cui abbiamo una tabella di dati sugli stipendi.

Caso d'uso della sicurezza a livello di riga per gli stipendi

Il grantee_list limita l'esecuzione di query ai membri del dominio dell'azienda. Inoltre, l'utilizzo della funzione SESSION_USER() limita ulteriormente l'accesso alle righe che appartengono all'utente che esegue la query, in base al suo indirizzo email dell'utente. In questo caso, è jim@example.com.

Filtra i dati delle righe in base alla tabella di ricerca

Per fornire feedback o richiedere assistenza in merito a questa funzionalità, invia un'email all'indirizzo bigquery-row-level-security-support@google.com.

Con il supporto delle sottoquery, i criteri di accesso alle righe possono fare riferimento ad altre tabelle e utilizzarle come tabelle di ricerca. I dati utilizzati nelle regole di filtro possono essere archiviati in una tabella e un singolo criterio di accesso alle righe di sottoquery può sostituire più criteri di accesso alle righe configurati. Per aggiornare i criteri di accesso alle righe, è sufficiente aggiornare la tabella di ricerca, che sostituisce più criteri di accesso alle righe. Non è necessario aggiornare ogni singolo criterio di accesso alle righe.

Quando utilizzare la sicurezza a livello di riga rispetto ad altri metodi

Le viste autorizzate, i criteri di accesso a livello di riga e l'archiviazione dei dati in tabelle separate offrono tutti livelli diversi di sicurezza, prestazioni e convenienza. La scelta del meccanismo giusto per il tuo caso d'uso è importante per garantire il giusto livello di sicurezza per i tuoi dati.

Confronto con le viste autorizzate: vulnerabilità

Sia la sicurezza a livello di riga sia l'applicazione dell'accesso a livello di riga con una vista autorizzata possono presentare vulnerabilità, se utilizzate in modo improprio.

Se utilizzi le viste autorizzate o i criteri di accesso a livello di riga per la sicurezza a livello di riga, ti consigliamo di monitorare eventuali attività sospette utilizzando l'audit logging.

I canali laterali, come la durata della query, possono divulgare informazioni sulle righe che si trovano sul perimetro di uno shard di archiviazione. Tali attacchi richiederebbero probabilmente una certa conoscenza di come viene eseguito lo sharding della tabella o un elevato numero di query.

Per ulteriori informazioni su come prevenire questi attacchi a livello di canale laterale, consulta Best practice per la sicurezza a livello di riga.

Confronto di viste autorizzate, sicurezza a livello di riga e tabelle separate

La seguente tabella mette a confronto flessibilità, prestazioni e sicurezza delle viste autorizzate, dei criteri di accesso a livello di riga e delle tabelle separate.

Metodo Considerazioni sulla sicurezza Consiglio
Visualizzazioni
autorizzate		 Consigliato per una maggiore flessibilità. Può essere vulnerabile a query e durate delle query create con attenzione e ad altri tipi di attacchi side-channel. Le viste autorizzate sono una buona scelta quando devi condividere dati con altri, inoltre alla flessibilità e alle prestazioni sono importanti. Ad esempio, puoi utilizzare le viste autorizzate per condividere i dati all'interno del tuo gruppo di lavoro.
Criteri di accesso a livello di riga Consigliato per un equilibrio tra flessibilità e sicurezza. Può essere vulnerabile ad attacchi al canale laterale della durata delle query. I criteri di accesso a livello di riga sono una buona scelta quando devi condividere i dati con altri utenti e vuoi fornire ulteriore sicurezza rispetto alle viste o alle sezioni delle tabelle. Ad esempio, puoi utilizzare i criteri di accesso a livello di riga per condividere i dati con utenti che utilizzano tutti la stessa dashboard, anche se alcuni hanno accesso a più dati di altri.
Tabelle separate Consigliato per la sicurezza. Gli utenti non possono dedurre i dati senza accesso alla tabella. Le tabelle separate sono una buona scelta quando devi condividere dati con altri e devi mantenere i dati isolati. Ad esempio, puoi utilizzare tabelle separate per condividere i dati con partner e fornitori terzi, quando il numero totale di righe deve essere segreto.

Crea e gestisci i criteri di accesso a livello di riga

Per informazioni su come creare, aggiornare (ricreare), elencare, visualizzare ed eliminare i criteri di accesso a livello di riga in una tabella e su come eseguire query sulle tabelle con criteri di accesso a livello di riga, consulta Utilizzo della sicurezza dell'accesso a livello di riga.

Quote

Per ulteriori informazioni su quote e limiti per la sicurezza a livello di riga, consulta Quote e limiti di BigQuery.

Prezzi

La sicurezza a livello di riga è inclusa in BigQuery senza costi aggiuntivi. Tuttavia, un criterio di accesso a livello di riga può influire sul costo dell'esecuzione di una query nei seguenti modi:

  • La fatturazione aggiuntiva può essere causata da criteri di accesso a livello di riga, in particolare quelli che includono sottoquery che fanno riferimento ad altre tabelle.

  • I filtri dei criteri di accesso a livello di riga non partecipano all'eliminazione delle query nelle tabelle partizionate e in cluster. Ciò non significa che legge più dati durante l'esecuzione della query principale. Non sfrutta i predicati del criterio di accesso alle righe per essere eliminati ulteriormente.

  • Con i filtri dei criteri di accesso a livello di riga, non tutti i filtri utente vengono applicati in anticipo. Questo potrebbe aumentare i dati letti dalle tabelle, nonché leggere e fatturare per più righe.

Per ulteriori informazioni sui prezzi delle query BigQuery, consulta Prezzi di BigQuery.

Limitazioni

Per informazioni sui limiti per la sicurezza a livello di riga, vedi BigQuery Limiti di sicurezza a livello di riga. Le sezioni seguenti documentano ulteriori limitazioni di sicurezza a livello di riga.

Limitazioni delle prestazioni

  • Alcune funzionalità di BigQuery non hanno un'accelerazione quando si lavora con tabelle contenenti criteri di accesso a livello di riga, ad esempio BigQuery BI Engine e le viste materializzate.

  • La sicurezza a livello di riga non partecipa all'eliminazione delle query, una funzionalità delle tabelle partizionate. Per ulteriori informazioni, consulta Tabelle partizionate e in cluster. Questa limitazione non rallenta l'esecuzione della query principale.

  • Potresti riscontrare un piccolo peggioramento delle prestazioni quando esegui query su tabelle con sicurezza a livello di riga.

Per ulteriori informazioni sull'interazione della sicurezza a livello di riga con alcuni servizi e funzionalità di BigQuery, consulta Utilizzo della sicurezza a livello di riga con altre funzionalità di BigQuery.

Altre limitazioni

  • Questa funzionalità potrebbe non essere disponibile quando utilizzi le prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni sulle funzionalità abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.

  • I criteri di accesso alle righe non sono compatibili con SQL precedente. Le query delle tabelle con criteri di accesso a livello di riga devono usare GoogleSQL. Le query SQL legacy vengono rifiutate con un errore.

  • Non puoi applicare criteri di accesso a livello di riga nelle colonne JSON.

  • Alcune funzionalità di BigQuery non sono compatibili con la sicurezza a livello di riga. Per maggiori informazioni, consulta Utilizzo della sicurezza a livello di riga.

  • Le operazioni non query, inclusi i job degli account di servizio, che richiedono l'accesso completo ai dati della tabella possono utilizzare la sicurezza a livello di riga con il filtro TRUE. Alcuni esempi sono la copia di tabelle, i flussi di lavoro Dataproc e altro ancora. Per maggiori informazioni, consulta Utilizzo della sicurezza a livello di riga.

  • La creazione, la sostituzione o l'eliminazione dei criteri di accesso a livello di riga deve essere eseguita con le istruzioni DDL. L'elenco e la visualizzazione dei criteri di accesso a livello di riga possono essere eseguiti tramite la console Google Cloud o lo strumento a riga di comando bq.

  • L'anteprima o la consultazione delle tabelle non è compatibile con la sicurezza a livello di riga.

  • Il campionamento della tabella non è compatibile con la sicurezza a livello di riga.

  • I risultati dei criteri di sottoquery di primo livello sono limitati a 100 MB. Questo limite si applica per criteri di accesso a livello di riga.

  • Se il predicato del criterio di accesso a livello di riga non può essere valutato a causa dell'eliminazione di qualsiasi tabella di riferimento, la query non riesce.

  • I criteri di accesso a livello di riga delle sottoquery supportano solo le tabelle BigQuery, le tabelle esterne BigLake e le tabelle gestite da BigLake.

Audit logging e monitoraggio

Quando vengono letti i dati di una tabella con uno o più criteri di accesso a livello di riga, i criteri di accesso a livello di riga autorizzati per l'accesso in lettura ed eventuali tabelle corrispondenti a cui viene fatto riferimento nelle sottoquery vengono visualizzati nelle informazioni sull'autorizzazione IAM per la richiesta di lettura.

La creazione e l'eliminazione dei criteri di accesso a livello di riga vengono audit log e sono accessibili tramite Cloud Logging. Gli audit log includono il nome del criterio di accesso a livello di riga. Tuttavia, le definizioni di filter_expression e grantee_list di un criterio di accesso a livello di riga vengono omesse dai log, in quanto potrebbero contenere informazioni sugli utenti o altre informazioni sensibili. L'elenco e la visualizzazione dei criteri di accesso a livello di riga non vengono registrati nel log di controllo.

Per ulteriori informazioni sul logging in BigQuery, consulta Introduzione al monitoraggio di BigQuery.

Per ulteriori informazioni sul logging in Google Cloud, consulta Cloud Logging.

Passaggi successivi