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 utente qualificanti.

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 criteri. La sicurezza a livello di riga estende il principio del privilegio minimo consentendo 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. 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 dataset, livello di tabella e livello di 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 su una tabella BigQuery di destinazione. Questi criteri fungono da filtri per nascondere o mostrare determinate righe di dati, a seconda che un utente o un gruppo faccia parte di un elenco autorizzato. A tutti gli utenti o gruppi non inclusi specificamente nell'elenco consentito viene negato l'accesso.

Un utente autorizzato, con i ruoli Identity and Access Management (IAM) 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 una tabella per nome e quali utenti o gruppi (definiti grantee-list) possono accedere a determinati dati delle righe. Il criterio include anche i dati che vuoi filtrare, chiamati filter_expression. La funzione filter_expression funziona come una clausola WHERE in una query tipica.

Per istruzioni su come creare e utilizzare una policy di accesso a livello di riga, vedi Gestire la sicurezza a livello di riga.

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

Esempi di casi d'uso

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

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 compilare 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 norme. La seguente istruzione implementa un criterio che limita gli utenti del gruppo di distribuzione APAC a vedere 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.

La seguente istruzione implementa un criterio che limita sia le persone che i gruppi a visualizzare solo i partner della regione degli 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.

L'immagine seguente mostra in che modo i due criteri di accesso precedenti limitano gli utenti e i gruppi che possono visualizzare le righe della tabella:

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

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 compilare 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');

Il criterio 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 il criterio di accesso a livello di riga limita la tabella contenente 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

Filtrare i dati delle righe in base alla tabella di ricerca

Grazie al 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 filtraggio 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 è necessario aggiornare ogni singolo criterio di accesso alle righe.

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

Viste autorizzate, policy di accesso a livello di riga e archiviazione dei dati in tabelle separate forniscono tutti diversi livelli di sicurezza, prestazioni e praticità. La scelta del meccanismo giusto per il tuo caso d'uso è importante per garantire il livello di sicurezza adeguato per i tuoi dati.

Confronto con le visualizzazioni autorizzate: vulnerabilità

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

Quando utilizzi viste autorizzate o criteri di accesso a livello di riga per la sicurezza a livello di riga, ti consigliamo di monitorare eventuali attività sospette utilizzando la registrazione di audit.

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 partizionata la tabella o un numero elevato di query.

Per saperne di più su come prevenire questi attacchi side-channel, consulta le 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 di viste autorizzate, policy di accesso a livello di riga e tabelle separate.

Metodo Considerazioni sulla sicurezza Consiglio
Visualizzazioni
autorizzate		 Consigliato per la flessibilità. Possono essere vulnerabili a query, durate delle query e altri tipi di attacchi side-channel realizzati con cura. Le visualizzazioni 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.
Policy di accesso a livello di riga Consigliato per un equilibrio tra flessibilità e sicurezza. Può essere vulnerabile ad attacchi side channel sulla 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 per le visualizzazioni o le sezioni delle tabelle. Ad esempio, puoi utilizzare i criteri di accesso a livello di riga per condividere i dati con persone che utilizzano tutte la stessa dashboard, anche se alcune persone hanno accesso a più dati rispetto ad altre.
Tabelle separate Consigliato per la sicurezza. Gli utenti non possono dedurre dati senza accedere alla tabella. Le tabelle separate sono una buona scelta quando devi condividere dati con altri e devi mantenerli 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 rimanere segreto.

Creare e gestire criteri di accesso a livello di riga

Per informazioni su come creare, aggiornare (ricreare), elencare, visualizzare ed eliminare 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, vedi Utilizzo della sicurezza di accesso a livello di riga.

Quote

Per ulteriori informazioni su quote e limiti per la sicurezza a livello di riga, consulta la sezione 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 di 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 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 dei criteri di accesso alle righe per eseguire ulteriori potature.

  • 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 leggere e fatturare più righe.

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

Limitazioni

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

Limitazioni delle prestazioni

  • Alcune funzionalità di BigQuery non vengono accelerate quando si lavora con tabelle contenenti criteri di accesso a livello di riga, ad esempio BigQuery BI Engine e viste materializzate.

  • La sicurezza a livello di riga non partecipa al taglio delle query, una funzionalità delle tabelle partizionate. Per saperne di più, consulta Tabelle partizionate e in cluster. Questa limitazione non rallenta l'esecuzione della query principale.

  • Potresti notare 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 alcuni servizi e funzionalità BigQuery, consulta Utilizzo della sicurezza a livello di riga con altre funzionalità BigQuery.

Altre limitazioni

  • Questa funzionalità potrebbe non essere disponibile quando utilizzi prenotazioni create con alcune versioni di BigQuery. Per ulteriori informazioni sulle funzionalità abilitate in ogni edizione, vedi Introduzione alle versioni di BigQuery.

  • I criteri di accesso alle righe non sono compatibili con SQL precedente. Le query delle tabelle con policy 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 caratteri jolly non sono supportate per le tabelle con criteri di accesso alle righe.

  • Le policy di accesso alle righe non possono essere applicate 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, vedi Utilizzo della sicurezza a livello di riga.

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

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

  • 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 risultati dei criteri delle sottoquery di primo livello sono limitati a 100 MB. Questo limite si applica per policy di accesso a livello di riga.

  • Le sottoquery IN di primo livello in cui il tipo di search_value è FLOAT, STRUCT, ARRAY, JSON o GEOGRAPHY non sono disponibili nelle norme 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 a cui viene fatto riferimento, la query non va a buon fine.

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

  • Le istruzioni di rinomina e eliminazione delle colonne che modificano lo schema della tabella e potrebbero influire sui criteri di accesso alle righe non sono consentite.

Logging e monitoraggio degli audit

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 dei criteri di accesso a livello di riga vengono registrate negli audit log e sono accessibili tramite Cloud Logging. I log di controllo includono il nome della policy di accesso a livello di riga. Tuttavia, le definizioni di filter_expression e grantee_list di una norma di accesso a livello di riga vengono omesse dai log, in quanto potrebbero contenere informazioni sensibili dell'utente o di altro tipo. L'elenco e la visualizzazione delle policy di accesso a livello di riga non vengono registrati nel log di controllo.

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

Per saperne di più sull'accesso Google Cloud, consulta Cloud Logging.

Passaggi successivi