BigQuery: come decidere tra policy tags e data governance tags per proteggere le colonne sensibili

Parliamo del tuo progetto →

BigQuery oggi offre due strade principali per la column-level security: i policy tags e i data governance tags. La differenza non è solo lessicale: cambia il modo in cui si organizza la classificazione, si gestiscono i ruoli e si mantiene il dynamic data masking sulle colonne sensibili.

Google Cloud ha presentato i data governance tags in BigQuery come preview e li descrive come una soluzione più scalabile, basata su IAM Resource Manager, con tag globali e gerarchie fino a cinque livelli. I policy tags, invece, restano la soluzione documentata per il controllo degli accessi a livello di colonna e per il masking, con tassonomie regionali. (blog ufficiale, documentazione BigQuery)

Quando conviene un approccio e non l’altro

Per una PMI, la scelta non va fatta in astratto. Conviene partire dal problema operativo.

  • Hai già una tassonomia regionale stabile e non vuoi cambiare il flusso attuale? I policy tags sono la strada più lineare.
  • Devi classificare gli stessi dati in più regioni o vuoi un modello globale più semplice da riusare? I data governance tags meritano una valutazione, ma essendo in preview vanno testati con cautela.
  • Ti serve masking su colonne già governate? BigQuery supporta il masking con policy tags e anche con data governance tags; la documentazione mostra inoltre che le data policy possono essere applicate direttamente alla colonna, in base al caso d’uso. (documentazione masking)

La regola pratica è semplice: non migrare per principio, migrare per necessità organizzativa. Se il perimetro è stabile e regionale, i policy tags possono bastare. Se invece il problema è la gestione globale della classificazione, i data governance tags possono ridurre attriti futuri.

Cosa verificare prima di scegliere

Prima di aprire un progetto pilota, controlla questi quattro punti.

  1. API e permessi: la documentazione BigQuery indica che, per creare e gestire policy tags e taxonomy usate nel masking, l’API datacatalog.googleapis.com deve essere abilitata. (documentazione intro)
  2. Regione o globalità: i policy tags sono regionali; i data governance tags sono descritti come globali nel post di lancio. (blog ufficiale)
  3. Maturità del servizio: i data governance tags sono in preview, quindi vanno trattati come una funzionalità da sperimentare, non come sostituzione definitiva.
  4. Integrazione con il flusso esistente: se usi già il masking, verifica dove vive oggi la classificazione e chi la mantiene: team dati, sicurezza o platform.

Esempio pratico simulato

Scenario simulato: una PMI gestisce anagrafiche clienti in BigQuery e vuole proteggere due colonne: email e codice_fiscale.

Input di lavoro:

  • tabella crm.clienti
  • colonna email visibile agli operatori del supporto
  • colonna codice_fiscale visibile solo al team autorizzato
  • reporting aggregato per il management

Opzione 1: policy tags

  • crei una tassonomia regionale per i dati sensibili;
  • associ i tag alle colonne;
  • abiliti il masking dove serve;
  • verifichi che i ruoli IAM siano coerenti con chi può vedere il dato completo.

Opzione 2: data governance tags

  • definisci una gerarchia globale di classificazione;
  • colleghi i tag alle colonne;
  • usi la preview per capire se il modello semplifica la governance multi-area o multi-regione;
  • misuri l’impatto operativo prima di una migrazione più ampia.

Output atteso simulato:

  • il supporto vede l’email mascherata;
  • il team autorizzato vede codice_fiscale completo;
  • il management accede solo a viste aggregate.

Checklist di accettazione

Questa verifica va fatta prima del go-live dal team dati e sicurezza.

  • Le colonne sensibili sono elencate e classificate? Controllo: data owner.
  • Le autorizzazioni IAM sono coerenti con i ruoli reali? Controllo: security o platform owner.
  • Il masking restituisce il valore atteso per utenti autorizzati e non autorizzati? Controllo: test funzionale su account separati.
  • La governance resta comprensibile a chi dovrà mantenerla? Controllo: data lead.
  • Se la soluzione è in preview, esiste un piano di rollback o di coesistenza con i policy tags? Controllo: architecture review.

L’errore da evitare

L’errore più comune è leggere i data governance tags come una sostituzione totale già pronta. Non è così: la documentazione conferma che i policy tags restano supportati e utili, mentre la preview dei nuovi tag va interpretata come opzione aggiuntiva per i casi in cui il modello regionale diventa un limite.

In sintesi

Per una PMI, la domanda giusta non è “quale tecnologia è più moderna?”, ma quale modello riduce davvero il rischio operativo senza complicare la manutenzione.

Se la tassonomia regionale funziona, restare sui policy tags è una scelta ragionevole. Se invece la governance deve diventare globale, gerarchica e più centralizzata, i data governance tags meritano una valutazione in un perimetro controllato, con verifiche esplicite su API, ruoli, masking e coesistenza.

Se il tema è il controllo delle colonne sensibili nel tuo ambiente BigQuery, il punto di partenza non è la funzione nuova in sé: è la mappa dei dati e dei ruoli. È questa la differenza tra una prova utile e una migrazione affrettata.

Fonti