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 Utilizzare la sicurezza a livello di riga.
Considerazioni sulla progettazione delle policy di accesso alle righe
Quando configuri le policy di accesso alle righe su una tabella, avrai bisogno di almeno due policy di accesso alle righe:
- Una policy che concede l'accesso alla tabella. La prima policy di accesso alle righe deve concedere l'accesso agli utenti e ai gruppi che richiedono l'accesso completo ai dati della tabella per la manutenzione o l'assistenza dei dati. Ad esempio, gli amministratori di BigQuery e i service account che utilizzano le istruzioni DML per trasformare i dati delle tabelle.
- Una seconda policy che utilizza filtri basati sulla logica di business e che viene concessa a gruppi specifici.
Per ulteriori informazioni sulla configurazione delle policy di accesso alle righe, consulta Creare o aggiornare una policy di accesso a livello di riga.
Testare i service account con le policy di accesso alle righe
Puoi utilizzare la simulazione dell'identità dei account di servizio per testare la modalità di applicazione delle policy di accesso alle righe. Per testare le policy di accesso alle righe utilizzando un account di servizio:
- Crea un service account.
- Aggiorna la policy di accesso alle righe per concedere l'accesso al account di servizio. In alternativa, aggiungi il account di servizio al gruppo Google a cui è stato concesso l'accesso dalla policy di accesso alle righe.
- Utilizza la simulazione dell'identità del service account per verificare che la policy di accesso alle righe funzioni come previsto.
Limitare le autorizzazioni utente per limitare gli attacchi side channel
Un attacco side channel è un attacco alla sicurezza basato su informazioni ottenute dal sistema stesso. Un utente malintenzionato con autorizzazioni più ampie del necessario può eseguire attacchi side channel e apprendere dati sensibili osservando o cercando messaggi di fatturazione, logging o 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 |
|---|---|
| Proprietario progetto | I proprietari dei progetti possono visualizzare i byte elaborati e i dati correlati solo nei log di audit. I metadati di fatturazione non possono essere visualizzati dai dettagli del job. Non esiste un'autorizzazione o un ruolo specifico per concedere l'accesso di visualizzazione a questi metadati di fatturazione. |
| Ruoli BigQuery Data Edit, Proprietario o Visualizzatore | Visualizza i messaggi di errore nelle query. |
| Autorizzazioni di visualizzazione della fatturazione Cloud | Visualizza la fatturazione di BigQuery. |
Esempi
- Tramite l'osservazione ripetuta della durata delle query sulle tabelle con policy di accesso a livello di riga, un utente potrebbe dedurre i valori delle righe che altrimenti potrebbero essere protette dalle policy di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti su un intervallo di valori chiave nelle colonne di partizionamento o clustering. Anche se l'osservazione o la misurazione della durata delle query presenta un rumore intrinseco, con tentativi ripetuti un utente 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 utente malintenzionato potrebbe cercare i byte elaborati da una query monitorando gli errori che si verificano quando vengono superati i limiti dei 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 nella fatturazione Cloud, un utente potrebbe dedurre i valori delle righe che altrimenti potrebbero essere protette dalle policy di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti su un intervallo di valori chiave nelle colonne di partizionamento o clustering. Se questo livello di protezione è importante per te, ti consigliamo di limitare l'accesso ai dati di fatturazione per le query.
Ti consigliamo inoltre agli amministratori di monitorare Cloud Audit Logs(/bigquery/docs/reference/auditlogs) per rilevare attività sospette sulle tabelle con sicurezza a livello di riga, come aggiunte, modifiche ed eliminazioni impreviste di policy di accesso a livello di riga.
Limitare le autorizzazioni utente per limitare la manomissione dei dati
Gli utenti con autorizzazioni di scrittura su una tabella possono inserire dati nella tabella con il
bq load comando 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.
Ti consigliamo agli amministratori di creare gruppi Google separati per l'accesso in scrittura alle tabelle e le policy di accesso a livello di riga. Gli utenti che devono visualizzare solo i risultati delle tabelle filtrate non devono avere accesso in scrittura alla tabella filtrata.
Evitare l'accesso involontario durante la ricreazione delle policy di accesso a livello di riga
Quando aggiungi una policy di accesso alle righe a una tabella per la prima volta, inizi immediatamente a filtrare i dati nei risultati delle query. Quando rimuovi l'ultima policy di accesso a livello di riga su una tabella, anche se intendi ricrearla, potresti inavvertitamente concedere l'accesso non filtrato a un pubblico più ampio del previsto.
Ti consigliamo agli amministratori di prestare particolare attenzione quando ricreano l'ultima policy di accesso a livello di riga su una tabella, seguendo queste linee guida:
- Rimuovi prima tutti gli accessi alla tabella utilizzando i controlli di accesso alle tabelle.
- Rimuovi tutte le policy di accesso a livello di riga.
- Ricrea le policy di accesso a livello di riga.
- Riattiva l'accesso alla tabella.
In alternativa, puoi prima creare nuove policy di accesso a livello di riga sulla tabella, quindi eliminare le policy di accesso a livello di riga precedenti che non sono più necessarie.
Utilizzare 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 tramite attacchi side channel e per mantenere un maggiore controllo sull'accesso ai dati sensibili.
Per le policy 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 ACL
più semplice, in quanto i beneficiari devono disporre dell'autorizzazione bigquery.tables.getData sulle
tabelle di destinazione e di riferimento nelle policy, nonché di tutte le autorizzazioni di sicurezza
a livello di colonna pertinenti.
Ti 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/azienda/società) 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 policy di accesso a livello di riga. Le informazioni di fatturazione sono un vettore per gli attacchi side channel.
Gestire il ruolo Filtered Data Viewer tramite le policy di accesso a livello di riga
Quando
crei una policy di accesso a livello di riga,
alle entità nella policy viene concesso automaticamente il ruolo
bigquery.filteredDataViewer. Puoi aggiungere o rimuovere le entità da
la policy 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 tutte le policy di accesso a livello di riga all'interno di questo ambito, indipendentemente dalle restrizioni previste. Sebbene l'unione dei filtri delle policy di accesso a livello di riga potrebbe non comprendere l'intera tabella, questa pratica comporta un rischio per la sicurezza significativo e compromette lo scopo della sicurezza a livello di riga.
Ti consigliamo di gestire il ruolo bigquery.filteredDataViewer esclusivamente tramite le policy di accesso a livello di riga. Questo metodo garantisce che alle entità venga concesso il ruolo bigquery.filteredDataViewer in modo implicito e corretto, rispettando i predicati di filtro definiti per ogni policy.
Impatto sulle prestazioni dei filtri sulle colonne partizionate
Se la policy di accesso a livello di riga nomina una colonna partizionata, la query non riceve i vantaggi in termini di prestazioni del pruning delle query.