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 alle condizioni di qualificazione dell'utente.

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 dell'accesso granulare a un sottoinsieme di dati in una tabella BigQuery mediante policy di accesso a livello di riga.

Una tabella può avere più policy di accesso a livello di riga. Le policy 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, 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 implica la creazione di policy di accesso a livello di riga sulla tabella BigQuery di destinazione. Queste policy fungono da filtri per nascondere o mostrare determinate righe di dati, a seconda se un utente o un gruppo fa parte di un elenco consentito. A tutti gli utenti o gruppi non inclusi specificamente nell'elenco consentito viene negato l'accesso.

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

Quando crei una policy 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. La policy 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 che 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 una policy 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 quando crei policy 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:kiran@example.com, group:support@example.com, 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', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

La sicurezza a livello di riga consente a un proprietario o amministratore dei dati di implementare le policy. La seguente istruzione implementa una policy 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:sales-apac@example.com")
FILTER USING
  (region="APAC" );

Il comportamento risultante è che gli utenti del gruppo sales-apac@example.com possono visualizzare solo le righe in cui il valore di region è APAC.

Comportamento della sicurezza a livello di riga per la regione Asia Pacifico.

La seguente istruzione implementa una policy che limita sia le persone fisiche sia i gruppi a visualizzare solo i partner della regione Stati Uniti:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user:jon@example.com")
FILTER USING
  (region="US");

Il comportamento risultante è che gli utenti del gruppo sales-us@example.com e l'utente jon@example.com possono visualizzare solo le righe in cui il valore di region è US.

Comportamento della sicurezza a livello di riga per la regione Stati Uniti.

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 altro caso d'uso, 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, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

La policy di accesso alle righe nella seguente istruzione limita le 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 la policy 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 jim@example.com.

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

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, le policy 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 una singola policy di accesso alle righe della sottoquery può sostituire più policy di accesso alle righe configurate. Per aggiornare le policy di accesso alle righe, devi solo aggiornare la tabella di ricerca, che sostituisce più policy di accesso alle righe. Non devi aggiornare ogni singola policy 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, le policy 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 le policy 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 ai margini 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à, le prestazioni e la sicurezza delle viste autorizzate, delle policy 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 le prestazioni sono importanti. Ad esempio, puoi utilizzare le viste autorizzate per condividere i dati all'interno del tuo gruppo di lavoro.
Policy 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.	Le policy 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 le policy 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 policy di accesso a livello di riga

Per informazioni su come creare, aggiornare (ricreare), elencare, visualizzare ed eliminare le policy di accesso a livello di riga in una tabella e su come eseguire query sulle tabelle con policy di accesso a livello di riga, consulta Utilizzare la sicurezza di accesso a livello di riga.

Eliminazione implicita delle policy di accesso a livello di riga

Le policy di accesso alle righe possono essere rimosse implicitamente (automaticamente) da una tabella in diverse condizioni.

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

Le operazioni che utilizzano una WRITE_TRUNCATE disposizione di scrittura sovrascrivono sempre le policy di accesso alle righe esistenti nella tabella di destinazione.
Per le operazioni con una disposizione di scrittura WRITE_APPEND, le policy di accesso alle righe correnti della tabella di destinazione vengono mantenute e le policy della tabella di origine vengono aggiunte alla tabella di destinazione.

In particolare, le policy di accesso alle righe vengono rimosse implicitamente nelle seguenti situazioni:

Sostituzione di una tabella: quando una tabella viene sostituita utilizzando l'istruzione DDL CREATE OR REPLACE TABLE, tutte le policy di accesso alle righe esistenti nella tabella originale vengono eliminate. 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 tutte le policy 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 le policy di accesso alle righe non vengono trasferite.
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 eliminate anche tutte le policy di accesso alle righe associate.
Operazioni di copia della tabella: quando copi una tabella senza policy di accesso alle righe in una tabella di destinazione che ha policy di accesso alle righe, le policy nella tabella di destinazione vengono rimosse, 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 le policy 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, una policy 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 policy di accesso a livello di riga, in particolare policy che includono sottoquery che fanno riferimento ad altre tabelle.
I filtri delle policy 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 delle policy di accesso alle righe per eseguire ulteriori pruning.
Con i filtri delle policy 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 leggere e fatturare 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 delle prestazioni

Alcune funzionalità di BigQuery non vengono accelerate quando si utilizzano tabelle contenenti policy 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 calo delle prestazioni 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.
Le policy di accesso alle righe non sono compatibili con SQL precedente. Le query sulle tabelle con policy di accesso a livello di riga devono utilizzare GoogleSQL. Le query SQL precedenti vengono rifiutate con un errore.
Non puoi applicare policy di accesso a livello di riga alle colonne JSON.
Le query sulle tabelle con funzione carattere jolly non sono supportate per le tabelle con policy di accesso alle righe.
Le policy di accesso alle righe non possono essere applicate alle tabelle temporanee.
Non puoi applicare policy 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.
- Le policy di accesso alle righe che incorporano le sottoquery non sono compatibili con l'API BigQuery Storage di lettura. L'API BigQuery Storage di lettura 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. Alcuni esempi includono la copia delle tabelle, i workflow Dataproc, e altro ancora. Per ulteriori informazioni, consulta Utilizzare la sicurezza a livello di riga.
Puoi creare, sostituire o eliminare le policy di accesso a livello di riga con le istruzioni DDL o le API delle policy di accesso alle righe. Puoi anche eseguire tutte le azioni disponibili nelle API delle policy di accesso alle righe nello strumento a riga di comando bq. Puoi elencare e visualizzare le policy 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.
Le policy 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 policy 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 nelle policy di accesso alle righe.
Se il predicato della policy 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.
Le policy 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 e eliminazione delle colonne che modificano lo schema della tabella e potrebbero influire sulle policy di accesso alle righe.
Il mascheramento dei dati è compatibile solo con le query che hanno policy di accesso alle righe non di sottoquery. Il mascheramento dei dati viene applicato in aggiunta alla sicurezza a livello di riga. Ad esempio, se è applicata una policy di accesso alle righe su location = "US" e location è mascherata, gli utenti possono vedere le righe in cui location = "US" ma il campo della località è mascherato nei risultati. Le query che coinvolgono una policy di accesso alle righe della sottoquery richiedono l'accesso Lettore granulare alle colonne a cui fanno riferimento le policy di accesso alle righe.

Audit log e monitoraggio

Quando vengono letti i dati in una tabella con una o più policy di accesso a livello di riga, le policy di accesso a livello di riga autorizzate per l'accesso in lettura e le tabelle corrispondenti a cui viene fatto riferimento nelle sottoquery vengono visualizzate nelle informazioni di autorizzazione IAM per la richiesta di lettura.

La creazione e l'eliminazione delle policy di accesso a livello di riga vengono registrate nell'audit log e sono accessibili tramite Cloud Logging. Gli audit log includono il nome della policy di accesso a livello di riga. Tuttavia, le definizioni di filter_expression e grantee_list di una policy 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 delle policy 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.