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 sezioni 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 a canale laterale

Un attacco a livello di canale è un attacco di sicurezza basato sulle informazioni ottenute dal sistema stesso, Un utente malintenzionato con autorizzazioni più ampie del necessario potrebbe apprendere dati sensibili tramite l'osservazione o la ricerca tramite messaggi di fatturazione, logging o sistema.

Per mitigare queste opportunità, BigQuery nasconde le statistiche sensibili per 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.

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 o Autore 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 per i quali sono proprietari e visualizzare i log di controllo e di fatturazione.
Ruoli di modifica, proprietario o visualizzatore di dati BigQuery Visualizza i messaggi di errore relativi alle query.
Ruoli di Visualizzatore metriche di Stackdriver Stackdriver Monitoring Visualizza le metriche relative alle query, inclusi i byte elaborati e i dati correlati.
Autorizzazioni visualizzatore Cloud Billing 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 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 in un intervallo di valori chiave nelle colonne di partizionamento o clustering. Anche se viene rilevato un rumore intrinseco durante l'osservazione o la misurazione della durata delle query, con tentativi ripetuti l'utente potrebbe ottenere una stima affidabile. Se consideri questo livello di protezione, ti consigliamo di utilizzare tabelle separate per isolare invece le righe con requisiti di controllo degli accessi diversi.
  • Attraverso query ripetute e create con precisione, è possibile che un utente malintenzionato scopri le informazioni sensibili osservando i messaggi di errore risultanti. In particolare, un utente malintenzionato con accesso alla tabella sottostante può ricavare valori di riga protetti quando la query restituisce un'eccezione di divisione per zero, anche se esiste un predicato di sicurezza che impedisce agli utenti di eseguire direttamente query sugli stessi dati. Questo tipo di attacco spesso richiede vari tentativi ripetuti contro una tabella con livello di 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 del job di query (ad esempio i byte massimi 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 in Cloud Billing, 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 numerosi tentativi ripetuti in un intervallo di valori chiave nelle colonne di partizionamento o clustering. Se ritieni che questo livello di protezione sia sufficiente, ti consigliamo di limitare l'accesso ai dati di fatturazione per le query.

Consigliamo inoltre agli amministratori di monitorare gli audit log di Cloud(/bigquery/docs/reference/auditlogs) per le attività sospette su tabelle con sicurezza a livello di riga, come aggiunte, modifiche ed eliminazioni impreviste dei criteri di accesso a livello di riga.

Evita di aprire inavvertitamente l'accesso durante la nuova creazione 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 delle query. Quando rimuovi l'ultimo criterio di accesso a livello di riga in una tabella, anche se intendi ricreare solo il criterio di accesso a livello di riga, puoi concedere inavvertitamente l'accesso non filtrato a un segmento di pubblico più ampio del previsto.

Consigliamo agli amministratori di prestare particolare attenzione quando ricreano gli ultimi criteri di accesso a livello di riga in una tabella, seguendo queste linee guida:

  1. Per prima cosa, rimuovi tutti gli accessi alla tabella utilizzando i controlli degli accessi alle tabelle.
  2. Rimuovi tutti i criteri di accesso a livello di riga.
  3. Ricrea i criteri di accesso a livello di riga desiderati.
  4. Riattiva l'accesso alla tabella con i controlli degli accessi alle tabelle.

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 contribuire a prevenire la fuga di dati da attacchi cross-channel e per mantenere un maggiore controllo sull'accesso ai dati sensibili.

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/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 stabilire a chi è stato concesso l'accesso ai dati di fatturazione delle query utilizzando le tabelle con criteri di accesso a livello di riga. I dati di fatturazione sono un vettore per gli attacchi lato canale.

Utilizza il ruolo Filtered Data Viewer con cautela

Quando crei un criterio di accesso a livello di riga, alle entità nel criterio viene assegnato 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, 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 in quella tabella, set di dati o progetto.

Tuttavia, concedere il ruolo di bigquery.filteredDataViewer in una tabella non significa necessariamente che l'utente possa visualizzare tutte le righe della tabella. Unione di tutti i criteri di accesso a livello di riga; le espressioni di filtro potrebbero formare o meno una chiusura sull'intera tabella.

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

L'applicazione di filtri su colonne partizionate influisce sulle prestazioni

I filtri dei criteri di accesso a livello di riga non partecipano all'eliminazione delle query su tabelle partizionate e in cluster.

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