BigQuery e i data governance tags: come proteggere le colonne sensibili senza rifare il data model

BigQuery sta spostando parte della governance dei dati sensibili dal controllo “a progetto” a un controllo più vicino al modello dati. La novità riguarda i data governance tags, collegati a tag IAM e data policy, con cui è possibile applicare accesso selettivo e masking a livello di colonna. Google Cloud li documenta come funzionalità Preview e li presenta come uno strumento utile per gestire taxonomy e policy in modo più centralizzato rispetto ai soli policy tags tradizionali. Fonte · Documentazione BigQuery

Per una PMI il punto non è solo tecnico: significa poter condividere tabelle con più team senza esporre, per errore, colonne con dati personali, finanziari o comunque riservati. Il vantaggio pratico sta nel separare tre aspetti che spesso vengono confusi: classificazione, accesso e mascheramento.

Quando ha senso usarli

I data governance tags sono più utili quando:

dataset e dashboard sono condivisi tra reparti diversi;
alcune colonne devono essere visibili solo a gruppi specifici;
serve mascherare un campo, non bloccare l’intera tabella;
il team vuole un flusso coerente tra classificazione del dato, policy e controllo degli accessi. Documentazione sul masking · Column-level security

Non sono invece la risposta giusta se il problema è più semplice, per esempio una sola tabella da proteggere con ruoli già ben definiti. In quel caso, introdurre una taxonomy complessa può aggiungere solo gestione.

Prerequisiti da verificare prima di partire

Prima di adottarli, conviene controllare questi punti:

Edizione e permessi: la documentazione BigQuery indica che per creare e gestire i data governance tags serve BigQuery Enterprise edition e ruoli specifici per tag, policy e tabelle. Documentazione BigQuery
Modello di ruoli: chi amministra i tag non dovrebbe essere la stessa persona che concede gli accessi quotidiani alle tabelle, per evitare privilegi eccessivi.
Mappa dei dati sensibili: bisogna sapere quali colonne contengono PII, dati economici, identificativi interni o altri campi riservati.
Regole di fallback: se la policy non si applica come previsto, il comportamento deve essere definito e testato prima del rilascio.

Flusso operativo minimo

Il flusso, in pratica, è questo:

Classificare la colonna o il campo.
Assegnare il tag di governance alla colonna.
Collegare la policy al tag o alla colonna, in base al disegno scelto.
Definire chi vede cosa: accesso pieno, accesso limitato o masking.
Testare con utenti reali di ruoli diversi.

Google documenta che i data governance tags possono essere usati sia per il column-level access control sia per il data masking, e che il controllo è legato ai permessi IAM e alle policy collegate al tag. Data masking intro · Column-level security intro

Esempio concreto, con dati simulati

Caso simulato: un reparto commerciale con una tabella clienti_ordini in BigQuery.

id_cliente → visibile al team vendite
email → visibile solo al customer care
fatturato_annuo → visibile ai manager
note_interne → mascherate per tutti tranne gli amministratori autorizzati

Input esemplificativo

id_cliente	email	fatturato_annuo	note_interne
C1024	m.rossi@example.it	18500	Verifica manuale richiesta

Output atteso per un utente vendite

id_cliente	email	fatturato_annuo	note_interne
C1024	mascherata	mascherata	mascherata

Output atteso per un manager autorizzato

id_cliente	email	fatturato_annuo	note_interne
C1024	mascherata	18500	mascherata

Questo esempio è didattico: il risultato reale dipende da taxonomy, policy tag, ruoli IAM e configurazione effettiva del progetto.

Controlli di accettazione: chi verifica cosa e quando

Prima del rilascio

Data platform: verifica che i tag siano applicati alle colonne corrette.
Security/IAM: verifica che i ruoli concessi siano minimi e separati.
Business owner: conferma quali colonne devono essere visibili e a chi.

Durante il test

Utente con permessi bassi: deve vedere solo i campi consentiti o mascherati.
Utente autorizzato: deve vedere i dati completi solo dove previsto.
Data owner: controlla che non ci siano eccezioni indesiderate su tabelle o viste derivate.

Dopo il rilascio

Security: controlla audit e cambi di policy.
Data platform: monitora nuove colonne o nuove tabelle che potrebbero restare senza tag.

Limiti da non sottovalutare

La documentazione Google mostra un modello potente, ma non automatico. I data governance tags non sostituiscono una strategia IAM ben progettata: la protezione regge solo se ruoli, taxonomy e policy sono coerenti. Inoltre, al momento delle fonti consultate, la funzione risulta ancora in Preview, quindi va trattata come una tecnologia da valutare e testare, non come uno standard definitivo. Documentazione BigQuery

Per una PMI il punto chiave è evitare un falso senso di sicurezza: una colonna taggata male, un ruolo troppo ampio o una vista non testata possono annullare il vantaggio della governance.

Cosa fare adesso

Se usate BigQuery, il passo utile non è “attivare tutto”, ma scegliere un dataset pilota e rispondere a tre domande:

quali colonne sono davvero sensibili;
chi deve vederle, e in quale forma;
quali controlli manuali servono per verificare che masking e accesso funzionino come previsto.

Da lì si può costruire una policy replicabile su altri dataset, evitando di rifare il data model e riducendo il rischio di accessi eccessivi.

Se vuoi, puoi partire da un processo concreto e separare accessi, masking e responsabilità in modo verificabile.

BigQuery e i data governance tags: come proteggere le colonne sensibili senza rifare il data model