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

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sul carico di lavoro di Power BI all'interno di Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo sulla pianificazione della sicurezza descrive le strategie per i consumer di sola lettura. L'attenzione riguarda le autorizzazioni del visualizzatore per i report e le app e su come applicare la sicurezza dei dati. È destinato principalmente a:

• Amministratori di Power BI: amministratori responsabili della supervisione di Power BI nell'organizzazione.
• Centro di eccellenza, IT e team bi: i 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 il contenuto usato da altri utenti.

La serie di articoli è destinata a 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 il contenuto creato e pubblicato da altri utenti. I consumatori sono l'obiettivo di questo articolo. Per la pianificazione della sicurezza incentrata sugli autori di contenuti e sui proprietari, vedere l'articolo Content Creator security planning (Pianificazione della sicurezza degli autori di contenuti).

Per ottenere il massimo da 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. La funzionalità di condivisione nella servizio Power BI ha come ambito un solo elemento. Si svolge più comunemente tra individui che si conoscono e lavorano strettamente insieme.

La distribuzione è la posizione in cui il contenuto viene distribuito ad altri utenti, noti come destinatari. Spesso comporta un numero maggiore di utenti in più team. I destinatari potrebbero non aver richiesto in modo esplicito il contenuto, ma è riconosciuto che è necessario per svolgere il proprio ruolo. I destinatari che utilizzano contenuti distribuiti potrebbero o meno conoscere l'autore originale del contenuto. Di conseguenza, la distribuzione come concetto è 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 correlato alla condivisione del contenuto con i 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. I collegamenti di condivisione e la condivisione dell'accesso diretto sono descritti in questo articolo.

Importante

Il ruolo di amministratore di Power BI è stato rinominato. Il nuovo nome del ruolo è Amministratore infrastruttura.

Strategia per i consumer di sola lettura

Nell'servizio Power BI i consumer possono visualizzare un report o un dashboard quando hanno l'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, precedentemente noto come set di dati) o un'altra origine.

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

• Concessione di accesso a utenti e gruppi a un'app Power BI.
• Aggiunta di utenti e gruppi a un ruolo Visualizzatore area di lavoro di Power BI.
• Fornire autorizzazioni per utenti e gruppi per elemento tramite un collegamento di condivisione.
• Fornire autorizzazioni per utenti e gruppi per elemento usando l'accesso diretto.

Le opzioni del ruolo Visualizzatore 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 elemento comportano la gestione delle autorizzazioni per un singolo elemento.

Suggerimento

In genere, è consigliabile usare un'app Power BI per la maggior parte dei consumer. 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 noiosa, dispendiosa in termini di tempo e soggetta 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 relative autorizzazioni siano le seguenti:

• Ereditato dall'area di lavoro o da un'app.
• Applicato direttamente all'elemento.

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

La strategia scelta per i consumer di sola lettura può essere diversa. Deve basarsi sulla singola soluzione, sulle preferenze di chi gestisce la soluzione o sulle esigenze del consumatore. Nella parte restante di questa sezione viene descritto quando prendere in considerazione l'uso di ognuna delle tecniche disponibili.

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

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

Autorizzazioni per le app Power BI

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

• Il riquadro di spostamento dell'app offre un'esperienza utente semplice e intuitiva. È un'esperienza più bella 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.
• I consumer hanno accesso solo a elementi specifici inclusi in modo esplicito nell'app per i 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 predefinito Richiedi accesso .

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. In questa sezione l'attenzione riguarda le app aziendali anziché le app modello.

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

Suggerimento

Per altre informazioni sull'uso di un'app Power BI per una distribuzione di contenuto generale, vedere lo scenario di utilizzo di business intelligence aziendale. È consigliabile che gli autori di contenuti che devono distribuire contenuti considerino 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:

• Concessione dell'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.
• Concessione delle autorizzazioni dell'app ai consumer. 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, è possibile considerare concettualmente i ruoli dell'area di lavoro 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 all'area di lavoro, vedere l'articolo Pianificazione della sicurezza di Content Creator.

L'uso di un'app per distribuire il contenuto ai consumer di sola lettura è la scelta migliore quando:

• Si vuole che gli utenti possano visualizzare solo elementi specifici visibili per il 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 vuole una gestione delle autorizzazioni più semplice per gli utenti di sola lettura rispetto alle autorizzazioni per elemento.
• Si vuole assicurarsi che venga applicata la sicurezza a livello di riga per i consumer (quando hanno l'autorizzazione di sola lettura per il modello semantico sottostante).
• Si vuole assicurarsi 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, esistono 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, potrebbe inavvertitamente comportare l'instabilità dei report (anche se non sono stati ripubblicati nell'app). Esistono due modi per attenuare 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 separate per lo sviluppo e il test. Facoltativamente, è possibile ottenere un livello di controllo superiore sulla distribuzione del contenuto dell'area di lavoro dallo sviluppo alla produzione e al test usando le pipeline di distribuzione.
• Il contenuto e le autorizzazioni vengono 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 ripubblicare l'app semplicemente per aggiornare le autorizzazioni. Per attenuare questo rischio, assegnare le autorizzazioni dell'app ai gruppi di sicurezza e usare le appartenenze ai gruppi di sicurezza (invece dei 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 nella 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.

• Sono disponibili 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.

Questa funzionalità consente di combinare e abbinare contenuti e gruppi di destinatari presenta i vantaggi seguenti.

• Alcuni report possono essere disponibili per la visualizzazione da parte di più destinatari. La creazione di più gruppi di destinatari elimina quindi la necessità di duplicare il contenuto in aree di lavoro diverse.
• Alcuni report devono essere disponibili per un solo gruppo di destinatari. Il contenuto di un 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: Sales Leadership e Sales Reps. Il riquadro Gestisci accesso al pubblico consente di accedere al gruppo di destinatari Sales Leadership per due gruppi di sicurezza: Sales Leadership-America del Nord e Sales Leadership-Europe. Il report Gross Margin Analysis visualizzato nello screenshot per il gruppo di destinatari Sales Leadership non è disponibile per il gruppo di destinatari dei rappresentanti delle vendite.

Nota

Il termine gruppo di destinatari viene talvolta usato. Non è 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 ogni volta che è pratico. Per altre informazioni, vedere la strategia per l'uso dei gruppi nell'articolo Pianificazione della sicurezza a livello di tenant.

Quando si gestiscono le 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 elencato in Tutti i gruppi di 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 l'uso dei gruppi di destinatari delle app consiste nel definire autorizzazioni specifiche per diversi set di utenti. Tuttavia, è possibile ottenere un po'di creatività quando si usano i destinatari. Un utente può essere un membro di più gruppi di destinatari e ogni gruppo di destinatari viene visualizzato ai visualizzatori dell'app come un set secondario di menu. Ad esempio, è possibile creare un gruppo di destinatari denominato Start Here che contiene informazioni su come usare l'app, chi contattare, come fornire commenti e suggerimenti 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 dell'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 è abilitata dall'impostazione Pubblica app nell'intero tenant dell'organizzazione e l'app non viene installata automaticamente. Quando possibile, è consigliabile assegnare gruppi ai gruppi di destinatari perché l'aggiunta o la rimozione di utenti comporta la ripubblicazione dell'app. Tutti gli utenti con accesso all'area di lavoro hanno automaticamente l'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 abilitata, 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.
  • Compilazione del modello semantico: se abilitata, 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 dai 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 il modello semantico Ricondividere o compilare le autorizzazioni durante la pubblicazione di un'app è utile. È tuttavia consigliabile gestire separatamente le autorizzazioni dell'app e le autorizzazioni del modello semantico. Ecco i motivi per cui.

• Il modello semantico condiviso potrebbe trovarsi in un'area di lavoro separata: se il modello semantico viene pubblicato in un'area di lavoro separata dall'app, sarà necessario gestirle 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 acquisire l'abitudine di gestire le autorizzazioni del modello semantico in modo indipendente.
• Le autorizzazioni del modello semantico vengono 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, è possibile considerare le autorizzazioni dell'app e le autorizzazioni del modello semantico come disaccoppiate. È 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: la concessione delle autorizzazioni del modello semantico tramite un'app rimuove il controllo dal proprietario del modello semantico. La concessione dell'autorizzazione di ricondivisione si basa su un buon giudizio da parte 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 è consentita la ricondivisione.
• I consumer e gli autori hanno obiettivi diversi: in genere, ci sono molti più consumer di contenuti che creatori di un'organizzazione. In linea con il principio dei privilegi minimi, i consumer necessitano solo dell'autorizzazione di lettura per il modello semantico sottostante. Non sono necessarie 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 di report separate, 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 in genere installarlo in modo che possa aprirlo. Un utente può installare un'app dalla pagina App nel servizio Power BI o usando un collegamento ricevuto da un altro utente. Saranno in grado di trovare (e installare) un'app quando vengono incluse in almeno un gruppo di destinatari dell'app.

Un approccio alternativo per installare un'app consiste nel eseguirne il push nei consumer di app. Viene restituita la preinstallazione dell'app in modo che venga visualizzata automaticamente nella pagina App nel servizio Power BI. Questo approccio è utile per gli utenti perché non è necessario trovare e installare l'app. Tuttavia, le app preinstallate possono diventare un fastidio per gli utenti perché potrebbero diventare sovraccaricate da troppe app che non sono rilevanti per loro.

L'impostazione Push apps to end users tenant controlla chi è autorizzato a installare automaticamente le app. È consigliabile usare questa funzionalità perché è utile per gli utenti. Tuttavia, ti consigliamo anche di informare i creatori di contenuti su quando usarlo in modo che non venga sovrautilato.

Suggerimento

Quando si pubblica un'app, se si seleziona l'opzione per installare automaticamente l'app, non è possibile impostare il gruppo di destinatari come l'intera organizzazione (se abilitata dall'impostazione Push delle app agli utenti finali).

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

• Decidere la strategia per l'uso delle app: definire le preferenze per l'uso delle app. Assicurarsi che sia allineato alla strategia complessiva per i consumer di sola lettura.
• Decidere chi può pubblicare app nell'intera organizzazione: decidere quali autori di report possono pubblicare nell'intera organizzazione. Impostare l'impostazione Pubblica app sull'intero tenant dell'organizzazione per allinearsi a 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. Impostare l'impostazione Push apps to end users tenant (Push apps to end users tenant) per allinearla a 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 per l'uso delle app in modo più efficace.
• Determinare come gestire le richieste di accesso alle app: assicurarsi che sia presente un processo per assegnare i contatti e gestire le richieste di accesso alle app in modo tempestivo.

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 Amministrazione. Questi ruoli sono descritti nell'articolo Pianificazione della sicurezza degli autori di contenuti.

È possibile assegnare il ruolo Visualizzatore dell'area di lavoro ai consumer. Consentire agli utenti di accedere al contenuto direttamente in un'area di lavoro può avere senso per i team di piccole dimensioni e i team informali che interagiscono 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 autorizzazioni separate, non è necessaria.
• I visualizzatori possono visualizzare tutti gli elementi archiviati nell'area di lavoro.
• Si vuole una gestione delle autorizzazioni più semplice rispetto alle autorizzazioni per 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 si trovino facilmente dai consumer di report e che siano allineati correttamente alla sicurezza. L'organizzazione dell'area di lavoro per area di interesse o progetto funziona in genere correttamente.
• Separare il contenuto di sviluppo e test dal contenuto di produzione in modo che gli elementi in corso non possano essere accessibili dai visualizzatori.
• Usare le app (o le autorizzazioni per elemento quando appropriato) quando si prevede di avere 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 i visualizzatori di contenuto, le decisioni chiave e le azioni 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 i consumer. Assicurarsi che sia allineato alla strategia complessiva per i consumer di sola lettura.
• Creare e pubblicare materiale sussidiario per gli autori di contenuti: fornire documentazione e formazione per gli autori di contenuti. Includere i requisiti e le preferenze per l'uso delle autorizzazioni dell'area di lavoro in modo più efficace.

Autorizzazioni per elemento

La condivisione di singoli elementi concede l'autorizzazione a un singolo elemento. I creatori di contenuti meno esperti usano in genere questa tecnica come tecnica di condivisione principale perché i comandi di condivisione vengono visualizzati in modo evidente nella servizio Power BI. Per questo motivo, è importante informare i creatori di contenuti sulle diverse opzioni di condivisione, tra cui quando usare le autorizzazioni dell'app anziché i ruoli dell'area di lavoro.

Le autorizzazioni per elemento sono una scelta ottimale quando:

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

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

Suggerimento

È consigliabile usare le autorizzazioni per le app quando possibile. Prendere quindi in considerazione l'uso dei ruoli dell'area di lavoro per abilitare l'accesso diretto all'area di lavoro. Infine, usare le autorizzazioni per 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 elemento può essere noiosa e soggetta a errori, soprattutto quando si condivide con singoli utenti anziché gruppi. Si consideri questo scenario: si hanno 40 report condivisi ai colleghi usando i singoli account utente. Quando un collega trasferisce a un reparto diverso, è necessario revocare l'accesso, 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 al 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 di 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. Rimuove il controllo dalla persona o dal team che gestisce l'elemento. Quindi, si basa su un buon giudizio da parte 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 è consentita la ricondivisione.
• Autorizzazione di compilazione: se abilitata, agli utenti viene concessa l'autorizzazione di compilazione 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 di Creatore di contenuti .

Le autorizzazioni per elemento per report e dashboard possono essere appropriate per scenari informali quando il contenuto viene condiviso con alcuni 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 il contenuto 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 risultato può essere impedito deselezionando l'opzione Consenti ai destinatari di condividere questo report durante la condivisione. Ridurre al minimo l'oversharing in questo modo è un problema di training degli utenti. L'autore del contenuto che imposta le autorizzazioni di condivisione deve prendere in considerazione questa scelta ogni volta.
• Tutte le modifiche apportate ai report e ai dashboard sono visualizzabili immediatamente da altri utenti, che potrebbero confondere gli utenti quando le modifiche al contenuto sono in corso. Questo problema può essere risolto distribuendo il contenuto in un'app o usando aree di lavoro separate per separare il contenuto di sviluppo, test e produzione. Per altre informazioni, vedere lo scenario di utilizzo della pubblicazione di contenuti self-service.
• Quando un utente condivide il contenuto dall'area di lavoro personale e lascia l'organizzazione, l'IT in genere disabilita l'account utente. In questo caso, tutti i destinatari del contenuto condiviso perderanno immediatamente l'accesso al contenuto.

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

Collegamenti alle autorizzazioni per elemento

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

• Persone nell'organizzazione: Se abilitata 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 gli utenti esterni. Questa opzione è più adatta a quando chiunque può visualizzare il contenuto e il collegamento può essere condiviso liberamente in tutta l'organizzazione. A meno che non sia disabilitato dall'impostazione Consenti collegamenti condivisibili di concedere l'accesso a tutti gli utenti del tenant dell'organizzazione , questo tipo di condivisione è l'impostazione predefinita.
• Persone 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 del tempo perché fornisce un accesso specifico. Se in genere si lavora con utenti esterni, è possibile usare questo tipo di collegamento per gli utenti guest già esistenti in Microsoft Entra ID (noto in precedenza come Azure Active Directory). 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 Consenti collegamenti condivisibili per concedere l'accesso a tutti gli utenti del tenant 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 comprendono le implicazioni della condivisione a livello di organizzazione. Se si è interessati ai collegamenti esistenti a livello di organizzazione, è possibile usare l'API di amministrazione per trovare tutti gli elementi condivisi con l'intera organizzazione.

Un collegamento di condivisione aggiunge l'autorizzazione Lettura all'elemento. L'autorizzazione Di ricondivisione è selezionata per impostazione predefinita. È anche possibile aggiungere l'autorizzazione di compilazione al modello semantico sottostante contemporaneamente alla 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 contenuti 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 diretta dell'accesso, in particolare quando è necessario apportare modifiche in blocco. Si tratta di un vantaggio significativo quando ai singoli utenti vengono concesse autorizzazioni di condivisione, più di gruppi (che in genere si verificano quando gli utenti self-service sono responsabili della gestione delle autorizzazioni). Prendere in considerazione i confronti seguenti.

• Collegamento di condivisione: a 20 utenti singoli viene concesso l'accesso con un collegamento di condivisione. Con 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 le 20 autorizzazioni utente.

Autorizzazioni di accesso diretto per elemento

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

Quando si concede a un utente l'accesso diretto, viene concessa l'autorizzazione lettura per l'elemento. L'autorizzazione Di ricondivisione è selezionata per impostazione predefinita, come è l'autorizzazione Di compilazione per il modello semantico sottostante. È consigliabile insegnare agli autori di contenuti di abilitare l'autorizzazione di compilazione solo quando l'utente di questo report è anche un creatore di contenuti 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 se tali autorizzazioni sono 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 l'accesso diretto.

Le visualizzazioni condivise sono un concetto temporaneo. Scadono automaticamente dopo 180 giorni. Per questo motivo, le visualizzazioni condivise sono più adatte agli 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 elemento, le decisioni chiave e le azioni 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 allineato alla strategia complessiva per i consumer di sola lettura.
• Decidere chi può pubblicare i collegamenti all'intera organizzazione: decidere quali autori di report possono pubblicare i collegamenti per l'intera organizzazione. Impostare l'impostazione Consenti collegamenti condivisibili per concedere l'accesso a tutti gli utenti del tenant dell'organizzazione per allinearsi a questa decisione.
• Creare e pubblicare linee guida per gli autori di contenuti: fornire documentazione e formazione per gli autori di contenuti che includono requisiti e preferenze per l'uso delle autorizzazioni per elemento in modo più efficace. Assicurarsi che siano chiari i vantaggi e gli svantaggi delle autorizzazioni per elemento. Includere indicazioni per quando usare i collegamenti di condivisione e quando usare la condivisione diretta degli accessi.

Altre tecniche di query consumer

I modi più comuni per interagire con Power BI sono le app, le aree di lavoro e le autorizzazioni per 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: i consumer 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é i dati non vengono duplicati. 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 nella 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, eseguire query e utilizzare un modello semantico archiviato in un'area di lavoro Premium. Questa funzionalità è utile quando i consumer vogliono usare un modello semantico di Power BI come origine dati per uno strumento di visualizzazione dei dati all'esterno dell'ecosistema Microsoft.
• Editor datamart: i consumer 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 quando i consumer preferiscono scrivere query SQL. Entrambi gli editor eseguono query sul database SQL di Azure gestito che sottoscriva il datamart di Power BI (anziché il 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 che sottoscriva il datamart di Power BI anziché il modello semantico predefinito.

Per altre informazioni sull'autorizzazione di compilazione, vedere l'articolo Pianificazione della sicurezza di Content Creator.

Elenco di controllo : quando si pianificano le tecniche di query usate dai consumer, le decisioni chiave e le azioni includono:

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

Richiedere il flusso di lavoro di accesso per i consumer

Quando si condivide il contenuto, è comune che un utente inoltra un collegamento (URL) a un altro utente. Quando il destinatario tenta di visualizzare il contenuto e rileva che non ha 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 per cui vuole l'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 del contenuto .

Richieste di accesso alle app

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

• Email: i contatti per l'app ricevono una notifica tramite posta elettronica. Per impostazione predefinita, questo contatto è l'autore dell'app. Per fornire un supporto migliore per le app critiche, è consigliabile impostare il contatto su un gruppo 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 i 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 un utente. Per approvarlo, è necessario selezionare uno dei due gruppi di destinatari delle app, Sales Reps o Sales Leadership.

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 Amministrazione o al ruolo 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 usare per i team di piccole dimensioni e i team informali che collaborano a stretto contatto. Questo è un motivo per cui un'app Power BI è più adatta ai team più grandi e agli scenari di distribuzione dei contenuti più ampi.

Richieste di accesso per elemento

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

• Email: i contatti per l'elemento ricevono una notifica tramite posta elettronica. Per fornire un supporto migliore per i report critici, è consigliabile impostare il contatto su un gruppo 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 i 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 i gruppi per rispettare i criteri di sicurezza interni.

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

Se si intende fornire l'accesso ai gruppi anziché ai 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 di avere accesso.

Suggerimento

Vedere Richiedere il flusso di lavoro di accesso per gli autori per informazioni sulla risposta alle richieste di accesso da parte degli autori di contenuti. 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 deve gestire le richieste di accesso alle app: assicurarsi che un processo sia in grado di gestire le richieste di accesso alle app in modo tempestivo. Assicurarsi che i contatti dell'app siano assegnati per supportare il processo.
• Determinare chi deve gestire le richieste per elemento: assicurarsi che un processo sia in grado di gestire le richieste di accesso in modo tempestivo. Assicurarsi che i contatti siano assegnati a ogni elemento per supportare il processo.
• Includere nella documentazione e nella formazione per gli autori di contenuti: 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 contenuti su come gestire in modo efficace 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à consumer

È 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 (consumer), 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 report separati per area da condividere 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 i dati che verranno ampiamente usati, potrebbe essere necessario usare la sicurezza dei dati.

È possibile eseguire 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 OLS limita l'accesso a tabelle o colonne specifiche. Queste regole definite per la sicurezza a livello di riga e OLS 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 OLS 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 OLS in base all'identità del consumer.
• Origine dati: alcune origini dati, ad esempio 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 un vantaggio significativo quando la sicurezza a livello di riga definita nell'origine è 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 su database SQL di Azure sicurezza a livello di riga, vedere questo articolo.

Nota

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

Sicurezza a livello di riga

La sicurezza a livello di riga consente a un modello di dati di limitare l'accesso a un subset di dati. In genere viene usato 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 è notato che un utente che crea più modelli di dati per supportare gruppi diversi di consumer, verificare se la sicurezza a livello di riga soddisfa i propri requisiti. In genere è preferibile creare, testare e gestire un modello di dati anziché più modelli di dati.

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

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

Regole di sicurezza a livello di riga

Per i 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 all'interno del contesto di riga. 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: U edizione Standard RNAME, U edizione Standard RPRINCIPALNAME 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 nella servizio Power BI, è necessario configurare i mapping dei ruoli in anticipo per gli utenti che accedono ai 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 ai gruppi di sicurezza. In questo modo, ci saranno meno mapping e la gestione delle appartenenze ai gruppi può 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 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 sui 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 di usare intenzionalmente 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 visualizza il report deve essere mappato a un ruolo di sicurezza a livello di riga per poter visualizzare i dati nel report. Se non viene eseguito il mapping a un ruolo di sicurezza a livello di riga, non verranno visualizzati dati.

La presenza di sicurezza a livello di riga modifica l'esperienza predefinita per i consumer.

• Quando la sicurezza a livello di riga non è definita per il modello semantico: creatori e consumer con almeno l'autorizzazione lettura per il modello semantico possono visualizzare tutti i dati nel modello semantico.
• Quando la sicurezza a livello di riga è definita nel modello semantico: creatori e consumer con autorizzazione di sola lettura per il modello semantico potranno visualizzare 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, è possibile 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 prima di certificare il modello semantico.

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

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

• L'utente dispone dell'autorizzazione lettura per il modello semantico: la sicurezza a livello di riga viene applicata per l'utente.
• L'utente dispone delle autorizzazioni lettura e 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 può visualizzare tutti i dati nel modello semantico. L'autorizzazione Scrittura consente di modificare un modello semantico. Può essere concessa in uno dei due modi seguenti:
  • Con i ruoli collaboratore, membro o Amministrazione area di lavoro (per l'area di lavoro in cui è archiviato il modello semantico).
  • Con l'autorizzazione write semantic model per elemento.

Suggerimento

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

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 i datamarts

I datamarts di Power BI possono anche applicare la sicurezza a livello di riga. Tuttavia, l'implementazione è diversa.

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

Un'altra differenza consiste nel fatto che i datamarts 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 dal modo in cui l'utente esegue query sui dati, sia che si tratti di connessione al modello semantico o al database SQL di Azure gestito.

Per altre informazioni, vedere La sicurezza a livello di riga per i datamarts.

Sicurezza a livello di oggetto

La sicurezza a livello di oggetto 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 le colonne sensibili, ad esempio lo stipendio dei dipendenti, non siano visibili a determinati utenti. Anche se non è possibile limitare l'accesso alle misure, qualsiasi misura che fa riferimento a una colonna con restrizioni sarà limitata.

Si consideri un esempio di tabella employee. Contiene colonne che archiviano il nome del dipendente e 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 stipendio, gli utenti che non hanno accesso a tale campo riceveranno un messaggio di errore. Il messaggio informerà che l'oggetto non esiste. Per questi utenti, sembra che il report sia interrotto.

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 praticità 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 terze parti per la creazione, la gestione e la gestione dei modelli. Per altre informazioni, vedere lo scenario di utilizzo avanzato della gestione dei modelli di dati.

Per altre informazioni su OLS, vedere Limitare l'accesso agli oggetti modello di Power BI.

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

• Decidere la strategia per l'uso della sicurezza a livello di riga: prendere in considerazione i casi d'uso e gli scopi che si intende usare per la sicurezza a livello di riga.
• Decidere la strategia per l'uso di OLS: prendere in considerazione i casi d'uso e gli scopi che si intende usare per la sicurezza a livello di oggetto.
• Prendere in considerazione i requisiti per il 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 OLS.
• Creare e pubblicare indicazioni per gli utenti: creare la documentazione per gli utenti che includono requisiti e preferenze per l'uso della sicurezza a livello di riga e OLS. 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 OLS nei materiali di formazione degli utenti. Fornire esempi per consentire agli utenti di comprendere quando è 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 gli autori di contenuti responsabili della creazione di modelli semantici, flussi di dati, datamarts, report o dashboard.