Introduzione a BigQuery a livello di riga sicurezza
Questo documento spiega 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 altre i dettagli.
Che cos'è la sicurezza a livello di riga?
La sicurezza a livello di riga consente di filtrare i dati e consentire l'accesso a righe specifiche di una tabella in base alle condizioni utente idonee.
BigQuery supporta i controlli dell'accesso a livello di progetto, set di dati livelli tabella, come nonché alla sicurezza a livello di colonna 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. Criteri di accesso a livello di riga possono coesistere su un tavolo con la sicurezza a livello di colonna e a livello di set di dati, a livello di tabella, controlli dell'accesso e a livello di progetto.
Come funziona la sicurezza a livello di riga
A livello generale, la sicurezza a livello di riga implica la creazione di di accesso a una tabella BigQuery di destinazione. Queste norme consentono come filtri per nascondere o visualizzare determinate righe di dati, a seconda che un utente o un gruppo è in un elenco autorizzato. Eventuali utenti o gruppi non inclusi specificamente in all'elenco di account autorizzati è negato l'accesso.
Un utente autorizzato con i ruoli IAM (Identity and Access Management) 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 in base al nome e
quali utenti o gruppi (chiamati grantee-list
) possono accedere a determinati
riga di dati. Il criterio include anche i dati che vuoi filtrare, chiamati
filter_expression
. L'elemento filter_expression
funziona come un WHERE
in una tipica query.
Per istruzioni su come creare e utilizzare un criterio di accesso a livello di riga, consulta Utilizzo della sicurezza a livello di riga.
Consulta le Riferimento DDL per la sintassi, l'utilizzo e le opzioni completi relativi alla creazione di 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
contiene righe appartenenti a
regioni diverse (indicate dalla colonna region
).
La sicurezza a livello di riga consente a un proprietario o un amministratore dei dati di implementare criteri come "Utenti
In group:apac
possono vedere solo i partner della regione APAC."
Il comportamento risultante è che gli utenti del gruppo [email protected]
possono
visualizza solo le righe in cui Region = "APAC"
. Analogamente, gli utenti del gruppo
[email protected]
può visualizzare solo le righe nella regione US
. Utenti non in
APAC
o US
gruppo non vedono righe.
Il criterio di accesso a livello di riga denominato us_filter
concede l'accesso a
più persone giuridiche, tra cui il responsabile delle vendite degli Stati Uniti [email protected]
, tutte
chi può ora accedere alle righe appartenenti alla regione US
.
Filtra i dati delle righe in base a dati sensibili
Ora consideriamo un caso d'uso diverso, in cui abbiamo una tabella di dati sugli stipendi.
Il grantee_list
limita l'esecuzione di query ai membri del dominio dell'azienda. Nella
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 suo
. In questo caso, è [email protected]
.
Filtra i dati delle righe in base alla tabella di ricerca
Per fornire feedback o richiedere assistenza in merito a questa funzione, invia un'email a [email protected].Con il supporto delle sottoquery, i criteri di accesso alle righe possono fare riferimento ad altre tabelle e utilizzare come tabelle di ricerca. I dati utilizzati nelle regole di filtro possono essere archiviati in una tabella un singolo criterio di accesso alle righe di sottoquery può sostituire più accessi alle righe configurate criteri. Per aggiornare i criteri di accesso alle righe, devi solo aggiornare il file che sostituisce più criteri di accesso alle righe. Non è necessario aggiorna ogni singolo criterio di accesso alle righe.
Quando utilizzare la sicurezza a livello di riga rispetto ad altri metodi
Visualizzazioni autorizzate, criteri di accesso a livello di riga e l'archiviazione dei dati in tabelle separate offrono tutti diversi livelli di sicurezza, prestazioni e convenienza. La scelta del meccanismo giusto per il tuo caso d'uso è importante per garantire di sicurezza dei dati.
Confronto con le viste autorizzate: vulnerabilità
Sia la sicurezza a livello di riga sia l'applicazione dell'accesso a livello di riga. con una vista autorizzata possono presentare vulnerabilità, se utilizzate in modo improprio.
Quando utilizzi delle viste autorizzate o dei criteri di accesso a livello di riga per la sicurezza a livello di riga, consigliamo di monitorare eventuali attività sospette tramite log di controllo.
I canali laterali, come la durata della query, possono divulgare informazioni su di righe sul perimetro di uno shard di archiviazione. Tali attacchi probabilmente richiedono una conoscenza di come viene eseguito lo sharding della tabella o un numero elevato di query.
Per ulteriori informazioni su come prevenire questi attacchi side-channel, consulta Best practice per la sicurezza a livello di riga.
Confronto di viste autorizzate, sicurezza a livello di riga e tabelle separate
La tabella seguente mette a confronto la flessibilità, le prestazioni e la sicurezza viste autorizzate, criteri di accesso a livello di riga e tabelle separate.
Metodo | Considerazioni sulla sicurezza | Consiglio |
---|---|---|
Autorizzato visualizzazioni |
Consigliato per una maggiore flessibilità. Può essere vulnerabile a creazioni le query, la durata delle query e altri tipi di attacchi a canale laterale. | Le visualizzazioni autorizzate sono una buona scelta quando devi condividere dati con altri e la flessibilità e le prestazioni sono importanti. Ad esempio, puoi utilizzare viste autorizzate a condividere dati all'interno del tuo gruppo di lavoro. |
Criteri di accesso a livello di riga | Consigliato per un equilibrio tra flessibilità e sicurezza. Può essere vulnerabile a attacchi al canale laterale con durata delle query. | I criteri di accesso a livello di riga sono una buona scelta quando devi condividere dati con altri utenti e vuoi offrire maggiore sicurezza alle viste o alle tabelle sezioni. Ad esempio, puoi utilizzare i criteri di accesso a livello di riga per condividere i dati utenti che usano tutti la stessa dashboard, anche se alcuni hanno accesso ad altri dati di altri utenti. |
Tabelle separate | Consigliato per la sicurezza. Gli utenti non possono dedurre i dati senza accedere al . | Le tabelle separate sono una buona scelta quando devi condividere dati con altri e devi mantenere i dati isolati. Ad esempio, puoi usare tabelle separate per condividere i dati con partner e fornitori terzi, quando il numero totale devono essere secret. |
Crea e gestisci i criteri di accesso a livello di riga
Per informazioni su come creare, aggiornare (ricreare), elencare, visualizzare ed eliminare criteri di accesso a livello di riga su una tabella e come eseguire query sulle tabelle con i criteri di accesso a livello di riga, consulta Utilizzo della 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 ulteriori ad accesso meno frequente per ridurre i costi di archiviazione. Tuttavia, un criterio di accesso a livello di riga può influire sul costo di esecuzione una query nei seguenti modi:
La fatturazione aggiuntiva può essere causata da criteri di accesso a livello di riga, in particolare e i criteri che includono sottoquery che fanno riferimento ad altre tabelle.
I filtri dei criteri di accesso a livello di riga non partecipano all'eliminazione delle query su partizionate e in cluster, tabelle. Ciò non significa che legge più dati durante l'esecuzione della query principale. it non sfrutta i predicati del criterio di accesso alle righe da eliminare ulteriormente.
Con i filtri dei criteri di accesso a livello di riga, non tutti i filtri utente vengono applicati in anticipo. Questo potrebbe aumentare i dati letti dalle tabelle e potrebbe generare un aumento dei costi righe.
Per ulteriori informazioni sui prezzi delle query BigQuery, consulta Prezzi di BigQuery.
Limitazioni
Per informazioni sui limiti per la sicurezza a livello di riga, vedi BigQuery Limiti di sicurezza a livello di riga. Le sezioni seguenti documentano ulteriori limitazioni di sicurezza a livello di riga.
Limitazioni delle prestazioni
Alcune funzionalità di BigQuery non vengono accelerate quando lavorare con tabelle contenenti criteri di accesso a livello di riga, BigQuery BI Engine e viste materializzate.
La sicurezza a livello di riga non partecipa alla query potatura, una funzionalità di tabelle partizionate. Per ulteriori informazioni, consulta Partizionati e in cluster tabelle. Questa limitazione non rallenta l'esecuzione della query principale.
Potresti riscontrare un piccolo peggioramento delle prestazioni quando esegui query sulle tabelle con una sicurezza a livello di riga.
Per ulteriori informazioni su come la sicurezza a livello di riga interagisce con alcuni Funzionalità e servizi di BigQuery, consulta Utilizzo della sicurezza a livello di riga con altre funzionalità di BigQuery.
Altre limitazioni
Questa funzionalità potrebbe non essere disponibile quando utilizzi le prenotazioni create con alcune versioni di BigQuery. Per ulteriori informazioni quali funzioni sono abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.
I criteri di accesso alle righe non sono compatibili con SQL precedente. Query delle tabelle con criteri di accesso a livello di riga devono usare GoogleSQL. Le query SQL legacy viene rifiutata con un errore.
Non puoi applicare criteri di accesso a livello di riga nelle colonne JSON.
Alcune funzionalità di BigQuery non sono compatibili con le metriche a livello di riga sicurezza. Per ulteriori informazioni, vedi Utilizzo della sicurezza a livello di riga.
Operazioni non di query, inclusi i job degli account di servizio, che richiedono l'accesso completo ai dati delle tabelle può utilizzare la sicurezza a livello di riga Filtro
TRUE
. Ecco alcuni esempi: copiare tabelle, flussi di lavoro Dataproc, e altro ancora. Per ulteriori informazioni, vedi Utilizzo della sicurezza a livello di riga.È necessario creare, sostituire o eliminare i criteri di accesso a livello di riga con le istruzioni DDL. È possibile elencare e visualizzare i criteri di accesso a livello di riga mediante la console Google Cloud o strumento a riga di comando bq.
Visualizzare l'anteprima o sfogliare le tabelle non è compatibile con la sicurezza a livello di riga.
Il campionamento della tabella non è compatibile. con una sicurezza a livello di riga.
I risultati dei criteri di sottoquery di primo livello sono limitati a 100 MB. Questo limite si applica a di accesso a livello di riga.
Se il predicato del criterio di accesso a livello di riga non può essere valutato a causa di qualsiasi tabella di riferimento, la query non riesce.
I criteri di accesso a livello di riga delle sottoquery supportano solo BigQuery tabelle, tabelle esterne BigLake e gestite da BigLake tabelle.
Audit logging e monitoraggio
Quando vengono letti i dati di una tabella con uno o più criteri di accesso a livello di riga, criteri di accesso a livello di riga autorizzati per l'accesso in lettura e qualsiasi le tabelle a cui viene fatto riferimento nelle sottoquery vengono visualizzate nel Informazioni sull'autorizzazione IAM per quella richiesta di lettura.
La creazione e l'eliminazione dei criteri di accesso a livello di riga vengono registrati in un log di controllo e possono essere
a cui si accede tramite Cloud Logging. Log di controllo
includi il nome del criterio di accesso a livello di riga. Tuttavia,
Definizioni di filter_expression
e grantee_list
di un accesso a livello di riga
vengono omessi dai log, in quanto potrebbero contenere dati dell'utente o altri
informazioni. L'elenco e la visualizzazione dei criteri di accesso a livello di riga non sono sottoposti a controllo
registrato.
Per saperne di più sul logging in BigQuery, consulta Introduzione al monitoraggio di BigQuery.
Per saperne di più sul logging in Google Cloud, consulta Cloud Logging.
Passaggi successivi
Per informazioni sulla gestione della sicurezza a livello di riga, vedi Utilizza la sicurezza a livello di riga.
Per informazioni su come funziona la sicurezza a livello di riga con altri Funzionalità e servizi di BigQuery, consulta Utilizzo della sicurezza a livello di riga con altre funzionalità di BigQuery.
Per informazioni sulle best practice per la sicurezza a livello di riga, vedi Best practice per la sicurezza a livello di riga in BigQuery.