Best practice per la sicurezza a livello di riga in BigQuery

Questo documento illustra le best practice per l'utilizzo della sicurezza a livello di riga.

Prima di leggere questo documento, familiarizza con la sicurezza a livello di riga leggendo Introduzione alla sicurezza a livello di riga di BigQuery e Utilizzo della sicurezza a livello di riga.

Limita le autorizzazioni utente per limitare gli attacchi lato canale

Un attacco lato canale è un attacco alla sicurezza basato sulle informazioni acquisite dal sistema stesso. Un malintenzionato con autorizzazioni più ampie del necessario può eseguire attacchi lato canale e ottenere dati sensibili osservando o cercando dati di fatturazione, log o messaggi di sistema.

Per ridurre queste opportunità, BigQuery nasconde le statistiche sensibili su tutte le query sulle tabelle con sicurezza a livello di riga. Queste statistiche sensibili includono il numero di byte e partizioni elaborati, il numero di byte fatturati e le fasi del piano di query.

Per evitare di concedere l'accesso a dati sensibili, consigliamo agli amministratori di astenersi dal concedere le seguenti autorizzazioni agli utenti che devono visualizzare solo i dati filtrati.

Autorizzazioni Dati sensibili
Ruolo Proprietario progetto o Autore progetto I proprietari del progetto possono visualizzare i byte elaborati e i dati correlati nei log di controllo. I creator di progetti possono creare nuovi progetti di cui sono proprietari e visualizzare i log di fatturazione e controllo.
Ruoli Editor, Proprietario o Visualizzatore dei dati BigQuery Visualizza i messaggi di errore sulle query.
Autorizzazioni visualizzatore di Fatturazione Cloud Visualizza la fatturazione di BigQuery.

Esempi

  • Attraverso ripetute osservazioni della durata delle query quando esegui query sulle tabelle con criteri di accesso a livello di riga, un utente potrebbe dedurre i valori delle righe che altrimenti potrebbero essere protetti da questi criteri. Questo tipo di attacco richiede molti tentativi ripetuti su un intervallo di valori chiave nelle colonne di partizione o clustering. Anche se esiste un disturbo intrinseco quando si osserva o misura la durata delle query, con tentativi ripetuti un malintenzionato potrebbe ottenere una stima affidabile. Se questo livello di protezione è importante per te, ti consigliamo di utilizzare tabelle separate per isolare le righe con requisiti di controllo dell'accesso diversi.
  • Un malintenzionato potrebbe cercare i byte elaborati da una query monitorando gli errori che si verificano quando vengono superati i limiti del job di query (ad esempio i byte massimi fatturati o i controlli dei costi personalizzati). Tuttavia, questo attacco richiede un volume elevato di query.
  • Tramite query ripetute e osservando l'importo della fatturazione di BigQuery in Fatturazione Cloud, un utente potrebbe dedurre i valori delle righe che altrimenti potrebbero essere protetti dai criteri di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti su un intervallo di valori chiave nelle colonne di partizione o di clustering. Se questo livello di protezione è importante per te, ti consigliamo di limitare l'accesso ai dati di fatturazione per le query.

Consigliamo inoltre agli amministratori di monitorare Cloud Audit Logs(/bigquery/docs/reference/auditlogs) per rilevare attività sospette nelle tabelle con sicurezza a livello di riga, ad esempio aggiunte, modifiche ed eliminazioni impreviste di criteri di accesso a livello di riga.

Limitare le autorizzazioni utente per limitare la manomissione dei dati

Gli utenti con autorizzazioni di scrittura per una tabella possono inserire dati al suo interno con il comando bq load o con l'API BigQuery Storage Write. In questo modo, l'utente con autorizzazioni di scrittura può modificare i risultati delle query di altri utenti.

Consigliamo agli amministratori di creare gruppi Google separati per l'accesso in scrittura alle tabelle e per i criteri di accesso a livello di riga. Gli utenti che devono visualizzare solo i risultati della tabella filtrata non devono avere accesso in scrittura alla tabella filtrata.

Evitare l'accesso involontario durante la ricreazione dei criteri di accesso a livello di riga

Quando aggiungi un criterio di accesso alle righe a una tabella per la prima volta, inizi immediatamente a filtrare i dati nei risultati della query. Quando rimuovi l'ultimo criterio di accesso a livello di riga in una tabella, anche se intendi solo ricrearlo, potresti concedere inavvertitamente accesso non filtrato a un segmento di pubblico più ampio del previsto.

Consigliamo agli amministratori di prestare particolare attenzione quando ricreano l'ultimo criterio di accesso a livello di riga in una tabella seguendo queste linee guida:

  1. Per prima cosa, rimuovi tutto l'accesso alla tabella utilizzando i controlli di accesso alla tabella.
  2. Rimuovi tutti i criteri di accesso a livello di riga.
  3. Ricrea i criteri di accesso a livello di riga.
  4. Riattiva l'accesso alla tabella.

In alternativa, puoi prima creare nuovi criteri di accesso a livello di riga nella tabella, quindi eliminare i criteri di accesso a livello di riga precedenti che non sono più necessari.

Utilizza la sicurezza a livello di riga solo all'interno delle organizzazioni, non tra organizzazioni

Non utilizzare la funzionalità di sicurezza a livello di riga nelle organizzazioni per contribuire a prevenire la fuga di dati tramite attacchi lato canale e mantenere un maggiore controllo sull'accesso ai dati sensibili.

Per i criteri di accesso a livello di riga delle sottoquery, crea e cerca tabelle all'interno di organizzazioni o progetti. Ciò comporta una maggiore sicurezza e una configurazione più semplice degli ACL, in quanto i beneficiari devono disporre dell'autorizzazione bigquery.tables.getData per le tabelle di destinazione e di riferimento nei criteri, nonché di eventuali autorizzazioni di sicurezza a livello di colonna pertinenti.

Consigliamo di utilizzare la funzionalità di sicurezza a livello di riga solo per i vincoli di sicurezza all'interno dell'organizzazione (ad esempio per la condivisione dei dati all'interno di un'organizzazione/impresa/azienda) e non per la sicurezza pubblica o tra organizzazioni.

Esempio

Al di fuori della tua organizzazione, hai meno controllo su chi ha accesso ai dati. All'interno della tua organizzazione, puoi controllare a chi è stato concesso l'accesso alle informazioni di fatturazione delle query sulle tabelle con criteri di accesso a livello di riga. I dati di fatturazione sono un vettore per gli attacchi lato canale.

Gestisci il ruolo Filtered Data Viewer tramite i criteri di accesso a livello di riga

Quando crei un criterio di accesso a livello di riga, viene concesso automaticamente il ruolo bigquery.filteredDataViewer alle entità nel criterio. Puoi aggiungere o rimuovere entità dal criterio di accesso solo con un'istruzione DDL.

Il ruolo bigquery.filteredDataViewer non deve essere concesso tramite IAM a una risorsa di livello superiore, come una tabella, un set di dati o un progetto. La concessione del ruolo in questo modo consente agli utenti di visualizzare le righe definite da tutti i criteri di accesso a livello di riga all'interno di questo ambito, indipendentemente dalle restrizioni previste. Sebbene l'unione dei filtri dei criteri di accesso a livello di riga potrebbe non includere l'intera tabella, questa pratica rappresenta un rischio di sicurezza significativo e mina lo scopo della sicurezza a livello di riga.

Ti consigliamo di gestire il ruolo bigquery.filteredDataViewer esclusivamente tramite i criteri di accesso a livello di riga. Questo metodo garantisce che ai principali venga concesso il ruolo bigquery.filteredDataViewer in modo implicito e corretto, rispettando i predicati di filtro definiti per ogni criterio.

Impatto dei filtri sulle prestazioni delle colonne partizionate

I filtri dei criteri di accesso a livello di riga non partecipano al trimming delle query nelle tabelle partizionate e raggruppate.

Se il criterio di accesso a livello di riga nomina una colonna partizionata, la query non beneficia dei vantaggi in termini di prestazioni della potatura delle query.