BigQuery data governance tags: dove mettere la policy e come verificarla

Parliamo del tuo progetto →

Risposta breve

I BigQuery data governance tags servono quando il problema non è solo “chi può leggere una tabella”, ma quale colonna deve essere mascherata, negata o governata in modo diverso in un ambiente con più team e più progetti. La documentazione Google li colloca tra le funzioni di governance di BigQuery per il controllo a livello di colonna, con prerequisiti, ruoli e limiti specifici, e segnala che la configurazione va progettata con attenzione quando le policy vivono in progetti diversi (data governance, tags).

Per un responsabile dati, la domanda utile non è “posso attivarli?”, ma:

  • dove vive la policy;
  • chi la può amministrare;
  • come verifico che il controllo sia applicato davvero;
  • come recupero la configurazione se un tag value viene rimosso.

Se ti serve una lettura più ampia su piattaforme dati e governance, puoi collegare questo tema a Data platform e analytics responsabili e, quando il tema tocca responsabilità, priorità e ownership, a Consulenza strategica e governance IT. Per il lato operativo del controllo del dato, è utile anche il contenuto su lineage in BigQuery e Knowledge Catalog.

Quando il caso d’uso è adatto

I data governance tags hanno senso quando servono insieme queste tre condizioni:

  1. controllo colonnare: non vuoi proteggere tutto il dataset allo stesso modo, ma solo alcune colonne sensibili;
  2. più progetti o più team: i dati e la governance non stanno nello stesso confine organizzativo;
  3. governo esplicito: vuoi ruoli, policy e naming leggibili e verificabili, non convenzioni implicite.

La documentazione BigQuery indica inoltre che i data governance tags sono una funzionalità Preview e richiedono BigQuery Enterprise edition; l’accesso dipende da ruoli IAM specifici e dal formato corretto del tag (tags).

Questa combinazione è utile quando vuoi una governance chiara e ripetibile. Non è la scelta giusta se cerchi una scorciatoia amministrativa o una configurazione da attivare “al volo” senza presidio operativo.

Le quattro dimensioni da tenere separate

Quando si parla di governance dei dati, è facile mescolare tutto sotto l’etichetta “sicurezza”. Conviene invece distinguere quattro dimensioni.

1. Disponibilità operativa

La domanda è: la policy può essere applicata quando serve, senza blocchi amministrativi inutili?

Gli indicatori utili sono:

  • presenza dei ruoli corretti per creare e gestire i tag;
  • possibilità di assegnare e aggiornare le policy senza dipendere da un singolo account;
  • assenza di errori operativi dovuti a permessi mancanti.

Se questa dimensione fallisce, il problema non è la sicurezza del dato, ma la capacità del team di governarlo in tempo utile.

2. Recuperabilità

La domanda è: se una configurazione viene modificata o rimossa, posso ricostruire il controllo senza perdere il perimetro?

La documentazione segnala un rischio concreto: se un tag value viene cancellato, il binding può restare attivo ma la colonna può diventare inaccessibile (tags).

Questo è un caso classico di recuperabilità: la policy non si giudica solo quando funziona, ma anche quando qualcosa viene eliminato o riallineato. Serve quindi un inventario dei tag, una convenzione di naming stabile e una procedura di ripristino.

3. Sicurezza

La domanda è: le colonne sensibili sono davvero protette nel modo previsto?

Gli indicatori utili sono:

  • numero di colonne sensibili con tag assegnato;
  • numero di colonne sensibili senza tag;
  • presenza di policy diverse per valori diversi del tag;
  • verifica che un utente non autorizzato veda il comportamento atteso: mascheramento o negazione, secondo la regola impostata.

La sicurezza, in questo contesto, non è astratta: si osserva nel risultato di accesso alla colonna.

4. Qualità del dato governato

La domanda è: la tassonomia dei tag è coerente, leggibile e mantenibile?

Gli indicatori utili sono:

  • nomi dei tag scritti in modo consistente;
  • valori brevi e standardizzati;
  • assenza di etichette duplicate o ambigue;
  • copertura completa delle colonne sensibili note.

La qualità del dato governato non coincide con la qualità del contenuto della colonna. Riguarda invece la qualità della sua classificazione e della sua protezione.

Architettura operativa consigliata

In un contesto multi-progetto, il modello più leggibile è questo:

  • un progetto dati che contiene le tabelle;
  • un progetto governance che contiene le policy o il controllo amministrativo;
  • una convenzione di tag con nome namespaced;
  • ruoli distinti per chi amministra i tag e per chi amministra le data policy.

La documentazione BigQuery chiarisce che le policy del progetto della tabella hanno precedenza rispetto a quelle in altri progetti, salvo l’uso di un default data policy project a livello di organizzazione (tags). Questo punto è cruciale: se i team lavorano su progetti diversi, bisogna decidere in anticipo se la governance sarà locale o centralizzata.

Il punto sul naming

Il tag key va usato nel formato namespaced previsto dalla documentazione, per esempio PROJECT_ID/TAG_KEY oppure ORGANIZATION_ID/TAG_KEY (tags).

Non è un dettaglio estetico: è un controllo di coerenza. Se il naming è ambiguo, la policy diventa fragile e più difficile da mantenere.

Tre scelte pratiche

A. Governance locale nel progetto della tabella

Conviene quando:

  • il perimetro è piccolo;
  • i dati e la governance stanno nello stesso team;
  • non hai una vera esigenza multi-progetto.

Vantaggio: meno complessità organizzativa.

Limite: scala peggio quando i dataset aumentano o quando più team devono condividere la stessa logica di accesso.

B. Governance centralizzata con default data policy project

Conviene quando:

  • la tua organizzazione usa più progetti;
  • vuoi una logica uniforme;
  • ti serve che la policy valga oltre il singolo progetto della tabella.

Vantaggio: più coerenza e meno eccezioni.

Limite: richiede disciplina amministrativa e ruoli ben definiti.

C. Rimandare l’adozione

Conviene quando:

  • non hai ancora l’Edizione Enterprise necessaria;
  • i ruoli IAM non sono chiari;
  • non sai ancora quali colonne siano davvero sensibili;
  • non puoi presidiare il ciclo di modifica e verifica.

Rinviare non è un fallimento: a volte è la scelta più corretta, perché evita una governance apparente ma non verificabile.

Esempio simulato completo

Immaginiamo un ambiente con questi elementi:

  • Project della tabella: sales-prod
  • Project di governance: governance-core
  • Edizione BigQuery: Enterprise
  • Tabella: customer_orders
  • Colonne sensibili:
    • customer_email
    • customer_tax_id
    • delivery_address

Tag e policy previsti

  • Tag key: pii
  • Tag values: email, tax_id, address

Policy previste:

  • pii=email → mascheramento
  • pii=tax_id → accesso negato per chi non è autorizzato
  • pii=address → mascheramento

Ruoli minimi nel caso simulato

  • amministratore dati sul dataset;
  • amministratore delle data policy nel progetto governance;
  • amministratore dei tag a livello organizzativo;
  • analista con accesso alla tabella ma non alle policy sensibili.

Formula di controllo

Per misurare la copertura della classificazione:

copertura_policy = (colonne_sensitive_con_tag / colonne_sensitive_totali) × 100

Nel caso simulato:

  • colonne sensibili totali = 3
  • colonne con tag = 3

Quindi:

copertura_policy = (3 / 3) × 100 = 100%

Tabella di verifica

Controllo Soglia Evidenza attesa Responsabile
Colonne sensibili taggate 100% Tutte le 3 colonne hanno un tag assegnato Data owner
Naming del tag 100% conforme PROJECT_ID/TAG_KEY o ORGANIZATION_ID/TAG_KEY Governance admin
Policy applicata nel progetto corretto Nessun conflitto La policy risulta coerente con la precedence prevista BigQuery admin
Accesso utente non autorizzato Negato o mascherato L’utente vede il comportamento previsto dalla regola Security/analytics
Recuperabilità del binding Verificata Esiste una procedura se un tag value viene rimosso Platform owner

Esito atteso

Se tutto è configurato bene:

  • l’analista vede i dati mascherati o negati secondo la regola;
  • i tre campi sensibili restano classificati;
  • il team sa dove intervenire se un tag value viene eliminato.

Esempio di errore

Supponiamo ora che il team registri il tag key come pii senza il formato namespaced richiesto, oppure che assegni la policy nel progetto sbagliato rispetto a quello che ospita la tabella.

In questo caso il problema non è solo tecnico: è di governance. Il controllo potrebbe non applicarsi come previsto o risultare difficile da verificare, perché la logica di precedenza tra progetti non è stata progettata prima.

Il segnale osservabile non è “la feature non esiste”, ma questo:

  • la colonna non mostra il comportamento atteso;
  • il team non sa se il problema dipende dal naming, dai ruoli o dal progetto di policy;
  • l’esercizio di recupero richiede interventi manuali e tempo aggiuntivo.

Questo è il motivo per cui la qualità del dato governato va controllata insieme alla sicurezza.

Controllo finale ripetibile

Per chiudere il pilot, usa sempre lo stesso ordine:

  1. verifica copertura: quante colonne sensibili hanno un tag;
  2. verifica applicazione: il comportamento di accesso è quello previsto;
  3. verifica ownership: chi può cambiare cosa;
  4. verifica recupero: cosa succede se un tag value viene rimosso;
  5. verifica logging interno: esiste un modo per ricostruire la decisione.

Se uno solo di questi punti è incerto, il pilot non è ancora pronto per l’estensione.

Limiti da dichiarare subito

BigQuery documenta chiaramente alcuni limiti che vanno esplicitati nel progetto:

  • i data governance tags sono in Preview;
  • serve BigQuery Enterprise edition;
  • servono ruoli specifici per creare e gestire tag e policy;
  • la precedenza tra policy di progetti diversi va progettata prima;
  • la cancellazione di un tag value può lasciare il binding attivo ma rendere la colonna inaccessibile (tags).

Questi limiti non rendono la soluzione inutile. La rendono, però, una scelta da fare con metodo, non da attivare senza governo in un ambiente senza regole.

Quando conviene portare il tema in un progetto vero

Se il tuo problema è uno di questi:

  • gestire dati sensibili in più progetti;
  • ridurre il rischio di accesso improprio alle colonne;
  • decidere dove centralizzare le policy;
  • costruire una classificazione dei dati che resti mantenibile;

allora la discussione non è solo tecnica. È una scelta di architettura e di governance.

In questi casi ha senso partire da una mappa semplice: quali colonne sono sensibili, chi decide la policy, dove vive il controllo e come si verifica il risultato. Su questo punto si innesta bene un lavoro di progettazione della data platform e analytics responsabili, soprattutto quando la complessità tra progetti rischia di rendere opaca la protezione del dato.

Fonti