Pianificazione dell'implementazione di Power BI: Pianificare la sicurezza degli utenti di report

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sull'esperienza Power BI in Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo sulla pianificazione della sicurezza descrive le strategie per gli utenti di sola lettura. È focalizzato sulle autorizzazioni di visualizzatore per report e app e su come imporre la sicurezza dei dati. È destinato principalmente a:

• Amministratori Power BI: amministratori responsabili della supervisione di Power BI nell'organizzazione.
• Center of Excellence, team IT e BI: altri team responsabili della supervisione di Power BI. Potrebbe essere necessario collaborare con gli amministratori di Power BI, i team di sicurezza delle informazioni e altri team pertinenti.
• Autori e proprietari di contenuti: creatori di business intelligence self-service che devono creare, pubblicare, proteggere e gestire contenuti usati da altri utenti.

La serie di articoli è destinata ad ampliare il contenuto del white paper sulla sicurezza di Power BI. Anche se il white paper sulla sicurezza di Power BI è incentrato su argomenti tecnici chiave come l'autenticazione, la residenza dei dati e l'isolamento della rete, l'obiettivo principale della serie è fornire considerazioni e decisioni utili per pianificare la sicurezza e la privacy.

In un'organizzazione molti utenti vengono classificati come consumer. Gli utenti visualizzano contenuto creato e pubblicato da altri utenti. Questi articolo è incentrato sugli utenti. Per la pianificazione della sicurezza incentrata sugli autori e sui proprietari di contenuto, vedere l'articolo Pianificazione della sicurezza per gli autori di contenuto.

Per approcciare al meglio questo articolo, è utile comprendere il significato dei termini condivisione e distribuzione nel contesto di Power BI.

La condivisione è la posizione in cui un utente concede a un altro utente (o gruppo di utenti) l'accesso a un elemento specifico del contenuto. L'ambito della funzionalità di condivisione nel servizio Power BI è di un elemento. Generalmente, si svolge tra individui che si conoscono e lavorano a stretto contatto.

La distribuzione consiste nel distribuire contenuto ad altri utenti, noti come destinatari. Spesso coinvolge un numero maggiore di utenti in più team. I destinatari potrebbero non aver richiesto il contenuto in modo esplicito, ma potrebbe essere stato riconosciuto che ne necessitano per svolgere il proprio ruolo. I destinatari che utilizzano contenuto distribuito possono o meno conoscere l'autore originale del contenuto. Di conseguenza, il concetto di distribuzione è più formale della condivisione.

Quando si parla con altre persone, determinare se usano il termine condivisione in modo generale o letteralmente. L'uso del termine condivisione può essere interpretato in due modi.

• Il termine condivisione viene spesso usato in modo generale, riferendosi alla condivisione del contenuto con colleghi. Esistono diverse tecniche per la distribuzione di contenuto di sola lettura, descritte in questo articolo.
• La condivisione è anche una funzionalità specifica in Power BI. Si tratta di una funzionalità in cui a un utente o a un gruppo viene concesso l'accesso a un singolo elemento. La condivisione tramite collegamenti e quella ad accesso diretto sono descritte in questo articolo.

Importante

Il ruolo dell’amministratore di Power BI è stato rinominato. Il nuovo nome del ruolo è Amministratore di Fabric.

Strategia per gli utenti di sola lettura

Nel servizio Power BI, gli utenti possono visualizzare un report o un dashboard quando dispongono dell'autorizzazione per entrambi:

• Visualizzare l'elemento di Power BI che contiene le visualizzazioni (ad esempio un report o un dashboard).
• Leggere i dati sottostanti (modello semantico o altra origine).

È possibile fornire l'accesso in sola lettura agli utenti usando tecniche diverse. Le tecniche comuni usate dagli autori di contenuto self-service includono:

• Concedere l’accesso a utenti e gruppi a un'app Power BI.
• Aggiungere utenti e gruppi a un ruolo Visualizzatore di area di lavoro di Power BI.
• Fornire autorizzazioni per utenti e gruppi per singolo elemento tramite un collegamento di condivisione.
• Fornire autorizzazioni per utenti e gruppi per singolo elemento tramite accesso diretto.

Le opzioni del ruolo Visualizzatore dell’area di lavoro di Power BI e dell'app Power BI comportano la gestione delle autorizzazioni per un set di elementi. Le due tecniche di autorizzazioni per singolo elemento comportano la gestione delle autorizzazioni per un singolo elemento.

Suggerimento

In genere, è consigliabile usare un'app Power BI per la maggior parte degli utenti. In alcuni casi, anche il ruolo Visualizzatore dell'area di lavoro potrebbe essere appropriato. Sia le app di Power BI che il ruolo Visualizzatore dell'area di lavoro consentono di gestire le autorizzazioni per molti elementi e devono essere usate quando possibile. La gestione delle autorizzazioni per singoli elementi può essere tediosa, dispendiosa in termini di tempo e propensa a errori. Al contrario, la gestione di un set di elementi riduce la manutenzione e migliora l'accuratezza.

Quando si esaminano le impostazioni di sicurezza per un elemento, è possibile che le sue autorizzazioni siano:

• Ereditate dall'area di lavoro o da un'app.
• Applicate direttamente all'elemento.

Nello screenshot seguente vengono mostrate le autorizzazioni di accesso diretto per un report. In questo caso, i ruoli amministratore e membro dell'area di lavoro vengono assegnati a un gruppo. Questi ruoli vengono mostrati per il report perché l'accesso a livello di report è ereditato dall'area di lavoro. Esiste anche un utente che dispone delle autorizzazioni di lettura applicate direttamente al report.

La strategia scelta per gli utenti di sola lettura può essere diversa. Deve basarsi sulla singola soluzione, sulle preferenze di chi la gestisce o sulle esigenze dell’utente. Nella parte restante di questa sezione viene descritto quando valutare l'uso di ognuna delle tecniche disponibili.

Elenco di controllo: quando si crea la strategia per fornire contenuto agli utenti di sola lettura, le decisioni e azioni chiave includono:

• Valutare la strategia esistente per gli utenti di sola lettura: verificare il modo in cui il contenuto è attualmente distribuito e condiviso agli utenti. Identificare se siano presenti opportunità di miglioramento.
• Decidere la strategia per gli utenti di sola lettura: valutare le proprie preferenze per l'uso di autorizzazioni dell'app, dei ruoli dell'area di lavoro o delle autorizzazioni per singolo elemento. Se sono necessarie modifiche per soddisfare queste preferenze, creare un piano per apportare miglioramenti.

Autorizzazioni app di Power BI

Un'app Power BI offre agli utenti una raccolta di report, dashboard e cartelle di lavoro. Un'app offre la migliore esperienza utente perché:

• Il riquadro di spostamento dell'app offre un'esperienza utente semplice e intuitiva. Si tratta di un'esperienza più piacevole rispetto all'accesso al contenuto direttamente in un'area di lavoro.
• Il contenuto può essere organizzato logicamente in sezioni (come cartelle) nel riquadro di spostamento dell'app.
• Gli uteni hanno accesso solo a elementi specifici inclusi esplicitamente nell'app per i relativi destinatari.
• I collegamenti a informazioni aggiuntive, documentazione o altro contenuto possono essere aggiunti al riquadro di spostamento per i destinatari.
• È disponibile un flusso di lavoro Richiedi accesso integrato.

Nota

Tutti i riferimenti a un'app in questo articolo fanno riferimento a un'app Power BI. Si tratta di un concetto diverso da Power Apps. Si tratta anche di un concetto diverso rispetto alle applicazioni Power BI per dispositivi mobili. Questa sezione è focalizzata sulle app aziendali anziché le app modello.

È possibile creare un'app per ogni area di lavoro come metodo formale per distribuire alcuni o tutti i contenuti dell'area di lavoro. Le app sono un buon metodo per distribuire contenuto su larga scala all'interno di un'organizzazione, in particolare per gli utenti che non si conoscono o non collaborano a stretto contatto.

Suggerimento

Per altre informazioni sull'uso di un'app Power BI per la distribuzione di contenuto su larga scala, vedere lo scenario di utilizzo di business intelligence aziendale. È consigliabile per gli autori di contenuto che devono distribuire contenuto considerare la creazione di un'app come prima scelta.

Le autorizzazioni dell'app sono gestite separatamente dai ruoli dell'area di lavoro. La separazione delle autorizzazioni presenta due vantaggi. Incoraggia:

• A concedere l'accesso all'area di lavoro ai creatori di contenuti. Include utenti che collaborano attivamente al contenuto, ad esempio creatori di modelli semantici, creatori di report e tester.
• A concedere autorizzazioni dell'app agli utenti. A differenza delle autorizzazioni dell'area di lavoro, le autorizzazioni dell'app sono sempre di sola lettura (o nessuna).

Tutti gli utenti con accesso all'area di lavoro possono visualizzare automaticamente l'app (quando un'app Power BI è stata pubblicata per l'area di lavoro). A causa di questo comportamento, i ruoli dell'area di lavoro possono essere considerati concettualmente come ereditati da ogni gruppo di destinatari dell'app. Alcuni utenti con accesso all'area di lavoro possono anche aggiornare l'app Power BI, a seconda del ruolo dell'area di lavoro assegnato.

Suggerimento

Per altre informazioni sull’accesso dell'area di lavoro, vedere l’articolo Pianificazione della sicurezza per gli autori di contenuti.

L'uso di un'app per distribuire contenuto agli utenti di sola lettura è la scelta migliore quando:

• Si vuole che gli utenti possano visualizzare solo elementi specifici visibili per quel gruppo di destinatari (anziché tutti gli elementi all'interno dell'area di lavoro sottostante).
• Si vogliono gestire le autorizzazioni di sola lettura per l'app separatamente dall'area di lavoro.
• Si desidera una gestione delle autorizzazioni più semplice per gli utenti di sola lettura rispetto alle autorizzazioni per singolo elemento.
• Ci si vuole assicurare che la sicurezza a livello di riga venga applicata per gli utenti (quando dispongono dell'autorizzazione di sola lettura per il modello semantico sottostante).
• Ci si vuole assicurare che gli utenti non possano visualizzare report nuovi e modificati fino a quando l'app non viene ripubblicata.

Anche se è vero che le modifiche ai report e ai dashboard non sono visibili agli utenti dell'app finché l'app non viene ripubblicata, ci sono due considerazioni che richiedono cautela.

• Modifiche immediate del modello semantico: le modifiche del modello semantico diventano sempre effettive immediatamente. Ad esempio, se si introducono modifiche di rilievo a un modello semantico nell'area di lavoro, questo potrebbe inavvertitamente comportare l'instabilità dei report (anche se non sono stati ripubblicati nell'app). Esistono due modi per ridurre questo rischio: prima di tutto, eseguire tutte le operazioni di sviluppo in Power BI Desktop (separate dall'area di lavoro). In secondo luogo, isolare l'app di produzione usando aree di lavoro diverse per lo sviluppo e il test. (Facoltativamente, è possibile ottenere un livello di controllo superiore sulla distribuzione di contenuto dell'area di lavoro dallo sviluppo al test e alla produzione usando pipeline di distribuzione).
• Il contenuto e le autorizzazioni sono pubblicati insieme: quando si pubblica un'app, le relative autorizzazioni vengono pubblicate contemporaneamente al contenuto. Ad esempio, potrebbero essere presenti modifiche al report in un'area di lavoro che non sono ancora state completate, completamente testate o approvate. Non è quindi possibile semplicemente ripubblicare l'app per aggiornare le autorizzazioni. Per ridurre questo rischio, assegnare le autorizzazioni dell'app a gruppi di sicurezza e usare le appartenenze a gruppi di sicurezza (invece di singoli utenti) quando si concedono le autorizzazioni dell'app. Evitare di ripubblicare un'app solo per applicare le modifiche alle autorizzazioni.

Destinatari dell'app

Ogni area di lavoro nel servizio Power BI può avere una sola app Power BI. Tuttavia, all'interno dell'app è possibile creare uno o più gruppi di destinatari. Si consideri il seguente scenario.

• Ci sono cinque report di vendita distribuiti a molti utenti nell'intera organizzazione di vendita globale.
• Un gruppo di destinatari è definito nell'app per i rappresentanti di vendita. Questo gruppo di destinatari può visualizzare tre dei cinque report.
• Un altro gruppo di destinatari è definito nell'app per il team responsabile delle vendite. Questo gruppo di destinatari può visualizzare tutti e cinque i report, inclusi i due report non disponibili per i rappresentanti delle vendite.

La capacità di mischiare e abbinare contenuti e gruppi di destinatari presenta i vantaggi seguenti.

• Alcuni report possono essere disponibili per la visualizzazione da parte di più gruppi di destinatari. La creazione di più gruppi di destinatari elimina quindi la necessità di duplicare il contenuto in aree di lavoro diverse.
• Alcuni report dovrebbero essere disponibili per un solo gruppo di destinatari. Il contenuto per quel gruppo di destinatari può quindi trovarsi nella stessa area di lavoro di altri contenuti correlati.

Lo screenshot seguente mostra un'app con due gruppi di destinatari: Responsabili vendite e Rappresentanti vendite. Il riquadro Gestisci accesso destinatari consente di accedere al gruppo di destinatari Responsabili vendite per due gruppi di sicurezza: Responsabili vendite - America del Nord e Responsabili vendite - Europa. Il report Analisi margine lordo visualizzato nello screenshot per il gruppo di destinatari Responsabili vendite non è disponibile per il gruppo di destinatari Rappresentanti vendite.

Nota

Il termine gruppo di destinatari è talvolta usato. Non si tratta di un riferimento diretto all'uso dei gruppi di sicurezza. Include i membri del gruppo di destinatari che vedranno la raccolta di contenuti all'interno di un'app Power BI. Sebbene sia possibile assegnare singoli utenti a un gruppo di destinatari, è consigliabile assegnare gruppi di sicurezza, gruppi di Microsoft 365 o gruppi di distribuzione qualvolta sia conveniente. Per altre informazioni, vedere la strategia per l'uso di gruppi nell'articolo Pianificazione della sicurezza a livello di tenant.

Quando si gestiscono autorizzazioni per un'app, nella pagina Accesso diretto è possibile visualizzare i membri di ogni gruppo di destinatari. È anche possibile visualizzare gli utenti con un ruolo area di lavoro elencati in Tutti i destinatari. Non è possibile aggiornare le autorizzazioni dell'app dalla pagina Accesso diretto. È invece necessario ripubblicare l'app. È tuttavia possibile aggiornare le autorizzazioni dell'app dalla pagina In sospeso quando sono presenti richieste di accesso aperte per l'app.

Suggerimento

Il caso d'uso principale per i gruppi di destinatari delle app consiste nel definire autorizzazioni specifiche per diversi set di utenti. Tuttavia, è possibile liberare creatività quando si usano i gruppi di destinatari. Un utente può essere membro di più gruppi di destinatari e ogni gruppo di destinatari viene mostrato ai visualizzatori dell'app come un set secondario di menu. Ad esempio, è possibile creare un gruppo di destinatari denominato Inizia qui che contiene informazioni su come usare l'app, chi contattare, come fornire feedback e come ottenere assistenza. In alternativa, è possibile creare un gruppo di destinatari denominato Definizioni KPI che include un dizionario dati. Fornire questo tipo di informazioni aiuta i nuovi utenti e migliora le attività di adozione della soluzione.

Opzioni di autorizzazione app

Quando si crea o si ripubblica un'app, ogni gruppo di destinatari ha un riquadro Gestisci accesso ai destinatari. In tale riquadro sono disponibili le autorizzazioni seguenti.

• Concedere l'accesso a: per ogni gruppo di destinatari, è possibile concedere l'accesso a singoli utenti e gruppi. È possibile pubblicare l'app nell'intera organizzazione quando l’opzione è abilitata dall'impostazione del tenant Pubblica app nell'intera organizzazione e l'app non è installata automaticamente. Quando possibile, è consigliabile assegnare gruppi ai destinatari, perché l'aggiunta o la rimozione di utenti comporta la ripubblicazione dell'app. Tutti gli utenti con accesso all'area di lavoro dispongono automaticamente dell'autorizzazione per visualizzare o aggiornare l'app a seconda del ruolo dell'area di lavoro.
• Autorizzazioni del modello semantico:durante la pubblicazione di un'app, è possibile concedere due tipi di autorizzazioni del modello semantico:
  • Ricondividi modello semantico: se abilitato, agli utenti dell'app viene concessa l'Autorizzazione di ricondivisione ai modelli semantici sottostanti con altri utenti. È opportuno abilitare questa opzione quando i modelli semantici sottostanti possono essere ricondivisi facilmente con chiunque. È consigliabile ottenere l'approvazione dai proprietari del modello semantico prima di concedere l'autorizzazione di ricondivisione a un gruppo di destinatari dell'app.
  • Compila modello semantico: se abilitato, agli utenti dell'app viene concessa l'Autorizzazione di compilazione per i modelli semantici. L'autorizzazione di compilazione consente agli utenti di creare nuovi report, esportare i dati sottostanti da report e altro ancora. È consigliabile ottenere l'approvazione dai proprietari del modello semantico prima di concedere l'autorizzazione di compilazione a un gruppo di destinatari dell'app.

La possibilità di aggiungere autorizzazioni Ricondividi o Compila al modello semantico durante la pubblicazione di un'app è utile. È tuttavia consigliabile gestire separatamente le autorizzazioni dell'app e le autorizzazioni del modello semantico. Eccone le ragioni.

• Il modello semantico condiviso potrebbe trovarsi in un'area di lavoro diversa: se il modello semantico viene pubblicato in un'area di lavoro diversa dall'app, sarà necessario gestire le sua autorizzazioni direttamente. La possibilità di aggiungere autorizzazioni lettura, compilazione o ricondivisione durante la pubblicazione di un'app funziona solo per i modelli semantici che si trovano nella stessa area di lavoro dell'app. Per questo motivo, è consigliabile gestire abitualmente le autorizzazioni del modello semantico in modo indipendente.
• Le autorizzazioni del modello semantico sono gestite separatamente: se si rimuovono o si modificano le autorizzazioni per un'app, tale azione influisce solo sull'app. Non rimuove automaticamente le autorizzazioni del modello semantico assegnate in precedenza. In questo modo, le autorizzazioni dell'app e le autorizzazioni del modello semantico possono essere considerate come disaccoppiate. Sarà necessario gestire direttamente il modello semantico, separatamente dall'app, quando le autorizzazioni del modello semantico cambiano o devono essere rimosse.
• Le autorizzazioni del modello semantico devono essere controllate: concedere le autorizzazioni del modello semantico tramite un'app rimuove il controllo dal proprietario del modello semantico. La concessione dell'autorizzazione di ricondivisione fa affidamento sul buon senso degli utenti che scelgono di ricondividere i modelli semantici. La governance interna o le linee guida per la sicurezza possono diventare più difficili da gestire quando la ricondivisione è consentita.
• I consumer e gli autori hanno obiettivi diversi: in genere, ci sono molti più utenti di contenuto che creatori di un'organizzazione. In linea con il principio dei privilegi minimi, gli utenti necessitano solo dell'autorizzazione di lettura per il modello semantico sottostante. Non necessitano di autorizzazioni di compilazione a meno che non intendano creare nuovi report.

Suggerimento

Per altre informazioni su quando usare aree di lavoro dati e aree di lavoro report diverse, vedere l'articolo Pianificazione a livello di area di lavoro.

Diritti di preinstallazione dell'app

Dopo la pubblicazione di un'app Power BI, un utente deve generalmente installarla in modo da poterla aprire. Un utente può installare un'app dalla pagina App nel servizio Power BI o usando un collegamento ricevuto da un altro utente. Sarà in grado di trovare (e installare) un'app quando verrà incluso in almeno un gruppo di destinatari dell'app.

Un approccio alternativo per installare un'app consiste nell’eseguirne il push agli utenti di app. Ciò risulta nella preinstallazione dell'app in modo che venga visualizzata automaticamente nella pagina App nel servizio Power BI. Questo approccio è utile per utenti perché non rende necessario trovare e installare l'app. Tuttavia, le app preinstallate possono diventare un inconveniente per gli utenti perché potrebbero sovraccaricarli con troppe app non direttamente rilevanti per loro.

L'impostazione tenant Esegui il push delle app a utenti finali controlla chi è autorizzato a installare automaticamente le app. È consigliabile usare questa funzionalità poiché conveniente per gli utenti. Tuttavia, è anche consigliabile informare i creatori di contenuti su quando usare la funzionalità, in modo che non venga usata troppo spesso.

Suggerimento

Quando si pubblica un'app, se si seleziona l'opzione di installazione automatica dell'app, non è possibile impostare il gruppo di destinatari come l'intera organizzazione (se quest’opzione è abilitata dall'impostazione Esegui il push delle app agli utenti finali).

Elenco di controllo: quando si crea la strategia per l'uso delle app per visualizzatori di contenuto, le decisioni e azioni chiave includono:

• Decidere la strategia per l'uso delle app: definire le preferenze per l'uso delle app. Assicurarsi che sia allineata alla strategia complessiva per gli utenti di sola lettura.
• Decidere chi può pubblicare app nell'intera organizzazione: decidere quali autori di report possono pubblicare nell'intera organizzazione. Settare l'impostazione Pubblica app sull'intero tenant dell'organizzazione in modo che sia in linea con questa decisione.
• Decidere chi può eseguire il push delle app agli utenti finali: decidere quali autori di report di Power BI possono pre-installare le app. Settare l'impostazione Esegui il push delle app agli utenti finali perché sia in linea con questa decisione.
• Creare e pubblicare materiale sussidiario per gli autori di contenuti: fornire documentazione e formazione per gli autori di contenuti. Includere requisiti e preferenze su come usare le app in modo più efficace.
• Determinare come gestire richieste di accesso alle app: assicurarsi di disporre di un processo per assegnare i contatti e gestire le richieste di accesso alle app tempestivamente.

Ruolo Visualizzatore area di lavoro

Come descritto negli articoli sulla pianificazione dell'area di lavoro, lo scopo principale di un'area di lavoro è la collaborazione. I collaboratori dell'area di lavoro, ad esempio creatori di modelli semantici, creatori di report e tester, devono essere assegnati a uno dei tre ruoli: Collaboratore, Membro o Amministratore. Questi ruoli sono descritti nell'articolo Pianificazione della sicurezza degli autori di contenuto.

È possibile assegnare il ruolo Visualizzatore dell'area di lavoro agli utenti. Consentire agli utenti di accedere al contenuto direttamente in un'area di lavoro può essere appropriato per team di piccole dimensioni e team informali che lavorano a stretto contatto.

Consentire agli utenti di accedere direttamente al contenuto dell'area di lavoro è una scelta ottimale quando:

• La formalità di un'app, con le sue autorizzazioni separate, non è necessaria.
• I visualizzatori possono vedere tutti gli elementi archiviati nell'area di lavoro.
• Si desidera una gestione delle autorizzazioni più semplice rispetto alle autorizzazioni per singolo elemento.
• Gli utenti dell'area di lavoro potrebbero anche visualizzare un'app (quando un'app viene pubblicata per l'area di lavoro).
• L'intenzione è che i visualizzatori rivedano il contenuto prima che venga pubblicato in un'app.

Ecco alcuni suggerimenti per supportare i visualizzatori dell'area di lavoro.

• Organizzare il contenuto in ogni area di lavoro in modo che gli elementi siano facilmente localizzabili dagli utenti di report e che siano in linea con la sicurezza. In genere, l’organizzazione dell'area di lavoro per area di interesse o progetto è una buona soluzione.
• Separare il contenuto di sviluppo e test dal contenuto di produzione in modo che gli elementi in corso di lavorazione non siano accessibili ai visualizzatori.
• Usare app (o le autorizzazioni per singolo elemento quando appropriato) quando si prevedono molte richieste di accesso da elaborare. Non esiste un flusso di lavoro Richiedi accesso per le aree di lavoro.

Elenco di controllo: quando si crea la strategia per l'uso di aree di lavoro per visualizzatori di contenuto, le decisioni e azioni chiave includono:

• Decidere una strategia per l'uso del ruolo Visualizzatore dell'area di lavoro: definire le preferenze per l'uso delle aree di lavoro per gli utenti. Assicurarsi che sia allineata alla strategia complessiva per gli utenti di sola lettura.
• Creare e pubblicare materiale sussidiario per gli autori di contenuti: fornire documentazione e formazione per gli autori di contenuti. Includere requisiti e preferenze su come usare le autorizzazioni delle aree di lavoro in modo più efficace.

Autorizzazioni per singolo elemento

La condivisione di elementi individualmente concede l'autorizzazione a un singolo elemento. Generalmente, i creatori di contenuto meno esperti usano questa tecnica come tecnica di condivisione principale perché i comandi di condivisione vengono visualizzati in primo piano nel servizio Power BI. Per questo motivo, è importante informare i creatori di contenuto sulle diverse opzioni di condivisione, incluso quando usare autorizzazioni dell'app anziché ruoli dell'area di lavoro.

Le autorizzazioni per singolo elemento sono una scelta ottimale quando:

• Si vuole fornire l'accesso in sola lettura a un elemento (report o dashboard).
• Non si desidera che l’utente visualizzi tutto il contenuto pubblicato in un'area di lavoro.
• Non si desidera che l’utente visualizzi tutti i contenuti pubblicati in un gruppo di destinatari dell'app.

Usare le autorizzazioni per singolo elemento con moderazione, perché la condivisione concede l'autorizzazione di lettura a un singolo elemento. In un certo senso, le autorizzazioni per elemento possono essere considerate come un override dei ruoli dell'area di lavoro o delle autorizzazioni dell'app.

Suggerimento

È consigliabile usare le autorizzazioni per app quando possibile. Quindi, valutare l'uso di ruoli dell'area di lavoro per abilitare l'accesso diretto all'area di lavoro. Infine, usare le autorizzazioni per singolo elemento quando soddisfano i criteri precedenti. Le autorizzazioni dell'app e i ruoli dell'area di lavoro specificano entrambi la sicurezza per una raccolta di contenuto (anziché per singoli elementi), una procedura di sicurezza migliore.

La condivisione di molti elementi tramite autorizzazioni per singolo elemento può essere tediosa e soggetta a errori, soprattutto quando si condivide con singoli utenti anziché gruppi. Si consideri questo scenario: si sono condivisi 40 report a colleghi usando i loro singoli account utente. Quando un collega viene trasferito a un reparto diverso, è necessario revocare l'accesso, il che comporta la modifica delle autorizzazioni per tutti i 40 report.

Importante

La condivisione del contenuto da un'area di lavoro personale deve essere eseguita raramente. Le aree di lavoro personali sono più adatte a contenuto non critico, informale o temporaneo. Se si verifica una situazione in cui i creatori di contenuti condividono spesso contenuti importanti o critici dalle aree di lavoro personali, è consigliabile intervenire in modo appropriato per spostare il contenuto in un'area di lavoro standard. Per altre informazioni, vedere lo scenario di utilizzo di business intelligence personale.

Quando si condivide un singolo elemento, sono disponibili diverse opzioni di autorizzazione.

• Autorizzazione Ricondividi: se abilitata, gli utenti possono condividere l'elemento con altri utenti, inclusi i modelli semantici sottostanti. È opportuno concedere questa autorizzazione quando l'elemento può essere facilmente condiviso con chiunque. Questa rimuove il controllo dalla persona o dal team che gestisce l'elemento. Quindi, fa affidamento sul buon senso degli utenti a cui viene concessa l'autorizzazione di ricondivisione. Tuttavia, la governance interna o le linee guida per la sicurezza possono diventare più difficili da gestire quando la ricondivisione è consentita.
• Autorizzazione di compilazione: se abilitata, agli utenti viene concessa l'autorizzazione Compila per il modello semantico sottostante. L'autorizzazione di compilazione consente agli utenti di creare nuovi contenuti basati sul modello semantico. Consente inoltre di esportare i dati sottostanti dai report e altro ancora. Le considerazioni relative alla concessione dell'autorizzazione di compilazione sono descritte nell'articolo Pianificazione della sicurezza dei creatori di contenuti.

Le autorizzazioni per singolo elemento per report e dashboard possono essere appropriate per scenari informali, quando il contenuto viene condiviso con un numero ridotto di utenti. È consigliabile informare gli utenti sulla gestione delle autorizzazioni con app e aree di lavoro, soprattutto quando condividono contenuto a un numero elevato di utenti o utenti esterni al team. È importante sottolineare i punti seguenti.

• Diventa più difficile determinare quale contenuto sia stato condiviso con quali utenti, perché le autorizzazioni per ogni report e dashboard devono essere esaminate singolarmente.
• In molti casi, l'autorizzazione di ricondivisione viene impostata perché l'esperienza utente abilita questa opzione per impostazione predefinita. C'è quindi il rischio che il contenuto venga condiviso a un set di utenti più ampio di quello previsto. Questo esito può essere prevenuto deselezionando l'opzione Consenti ai destinatari di condividere questo report durante la condivisione. Ridurre al minimo l'oversharing in questo modo è un problema relativo al training degli utenti. L'autore del contenuto che imposta le autorizzazioni di condivisione deve valutare questa decisione ogni volta.
• Tutte le modifiche apportate ai report e ai dashboard sono visualizzabili immediatamente da altri utenti, il che potrebbe creare confusione tra gli utenti quando modifiche al contenuto sono in corso. Questo problema può essere risolto distribuendo il contenuto in un'app o usando aree di lavoro diverse per separare il contenuto di sviluppo, test e produzione. Per altre informazioni, vedere lo scenario di utilizzo della pubblicazione di contenuti self-service.
• In genere, quando un utente condivide il contenuto dall'area di lavoro personale e lascia l'organizzazione, l'IT disabilita il suo account utente. In questo caso, tutti i destinatari del contenuto condiviso perderanno immediatamente l'accesso al contenuto.

Esistono tre tipi specifici di condivisione: condivisione tramite collegamenti, condivisione diretta e visualizzazioni condivise.

Collegamenti di autorizzazioni per singolo elemento

Quando si condivide un singolo elemento, l'esperienza predefinita genera un collegamento di condivisione. Esistono tre tipi di collegamenti di condivisione.

• Utenti dell'organizzazione: se abilitato nelle impostazioni del tenant di Power BI, questo tipo di collegamento di condivisione è un modo semplice per fornire l'accesso in sola lettura a tutti gli utenti all'interno dell'organizzazione. Tuttavia, il collegamento di condivisione non funzionerà per utenti esterni. Questa opzione è più adatta quando chiunque può visualizzare il contenuto e il collegamento può essere condiviso liberamente in tutta l'organizzazione. A meno che non sia disabilitata dall'impostazione del tenant Consenti collegamenti condivisibili per concedere l'accesso a tutti gli utenti dell'organizzazione, questo tipo di condivisione è l'impostazione predefinita.
• Utenti con accesso esistente: questa opzione non crea un nuovo collegamento di condivisione. Invece, consente di recuperare l'URL in modo da poterlo inviare a un utente che ha già accesso.
• Utenti specifici: questa opzione genera un collegamento di condivisione per utenti o gruppi specifici. È consigliabile usare questa opzione per la maggior parte dei casi, poiché fornisce un accesso specifico. Se in genere si lavora con utenti esterni, è possibile usare questo tipo di collegamento per gli utenti guest che esistono già in Microsoft Entra ID. Per altre informazioni sul processo di invito pianificato per la creazione di utenti guest, vedere l'articolo Pianificazione della sicurezza a livello di tenant.

Importante

È consigliabile limitare l'impostazione del tenant Consenti collegamenti condivisibili per concedere l'accesso a tutti gli utenti dell'organizzazione ai membri di un gruppo. È possibile creare un nome di gruppo come Condivisione di Power BI all'intera organizzazione e quindi aggiungere un numero ridotto di utenti che sono consapevoli delle implicazioni della condivisione a livello di organizzazione. Se si è allarmati riguardo ai collegamenti esistenti a livello di organizzazione, è possibile usare l'API amministratore per trovare tutti gli elementi condivisi con l'intera organizzazione.

Un collegamento di condivisione aggiunge l'autorizzazione di lettura all'elemento. L'autorizzazione di ricondivisione è selezionata per impostazione predefinita. È anche possibile aggiungere l'autorizzazione di compilazione al modello semantico sottostante durante la creazione del collegamento di condivisione.

Suggerimento

È consigliabile insegnare agli autori di contenuti di abilitare l'opzione autorizzazione di compilazione solo quando l'utente del report è anche un creatore di contenuto che potrebbe dover creare report, esportare dati o creare un modello composito dal modello semantico sottostante.

I collegamenti di condivisione sono più facili da gestire rispetto alla condivisione dell’accesso diretta, in particolare quando si necessita di apportare modifiche in blocco. Si tratta di un vantaggio significativo quando vengono concesse autorizzazioni di condivisione a singoli utenti, più che a gruppi (il che in genere si verifica quando gli utenti self-service sono responsabili della gestione delle autorizzazioni). Prendere in considerazione i confronti seguenti.

• Collegamento di condivisione: viene concesso l'accesso con un collegamento di condivisione a 20 singoli utenti. Una singola modifica al collegamento influisce su tutti i 20 utenti.
• Accesso diretto: a 20 utenti viene concesso l'accesso diretto a un elemento. Per apportare una modifica, è necessario modificare tutte e 20 le autorizzazioni utente.

Autorizzazioni di accesso diretto per singolo elemento

È anche possibile ottenere autorizzazioni per singolo elemento usando l’accesso diretto. L'accesso diretto comporta la configurazione delle autorizzazioni per un singolo elemento. È anche possibile determinare eventuali autorizzazioni ereditate derivate dai ruoli dell'area di lavoro.

Quando si concede l'accesso diretto a un utente, gli viene concessa l'autorizzazione di lettura per l'elemento. L'autorizzazione di ricondivisione è selezionata per impostazione predefinita, come anche l'autorizzazione di compilazione per il modello semantico sottostante. È consigliabile insegnare agli autori di contenuti di abilitare l'autorizzazione di Compila solo quando l'utente del report è anche un creatore di contenuto che potrebbe dover creare report, esportare dati o creare modelli compositi dal modello semantico sottostante.

Suggerimento

L'esperienza utente rende molto semplice concedere le autorizzazioni di ricondivisione e compilazione, ma l'utente che esegue la condivisione deve sempre verificare che tali autorizzazioni siano necessarie.

Visualizzazioni condivise

Usare una visualizzazione condivisa per condividere una prospettiva filtrata di un report con un altro utente. È possibile pubblicare una visualizzazione condivisa usando un collegamento di condivisione o tramite accesso diretto.

Le visualizzazioni condivise sono un concetto temporaneo. Scadono automaticamente dopo 180 giorni. Per questo motivo, le visualizzazioni condivise sono più adatte a scenari di condivisione informale e temporanea. Assicurarsi che gli utenti siano consapevoli di questa limitazione.

Elenco di controllo: quando si crea la strategia per l'uso delle autorizzazioni per singolo elemento, le decisioni e azioni chiave includono:

• Decidere la strategia per l'uso della funzionalità di condivisione: definire le preferenze per l'uso delle autorizzazioni per ogni elemento. Assicurarsi che sia allineata alla strategia complessiva per gli utenti di sola lettura.
• Decidere chi può pubblicare link nell'intera organizzazione: decidere quali autori di report possono pubblicare link nell'intera organizzazione. Settare l'impostazione del tenant Consenti collegamenti condivisibili per concedere l'accesso a tutti gli utenti dell'organizzazione per essere in linea con questa decisione.
• Creare e pubblicare linee guida per gli autori di contenuti: fornire documentazione e formazione per gli autori di contenuti che includano requisiti e preferenze per usare autorizzazioni per singolo elemento in modo più efficace. Assicurarsi che i vantaggi e gli svantaggi delle autorizzazioni per singolo elemento siano chiari agli utenti. Includere indicazioni su quando usare i collegamenti di condivisione e quando usare la condivisione per accesso diretto.

Altre tecniche di query utente

I modi più comuni per gli utenti per interagire con Power BI sono le app, le aree di lavoro e le autorizzazioni per singolo elemento (descritte in precedenza in questo articolo).

Esistono altre tecniche che gli utenti possono usare per eseguire query sui dati di Power BI. Ognuna delle tecniche di query seguenti richiede un modello semantico o un'autorizzazione di compilazione datamart.

• Analizza in Excel: gli utenti che preferiscono usare Excel possono eseguire query su un modello semantico di Power BI usando Analizza in Excel. Questa funzionalità è un'ottima alternativa all'esportazione dei dati in Excel perché non comporta la duplicazione dei dati. Con una connessione dinamica al modello semantico, gli utenti possono creare tabelle pivot, grafici e filtri dei dati. Possono quindi pubblicare la cartella di lavoro in un'area di lavoro nel servizio Power BI che consente agli utenti di aprirla e interagire con essa.
• Endpoint XMLA: i consumer possono eseguire query su un modello semantico connettendosi all'endpoint XMLA. Un'applicazione conforme a XMLA può connettersi a, eseguire query su e utilizzare un modello semantico archiviato in un'area di lavoro Premium. Questa funzionalità è utile quando gli utenti vogliono usare un modello semantico di Power BI come origine dati per uno strumento di visualizzazione di dati esterno all'ecosistema Microsoft.
• Editor datamart: gli utenti possono eseguire query su un datamart di Power BI usando l'editor datamart. Si tratta di un editor di query visivo basato sul Web per la creazione di query senza codice. È disponibile anche un editor SQL basato sul Web per utenti che preferiscano scrivere query SQL. Entrambi gli editor eseguono query sul database SQL di Azure gestito sottostante al datamart di Power BI (anziché sul modello semantico predefinito).
• Endpoint SQL: i consumer possono eseguire query su un datamart di Power BI usando l'endpoint SQL. Possono usare strumenti come Azure Data Studio o SQL Server Management Studio (SSMS) per eseguire query SQL. L'endpoint SQL indirizza le query al database SQL di Azure gestito sottostante al datamart di Power BI anziché al modello semantico predefinito.

Per altre informazioni sull'autorizzazione di compilazione, vedere l'articolo Pianificazione della sicurezza per autori di contenuto.

Elenco di controllo: quando si pianifica quali tecniche di query saranno usate dagli utenti, le decisioni azioni chiave includono:

• Creare indicazioni per gli utenti sull'uso di Analizza in Excel: fornire documentazione e formazione per gli utenti su come riutilizzare al meglio modelli semantici esistenti con Excel.
• Creare indicazioni per gli utenti sull'uso dell'endpoint XMLA: fornire documentazione e formazione gli utenti su come riutilizzare al meglio modelli semantici esistenti con l'endpoint XMLA.
• Creare indicazioni per gli utenti sulle query datamart: fornire documentazione e formazione per i consumer sulle tecniche disponibili per l'esecuzione di query sui datamart di Power BI.

Richiedere il flusso di lavoro di accesso per gli utenti

Durante la condivisione di contenuto, è comune che un utente inoltri un collegamento (URL) a un altro utente. Quando il destinatario tenta di visualizzare il contenuto e scopre di non avervi accesso, può selezionare il pulsante Richiedi accesso. Questa azione avvia il flusso di lavoro Richiedi accesso. All'utente viene quindi chiesto di fornire un messaggio per spiegare il motivo della richiesta di accesso.

Esiste un flusso di lavoro Richiedi accesso per:

• Accesso a un'app Power BI.
• Accesso a un elemento, ad esempio un report o un dashboard.
• Accesso a un modello semantico. Per altre informazioni sul flusso di lavoro Richiedi accesso quando un modello semantico è individuabile, vedere l'articolo Pianificazione della sicurezza dell’autore di contenuto.

Richieste di accesso alle app

Esistono due modi per ottenere informazioni sulle richieste di accesso in sospeso inviate per un'app.

• Email: il/i contatto/i per l'app ricevono una notifica tramite posta elettronica. Per impostazione predefinita, questo contatto è l'autore dell'app. Per fornire un miglior supporto per app critiche, è consigliabile impostare il contatto su un gruppo che sia in grado di rispondere rapidamente alle richieste di accesso.
• Menu Gestisci autorizzazioni: gli amministratori e i membri dell'area di lavoro possono visualizzare, approvare o rifiutare le richieste di accesso. La pagina Gestisci autorizzazioni è disponibile nella pagina App e può essere aperta per ogni app. Questa funzionalità è disponibile anche per collaboratori dell'area di lavoro quando l'impostazione Consenti ai collaboratori di aggiornare l'app per questa area di lavoro è abilitata.

Le richieste di accesso in sospeso per un'app mostrano il messaggio fornito dall'utente. Ogni richiesta in sospeso può essere approvata o rifiutata. Quando si sceglie di approvare una richiesta, è necessario selezionare un gruppo di destinatari dell'app.

Lo screenshot seguente mostra una richiesta di accesso in sospeso da parte di un utente. Per approvarla, è necessario selezionare uno dei due gruppi di destinatari delle app, Rappresentanti vendite o Responsabili vendite.

Quando si pubblica un'app, il contenuto e le autorizzazioni vengono pubblicate contemporaneamente. Come descritto in precedenza, non è possibile pubblicare solo le autorizzazioni dell'app senza modifiche al contenuto. Tuttavia, esiste un'eccezione: quando si approva una richiesta di accesso in sospeso (ad esempio, quella illustrata nello screenshot precedente), la modifica delle autorizzazioni viene eseguita senza pubblicare il contenuto più recente nell'area di lavoro.

Richieste di accesso all'area di lavoro

L'accesso all'area di lavoro viene concesso agli utenti che appartengono al ruolo Amministratore o Membro.

Un utente che sta tentando di visualizzare un'area di lavoro riceve un messaggio di accesso negato quando non è membro di un ruolo dell'area di lavoro. Poiché non esiste un flusso di lavoro predefinito Richiedi accesso per le aree di lavoro, è preferibile usarle per team di piccole dimensioni e team informali che lavorano a stretto contatto. Questa è una delle ragioni per cui un'app Power BI è più adatta a team più grandi e agli scenari di distribuzione di contenuto più ampi.

Richieste di accesso per singolo elemento

Esistono due modi per ottenere informazioni sulle richieste di accesso in sospeso inviate per un singolo elemento, ad esempio un report.

• Email: il/i contatto/i per l'elemento ricevono una notifica tramite posta elettronica. Per fornire un miglior supporto per report critici, è consigliabile impostare il contatto su un gruppo che sia in grado di rispondere rapidamente alle richieste di accesso.
• Menu Gestisci autorizzazioni: gli amministratori e i membri dell'area di lavoro possono accedere alla pagina Gestisci autorizzazioni per ogni elemento. Possono visualizzare, approvare o rifiutare le richieste di accesso in sospeso.

Gestire le richieste di accesso con gruppi

Quando un utente invia il modulo Richiedi accesso per un elemento di Power BI (ad esempio un report o un modello semantico) o un'app Power BI, la richiesta viene inviata per un singolo utente. Tuttavia, molte organizzazioni di grandi dimensioni devono usare gruppi per rispettare i criteri di sicurezza interni.

Qualvolta risulti pratico, è consigliabile usare gruppi, anziché utenti singoli, per proteggere il contenuto. Per altre informazioni sulla pianificazione per gruppi, vedere l'articolo Pianificazione della sicurezza a livello di tenant.

Se si intende fornire l'accesso a gruppi anziché singoli utenti, il proprietario del contenuto o l'amministratore che sta elaborando la richiesta di accesso dovrà completare la richiesta in più passaggi:

1. Rifiutare la richiesta in sospeso in Power BI perché associata a un singolo utente.
2. Aggiungere il richiedente al gruppo corretto in base al processo corrente.
3. Notificare al richiedente che l’accesso è stato concesso.

Suggerimento

Vedere Flusso di lavoro di richiesta di accesso per autori per informazioni sulla risposta alle richieste di accesso da parte di autori di contenuto. Include anche raccomandazioni sull'uso di un modulo per le richieste di accesso.

Elenco di controllo: quando si pianifica il flusso di lavoro Richiedi accesso, le decisioni chiave e le azioni includono:

• Determinare chi debba gestire le richieste di accesso alle app: assicurarsi di disporre di un processo per gestire le richieste di accesso alle app tempestivamente. Assicurarsi che i contatti dell'app siano assegnati per supportare il processo.
• Determinare chi debba gestire le richieste di accesso per singolo elemento: assicurarsi di disporre di un processo per gestire le richieste di accesso tempestivamente. Assicurarsi che contatti siano assegnati a ogni elemento per supportare il processo.
• Includere nella documentazione e nella formazione per autori di contenuto: assicurarsi che gli autori di contenuti comprendano come gestire le richieste di accesso in modo tempestivo. Assicurarsi che siano consapevoli di come gestire le richieste quando un gruppo deve essere usato invece di un singolo utente.
• Includere nella documentazione e nella formazione: includere indicazioni per i creatori di contenuto su come gestire efficacemente le richieste di accesso. Includere anche indicazioni per gli utenti sulle informazioni da includere nel messaggio di richiesta di accesso.

Applicare la sicurezza dei dati in base all'identità utente

È possibile pianificare la creazione di un minor numero di modelli semantici e report applicando la sicurezza dei dati. L'obiettivo è applicare la sicurezza dei dati in base all'identità dell'utente che visualizza il contenuto.

Si consideri, ad esempio, che sia possibile condividere un singolo report di vendita con tutti i venditori (utenti), sapendo che ogni venditore visualizzerà solo i risultati delle vendite per la propria area geografica. Questo approccio consente di evitare la complessità della creazione di diversi report per ogni area che andrebbero condivisi con i venditori dell'area di vendita.

Alcune organizzazioni hanno requisiti specifici per i modelli semantici approvati (certificati o alzati di livello) o per i datamarts. Per dati che verranno usati su larga scala, potrebbe essere necessario usare la sicurezza dei dati.

È possibile ottenere la sicurezza dei dati in diversi modi.

• Modello semantico di Power BI: in qualità di creatore di dati di Power BI, è possibile applicare la sicurezza a livello di riga e la sicurezza a livello di oggetto (OLS). La sicurezza a livello di riga implica la definizione di ruoli e regole che filtrano le righe del modello di dati, mentre la sicurezza a livello di oggetto limita l'accesso a tabelle o colonne specifiche. Queste regole definite per la sicurezza a livello di riga e a livello di oggetto non si applicano ai riferimenti archiviati all'esterno del modello semantico, ad esempio filtri dei dati e selezioni di filtri. Entrambe le tecniche di sicurezza a livello di riga e a livello di oggetto sono descritte più avanti in questa sezione.
• Analysis Services: un modello semantico di connessione dinamica può connettersi a un modello di dati remoto, ospitato da Azure Analysis Services (AAS) o SQL Server Analysis Services (SSAS). Il modello remoto può applicare la sicurezza a livello di riga o a livello di oggetto in base all'identità dell’utente.
• Origine dati: alcune origini dati, ad esempio il database SQL di Azure, possono applicare la sicurezza a livello di riga. In questo caso, il modello di Power BI può sfruttare la sicurezza esistente anziché definirla. Questo approccio può essere significativamente vantaggioso quando la sicurezza a livello di riga definita nell'origine risulta complessa. È possibile sviluppare e pubblicare un modello DirectQuery e impostare le credenziali dell'origine dati del modello semantico nel servizio Power BI per abilitare l'accesso Single Sign-On (SSO). Quando un consumer di report apre un report, Power BI passa l'identità all'origine dati. L'origine dati applica quindi la sicurezza a livello di riga in base all'identità del consumer del report. Per altre informazioni sulla sicurezza a livello di riga del database SQL di Azure, vedere questo articolo.

Nota

I sistemi di origine, come il database SQL di Azure, possono anche usare tecniche come le visualizzazioni per restringere il contenuto che l'utente può visualizzare. Anche se questa è una tecnica valida, non è rilevante per il soggetto di questa sezione.

Sicurezza a livello di riga

La sicurezza a livello di riga (RLS) consente a un modello di dati di limitare l'accesso a un subset di dati. Viene generalmente usata per garantire che alcuni consumer di report non possano visualizzare dati specifici, ad esempio i risultati delle vendite di altre aree di vendita.

Suggerimento

Se si nota che un utente ha creato più modelli di dati per supportare diversi gruppi di consumer, verificare che la sicurezza a livello di riga soddisfi i propri requisiti. In genere è preferibile creare, testare e gestire un solo modello di dati anziché più modelli di dati.

Fare attenzione, poiché se un report di Power BI fa riferimento a una riga con sicurezza a livello di riga configurata, verrà visualizzato lo stesso messaggio che per un campo eliminato o non esistente. Per questi utenti, sembra che il report sia malfunzionante.

Esistono due passaggi per configurare la sicurezza a livello di riga: regole e mapping dei ruoli.

Regole sicurezza a livello di riga

Per modelli semantici, un modello di dati può configurare la sicurezza a livello di riga in Power BI Desktop creando uno o più ruoli. Un ruolo ha un nome univoco nel modello e include in genere una o più regole. Le regole applicano filtri alle tabelle del modello usando espressioni filtro di tipo DAX (Data Analysis Expressions). Per impostazione predefinita, un modello non ha ruoli.

Importante

Un modello senza ruoli significa che gli utenti che dispongono dell'autorizzazione per eseguire query sul modello di dati hanno accesso a tutti i dati del modello.

Le espressioni di regola vengono valutate nel contesto di riga. Il contesto di riga indica che l'espressione viene valutata per ogni riga usando i valori di colonna di tale riga. Quando l'espressione restituisce TRUE, l'utente può visualizzare la riga. È possibile definire regole statiche o dinamiche.

• Regole statiche: usare espressioni DAX che fanno riferimento a costanti, ad esempio [Region] = "Midwest".
• Regole dinamiche: usare funzioni DAX specifiche che restituiscono valori ambientali (anziché costanti). I valori ambientali vengono restituiti da tre funzioni DAX specifiche: USERNAME, USERPRINCIPALNAME e CUSTOMDATA. La definizione di regole dinamiche è un approccio semplice ed efficace quando una tabella del modello archivia valori del nome utente. Tali regole consentono di applicare una struttura basata sui dati per la Sicurezza a livello di riga.

Mapping dei ruoli di sicurezza a livello di riga

Dopo aver pubblicato il modello nel servizio Power BI, è necessario configurare in anticipo i mapping dei ruoli degli utenti che accedono a report correlati. Il mapping di ruoli comporta l'assegnazione di oggetti di sicurezza di Microsoft Entra ai ruoli. Gli oggetti di sicurezza possono essere account utente o gruppi di sicurezza.

Quando possibile, è consigliabile eseguire il mapping dei ruoli a gruppi di sicurezza. In questo modo, ci saranno meno mapping e l’appartenenza a un gruppo potrà essere gestita dal proprietario del gruppo.

È consigliabile rendere disponibili ai creatori di contenuti le informazioni sull'account di sicurezza di Microsoft Entra. Un'opzione consiste nel creare un flusso di dati con dati che siano mantenuti sincronizzati con Microsoft Entra ID. In questo modo, gli autori di contenuti possono integrare i dati del flusso di dati per produrre un modello semantico basato su dati.

Suggerimento

È possibile definire un ruolo senza regole. In questo caso, il ruolo fornisce l'accesso a tutte le righe di tutte le tabelle del modello. La configurazione di questo tipo di ruolo è adatta quando un amministratore o un utente può visualizzare tutti i dati nel modello.

Esperienza utente con sicurezza a livello di riga

Alcune organizzazioni scelgono intenzionalmente di usare la sicurezza a livello di riga come livello secondario di sicurezza, oltre alle autorizzazioni standard di Power BI. Si consideri lo scenario seguente: si condivide un collegamento a un report con l'intera organizzazione. Qualsiasi utente che visualizzi il report deve essere mappato a un ruolo di sicurezza a livello di riga per poter visualizzare i dati al suo interno. Se l’utente non è mappato a un ruolo di sicurezza a livello di riga, non potrà visualizzare i dati.

La presenza della sicurezza a livello di riga modifica l'esperienza predefinita per gli utenti.

• Quando la sicurezza a livello di riga non è definita per il modello semantico: creatori e utenti con almeno l'autorizzazione di lettura per il modello semantico possono visualizzare tutti i dati nel modello semantico.
• Quando la sicurezza a livello di riga è definita nel modello semantico: Autori e utenti con solo l'autorizzazione di lettura per il modello semantico visualizzeranno solo i dati che sono autorizzati a visualizzare (in base al mapping dei ruoli della sicurezza a livello di riga).

Nota

Alcune organizzazioni applicano la sicurezza a livello di riga come livello di sicurezza aggiuntivo, soprattutto quando sono coinvolti dati sensibili. Per questo motivo, si può scegliere di richiedere la sicurezza a livello di riga per i modelli semantici certificati. Questo requisito può essere ottenuto con un processo di revisione e approvazione interno precedente alla certificazione del modello semantico.

Quando un utente visualizza un report in un'area di lavoro o in un'app, la sicurezza a livello di riga potrebbe essere applicata o meno, a seconda delle autorizzazioni del modello semantico. Per questo motivo, è fondamentale che quando è necessario applicare la sicurezza a livello di riga, i consumer e gli autori di contenuti dispongano solo dell'autorizzazione di lettura per il modello semantico sottostante.

Ecco le regole di autorizzazione che determinano se la sicurezza a livello di riga sia applicata.

• L'utente dispone dell'autorizzazione di lettura per il modello semantico: la sicurezza a livello di riga viene applicata per l'utente.
• L'utente dispone dell'autorizzazione di lettura e di compilazione per il modello semantico: la sicurezza a livello di riga viene applicata per l'utente.
• L'utente dispone dell'autorizzazione di scrittura per il modello semantico: la sicurezza a livello di riga non viene applicata per l'utente, ovvero l’utente può visualizzare tutti i dati nel modello semantico. L'autorizzazione di scrittura consente di modificare un modello semantico. Può essere concessa in uno dei due modi seguenti:
  • Con i ruoli dell’area di lavoro Collaboratore, Membro o Amministratore (per l'area di lavoro in cui è archiviato il modello semantico).
  • Con l'autorizzazione di modello semantico di scrittura per singolo elemento.

Suggerimento

Per altre informazioni su come usare aree di lavoro diverse in modo che la sicurezza a livello di riga funzioni per gli autori di contenuto, vedere lo scenario di utilizzo di business intelligence gestita self-service.

Per altre informazioni sulla sicurezza a livello di riga, vedere Limitare l'accesso ai dati del modello di Power BI.

Sicurezza a livello di riga per datamart

Anche i datamart di Power BI possono applicare la sicurezza a livello di riga. Tuttavia, l'implementazione è diversa.

La differenza principale è che la sicurezza a livello di riga per i datamart è configurata nel servizio Power BI, anziché in Power BI Desktop.

Un'altra differenza consiste nel fatto che i datamart applicano la sicurezza a livello di riga sia al modello semantico che al database SQL di Azure gestito associato al datamart. L'applicazione della sicurezza a livello di riga a entrambi i livelli offre coerenza e flessibilità. Gli stessi filtri di sicurezza a livello di riga vengono applicati indipendentemente da come l'utente esegua query sui dati, sia che si connetta al modello semantico che al database SQL di Azure gestito.

Per altre informazioni, vedere Sicurezza a livello di riga per datamart.

Sicurezza a livello di oggetto

La sicurezza a livello di oggetto (OLS) consente a un modello di dati di limitare l'accesso a tabelle e colonne specifiche e ai relativi metadati. In genere, si usa OLS per garantire che colonne sensibili (ad esempio, lo stipendio dei dipendenti) non siano visibili a determinati utenti. Anche se non è possibile limitare l'accesso a misure, qualsiasi misura che fa riferimento a una colonna con restrizioni sarà limitata.

Si consideri un esempio di tabella dipendenti. Questa contiene colonne che archiviano il nome del dipendente, il numero di telefono e anche lo stipendio. È possibile usare OLS per assicurarsi che solo determinati utenti, come il personale senior delle risorse umane, possano visualizzare i valori di stipendio. Per gli utenti che non possono visualizzare i valori di stipendio, è come se la colonna non esistesse.

Prestare attenzione, perché se un oggetto visivo del report di Power BI include lo stipendio, gli utenti che non hanno accesso a tale campo riceveranno un messaggio di errore. Il messaggio li informerà che l'oggetto non esiste. Per questi utenti, sembra che il report sia malfunzionante.

Nota

È anche possibile definire prospettive in un modello di dati. Una prospettiva definisce subset visualizzabili di oggetti modello che consentono di fornire uno stato attivo specifico per gli autori di report. Le prospettive non sono destinate a limitare l'accesso agli oggetti modello. Un utente può comunque eseguire query su una tabella o una colonna, anche quando non è visibile. Di conseguenza, considerare le prospettive come un comfort per l’utente anziché una funzionalità di sicurezza.

Attualmente, non esiste un'interfaccia in Power BI Desktop per configurare OLS. È possibile usare l’Editor tabulare, uno strumento di terzi per la creazione, il mantenimento e la gestione di modelli. Per altre informazioni, vedere lo scenario di utilizzo di gestione avanzata dei modelli di dati.

Per altre informazioni sulla sicurezza a livello di oggetto, vedere Limitare l'accesso ad oggetti del modello di Power BI.

Elenco di controllo: quando si pianificano la sicurezza a livello di riga e a livello di oggetto, le decisioni e azioni principali includono:

• Decidere la strategia per l'uso della sicurezza a livello di riga: valutare i casi d'uso e gli scopi per i quali si intende usare la sicurezza a livello di riga.
• Decidere la strategia per l'uso della sicurezza a livello di oggetto: valutare i casi d'uso e gli scopi per i quali si intende usare la sicurezza a livello di oggetto.
• Prendere in considerazione i requisiti per contenuto certificato: se è necessario un processo per certificare un modello semantico, decidere se includere requisiti specifici per l'uso della sicurezza a livello di riga o a livello di oggetto.
• Creare e pubblicare indicazioni per gli utenti: creare documentazione per gli utenti che includa requisiti e preferenze per l'uso della sicurezza a livello di riga e a livello di oggetto. Descrivere come ottenere informazioni di mapping utente, se presenti in una posizione centralizzata.
• Aggiornare i materiali di formazione: includere informazioni chiave sui requisiti e sulle preferenze per la sicurezza a livello di riga e a livello di oggetto nei materiali di formazione degli utenti. Fornire esempi per consentire agli utenti di comprendere quando sia opportuno usare una delle due tecniche di sicurezza dei dati.

Contenuto correlato

Nell'articolo successivo di questa serie vengono fornite informazioni sulla pianificazione della sicurezza per autori di contenuto responsabili della creazione di modelli semantici, flussi di dati, datamart, report o dashboard.