Gestione dei tag di criteri in varie località
Questo documento descrive come gestire i tag di criteri in diverse località regionali per la sicurezza a livello di colonna e il mascheramento dinamico dei dati in BigQuery.
BigQuery fornisce un controllo dell'accesso granulare e un mascheramento dinamico dei dati per le colonne sensibili delle tabelle tramite i tag di criteri, supportando la classificazione dei dati basata sui tipi.
Dopo aver creato una tassonomia di classificazione dei dati e applicato i tag policy ai tuoi dati, puoi gestire ulteriormente i tag policy nelle varie posizioni.
Considerazioni sulla posizione
Le taxonomies sono risorse regionali, come i set di dati e le tabelle BigQuery. Quando crei una tassonomia, specifichi la regione o la posizione 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 località regionale.
Sebbene non sia possibile 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.
Utilizzo delle tassonomie in più sedi
Puoi copiare (o replicare) esplicitamente una tassonomia e le relative definizioni deitag di criteriy in altre posizioni senza dover creare manualmente una nuova tassonomia in ogni posizione. Quando replichi le classificazioni, puoi utilizzare gli stessi tag di criteri per la sicurezza a livello di colonna in più posizioni, semplificandone la gestione.
Quando li replichi, la tassonomia e i tag criterio mantengono gli stessi ID in ogni località.
La tassonomia e i tag di criteri possono essere sincronizzati di nuovo per mantenerli unificati in più sedi. 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 prestabilita o con la pressione di un pulsante manuale. Per utilizzare Cloud Scheduler, devi configurare un account di servizio.
Replicare una tassonomia in una nuova posizione
Autorizzazioni obbligatorie
Le credenziali utente o l'account di servizio che replica la tassonomia devono disporre del ruolo Amministratore tag di policy Data Catalog.
Scopri di più sulla concessione del ruolo Amministratore tag di criteri 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ù sedi:
API
Chiama il metodo
projects.locations.taxonomies.import
dell'API Data Catalog, fornendo una richiesta POST e
il nome del progetto di destinazione e della località nella stringa HTTP.
POST https://datacatalog.googleapis.com/{parent}/taxonomies:import
Il parametro di percorso parent è il progetto e la posizione di destinazione
in cui vuoi copiare la tassonomia. Esempio:
projects/MyProject/locations/eu
Sincronizzazione di una tassonomia replicata
Per sincronizzare una tassonomia già replicata in più località, ripeti la chiamata API Data Catalog come descritto in Replicare 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 ti consente anche di attivare una sincronizzazione on demand (non pianificata) tramite la pagina Cloud Scheduler nella console Google Cloud o con Google Cloud CLI.
Sincronizzazione di una tassonomia replicata con Cloud Scheduler
Per sincronizzare una tassonomia replicata in più località con Cloud Scheduler, devi disporre di un account di servizio.
Account di servizio
Puoi concedere le autorizzazioni per la sincronizzazione della replica a un service account esistente oppure puoi crearne uno nuovo.
Per creare un nuovo account di servizio, vedi Creare service account.
Autorizzazioni obbligatorie
Il account di servizio che sincronizza la tassonomia deve avere il ruolo Amministratore tag di policy Data Catalog. Per ulteriori informazioni, consulta Concedere il ruolo Amministratore tag dei criteri.
Configurazione di una sincronizzazione della tassonomia con Cloud Scheduler
Per sincronizzare una tassonomia replicata in più località con Cloud Scheduler:
Console
Innanzitutto, crea il job di sincronizzazione e la relativa pianificazione.
Segui le istruzioni per creare un job in Cloud Scheduler.
Per Target, consulta le istruzioni riportate in Creazione di un job di pianificazione con autenticazione.
Poi, aggiungi l'autenticazione necessaria per la sincronizzazione pianificata.
Fai clic su MOSTRA ALTRO per visualizzare i campi di autenticazione.
Per Intestazione di autenticazione, seleziona "Aggiungi token OAuth".
Aggiungi le informazioni del account di servizio.
Per l'ambito, inserisci "https://www.googleapis.com/auth/cloud-platform".
Fai clic su Crea per salvare la sincronizzazione pianificata.
Ora verifica che il job sia configurato correttamente.
Dopo aver creato il job, fai clic su Esegui ora per verificare che sia configurato correttamente. Successivamente, Cloud Scheduler attiva la richiesta HTTP in base alla pianificazione specificata.
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:
${JOB_ID}è un nome per il job. Deve essere univoco nel progetto. Tieni presente che non puoi riutilizzare il nome di un job in un progetto anche se elimini il job associato.${FREQUENCY}è la pianificazione, chiamata anche intervallo di 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 di App Engine precedente possono utilizzare la sintassi di cron di App Engine.${URI}è l'URL completo dell'endpoint.--oauth-service-account-emaildefinisce il tipo di token. Tieni presente che le API di Google ospitate su*.googleapis.comprevedono un token OAuth.${CLIENT_SERVICE_ACCOUNT_EMAIL}è l'email del account di servizio client.${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="policytag-manager-service-acou@my-project.iam.gserviceaccount.com" --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 criteri, consulta Introduzione alla sicurezza a livello di colonna di BigQuery.
- Per saperne di più sulla creazione e sull'applicazione dei tag di criteri, consulta Limitare l'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 criteri, vedi Utilizzo dei tag di criteri in BigQuery.