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 utilizzarla 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 consentire l'accesso a righe specifiche di una tabella in base alle condizioni utente idonee.

BigQuery supporta i controlli di 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 il controllo dell'accesso granulare a un sottoinsieme di dati in una tabella BigQuery tramite 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 di accesso alivello di set di dati, livello di tabella e livello di progetto.

Come funziona la sicurezza a livello di riga

In 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 fa parte di un elenco autorizzato. Eventuali utenti o gruppi non inclusi specificamente in all'elenco di account autorizzati è negato l'accesso.

Un utente autorizzato, con i ruoli di 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. 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, consulta Utilizzare la sicurezza a livello di riga.

Consulta le Riferimento DDL per la sintassi, l'utilizzo e le opzioni completi relativi alla creazione di criteri di accesso a livello di riga.

Esempi di casi d'uso

I seguenti esempi 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 contiene 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 i criteri. La seguente dichiarazione implementa un criterio che limita gli utenti del gruppo di mailing 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.

Le seguenti implementano un criterio che restringe sia gli individui che i gruppi a Visualizza 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'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 relativo alla sicurezza a livello di riga per le regioni.

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

Filtra i dati delle righe in base a dati sensibili

Consideriamo ora un caso d'uso diverso, in cui hai una tabella che contiene lo stipendio informazioni.

Puoi creare e completare 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 l'esecuzione di query ai membri del dominio aziendale. Inoltre, l'utilizzo della funzione SESSION_USER() limita l'accesso solo alle righe che appartengono all'utente che esegue la query, in base all'indirizzo email dell'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 lo stipendio informazioni. 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

Filtra i dati delle righe in base alla tabella di ricerca

Per fornire feedback o richiedere assistenza in merito a questa funzione, invia un'email a 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 utilizzare come tabelle di ricerca. I dati utilizzati nelle regole di filtro possono essere archiviati in una tabella un singolo criterio di accesso alle righe di sottoquery può sostituire più accessi alle righe configurate criteri. 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

Visualizzazioni autorizzate, criteri di accesso a livello di riga e l'archiviazione dei dati in tabelle separate offrono tutti diversi livelli di sicurezza, prestazioni e convenienza. È importante scegliere il meccanismo giusto per il tuo caso d'uso per garantire il livello di sicurezza adeguato 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 visualizzazioni 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 il logging di controllo.

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

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

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

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

Metodo Considerazioni sulla sicurezza Consiglio
Autorizzato
visualizzazioni		 Consigliato per una maggiore flessibilità. Può essere vulnerabile a creazioni le query, la durata delle query e altri tipi di attacchi a canale laterale. 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.
Criteri di accesso a livello di riga Consigliato per un equilibrio tra flessibilità e sicurezza. Può essere vulnerabile a attacchi al canale laterale con durata delle query. I criteri di accesso a livello di riga sono una buona scelta quando devi condividere dati con altri utenti e vuoi fornire una maggiore sicurezza alle visualizzazioni o alle sezioni della tabella. Ad esempio, puoi utilizzare i criteri di accesso a livello di riga per condividere i dati utenti che usano tutti la stessa dashboard, anche se alcuni hanno accesso ad altri dati di altri utenti.
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 i 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 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 Utilizzare la sicurezza di 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 ulteriori ad accesso meno frequente per ridurre i costi di archiviazione. 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 su partizionate e in cluster, tabelle. Ciò non significa che legge più dati durante l'esecuzione della query principale. Non sfrutta i predicati dei criteri di accesso alle righe per ulteriori operazioni di potatura.

  • 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 e potrebbe generare un aumento dei costi 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 vengono accelerate quando si utilizzano tabelle contenenti criteri di accesso a livello di riga, ad esempio BigQuery BI Engine e viste tabelle materializzate.

  • La sicurezza a livello di riga non partecipa alla query potatura, una funzionalità di tabelle partizionate. Per ulteriori informazioni, consulta Partizionati e in cluster tabelle. 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 alcune funzionalità e servizi BigQuery, consulta Utilizzare la sicurezza a livello di riga con altre funzionalità BigQuery.

Altre limitazioni

  • Questa funzionalità potrebbe non essere disponibile se utilizzi prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni su le 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 nelle colonne JSON.

  • 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.

  • Operazioni non di query, inclusi i job degli account di servizio, che richiedono l'accesso completo ai dati delle tabelle può utilizzare la sicurezza a livello di riga Filtro TRUE. Alcuni esempi sono la copia delle tabelle, i workflow di dataproc e altro ancora. Per ulteriori informazioni, consulta Utilizzare la sicurezza a livello di riga.

  • La creazione, la sostituzione o l'eliminazione dei criteri di accesso a livello di riga deve essere eseguita con 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.

  • Visualizzare l'anteprima o sfogliare le 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 ogni criterio 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 una 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 le tabelle BigQuery, le tabelle esterne BigLake e le tabelle gestite BigLake.

Logging e monitoraggio degli audit

Quando vengono letti i dati di una tabella con uno o più criteri di accesso a livello di riga, criteri di accesso a livello di riga autorizzati per l'accesso in lettura e qualsiasi le tabelle a cui viene fatto riferimento nelle sottoquery vengono visualizzate nel Informazioni sull'autorizzazione IAM per quella richiesta di lettura.

La creazione e l'eliminazione dei criteri di accesso a livello di riga vengono registrate in un audit log e sono accessibili tramite Cloud Logging. I log di controllo includono il nome del criterio di accesso a livello di riga. Tuttavia, Definizioni di filter_expression e grantee_list di un accesso a livello di riga vengono omessi dai log, in quanto potrebbero contenere dati dell'utente o altri informazioni. L'elenco e la visualizzazione dei criteri di accesso a livello di riga non vengono registrati per i controlli.

Per ulteriori informazioni sui log in BigQuery, consulta Introduzione al monitoraggio di BigQuery.

Per saperne di più sul logging in Google Cloud, consulta Cloud Logging.

Passaggi successivi