Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 le pagine 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 lato canale

Un attacco lato canale è un attacco di sicurezza basato su informazioni ottenute dal sistema stesso. Un utente malintenzionato con autorizzazioni più ampie del necessario può montare più facilmente gli attacchi lato canale e apprendere i dati sensibili osservando o cercando fatturazione, logging o messaggi di sistema.

Per mitigare queste opportunità, BigQuery nasconde 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 elaborate, 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
Proprietario del progetto o ruolo di autore del progetto I proprietari del progetto possono visualizzare i byte elaborati e i dati correlati nei log di controllo. Gli autori dei progetti possono creare nuovi progetti di cui sono proprietari e visualizzare i log di fatturazione e di controllo.
Ruoli di modifica dei dati, proprietario o visualizzatore di BigQuery Visualizza i messaggi di errore sulle query.
Ruoli di Visualizzatore monitoraggio metriche di BigQuery Stackdriver Visualizza le metriche sulle query, inclusi i byte elaborati e i dati correlati.
Autorizzazioni per i visualizzatori della fatturazione Cloud Visualizzare la fatturazione di BigQuery.

Esempi

  • Attraverso l'osservazione ripetuta della durata delle query durante l'esecuzione di query con criteri di accesso a livello di riga, 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 per una serie di coppie chiave-valore nel partizionamento o nel cluster di colonne. Anche se si verifica un rumore intrinseco durante l'osservazione o la misurazione della durata delle query, con tentativi ripetuti potresti ottenere una stima affidabile. Se sei sensibile a questo livello di protezione, ti consigliamo invece di utilizzare tabelle separate per isolare le righe con requisiti di controllo dell'accesso diversi.
  • Attraverso query ripetute e accuratamente create, è possibile che un utente malintenzionato conosca informazioni sensibili osservando i messaggi di errore generati. Nello specifico, un utente malintenzionato con accesso alla tabella sottostante può ricavare valori di riga protetti quando la query restituisce un'eccezione di suddivisione per zero, anche se è presente un predicato di sicurezza per impedire all'utente di eseguire query dirette sugli stessi dati. Questo tipo di attacco spesso richiede molti tentativi ripetuti contro una tabella con sicurezza a livello di riga.
  • 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 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 per un intervallo di coppie chiave-valore nel partizionamento o nel cluster di colonne. 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 individuare le attività sospette nelle tabelle con sicurezza a livello di riga, come aggiunte aggiuntive, modifiche ed eliminazioni dei criteri di accesso a livello di riga.

Limita 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 Write. Ciò può consentire all'utente con autorizzazioni di scrittura di modificare i risultati della query di altri utenti.

Consigliamo agli amministratori di creare gruppi Google separati per l'accesso in scrittura alle tabelle e ai criteri di accesso 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 durante la ricreazione dei criteri di accesso a livello di riga

Quando aggiungi un criterio di accesso alle righe per la prima volta in una tabella, inizi immediatamente a filtrare i dati nei risultati delle query. Quando rimuovi l'ultimo criterio di accesso a livello di riga su una tabella, anche se hai intenzione di ricreare solo il criterio di accesso a livello di riga, potresti concedere involontariamente l'accesso non filtrato a un pubblico più ampio del previsto.

Consigliamo agli amministratori di prestare particolare attenzione quando ricreano l'ultimo criterio di accesso a livello di riga su una tabella, seguendo queste linee guida:

  1. Per prima cosa, rimuovi tutto l'accesso alla tabella utilizzando i controlli di accesso alla tabella.
  2. Rimuovi tutti i criteri di accesso a livello di riga.
  3. Ricrea i criteri di accesso a livello di riga che ti interessano.
  4. 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 precedenti a livello di riga 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 fughe di dati attraverso attacchi lato-canale e per mantenere un maggiore controllo sull'accesso ai dati sensibili.

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/un'azienda) e non per la sicurezza tra organizzazioni o pubblica.

Esempio

Al di fuori dell'organizzazione, hai meno controllo su chi ha accesso ai dati. All'interno della tua organizzazione, puoi controllare chi ha ricevuto l'accesso alle informazioni di fatturazione delle query rispetto alle tabelle con criteri di accesso a livello di riga. Le informazioni di fatturazione sono un vettore per gli attacchi laterali.

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 le 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. 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 della tabella, del set di dati o del progetto in questione.

Tuttavia, concedere il 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ò o meno costituire una chiusura sull'intera tabella.

Ti consigliamo di fare attenzione prima di concedere il ruolo bigquery.filteredDataViewer a qualsiasi risorsa.

L'applicazione di un filtro in base alle colonne partizionate influisce sul rendimento

I filtri dei criteri di accesso a livello di riga non partecipano alla creazione di query sulle tabelle partizionate e in cluster.

Se il criterio di accesso a livello di riga assegna un nome a una colonna partizionata, la query non riceve i vantaggi in termini di prestazioni dell'eliminazione delle query.