A cosa serve il Dynamic Data Masking nel Warehouse

Il Dynamic Data Masking (DDM) del Fabric Data Warehouse offusca “al volo” i dati sensibili nei risultati di una query, senza modificare i valori memorizzati fisicamente. La maschera viene definita a livello di colonna con la clausola MASKED WITH e si applica in fase di lettura: gli utenti privi del permesso di sblocco vedono valori camuffati (es. XXXX), mentre chi è autorizzato vede il dato in chiaro. È un controllo pensato per limitare l’esposizione accidentale (operatori di help desk, sviluppatori, report ad hoc), non per soddisfare requisiti crittografici.

La regola di masking si dichiara in DDL, in creazione o in ALTER:

ALTER TABLE dbo.Customers
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

I quattro tipi di maschera

  • default() — offuscamento completo coerente col tipo di dato: stringhe → XXXX, numerici → 0, date → 1900-01-01. È la scelta quando non serve mostrare nulla del valore.
  • email() — espone solo la prima lettera e il suffisso: aXXX@XXXX.com. Utile per riconoscere che un contatto esiste senza rivelarlo.
  • partial(prefix, padding, suffix) — la più flessibile: mantiene un numero definito di caratteri iniziali e finali sostituendo il resto con un padding custom. Tipico per codici fiscali o carte, es. mostrare solo le ultime 4 cifre.
  • random(start, end) — per colonne numeriche, restituisce un valore casuale nell’intervallo indicato. Adatto a dataset di test/analitici dove serve un ordine di grandezza plausibile ma non il dato reale.

Il permesso UNMASK

Il DDM è disattivato per chi possiede il permesso UNMASK. Nel Fabric Warehouse UNMASK è granulare: può essere concesso a livello di database, schema, tabella o singola colonna, così si allarga la visione in chiaro solo dove serve.

GRANT UNMASK ON dbo.Customers(Email) TO analyst_role;
-- oppure a livello database: GRANT UNMASK TO admin_role;

I membri di ruoli con privilegi amministrativi (es. proprietario del workspace/Admin) vedono sempre i dati smascherati. La gestione tramite ruoli anziché utenti singoli è la prassi raccomandata.

DDM non è cifratura: perché va combinato con CLS e RLS

Il punto architetturale più importante per l’esame: il DDM è un controllo di presentazione, non un controllo di accesso e non una cifratura. Il valore reale resta in chiaro nello storage e transita nel motore di query; viene mascherato solo nell’output. Chiunque possa eseguire query arbitrarie sulla colonna può quindi inferire il dato pur senza avere UNMASK, ad esempio filtrando su valori candidati:

-- La maschera non impedisce il filtro sul valore reale
SELECT COUNT(*) FROM Customers WHERE Salary > 90000;

Ripetendo predicati di uguaglianza o disuguaglianza (attacco inferenziale/brute force) l’utente ricostruisce i valori. Per questo il DDM va inserito in una strategia a livelli:

  • Column-Level Security (CLS) — con GRANT/DENY sui permessi SELECT di specifiche colonne si nega del tutto l’accesso alla colonna sensibile a chi non deve leggerla. Se non può interrogarla, non può inferirla.
  • Row-Level Security (RLS) — tramite una security policy con PREDICATE (funzione inline table-valued) si filtrano le righe visibili in base all’identità (USER_NAME(), SESSION_CONTEXT), così ogni utente vede solo il proprio sottoinsieme.
  • Per la protezione a riposo restano attive la cifratura di piattaforma e la governance di Microsoft Purview (classificazione, sensitivity label, Information Protection).

La combinazione tipica: CLS/DENY per chi non deve proprio vedere la colonna, DDM per chi la può interrogare ma dovrebbe vederla offuscata, RLS per limitare le righe, il tutto etichettato e monitorato in Purview.

Trappole tipiche d’esame

  • Scenario: un ruolo può eseguire query libere sulla tabella e devi impedirgli di dedurre gli stipendi mascherati → DDM da solo non basta: aggiungi CLS (DENY SELECT sulla colonna) o RLS, perché la maschera non blocca i predicati WHERE.
  • Scenario: vuoi mostrare le ultime 4 cifre di una carta e nascondere il resto → usa partial(), non default() (che offusca tutto) né random() (solo numerici casuali).
  • Scenario: un analista deve vedere in chiaro solo la colonna Email di una tabella → GRANT UNMASK ON <tabella>(Email) (granularità di colonna), non UNMASK a livello database.
  • Scenario: ti chiedono di “proteggere i dati a riposo” per compliance → il DDM non è cifratura; indica cifratura/Purview, non il masking.
  • Scenario: l’admin del workspace “non vede” la maschera → è atteso: i ruoli con privilegi elevati bypassano sempre il DDM.