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, per acquisire familiarità con la sicurezza a livello di riga consulta gli articoli 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 dal sistema stesso. Un utente malintenzionato con autorizzazioni più ampie del necessario può installare più facilmente attacchi side-channel e apprendere dati sensibili osservando o cercando messaggi di fatturazione, logging o di sistema.
Per mitigare queste opportunità, BigQuery nasconde statistiche sensibili su tutte le query nelle 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.
Consigliamo agli amministratori di non concedere le seguenti autorizzazioni agli utenti che devono visualizzare solo i dati filtrati per evitare di concedere l'accesso a dati sensibili.
| Autorizzazioni | Dati sensibili |
|---|---|
| Ruolo Proprietario progetto o Autore progetto | I proprietari del progetto possono visualizzare i byte elaborati e i dati correlati negli audit log. Gli autori dei progetti possono creare nuovi progetti di cui sono proprietari e visualizzare log di controllo e fatturazione. |
| Ruoli di modifica, proprietario o visualizzatore dei dati BigQuery | Visualizzare i messaggi di errore relativi alle query. |
| Autorizzazioni visualizzatore fatturazione Cloud | Visualizza la fatturazione di BigQuery. |
Esempi
- Tramite un'osservazione ripetuta della durata delle query durante l'esecuzione di query su tabelle con criteri di accesso a livello di riga, un utente potrebbe dedurre i valori delle righe che altrimenti potrebbero essere protette dai criteri di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti in un intervallo di coppie chiave-valore nelle colonne di partizionamento o clustering. Anche se esiste un rumore intrinseco durante l'osservazione o la misurazione della durata delle query, con tentativi ripetuti, un utente malintenzionato potrebbe ottenere una stima affidabile. Se sei sensibile a questo livello di protezione, 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 al superamento dei limiti del job di query (come il numero massimo di byte fatturati o i controlli dei costi personalizzati). Tuttavia, questo attacco richiede un volume elevato di query.
- Attraverso query ripetute e osservando l'importo di fatturazione di BigQuery nel fatturazione Cloud, un utente può dedurre i valori delle righe che altrimenti potrebbero essere protette dai criteri di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti in un intervallo di coppie chiave-valore nelle colonne di partizionamento o clustering. Se sei sensibile a questo livello di protezione, 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 eventuali attività sospette nelle tabelle con sicurezza a livello di riga, come aggiunte, modifiche ed eliminazioni impreviste di criteri di accesso a livello di riga.
Limita le autorizzazioni utente per limitare le manomissioni 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. Ciò può consentire all'utente con autorizzazioni di scrittura di modificare i risultati delle query di altri utenti.
Consigliamo agli amministratori di creare gruppi Google separati per i criteri di accesso in scrittura alle tabelle e a livello di riga. Gli utenti che dovrebbero vedere solo i risultati delle tabelle filtrate non devono avere accesso in scrittura alla tabella filtrata.
Evitare l'accesso involontario quando si ricreano criteri di accesso a livello di riga
Quando aggiungi per la prima volta un criterio di accesso alle righe a una tabella, 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 ricreare il criterio di accesso a livello di riga, potresti inavvertitamente concedere l'accesso senza filtri 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:
- Innanzitutto, rimuovi tutti gli accessi alla tabella utilizzando i controlli di accesso alle tabelle.
- Rimuovi tutti i criteri di accesso a livello di riga.
- Ricrea i criteri di accesso a livello di riga che ti interessano.
- Riattiva l'accesso alla tabella.
In alternativa, puoi prima creare nuovi criteri di accesso a livello di riga nella tabella, quindi eliminare i precedenti criteri di accesso a livello di riga che non sono più necessari.
Utilizza la sicurezza a livello di riga solo all'interno delle organizzazioni, non in più organizzazioni
Non utilizzare la funzionalità di sicurezza a livello di riga in tutte le organizzazioni per prevenire la fuga di dati attraverso attacchi side-channel e mantenere un maggiore controllo sull'accesso ai dati sensibili.
Per i criteri di accesso a livello di riga di sottoquery, crea e cerca tabelle all'interno di organizzazioni o progetti. Ciò porta a una maggiore sicurezza e a una configurazione ACL più semplice, poiché i beneficiari devono disporre dell'autorizzazione bigquery.tables.getData sulla destinazione e nelle tabelle di riferimento nei criteri, nonché di eventuali 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, un'azienda o un'azienda) e non per la sicurezza pubblica o tra organizzazioni.
Esempio
All'esterno 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 ai dati di fatturazione delle query rispetto alle tabelle con criteri di accesso a livello di riga. I dati di fatturazione sono un vettore per gli attacchi side-channel.
Usa il ruolo Filtered Data Viewer con cautela
Quando crei un criterio di accesso a livello di riga, alle entità nel criterio viene concesso automaticamente il ruolo bigquery.filteredDataViewer. Puoi aggiungere o rimuovere entità dal criterio solo con un'istruzione DDL.
Tuttavia, è possibile concedere il ruolo bigquery.filteredDataViewer tramite IAM a una risorsa di livello superiore, ad esempio una tabella, un set di dati o un progetto. La concessione del ruolo bigquery.filteredDataViewer a un utente consente di visualizzare le righe definite da tutti 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 possa visualizzare tutte le righe della tabella. L'unione di tutte le espressioni di filtro dei criteri di accesso a livello di riga può formare o meno una chiusura sull'intera tabella.
Ti consigliamo di fare attenzione prima di concedere il ruolo bigquery.filteredDataViewer su qualsiasi risorsa.
Il filtro in base alle colonne partizionate influisce sulle prestazioni
I filtri dei criteri di accesso a livello di riga non partecipano all'eliminazione delle query sulle tabelle partizionate e in cluster.
Se il criterio di accesso a livello di riga indica una colonna partizionata, la query non riceve i vantaggi in termini di prestazioni dell'eliminazione delle query.