Best practice per la sicurezza a livello di riga in BigQuery

Questo documento illustra le best practice relative all'uso di sicurezza a livello di riga.

Prima di leggere questo documento, acquisisci familiarità 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 degli utenti per limitare gli attacchi side-channel

Un attacco side-channel è un attacco alla sicurezza basato sulle informazioni acquisite tramite sistema stesso. Un aggressore con autorizzazioni più ampie del necessario può montare facilmente attacchi side-channel e apprendere i dati sensibili osservando o cercare messaggi di fatturazione, logging o di sistema.

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

Consigliamo agli amministratori di evitare di concedere le seguenti autorizzazioni agli utenti che dovrebbero vedere solo i dati filtrati, per evitare di concedere l'accesso a dati sensibili dati.

Autorizzazioni Dati sensibili
Ruolo di Proprietario progetto o Autore progetto I proprietari del progetto possono visualizzare i byte elaborati e i dati correlati negli audit log. Gli autori possono creare nuovi progetti di cui sono proprietari. e visualizzare log di controllo e fatturazione.
Ruoli di modifica, Proprietario o Visualizzatore dei dati di BigQuery Visualizzare i messaggi di errore nelle query.
Autorizzazioni di visualizzatore fatturazione Cloud Visualizza la fatturazione BigQuery.

Esempi

  • Tramite l'osservazione ripetuta della durata delle query durante l'esecuzione di query su tabelle con criteri di accesso a livello di riga, un utente può dedurre i valori delle righe che altrimenti potrebbero essere protetti da criteri di accesso a livello di riga. Questo tipo di richiede molti tentativi ripetuti su una serie di coppie chiave-valore di partizionamento o clustering delle colonne. Anche se esiste un rumore durante l'osservazione o la misurazione della durata delle query, con tentativi ripetuti, potrebbe ottenere una stima affidabile. Se sei sensibile a questo livello di protezione, consigliamo di utilizzare tabelle separate per isolare le righe diversi requisiti di controllo dell'accesso.
  • Un utente malintenzionato potrebbe cercare i byte elaborati da una mediante il monitoraggio degli errori che si verificano quando i limiti del job di query (come il numero massimo byte fatturati o controlli dei costi personalizzati). Tuttavia, questo attacco richiede un elevato volume di query.
  • Mediante query ripetute e l'osservazione della fatturazione BigQuery in fatturazione Cloud, un utente può dedurre i valori delle righe che altrimenti potrebbe essere protetto da criteri di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti su un intervallo di valori chiave nel partizionamento o il clustering delle colonne. Se sei sensibile a questo livello di protezione, ti consigliamo di limitare l'accesso ai dati di fatturazione per query.

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

Limitare le autorizzazioni degli utenti per limitare le manomissioni dei dati

Gli utenti con autorizzazioni di scrittura per una tabella possono inserire dati nella tabella utilizzando Comando bq load o con l'API BigQuery Storage Writer. Ciò può consentire all'utente autorizzazioni di scrittura per modificare i risultati delle query di altri utenti.

Consigliamo agli amministratori di creare gruppi Google separati per l'accesso in scrittura delle tabelle di accesso a livello di riga. Utenti che devono visualizzare solo la tabella filtrata I risultati non devono avere accesso in scrittura alla tabella filtrata.

Evita l'accesso involontario quando ricrei criteri di accesso a livello di riga.

Quando aggiungi un criterio di accesso alle righe in una tabella per la prima volta, iniziare a filtrare i dati nei risultati della query. Se rimuovi l'ultimo accesso a livello di riga in una tabella, anche se vuoi ricreare solo l'accesso a livello di riga. , potresti inavvertitamente concedere l'accesso senza filtri a un utente più ampio del previsto pubblico.

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

  1. Innanzitutto rimuovi tutti gli accessi alla tabella, utilizzando controlli di accesso alle tabelle.
  2. Rimuovi tutti i criteri di accesso a livello di riga.
  3. Ricrea i criteri di accesso a livello di riga desiderati.
  4. Riattiva l'accesso alla tabella.

In alternativa, puoi prima creare nuovi criteri di accesso a livello di riga nella tabella, 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 le organizzazioni

Non utilizzare la funzionalità di sicurezza a livello di riga tra le organizzazioni, per evitare la perdita di dati attraverso attacchi side-channel e di mantenere un maggiore controllo l'accesso ai dati sensibili.

Per i criteri di accesso a livello di riga delle sottoquery, crea ed esegui ricerche nelle tabelle all'interno di organizzazioni o progetti. Ciò porta a una maggiore sicurezza e a una ACL più semplice perché i beneficiari devono avere l'autorizzazione bigquery.tables.getData il target e le tabelle di riferimento nei criteri, nonché eventuali autorizzazioni di sicurezza a livello di colonna.

Consigliamo di utilizzare la funzionalità di sicurezza a livello di riga per l'interno dell'organizzazione solo vincoli di sicurezza (come la condivisione dei dati all'interno di organizzazione/azienda/azienda) e non per interorganizzazioni o aree pubbliche sicurezza.

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 alla fatturazione informazioni delle query rispetto alle tabelle con criteri di accesso a livello di riga. Fatturazione. informazioni è un vettore di attacchi side-channel.

Utilizza il ruolo Filtered Data Viewer con cautela

Quando crea un criterio di accesso a livello di riga, alle entità del criterio viene concesso automaticamente bigquery.filteredDataViewer. Puoi aggiungere o rimuovere entità solo da le norme con un'istruzione DDL.

Tuttavia, è possibile concedere il ruolo bigquery.filteredDataViewer tramite IAM a una risorsa di livello superiore, come come tabella, set di dati o progetto. Concessione del ruolo bigquery.filteredDataViewer a un utente gli offre la possibilità di visualizzare le righe definite da i criteri di accesso a livello di riga in quella tabella, set di dati o progetto.

Tuttavia, la concessione del ruolo bigquery.filteredDataViewer in una tabella non significa necessariamente che l'utente può vedere tutte le righe della tabella. L'unione di tutti i criteri di accesso a livello di riga, le espressioni di filtro possono formare o meno dell'intera tabella.

Ti consigliamo di fare attenzione prima di concedere ai bigquery.filteredDataViewer su qualsiasi risorsa.

L'applicazione di filtri alle colonne partizionate influisce sulle prestazioni

I filtri dei criteri di accesso a livello di riga non partecipano alla query eliminando le tabelle partizionate e in cluster.

Se il criterio di accesso a livello di riga nomina una colonna partizionata, la query non sfrutta i vantaggi in termini di prestazioni dell'eliminazione delle query.