I quattro ruoli di workspace in Microsoft Fabric

In Microsoft Fabric l’unità primaria di collaborazione e sicurezza è il workspace: un contenitore di item (lakehouse, warehouse, notebook, pipeline, semantic model, report) associato a una capacity. L’accesso a un workspace si concede assegnando uno dei quattro ruoli, ereditati dal modello di Power BI ma estesi a tutte le esperienze Fabric. I ruoli sono cumulativi: ognuno include tutto ciò che può fare quello inferiore e aggiunge nuove capacità.

  • Admin — controllo totale. Gestisce l’appartenenza al workspace (aggiunge/rimuove utenti e assegna ruoli, incluso altri Admin), rinomina o elimina il workspace, configura la connessione alla capacity, gestisce le git integration e i deployment pipeline. È l’unico ruolo che può cancellare il workspace stesso.
  • Member — può fare quasi tutto ciò che fa l’Admin sul contenuto, ma con un limite chiave sulla governance: può aggiungere altri utenti solo a ruoli pari o inferiori al proprio (Member, Contributor, Viewer), non può promuovere ad Admin né rimuovere Admin. Può condividere item e ripubblicare/aggiornare contenuti.
  • Contributor — è il ruolo “di lavoro” per chi costruisce soluzioni dati. Può creare, modificare ed eliminare item (scrivere codice nei notebook, eseguire pipeline, creare tabelle nel lakehouse/warehouse, pubblicare report). Non gestisce gli accessi e non tocca le impostazioni del workspace.
  • Viewer — accesso in sola lettura. Può visualizzare e interagire con item già pubblicati (aprire report, eseguire query di lettura su un warehouse/SQL analytics endpoint tramite RLS/OLS, leggere dati esposti), ma non può creare né modificare alcun item.

Chi fa cosa, in sintesi

Capacità Admin Member Contributor Viewer
Gestire accessi / ruoli Sì (tutti) Sì (≤ Member) No No
Creare / modificare item Sì Sì Sì No
Eliminare il workspace Sì No No No
Sola lettura sul contenuto Sì Sì Sì Sì

Controllo a livello di item (item-level sharing)

Oltre ai ruoli di workspace, Fabric permette la condivisione del singolo item: un lakehouse, un warehouse, un semantic model o un report possono essere condivisi direttamente con un utente che non ha alcun ruolo sul workspace. Questo è lo scenario tipico quando un consumer deve accedere a un solo dataset senza vedere l’intero workspace.

Punti architetturali da capire:

  • La condivisione item estende (non sostituisce) i permessi. Chi ha un ruolo di workspace conserva sempre quelle capacità; la share aggiunge accesso mirato a chi ne è sprovvisto.
  • Si possono concedere permessi granulari: ad esempio, su un lakehouse, ReadAll (leggere i dati via SQL endpoint/Spark), Build (costruire contenuti sul semantic model derivato) o solo l’accesso al report. Su un warehouse si distingue tra Read (connessione) e ReadData (query effettive sui dati).
  • La share non conferisce capacità di scrittura strutturale come farebbe un Contributor: è pensata per l’accesso in consumo, non per l’authoring.

Interazione tra ruoli ereditati e share

Il rischio governativo è l’over-sharing: un item condiviso apre un canale d’accesso parallelo ai ruoli di workspace. Un utente Viewer che riceve ReadAll su un lakehouse può leggere i dati grezzi anche se il team pensava di limitarlo alla vista curata. Le share vanno quindi inventariate e revisionate insieme ai ruoli, perché non compaiono nella semplice lista dei membri del workspace.

Trappole tipiche d’esame

  • Scenario: un analista deve costruire pipeline e notebook ma non deve gestire chi accede al workspace → risposta: Contributor, non Member (Member può gestire accessi ≤ propri; è più di quanto serve).
  • Scenario: un utente deve solo consultare report e leggere dati, senza modificare nulla → risposta: Viewer. Attenzione: Viewer non può creare item, quindi non va scelto se deve pubblicare anche un solo report.
  • Scenario: un consumer esterno al team deve accedere a un unico warehouse senza vedere gli altri item → risposta: item-level sharing con permesso ReadData, non aggiungerlo come Viewer dell’intero workspace.
  • Scenario: occorre delegare l’aggiunta di nuovi Admin e la connessione alla capacity → risposta: Admin; il Member non può promuovere ad Admin.
  • Trappola concettuale: una share su un lakehouse concede accesso in aggiunta ai ruoli; assegnare Viewer non “blocca” un permesso ReadAll già condiviso separatamente. I due meccanismi si sommano, non si sovrascrivono.