Tre controlli diversi per tre requisiti diversi

Un requisito di compliance non si traduce automaticamente in “metti la RLS”. In Microsoft Fabric hai tre leve distinte, e l’esame DP-600 verifica soprattutto che tu sappia quale scegliere data la frase del requisito.

Controllo Dove si definisce Effetto Requisito tipico
RLS (row-level security) Ruolo del semantic model (filtro DAX) oppure CREATE SECURITY POLICY in Warehouse L’utente vede meno righe; struttura invariata “Ogni regional manager vede solo la sua area”
OLS (object-level security) Ruolo del semantic model (metadata permission) Tabella o colonna inesistente per l’utente: non compare nel campo elenco, non è interrogabile “Il reparto Sales non deve sapere che esiste la colonna Salary”
CLS (column-level security) DENY SELECT ON tabella(colonna) in Warehouse La colonna esiste ma la query fallisce “Nessuna lettura del codice fiscale via SQL endpoint”
DDM (dynamic data masking) ALTER TABLE ... ALTER COLUMN ... ADD MASKED WITH in Warehouse La colonna si vede, i valori sono offuscati “Il supporto deve vedere le ultime 4 cifre della carta”

Regola operativa: se il requisito parla di righe → RLS; se parla di esistenza/segretezza dello schema → OLS; se parla di usabilità con valori parziali → DDM.

Definire OLS su un semantic model

L’OLS non si configura dall’interfaccia di Power BI Desktop: crei il ruolo lì (o in Fabric portal), poi imposti i permessi di metadata via Tabular Editor o script TMSL/TMDL sull’endpoint XMLA del workspace (richiede capacità Fabric/Premium e XMLA read-write abilitato).

"roles": [{
  "name": "Sales",
  "modelPermission": "read",
  "tablePermissions": [{
    "name": "Employee",
    "columnPermissions": [
      { "name": "Salary", "metadataPermission": "none" }
    ]
  }]
}]

Con metadataPermission: "none" sulla tabella nascondi l’oggetto intero; a livello di colonna nascondi il singolo campo. "defaultMember" non c’entra: l’OLS agisce sui metadati, non sui valori.

L’effetto collaterale che rompe i report

Qui sta il punto che l’esame ama. Una colonna nascosta da OLS non è “vuota”: non esiste. Di conseguenza:

  • Ogni visual che referenzia l’oggetto nascosto va in errore per l’utente del ruolo (tipicamente “non è possibile visualizzare i dati” / oggetto non trovato), non mostra semplicemente un valore in bianco.
  • Ogni misura DAX che referenzia la colonna diventa non valutabile e propaga l’errore, anche se la misura restituirebbe solo un aggregato apparentemente innocuo.
  • Colonne e tabelle calcolate, relazioni e gerarchie che dipendono dall’oggetto protetto diventano inaccessibili a cascata.

Mitigazione pratica: costruisci report separati (o una perspective dedicata) per i ruoli con OLS, oppure isola i campi sensibili in una tabella a parte così che il resto del modello resti navigabile. E ricorda che la sola hidden property di un campo non è sicurezza: nasconde nella lista campi, ma il campo resta interrogabile via XMLA/Analyze in Excel.

Dynamic data masking in Fabric Warehouse

DDM si applica al SQL analytics endpoint e al Warehouse:

ALTER TABLE dbo.Customer
  ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');
ALTER TABLE dbo.Customer
  ALTER COLUMN CardNumber ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)');

Funzioni disponibili:

  • default() — mask completo secondo il tipo (XXXX, 0, 1900-01-01).
  • email() — aXXX@XXXX.com, conserva solo la prima lettera.
  • partial(prefix, padding, suffix) — la più usata: espone N caratteri iniziali/finali.
  • random(start, end) — valore casuale nel range, solo tipi numerici.

DDM è un controllo di presentazione, non di autorizzazione. Chi ha UNMASK (grant a livello di colonna, tabella, schema o database) vede i valori reali; gli amministratori e i ruoli workspace Admin/Member lo bypassano; chi può leggere i file Delta sottostanti in OneLake aggira del tutto il motore SQL. Va sempre accoppiato a DENY SELECT sulle colonne davvero riservate e al principio del least privilege.

Trappole tipiche d’esame

  • “Gli analisti non devono nemmeno sapere che esiste la colonna Salary” → OLS sul semantic model (metadataPermission: none), non RLS e non DDM: DDM lascia la colonna visibile, RLS non tocca le colonne.
  • “Dopo aver applicato OLS gli utenti del ruolo vedono errori nei report” → comportamento atteso: le misure/visual che referenziano l’oggetto nascosto si rompono. La risposta corretta è report o perspective dedicate per ruolo, non rimuovere l’OLS.
  • “L’utente appartiene a due ruoli, uno con OLS sulla colonna e uno senza” → l’appartenenza ai ruoli è additiva: l’utente vede la colonna. Per proteggerla davvero, l’OLS deve essere presente in tutti i ruoli assegnati.
  • “Il supporto deve vedere le ultime 4 cifre dell’IBAN ma non l’intero valore” → partial() con DDM, più DENY UNMASK implicito (non concedere UNMASK); non CLS, che negherebbe l’intera colonna e romperebbe la query.
  • “La RLS/DDM definita nel Warehouse non viene applicata al semantic model in Direct Lake” → corretto: Direct Lake legge i file Delta da OneLake e non eredita la sicurezza T-SQL. Definisci RLS/OLS sul semantic model; se l’utente non ha permessi OneLake, la query può fare fallback a DirectQuery sul SQL endpoint, dove invece la sicurezza T-SQL si applica (con risultati diversi: sintomo classico da riconoscere).