Introduzione alla sicurezza a livello di riga di BigQuery

Nota: questa funzionalità potrebbe non essere disponibile quando utilizzi prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni sulle funzionalità abilitate in ogni versione, consulta Introduzione alle versioni 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 alle condizioni dell'utente qualificato.

BigQuery supporta i controlli dell'accesso a livello di progetto, set di dati e tabella, nonché la sicurezza a livello di colonna tramite i tag di policy. La sicurezza a livello di riga estende il principio del privilegio minimo consentendo il controllo granulare dell'accesso 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 la sicurezza a livello di colonna, nonché con i controlli dell'accesso a livello di set di dati, tabella, e progetto.

Come funziona la sicurezza a livello di riga

A livello generale, la sicurezza a livello di riga implica la creazione di criteri di accesso a livello di riga sulla tabella BigQuery di destinazione. Questi criteri fungono da filtri per nascondere o mostrare determinate righe di dati, a seconda se un utente o un gruppo fa parte di un elenco autorizzato. A tutti gli utenti o gruppi non inclusi specificamente nell'elenco autorizzato viene negato l'accesso.

Nota: se crei un nuovo criterio di sicurezza a livello di riga per limitare l'accesso alle righe, gli utenti che in precedenza avevano accesso completo devono essere aggiunti a un TRUE filtro per mantenere l'accesso.

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

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

Ricorda: come una clausola WHERE, filter_expression corrisponde ai dati che vuoi siano visibili alle entità in grantee_list. Gli utenti che non sono in grantee_list non possono vedere alcuna riga.

Per istruzioni su come creare e utilizzare un criterio di accesso a livello di riga, consulta Gestire la sicurezza a livello di riga.

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

Esempi di casi d'uso

Gli esempi seguenti illustrano i potenziali casi d'uso per la sicurezza a livello di riga.

Nota: quando gestisci l'accesso per gli utenti nei provider di identità esterni, sostituisci le istanze degli identificatori di entità dell'Account Google, come user:[e-mail], group:[e-mail], e domain:example.com—con gli identificatori di entità della federazione delle identità per la forza lavoro appropriati.

Filtrare i dati delle righe in base alla regione

Considera il caso in cui la tabella dataset1.table1 contenga righe appartenenti a regioni diverse (indicate dalla colonna region).

Puoi creare e popolare la tabella di esempio utilizzando la seguente query:

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', '[e-mail]', 'Japan', 'APAC'),
  ('Example Enterprise Group', '[e-mail]', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', '[e-mail]', 'USA', 'US'),
  ('Example Buyers Inc.', '[e-mail]', 'USA', 'US');

La sicurezza a livello di riga consente a un proprietario o amministratore dei dati di implementare i criteri. La seguente istruzione implementa un criterio che limita gli utenti del gruppo di mailing APAC a visualizzare solo i partner della regione APAC:

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group:[e-mail]")
FILTER USING
  (region="APAC" );

Il comportamento risultante è che gli utenti del gruppo [e-mail] possono visualizzare solo le righe in cui il valore di region è APAC.

La seguente istruzione implementa un criterio che limita sia i singoli utenti sia i gruppi a visualizzare solo i partner della regione Stati Uniti:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:[e-mail]",
"user:[e-mail]")
FILTER USING
  (region="US");

Il comportamento risultante è che gli utenti del gruppo [e-mail] e l'utente [e-mail] possono visualizzare solo le righe in cui il valore di region è US.

Gli utenti che non fanno parte dei gruppi APAC o US non vedono alcuna riga.

Filtrare i dati delle righe in base ai dati sensibili

Ora considera un caso d'uso diverso, in cui hai una tabella che contiene informazioni sugli stipendi.

Puoi creare e popolare la tabella di esempio utilizzando la seguente query:

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, '[e-mail]'),
  ('Anna K', 'Finance', 100000, '[e-mail]'),
  ('Bruce L', 'Engineering', 100000, '[e-mail]'),
  ('Carrie F', 'Business', 100000, '[e-mail]');

Il criterio di accesso alle righe nella seguente istruzione limita l'esecuzione di query ai membri del dominio aziendale. Inoltre, l'utilizzo della funzione SESSION_USER() limita l'accesso solo alle righe appartenenti all'utente che esegue la query, in base al suo indirizzo email utente.

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

L'immagine seguente mostra come il criterio di accesso alle righe limita la tabella contenente le informazioni sugli stipendi. In questo esempio, l'utente si chiama Jim e ha l'indirizzo email [e-mail].

Per altri esempi di sicurezza a livello di riga, consulta Utilizzare la sicurezza a livello di riga.

Filtrare i dati delle righe in base alla tabella di ricerca

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 della sottoquery può sostituire più criteri di accesso alle righe configurati. Per aggiornare i criteri di accesso alle righe, devi solo aggiornare la tabella di ricerca, che sostituisce più criteri di accesso alle righe. Non devi aggiornare ogni singolo criterio di accesso alle righe.

Per esempi di filtraggio dei dati delle righe, consulta Utilizzare la sicurezza a livello di riga.

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 praticità. La scelta del meccanismo giusto per il tuo caso d'uso è importante per garantire il livello di sicurezza appropriato 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.

Quando 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 gli audit log.

I canali secondari, come la durata della query, possono divulgare informazioni sulle righe che si trovano al limite di uno shard di archiviazione. Questi attacchi richiederebbero probabilmente una certa conoscenza di come viene suddivisa la tabella o un numero elevato di query.

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

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

La tabella seguente confronta la flessibilità, il rendimento e la sicurezza delle viste autorizzate, dei criteri di accesso a livello di riga e delle tabelle separate.

Metodo	Considerazioni sulla sicurezza	Consiglio
Viste autorizzate	Consigliato per la flessibilità. Può essere vulnerabile a query create con cura , durate delle query e altri tipi di attacchi tramite canali secondari.	Le viste autorizzate sono una buona scelta quando devi condividere dati con altri e la flessibilità e il rendimento 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 agli attacchi tramite canali secondari della durata delle query.	I criteri di accesso a livello di riga sono una buona scelta quando devi condividere dati con altri e vuoi fornire una sicurezza aggiuntiva 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 persone che utilizzano la stessa dashboard, anche se alcune persone hanno accesso a più dati di altre.
Tabelle separate	Consigliato per la sicurezza. Gli utenti non possono dedurre i dati senza accedere 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 di terze parti, quando il numero totale di righe deve essere segreto.

Creare e gestire 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 Utilizzare la sicurezza di accesso a livello di riga.

Eliminazione implicita dei criteri di accesso a livello di riga

I criteri di accesso alle righe possono essere rimossi implicitamente (automaticamente) da una tabella in diverse condizioni.

Il principio generale per l'eliminazione automatica dei criteri di accesso alle righe è il seguente:

• Le operazioni che utilizzano una WRITE_TRUNCATE disposizione di scrittura sovrascrivono sempre tutti i criteri di accesso alle righe esistenti nella tabella di destinazione.
• Per le operazioni con una disposizione di scrittura WRITE_APPEND, i criteri di accesso alle righe correnti della tabella di destinazione vengono mantenuti e i criteri della tabella di origine vengono aggiunti alla tabella di destinazione.

In particolare, i criteri di accesso alle righe vengono rimossi implicitamente nelle seguenti situazioni:

• Sostituzione di una tabella: quando una tabella viene sostituita utilizzando l'istruzione CREATE OR REPLACE TABLE DDL, vengono eliminati tutti i criteri di accesso alle righe esistenti nella tabella originale. Ciò si verifica anche se la query di sostituzione si basa sui dati della tabella originale.

• Caricamento o esecuzione di query con WRITE_TRUNCATE: le operazioni che utilizzano la disposizione di scrittura WRITE_TRUNCATE rimuovono tutti i criteri di accesso alle righe esistenti. Ciò include il caricamento dei dati utilizzando il bq load --replace comando e l'esecuzione di una query con lo stato di writeDisposition impostato su WRITE_TRUNCATE. Queste operazioni sovrascrivono completamente la tabella e i criteri di accesso alle righe non vengono trasferiti.

• Eliminazione o scadenza della tabella: se una tabella viene eliminata in modo esplicito o se raggiunge il tempo di scadenza e viene rimossa automaticamente, vengono eliminati anche tutti i criteri di accesso alle righe associati.

• Operazioni di copia della tabella: quando copi una tabella senza criteri di accesso alle righe in una tabella di destinazione che ha criteri di accesso alle righe, i criteri della tabella di destinazione vengono rimossi, a meno che non venga utilizzato il --append_table flag o "writeDisposition": "WRITE_APPEND". Per ulteriori informazioni sui job di copia delle tabelle, consulta Utilizzare la sicurezza a livello di riga con altre funzionalità di BigQuery.

L'utilizzo dell'TRUNCATE TABLE istruzione DML, che rimuove tutte le righe da una tabella mantenendo lo schema, non rimuove i criteri di accesso alle righe.

Quote

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

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 criteri che includono sottoquery che fanno riferimento ad altre tabelle.

• I filtri dei criteri di accesso a livello di riga non partecipano al pruning delle query su tabelle partizionate e con clustering. Ciò non significa che legge più dati durante l'esecuzione della query principale. Non sfrutta i predicati dei criteri di accesso alle righe per eseguire ulteriori pruning.

• Con i filtri dei criteri di accesso a livello di riga, non tutti i filtri utente vengono applicati in anticipo. Ciò potrebbe aumentare i dati letti dalle tabelle e potrebbe comportare la lettura e la fatturazione di 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, consulta Limiti della sicurezza a livello di riga di BigQuery . Le sezioni seguenti documentano le limitazioni aggiuntive della sicurezza a livello di riga.

Limitazioni del rendimento

• Alcune funzionalità di BigQuery non vengono accelerate quando si utilizzano tabelle contenenti criteri di accesso a livello di riga, come BigQuery BI Engine e le viste materializzate.

• La sicurezza a livello di riga non partecipa al pruning delle query , una funzionalità delle tabelle partizionate. Per ulteriori informazioni, consulta Tabelle partizionate e con clustering tables. Questa limitazione non rallenta l'esecuzione della query principale.

• Potresti riscontrare un leggero peggioramento del rendimento quando esegui query sulle tabelle con sicurezza a livello di riga.

Per ulteriori informazioni su come la sicurezza a livello di riga interagisce con alcune funzionalità e servizi di BigQuery, consulta Utilizzare la sicurezza a livello di riga con altre funzionalità di BigQuery.

Altre limitazioni

• Questa funzionalità potrebbe non essere disponibile quando utilizzi 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 sulle tabelle con criteri di accesso a livello di riga devono utilizzare GoogleSQL. Le query SQL precedenti vengono rifiutate con un errore.

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

• Le query sulle tabelle con funzione carattere jolly non sono supportate per le tabelle con criteri di accesso alle righe.

• I criteri di accesso alle righe non possono essere applicati alle tabelle temporanee.

• Non puoi applicare criteri di accesso a livello di riga alle tabelle che fanno riferimento ad altre tabelle con sicurezza a livello di riga.

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

  • I criteri di accesso alle righe che incorporano le sottoquery non sono compatibili con l'API BigQuery Storage Read. L'API BigQuery Storage Read supporta solo i predicati di filtro semplici.

• Le operazioni non di query, inclusi i job dei account di servizio, che richiedono l'accesso completo ai dati delle tabelle possono utilizzare la sicurezza a livello di riga con il TRUE filtro. Esempi includono la copia delle tabelle, i flussi di lavoro di Managed Service per Apache Spark, e altro ancora. Per ulteriori informazioni, consulta Utilizzare la sicurezza a livello di riga.

• Puoi creare, sostituire o eliminare i criteri di accesso a livello di riga con le istruzioni DDL o le API dei criteri di accesso alle righe. Puoi anche eseguire tutte le azioni disponibili nelle API dei criteri di accesso alle righe nello strumento a riga di comando bq. Puoi elencare e visualizzare i criteri di accesso a livello di riga nella Google Cloud console.

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

• Il campionamento delle tabelle non è compatibile con la sicurezza a livello di riga.

• I criteri di accesso a livello di riga impongono un limite di 100 MB ai risultati delle sottoquery di primo livello al loro interno. Il superamento di questa soglia causerà l'errore della query. È importante notare che questa limitazione viene applicata per ogni criterio e non influisce sulla query dell'utente.

• Le sottoquery IN di primo livello in cui il tipo di search_value è FLOAT, STRUCT, ARRAY, JSON o GEOGRAPHY non sono disponibili nei criteri di accesso alle righe.

• Se il predicato dei criteri di accesso a livello di riga non può essere valutato a causa dell'eliminazione di una tabella a cui viene fatto 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 BigLake.

• Non sono consentite le istruzioni di ridenominazione delle colonne e di eliminazione che modificano lo schema della tabella e potrebbero influire sui criteri di accesso alle righe.

• Il mascheramento dei dati è compatibile solo con le query che hanno criteri di accesso alle righe non di sottoquery. Il mascheramento dei dati viene applicato in aggiunta alla sicurezza a livello di riga. Ad esempio, se è applicato un criterio di accesso alle righe su location = "US" e location è mascherato, gli utenti possono vedere le righe in cui location = "US" ma il campo della località è mascherato nei risultati. Le query che coinvolgono un criterio di accesso alle righe della sottoquery richiedono l'accesso Lettore granulare alle colonne a cui fanno riferimento i criteri di accesso alle righe.

Audit log e monitoraggio

Quando vengono letti i dati in 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 e le tabelle corrispondenti a cui viene fatto riferimento nelle sottoquery vengono visualizzati nelle informazioni di autorizzazione IAM per la richiesta di lettura.

La creazione e l'eliminazione dei criteri di accesso a livello di riga vengono registrate nell'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 utente o altre informazioni sensibili. L'elenco e la visualizzazione dei criteri di accesso a livello di riga non vengono registrati nell'audit log.

Per ulteriori informazioni sulla registrazione in BigQuery, consulta Introduzione al monitoraggio di BigQuery.

Per ulteriori informazioni sulla registrazione Google Cloud, consulta Cloud Logging.

Passaggi successivi

• Per informazioni sulla gestione della sicurezza a livello di riga, consulta Utilizzare la sicurezza a livello di riga.

• Per informazioni su come la sicurezza a livello di riga funziona con altre funzionalità e servizi di BigQuery, consulta Utilizzare la sicurezza a livello di riga con altre funzionalità di BigQuery.

• Per informazioni sulle best practice per la sicurezza a livello di riga, consulta Best practice per la sicurezza a livello di riga in BigQuery.