La sicurezza in Microsoft Fabric si applica su due livelli sovrapposti: il workspace role, che concede un set fisso di permessi su tutti gli item del workspace, e le item permissions, che si concedono al singolo elemento (lakehouse, warehouse, semantic model, report) tramite condivisione. Il principio operativo del DP-600 è sempre lo stesso: il ruolo di workspace è lo strumento grosso, l’item permission è il bisturi. Se un requisito parla di “un solo item” o “una sola tabella”, la risposta quasi mai è aggiungere l’utente al workspace.
I quattro ruoli di workspace
| Capacità | Admin | Member | Contributor | Viewer |
|---|---|---|---|---|
| Eliminare/rinominare il workspace, gestire la capacity | Sì | No | No | No |
| Aggiungere/rimuovere utenti, inclusi altri Admin | Sì | No | No | No |
| Aggiungere utenti con ruolo pari o inferiore (Member, Contributor, Viewer) | Sì | Sì | No | No |
| Condividere item e concedere item permissions (Reshare) | Sì | Sì | No | No |
| Pubblicare, aggiornare o rimuovere un’app | Sì | Sì | No | No |
| Creare, modificare, eliminare item (notebook, pipeline, lakehouse, report) | Sì | Sì | Sì | No |
| Scrivere dati, eseguire pipeline, pianificare refresh | Sì | Sì | Sì | No |
| Visualizzare report e dashboard | Sì | Sì | Sì | Sì |
| Accesso Spark/OneLake ai file del lakehouse (ReadAll) | Sì | Sì | Sì | No |
I ruoli si assegnano a gruppi di sicurezza Entra ID, non a singoli utenti: è l’unica strategia che regge in produzione e la risposta corretta in ogni scenario di governance.
Le item permissions
Condividendo un item si concedono permessi granulari, indipendenti dal workspace role:
- Read — vede l’item nell’elenco e si connette; da solo non legge alcun dato.
- ReadData — esegue query T-SQL sul SQL analytics endpoint o sul warehouse.
- ReadAll — legge i file/le tabelle Delta direttamente da OneLake (Spark, notebook, shortcut).
- Build — costruisce nuovo contenuto sopra un semantic model (report, Analyze in Excel, composite model).
- Write / Reshare — modifica l’item; ricondivide con altri.
Il ruolo Viewer mappa su Read + ReadData sul SQL analytics endpoint, ma non su ReadAll: un Viewer può interrogare le tabelle in T-SQL e fallisce su Spark, OneLake Explorer e API OneLake. Il Contributor ottiene tutto tranne Reshare.
Scenari risolti
“Un data engineer deve aggiornare le pipeline ma non pubblicare report.” Contributor concede entrambe le cose: creare pipeline e pubblicare report sono lo stesso permesso Write. La soluzione corretta è separare i workspace — un workspace di ingestion dove è Contributor, un workspace di reporting dove è Viewer. Il workspace, non il ruolo, è il confine di sicurezza.
“Un analista deve leggere una sola tabella del lakehouse.” Niente workspace role. Si crea una vista nel SQL analytics endpoint e si concede GRANT SELECT all’utente, oppure si usa un OneLake data access role che limita l’accesso a una cartella; poi si condivide l’item con Read senza spuntare ReadData/ReadAll. In alternativa, per il warehouse, RLS/OLS via T-SQL.
“Un utente esterno al team deve consumare un report.” Item permission + condivisione, o pubblicazione di un’app con audience mirata — mai aggiunta al workspace.
Trappole tipiche d’esame
- Scenario: un Viewer apre un notebook Spark sul lakehouse e riceve un errore di permessi → Risposta: il ruolo Viewer non include ReadAll; serve condividere il lakehouse concedendo esplicitamente ReadAll, o promuovere a Contributor se deve anche scrivere.
- Scenario: l’utente riceve la condivisione di un lakehouse ma ogni query T-SQL fallisce → Risposta: è stato concesso solo Read; va spuntato “Read all SQL analytics endpoint data” (ReadData) in fase di sharing.
- Scenario: un Contributor deve dare accesso a un collega a un semantic model → Risposta: non può, gli manca Reshare; l’operazione richiede Member o Admin, oppure il grant esplicito di Reshare sull’item.
- Scenario: serve che un analista crei report su un semantic model certificato senza vedere gli altri item del workspace → Risposta: permesso Build sul solo semantic model, nessun ruolo di workspace.
- Scenario: un Member deve promuovere un collega ad Admin → Risposta: impossibile; solo un Admin può assegnare il ruolo Admin (Member aggiunge solo ruoli pari o inferiori).
- Scenario: un Viewer “vede” un report che espone dati che non dovrebbe leggere → Risposta: il ruolo di workspace non filtra le righe; serve RLS sul semantic model o sul warehouse.