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, 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 dal sistema stesso. Un utente malintenzionato con autorizzazioni più ampie del necessario può facilmente montare attacchi side-channel e acquisire dati sensibili osservando o cercando messaggi di fatturazione, logging o di sistema.
Per mitigare queste opportunità, BigQuery nasconde le statistiche sensibili su tutte le query rispetto alle 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 non concedere le seguenti autorizzazioni agli utenti che devono visualizzare solo i dati filtrati.
| 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 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 di BigQuery | Visualizzare i messaggi di errore delle query. |
| Autorizzazioni di visualizzatore fatturazione Cloud | Visualizza la fatturazione BigQuery. |
Esempi
- Attraverso la ripetuta osservazione 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 protette da criteri di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti su 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 questo livello di protezione è sensibile, 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 del job di query (come i byte massimi fatturati o i controlli dei costi personalizzati). Tuttavia, questo attacco richiede un elevato volume di query.
- Mediante query ripetute e osservando l'importo della fatturazione BigQuery nella fatturazione Cloud, un utente può dedurre i valori delle righe che altrimenti potrebbero essere protette da criteri di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti su una serie 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 attività sospette sulle tabelle con sicurezza a livello di riga, come aggiunte, modifiche ed eliminazioni impreviste dei 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 con il comando bq load o con l'API BigQuery Storage Writer. 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 devono visualizzare solo i risultati delle tabelle filtrate 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, inizi immediatamente a filtrare i dati nei risultati della query. Se rimuovi l'ultimo criterio di accesso a livello di riga da una tabella, anche se intendi ricreare solo il criterio di accesso a livello di riga, potresti concedere inavvertitamente 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 alla tabella.
- Rimuovi tutti i criteri di accesso a livello di riga.
- Ricrea i criteri di accesso a livello di riga desiderati.
- 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 le organizzazioni
Non utilizzare la funzionalità di sicurezza a livello di riga tra le organizzazioni per prevenire la fuga di dati tramite attacchi side-channel e per 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ò porta a una maggiore sicurezza e a una configurazione dell'ACL più semplice, poiché i beneficiari devono disporre dell'autorizzazione bigquery.tables.getData per le tabelle di destinazione e di riferimento nei criteri, nonché di eventuali autorizzazioni pertinenti di sicurezza a livello di colonna.
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/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 chi è stato autorizzato ad accedere ai dati di fatturazione delle query rispetto alle tabelle con criteri di accesso a livello di riga. I dati di fatturazione fungono da vettore di attacchi side-channel.
Utilizza il ruolo Filtered Data Viewer con cautela
Quando crei un criterio di accesso a livello di riga, alle entità del 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 su 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ò costituire o meno una chiusura dell'intera tabella.
Ti consigliamo di fare attenzione prima di concedere il ruolo 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 all'eliminazione delle query sulle tabelle partizionate e in cluster.
Se il criterio di accesso a livello di riga assegna il nome a una colonna partizionata, la query non riceve i vantaggi in termini di prestazioni dell'eliminazione delle query.