Modello di autorizzazione
Microsoft Fabric offre un modello di autorizzazione flessibile che consente di controllare l'accesso ai dati nell'organizzazione. Questo articolo illustra i diversi tipi di autorizzazioni in Fabric e come interagiscono per controllare l'accesso ai dati nell'organizzazione.
Un'area di lavoro è un'entità logica per il raggruppamento di elementi in Fabric. I ruoli dell'area di lavoro definiscono le autorizzazioni di accesso per le aree di lavoro. Anche se gli elementi vengono archiviati in un'area di lavoro, possono essere condivisi con altri utenti in Fabric. Quando si condividono gli elementi di Fabric, è possibile decidere quali autorizzazioni concedere all'utente con cui si condivide l'elemento. Alcuni elementi, ad esempio i report di Power BI, consentono un controllo ancora più granulare dei dati. I report possono essere configurati in modo che, a seconda delle autorizzazioni, gli utenti che li visualizzano visualizzino solo una parte dei dati che contengono.
Ruoli dell'area di lavoro
I ruoli dell'area di lavoro vengono usati per controllare l'accesso alle aree di lavoro e al contenuto all'interno di esse. Un amministratore di Fabric può assegnare ruoli dell'area di lavoro a singoli utenti o gruppi. I ruoli dell'area di lavoro sono limitati a un'area di lavoro specifica e non si applicano ad altre aree di lavoro, alla capacità in cui si trova l'area di lavoro o al tenant.
Esistono quattro ruoli dell'area di lavoro e si applicano a tutti gli elementi all'interno dell'area di lavoro. Gli utenti che non dispongono di questi ruoli non possono accedere all'area di lavoro. I ruoli sono:
Visualizzatore: può visualizzare tutto il contenuto nell'area di lavoro, ma non modificarlo.
Collaboratore: può visualizzare e modificare tutto il contenuto nell'area di lavoro.
Membro: può visualizzare, modificare e condividere tutto il contenuto nell'area di lavoro.
Amministratore: può visualizzare, modificare, condividere e gestire tutto il contenuto nell'area di lavoro, inclusa la gestione delle autorizzazioni.
Questa tabella mostra un piccolo insieme di funzionalità di ogni ruolo. Per un elenco completo e più dettagliato, vedere Ruoli nell'area di lavoro di Microsoft Fabric.
| Funzionalità | Amministrativi | Membro | Contributore | Visualizzatore |
|---|---|---|---|---|
| Eliminare l'area di lavoro. | ✅ | ❌ | ❌ | ❌ |
| Add admins | ✅ | ❌ | ❌ | ❌ |
| Aggiungere membri | ✅ | ✅ | ❌ | ❌ |
| Scrivere dati | ✅ | ✅ | ✅ | ❌ |
| Creare elementi | ✅ | ✅ | ✅ | ❌ |
| Leggere i dati | ✅ | ✅ | ✅ | ✅ |
Autorizzazioni per gli elementi
Le autorizzazioni degli elementi vengono usate per controllare l'accesso a singoli elementi di Fabric all'interno di un'area di lavoro. Le autorizzazioni degli elementi sono limitate a un elemento specifico e non si applicano ad altri elementi. Usare le autorizzazioni degli elementi per controllare chi può visualizzare, modificare e gestire singoli elementi in un'area di lavoro. È possibile usare le autorizzazioni degli elementi per concedere a un utente l'accesso a un singolo elemento in un'area di lavoro a cui non ha accesso.
Quando si condivide l'elemento con un utente o un gruppo, è possibile configurare le autorizzazioni per gli elementi. La condivisione di un elemento concede all'utente, per impostazione predefinita, l'autorizzazione di lettura per tale elemento. Le autorizzazioni di lettura consentono agli utenti di visualizzare i metadati per tale elemento e di visualizzare i report associati. Tuttavia, le autorizzazioni di lettura non consentono agli utenti di accedere ai dati sottostanti in SQL o OneLake.
Diversi elementi di Fabric dispongono di autorizzazioni diverse. Per altre informazioni sulle autorizzazioni per ogni elemento, vedere:
Autorizzazioni di calcolo
Le autorizzazioni possono essere impostate anche all'interno di un motore di calcolo specifico in Fabric, in particolare tramite l'endpoint di analisi SQL o in un modello semantico. Le autorizzazioni del motore di calcolo consentono un controllo di accesso ai dati più granulare, ad esempio la sicurezza a livello di tabella e di riga.
Endpoint di analisi SQL: l'endpoint di analisi SQL fornisce l'accesso SQL diretto alle tabelle in OneLake e può avere la sicurezza configurata in modo nativo tramite i comandi SQL. Queste autorizzazioni si applicano solo alle query eseguite tramite SQL.
Modello semantico: i modelli semantici consentono di definire la sicurezza tramite DAX. Le restrizioni definite tramite DAX si applicano agli utenti che eseguono query tramite il modello semantico o i report di Power BI basati sul modello semantico.
Puoi trovare informazioni più dettagliate nei seguenti articoli:
Autorizzazioni di OneLake (ruoli di accesso ai dati)
OneLake ha le proprie autorizzazioni per gestire l'accesso a file e cartelle in OneLake tramite i ruoli di accesso ai dati di OneLake. I ruoli di accesso ai dati di OneLake consentono agli utenti di creare ruoli personalizzati all'interno di una lakehouse e di concedere autorizzazioni di lettura solo alle cartelle specificate durante l'accesso a OneLake. Per ogni ruolo OneLake, gli utenti possono assegnare utenti, gruppi di sicurezza o concedere un'assegnazione automatica in base al ruolo dell'area di lavoro.
Altre informazioni sul Modello di controllo di accesso ai dati OneLake e visualizzare le guide pratiche.
Ordine dell'operazione
Fabric ha tre diversi livelli di sicurezza. Un utente deve avere accesso a ogni livello per accedere ai dati. Ogni livello valuta in sequenza per determinare se un utente abbia accesso. Le regole di sicurezza, come i criteri di Microsoft Information Protection, valutano a un determinato livello per consentire o impedire l'accesso. L'ordine di funzionamento durante la valutazione della sicurezza di Fabric è:
- Autenticazione Entra: verifica se l'utente è in grado di eseguire l'autenticazione nel tenant di Microsoft Entra.
- Accesso Fabric: controlla se l'utente può accedere a Microsoft Fabric.
- Sicurezza dei dati: controlla se l'utente può eseguire l'azione richiesta in una tabella o in un file.
Esempi
Questa sezione fornisce due esempi di come configurare le autorizzazioni in Fabric.
Esempio 1: Configurazione delle autorizzazioni del team
Wingtip Toys è configurato con un tenant per l'intera organizzazione e tre capacità. Ogni capacità rappresenta un'area diversa. Wingtip Toys opera in Stati Uniti, Europa e Asia. Ogni capacità ha un'area di lavoro per ogni reparto dell'organizzazione, incluso il reparto vendite.
Il reparto vendite ha un manager, un responsabile del team di vendita e membri del team di vendita. Wingtip Toys impiega anche un analista per l'intera organizzazione.
La tabella seguente illustra i requisiti per ogni ruolo nel reparto vendite e il modo in cui vengono configurate le autorizzazioni per abilitarle.
| Ruolo | Requisito | Attrezzaggio |
|---|---|---|
| Responsabile | Visualizzare e modificare tutto il contenuto nel reparto vendite dell'intera organizzazione | Ruolo membro per tutte le aree di lavoro di vendita nell'organizzazione |
| Responsabile del team | Visualizzare e modificare tutto il contenuto nel reparto vendite in un'area specifica | Ruolo membro per l'area di lavoro vendite nell'area |
| Membro del team di vendita | ||
| Analista | Visualizzare tutto il contenuto nel reparto vendite dell'intera organizzazione | Ruolo visualizzatore per tutte le aree di lavoro di vendita nell'organizzazione |
Wingtip ha anche un report trimestrale che elenca il reddito di vendita per ogni membro di vendita. Questo report viene archiviato in un'area di lavoro finance. Usando la sicurezza a livello di riga, il report viene configurato in modo che ogni membro di vendita possa visualizzare solo le proprie cifre di vendita. I responsabili del team possono visualizzare i dati sulle vendite di tutti i membri della vendita nella propria area geografica e il responsabile vendite può visualizzare i dati di vendita di tutti i membri della vendita nell'organizzazione.
Esempio 2: Autorizzazioni per aree di lavoro ed elementi
Quando si condivide un elemento o si modificano le relative autorizzazioni, i ruoli dell'area di lavoro non cambiano. Nell'esempio riportato in questa sezione viene illustrato come interagiscono le autorizzazioni per l'area di lavoro e gli elementi.
Veronica e Marta lavorano insieme. Veronica è il proprietario di un report che desidera condividere con Marta. Se Veronica condivide il report con Marta, Marta sarà in grado di accedervi indipendentemente dal ruolo dell'area di lavoro che ha.
Supponiamo che Marta abbia un ruolo visualizzatore nell'area di lavoro in cui è archiviato il report. Se Veronica decide di rimuovere le autorizzazioni per l'elemento di Marta dal report, Marta sarà comunque in grado di visualizzare il report nell'area di lavoro. Marta sarà anche in grado di aprire il report dall'area di lavoro e visualizzarne il contenuto. Ciò avviene perché Marta dispone delle autorizzazioni di visualizzazione per l'area di lavoro.
Se Veronica non vuole che Marta visualizzi il report, la rimozione delle autorizzazioni per l'elemento di Marta dal report non è sufficiente. Veronica deve anche rimuovere le autorizzazioni del visualizzatore di Marta dall'area di lavoro. Senza le autorizzazioni del visualizzatore dell'area di lavoro, Marta non sarà in grado di vedere che il report esiste perché non sarà in grado di accedere all'area di lavoro. Inoltre, Marta non sarà in grado di usare il collegamento al report, perché non ha accesso al report.
Ora che Marta non ha un ruolo visualizzatore dell'area di lavoro, se Veronica decide di condividere di nuovo il report con lei, Marta sarà in grado di visualizzarlo usando il collegamento Veronica ha condiviso con lei, senza avere accesso all'area di lavoro.
Esempio 3: autorizzazioni app Power BI
Quando si condividono i report di Power BI, spesso si desidera che i destinatari abbiano accesso solo ai report e non agli elementi nell'area di lavoro. A questo scopo, è possibile usare le app Power BI o condividere i report direttamente con gli utenti.
Inoltre, è possibile limitare l'accesso del visualizzatore ai dati usando la sicurezza a livello di riga con la sicurezza a livello di riga è possibile creare ruoli che hanno accesso a determinate parti dei dati e limitare i risultati restituendo solo ciò che l'identità dell'utente può accedere.
Questa operazione funziona correttamente quando si usano i modelli di importazione se i dati vengono importati nel modello semantico e i destinatari hanno accesso a questo nell'ambito dell'app. Con DirectLake, il report legge i dati direttamente da Lakehouse e il destinatario del report deve avere accesso a questi file nel lago. È possibile farlo in diversi modi:
- Concedere
ReadDatadirettamente l'autorizzazione a Lakehouse. - Cambiare le credenziali dell'origine dati da Single Sign On (SSO) a un'identità fissa che abbia accesso ai file nel lake.
Poiché la sicurezza a livello di riga è definita nel modello semantico, i dati verranno letti per primi e quindi le righe verranno filtrate.
Se viene definita una sicurezza nell'endpoint di analisi SQL su cui si basa il report, le query eseguono automaticamente il fallback alla modalità DirectQuery. Se non si desidera questo comportamento di fallback predefinito, è possibile creare una nuova Lakehouse usando collegamenti alle tabelle nella lakehouse originale e non definire la sicurezza a livello di riga o OLS in SQL nella nuova Lakehouse.