Gestione dei tag di policy in più località

Questo documento descrive come gestire i tag di policy in località regionali per la sicurezza a livello di colonna e il mascheramento dinamico dei dati in BigQuery.

BigQuery fornisce il controllo granulare dell'accesso e il mascheramento dinamico dei dati per le colonne delle tabelle sensibili tramite i tag di policy, supportando la classificazione dei dati basata sul tipo.

Dopo aver creato una tassonomia di classificazione dei dati e aver applicato i tag di policy ai tuoi dati, puoi gestire ulteriormente i tag di policy in più località.

Considerazioni sulla località

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 di policy 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 trovarsi nella stessa località regionale.

Sebbene non sia possibile applicare un tag di criteri a una colonna di tabella che si trova in una località diversa, puoi copiare la tassonomia in un'altra località replicandola esplicitamente lì.

Utilizzo delle tassonomie in più località

Puoi copiare (o replicare) esplicitamente una tassonomia e le relative definizioni dei tag di criteri in altre località senza dover creare manualmente una nuova tassonomia in ogni località. Quando replichi le tassonomie, puoi utilizzare gli stessi tag di policy per la sicurezza a livello di colonna in più località, semplificandone la gestione.

Quando li replichi, la tassonomia e i tag di policy mantengono gli stessi ID in ogni località.

Attenzione: la sincronizzazione di una tassonomia tra località sincronizza solo la tassonomia e i tag di policy nella tassonomia. Le autorizzazioni concesse a un tag di criteri e alle colonne regolate da quel tag di criteri non sono sincronizzate e possono variare in base alla località.

La tassonomia e i tag di policy possono essere sincronizzati di nuovo per mantenerli unificati in più località. La replica esplicita di una tassonomia viene eseguita tramite una chiamata all'API Data Catalog. Le sincronizzazioni future della tassonomia replicata utilizzano lo stesso comando API, che sovrascrive la tassonomia precedente.

Per facilitare la sincronizzazione della tassonomia, puoi utilizzare Cloud Scheduler per eseguire periodicamente una sincronizzazione della tassonomia tra le regioni, in base a una pianificazione impostata o premendo un pulsante manuale. Per utilizzare Cloud Scheduler, devi configurare un account di servizio.

Replica di una tassonomia in una nuova località

Autorizzazioni obbligatorie

Le credenziali utente o il account di servizio che replica la tassonomia devono avere il ruolo Amministratore tag di policy di Data Catalog.

Scopri di più sulla concessione del ruolo Amministratore tag di policy in Limitazione dell'accesso con la sicurezza a livello di colonna di BigQuery.

Per saperne di più sui ruoli e sulle autorizzazioni IAM in BigQuery, consulta Ruoli e autorizzazioni predefiniti.

Per replicare una tassonomia in più località:

API

Chiama il metodo projects.locations.taxonomies.import dell'API Data Catalog, fornendo una richiesta POST e il nome del progetto e della località di destinazione nella stringa HTTP.

POST https://datacatalog.googleapis.com/{parent}/taxonomies:import

Il parametro di percorso parent è il progetto e la località di destinazione in cui vuoi copiare la tassonomia. Esempio: projects/MyProject/locations/eu

Punto chiave: per sincronizzare la tassonomia replicata tra le località in futuro, ripeti gli stessi passaggi.

Sincronizzazione di una tassonomia replicata

Per sincronizzare una tassonomia che è già stata replicata in più località, ripeti la chiamata API Data Catalog come descritto in Replica di una tassonomia in una nuova località.

In alternativa, puoi utilizzare un account di servizio e Cloud Scheduler per sincronizzare la tassonomia in base a una pianificazione specificata. La configurazione di un account di servizio in Cloud Scheduler consente anche di attivare una sincronizzazione on demand (non pianificata) tramite la pagina di Cloud Scheduler nella console Google Cloud o con Google Cloud CLI.

Nota: Una volta che una tassonomia viene replicata in altre posizioni, le modifiche apportate in una posizione non si riflettono automaticamente nelle altre posizioni. La tassonomia deve essere sincronizzata di nuovo in modo esplicito da un utente o da un account di servizio con le autorizzazioni appropriate.

Sincronizzazione di una tassonomia replicata con Cloud Scheduler

Per sincronizzare una tassonomia replicata tra località con Cloud Scheduler, devi disporre di un account di servizio.

Service account

Puoi concedere le autorizzazioni per la sincronizzazione della replica a un service account esistente o crearne uno nuovo.

Per creare un nuovo account di servizio, consulta Crea service account.

Autorizzazioni obbligatorie

1. Il account di servizio che sincronizza la tassonomia deve avere il ruolo Amministratore tag di policy di Data Catalog. Per saperne di più, consulta Il ruolo Amministratore tag di policy di Data Catalog.

2. Abilita l'API Cloud Scheduler

Configurazione di una sincronizzazione della tassonomia con Cloud Scheduler

Per sincronizzare una tassonomia replicata tra località con Cloud Scheduler:

Console

Innanzitutto, crea il job di sincronizzazione e la relativa pianificazione.

1. Segui le istruzioni per creare un job in Cloud Scheduler.

2. Per Target, consulta le istruzioni riportate in Creazione di un job dello scheduler con autenticazione.

Successivamente, aggiungi l'autenticazione necessaria per la sincronizzazione pianificata.

1. Fai clic su MOSTRA ALTRO per visualizzare i campi di autenticazione.

2. Per Intestazione di autenticazione, seleziona "Aggiungi token OAuth".

3. Aggiungi le informazioni del account di servizio.

4. In Ambito, inserisci "https://www.googleapis.com/auth/cloud-platform".

5. Fai clic su Crea per salvare la sincronizzazione pianificata.

   

Ora verifica che il job sia configurato correttamente.

1. Dopo aver creato il job, fai clic su Esegui ora per verificare che il job sia configurato correttamente. Successivamente, Cloud Scheduler attiva la richiesta HTTP in base alla pianificazione specificata.

   

Punto chiave: per la sincronizzazione on demand (non pianificata) futura della tassonomia replicata, fai clic su Esegui ora nella pagina Cloud Scheduler nella console Google Cloud .

gcloud

Sintassi:

  gcloud scheduler jobs create http "JOB_ID" --schedule="FREQUENCY" --uri="URI" --oath-service-account-email="CLIENT_SERVICE_ACCOUNT_EMAIL" --time-zone="TIME_ZONE" --message-body-from-file="MESSAGE_BODY"
  

Sostituisci quanto segue:

1. ${JOB_ID} è un nome per il job. Deve essere univoco nel progetto. Tieni presente che non puoi riutilizzare un nome di job in un progetto, anche se elimini il job associato.
2. ${FREQUENCY} è la pianificazione, chiamata anche intervallo del job, della frequenza di esecuzione del job. Ad esempio, "ogni 3 ore". La stringa che fornisci qui può essere qualsiasi stringa compatibile con crontab. In alternativa, gli sviluppatori che hanno familiarità con il cron App Engine legacy possono utilizzare la sintassi cron App Engine.
3. ${URI} è l'URL completo dell'endpoint.
4. --oauth-service-account-email definisce il tipo di token. Tieni presente che le API di Google ospitate su *.googleapis.com prevedono un token OAuth.
5. ${CLIENT_SERVICE_ACCOUNT_EMAIL} è l'indirizzo email del account di servizio client.
6. ${MESSAGE_BODY} è il percorso del file che contiene il corpo della richiesta POST.

Sono disponibili altri parametri di opzione, descritti nella documentazione di riferimento di Google Cloud CLI.

Esempio:

  gcloud scheduler jobs create http cross_regional_copy_to_eu_scheduler --schedule="0 0 1 * *" --uri="https://datacatalog.googleapis.com/v1/projects/my-project/locations/eu/taxonomies:import" --oauth-service-account-email="[e-mail]" --time-zone="America/Los_Angeles" --message-body-from-file=request_body.json
  

Passaggi successivi

• Per una panoramica della sicurezza a livello di colonna con i tag di policy, consulta Introduzione alla sicurezza a livello di colonna di BigQuery.
• Per saperne di più sulla creazione e sull'applicazione dei tag di policy, consulta Limitazione dell'accesso con la sicurezza a livello di colonna di BigQuery.
• Per scoprire l'impatto sulle scritture quando utilizzi la sicurezza a livello di colonna di BigQuery, consulta Impatto sulle scritture con la sicurezza a livello di colonna di BigQuery.
• Per informazioni sulle best practice per l'utilizzo dei tag di policy, consulta Utilizzo dei tag di policy in BigQuery.