BigQuery: quando conviene configurare un default data policy project per i data governance tags

Parliamo del tuo progetto →

BigQuery: quando conviene configurare un default data policy project per i data governance tags

Risposta breve

Se le tabelle sensibili stanno in un progetto e la governance in un altro, il default data policy project serve quando vuoi che BigQuery valuti anche le policy del progetto di governance, invece di limitarsi a quelle del progetto della tabella. La documentazione Google Cloud indica che i data governance tags supportano controllo colonnare e masking, che la funzionalità è ancora in Preview e che, con il progetto predefinito configurato, BigQuery considera sia le policy del progetto della tabella sia quelle del progetto predefinito; in caso di conflitto prevale la policy del progetto della tabella. (Control access with tags, Manage default configuration settings, Restrict access with column-level access control, Introduction to data masking)

In pratica, la scelta è utile quando la governance è centralizzata ma i dataset sono distribuiti. Se invece tabelle e policy vivono già nello stesso progetto, spesso è più semplice lavorare con la tassonomia dei tag e con i ruoli corretti, senza aggiungere un livello amministrativo in più. Le best practice sui policy tags restano comunque una strada valida quando l’organizzazione preferisce una classificazione colonnare più strutturata. (Best practices for using policy tags in BigQuery, Introduction to data governance in BigQuery)

Che cosa cambia davvero

Il punto non è soltanto creare una policy, ma capire dove viene valutata quando una query legge una colonna protetta. Senza configurazione aggiuntiva, BigQuery considera le policy presenti nel progetto della tabella. Con il default data policy project, invece, amplia il perimetro di valutazione alle policy del progetto predefinito. Questo dettaglio è decisivo negli ambienti multi-progetto, dove governance, dataset e consumo analitico sono separati. (Control access with tags, Manage default configuration settings)

La conseguenza operativa è semplice: una policy può essere scritta correttamente ma restare inefficace se si trova nel progetto sbagliato rispetto alla tabella. Il default data policy project riduce questo rischio, ma non sostituisce una classificazione chiara delle colonne né una progettazione attenta dei ruoli.

Quando basta la policy nel progetto della tabella

Non sempre serve un progetto predefinito per le data policy. Se il team è piccolo, i dataset sono pochi e governance e tabelle vivono già nello stesso progetto, la soluzione più lineare è spesso la migliore.

In questo scenario:

  • il percorso di valutazione è più leggibile;
  • i ruoli sono più facili da controllare;
  • il rischio di policy “fantasma” è più basso;
  • la manutenzione è più semplice.

Qui il problema principale non è la distribuzione delle policy, ma la qualità della classificazione: tag coerenti, ruoli chiari e masking definito bene sulle colonne sensibili.

Quando conviene il default data policy project

Il default data policy project diventa interessante quando:

  • i dati stanno in un progetto;
  • le policy stanno in un altro;
  • la governance è centralizzata;
  • più team gestiscono tabelle, policy e consumi;
  • vuoi evitare che una policy esista ma non venga mai considerata nella lettura della tabella.

In questi casi la scelta non è “più avanzata”, ma più adatta a una struttura distribuita. Il vantaggio è organizzativo prima ancora che tecnico: riduce il rischio di errori dovuti alla separazione tra chi definisce la governance e chi pubblica i dataset.

Tre architetture a confronto

Modello Quando ha senso Vantaggio Rischio principale
Policy e tabelle nello stesso progetto Team piccolo, pochi dataset, governance semplice La valutazione è immediata e leggibile Governance frammentata se il perimetro cresce
Tabella in un progetto, policy in un altro con default data policy project Più team, più progetti, governance centralizzata Unifica il controllo senza spostare i dati Richiede test e disciplina sui ruoli
Policy tags come tassonomia principale Classificazione colonnare già matura o standardizzata Maggiore coerenza nella classificazione Serve progettare bene la gerarchia dei tag

La domanda giusta non è quale modello sembri più sofisticato, ma quale riduca di più il rischio operativo nel vostro contesto.

Esempio simulato completo

Scenario

Caso simulato di un’azienda che usa tre progetti Google Cloud:

  • sales-raw: contiene la tabella con gli ordini;
  • security-central: contiene le policy e la governance;
  • bi-prod: esegue le query di consumo.

Tabella: sales-raw.orders.customer_orders

Colonne:

  • order_id STRING
  • customer_id STRING
  • customer_email STRING
  • order_total NUMERIC
  • order_date DATE

Righe di esempio:

  1. O-1001 | C-10 | alice@example.test | 120.50 | 2026-10-01
  2. O-1002 | C-11 | bob@example.test | 89.90 | 2026-10-01
  3. O-1003 | C-12 | chiara@example.test | 44.00 | 2026-10-02
  4. O-1004 | C-10 | alice@example.test | 15.00 | 2026-10-03

Tag di classificazione:

  • classification = sensitive

Data policy attesa:

  • gruppo autorizzato: data-privacy@company.test
  • tutti gli altri ruoli: masking sulla colonna customer_email

Formula di verifica

esito = (la policy viene valutata nel progetto corretto) AND
        (il gruppo autorizzato vede il dato in chiaro) AND
        (il gruppo non autorizzato vede il dato mascherato)

Caso sano

Configurazione:

  • la tabella è in sales-raw;
  • il default data policy project è impostato correttamente;
  • la policy per classification = sensitive è presente e valida;
  • il gruppo data-privacy@company.test ha accesso in chiaro.

Esito atteso:

  • il gruppo privacy legge customer_email in chiaro;
  • il gruppo analitico standard vede customer_email mascherato;
  • le altre colonne restano leggibili secondo i permessi già previsti.

Caso guasto

Configurazione:

  • la policy è stata creata solo in security-central;
  • il default data policy project non è configurato;
  • la query parte da bi-prod sulla tabella in sales-raw.

Esito atteso:

  • BigQuery valuta solo le policy del progetto della tabella;
  • la policy centrale non entra nel percorso di valutazione;
  • il masking previsto dalla governance centrale non si applica come atteso.

Questo è il motivo per cui la posizione della policy conta quanto la sua definizione.

Come verificare prima di andare in produzione

Prima di adottare questa configurazione in modo esteso, conviene controllare almeno questi punti:

  1. La tabella sensibile è classificata in modo coerente
    Verifica il legame tra colonna e tag, senza ambiguità sui campi da proteggere.

  2. La policy vive nel progetto giusto
    Controlla dove risiede la policy rispetto alla tabella e se il default data policy project è effettivamente configurato.

  3. Il test attraversa un progetto diverso
    Esegui una query di prova da un progetto di consumo distinto da quello della tabella.

  4. I ruoli producono esiti diversi
    Un ruolo autorizzato deve vedere il valore in chiaro; un ruolo non autorizzato deve vedere il masking previsto.

  5. Il comportamento è documentato
    Registra il risultato del test e chi ne ha verificato l’esito, così da poterlo ripetere nel tempo.

Limiti da tenere presenti

Tre limiti vanno dichiarati chiaramente:

  • i data governance tags sono ancora in Preview e il comportamento può evolvere;
  • la documentazione descrive il prodotto, ma non sostituisce una prova nel vostro ambiente;
  • il masking governa l’accesso, non la qualità del dato né il suo recupero.

Per questo il costo reale della scelta non è solo economico. È soprattutto operativo: modellazione dei tag, assegnazione dei ruoli, test tra progetti e manutenzione del runbook. La documentazione non fornisce un listino dedicato per questa configurazione, quindi sarebbe scorretto trasformare il tema in un benchmark di prezzo.

Quale alternativa scegliere

In sintesi:

  • stesso progetto: se il perimetro è piccolo e la governance è semplice;
  • default data policy project: se la governance è centralizzata ma i dataset sono distribuiti;
  • policy tags: se volete una classificazione colonnare più strutturata o già allineata a standard interni.

La regola pratica è questa: se il vostro rischio principale è dimenticare dove vive la policy, il progetto predefinito può essere la risposta giusta. Se invece il rischio è una tassonomia confusa, il problema è prima di tutto di classificazione.

Dove collocare questo tema nel lavoro quotidiano

Se devi tradurre questa scelta in una piattaforma dati, il punto di partenza naturale è Data platform e analytics responsabili, perché il tema riguarda governo del dato, qualità delle metriche e controllo dell’accesso.

Se la tua organizzazione deve chiarire responsabilità, priorità e processi tra più team, può essere utile anche Consulenza strategica e governance IT.

Quando la separazione tra ambienti e policy si accompagna a temi di accessi, backup e controllo dell’infrastruttura, il quadro si completa con Cybersecurity e infrastrutture cloud.

Cosa preparare per il primo confronto

Per un confronto utile con il team cloud o con il fornitore, prepara solo elementi non riservati:

  • elenco dei progetti coinvolti;
  • tabella o dataset da proteggere;
  • colonna sensibile da classificare;
  • ruolo che deve vedere il dato in chiaro;
  • ruolo che deve vederlo mascherato;
  • esempio di query da usare nel test;
  • esito atteso in caso di conflitto tra policy.

Con questi dati si capisce subito se il problema è di classificazione, di configurazione o di governance tra progetti.

Fonti