Best practice per la sicurezza a livello di riga in BigQuery
Questo documento spiega 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 Utilizzo della sicurezza a livello di riga.
Limitare le autorizzazioni utente per limitare gli attacchi side-channel
Un attacco side-channel è un attacco alla sicurezza basato sulle informazioni ottenute dal sistema stesso. Un malintenzionato con autorizzazioni più ampie del necessario può montare attacchi side-channel e apprendere dati sensibili osservando o cercando messaggi di fatturazione, logging o di sistema.
Per ridurre al minimo 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.
Ti consigliamo agli amministratori di astenersi dal 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 |
|---|---|
| Proprietario progetto | I proprietari dei progetti possono visualizzare i byte elaborati e i dati correlati solo nei log di controllo. I metadati di fatturazione non possono essere visualizzati dai dettagli del job. Non esiste un'autorizzazione o un ruolo specifico per concedere l'accesso in visualizzazione a questi metadati di fatturazione. |
| Ruoli BigQuery Data Edit, Proprietario o Visualizzatore | Visualizza i messaggi di errore nelle query. |
| Autorizzazioni visualizzatore fatturazione Cloud | Visualizza la fatturazione BigQuery. |
Esempi
- Attraverso l'osservazione ripetuta della durata delle query quando si eseguono query su tabelle con norme di accesso a livello di riga, un utente potrebbe dedurre i valori delle righe che altrimenti potrebbero essere protette da norme di accesso a livello di riga. Questo tipo di attacco richiede molti tentativi ripetuti in un intervallo di valori chiave nelle colonne di partizionamento o clustering. Anche se esiste un rumore intrinseco durante l'osservazione o la misurazione della durata della query, con tentativi ripetuti un malintenzionato potrebbe ottenere una stima affidabile. Se questo livello di protezione ti preoccupa, 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 byte fatturati massimi o controlli dei costi personalizzati). Tuttavia, questo attacco richiede un volume elevato di query.
- Tramite query ripetute e osservando l'importo della fatturazione BigQuery nel fatturazione Cloud, un utente potrebbe 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 valori chiave nelle colonne di partizionamento o di clustering. Se questo livello di protezione ti preoccupa, 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 attività sospette nelle tabelle con sicurezza a livello di riga, ad esempio aggiunte, modifiche ed eliminazioni impreviste di norme di accesso a livello di riga.
Limitare le autorizzazioni utente per limitare la manomissione 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 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 l'accesso in scrittura alle tabelle e per le norme 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. Quando rimuovi l'ultima policy di accesso a livello di riga in una tabella, anche se intendi ricrearla, potresti concedere inavvertitamente l'accesso senza filtri a un pubblico più ampio del previsto.
Consigliamo agli amministratori di prestare particolare attenzione quando ricreano l'ultima norma 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 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 nella tabella, poi eliminare le policy di accesso a livello di riga precedenti che non sono più necessarie.
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 contribuire a prevenire 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 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.
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 di dati all'interno di un'organizzazione/azienda), e non per la sicurezza interorganizzativa o pubblica.
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. I dati 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 un criterio di accesso a livello di riga, alle entità nel criterio viene concesso automaticamente il ruolo bigquery.filteredDataViewer. Puoi aggiungere o rimuovere entità solo dai criteri di accesso
con un'istruzione DDL.
Il ruolo bigquery.filteredDataViewer non deve essere concesso tramite
IAM a una risorsa di livello superiore, ad esempio
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 limitazioni 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
significativo per la sicurezza 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 norma.
Impatto sulle prestazioni dei filtri sulle colonne partizionate
I filtri delle policy di accesso a livello di riga non partecipano all'eliminazione delle query nelle tabelle partizionate e in cluster.
Se la tua 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.