Introduzione al controllo dell'accesso a livello di colonna

Nota: questa funzionalità potrebbe non essere disponibile quando si utilizzano prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni sulle funzionalità attivate in ogni versione, consulta Introduzione alle versioni di BigQuery.

BigQuery fornisce un accesso granulare alle colonne sensibili utilizzando tag di criteri o la classificazione basata sui tipi di dati. Con controllo dell'accesso a livello di colonna di BigQuery, puoi creare criteri che controllano, al momento della query, se un utente dispone dell'accesso corretto. Ad esempio, un criterio può applicare controlli di accesso come:

• Devi essere in group:high-access per visualizzare le colonne contenenti TYPE_SSN.

Per migliorare controllo dell'accesso a livello di colonna, puoi eventualmente utilizzare il mascheramento dinamico dei dati. La mascheratura dei dati ti consente di mascherare i dati sensibili sostituendo contenuti null, predefiniti o sottoposti ad hashing al posto del valore effettivo della colonna.

Flusso di lavoro per controllo dell'accesso a livello di colonna

Per limitare l'accesso ai dati a livello di colonna:

1. Definire una tassonomia e i tag di criteri. Crea e gestisci una tassonomia e tag di criteri per i tuoi dati. Per le linee guida, consulta Best practice per i tag delle norme.

2. Assegna i tag di criteri alle colonne di BigQuery. In BigQuery, utilizza le annotazioni dello schema per assegnare un tag di criteri a ogni colonna in cui vuoi limitare l'accesso.

3. Applica controllo dell'accesso alla tassonomia. L'applicazione del controllo dell'accesso comporta l'applicazione delle limitazioni di accesso definite per tutti i tag criterio nella tassonomia.

4. Gestisci l'accesso ai tag criterio. Utilizza i criteri di Gestione di identità e accessi (IAM) per limitare l'accesso a ciascun tag di criteri. Il criterio è attivo per ogni colonna che appartiene al tag di criteri.

Quando un utente tenta di accedere ai dati della colonna al momento della query, BigQuery controlla il tag di criteri della colonna e il relativo criterio per verificare se l'utente è autorizzato ad accedere ai dati.

Nota: controllo dell'accesso a livello di colonna viene applicato in aggiunta alle ACL del set di dati esistenti. Un utente deve disporre sia dell'autorizzazione per il set di dati sia dell'autorizzazione per i tag di criteri per accedere ai dati protetti dal controllo dell'accesso a livello di colonna.

Identifica ciò che deve essere taggato

Per determinare i tipi di dati sensibili di cui disponi e quali colonne richiedono i tag delle norme, ti consigliamo di generare profili dei tuoi dati in un'organizzazione, una cartella o un progetto utilizzando Sensitive Data Protection. I profili di dati contengono metriche e metadati sulle tabelle e ti aiutano a determinare dove si trovano i dati sensibili e ad alto rischio. Sensitive Data Protection genera report su queste metriche a livello di progetto, tabella e colonna. Per ulteriori informazioni, consulta Profili di dati per i dati BigQuery.

L'immagine seguente mostra un elenco di profili dei dati delle colonne (fai clic per ingrandire). Le colonne con valori di rischio dati elevati potrebbero contenere dati con sensibilità elevata e non avere controlli di accesso a livello di colonna. In alternativa, queste colonne potrebbero contenere dati con sensibilità moderata o elevata accessibili a un gran numero di persone.

Caso d'uso di esempio

Prendiamo ad esempio un'organizzazione che deve classificare i dati sensibili in due categorie: Alta e Media.

Per configurare la sicurezza a livello di colonna, un responsabile dei dati che dispone delle autorizzazioni appropriate deve eseguire i seguenti passaggi per impostare una gerarchia di classificazione dei dati.

1. Il responsabile dei dati crea una tassonomia denominata "Criticità per l'attività". La taxonomia include i nodi o i tag dei criteri Alto e Medio.

2. Lo steward dei dati decide che il criterio per il nodo Alto include l'accesso per un gruppo denominato accesso-livello-alto.

3. L'amministratore dei dati crea più livelli di nodi nella tassonomia, in Alto e Medio. Il nodo di livello più basso è un nodo foglia, come il nodo foglia employee_ssn. Lo steward dei dati può creare o meno un criterio di accesso diverso per il nodo foglia employee_ssn.

4. Il responsabile dei dati assegna un tag di criteri a colonne di tabelle specifiche. In questo esempio, lo steward dei dati assegna il criterio di accesso Alto alla colonna employee_ssn di una tabella.

5. Nella pagina Schema corrente della console, l'amministratore dei dati può vedere il tag di criteri che regola una determinata colonna. In questo esempio, la colonna employee_ssn è sotto il tag di criteri Alto, pertanto quando viene visualizzato lo schema per employee_ssn, la console mostra il nome della tassonomia e il tag di criteri nel campo Policy tags: Business criticality:High.

   

   Per informazioni dettagliate sull'utilizzo della console per impostare un tag di criteri, consulta Impostare un tag di criteri in una colonna.

   In alternativa, puoi impostare il tag di criteri utilizzando il comando bq update. Il names campo di policyTags include l'ID del tag di criteri Alto, projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id:

   [
    ...
    {
      "name": "ssn",
      "type": "STRING",
      "mode": "REQUIRED",
      "policyTags": {
        "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id"]
      }
    },
    ...
   ]

   Per informazioni dettagliate sull'utilizzo del comando bq update per impostare un tag di criteri, consulta Impostare un tag di criteri in una colonna.

   Nota: puoi assegnare un solo tag di criteri per colonna.

6. L'amministratore esegue passaggi simili per il tag di criteri Medium.

Con questo accesso granulare, puoi gestire l'accesso a molte colonne controllando solo un numero limitato di tag dei criteri di classificazione dei dati.

Per maggiori dettagli su questi passaggi, consulta Limitare l'accesso con il controllo dell'accesso a livello di colonna.

Ruoli utilizzati con controllo dell'accesso a livello di colonna

I seguenti ruoli vengono utilizzati per controllo dell'accesso a livello di colonna BigQuery.

Il ruolo Amministratore dei tag di criteri di Data Catalog è obbligatorio per gli utenti che devono creare e gestire tassonomie e tag di criteri.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore tag criterio Data Catalog/datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	Si applica a livello di progetto. Questo ruolo consente di: Crea, leggi, aggiorna ed elimina tassonomie e tag di criteri. Recupera e imposta i criteri IAM sui tag di criterio.

Per creare e gestire i criteri dei dati, è necessario il ruolo Amministratore dei criteri dei dati BigQuery, il ruolo Amministratore BigQuery o il ruolo Proprietario dati BigQuery. Quando utilizzi la console Google Cloud per applicare controllo dell'accesso a una tassonomia, il servizio crea automaticamente un criterio relativo ai dati.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore delle norme relative ai dati BigQuery/bigquerydatapolicy.admin Amministratore BigQuery/bigquery.admin Proprietario dei dati BigQuery/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	Le autorizzazioni bigquery.dataPolicies.create e bigquery.dataPolicies.list si applicano a livello di progetto. Le altre autorizzazioni si applicano a livello di criteri dei dati. Questo ruolo consente di: Crea, leggi, aggiorna ed elimina i criteri dei dati. Recupera e imposta i criteri IAM sui criteri dei dati.

Inoltre, devi disporre dell'autorizzazione datacatalog.taxonomies.get, che puoi ottenere da diversi ruoli predefiniti di Data Catalog.

Il ruolo Lettore granulare di Data Catalog è obbligatorio per gli utenti che devono accedere ai dati nelle colonne protette.

Ruolo/ID	Autorizzazioni	Descrizione
Lettore granulare/datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	Si applica a livello di tag di criteri. Questo ruolo concede la possibilità di accedere ai contenuti delle colonne limitate da un tag di criteri.

Per scoprire di più sui ruoli di Data Catalog, consulta Identity and Access Management (IAM) di Data Catalog. Per saperne di più sui ruoli BigQuery, consulta Controllo dell'accesso con IAM.

Impatto delle scritture

Per leggere i dati da una colonna protetta dal controllo dell'accesso a livello di colonna, l'utente deve sempre disporre dell'autorizzazione di lettura tramite l'accesso in lettura granulare ai tag di criteri per la colonna.

Ciò si applica a:

• Tabelle, incluse le tabelle con caratteri jolly
• Visualizzazioni
• Copia delle tabelle

Per scrivere dati in una riga per una colonna protetta dal controllo dell'accesso a livello di colonna, il requisito dell'utente dipende dal tipo di scrittura.

Se l'operazione di scrittura è un insert, l'accesso in lettura granulare non è richiesto. Tuttavia, l'utente non ha accesso in lettura ai dati inseriti, a meno che non abbia accesso in lettura granulare.

Se un utente esegue un'istruzione INSERT SELECT, è necessario il ruolo di lettore granulare nella tabella sottoposta a query.

Se l'operazione di scrittura è un aggiornamento, un'eliminazione o un'unione, l'utente non può eseguire l'operazione a meno che non disponga dell'accesso in lettura granulare alle colonne di lettura.

Un utente può caricare i dati da file locali o da Cloud Storage. Quando carica i dati in una tabella, BigQuery non controlla l'autorizzazione di lettore granulare sulle colonne della tabella di destinazione. Questo perché il caricamento dei dati non richiede la lettura dei contenuti dalla tabella di destinazione. Analogamente, un utente può caricare i dati dallo streaming, perché i caricamenti in streaming non controllano i tag delle norme. L'utente non ha accesso in lettura ai dati caricati da uno stream, a meno che non disponga di accesso in lettura granulare.

Per ulteriori informazioni, consulta Impatto sulle scritture con il controllo dell'accesso a livello di colonna.

Esegui query sulle tabelle

Se un utente ha accesso al set di dati e dispone del ruolo Lettore granulare Data Catalog, i dati delle colonne sono disponibili per l'utente. L'utente esegue una query come di consueto.

Se un utente ha accesso al set di dati, ma non ha il ruolo Lettore granulare Data Catalog, i dati delle colonne non sono disponibili per l'utente. Se un utente di questo tipo esegue SELECT *, riceve un messaggio di errore che elenca le colonne a cui non può accedere. Per risolvere l'errore, puoi:

• Modifica la query in modo da escludere le colonne a cui l'utente non può accedere. Ad esempio, se l'utente non ha accesso alla colonna ssn, ma ha accesso alle colonne rimanenti, può eseguire la seguente query:

  SELECT * EXCEPT (ssn) FROM ...

  Nell'esempio precedente, la clausola EXCEPT esclude la colonna ssn.

• Chiedi a un amministratore di Data Catalog di aggiungere l'utente come Lettore granulare Data Catalog alla classe di dati pertinente. Il messaggio di errore fornisce il nome completo del tag di criteri per cui l'utente deve avere accesso.

Visualizzazioni query

L'impatto della sicurezza a livello di colonna sulle viste è indipendente dal fatto che la vista sia o meno autorizzata. In entrambi i casi, la sicurezza a livello di colonna viene applicata in modo trasparente.

Una vista autorizzata è una delle seguenti:

• Una vista autorizzata esplicitamente ad accedere alle tabelle di un set di dati.
• Una vista che è implicitamente autorizzata ad accedere alle tabelle di un set di dati perché è contenuta in un set di dati autorizzato.

Per ulteriori informazioni, consulta Viste autorizzate e Set di dati autorizzati.

Se la visualizzazione non è una vista autorizzata:

Se l'utente dispone dell'accesso IAM alle tabelle e al set di dati sottostanti della vista, nonché dell'accesso a livello di colonna alle tabelle sottostanti della vista, può eseguire query sulle colonne della vista. In caso contrario, l'utente non potrà eseguire query sulle colonne della vista.

Se la visualizzazione è una vista autorizzata:

Solo la sicurezza a livello di colonna delle colonne nelle tabelle sottostanti della vista controlla l'accesso. Gli eventuali criteri IAM a livello di tabella e di set di dati non vengono utilizzati per controllare l'accesso. Se l'utente ha accesso ai tag delle norme utilizzati nelle tabelle sottostanti della vista autorizzata, può eseguire query sulle colonne nella vista autorizzata.

Il seguente diagramma mostra come viene valutato l'accesso a una visualizzazione.

Impatto del viaggio nel tempo e delle viste materializzate con max_staleness

BigQuery ti consente di eseguire query su una tabella in uno stato precedente. Questa funzionalità ti consente di eseguire query sulle righe di un punto in tempo precedente. Inoltre, consente di ripristinare una tabella da un momento specifico.

In SQL precedente, esegui query sui dati storici utilizzando i decoratori di tempo sul nome della tabella. In GoogleSQL, esegui query sui dati storici utilizzando la clausola FOR SYSTEM_TIME AS OF nella tabella.

Le visualizzazioni con dati materiali con l'opzione max_staleness impostata restituiscono i dati storici all'interno del loro intervallo di inattività. Questo comportamento è simile a una query che utilizza FOR SYSTEM_TIME AS OF al momento dell'ultimo aggiornamento della visualizzazione, in quanto consente a BigQuery di eseguire query sui record che sono stati eliminati o aggiornati. Supponiamo che tu esegua una query sui dati storici di una tabella al momento t. In questo caso:

• Se lo schema al momento t è identico o è un sottoinsieme dello schema attuale della tabella, BigQuery esegue il controllo in base alla sicurezza più recente a livello di colonna nella tabella corrente. Se l'utente è autorizzato a leggere le colonne attuali, può eseguire query sui dati storici di queste colonne. Per eliminare o mascherare i dati sensibili delle colonne protette dalla sicurezza a livello di colonna, la sicurezza a livello di colonna può essere allentata in sicurezza solo dopo il superamento della finestra di viaggio nel tempo configurata dal momento del cleanup dei dati sensibili.

• Se lo schema al momento t è diverso da quello corrente per le colonne della query, la query non va a buon fine.

Considerazioni sulla località

Quando scegli una località per la tua tassonomia, tieni presente le seguenti limitazioni.

Tag di criteri

Le tassonomie sono risorse regionali, come i set di dati e le tabelle BigQuery. Quando crei una tassonomia, devi specificare la regione o la posizione per la tassonomia.

Puoi creare una tassonomia e applicare i tag criterio alle tabelle in tutte le regioni in cui è disponibile BigQuery. Tuttavia, per applicare i tag di criteri da una tassonomia a una colonna di una tabella, la tassonomia e la tabella devono trovarsi nella stessa posizione regionale.

Sebbene non sia possibile applicare un tag di criteri a una colonna di una tabella esistente in un'altra posizione, puoi copiare la tassonomia in un'altra posizione replicandola esplicitamente.

Se vuoi utilizzare la stessa tassonomia e gli stessi tag di criteri in più località regionali, scopri di più sulla replica delle tassonomie in Gestire i tag di criteri in più località.

Organizzazioni

Non puoi utilizzare i riferimenti tra organizzazioni. Una tabella e tutti i tag dei criteri che vuoi applicare alle relative colonne devono esistere nella stessa organizzazione.

Limitazioni

• Questa funzionalità potrebbe non essere disponibile se utilizzi prenotazioni create con determinate versioni di BigQuery. Per ulteriori informazioni su le funzionalità abilitate in ogni versione, consulta Introduzione alle versioni di BigQuery.

• BigQuery supporta controllo dell'accesso a livello di colonna solo per le tabelle BigLake, le tabelle BigQuery e le tabelle BigQuery Omni.

• Se esegui l'override in una tabella di destinazione, tutti i tag di criteri esistenti vengono rimossi dalla tabella, a meno che non utilizzi il flag --destination_schema per specificare uno schema con i tag di criteri. Il seguente esempio mostra come utilizzare --destination_schema.

  bq query --destination_table mydataset.mytable2 \
    --use_legacy_sql=false --destination_schema=schema.json \
    'SELECT * FROM mydataset.mytable1'
  

  Le modifiche allo schema vengono eseguite in un'operazione separata dall'esecuzione della query. Se scrivi i risultati della query in una tabella specificando il flag --destination_table e la query solleva successivamente un'eccezione, è possibile che eventuali modifiche allo schema vengano ignorate. In questo caso, controlla lo schema della tabella di destinazione e, se necessario, aggiornalo manualmente.

• Una colonna può avere un solo tag di criteri.

• Una tabella può avere al massimo 1000 tag di criterio univoci.

• Non puoi utilizzare SQL precedente se hai attivato il controllo dell'accesso a livello di colonna. Eventuali query SQL precedente vengono rifiutate se nelle tabelle di destinazione sono presenti tag di criteri.

• Una gerarchia di tag di criteri non può avere più di cinque livelli di profondità dal nodo principale al sottotag di livello più basso, come mostrato nello screenshot seguente:

  

• I nomi delle tassonomie devono essere univoci in tutti i progetti di un'organizzazione.

• Non puoi copiare una tabella tra regioni se hai attivato il controllo dell'accesso a livello di riga o colonna. Eventuali copie delle tabelle nelle varie regioni vengono rifiutate se esistono tag dei criteri nelle tabelle di origine.

Prezzi

Controllo dell'accesso a livello di colonna richiede l'utilizzo sia di BigQuery sia di Data Catalog. Per informazioni sui prezzi di questi prodotti, consulta i seguenti argomenti:

• Prezzi di BigQuery
• Prezzi di Data Catalog

Audit logging

Quando i dati della tabella con i tag di criteri vengono letti, salviamo i tag di criteri a cui si fa riferimento in Cloud Logging. Tuttavia, il controllo tag di criteri non è associato alla query che ha attivato il controllo.

Tramite Cloud Logging, i revisori possono capire chi ha quale tipo di accesso a quali categorie di dati sensibili. Per ulteriori informazioni, consulta Tag dei criteri di controllo.

Per ulteriori informazioni su come eseguire il logging in BigQuery, consulta Introduzione al monitoraggio di BigQuery.

Per ulteriori informazioni su come accedere a Google Cloud, consulta Cloud Logging.

Passaggi successivi

• Per informazioni dettagliate sull'utilizzo controllo dell'accesso a livello di colonna, consulta Limitare l'accesso con il controllo dell'accesso a livello di colonna.

• Per informazioni sulle best practice per i tag di criteri, consulta Best practice di BigQuery: utilizzo dei tag di criteri.