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à abilitate in ogni edizione, vedi Introduzione alle versioni di BigQuery.

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

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

Per migliorare controllo dell'accesso a livello di colonna, puoi utilizzare facoltativamente il mascheramento dinamico dei dati. Il mascheramento dei dati consente di mascherare i dati sensibili sostituendo i contenuti nulli, predefiniti o con hash 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. Definisci 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 tag di criteri alle colonne BigQuery. In BigQuery, utilizza le annotazioni dello schema per assegnare un tag di criteri a ogni colonna a 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 di criteri. Utilizza le policy Identity and Access Management (IAM) per limitare l'accesso a ogni tag di criteri. La norma è in vigore per ogni colonna appartenente al tag di criteri.

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

Nota: controllo dell'accesso a livello di colonna viene applicato in aggiunta agli elenchi di controllo dell'accesso (ACL) dei set di dati esistenti. Un utente ha bisogno sia dell'autorizzazione per il set di dati sia dell'autorizzazione per il tag di criteri per accedere ai dati protetti dal controllo dell'accesso a livello di colonna.

Identificare gli elementi da taggare

Per determinare i tipi di dati sensibili che hai e quali colonne richiedono tag di policy, valuta la possibilità di generare profili sui 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 riporta queste metriche a livello di progetto, tabella e colonna. Per ulteriori informazioni, consulta Profili di dati per dati BigQuery.

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

Caso d'uso di esempio

Considera un'organizzazione che deve classificare i dati sensibili in due categorie: Alto e Medio.

Per configurare la sicurezza a livello di colonna, un data steward, che dispone delle autorizzazioni appropriate, esegue i seguenti passaggi per configurare una gerarchia di classificazione dei dati.

1. Il responsabile dei dati crea una tassonomia denominata "Criticità aziendale". La tassonomia include i nodi o tag dei criteri High e Medium.

2. Il responsabile dei dati decide che il criterio per il nodo High includa l'accesso per un gruppo denominato high-tier-access.

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

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

5. Nella pagina Schema attuale della console, il responsabile dei dati può visualizzare il tag di criteri che regola una determinata colonna. In questo esempio, la colonna employee_ssn si trova sotto il tag di criteri High, quindi quando visualizzi 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, vedi Impostare un tag di criteri su una colonna.

   In alternativa, puoi impostare il tag di criteri utilizzando il comando bq update. Il campo names 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, vedi Impostare un tag di criteri su una colonna.

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

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

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

Per informazioni dettagliate su questi passaggi, vedi 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 tag di criteri Data Catalog è necessario per gli utenti che devono creare e gestire tassonomie e tag di criteri.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore tag di policy 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 concede la possibilità di: Crea, leggi, aggiorna ed elimina tassonomie e tag di criteri. Recupera e imposta le policy IAM sui tag di criterio.

Per creare e gestire le policy dei dati sono necessari il ruolo Amministratore policy dei dati BigQuery, Amministratore BigQuery o Proprietario dati BigQuery. Quando utilizzi la consoleGoogle Cloud per applicare controllo dell'accesso a una tassonomia, il servizio crea automaticamente un criterio di gestione dei dati.

Ruolo/ID	Autorizzazioni	Descrizione
Amministratore delle norme sui 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 norme sui dati. Questo ruolo concede la possibilità di: Crea, leggi, aggiorna ed elimina le norme sui dati. Recupera e imposta i criteri IAM sulle norme relative ai dati.

Devi anche disporre dell'autorizzazione datacatalog.taxonomies.get, che puoi ottenere da diversi dei ruoli predefiniti di Data Catalog.

Il ruolo Lettore granulare Data Catalog è necessario 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 limitati da untag di criteriy.

Per saperne 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 operazioni di scrittura

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 sui tag criterio per la colonna.

Ciò si applica a:

• Tabelle, incluse quelle con caratteri jolly
• Visualizzazioni
• Copia di 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'inserimento, non è necessario l'accesso in lettura granulare. Tuttavia, l'utente non ha accesso in lettura ai dati inseriti, a meno che non disponga di un 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 di un accesso in lettura granulare alle colonne di lettura.

Un utente può caricare i dati da file locali o da Cloud Storage. Quando carichi i dati in una tabella, BigQuery non controlla l'autorizzazione di lettura granulare sulle colonne della tabella di destinazione. Questo perché il caricamento dei dati non richiede la lettura dei contenuti dalla tabella di destinazione. Allo stesso modo, un utente può caricare dati dallo streaming, perché i caricamenti di 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 un accesso in lettura granulare.

Per saperne di più, consulta Impatto sulle scritture con il controllo dell'accesso a livello di colonna.

Tabelle di query

Se un utente ha accesso al set di dati e dispone del ruolo Lettore granulare di 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 di Data Catalog, i dati delle colonne non sono disponibili per l'utente. Se un utente di questo tipo esegue SELECT *, riceve un errore che elenca le colonne a cui non può accedere. Per risolvere l'errore, puoi:

• Modifica la query per 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 Data Catalog di aggiungere l'utente come lettore granulare Data Catalog alla classe di dati pertinente. Il messaggio di errore fornisce il nome completo deltag di criteriy per cui l'utente avrebbe bisogno dell'accesso.

Visualizzazioni query

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

Una visualizzazione autorizzata è una delle seguenti:

• Una vista esplicitamente autorizzata ad accedere alle tabelle in un set di dati.
• Una vista autorizzata implicitamente ad accedere alle tabelle in 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 vista 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 può eseguire query sulle colonne nella vista.

Se la vista è una vista autorizzata:

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

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

Impatto dei viaggi 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 da un momento precedente. Ti consente anche di ripristinare una tabella da un momento specifico.

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

Le viste materializzate con l'opzione max_staleness impostata restituiscono dati storici all'interno dell'intervallo di obsolescenza. Questo comportamento è simile a una query che utilizza FOR SYSTEM_TIME AS OF al momento dell'ultimo aggiornamento della vista, in quanto consente a BigQuery di eseguire query sui record eliminati o aggiornati. Supponiamo di eseguire una query sui dati storici di una tabella al momento t. In tal caso:

• Se lo schema al momento t è identico o un sottoinsieme dello schema attuale della tabella, BigQuery esegue il controllo in base alla sicurezza a livello di colonna più recente nella tabella attuale. Se l'utente è autorizzato a leggere le colonne correnti, 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, quest'ultima può essere tranquillamente ridotta solo dopo che è trascorso il periodo di tempo configurato per il time travel dall'eliminazione dei dati sensibili.

• Se lo schema al momento t differisce dallo schema attuale per le colonne della query, la query non riesce.

Considerazioni sulla posizione

Quando scegli una posizione 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, specifichi la regione o la località per la tassonomia.

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

Anche se non puoi applicare un tag di criteri a una colonna della tabella che si trova in una posizione diversa, puoi copiare la tassonomia in un'altra posizione replicandola esplicitamente.

Se vuoi utilizzare gli stessi tag di classificazione e policy in più località regionali, scopri di più sulla replica delle classificazioni in Gestire i tag di policy in più località.

Organizzazioni

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

Limitazioni

• Questa funzionalità potrebbe non essere disponibile quando utilizzi prenotazioni create con alcune versioni di BigQuery. Per ulteriori informazioni sulle funzionalità abilitate in ogni edizione, vedi Introduzione alle versioni di BigQuery.

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

• Se esegui la sovrascrittura in una tabella di destinazione, tutti i tag di policy esistenti vengono rimossi dalla tabella, a meno che tu non utilizzi il flag --destination_schema per specificare uno schema con tag di policy. L'esempio seguente 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 genera successivamente un'eccezione, è possibile che le modifiche allo schema vengano ignorate. Se si verifica questo problema, controlla lo schema della tabella di destinazione e aggiornalo manualmente, se necessario.

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

• Una tabella può avere al massimo 1000 tag di criteri unici.

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

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

  

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

• Non puoi copiare una tabella tra regioni se hai attivato il controllo dell'accesso a livello di colonna o riga. Tutte le copie delle tabelle tra regioni vengono rifiutate se sono presenti tag di policy 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 vengono letti i dati della tabella con i tag di policy, salviamo i tag di policy a cui viene fatto riferimento in Cloud Logging. Tuttavia, il controllo tag di criteri non è associato alla query che ha attivato il controllo.

Tramite Cloud Logging, gli auditor possono capire chi ha quale tipo di accesso a quali categorie di dati sensibili. Per saperne di più, consulta Tag di policy di controllo.

Per ulteriori informazioni sulla registrazione in BigQuery, consulta Introduzione al monitoraggio di BigQuery.

Per saperne di più sull'accesso Google Cloud, consulta Cloud Logging.

Passaggi successivi

• Per informazioni dettagliate sull'utilizzo controllo dell'accesso a livello di colonna, vedi 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.