Introduzione alla sicurezza a livello di riga di BigQuery
Questo documento illustra il concetto di sicurezza a livello di riga, come funziona in BigQuery, quando utilizzare la sicurezza a livello di riga per proteggere i dati e altri dettagli.
Che cos'è la sicurezza a livello di riga?
La sicurezza a livello di riga consente di filtrare i dati e di accedere a righe specifiche di una tabella in base a condizioni utente idonee.
BigQuery supporta già i controlli dell'accesso a livello di progetto, set di dati e tabella, nonché la sicurezza a livello di colonna tramite i tag di criteri. La sicurezza a livello di riga estende il principio del privilegio minimo consentendo un controllo dell'accesso granulare a un sottoinsieme di dati in una tabella BigQuery mediante criteri di accesso a livello di riga.
Una tabella può avere più criteri di accesso a livello di riga. I criteri di accesso a livello di riga possono coesistere in una tabella con i controlli di sicurezza a livello di colonna e di livello di set di dati, a livello di tabella e a livello di progetto.
Come funziona la sicurezza a livello di riga
A livello generale, la sicurezza a livello di riga comporta la creazione di criteri di accesso a livello di riga su una tabella BigQuery di destinazione. Questi criteri agiscono come filtri per nascondere o visualizzare determinate righe di dati, a seconda che un utente o un gruppo sia in un elenco di dati consentiti. L'accesso viene negato a tutti gli utenti o gruppi non specificamente inclusi nell'elenco delle persone autorizzate.
Un utente autorizzato con i ruoli Identity and Access Management (IAM) Amministratore BigQuery o Proprietario dati BigQuery può creare criteri di accesso a livello di riga in una tabella BigQuery.
Quando crei un criterio di accesso a livello di riga, specifichi la tabella per nome e quali utenti o gruppi (chiamati grantee-list
) possono accedere a determinati dati di riga. Il criterio include anche i dati che vuoi filtrare, chiamati filter_expression
. filter_expression
funziona come una clausola WHERE
in una query tipica.
Per istruzioni su come creare e utilizzare un criterio di accesso a livello di riga, consulta Utilizzare la sicurezza a livello di riga.
Consulta il riferimento DDL per la sintassi, l'utilizzo e le opzioni complete durante la creazione dei criteri di accesso a livello di riga.
Esempi di casi d'uso
Filtra i dati delle righe in base alla regione
Considera il caso in cui una tabella dataset1.table1
contenga righe appartenenti a
regioni diverse (indicate dalla colonna region
).
La sicurezza a livello di riga consente a un proprietario dei dati o un amministratore di implementare criteri, ad esempio "Gli utenti
in group:apac
possono visualizzare solo i partner della regione APAC".
Il comportamento risultante è che gli utenti del gruppo sales-apac@example.com
possono
visualizzare solo le righe in cui Region = "APAC"
. Analogamente, gli utenti nel gruppo sales-us@example.com
possono visualizzare solo le righe nella regione US
. Gli utenti che non appartengono ai gruppi APAC
o US
non vedono alcuna riga.
Il criterio di accesso a livello di riga us_filter
concede l'accesso a
più entità, tra cui il responsabile delle vendite statunitense jon@example.com
, che ora può accedere alle righe appartenenti alla regione US
.
Filtra i dati delle righe in base ai dati sensibili
Ora prendiamo in considerazione un caso d'uso diverso, in cui abbiamo una tabella di dati sugli stipendi.
grantee_list
limita le query ai membri del dominio dell'azienda. Inoltre, l'uso della funzione SESSION_USER()
limita ulteriormente l'accesso solo alle righe che appartengono all'utente che esegue la query, in base al proprio indirizzo email dell'utente. In questo caso, è jim@example.com
.
Quando utilizzare la sicurezza a livello di riga rispetto ad altri metodi
Le viste autorizzate, i criteri di accesso a livello di riga e l'archiviazione dei dati in tabelle separate offrono tutti livelli diversi di sicurezza, prestazioni e praticità. La scelta del meccanismo giusto per il tuo caso d'uso è importante per garantire il livello di sicurezza appropriato dei tuoi dati.
Confronto con le viste autorizzate: vulnerabilità
Sia la sicurezza a livello di riga sia l'applicazione forzata dell'accesso a livello di riga con una vista autorizzata possono presentare vulnerabilità, se utilizzate in modo improprio.
Quando utilizzi visualizzazioni autorizzate o criteri di accesso a livello di riga per la sicurezza a livello di riga, ti consigliamo di monitorare eventuali attività sospette utilizzando l'audit logging.
I canali laterali, come la durata della query, possono rivelare informazioni sulle righe che si trovano sul bordo di uno shard di archiviazione. Questi attacchi richiedono probabilmente una certa conoscenza delle modalità di sharding della tabella o un numero elevato di query.
Per ulteriori informazioni su come prevenire questi attacchi sul canale laterale, consulta le best practice per la sicurezza a livello di riga.
Confronto tra viste autorizzate, sicurezza a livello di riga e tabelle separate
La seguente tabella mette a confronto la flessibilità, le prestazioni e la sicurezza delle visualizzazioni autorizzate, dei criteri di accesso a livello di riga e di tabelle separate.
Metodo | Considerazioni sulla sicurezza | Consiglio |
---|---|---|
Visualizzazioni autorizzate |
Consigliato per flessibilità. Può essere vulnerabile a query, durata delle query e altri tipi di attacchi progettati in modo accurato e altri tipi di attacchi side-channel. | Le visualizzazioni autorizzate sono un'ottima scelta quando devi condividere dati con altri, mentre la flessibilità e le prestazioni sono importanti. Ad esempio, puoi utilizzare le viste autorizzate per condividere i dati all'interno del tuo gruppo di lavoro. |
Criteri di accesso a livello di riga | Opzione consigliata per un equilibrio tra flessibilità e sicurezza. Può essere vulnerabile agli attacchi sul canale laterale della durata delle query. | I criteri di accesso a livello di riga sono una buona scelta quando devi condividere i dati con altri e vuoi garantire maggiore sicurezza sulle viste o sulle sezioni di una tabella. Ad esempio, puoi utilizzare i criteri di accesso a livello di riga per condividere i dati con persone che utilizzano tutte la stessa dashboard, anche se alcune hanno accesso a più dati di altre. |
Tabelle separate | Consigliato per motivi di sicurezza. Gli utenti non possono dedurre dati senza accesso alla tabella. | Le tabelle separate sono un'ottima scelta quando devi condividere i dati con altri e mantenere i dati isolati. Ad esempio, puoi utilizzare tabelle separate per condividere i dati con partner e fornitori terzi, quando il numero totale di righe deve essere secret. |
Crea e gestisci i criteri di accesso a livello di riga
Per informazioni su come creare, aggiornare (ricreare), elencare, visualizzare ed eliminare i criteri di accesso a livello di riga in una tabella e su come eseguire query sulle tabelle con criteri di accesso a livello di riga, consulta Utilizzare la sicurezza dell'accesso a livello di riga.
Quote
Per ulteriori informazioni su quote e limiti per la sicurezza a livello di riga, consulta Quote e limiti di BigQuery.
Prezzi
La sicurezza a livello di riga è inclusa in BigQuery senza costi aggiuntivi. Tuttavia, un criterio di accesso a livello di riga può influire sul costo dell'esecuzione di una query nei modi seguenti:
Se un criterio di accesso a livello di riga impedisce a un utente di accedere a una riga in una query, la riga non viene elaborata né fatturata.
I filtri dei criteri di accesso a livello di riga non contribuiscono all'eliminazione delle query sulle tabelle partizionate e in cluster. Ciò significa che un filtro di sicurezza a livello di riga potrebbe causare l'elaborazione di più dati rispetto a quando non fossero utilizzati.
Per ulteriori informazioni sui prezzi delle query BigQuery, consulta la pagina relativa ai prezzi di BigQuery.
Limitazioni
Per informazioni sui limiti di sicurezza a livello di riga, vedi Limiti di sicurezza a livello di riga di BigQuery. Le sezioni seguenti descrivono ulteriori limiti di sicurezza a livello di riga.
Limitazioni delle prestazioni
Alcune funzionalità di BigQuery non sono accelerate quando si lavora con tabelle contenenti criteri di accesso a livello di riga, come BigQuery BI Engine e le viste materializzate.
La sicurezza a livello di riga non partecipa all'eliminazione delle query, che è una funzionalità delle tabelle partizionate. Per saperne di più, consulta Tabelle partizionate e in cluster.
Potresti riscontrare un calo delle prestazioni quando esegui query su tabelle con sicurezza a livello di riga.
Per saperne di più su come la sicurezza a livello di riga interagisce con alcuni servizi e funzionalità di BigQuery, consulta Utilizzare la sicurezza a livello di riga con altre funzionalità di BigQuery.
Altre limitazioni
Questa funzionalità potrebbe non essere disponibile quando utilizzi le prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni sulle funzionalità abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.
I criteri di accesso alle righe non sono compatibili con l'SQL precedente. Le query delle tabelle con criteri di accesso a livello di riga devono utilizzare GoogleSQL. Le query SQL legacy vengono rifiutate con un errore.
Non puoi applicare criteri di accesso a livello di riga alle colonne JSON.
Alcune funzionalità di BigQuery non sono compatibili con la sicurezza a livello di riga. Per maggiori informazioni, consulta Utilizzare la sicurezza a livello di riga.
Le operazioni non basate su query, inclusi i job degli account di servizio, che richiedono l'accesso completo ai dati delle tabelle possono utilizzare la sicurezza a livello di riga con il filtro
TRUE
. Alcuni esempi includono la copia di tabelle, i flussi di lavoro di Dataproc e altro ancora. Per maggiori informazioni, consulta Utilizzare la sicurezza a livello di riga.La creazione, la sostituzione o l'eliminazione dei criteri di accesso a livello di riga devono essere eseguite con le istruzioni DDL. L'elenco e la visualizzazione dei criteri di accesso a livello di riga possono essere eseguiti tramite la console Google Cloud o lo strumento a riga di comando bq.
Il campionamento delle tabelle non è compatibile con la sicurezza a livello di riga.
Audit logging e monitoraggio
Quando vengono letti i dati di una tabella con uno o più criteri di accesso a livello di riga, i criteri di accesso a livello di riga autorizzati per l'accesso in lettura vengono visualizzati nelle informazioni sull'autorizzazione IAM per la richiesta di lettura in questione.
La creazione e l'eliminazione dei criteri di accesso a livello di riga vengono audit registrate e sono accessibili tramite Cloud Logging. Gli audit log includono il nome del criterio di accesso a livello di riga. Tuttavia, le definizioni filter_expression
e grantee_list
di un criterio di accesso a livello di riga vengono omesse dai log, in quanto potrebbero contenere informazioni degli utenti o altre informazioni sensibili. L'elenco e la visualizzazione dei criteri di accesso a livello di riga non vengono controllati.
Per ulteriori informazioni sul logging in BigQuery, consulta Introduzione al monitoraggio di BigQuery.
Per ulteriori informazioni sul logging in Google Cloud, consulta Cloud Logging.
Passaggi successivi
Per informazioni sulla gestione della sicurezza a livello di riga, consulta Utilizzare la sicurezza a livello di riga.
Per informazioni su come funziona la sicurezza a livello di riga con altre funzionalità e servizi di BigQuery, consulta Utilizzare la sicurezza a livello di riga con altre funzionalità di BigQuery.
Per informazioni sulle best practice per la sicurezza a livello di riga, consulta le best practice per la sicurezza a livello di riga in BigQuery.