Nel mondo Fabric l’autorizzazione non è un singolo interruttore: è una catena che parte dal workspace, attraversa l’item, scende fino ai file in OneLake e risale fino al report. Se anche un solo anello manca, l’utente vede una pagina vuota o — peggio — dati che non dovrebbe vedere.
La catena di autorizzazione, anello per anello
1. Workspace role
È il livello più grossolano e sovrascrive tutto ciò che sta sotto.
| Ruolo | Cosa può fare |
|---|---|
| Admin | Tutto, incluso gestire accessi ed eliminare il workspace |
| Member | Come Contributor + condividere item e aggiungere altri membri |
| Contributor | Creare/modificare item, scrivere dati nel lakehouse |
| Viewer | Vedere report e dashboard, interrogare il SQL analytics endpoint; nessun accesso ai file OneLake |
Regola pratica per il least privilege: il ruolo Viewer è il default per i consumatori, e i permessi granulari si concedono per item, non promuovendo l’utente a Contributor.
2. Item permission sul lakehouse
Sul singolo lakehouse esistono tre livelli cumulativi:
- Read — permette solo di “vedere” l’item e connettersi all’endpoint, senza leggere dati.
- ReadData — legge le tabelle attraverso il SQL analytics endpoint, soggetto a SQL RLS/CLS e dynamic data masking.
- ReadAll — legge i file direttamente in OneLake (Spark, notebook, OneLake file explorer, shortcut). Bypassa completamente le regole SQL.
Le OneLake data access roles consentono di restringere ReadAll a cartelle specifiche (es. solo Tables/sales), riportando il principio del privilegio minimo anche sul layer file.
3. Semantic model
Sopra il lakehouse il modello ha permessi propri: Read, Build, Reshare, Write. Build è quello che abilita creare report nuovi, usare Analyze in Excel, interrogare via XMLA/executeQueries. La RLS dinamica in DAX vive qui e vale solo per chi passa dal modello.
4. Report e condivisione
Condividere un report concede implicitamente Read sul semantic model. La casella “Allow recipients to build content with the data” aggiunge Build: senza di essa l’utente vede il report esistente ma non può creare visual propri. Per i modelli in Direct Lake, l’accesso ai dati usa le credenziali del modello (fixed identity o SSO): con SSO l’utente finale deve avere ReadData sul lakehouse sottostante.
Diagnosi degli scenari classici
- “Vedo il report ma i visual danno errore” → manca Read sul semantic model, oppure il modello è in Direct Lake con SSO e l’utente non ha ReadData sul lakehouse. Soluzione minima: concedere Read sul modello (o ReadData sul lakehouse), non aggiungere l’utente al workspace.
- “Vedo il report ma le righe sono zero” → la RLS del modello sta filtrando: l’utente non appartiene a nessun ruolo, o il ruolo restituisce un set vuoto.
- “L’utente interroga il warehouse e vede tutte le righe” → la RLS DAX del semantic model non si applica al SQL analytics endpoint. Serve RLS T-SQL (
CREATE SECURITY POLICY) più eventuale CLS/masking definita sull’endpoint. - “Il data engineer vede tutto nonostante RLS” → ha
ReadAllo è Contributor: legge i Delta file direttamente in OneLake, dove nessuna policy SQL è valutata.
Endorsement e sensitivity label
L’endorsement è governance di fiducia, non di accesso: Promoted può applicarlo chi ha permessi di scrittura sull’item; Certified solo utenti autorizzati da un tenant admin nel portale di amministrazione. Un item certificato sale nei risultati di ricerca e in OneLake catalog, ma non cambia di una virgola chi può leggerlo.
Le sensitivity label di Microsoft Purview Information Protection si applicano agli item Fabric e si propagano downstream (lakehouse → semantic model → report) tramite l’ereditarietà; viaggiano anche negli export in Excel, PowerPoint e PDF, dove la crittografia continua a proteggere il file fuori dal tenant. Anche qui: la label non nega l’accesso in Fabric, applica protezione e controlli DLP.
Microsoft Purview completa il quadro a livello tenant con il Purview hub in Fabric, il catalogo e la data lineage, le policy DLP per Fabric (rilevano dati sensibili nei semantic model e nei lakehouse), l’audit unificato delle attività e le insight su etichettatura ed endorsement.
Trappole tipiche d’esame
- Un analista deve costruire report nuovi da un modello condiviso, senza accedere al workspace → concedere Build sul semantic model, non aggiungerlo come Contributor.
- Un utente Viewer deve leggere i file Parquet del lakehouse via notebook Spark → serve ReadAll (idealmente ristretto con una OneLake data access role): ReadData copre solo il SQL analytics endpoint.
- La RLS definita nel semantic model deve valere anche per chi usa SSMS sull’endpoint → implementare RLS T-SQL sul SQL analytics endpoint; la RLS DAX non viene ereditata.
- Servono garanzie che il modello sia “ufficiale” per l’organizzazione → Certified endorsement, applicabile solo da utenti autorizzati dal tenant admin; non sostituisce i permessi.
- Un export Excel di dati riservati deve restare protetto fuori dal tenant → sensitivity label ereditata con crittografia, non l’endorsement né i permessi del workspace.