Azure Databricks - Governed Tags e ABAC Policy: cambia tutto!

Gestire la governance dei dati su una piattaforma distribuita, con centinaia di tabelle e diversi team, non è mai stato semplice. Chi lavora su Azure Databricks conosce bene il problema: i tag vengono applicati in modo inconsistente, le policy di accesso si moltiplicano per ogni workspace, e garantire la conformità GDPR su dati sensibili diventa un lavoro manuale e soggetto a errori.

Ho testato alle nuove funzionalità Governed Tags e ABAC Policy di Azure Databricks Unity Catalog nelle ultime settimane. La mia conclusione è netta: portano un valore enorme alla piattaforma e rappresentano un salto qualitativo significativo nella maturità della governance Databricks.

Unity Catalog: lo standard emergente per la data governance unificata

Unity Catalog non è solo un catalogo dati. È il layer di governance centralizzato di Azure Databricks, quello che unifica il controllo degli accessi, il tracciamento del lineage, l’auditing e la qualità dei dati su tutti i workspace collegati a uno stesso metastore.

Il modello a oggetti segue una gerarchia a tre livelli (catalog.schema.object). Ogni oggetto (tabella, vista, volume, modello ML) è un securable object su cui puoi definire permessi, applicare tag e tracciare ogni accesso.

Con l’avanzare rapido delle sue funzionalità, Unity Catalog sta diventando il riferimento de facto per la governance su piattaforme datalakehouse enterprise. I Governed Tags e le ABAC Policy ne sono la dimostrazione più concreta: non si tratta di funzionalità accessorie, ma dei componenti che mancavano per costruire una governance seria su larga scala.

Governed Tags: la fine del tagging caotico

Il tagging su Databricks esiste da tempo, ma fino ad oggi era completamente libero. Chiunque poteva creare qualsiasi tag con qualsiasi valore, su qualsiasi oggetto. Il risultato è quello che si vede in quasi tutte le piattaforme medio-grandi: tag inconsistenti, nomi diversi per lo stesso concetto (pii, PII, Pii_data, sensitive), impossibile usarli in modo affidabile per automazioni o policy.

I Governed Tags risolvono questo problema alla radice.

Un Governed Tag è un tag definito a livello di account, non di workspace. Ha una Tag Policy incorporata che specifica la chiave del tag (es. pii), i valori consentiti (es. ssn, address, email, massimo 50), chi può assegnarlo tramite permesso ASSIGN e dove può essere applicato.

Quando un Governed Tag viene applicato a un oggetto, appare nell’interfaccia Databricks con un’icona lucchetto, distinguendolo visivamente dai tag liberi. In pratica questo è più utile di quanto sembri: chiunque esplori il catalogo capisce immediatamente quali tag sono sotto governance e quali no.

Una volta che la tabella esiste nel catalog, applicare i Governed Tag richiede pochi comandi ALTER TABLE. Per questo esempio lavoriamo con due tag distinti su due colonne:

• pii = ssn sulla colonna ssn → attiva la Column Mask Policy
• data_access = restricted sulla colonna business_unit → attiva la Row Filter Policy

Tenere i due tag separati riflette responsabilità diverse: pii riguarda la classificazione privacy (GDPR, compliance), data_access governa la visibilità commerciale per business unit. Due team distinti, il “Data Protection Officer” e il “Sales Operations” possono gestire i permessi ASSIGN su ciascuno in modo indipendente.

-- PII tag on ssn column: triggers Column Mask Policy
ALTER TABLE sc_demo.bronze.customer_profiles ALTER COLUMN ssn SET TAGS ('pii' = 'ssn');

-- Data access tag on business_unit column: triggers Row Filter Policy
ALTER TABLE sc_demo.bronze.customer_profiles ALTER COLUMN business_unit SET TAGS ('data_access' = 'restricted');

Dopo aver eseguito i comandi, apri la tabella in Catalog Explorer. Le colonne ssn e business_unit mostrano l’icona lucchetto accanto al nome del tag. È il segnale visivo che conferma che il tag è sotto governance e non può essere assegnato con valori arbitrari.

Un dettaglio interessante: se crei un Governed Tag con la stessa chiave di tag già esistenti nel tuo account, quegli assignment vengono automaticamente portati sotto governance. Puoi introdurre la governance incrementalmente, senza dover riapplicare manualmente i tag a tutto il catalogo.

L’ereditarietà funziona come ti aspetteresti. Se applichi un tag a un catalog o schema, tutti gli oggetti figli lo ereditano in automatico. L’unica eccezione riguarda le singole colonne di tabella, che non ereditano. Puoi taggare un catalog con dominio=sales e tutte le tabelle al suo interno prendono quella classificazione senza fare altro.

Attenzione: i dati di tag sono memorizzati in chiaro e possono essere replicati globalmente. Non usare nei nomi o nei valori dei tag informazioni sensibili o personali.

Tag Policy: le regole che mancavano alla governance

La Tag Policy è il meccanismo che rende i Governed Tags diversi da semplici convenzioni di naming che tutti ignorano dopo due settimane.

Ogni Governed Tag ha una policy associata su tre livelli. Gli Allowed Values fanno sì che solo i valori nella lista possano essere assegnati a quella chiave: se provi ad applicare pii=cellphone e cellphone non è nella policy, l’operazione viene bloccata. I Permessi ASSIGN ti permettono di designare quali utenti o gruppi possono assegnare quel tag: il data steward del dominio Finance gestisce cost_center=finance. L’Enforcement account-wide applica i Tag su tutti i workspace collegati al metastore, indipendentemente da dove lavora il data engineer.

Questo trasforma il tagging da un’attività informale a un processo strutturato, auditabile e verificabile.

System Governed Tags

Databricks introduce anche i System Governed Tags: tag predefiniti dalla piattaforma, identificati con un’icona chiave inglese nell’UI, che non possono essere modificati o cancellati. Supportano scenari standard come classificazione dati, gestione del ciclo di vita e certificazione degli asset.

Due di questi sono particolarmente utili nella pratica: i tag per marcare oggetti come certified (dati validati e affidabili) o deprecated (dati obsoleti che i team non dovrebbero più usare). Con i System Tags puoi costruire un workflow di data lifecycle management senza dover reinventare nulla.

ABAC: quando i tag diventano access control dinamico

I Governed Tags da soli sono già utili. Ma il vero salto di qualità arriva quando li combini con le ABAC Policy (Attribute-Based Access Control).

Invece di definire permessi espliciti su ogni singola tabella per ogni utente o gruppo, definisci policy centrali che si applicano dinamicamente in base ai tag degli oggetti. Il tag diventa l’attributo che guida l’accesso.

ABAC in Unity Catalog supporta due tipi di policy.

Row Filter Policy

Una Row Filter Policy filtra automaticamente le righe restituite da una query in base al gruppo di appartenenza dell’utente. Il caso d’uso classico in un’azienda multinazionale è la segmentazione per business unit: il team EMEA vede solo i propri clienti, il team APAC i propri, e il team global analytics ha visibilità completa. Nessuna vista per team, nessuna logica nei report, la policy si applica a qualsiasi query, da qualsiasi tool connesso al catalog.

La tabella ha una colonna business_unit con valori AMERICAS, APAC, EMEA — un campo di business esplicito e stabile. La UDF usa IS_ACCOUNT_GROUP_MEMBER(), la funzione raccomandata da Databricks per verificare l’appartenenza a gruppi account-level, compatibile anche con i gruppi Microsoft Entra ID sincronizzati via SCIM:

-- Row visibility by business unit group membership
CREATE OR REPLACE FUNCTION sc_demo.security.row_access_by_bu(business_unit STRING)
RETURNS BOOLEAN
RETURN (
  IS_ACCOUNT_GROUP_MEMBER('global_analysts')
  OR IS_ACCOUNT_GROUP_MEMBER('account_admins')
  OR (IS_ACCOUNT_GROUP_MEMBER('bu_emea')     AND business_unit = 'EMEA')
  OR (IS_ACCOUNT_GROUP_MEMBER('bu_apac')     AND business_unit = 'APAC')
  OR (IS_ACCOUNT_GROUP_MEMBER('bu_americas') AND business_unit = 'AMERICAS')
);

Ogni condizione combina il check di gruppo con il valore della colonna: un utente in bu_emea vede solo le righe EMEA, non le altre. Nessun utente senza gruppo vede alcuna riga (il default è deny).

Con la UDF pronta, crei la policy via SQL oppure dalla UI (Catalog Explorer, tab Policies sul catalog, poi New policy):

CREATE POLICY bu_row_access
ON CATALOG sc_demo
COMMENT 'Row-level security by business unit: each group sees only its own segment, global_analysts and admins see all'
ROW FILTER sc_demo.security.row_access_by_bu
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('data_access', 'restricted') AS bu_col
USING COLUMNS (bu_col);

MATCH COLUMNS individua automaticamente ogni colonna delle tabelle del catalogo sc_demo con il tag data_access = restricted e la passa come argomento alla UDF. Aggiungi una nuova tabella con una colonna business_unit taggata e la policy si applica senza toccare nulla di table-specific.

La policy appare nel tab Policies del catalog con scope, UDF collegata e principali coinvolti.

La stessa query restituisce risultati diversi in base al gruppo dell’utente:

-- bu_emea analyst runs this query...
SELECT *
FROM sc_demo.bronze.customer_profiles;

Column Mask Policy

Una Column Mask Policy sostituisce il valore di una colonna con un valore calcolato dalla UDF. La UDF riceve il valore originale e decide cosa restituire: il valore reale per chi ha il privilegio di vederlo, una maschera per tutti gli altri.

La UDF in sc_demo.security usa IS_ACCOUNT_GROUP_MEMBER() per decidere:

-- Returns the real SSN for pii_readers and account_admins, masked value for everyone else
CREATE OR REPLACE FUNCTION sc_demo.security.mask_ssn(ssn STRING)
RETURNS STRING
RETURN (
  CASE
    WHEN IS_ACCOUNT_GROUP_MEMBER('pii_readers')
      OR IS_ACCOUNT_GROUP_MEMBER('account_admins')
    THEN ssn
    ELSE '***-**-****'
  END
);

Il gruppo pii_readers è dedicato agli utenti che hanno bisogno di accedere ai dati PII reali, tipicamente il team di compliance, il Data Protection Officer o i sistemi di audit. Non è sufficiente essere global_analysts o avere accesso a tutte le righe: la visibilità dell’SSN richiede una concessione esplicita separata.

La policy collega la UDF a tutte le colonne del catalogo che portano il tag pii=ssn:

CREATE POLICY mask_ssn
ON CATALOG sc_demo
COMMENT 'Masks social security numbers: pii_readers and account_admins see real value, others see placeholder'
COLUMN MASK sc_demo.security.mask_ssn
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col;

ON COLUMN ssn_col specifica che la maschera si applica alla colonna taggata, non all’intera riga. Il risultato per la stessa query cambia in base ai gruppi dell’utente:

Con entrambe le policy attive, la visibilità dipende da due dimensioni indipendenti — le righe visibili dipendono dalla BU, il valore dell’SSN dipende dal gruppo PII:

SELECT *
FROM sc_demo.bronze.customer_profiles;

Il modello di ereditarietà delle policy

Una delle cose che ho apprezzato di più testando ABAC è l’ereditarietà gerarchica. Definisci una policy a livello di catalog e si applica a tutti gli schema e tutte le tabelle al suo interno che soddisfano le condizioni, comprese le tabelle create in futuro.

Su una piattaforma con diversi workspace e centinaia di tabelle per dominio, questo fa una differenza concreta.

• Prima: viste apposite per ogni team o applicazione delle funzioni per ogni tabella, aggiornate manualmente ogni volta che si aggiunge una tabella o cambia un requisito.
• Adesso: definisci la policy una volta, applichi il tag sulla colonna sensibile, e il sistema si occupa di tutto il resto.

Databricks consiglia di definire le policy al livello più alto possibile, di solito il catalog, per massimizzare la copertura e ridurre l’overhead amministrativo.

Prerequisiti tecnici

Per usare queste funzionalità devi verificare:

• Workspace Azure Databricks abilitato a Unity Catalog
• Account admin o workspace admin per creare i Governed Tags
• Permesso MANAGE sull’oggetto o ownership per creare policy
• Databricks Runtime 16.4 o superiore (oppure Serverless Compute) per le ABAC Policy (i runtime più vecchi non riescono ad accedere a tabelle protette da ABAC)
• Permesso CREATE sui governed tags a livello di account

Stato attuale: cosa funziona oggi

Essere onesti sullo stato di queste funzionalità è importante:

Tutto in Public Preview, quindi le API e l’interfaccia potrebbero cambiare. Databricks sconsiglia di usarle in carichi di lavoro mission-critical senza un piano di aggiornamento. La qualità della documentazione e la stabilità che ho osservato però mi fanno credere che la GA sia relativamente vicina.

Alcune limitazioni concrete da tenere a mente:

• Massimo 1.000 Governed Tags per account e 50 valori consentiti per tag
• ABAC non si applica direttamente alle viste (ma le policy sulle tabelle sottostanti vengono valutate comunque, con le permission del view owner)
• Time travel e clone su tabelle con ABAC richiedono di essere esclusi dalla policy
• information_schema.row_filters mostra solo i filtri applicati direttamente, non quelli derivati da policy ABAC
• Governed Tags non si applicano a compute resources, SQL warehouse e job, che usano un meccanismo separato

Perché vale la pena provarli adesso

Ho lavorato su piattaforme dati dove la governance era gestita con un documento Excel condiviso: ogni team aveva la sua convenzione per i tag, i permessi venivano gestiti caso per caso, e ogni nuovo requisito GDPR si traduceva in una riunione per stabilire chi doveva creare le viste giuste. Non un’esperienza edificante.

Il modello con Governed Tags e ABAC è concettualmente diverso: la governance diventa dichiarativa. Dichiari la regola una volta, la piattaforma la applica ovunque, in modo automatico e auditabile. Lato data engineering, sparisce il lavoro manuale di creare e mantenere i layer di sicurezza per ogni nuovo team o requisito. Lato compliance, hai un punto unico dove verificare che i dati sensibili siano classificati e protetti, con audit trail incluso in Unity Catalog.

La direzione che Databricks sta seguendo con Unity Catalog è quella giusta per una piattaforma enterprise matura. Questi sono i pezzi che mancavano.

Conclusioni

Se stai costruendo o evolvendo una piattaforma datalakehouse su Azure Databricks, inizia a sperimentare con Governed Tags e ABAC Policy. La curva di adozione è più bassa di quanto sembri: il tutorial ufficiale è completo e la UI è ragionevolmente intuitiva. Il valore arriva in fretta, già dalle prime policy configurate.

Sono in Public Preview, quindi qualcosa cambierà. Ma la direzione è chiara e la velocità di evoluzione del team Databricks fa pensare che la GA non sia lontana.

Risorse

• Governed tags — Azure Databricks | Microsoft Learn
• Tutorial: Configure ABAC — Azure Databricks | Microsoft Learn
• Unity Catalog ABAC overview — Azure Databricks | Microsoft Learn

Nota sui dati di esempio: i dati utilizzati negli esempi di codice (nomi, indirizzi, numeri di telefono, codici fiscali e identificativi cliente) sono dati sintetici generati a puro scopo dimostrativo. Qualsiasi somiglianza con persone reali è puramente casuale. Non rappresentano dati reali di clienti o aziende.