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 lato canale è un attacco alla sicurezza basato sulle informazioni acquisite dal sistema stesso. Un malintenzionato con autorizzazioni più ampie del necessario può eseguire più facilmente attacchi lato canale e ottenere dati sensibili osservando o cercando messaggi di fatturazione, log 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 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 del progetto o Creator del 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 di 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 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 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.
Limita 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 delle tabelle 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. Se rimuovi l'ultimo accesso a livello di riga in una tabella, anche se vuoi ricreare solo l'accesso a livello di riga. di sicurezza, 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 criterio di accesso a livello di riga in una tabella seguendo queste linee guida:
- Per prima cosa, rimuovi tutto l'accesso 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 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 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ò comporta una maggiore sicurezza e una configurazione più semplice delle 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 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 alle informazioni di fatturazione delle query sulle 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à dal
criterio
solo con un'istruzione DDL.
Tuttavia, è possibile concedere il ruolo bigquery.filteredDataViewer tramite
IAM a una risorsa di livello superiore, come
una tabella, un set di dati o un 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, l'assegnazione del ruolo bigquery.filteredDataViewer a una tabella non significa necessariamente che l'utente possa vedere tutte le righe della tabella. L'unione di tutte le espressioni di filtro dei criteri di accesso a livello di riga può o meno formare una chiusura sull'intera tabella.
Ti consigliamo di fare attenzione prima di concedere ai
bigquery.filteredDataViewer su qualsiasi risorsa.
L'applicazione di filtri alle colonne partizionate influisce sul rendimento
I filtri dei criteri di accesso a livello di riga non vengono presi in considerazione per la potatura delle query nelle tabelle partizionate e raggruppate.
Se il criterio di accesso a livello di riga nomina una colonna partizionata, la query non i vantaggi in termini di prestazioni dell'eliminazione delle query.