Pianificazione dell'implementazione di Power BI: Pianificazione della sicurezza degli autori di contenuti

Articolo
11/10/2023

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 gli autori di contenuti responsabili della creazione di modelli semantici (noti in precedenza come set di dati), flussi di dati, datamarts, report o dashboard. È 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 contenuti usati 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 sono creatori di contenuti. Gli autori di contenuti producono e pubblicano contenuti visualizzati da altri utenti. Gli autori di contenuti sono l'obiettivo di questo articolo.

Suggerimento

È consigliabile esaminare prima di tutto l'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti consumer). Descrive le strategie per fornire contenuti in modo sicuro ai consumer di sola lettura, tra cui come applicare la sicurezza dei dati.

Strategia per gli autori di contenuti

La base di un sistema di business intelligence self-service ben governato inizia con creatori e proprietari di contenuti. Creano e convalidano modelli semantici e report. In molti casi, gli autori di contenuti configurano anche le autorizzazioni per gestire la sicurezza per il contenuto.

Suggerimento

È consigliabile promuovere una cultura dei dati che rende la sicurezza e la protezione dei dati una parte normale del ruolo di tutti. Per raggiungere tale obiettivo, l'istruzione degli utenti, il supporto e la formazione sono essenziali.

Ai fini della sicurezza e delle autorizzazioni, considerare che esistono due tipi di creatori di contenuti: creatori di dati e creatori di report. Possono essere responsabili della creazione e della gestione di contenuti bi aziendali o di business intelligence self-service.

Creatori di dati

Un autore di dati è qualsiasi utente di Power BI che crea modelli semantici, flussi di dati o datamarts.

Ecco alcuni scenari comuni di creatore di dati.

Creare un nuovo modello semantico: creare e testare un nuovo modello di dati in Power BI Desktop. Viene quindi pubblicato nel servizio Power BI in modo che possa essere usato come modello semantico condiviso per molti report. Per altre informazioni sul riutilizzo di modelli semantici condivisi, vedere lo scenario di utilizzo di BUSINESS intelligence self-service gestito.
Estendere e personalizzare un modello semantico: creare una connessione dinamica a un modello semantico condiviso esistente in Power BI Desktop. Convertire la connessione dinamica in un modello locale, che consente di estendere la progettazione del modello con nuove tabelle o colonne. Per altre informazioni sull'estensione e la personalizzazione di modelli semantici condivisi, vedere lo scenario di utilizzo di business intelligence self-service gestito personalizzabile.
Creare un nuovo flusso di dati: nella servizio Power BI creare un nuovo flusso di dati in modo che possa essere usato come origine da molti modelli semantici. Per altre informazioni sul riutilizzo delle attività di preparazione dei dati, vedere lo scenario di utilizzo della preparazione dei dati self-service.
Creare un nuovo datamart. Nella servizio Power BI creare un nuovo datamart.

I creatori di dati si trovano spesso nei team di business intelligence aziendali e nel Centro di eccellenza (COE). Hanno anche un ruolo fondamentale da svolgere nelle business unit decentralizzate e nei reparti che gestiscono e gestiscono i propri dati.

Per altre considerazioni sulla BI gestita dal business, la BI self-service gestita e la BUSINESS INTELLIGENCE aziendale, vedere l'articolo Proprietà e gestione dei contenuti .

Autori di report

Gli autori di report creano report e dashboard per visualizzare i dati originati da modelli semantici esistenti.

Ecco alcuni scenari comuni dell'autore di report.

Creare un nuovo report, incluso un modello di dati: creare e testare un nuovo report e un nuovo modello di dati in Power BI Desktop. Il file di Power BI Desktop che contiene una o più pagine di report e include un modello di dati viene pubblicato nel servizio Power BI. I nuovi creatori di contenuti usano in genere questo metodo prima di essere consapevoli dell'uso di modelli semantici condivisi. È anche appropriato per casi d'uso ristretti che non necessitano di riutilizzo dei dati.
Creare un report di connessione dinamica: creare un nuovo report di Power BI che si connette a un modello semantico condiviso nella servizio Power BI. Per altre informazioni sul riutilizzo di modelli semantici condivisi, vedere lo scenario di utilizzo di BUSINESS intelligence self-service gestito.
Creare una cartella di lavoro di Excel connessa: creare un nuovo report di Excel che si connette a un modello semantico condiviso nella servizio Power BI. Connessione esperienze excel, anziché download di dati, sono altamente incoraggiate.
Creare un report DirectQuery: creare un nuovo report di Power BI che si connette a un'origine dati supportata in modalità DirectQuery. Una situazione quando questo metodo è utile è quando si vuole sfruttare la sicurezza degli utenti implementata dal sistema di origine.

Gli autori di report si trovano in tutte le business unit dell'organizzazione. In genere sono presenti molti creatori di report in un'organizzazione rispetto ai creatori di dati.

Suggerimento

Anche se non tutti i modelli semantici sono un modello semantico condiviso, vale comunque la pena adottare una strategia di business intelligence self-service gestita. Questa strategia riutilizza i modelli semantici condivisi quando possibile. In questo modo, la creazione di report e la creazione di dati vengono disaccoppiate. Qualsiasi creatore di contenuti di qualsiasi business unit può usare in modo efficace questa strategia.

Autorizzazioni per gli autori

In questa sezione vengono descritte le autorizzazioni più comuni per gli autori di dati e gli autori di report.

Questa sezione non è progettata per essere un elenco completo di tutte le autorizzazioni possibili. È invece destinato a pianificare la strategia per supportare diversi tipi di creatori di contenuti. L'obiettivo deve essere quello di seguire il principio dei privilegi minimi. Questo principio consente autorizzazioni sufficienti per consentire agli utenti di essere produttivi, senza autorizzazioni di over provisioning.

Creazione di nuovo contenuto

Per la creazione di nuovo contenuto sono in genere necessarie le autorizzazioni seguenti.

Autorizzazione	Autore di report	Creatore di modelli semantici	Autore del flusso di dati	Autore datamart
Accesso all'origine dati sottostante
Autorizzazioni di lettura e compilazione del modello semantico
Autorizzazione lettura flusso di dati (quando un flusso di dati viene usato come origine, tramite il ruolo Visualizzatore dell'area di lavoro)
Accesso in cui è archiviato il file originale di Power BI Desktop
Autorizzazione per l'uso di oggetti visivi personalizzati

Autorizzazioni per la pubblicazione del contenuto

Per la pubblicazione del contenuto sono in genere necessarie le autorizzazioni seguenti.

Autorizzazione	Autore di report	Creatore di modelli semantici	Autore del flusso di dati	Autore datamart
Ruolo area di lavoro: Collaboratore, Membro o Amministrazione
Autorizzazione scrittura modello semantico (quando l'utente non appartiene a un ruolo dell'area di lavoro)
Ruolo della pipeline di distribuzione per pubblicare elementi (facoltativo)

Aggiornamento dei dati

Le autorizzazioni seguenti sono in genere necessarie per l'aggiornamento dei dati.

Autorizzazione	Autore di report	Creatore di modelli semantici	Autore del flusso di dati	Autore datamart
Proprietario assegnato (che ha configurato le impostazioni o ha assunto l'elemento)
Accesso all'origine dati sottostante (quando non viene usato un gateway)
Accesso all'origine dati in un gateway (quando l'origine è locale o in una rete virtuale)

Nella parte restante di questo articolo vengono descritte le considerazioni relative alle autorizzazioni dell'autore del contenuto.

Suggerimento

Per le autorizzazioni relative alla visualizzazione del contenuto, vedere l'articolo Pianificazione della sicurezza degli utenti del report.

Elenco di controllo : quando si pianifica la strategia di sicurezza per gli autori di contenuti, le decisioni chiave e le azioni includono:

Determinare chi sono i creatori di dati: assicurarsi di avere familiarità con chi sta creando modelli semantici, flussi di dati e datamarts. Verificare di aver compreso quali sono le loro esigenze prima di avviare le attività di pianificazione della sicurezza.
Determinare chi sono gli autori di report: assicurarsi di avere familiarità con chi sta creando report, dashboard, cartelle di lavoro e scorecard. Verificare di aver compreso quali sono le loro esigenze prima di avviare le attività di pianificazione della sicurezza.

Scoprire il contenuto per i creatori

Gli utenti possono basarsi sull'individuazione dei dati per trovare modelli semantici e datamarts. L'individuazione dei dati è una funzionalità di Power BI che consente agli autori di contenuti di individuare gli asset di dati esistenti, anche quando non dispongono di autorizzazioni per tale contenuto.

L'individuazione dei dati esistenti è utile per:

Autori di report che vogliono usare un modello semantico esistente per un nuovo report.
Autori di report che vogliono eseguire query sui dati da un datamart esistente.
Creatori di modelli semantici che vogliono usare un modello semantico esistente per un nuovo modello composito.

Nota

L'individuazione dei dati in Power BI non è un'autorizzazione di sicurezza dei dati. Si tratta di un'impostazione che consente agli autori di report di leggere i metadati, aiutandoli a individuare i dati e richiedere l'accesso.

È possibile configurare un modello semantico o un datamart come individuabile quando è stato approvato (certificato o alzato di livello). Quando è individuabile, gli autori di contenuti possono trovarli nell'hub dati.

Un creatore di contenuti può anche richiedere l'accesso al modello semantico o al datamart. Essenzialmente, una richiesta di accesso richiede l'autorizzazione di compilazione, necessaria per creare nuovo contenuto in base a esso. Quando si risponde alle richieste di accesso, è consigliabile usare i gruppi anziché i singoli utenti. Per altre informazioni su come usare i gruppi a questo scopo, vedere Richiedere il flusso di lavoro di accesso per i consumer.

Si considerino i tre esempi seguenti.

Il modello semantico Sales Summary è certificato. È l'origine attendibile e autorevole per il rilevamento delle vendite. Molti autori di report self-service in tutta l'organizzazione usano questo modello semantico. Esistono quindi molti report esistenti e modelli compositi basati sul modello semantico. Per incoraggiare altri creatori a trovare e usare il modello semantico, viene impostato come individuabile.
Il modello semantico Inventory Stats è certificato. Si tratta di un'origine attendibile e autorevole per l'analisi dell'inventario. Il modello semantico e i report correlati vengono gestiti e distribuiti dal team di business intelligence aziendale. A causa della progettazione complessa del modello semantico, solo il team di business intelligence aziendale è autorizzato a creare e gestire il contenuto dell'inventario. Poiché l'obiettivo è scoraggiare gli autori di report dall'uso del modello semantico, non è impostato come individuabile.
Il modello semantico Executive Bonuses contiene informazioni estremamente riservate. Le autorizzazioni per visualizzare o aggiornare questo modello semantico sono limitate a pochi utenti. Questo modello semantico non è impostato come individuabile.

Lo screenshot seguente mostra un modello semantico nell'hub dati nel servizio Power BI. In particolare, mostra un esempio di messaggio di accesso alla richiesta per un modello semantico individuabile. Questo messaggio viene visualizzato quando l'utente non ha attualmente accesso. Il messaggio Richiedi accesso è stato personalizzato nelle impostazioni del modello semantico.

Il messaggio di accesso alla richiesta legge: per la segnalazione standard delle vendite di MTD/QTD/YTD, questo modello semantico è l'origine autorevole e certificata. Richiedere l'accesso al modello semantico completando il modulo disponibile in https://COE.contoso.com/RequestAccess. Verrà richiesta una breve motivazione aziendale e anche il responsabile del Centro di Eccellenza dovrà approvare la richiesta. L'accesso verrà controllato ogni sei mesi.

Screenshot del messaggio di accesso alla richiesta nell'hub dati per un modello semantico impostato per essere individuabile.

Nota

Le impostazioni cultura dei dati e la posizione sulla democratizzazione dei dati devono influenzare fortemente se si abilita l'individuazione dei dati. Per altre informazioni sull'individuazione dei dati, vedere lo scenario di utilizzo di business intelligence self-service gestito personalizzabile.

Esistono tre impostazioni del tenant correlate all'individuazione.

L'impostazione Individua tenant del contenuto consente agli amministratori di Power BI di impostare i gruppi di utenti autorizzati a individuare i dati. È destinato principalmente agli autori di report che potrebbero dover individuare modelli semantici esistenti durante la creazione di report. È utile anche per gli autori di modelli semantici che potrebbero cercare dati esistenti che possono usare nello sviluppo di modelli compositi. Sebbene sia possibile impostarlo per gruppi di sicurezza specifici, è consigliabile abilitare l'impostazione per l'intera organizzazione. L'impostazione di individuazione su singoli modelli semantici e flussi di dati controlla ciò che è individuabile. Meno comunemente, è possibile limitare questa funzionalità solo agli autori di contenuti approvati.
L'impostazione Rendi il tenant individuabile del contenuto certificato consente agli amministratori di Power BI di impostare quali gruppi possono impostare il contenuto da individuare (quando hanno anche l'autorizzazione per modificare l'elemento e l'autorizzazione per certificare il contenuto, concesso dall'impostazione tenant di certificazione ). La possibilità di certificare il contenuto deve essere strettamente controllata. Nella maggior parte dei casi, gli stessi utenti autorizzati a certificare il contenuto devono essere autorizzati a impostarlo come individuabile. In alcune situazioni, è possibile limitare questa funzionalità solo agli autori di dati approvati.
L'impostazione Rendi individuabile contenuto alzato di livello consente agli amministratori di Power BI di impostare quali gruppi possono impostare il contenuto come individuabile (quando hanno anche le autorizzazioni per modificare i dati). Poiché la possibilità di alzare di livello il contenuto è aperta a tutti gli autori di contenuti, nella maggior parte dei casi, questa funzionalità deve essere disponibile per tutti gli utenti. Meno comunemente, è consigliabile limitare questa funzionalità solo agli autori di contenuti approvati.

Elenco di controllo : quando si pianifica l'individuazione dei dati per gli autori di contenuti, le decisioni chiave e le azioni includono:

Chiarire le esigenze per l'individuazione dei dati: valutare la posizione dell'organizzazione per incoraggiare gli autori di contenuti a trovare modelli semantici e datamarts esistenti. Quando appropriato, creare criteri di governance sulla modalità di utilizzo dell'individuazione dei dati.
Decidere chi può individuare il contenuto: decidere se un utente di Power BI è autorizzato a individuare il contenuto o se l'individuazione deve essere limitata a determinati gruppi di utenti(ad esempio, un gruppo di autori di contenuti approvati). Impostare l'impostazione Individua tenant del contenuto per allinearsi a questa decisione.
Decidere chi può impostare contenuto certificato da individuare: decidere se un utente di Power BI (che ha l'autorizzazione per modificare il modello semantico o il datamart, nonché l'autorizzazione per certificarla) può impostarlo come individuabile. Impostare l'impostazione Make certified content discoverable tenant (Rendi il contenuto certificato individuabile ) per allinearsi a questa decisione.
Decidere chi può impostare il contenuto alzato di livello in modo che sia individuabile: decidere se un utente di Power BI (che ha l'autorizzazione per modificare il modello semantico o il datamart) può impostarlo come individuabile. Impostare l'impostazione Make promoted content discoverable tenant (Rendi individuabile contenuto alzato di livello) per allinearla a questa decisione.
Includere nella documentazione e nel training per gli autori di modelli semantici: includere linee guida per gli autori di modelli semantici su quando è appropriato usare l'individuazione dei dati per i modelli semantici e i datamarts di cui sono proprietari e gestiti.
Includere nella documentazione e nella formazione per gli autori di report: includere indicazioni per i creatori di contenuti sul funzionamento dell'individuazione dei dati e su cosa possono aspettarsi.

Richiedere il flusso di lavoro di accesso per gli autori

Un utente può richiedere l'accesso al contenuto in due modi.

Per i consumer di contenuto: un utente riceve un collegamento a un report o a un'app esistente nella servizio Power BI. Per visualizzare l'elemento, il consumer può selezionare il pulsante Richiedi accesso . Per altre informazioni, vedere l'articolo Pianificazione della sicurezza degli utenti del report.
Per gli autori di contenuti: l'utente individua un modello semantico o un datamart nell'hub dati. Per creare un nuovo report o un nuovo modello composito in base ai dati esistenti, l'autore del contenuto può selezionare il pulsante Richiedi accesso . Questa esperienza è l'obiettivo di questa sezione.

Per impostazione predefinita, una richiesta di accesso a un modello semantico o a un datamart passa al proprietario. Il proprietario è l'utente che ha pianificato l'ultimo aggiornamento dati o credenziali di input. L'uso di un utente per elaborare le richieste di accesso potrebbe essere accettabile per i modelli semantici del team. Tuttavia, potrebbe non essere pratico o affidabile.

Anziché basarsi su un proprietario, è possibile definire istruzioni personalizzate presentate agli utenti quando richiedono l'accesso a un modello semantico o a un datamart. Le istruzioni personalizzate sono utili quando:

Il modello semantico è impostato come individuabile.
L'approvazione della richiesta di accesso verrà eseguita da un utente diverso dal proprietario dei dati.
È presente un processo esistente che deve essere seguito per le richieste di accesso.
Rilevamento di chi ha richiesto l'accesso, quando e perché è necessario per motivi di controllo o conformità.
La spiegazione è necessaria per richiedere l'accesso e per impostare le aspettative.

Lo screenshot seguente mostra un esempio di configurazione di istruzioni personalizzate visualizzate da un utente quando richiedono l'autorizzazione di compilazione. Le istruzioni personalizzate leggono: per la segnalazione standard delle vendite di MTD/QTD/YTD, questo modello semantico è l'origine autorevole e certificata. Richiedere l'accesso al modello semantico completando il modulo disponibile in https://COE.contoso.com/RequestAccess. Verrà richiesta una breve motivazione aziendale e anche il responsabile del Centro di Eccellenza dovrà approvare la richiesta. L'accesso verrà controllato ogni sei mesi.

Screenshot dell'impostazione di accesso alla richiesta per un modello semantico nel servizio Power BI.

Sono disponibili molte opzioni per creare un modulo. Power Apps e Microsoft Forms sono entrambe opzioni con poco codice e facili da usare. È consigliabile creare un modulo in modo indipendente da un singolo utente. È fondamentale che il modulo venga creato, gestito e monitorato dal team appropriato.

È consigliabile creare informazioni utili per:

Gli autori di contenuti sanno cosa aspettarsi quando richiedono l'accesso.
Proprietari e amministratori dei contenuti in modo che sappiano come gestire le richieste inviate.

Suggerimento

Per altre informazioni sulla risposta alle richieste di accesso in lettura dai consumer, vedere Richiedere il flusso di lavoro di accesso per i consumer. Include anche informazioni sull'uso dei gruppi (invece dei singoli utenti).

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

Chiarire le preferenze per gestire le richieste di accesso: determinare le situazioni in cui è accettabile per l'approvazione del proprietario e quando usare un processo diverso. Quando appropriato, creare criteri di governance sulla modalità di gestione delle richieste di accesso.
Includere nella documentazione e nel training per i creatori di modelli semantici e datamart: includere indicazioni per il modello semantico e gli autori di datamart su come e quando impostare istruzioni personalizzate per le richieste di accesso.
Includere nella documentazione e nella formazione per gli autori di report: includere indicazioni per gli autori di report su ciò che possono aspettarsi quando si richiedono autorizzazioni di compilazione per modelli semantici e datamarts.

Creare e pubblicare contenuto

Questa sezione include gli aspetti di sicurezza che si applicano agli autori di contenuti.

Nota

Per gli utenti che visualizzano report, dashboard e scorecard, vedere l'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti dei report). Anche le considerazioni relative alle autorizzazioni per le app sono descritte in questo articolo.

Ruoli dell'area di lavoro

Concedere l'accesso all'area di lavoro aggiungendo utenti o gruppi (inclusi i gruppi di sicurezza, i gruppi di Microsoft 365 e le liste di distribuzione) ai ruoli dell'area di lavoro. L'assegnazione di utenti ai ruoli dell'area di lavoro consente di specificare le operazioni che possono eseguire con l'area di lavoro e il relativo contenuto.

Nota

Per altre informazioni sulle considerazioni sulla pianificazione dell'area di lavoro, vedere gli articoli sulla pianificazione dell'area di lavoro. Per altre informazioni sui gruppi, vedere l'articolo Pianificazione della sicurezza a livello di tenant.

Poiché lo scopo principale di un'area di lavoro è la collaborazione, l'accesso all'area di lavoro è principalmente rilevante per gli utenti proprietari e la gestione del contenuto. Quando si inizia a pianificare i ruoli dell'area di lavoro, è utile porsi le domande seguenti.

Quali sono le aspettative per il modo in cui si verificherà la collaborazione nell'area di lavoro?
Chi sarà responsabile della gestione del contenuto nell'area di lavoro?
L'intenzione di assegnare singoli utenti o gruppi ai ruoli dell'area di lavoro?

Sono disponibili quattro ruoli dell'area di lavoro di Power BI: Amministrazione, membro, collaboratore e visualizzatore. I primi tre ruoli sono rilevanti per gli autori di contenuti, che creano e pubblicano contenuto. Il ruolo Visualizzatore è rilevante per i consumer di sola lettura.

Le quattro autorizzazioni del ruolo dell'area di lavoro sono annidate. Ciò significa che gli amministratori dell'area di lavoro hanno tutte le funzionalità disponibili per membri, collaboratori e visualizzatori. Analogamente, i membri hanno tutte le funzionalità disponibili per collaboratori e visualizzatori. I collaboratori hanno tutte le funzionalità disponibili per i visualizzatori.

Suggerimento

Vedere la documentazione relativa ai ruoli dell'area di lavoro per informazioni di riferimento autorevoli per ognuno dei quattro ruoli.

Amministratore dell'area di lavoro

Gli utenti assegnati al ruolo Amministrazione diventano amministratori dell'area di lavoro. Possono gestire tutte le impostazioni ed eseguire tutte le azioni, inclusa l'aggiunta o la rimozione di utenti (inclusi altri amministratori dell'area di lavoro).

Gli amministratori dell'area di lavoro possono aggiornare o eliminare l'app Power BI (se presente). Possono, facoltativamente, consentire ai collaboratori di aggiornare l'app per l'area di lavoro. Per altre informazioni, vedere Varianti ai ruoli dell'area di lavoro più avanti in questo articolo.

Suggerimento

Quando si fa riferimento a un amministratore, assicurarsi di chiarire se si sta parlando di un amministratore dell'area di lavoro o di un amministratore a livello di tenant di Power BI.

Prestare attenzione a garantire che solo gli utenti attendibili e affidabili siano amministratori dell'area di lavoro. Un amministratore dell'area di lavoro ha privilegi elevati. Hanno accesso per visualizzare e gestire tutto il contenuto nell'area di lavoro. Possono aggiungere e rimuovere utenti (inclusi altri amministratori) a qualsiasi ruolo dell'area di lavoro. Possono anche eliminare l'area di lavoro.

È consigliabile che siano presenti almeno due amministratori in modo che uno funzioni come backup se l'amministratore primario non sia disponibile. Un'area di lavoro che non dispone di un amministratore è nota come area di lavoro orfana. Lo stato orfano si verifica quando un utente lascia l'organizzazione e non esiste un amministratore alternativo assegnato all'area di lavoro. Per altre informazioni su come rilevare e correggere le aree di lavoro orfane, vedere l'articolo Visualizzare le aree di lavoro.

Idealmente, è consigliabile essere in grado di determinare chi è responsabile del contenuto dell'area di lavoro da chi sono gli amministratori e i membri dell'area di lavoro (e i contatti specificati per l'area di lavoro). Tuttavia, alcune organizzazioni adottano una strategia di gestione e proprietà del contenuto che limita la creazione dell'area di lavoro a utenti o gruppi specifici. In genere hanno un processo di creazione dell'area di lavoro stabilito gestito dal reparto IT. In questo caso, gli amministratori dell'area di lavoro sono il reparto IT anziché gli utenti che creano e pubblicano direttamente il contenuto.

Membro dell'area di lavoro

Gli utenti assegnati al ruolo Membro possono aggiungere altri utenti dell'area di lavoro (ma non amministratori). Possono anche gestire le autorizzazioni per tutto il contenuto nell'area di lavoro.

I membri dell'area di lavoro possono pubblicare o annullare la pubblicazione dell'app per l'area di lavoro, condividere un elemento dell'area di lavoro o l'app e consentire ad altri utenti di condividere gli elementi dell'area di lavoro dell'app.

I membri dell'area di lavoro devono essere limitati agli utenti che devono gestire la creazione del contenuto dell'area di lavoro e pubblicare l'app. In alcuni casi, gli amministratori dell'area di lavoro soddisfano tale scopo, pertanto potrebbe non essere necessario assegnare utenti o gruppi al ruolo Membro. Quando gli amministratori dell'area di lavoro non sono direttamente correlati al contenuto dell'area di lavoro, ad esempio perché il reparto IT gestisce il processo di creazione dell'area di lavoro, i membri dell'area di lavoro potrebbero essere i veri proprietari responsabili del contenuto dell'area di lavoro.

Collaboratore area di lavoro

Gli utenti assegnati al ruolo Collaboratore possono creare, modificare o eliminare il contenuto dell'area di lavoro.

I collaboratori non possono aggiornare l'app Power BI (se esistente per l'area di lavoro) a meno che non sia consentita dall'impostazione dell'area di lavoro. Per altre informazioni, vedere Varianti ai ruoli dell'area di lavoro più avanti in questo articolo.

La maggior parte dei creatori di contenuti nell'organizzazione è collaboratore all'area di lavoro.

Visualizzatore dell'area di lavoro

Gli utenti assegnati al ruolo Visualizzatore possono visualizzare e interagire con tutto il contenuto dell'area di lavoro.

Il ruolo Visualizzatore è rilevante per i consumer di sola lettura per piccoli team e scenari informali. È descritto in modo completo nell'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti dei report).

Considerazioni sulla proprietà dell'area di lavoro

Si consideri un esempio in cui vengono eseguite le azioni seguenti per configurare una nuova area di lavoro.

Ai promotori di Power BI e ai membri satellite specifici del Centro di eccellenza (COE) è stata concessa l'autorizzazione nelle impostazioni del tenant per creare nuove aree di lavoro. Sono stati addestrati nelle strategie e negli standard di denominazione dell'organizzazione del contenuto.
L'utente (creatore di contenuti) invia una richiesta per creare un'area di lavoro per un nuovo progetto che verrà gestito. L'area di lavoro includerà report che tengono traccia dello stato di avanzamento del progetto.
Un campione di Power BI per la business unit riceve la richiesta. Determinano che una nuova area di lavoro è giustificata. Quindi creano un'area di lavoro e assegnano il gruppo di sicurezza dei promotori di Power BI (per la propria business unit) all'area di lavoro Amministrazione ruolo.
Il campione di Power BI assegna l'utente (autore del contenuto) al ruolo Membro dell'area di lavoro.
Assegnare un collega attendibile al ruolo Membro dell'area di lavoro per assicurarsi che sia presente un backup.
Si assegnano altri colleghi al ruolo Collaboratore dell'area di lavoro perché saranno responsabili della creazione del contenuto dell'area di lavoro, inclusi modelli semantici e report.
Il manager viene assegnato al ruolo Visualizzatore dell'area di lavoro perché ha richiesto l'accesso per monitorare lo stato di avanzamento del progetto. Il responsabile vuole esaminare il contenuto nell'area di lavoro prima di pubblicare un'app.
Si assume la responsabilità di gestire altre proprietà dell'area di lavoro, ad esempio descrizione e contatti. Si assume anche la responsabilità di gestire l'accesso all'area di lavoro in modo continuativo.

L'esempio precedente mostra un modo efficace per consentire a una business unit decentralizzata di agire in modo indipendente. Mostra anche il principio dei privilegi minimi.

Per il contenuto regolamentato o il contenuto critico più strettamente gestito, è consigliabile assegnare gruppi anziché singoli account utente ai ruoli dell'area di lavoro. In questo modo, è possibile gestire l'appartenenza al gruppo separatamente dall'area di lavoro. Tuttavia, quando si assegnano gruppi ai ruoli, è possibile che gli utenti diventino assegnati a più ruoli dell'area di lavoro (perché l'utente appartiene a più gruppi). In tal caso, le autorizzazioni effettive sono basate sul ruolo più alto a cui sono assegnati. Per altre considerazioni, vedere Strategia per l'uso dei gruppi.

Quando un'area di lavoro è condivisa da più utenti o team, può rendere complessa la gestione del contenuto. Provare a evitare scenari di proprietà multi-team separando le aree di lavoro. In questo modo, le responsabilità sono chiare e le assegnazioni di ruolo sono semplici da configurare.

Varianti ai ruoli dell'area di lavoro

Esistono due varianti per i quattro ruoli dell'area di lavoro (descritti in precedenza).

Per impostazione predefinita, solo gli amministratori e i membri dell'area di lavoro possono creare, pubblicare e aggiornare l'app per l'area di lavoro. L'opzione Consenti ai collaboratori di aggiornare l'app per questa impostazione dell'area di lavoro è un'impostazione a livello di area di lavoro, che consente agli amministratori dell'area di lavoro di delegare la possibilità di aggiornare l'app per l'area di lavoro ai collaboratori. Tuttavia, i collaboratori non possono pubblicare una nuova app o modificare chi ha l'autorizzazione per modificarla. Questa impostazione è utile quando si desidera che i collaboratori siano in grado di aggiornare l'app (quando ne esiste una per l'area di lavoro), ma non concedere le altre autorizzazioni disponibili ai membri.
L'impostazione Blocca ripubblicare e disabilitare il tenant di aggiornamento dei pacchetti consente solo ai proprietari di modelli semantici di pubblicare gli aggiornamenti. Se abilitata, gli amministratori, i membri e i collaboratori dell'area di lavoro non possono pubblicare le modifiche a meno che non assumano prima il modello semantico come proprietario. Poiché questa impostazione si applica all'intera organizzazione, abilitarla con una misura di cautela perché influisce su tutti i modelli semantici per il tenant. Assicurarsi di comunicare con gli autori di modelli semantici cosa aspettarsi perché modifica il normale comportamento dei ruoli dell'area di lavoro.

Importante

Le autorizzazioni per elemento possono anche essere considerate come override dei ruoli dell'area di lavoro standard. Per altre informazioni sulle autorizzazioni per elemento, vedere l'articolo Pianificazione della sicurezza degli utenti del report.

Elenco di controllo : quando si pianificano i ruoli dell'area di lavoro, le decisioni chiave e le azioni includono:

Creare una matrice di responsabilità: eseguire il mapping di chi deve gestire ogni funzione durante la creazione, la gestione, la pubblicazione, la protezione e il supporto del contenuto. Usare queste informazioni quando si pianificano i ruoli dell'area di lavoro.
Decidere la strategia per assegnare i ruoli dell'area di lavoro per gli autori di contenuti: determinare quali utenti devono essere un amministratore, un membro o un collaboratore e in quali circostanze,ad esempio ruolo di lavoro o area dell'oggetto. Se ci sono mancate corrispondenze che causano problemi di sicurezza, riconsiderare il modo in cui le aree di lavoro potrebbero essere meglio organizzate.
Determinare il modo in cui i gruppi di sicurezza e i singoli utenti devono essere usati per i ruoli dell'area di lavoro: determinare i casi d'uso e gli scopi necessari per usare i gruppi. Specificare quando la sicurezza deve essere applicata usando gli account utente rispetto a quando un gruppo è obbligatorio o preferito.
Fornire indicazioni per gli autori di contenuti sulla gestione dei ruoli dell'area di lavoro: includere la documentazione per gli autori di contenuti su come gestire i ruoli dell'area di lavoro. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.
Configurare e testare le assegnazioni di ruolo dell'area di lavoro: verificare che gli autori di contenuti dispongano delle funzionalità necessarie per la modifica e la pubblicazione del contenuto.

Autorizzazioni per autori di app

Gli autori di contenuti che sono amministratori o membri dell'area di lavoro possono creare e pubblicare un'app Power BI.

Un amministratore dell'area di lavoro può anche specificare un'impostazione nell'area di lavoro che consente ai collaboratori dell'area di lavoro di aggiornare l'app. Si tratta di una variante alla sicurezza dei ruoli dell'area di lavoro perché concede ai collaboratori un'altra autorizzazione che normalmente non avrebbero. Questa impostazione viene impostata in base all'area di lavoro.

Suggerimento

Per altre informazioni sulla distribuzione di contenuto ai consumer di sola lettura, vedere l'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti consumer di report). Questo articolo include informazioni sulle autorizzazioni dell'app per i consumer di app, inclusi i gruppi di destinatari per l'app.

Elenco di controllo : quando si pianificano le autorizzazioni per gli autori di app, le decisioni chiave e le azioni includono:

Decidere la strategia per chi può creare e pubblicare app di Power BI: chiarire chi deve essere autorizzato a creare e pubblicare app di Power BI.
Determinare quando i collaboratori possono aggiornare le app di Power BI: chiarire le situazioni in cui un collaboratore deve essere autorizzato ad aggiornare le app di Power BI. Aggiornare l'impostazione dell'area di lavoro quando è necessaria questa funzionalità.

Autorizzazioni origine dati

Quando un creatore di dati avvia un nuovo progetto, le autorizzazioni necessarie per accedere alle origini dati esterne sono una delle prime considerazioni relative alla sicurezza. Potrebbero anche essere necessarie indicazioni su altre questioni correlate all'origine dati, inclusi i livelli di privacy, le query di database native e i connettori personalizzati.

Accesso all'origine dati

Quando un autore di dati crea un modello semantico, un flusso di dati o un datamart, deve eseguire l'autenticazione con le origini dati per recuperare i dati. In genere, l'autenticazione comporta credenziali utente (account e password), che potrebbero essere per un account del servizio.

In alcuni casi è utile creare account di servizio specifici per l'accesso alle origini dati. Rivolgersi al reparto IT per indicazioni su come usare gli account del servizio nell'organizzazione. Quando sono consentiti, l'uso degli account di servizio può:

Centralizzare le autorizzazioni necessarie per le origini dati.
Ridurre il numero di singoli utenti che necessitano di autorizzazioni per un'origine dati.
Evitare errori di aggiornamento dei dati quando un utente lascia l'organizzazione.

Suggerimento

Se si sceglie di usare gli account di servizio, è consigliabile controllare rigorosamente chi ha accesso alle credenziali. Ruotare le password a intervalli regolari (ad esempio ogni tre mesi) o quando un utente che ha accesso lascia l'organizzazione.

Quando si accede alle origini dati, applicare il principio dei privilegi minimi per garantire che gli utenti (o gli account del servizio) dispongano dell'autorizzazione per leggere solo i dati necessari. Non devono mai disporre dell'autorizzazione per eseguire modifiche ai dati. Gli amministratori di database che creano questi account di servizio devono chiedere informazioni sulle query e sui carichi di lavoro previsti e adottare le misure necessarie per garantire ottimizzazioni adeguate (ad esempio indici) e risorse.

Suggerimento

Se è difficile fornire l'accesso diretto all'origine dati agli autori di dati self-service, è consigliabile usare un approccio indiretto. È possibile creare flussi di dati nella servizio Power BI e consentire agli autori di dati self-service di origine dati da essi. Questo approccio offre i vantaggi aggiuntivi della riduzione del carico di query nell'origine dati e della distribuzione di uno snapshot coerente dei dati. Per altre informazioni, vedere gli scenari di preparazione dei dati self-service e preparazione dei dati avanzata.

Le credenziali (account e password) possono essere applicate in due modi.

Power BI Desktop: le credenziali vengono crittografate e archiviate localmente nel computer utente.
servizio Power BI: Le credenziali vengono crittografate e archiviate in modo sicuro per:
- Modello semantico (quando un gateway dati non è in uso per raggiungere l'origine dati).
- Origine dati del gateway (quando un gateway standard o un servizio gateway di rete virtuale è in uso per raggiungere l'origine dati).

Suggerimento

Quando sono già state immesse le credenziali per un'origine dati del modello semantico, il servizio Power BI associa automaticamente tali credenziali ad altre origini dati del modello semantico quando esiste una corrispondenza esatta di stringa di connessione e nome del database. Sia il servizio Power BI che Power BI Desktop lo rendono simile all'immissione delle credenziali per ogni origine dati. Tuttavia, può applicare le stesse credenziali alle origini dati corrispondenti con lo stesso proprietario. In tal senso, le credenziali del modello semantico hanno come ambito il proprietario.

Le credenziali vengono crittografate e archiviate separatamente dal modello di dati sia in Power BI Desktop che nel servizio Power BI. Questa separazione dei dati presenta i vantaggi di sicurezza seguenti.

Facilita il riutilizzo delle credenziali per più modelli semantici, flussi di dati e datamarts.
Quando un utente analizza i metadati di un modello semantico, non può estrarre le credenziali.
In Power BI Desktop un altro utente non può connettersi all'origine dati originale per aggiornare i dati senza prima applicare le credenziali.

Alcune origini dati supportano l'accesso Single Sign-On (SSO), che può essere impostato quando si immettono le credenziali nella servizio Power BI (per il modello semantico o le origini dati del gateway). Quando si abilita l'accesso SSO, Power BI invia le credenziali dell'utente autenticato all'origine dati. Questa opzione consente a Power BI di rispettare le impostazioni di sicurezza configurate nell'origine dati, ad esempio la sicurezza a livello di riga. L'accesso Single Sign-On è particolarmente utile quando le tabelle nel modello di dati usano la modalità di archiviazione DirectQuery.

Livelli di privacy

I livelli di privacy dei dati specificano i livelli di isolamento che definiscono il grado in cui un'origine dati è isolata da altre origini dati. Se impostata in modo appropriato, assicurano che Power Query trasmetta solo dati compatibili tra origini. Quando Power Query può trasmettere dati tra origini dati, può comportare query più efficienti che riducono il volume di dati inviati a Power BI. Quando non riesce a trasmettere dati tra origini dati, può comportare prestazioni più lente.

Esistono tre livelli di privacy.

Privato: include dati sensibili o riservati che devono essere isolati da tutte le altre origini dati. Questo livello è il più restrittivo. I dati dell'origine dati privata non possono essere condivisi con altre origini dati. Ad esempio, un database delle risorse umane che contiene i valori relativi allo stipendio dei dipendenti deve essere impostato sul livello privacy privato.
Organizzazione: isolato da origini dati pubbliche, ma visibile ad altre origini dati dell'organizzazione. Questo livello è il più comune. I dati dell'origine dati dell'organizzazione possono essere condivisi con origini dati private o altre origini dati dell'organizzazione. La maggior parte dei database operativi interni può essere impostata con il livello di privacy dell'organizzazione.
Pubblico: dati non sensibili che possono essere resi visibili a qualsiasi origine dati. Questo livello è il meno restrittivo. I dati dell'origine dati pubblica possono essere condivisi con qualsiasi altra origine dati. Ad esempio, un report di censimento ottenuto da un sito Web governativo può essere impostato sul livello di privacy Pubblico.

Quando si combinano query da origini dati diverse, è importante impostare i livelli di privacy corretti. Quando i livelli di privacy vengono impostati correttamente, è possibile che i dati di un'origine dati vengano trasmessi a un'altra origine dati per eseguire query sui dati in modo efficiente.

Si consideri uno scenario in cui un creatore di modelli semantici ha due origini dati: una cartella di lavoro di Excel e una tabella in un database SQL di Azure. Vogliono filtrare i dati nella tabella database SQL di Azure usando un valore originato dalla cartella di lavoro di Excel. Il modo più efficiente per generare un'istruzione SQL per il database SQL di Azure consiste nell'applicare una clausola WHERE per eseguire il filtro necessario. Tuttavia, tale istruzione SQL conterrà un predicato di clausola WHERE con un valore originato dalla cartella di lavoro di Excel. Se la cartella di lavoro di Excel contiene dati sensibili, potrebbe rappresentare una violazione della sicurezza perché l'amministratore del database potrebbe visualizzare l'istruzione SQL usando uno strumento di traccia. Sebbene meno efficiente, l'alternativa è che il motore mashup di Power Query scarichi l'intero set di risultati della tabella di database ed esegua il filtro stesso nel servizio Power BI. Questo approccio sarà meno efficiente e lento, ma sicuro.

I livelli di privacy possono essere impostati per ogni origine dati:

Per i modelli di dati in Power BI Desktop.
Per proprietari di modelli semantici nella servizio Power BI (per le origini dati cloud, che non richiedono un gateway).
Per autori e proprietari dell'origine dati del gateway nel servizio Power BI (per le origini dati del gateway).

Importante

I livelli di privacy impostati in Power BI Desktop non vengono trasferiti al servizio Power BI.

È disponibile un'opzione di sicurezza di Power BI Desktop che consente di ignorare i livelli di privacy per migliorare le prestazioni. È possibile usare questa opzione per migliorare le prestazioni delle query durante lo sviluppo di un modello di dati quando non esiste alcun rischio di violazione della sicurezza dei dati (perché si usano dati di sviluppo o test non sensibili). Tuttavia, questa impostazione non viene rispettata dal servizio Power BI.

Per altre informazioni, vedere Livelli di privacy di Power BI Desktop.

Query di database native

Per creare query di Power Query efficienti, è possibile usare una query nativa per accedere ai dati. Una query nativa è un'istruzione scritta in un linguaggio supportato dall'origine dati. Le query native sono supportate solo da origini dati specifiche, che in genere sono database relazionali come database SQL di Azure.

Le query native possono rappresentare un rischio per la sicurezza perché potrebbero eseguire un'istruzione SQL dannosa. Un'istruzione dannosa può eseguire modifiche ai dati o eliminare record di database (quando l'utente dispone delle autorizzazioni necessarie nell'origine dati). Per questo motivo, per impostazione predefinita, le query native richiedono l'approvazione dell'utente per l'esecuzione in Power BI Desktop.

È disponibile un'opzione di sicurezza di Power BI Desktop che consente di disabilitare il requisito di pre-approvazione. È consigliabile lasciare l'impostazione predefinita che richiede l'approvazione dell'utente, soprattutto quando si prevede che il file di Power BI Desktop possa essere aggiornato da altri utenti.

Connettori personalizzati

Gli sviluppatori possono usare Power Query SDK per creare connettori personalizzati. I connettori personalizzati consentono l'accesso a origini dati proprietarie o implementano un'autenticazione specifica con estensioni dati personalizzate. Alcuni connettori personalizzati sono certificati e distribuiti da Microsoft come connettori certificati. I connettori certificati sono stati controllati ed esaminati per assicurarsi che soddisfino determinati requisiti di codice specificati testati e approvati da Microsoft.

È disponibile un'opzione di sicurezza dell'estensione dati di Power BI Desktop che limita l'uso di connettori non certificati. Per impostazione predefinita, viene generato un errore quando viene effettuato un tentativo di caricare un connettore non certificato. Impostando questa opzione per consentire connettori non certificati, i connettori personalizzati verranno caricati senza convalida o avviso.

È consigliabile mantenere il livello di sicurezza dell'estensione dati al livello superiore, impedendo il caricamento di codice non certificato. Tuttavia, potrebbero essere presenti casi in cui si vogliono caricare connettori specifici, ad esempio connettori sviluppati o connettori forniti dall'utente da un consulente attendibile o fornitore al di fuori del percorso di certificazione Microsoft.

Nota

Gli sviluppatori di connettori sviluppati internamente possono eseguire passaggi per firmare un connettore con un certificato, consentendo di usare il connettore senza dover modificare le impostazioni di sicurezza. Per altre informazioni, vedere Connettori di terze parti attendibili.

Elenco di controllo : quando si pianificano le autorizzazioni dell'origine dati, le decisioni chiave e le azioni includono:

Decidere chi può accedere direttamente a ogni origine dati: determinare i creatori di dati autorizzati ad accedere direttamente a un'origine dati. Se esiste una strategia per ridurre il numero di persone con accesso diretto, chiarire qual è l'alternativa preferita (ad esempio usando flussi di dati).
Decidere come accedere alle origini dati: determinare se le singole credenziali utente verranno usate per l'accesso a un'origine dati o se è necessario creare un account del servizio a tale scopo. Determinare quando l'accesso Single Sign-On è appropriato.
Fornire indicazioni per gli autori di modelli semantici sull'accesso alle origini dati: includere la documentazione per gli autori di contenuti su come accedere alle origini dati dell'organizzazione. Pubblicare le informazioni nel portale centralizzato e nel materiale di formazione.
Fornire indicazioni per gli autori di modelli semantici sui livelli di privacy: fornire indicazioni ai creatori di modelli semantici per renderli consapevoli dei livelli di privacy e le relative implicazioni quando si lavora con dati sensibili o riservati. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.
Fornire indicazioni per gli autori di connessioni gateway sui livelli di privacy: fornire indicazioni ai creatori di modelli semantici per renderli consapevoli dei livelli di privacy e delle relative implicazioni quando si lavora con dati sensibili o riservati. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.
Decidere la strategia per l'uso di query di database native: prendere in considerazione la strategia per l'uso di query di database native. Informare gli autori di modelli semantici su come e quando impostare l'opzione query di database native di Power BI Desktop per disabilitare la pre-approvazione quando Power Query esegue query native.
Decidere la strategia per l'uso di connettori personalizzati: prendere in considerazione la strategia per l'uso di connettori personalizzati. Determinare se l'uso di connettori non certificati è giustificato, nel qual caso informare gli autori di modelli semantici su come e quando impostare l'opzione di estensione dati di Power BI Desktop.

Autorizzazioni per creatori di modelli semantici

È possibile assegnare l'autorizzazione per modificare un modello semantico a un utente o a un gruppo in modi diversi.

Ruolo area di lavoro: l'assegnazione a uno dei ruoli dell'area di lavoro consente l'accesso a tutti i modelli semantici nell'area di lavoro. La possibilità di visualizzare o modificare un modello semantico esistente dipende dal ruolo dell'area di lavoro assegnato. Amministrazione istrator, i membri e i collaboratori possono pubblicare o modificare il contenuto all'interno di un'area di lavoro.
Collegamenti di autorizzazione per elemento: se è stato creato un collegamento di condivisione per un report, l'autorizzazione per leggere il modello semantico (e facoltativamente, compilare, scrivere e/o ricondividere) viene concessa indirettamente dal collegamento.
Autorizzazioni di accesso diretto per elemento: è possibile assegnare l'autorizzazione di accesso diretto a un modello semantico specifico.

Nello screenshot seguente si notino le autorizzazioni assegnate al modello semantico di dati di Call Center. Un utente dispone dell'autorizzazione lettura, concessa usando autorizzazioni di accesso diretto per elemento. Gli utenti e i gruppi rimanenti dispongono delle autorizzazioni perché sono assegnati ai ruoli dell'area di lavoro.

Screenshot del servizio Power BI che mostra le autorizzazioni di accesso diretto per un modello semantico per utenti e gruppi.

Suggerimento

L'uso delle autorizzazioni per elemento (collegamenti o accesso diretto) funziona meglio quando l'intenzione è che un utente o un gruppo visualizzi o modifichi un elemento specifico nell'area di lavoro. È più adatto quando l'utente non è autorizzato ad accedere a tutti gli elementi nell'area di lavoro. Nella maggior parte dei casi, è consigliabile progettare le aree di lavoro in modo che la sicurezza sia più semplice da gestire con i ruoli dell'area di lavoro. Evitare di impostare le autorizzazioni per elemento quando possibile.

Autorizzazioni del modello semantico

È possibile assegnare le autorizzazioni del modello semantico seguenti.

Lettura: destinata principalmente ai consumer di report, questa autorizzazione consente a un report di eseguire query sui dati nel modello semantico. Per altre informazioni sulle autorizzazioni per la visualizzazione di contenuto di sola lettura, vedere l'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti dei report).
Compilazione: destinata agli autori di report, questa autorizzazione consente agli utenti di creare nuovi report in base al modello semantico condiviso. Per altre informazioni, vedere la sezione Autorizzazioni autore report più avanti in questo articolo.
Scrittura: destinata agli autori di modelli semantici che creano, pubblicano e gestiscono modelli semantici, questa autorizzazione consente agli utenti di modificare il modello semantico. Questa sezione è descritta più avanti in questa sezione.
Ricondividi: destinata a chiunque disponga dell'autorizzazione esistente per il modello semantico, questa autorizzazione consente agli utenti di condividere il modello semantico con un altro utente. Questa sezione è descritta più avanti in questa sezione.

Un amministratore o un membro dell'area di lavoro può modificare le autorizzazioni per un modello semantico.

Autorizzazione di lettura del modello semantico

L'autorizzazione di lettura del modello semantico è destinata principalmente ai consumer. Questa autorizzazione è necessaria per consentire agli utenti di visualizzare i dati visualizzati nei report. Tenere presente che anche i report basati sul modello semantico devono disporre dell'autorizzazione lettura; in caso contrario, il report non verrà caricato. Per altre informazioni sull'impostazione delle autorizzazioni di lettura del report, vedere l'articolo Pianificare la sicurezza degli utenti del report.

Autorizzazione di compilazione del modello semantico

Oltre all'autorizzazione di lettura del modello semantico, anche gli autori di contenuti necessitano dell'autorizzazione di compilazione del modello semantico. In particolare, l'autorizzazione di compilazione consente agli autori di report di:

Creare nuovi report di Power BI in base al modello semantico.
Connessione al modello semantico usando Analizza in Excel.
Eseguire una query sul modello semantico usando l'endpoint XMLA.
Esportare i dati sottostanti del report di Power BI anziché i dati riepilogati recuperati dall'oggetto visivo.
Creare una connessione DirectQuery a un modello semantico di Power BI. In questo caso, il nuovo modello semantico si connette a uno o più modelli semantici di Power BI esistenti (noti come concatenamento). Per eseguire query su modelli semantici concatenati, l'autore del modello semantico dovrà disporre dell'autorizzazione di compilazione per tutti i modelli semantici upstream. Per altre informazioni, vedere Modelli semantici concatenati più avanti in questo articolo.

È possibile concedere l'autorizzazione di compilazione a un utente o a un gruppo, direttamente o indirettamente, in modi diversi.

Concedere la compilazione direttamente tramite:
- Impostazione delle autorizzazioni del modello semantico nella pagina delle impostazioni del modello semantico nella servizio Power BI.
- Impostazione delle autorizzazioni del modello semantico tramite l'API REST di Power BI.
Concedere la compilazione indirettamente da:
- Condividere un report o un dashboard e impostare l'opzione per concedere l'autorizzazione di compilazione del modello semantico.
- Pubblicazione di un'app Power BI e impostazione dell'opzione avanzata (per un gruppo di destinatari) per concedere l'autorizzazione di compilazione per i modelli semantici correlati.
- Assegnazione di utenti ai ruoli dell'area di lavoro Amministrazione, membro o collaboratore.

L'impostazione dell'autorizzazione di compilazione direttamente per un modello semantico è appropriata quando si vuole gestire la sicurezza in base a un elemento granulare. L'impostazione dell'autorizzazione di compilazione indirettamente è appropriata quando gli utenti che visualizzeranno o useranno il contenuto tramite uno dei metodi indiretti creeranno anche nuovo contenuto.

Suggerimento

Spesso gli utenti che visualizzano un report o un'app Power BI sono diversi dagli utenti che creano nuovo contenuto usando i modelli semantici sottostanti. La maggior parte dei consumer è solo visualizzatori, quindi non è necessario creare nuovi contenuti. È consigliabile informare i creatori di contenuti per concedere il minor numero di autorizzazioni necessarie.

Autorizzazione scrittura modello semantico

In genere, l'impostazione delle autorizzazioni per chi può modificare e gestire modelli semantici verrà eseguita assegnando gli utenti al ruolo dell'area di lavoro Amministrazione, membro o collaboratore. Tuttavia, è anche possibile impostare l'autorizzazione di scrittura per un modello semantico specifico.

È consigliabile usare i ruoli dell'area di lavoro quando possibile perché è il modo più semplice per gestire e controllare le autorizzazioni. Usare le autorizzazioni di scrittura del modello semantico per ogni elemento quando si è scelto di creare meno aree di lavoro e un'area di lavoro contiene modelli semantici per aree di interesse diverse che richiedono una gestione delle autorizzazioni diversa.

Suggerimento

Per indicazioni su come organizzare le aree di lavoro, vedere gli articoli sulla pianificazione dell'area di lavoro.

Autorizzazione di ricondividi modello semantico

L'autorizzazione di ricondivisione del modello semantico consente a un utente con autorizzazione esistente di condividere il modello semantico con altri utenti. È possibile concedere questa autorizzazione quando il contenuto nel modello semantico può essere condiviso liberamente, in base alla discrezione dell'utente.

In molti casi, è consigliabile limitare l'uso dell'autorizzazione Ricondividi per garantire che le autorizzazioni del modello semantico siano controllate attentamente. Ottenere l'approvazione dai proprietari del modello semantico prima di concedere l'autorizzazione di ricondivisione.

Sicurezza dei dati del modello semantico

È 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.

Un creatore di modelli semantici può applicare la sicurezza dei dati in due modi.

La sicurezza a livello di riga consente a un modello di dati di limitare l'accesso a un subset di dati.
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.

L'implementazione di sicurezza a livello di riga e OLS è destinata ai consumer di report. Per altre informazioni, vedere l'articolo Sulla pianificazione della sicurezza degli utenti consumer. Descrive come e quando viene applicata la sicurezza a livello di riga e OLS per i consumer che dispongono dell'autorizzazione di sola visualizzazione per il modello semantico.

Per la sicurezza a livello di riga e OLS destinato ad altri autori di report, vedere sicurezza dei dati nella sezione Autorizzazioni autore report più avanti in questo articolo.

Modelli semantici concatenati

I modelli semantici di Power BI possono connettersi ad altri modelli semantici in un processo noto come concatenamento, ovvero connessioni a modelli semantici upstream. Per altre informazioni, vedere Uso di DirectQuery per i modelli semantici di Power BI e Analysis Services.

L'impostazione del tenant Consenti connessioni DirectQuery ai modelli semantici di Power BI consente agli amministratori di Power BI di configurare i gruppi di creatori di contenuti in grado di creare modelli semantici concatenati. Se non si vuole limitare i creatori di modelli semantici dal concatenamento dei modelli semantici, è possibile lasciare abilitata questa impostazione per l'intera organizzazione e basarsi sull'accesso all'area di lavoro e sulle autorizzazioni del modello semantico. In alcuni casi, è possibile limitare questa funzionalità ai creatori di contenuti approvati.

Nota

In qualità di creatore di modelli semantici, è possibile limitare il concatenamento al modello semantico. Questa operazione viene eseguita abilitando l'opzione Scoraggiare la connessione DirectQuery a questo modello semantico in Power BI Desktop. Per altre informazioni, vedere Gestire le connessioni DirectQuery a un modello semantico pubblicato.

Query dell'API del modello semantico

In alcune situazioni, è possibile eseguire una query DAX usando l'API REST di Power BI. Ad esempio, è possibile eseguire convalide della qualità dei dati. Per altre informazioni, vedere Set di dati - Esecuzione di query.

L'impostazione del tenant dell'API REST Esecuzione query del set di dati consente agli amministratori di Power BI di impostare quali gruppi di utenti possono inviare query DAX usando l'API REST di Power BI. Nella maggior parte dei casi, è possibile lasciare abilitata questa impostazione per l'intera organizzazione e basarsi sull'accesso all'area di lavoro e sulle autorizzazioni del modello semantico. In alcuni casi, è possibile limitare questa funzionalità ai creatori di contenuti approvati.

Elenco di controllo : quando si pianificano le autorizzazioni dell'autore di modelli semantici, le decisioni chiave e le azioni includono:

Decidere la strategia per le autorizzazioni dell'autore di modelli semantici: determinare quali preferenze e requisiti esistono per la gestione della sicurezza per gli autori di modelli semantici. Considerare l'area di interesse e il livello di riservatezza dei dati. Considerare anche chi può assumere la responsabilità di gestire i dati e le autorizzazioni in business unit centralizzate e decentralizzate.
Esaminare il modo in cui i ruoli dell'area di lavoro vengono gestiti per gli autori di modelli semantici: determinare l'impatto sul processo di progettazione dell'area di lavoro. Creare aree di lavoro dati separate per ogni area di interesse in modo da poter gestire più facilmente i ruoli dell'area di lavoro e la sicurezza semantica del modello per ogni area di interesse.
Fornire indicazioni per gli autori di modelli semantici sulla gestione delle autorizzazioni: includere la documentazione per gli autori di modelli semantici su come gestire le autorizzazioni del modello semantico. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.
Decidere chi può usare le connessioni DirectQuery per i modelli semantici di Power BI: decidere se devono essere presenti limitazioni per i creatori di modelli semantici di Power BI (con autorizzazione di compilazione esistente per un modello semantico) possono creare una connessione a un modello semantico di Power BI. Impostare l'impostazione consenti connessioni DirectQuery al tenant dei modelli semantici di Power BI per allinearsi a questa decisione. Se si decide di limitare questa funzionalità, è consigliabile usare un gruppo come gli autori di modelli semantici approvati da Power BI.
Decidere chi può eseguire query sui modelli semantici di Power BI usando l'API REST: decidere se limitare gli autori di contenuti di Power BI a eseguire query sui modelli semantici di Power BI usando l'API REST di Power BI. Impostare l'impostazione del tenant dell'API REST Per l'esecuzione di query del set di dati in modo che sia allineata a questa decisione. Se si decide di limitare questa funzionalità, è consigliabile usare un gruppo come gli autori di report approvati da Power BI.
Decidere la strategia per l'uso di sicurezza a livello di riga o OLS per creatori di modelli semantici: considerare i casi d'uso e gli scopi che si intende usare la sicurezza a livello di riga o OLS. Fattore nella strategia di progettazione dell'area di lavoro e chi ha autorizzazioni di lettura e modifica, quando si vuole applicare la sicurezza a livello di riga o OLS per gli autori di modelli semantici.

Autorizzazioni autore report

Gli autori di report devono avere accesso all'area di lavoro per creare report nel servizio Power BI o pubblicarli da Power BI Desktop. Devono essere un amministratore, un membro o un collaboratore nell'area di lavoro di destinazione.

Quando possibile, gli autori di report devono usare un modello semantico condiviso esistente (tramite una connessione dinamica o DirectQuery). In questo modo, il processo di creazione del report viene separato dal processo di creazione del modello semantico. Questo tipo di separazione offre molti vantaggi per gli scenari di sicurezza e sviluppo del team.

Un autore di report deve essere un amministratore, un membro o un collaboratore dell'area di lavoro.

A differenza dei modelli semantici, non esiste un'autorizzazione di scrittura per i report. Per supportare gli autori di report, è necessario usare i ruoli dell'area di lavoro. Per questo motivo, la progettazione ottimale dell'area di lavoro è importante per bilanciare le esigenze di sicurezza e organizzazione del contenuto.

Suggerimento

Per le autorizzazioni per supportare i consumer di report (incluse le autorizzazioni lettura e ricondivisione per elemento), vedere l'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti consumer di report).

Autorizzazioni di lettura e compilazione per il modello semantico sottostante

Gli autori di report devono disporre delle autorizzazioni lettura e compilazione per i modelli semantici che verranno usati dai report, inclusi i modelli semantici concatenati. Tale autorizzazione può essere concessa in modo esplicito sui singoli modelli semantici oppure può essere concessa in modo implicito per i modelli semantici dell'area di lavoro quando l'autore del report è un amministratore, un membro o un collaboratore dell'area di lavoro.

L'impostazione Usa modelli semantici nei tenant delle aree di lavoro consente agli amministratori di Power BI di configurare i gruppi di utenti che possono creare report che usano modelli semantici situati in altre aree di lavoro. Questa impostazione è destinata ai creatori di modelli semantici e report. In genere, è consigliabile lasciare abilitata questa impostazione per l'intera organizzazione e basarsi sulle impostazioni di accesso all'area di lavoro e sulle autorizzazioni del modello semantico. In questo modo, è possibile incoraggiare l'uso di modelli semantici esistenti. In alcuni casi, è possibile limitare questa funzionalità solo agli autori di contenuti approvati.

È disponibile anche l'impostazione Consenti connessioni dinamiche, che consente agli amministratori di Power BI di configurare i gruppi di utenti che possono creare connessioni dinamiche a modelli semantici in Power BI Desktop o Excel. È destinato in modo specifico agli autori di report e richiede anche che venga concessa l'autorizzazione lettura e compilazione per il modello semantico che verrà usato dal report. È consigliabile lasciare abilitata questa impostazione per l'intera organizzazione e basarsi sull'accesso all'area di lavoro e sulle autorizzazioni del modello semantico. In questo modo, è possibile incoraggiare l'uso di modelli semantici esistenti. In alcuni casi, è possibile limitare questa funzionalità solo agli autori di contenuti approvati.

Sicurezza dei dati per il modello semantico sottostante

La sicurezza a livello di riga e OLS (descritta in precedenza in questo articolo) è destinata ai consumer di report. Tuttavia, a volte deve essere applicato anche per gli autori di report. La creazione di aree di lavoro separate è giustificato quando è necessario applicare la sicurezza a livello di riga per gli autori di report e anche per i consumer di report.

Si consideri il seguente scenario.

Modelli semantici condivisi centralizzati con la sicurezza a livello di riga: il team di business intelligence aziendale ha pubblicato modelli semantici di vendita nell'area di lavoro Sales Data . Questi modelli semantici applicano la sicurezza a livello di riga per visualizzare i dati di vendita per l'area di vendita assegnata del consumer di report.
Creatori di report self-service decentralizzati: la business unit sales e marketing ha molti analisti in grado di creare report personalizzati. Pubblicano i report nell'area di lavoro Sales Analytics .
Autorizzazioni di lettura e compilazione per i modelli semantici: quando possibile, gli analisti usano i modelli semantici dell'area di lavoro Sales Data per evitare la duplicazione non necessaria dei dati. Poiché gli analisti dispongono solo delle autorizzazioni lettura e compilazione per questi modelli semantici (senza autorizzazioni di scrittura o modifica), la sicurezza a livello di riga viene applicata agli autori di report (e anche ai consumer di report).
Autorizzazioni di modifica per l'area di lavoro per la creazione di report: gli analisti hanno più diritti nell'area di lavoro Sales Analytics . I ruoli dell'area di lavoro amministratore, membro o collaboratore consentono loro di pubblicare e gestire i report.

Per altre informazioni sulla sicurezza a livello di riga e su OLS, vedere l'articolo Pianificazione della sicurezza degli utenti del report. Descrive come e quando viene applicata la sicurezza a livello di riga e OLS per i consumer che dispongono dell'autorizzazione di sola visualizzazione per il modello semantico.

Connessione ing a modelli semantici esterni

Quando un autore di report si connette a un modello semantico condiviso per il report, in genere si connette a un modello semantico condiviso pubblicato nel proprio tenant di Power BI. Quando è stata concessa l'autorizzazione, è anche possibile connettersi a un modello semantico condiviso in un altro tenant. L'altro tenant può essere un partner, un cliente o un fornitore.

Questa funzionalità è nota come condivisione di modelli semantici sul posto (nota anche come condivisione di modelli semantici tra tenant). I report creati dall'autore del report (o nuovi modelli compositi creati da un creatore di modelli semantici) vengono archiviati e protetti nel tenant di Power BI usando il processo normale. Il modello semantico condiviso originale rimane nel tenant originale di Power BI e tutte le autorizzazioni vengono gestite in tale tenant.

Per altre informazioni, vedere l'articolo Pianificazione della sicurezza a livello di tenant. Include informazioni sulle impostazioni del tenant e sulle impostazioni del modello semantico che rendono funzionante la condivisione esterna.

Tabelle in primo piano

In Power BI Desktop gli autori di modelli semantici possono impostare una tabella modello per diventare una tabella in primo piano. Quando il modello semantico viene pubblicato nella servizio Power BI, gli autori di report possono usare la raccolta tipi di dati in Excel per trovare la tabella in primo piano, consentendo loro di aggiungere dati di tabella in primo piano per aumentare i fogli di lavoro di Excel.

L'impostazione Consenti connessioni alle tabelle in primo piano consente agli amministratori di Power BI di configurare i gruppi di utenti che possono accedere alle tabelle in primo piano. È destinato agli utenti di Excel che vogliono accedere alle tabelle in primo piano di Power BI nei tipi di dati dell'organizzazione di Excel. È consigliabile lasciare abilitata questa impostazione per l'intera organizzazione e basarsi sull'accesso all'area di lavoro e sulle autorizzazioni del modello semantico. In questo modo, è possibile incoraggiare l'uso di tabelle in primo piano.

Autorizzazioni per oggetti visivi personalizzati

Oltre agli oggetti visivi principali, gli autori di report di Power BI possono usare oggetti visivi personalizzati. In Power BI Desktop gli oggetti visivi personalizzati possono essere scaricati da Microsoft AppSource. Possono anche essere sviluppati internamente usando Power BI SDK e installati aprendo il file visivo (pbviz).

Alcuni oggetti visivi disponibili per il download da AppSource sono oggetti visivi certificati. Gli oggetti visivi certificati soddisfano determinati requisiti di codice specificati testati e approvati dal team di Power BI. I test verificano che gli oggetti visivi non accungono a servizi o risorse esterni.

L'impostazione Consenti oggetti visivi creati dal tenant di Power BI SDK consente agli amministratori di Power BI di controllare quali gruppi di utenti possono usare oggetti visivi personalizzati.

È anche disponibile l'impostazione Aggiungi e usa oggetti visivi certificati solo tenant, che consente agli amministratori di Power BI di bloccare l'uso di oggetti visivi non certificati nella servizio Power BI. Questa impostazione può essere abilitata o disabilitata per l'intera organizzazione.

Nota

Se si blocca l'uso di oggetti visivi non certificati, si applica solo al servizio Power BI. Se si vuole limitare l'uso in Power BI Desktop, chiedere agli amministratori di sistema di usare un'impostazione di Criteri di gruppo per bloccare l'uso in Power BI Desktop. Se si esegue questo passaggio, gli autori di report non sprecano tempo e sforzi per creare un report che non funzionerà quando pubblicato nel servizio Power BI. È consigliabile configurare gli utenti per avere esperienze coerenti nel servizio Power BI (con l'impostazione del tenant) e Power BI Desktop (con Criteri di gruppo).

Power BI Desktop offre un'opzione per visualizzare un avviso di sicurezza quando un autore di report aggiunge un oggetto visivo personalizzato al report. Gli autori di report possono disabilitare questa opzione. Questa opzione non verifica se l'oggetto visivo è certificato.

Gli amministratori di Power BI possono approvare e distribuire oggetti visivi personalizzati per l'organizzazione. Gli autori di report possono quindi individuare, aggiornare e usare facilmente questi oggetti visivi. Amministrazione istrator può quindi gestire questi oggetti visivi aggiornando le versioni o disabilitando e abilitando oggetti visivi personalizzati specifici. Questo approccio è utile quando si vuole rendere disponibile agli autori di report un oggetto visivo sviluppato internamente o quando si acquisisce un oggetto visivo personalizzato da un fornitore che non si trova in AppSource. Per altre informazioni, vedere Oggetti visivi dell'organizzazione di Power BI.

Prendere in considerazione una strategia bilanciata per abilitare solo oggetti visivi personalizzati certificati nell'organizzazione (con l'impostazione del tenant e i criteri di gruppo descritti in precedenza), durante la distribuzione di oggetti visivi aziendali per gestire eventuali eccezioni.

Elenco di controllo : quando si pianificano le autorizzazioni per l'autore di report, le decisioni chiave e le azioni includono:

Decidere la strategia per le autorizzazioni dell'autore di report: determinare quali preferenze e requisiti esistono per la gestione della sicurezza per gli autori di report. Considerare l'area di interesse e il livello di riservatezza dei dati. Considerare anche chi può assumere la responsabilità di creare e gestire report in business unit centralizzate e decentralizzate.
Esaminare il modo in cui i ruoli dell'area di lavoro vengono gestiti per gli autori di report: determinare l'impatto sul processo di progettazione dell'area di lavoro. Creare aree di lavoro dati e aree di lavoro di report separate per ogni area di interesse, in modo che i ruoli dell'area di lavoro (e la sicurezza del modello semantico sottostante) siano semplificati per l'area di interesse.
Fornire indicazioni per gli autori di report sulla gestione delle autorizzazioni: includere la documentazione per gli autori di report su come gestire le autorizzazioni per i consumer di report. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.
Decidere chi può usare modelli semantici condivisi: decidere se devono essere presenti limitazioni per i creatori di report di Power BI (che dispongono già delle autorizzazioni lettura e compilazione per un modello semantico) possono usare modelli semantici tra aree di lavoro. Impostare l'impostazione Usa modelli semantici tra i tenant delle aree di lavoro per allinearsi a questa decisione. Se si decide di limitare questa funzionalità, è consigliabile usare un gruppo come gli autori di report approvati da Power BI.
Decidere chi può usare le connessioni dinamiche: decidere se devono essere presenti limitazioni per i creatori di report di Power BI (che dispongono già dell'autorizzazione Lettura e compilazione per un modello semantico) possono usare le connessioni dinamiche. Impostare l'impostazione Consenti connessioni dinamiche del tenant per allinearsi a questa decisione. Se si decide di limitare questa funzionalità, è consigliabile usare un gruppo come gli autori di report approvati da Power BI.
Decidere la strategia per l'uso della sicurezza a livello di riga per gli autori di report: prendere in considerazione i casi d'uso e gli scopi che si intende usare per la sicurezza a livello di riga. Fattore nella strategia di progettazione dell'area di lavoro per garantire che la sicurezza a livello di riga venga applicata per gli autori di report.
Decidere la strategia per l'uso di oggetti visivi personalizzati: prendere in considerazione la strategia per cui gli autori di report possono usare oggetti visivi personalizzati. Impostare l'impostazione Consenti oggetti visivi creati dal tenant di Power BI SDK per allinearsi a questa decisione. Creare un processo per l'uso di oggetti visivi dell'organizzazione, se appropriato.

Autorizzazioni autore del flusso di dati

I flussi di dati sono utili per centralizzare la preparazione dei dati in modo che il lavoro svolto in Power Query non venga ripetuto in molti modelli semantici. Si tratta di un blocco predefinito per ottenere una singola fonte di verità, impedendo agli analisti di richiedere l'accesso diretto alle origini e di contribuire a eseguire operazioni di estrazione, trasformazione e caricamento (ETL) su larga scala.

Un creatore di flussi di dati deve essere un amministratore, un membro o un collaboratore dell'area di lavoro.

Per utilizzare un flusso di dati (ad esempio, da un nuovo modello di dati creato in Power BI Desktop o in un'altra area di lavoro), un creatore di modelli semantici può appartenere a qualsiasi ruolo dell'area di lavoro, incluso il ruolo Visualizzatore. Non esiste alcun concetto di sicurezza a livello di riga per i flussi di dati.

Oltre ai ruoli dell'area di lavoro, è necessario abilitare l'impostazione Del tenant Crea e usa flussi di dati. Questa impostazione del tenant si applica all'intera organizzazione.

Si consideri il seguente scenario.

Molti modelli semantici nell'organizzazione devono applicare la sicurezza a livello di riga dinamica. Richiede che i nomi dell'entità utente (UPN) siano archiviati nel modello semantico (per filtrare in base all'identità del consumer di report).
Un creatore di flussi di dati, che appartiene al reparto Risorse umane, crea un flusso di dati dei dettagli correnti dei dipendenti, inclusi i relativi UPN. Configurano il flusso di dati per l'aggiornamento giornaliero.
Gli autori di modelli semantici usano quindi il flusso di dati nelle progettazioni dei modelli per configurare la sicurezza a livello di riga.

Per altre informazioni sull'uso dei flussi di dati, vedere gli scenari di preparazione dei dati self-service e preparazione avanzata dei dati .

Elenco di controllo : quando si pianificano le autorizzazioni dell'autore del flusso di dati, le decisioni chiave e le azioni includono:

Decidere la strategia per le autorizzazioni dell'autore del flusso di dati: determinare quali preferenze e requisiti esistono per la gestione della sicurezza per gli autori di flussi di dati. Considerare chi è autorizzato, o incoraggiato, a prendere la responsabilità di gestire le attività di preparazione dei dati in business unit centralizzate e decentralizzate.
Decidere chi può creare flussi di dati: decidere se devono essere presenti limitazioni per cui gli autori di dati di Power BI possono creare flussi di dati. Impostare l'impostazione Create and use dataflows tenant (Crea e usa il tenant dei flussi di dati) per allinearla a questa decisione.
Esaminare il modo in cui i ruoli dell'area di lavoro vengono gestiti per gli autori di flussi di dati: determinare l'impatto sul processo di progettazione dell'area di lavoro. Creare aree di lavoro del flusso di dati separate per ogni area di interesse in modo da poter gestire separatamente i ruoli e le autorizzazioni dell'area di lavoro per ogni area dell'oggetto, se appropriato.

Autorizzazioni autore datamart

Un datamart è una soluzione di analisi self-service che consente agli utenti di archiviare ed esplorare i dati caricati in un database relazionale completamente gestito. Comprende anche un modello semantico generato automaticamente.

I datamarts offrono un'esperienza semplice a basso codice per inserire dati da origini dati diverse e per estrarre, trasformare e caricare i dati usando Power Query Online. I dati vengono caricati in un database SQL di Azure completamente gestito e non richiede alcuna ottimizzazione o ottimizzazione. Il modello semantico generato automaticamente viene sempre sincronizzato con il database gestito perché è in modalità DirectQuery.

È possibile creare un datamart quando si è un amministratore, un membro o un collaboratore dell'area di lavoro. I ruoli dell'area di lavoro vengono mappati anche ai ruoli a livello di database nella database SQL di Azure, tuttavia, poiché il database è completamente gestito, le autorizzazioni utente non possono essere modificate o gestite nel database relazionale.

L'impostazione Crea tenant di datamarts consente agli amministratori di Power BI di configurare i gruppi di utenti che possono creare datamarts.

Per i datamarts, il termine sharing assume un significato diverso da quello di altri tipi di contenuto di Power BI. In genere, un'operazione di condivisione è destinata a un consumer perché fornisce l'autorizzazione di sola lettura a un elemento, ad esempio un report.

La condivisione di un datamart è destinata ai creatori di contenuti (anziché ai consumer). Concede le autorizzazioni Lettura e Compilazione, che consente agli utenti di eseguire query sul modello semantico o sul database relazionale, indipendentemente dalla preferenza.

La condivisione di un datamart consente agli autori di contenuti di:

Creare contenuto usando il modello semantico generato automaticamente: il modello semantico è il livello semantico in cui è possibile compilare i report di Power BI. La maggior parte degli autori di report deve usare il modello semantico.
Connessione a ed eseguire query sul database SQL di Azure: il database relazionale è utile per gli autori di contenuti che vogliono creare nuovi modelli semantici o report impaginati. Possono scrivere query SQL (Structured Query Language) per recuperare i dati usando l'endpoint SQL.

Sicurezza a livello di riga datamart

È possibile definire la sicurezza a livello di riga per i datamarts per limitare l'accesso ai dati per gli utenti specificati. La sicurezza a livello di riga viene configurata nell'editor datamart nella servizio Power BI e viene applicata automaticamente al modello semantico generato automaticamente e al database SQL di Azure (come regole di sicurezza).

Indipendentemente dal modo in cui un utente sceglie di connettersi al datamart (al modello semantico o al database), vengono applicate autorizzazioni identiche per la sicurezza a livello di riga.

Elenco di controllo : quando si pianificano le autorizzazioni per l'autore di datamart, le decisioni chiave e le azioni includono:

Decidere la strategia per le autorizzazioni autore di datamart: determinare quali preferenze e requisiti esistono per la gestione della sicurezza per gli autori di datamart. Considerare chi è autorizzato, o incoraggiato, a prendere la responsabilità di gestire i dati in business unit centralizzate e decentralizzate.
Decidere chi può creare i datamarts: decidere se devono essere presenti limitazioni per cui gli autori di dati di Power BI possono creare un datamart. Impostare l'impostazione Create datamarts tenant (Crea tenant datamarts ) per allinearla a questa decisione. Se si decide di limitare chi può creare datamarts, prendere in considerazione l'uso di un gruppo come gli autori di datamart approvati da Power BI.
Esaminare il modo in cui i ruoli dell'area di lavoro vengono gestiti per i creatori di datamart: determinare l'impatto sul processo di progettazione dell'area di lavoro. Creare aree di lavoro dati separate per ogni area di interesse in modo che i ruoli dell'area di lavoro e la sicurezza semantica del modello possano essere semplificati per l'area di interesse.
Fornire indicazioni per gli autori di datamart sulla gestione delle autorizzazioni: includere la documentazione per gli autori di datamart su come gestire le autorizzazioni di datamart. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.
Decidere la strategia per l'uso della sicurezza a livello di riga in datamarts: considerare quali casi d'uso e scopi si intende usare la sicurezza a livello di riga all'interno di un datamart.

Autorizzazioni autore scorecard

Le metriche in Power BI consentono di curare metriche specifiche e monitorarle in base agli obiettivi aziendali chiave. Le metriche vengono aggiunte alle scorecard, che possono essere condivise con altri utenti e visualizzate in un unico riquadro.

Le scorecard possono essere protette con tre livelli di autorizzazioni:

Area di lavoro.
Autorizzazioni scorecard (per elemento).
Metriche (all'interno della scorecard).

Un utente che crea o gestisce completamente una scorecard deve essere un amministratore, un membro o un collaboratore dell'area di lavoro.

Poiché le metriche spesso si estendono su più aree di interesse, è consigliabile creare un'area di lavoro separata in modo da poter gestire in modo indipendente le autorizzazioni per autori e consumer.

L'impostazione Crea e usa tenant delle metriche consente agli amministratori di Power BI di configurare i gruppi di utenti che possono creare metriche scorecard.

Autorizzazioni scorecard

È possibile assegnare le autorizzazioni scorecard seguenti.

Lettura: questa autorizzazione consente a un utente di visualizzare la scorecard.
Ricondividi: destinata a chiunque disponga dell'autorizzazione esistente per la scorecard, questa autorizzazione consente agli utenti di condividere la scorecard con un altro utente.

Coerentemente con altri tipi di contenuto nella servizio Power BI, le autorizzazioni per elemento sono utili quando l'intenzione è condividere un elemento con un altro utente. È consigliabile usare i ruoli dell'area di lavoro e le autorizzazioni dell'app quando possibile.

Autorizzazioni a livello di metrica

Ogni scorecard ha un set di autorizzazioni a livello di metrica che è possibile configurare nelle impostazioni scorecard. Le autorizzazioni a livello di metrica (all'interno di una scorecard) possono essere concesse in modo diverso rispetto all'area di lavoro o alle autorizzazioni scorecard (per elemento).

I ruoli a livello di metrica consentono di impostare:

Chi può visualizzare le singole metriche in una scorecard.
Chi può aggiornare le singole metriche in base a:
- Aggiornamento dello stato durante un'archiviazione.
- Aggiunta di note durante un'archiviazione.
- Aggiornamento del valore corrente durante un'archiviazione.

Per ridurre il livello di manutenzione futura, è possibile impostare le autorizzazioni predefinite che verranno ereditate dalle sottometriche create in futuro.

Elenco di controllo : quando si pianificano le autorizzazioni dell'autore delle metriche, le decisioni chiave e le azioni includono:

Decidere la strategia per le autorizzazioni dell'autore di scorecard: determinare quali preferenze e requisiti esistono per la gestione della sicurezza per gli autori di scorecard. Considerare chi è autorizzato, o incoraggiato, a prendere la responsabilità di gestire i dati in business unit centralizzate e decentralizzate.
Decidere chi può creare scorecard: decidere se devono essere presenti limitazioni per cui gli autori di dati di Power BI possono creare scorecard. Impostare l'impostazione Create and use Metrics tenant (Crea e usa tenant metriche) per allinearla a questa decisione. Se si decide di limitare chi può creare scorecard, prendere in considerazione l'uso di un gruppo come gli autori di scorecard approvati da Power BI.
Esaminare il modo in cui i ruoli dell'area di lavoro vengono gestiti per gli autori di scorecard: determinare l'impatto sul processo di progettazione dell'area di lavoro. È consigliabile creare aree di lavoro separate per le scorecard quando il contenuto si estende su aree di interesse.
Fornire indicazioni per gli autori di scorecard sulla gestione delle autorizzazioni: includere la documentazione per gli autori di scorecard su come gestire le autorizzazioni a livello di metrica. Pubblicare queste informazioni nel portale centralizzato e nel materiale di formazione.

Pubblicazione di contenuto

Questa sezione include argomenti relativi alla pubblicazione di contenuti rilevanti per gli autori di contenuti.

Aree di lavoro

Gli autori di contenuti dovranno disporre dell'accesso al ruolo di amministratore, membro o collaboratore per pubblicare il contenuto in un'area di lavoro. Per altre informazioni, vedere i ruoli dell'area di lavoro descritti in precedenza in questo articolo.

Ad eccezione della BI personale, gli autori di contenuti devono essere incoraggiati a pubblicare contenuto in aree di lavoro standard, anziché nell'area di lavoro personale.

L'impostazione Blocca ripubblicare e disabilitare il tenant di aggiornamento del pacchetto modifica il comportamento per la pubblicazione di modelli semantici. Se abilitata, gli amministratori, i membri o i collaboratori dell'area di lavoro non possono pubblicare modifiche in un modello semantico. Solo il proprietario del modello semantico è autorizzato a pubblicare un aggiornamento (forzando l'acquisizione di un modello semantico prima di pubblicare un modello semantico aggiornato). Poiché questa impostazione del tenant si applica all'intera organizzazione, abilitarla con una misura di cautela perché influisce su tutti i modelli semantici per l'intero tenant. Assicurarsi di comunicare con gli autori di modelli semantici cosa aspettarsi perché modifica il normale comportamento dei ruoli dell'area di lavoro.

Sincronizzazione di Power Apps

È possibile creare una soluzione Power Apps che include report di Power BI incorporati. Il processo di Power Apps creerà automaticamente un'area di lavoro power BI dedicata per l'archiviazione e la protezione dei report e dei modelli semantici di Power BI. Per gestire gli elementi presenti sia in Power Apps che in Power BI, è presente un processo di sincronizzazione.

Il processo sincronizza i ruoli di sicurezza per assicurarsi che Power BI erediti gli stessi ruoli inizialmente configurati in Power Apps. Consente inoltre all'autore del contenuto di gestire le autorizzazioni per chi può visualizzare i report di Power BI (e i modelli semantici correlati) incorporati in un'app power.

Per altre informazioni sulla sincronizzazione dei ruoli di Power Apps con i ruoli dell'area di lavoro di Power BI, vedere Sincronizzazione delle autorizzazioni tra l'ambiente Power Apps e l'area di lavoro di Power BI.

Accesso alla pipeline di distribuzione

Gli autori di contenuti e i proprietari possono usare le pipeline di distribuzione di Power BI per la pubblicazione di contenuto self-service. Le pipeline di distribuzione semplificano il processo di pubblicazione e migliorano il livello di controllo durante il rilascio di nuovi contenuti.

È possibile gestire le autorizzazioni della pipeline (per gli utenti che possono distribuire contenuto con una pipeline di distribuzione) separatamente dai ruoli dell'area di lavoro. L'accesso all'area di lavoro e alla pipeline di distribuzione è necessario per gli utenti che eseguono una distribuzione.

I creatori di contenuti potrebbero anche avere bisogno di:

Autorizzazioni di creazione dell'area di lavoro (quando le aree di lavoro devono essere create dalla pipeline).
Autorizzazioni di capacità Premium o Infrastruttura (quando le aree di lavoro vengono assegnate dalla pipeline).

Importante

A volte questo articolo si riferisce a Power BI Premium o alle relative sottoscrizioni di capacità (SKU P). Tenere presente che Microsoft sta attualmente consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti devono invece prendere in considerazione l'acquisto di sottoscrizioni della capacità di Fabric (SKU F).

Per altre informazioni, vedere Aggiornamenti importanti in arrivo per le licenze di Power BI Premium e Domande frequenti su Power BI Premium.

Per altre informazioni, vedere Accesso alla pipeline di distribuzione.

Endpoint XMLA

L'endpoint XMLA usa il protocollo XMLA per esporre tutte le funzionalità di un modello di dati tabulare, incluse alcune operazioni di modellazione dei dati non supportate da Power BI Desktop. È possibile usare l'API TOM (Tabular Object Model) per apportare modifiche a livello di codice a un modello di dati.

L'endpoint XMLA fornisce anche la connettività. È possibile connettersi a un modello semantico solo quando l'area di lavoro ha la modalità di licenza impostata su Premium per utente, Premium per capacità o Embedded. Una volta stabilita una connessione, uno strumento conforme a XMLA può operare sul modello di dati per leggere o scrivere dati. Per altre informazioni su come usare l'endpoint XMLA per la gestione di un modello semantico, vedere lo scenario di utilizzo avanzato della gestione dei modelli di dati.

L'accesso tramite l'endpoint XMLA rispetta le autorizzazioni esistenti. Gli amministratori, i membri e i collaboratori dell'area di lavoro dispongono implicitamente dell'autorizzazione di scrittura del modello semantico, ovvero possono distribuire nuovi modelli semantici da Visual Studio ed eseguire script TMSL (Tabular Modeling Scripting Language) in SQL Server Management Studio (SSMS).

Gli utenti con l'autorizzazione di compilazione del modello semantico possono usare l'endpoint XMLA per connettersi e esplorare modelli semantici per l'utilizzo e la visualizzazione dei dati. Le regole di sicurezza a livello di riga vengono rispettate e gli utenti non possono visualizzare i metadati interni del modello semantico.

L'impostazione tenant Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali fa riferimento a due funzionalità: controlla quali gruppi di utenti possono usare l'endpoint XMLA per eseguire query e/o gestire modelli semantici nel servizio Power BI. Determina inoltre se Analizzare in Excel può essere usato con modelli di SQL Server Analysis Services (SSAS) locali.

Nota

L'impostazione Analizza in Excel di tale tenant si applica solo ai modelli di SQL Server Analysis Services (SSAS) locali. La funzionalità Analizza in Excel standard, che si connette a un modello semantico di Power BI nella servizio Power BI, è controllata dall'impostazione del tenant Consenti Connessione ions live.

Pubblica sul Web

La pubblicazione sul Web è una funzionalità che consente l'accesso ai report di Power BI a chiunque su Internet. Non richiede l'autenticazione e l'accesso non viene registrato a scopo di controllo. Poiché gli utenti dei report non devono necessariamente appartenere all'organizzazione o disporre di una licenza Power BI, questa tecnica è particolarmente adatta al data journalism, un processo in cui i report sono incorporati in post di blog, siti Web, messaggi di posta elettronica o social media.

Attenzione

La pubblicazione sul Web può esporre dati sensibili o riservati, sia accidentalmente che intenzionalmente. Per questo motivo, questa funzionalità è disabilitata per impostazione predefinita. La pubblicazione sul Web deve essere usata solo per i report che contengono dati che possono essere visualizzati dal pubblico.

L'impostazione Pubblica sul tenant Web consente agli amministratori di Power BI di controllare quali gruppi di utenti possono pubblicare report sul Web. Per mantenere un livello di controllo superiore, è consigliabile non includere altri gruppi in questa impostazione del tenant, ad esempio amministratori di Power BI o altri tipi di creatori di contenuti. Applicare invece l'accesso utente specifico usando un gruppo di sicurezza, ad esempio la pubblicazione pubblica di Power BI. Assicurarsi che il gruppo di sicurezza sia ben gestito.

Incorporamento in app personalizzate

L'impostazione Incorpora contenuto nei tenant delle app consente agli amministratori di Power BI di controllare quali utenti possono incorporare contenuto di Power BI all'esterno del servizio Power BI. Quando si prevede di incorporare il contenuto di Power BI nelle applicazioni personalizzate, abilitare questa impostazione per gruppi specifici, ad esempio gli sviluppatori di app.

Incorporamento in PowerPoint

L'impostazione Abilita componente aggiuntivo Power BI per il tenant di PowerPoint consente agli amministratori di Power BI di controllare quali utenti possono incorporare pagine di report di Power BI nelle presentazioni di PowerPoint. Se appropriato, abilitare questa impostazione per gruppi specifici, ad esempio autori di report.

Nota

Per consentire il funzionamento di questa funzionalità, gli utenti devono installare il componente aggiuntivo Power BI per PowerPoint. Per usare il componente aggiuntivo, gli utenti devono avere accesso all'archivio dei componenti aggiuntivi di Office oppure il componente aggiuntivo deve essere reso disponibile come componente aggiuntivo gestito dall'amministratore. Per altre informazioni, vedere Componente aggiuntivo power BI per PowerPoint.

Informare gli autori di report di essere cauti sulla posizione in cui salvano le presentazioni di PowerPoint e con chi li condividono. Ciò è dovuto al fatto che un'immagine degli oggetti visivi del report di Power BI viene visualizzata agli utenti quando aprono la presentazione. L'immagine viene acquisita dall'ultima volta che il file di PowerPoint è stato connesso. Tuttavia, l'immagine potrebbe inavvertitamente rivelare i dati che l'utente ricevente non dispone dell'autorizzazione per visualizzare.

Nota

L'immagine può essere utile quando l'utente ricevente non ha ancora il componente aggiuntivo o finché il componente aggiuntivo non si connette al servizio Power BI per recuperare i dati. Dopo la connessione dell'utente, solo i dati che l'utente può visualizzare (applicando qualsiasi sicurezza a livello di riga) viene recuperato da Power BI.

App modello

Le app modello consentono ai partner power BI e ai fornitori di software di creare app di Power BI con poco o nessun codice e distribuirle a qualsiasi cliente di Power BI.

L'impostazione tenant Pubblica app modello consente agli amministratori di Power BI di controllare quali utenti possono pubblicare app modello all'esterno dell'organizzazione, ad esempio tramite Microsoft AppSource. Per la maggior parte delle organizzazioni, questa impostazione del tenant deve essere disabilitata o strettamente controllata. Prendere in considerazione l'uso di un gruppo di sicurezza, ad esempio autori di app modello esterne di Power BI.

Sottoscrizioni tramite posta elettronica

È possibile sottoscrivere se stessi e altri utenti a report, dashboard e report impaginati di Power BI. Power BI invierà quindi un messaggio di posta elettronica in base a una pianificazione impostata. Il messaggio di posta elettronica conterrà uno snapshot e un collegamento al report o al dashboard.

È possibile creare una sottoscrizione che includa altri utenti quando si è un amministratore, un membro o un collaboratore dell'area di lavoro. Se il report si trova in un'area di lavoro Premium, è possibile sottoscrivere gruppi (che si trovino nel dominio o meno) e utenti esterni. Quando si configura la sottoscrizione, è anche possibile concedere le autorizzazioni all'elemento. A questo scopo vengono usate autorizzazioni di accesso diretto per elemento, descritte nell'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti dei report).

Attenzione

La funzionalità di sottoscrizione tramite posta elettronica può condividere contenuti a gruppi di destinatari interni ed esterni. Inoltre, quando la sicurezza a livello di riga viene applicata al modello semantico sottostante, gli allegati e le immagini vengono generati usando il contesto di sicurezza dell'utente che esegue la sottoscrizione.

L'impostazione tenant Sottoscrizioni di posta elettronica consente agli amministratori di Power BI di controllare se questa funzionalità è abilitata o disabilitata per l'intera organizzazione.

Esistono alcune limitazioni relative agli allegati correlati alle restrizioni relative alle licenze e alle impostazioni del tenant. Per altre informazioni, vedere Sottoscrizioni di posta elettronica per report e dashboard nel servizio Power BI.

Elenco di controllo : quando si pianifica la pubblicazione di contenuto, le decisioni chiave e le azioni includono:

Decidere la strategia per la posizione in cui pubblicare il contenuto, come e da chi: determinare quali preferenze e requisiti esistono per la posizione in cui viene pubblicato il contenuto.
Verificare l'accesso all'area di lavoro: confermare l'approccio di progettazione dell'area di lavoro. Verificare come usare i ruoli di accesso all'area di lavoro per supportare la strategia di pubblicazione del contenuto.
Determinare come gestire le autorizzazioni della pipeline di distribuzione: decidere quali utenti sono autorizzati a pubblicare contenuto usando una pipeline di distribuzione. Impostare di conseguenza le autorizzazioni della pipeline di distribuzione. Assicurarsi che venga fornito anche l'accesso all'area di lavoro.
Decidere chi può connettersi ai modelli semantici usando l'endpoint XMLA: decidere quali utenti possono eseguire query o gestire modelli semantici usando l'endpoint XMLA. Impostare l'impostazione Consenti endpoint XMLA e Analizza in Excel con i modelli semantici locali per allinearsi a questa decisione. Quando si decide di limitare questa funzionalità, prendere in considerazione l'uso di un gruppo come gli autori di contenuti approvati da Power BI.
Decidere chi può pubblicare i report pubblicamente: decidere quali utenti sono autorizzati a pubblicare pubblicamente i report di Power BI, se presenti. Impostare l'impostazione Pubblica sul tenant Web per allinearsi a questa decisione. Usare un gruppo, ad esempio la pubblicazione pubblica di Power BI.
Decidere chi può incorporare contenuto nelle app personalizzate: determinare chi deve essere autorizzato a incorporare contenuto all'esterno del servizio Power BI. Impostare l'impostazione Incorpora contenuto nelle app tenant per allinearsi a questa decisione.
Decidere chi può incorporare contenuto in PowerPoint: determinare chi deve essere autorizzato a incorporare contenuto in PowerPoint. Impostare l'impostazione Abilita componente aggiuntivo Power BI per il tenant di PowerPoint per allinearsi a questa decisione.
Decidere chi può pubblicare app modello: determinare qual è la strategia per l'uso di app modello all'esterno dell'organizzazione. Impostare l'impostazione del tenant Publish template apps (Pubblica app modello) per allinearla a questa decisione.
Decidere se abilitare le sottoscrizioni: verificare qual è la strategia per l'uso delle sottoscrizioni. Impostare l'impostazione tenant Sottoscrizioni di posta elettronica per allinearla a questa decisione.

Aggiorna dati

Dopo la pubblicazione, gli autori di dati devono assicurarsi che i modelli semantici e i flussi di dati (che contengono dati importati) vengano aggiornati periodicamente. È anche necessario decidere le strategie appropriate per il modello semantico e i proprietari del flusso di dati.

Proprietario del modello semantico

Ogni modello semantico ha un proprietario, ovvero un singolo account utente. Il proprietario del modello semantico è necessario per configurare l'aggiornamento semantico del modello e impostare i parametri del modello semantico.

Per impostazione predefinita, il proprietario del modello semantico riceve anche le richieste di accesso dagli autori di report che desiderano autorizzazioni di compilazione (a meno che le impostazioni richiedi l'accesso per il modello semantico siano impostate per fornire istruzioni personalizzate). Per altre informazioni, vedere la sezione Richiedere l'accesso ai creatori in questo articolo.

Esistono due modi in cui Power BI può ottenere le credenziali per aggiornare un modello semantico.

Il proprietario del modello semantico archivia le credenziali nelle impostazioni del modello semantico.
Il proprietario del modello semantico fa riferimento a un gateway nelle impostazioni del modello semantico (che contiene un'origine dati con credenziali archiviate).

Se un utente diverso deve configurare i parametri di aggiornamento o set semantico del modello, deve assumere la proprietà del modello semantico. la proprietà del modello semantico può essere acquisita da un amministratore, un membro o un collaboratore dell'area di lavoro.

Attenzione

L'acquisizione della proprietà del modello semantico rimuove definitivamente tutte le credenziali archiviate per il modello semantico. Le credenziali devono essere immesse nuovamente per consentire la ripresa delle operazioni di aggiornamento dati.

Idealmente, il proprietario del modello semantico è l'utente responsabile del modello semantico. È consigliabile aggiornare il proprietario del modello semantico quando lasciano l'organizzazione o modificano i ruoli. Tenere inoltre presente che quando l'account utente del proprietario del modello semantico è disabilitato in Microsoft Entra ID (noto in precedenza come Azure Active Directory), l'aggiornamento dei dati viene disabilitato automaticamente. In questo caso, un altro utente deve assumere la proprietà del modello semantico per consentire la ripresa delle operazioni di aggiornamento dei dati.

Proprietario del flusso di dati

Analogamente ai modelli semantici, i flussi di dati hanno anche un proprietario, ovvero un singolo account utente. Le informazioni e le indicazioni fornite nell'argomento precedente sui proprietari di modelli semantici si applicano anche ai proprietari del flusso di dati.

Elenco di controllo : quando si pianifica la sicurezza relativa ai processi di aggiornamento dei dati, le decisioni chiave e le azioni includono:

Decidere la strategia per i proprietari di modelli semantici: determinare quali preferenze e requisiti esistono per la gestione dei proprietari di modelli semantici.
Decidere la strategia per i proprietari del flusso di dati: determinare quali preferenze e requisiti esistono per la gestione dei proprietari del flusso di dati.
Includere nella documentazione e nel training per gli autori di modelli semantici: includere indicazioni per gli autori di dati su come gestire i proprietari per ogni tipo di elemento.

Per altre considerazioni, azioni, criteri decisionali e consigli utili per prendere in considerazione le decisioni di implementazione di Power BI, vedere le aree di interesse da considerare.

Pianificazione dell'implementazione di Power BI: Pianificazione della sicurezza degli autori di contenuti

Strategia per gli autori di contenuti

Creatori di dati

Autori di report

Autorizzazioni per gli autori

Creazione di nuovo contenuto

Autorizzazioni per la pubblicazione del contenuto

Aggiornamento dei dati

Scoprire il contenuto per i creatori

Richiedere il flusso di lavoro di accesso per gli autori

Creare e pubblicare contenuto

Ruoli dell'area di lavoro

Amministratore dell'area di lavoro

Membro dell'area di lavoro

Collaboratore area di lavoro

Visualizzatore dell'area di lavoro

Considerazioni sulla proprietà dell'area di lavoro

Varianti ai ruoli dell'area di lavoro

Autorizzazioni per autori di app

Autorizzazioni origine dati

Accesso all'origine dati

Livelli di privacy

Query di database native

Connettori personalizzati

Autorizzazioni per creatori di modelli semantici

Autorizzazioni del modello semantico

Autorizzazione di lettura del modello semantico

Autorizzazione di compilazione del modello semantico

Autorizzazione scrittura modello semantico

Autorizzazione di ricondividi modello semantico

Sicurezza dei dati del modello semantico

Modelli semantici concatenati

Query dell'API del modello semantico

Autorizzazioni autore report

Autorizzazioni di lettura e compilazione per il modello semantico sottostante

Sicurezza dei dati per il modello semantico sottostante

Connessione ing a modelli semantici esterni

Tabelle in primo piano

Autorizzazioni per oggetti visivi personalizzati

Autorizzazioni autore del flusso di dati

Autorizzazioni autore datamart

Condivisione di datamart

Sicurezza a livello di riga datamart

Autorizzazioni autore scorecard

Autorizzazioni scorecard

Autorizzazioni a livello di metrica

Pubblicazione di contenuto

Aree di lavoro

Sincronizzazione di Power Apps

Accesso alla pipeline di distribuzione

Endpoint XMLA

Pubblica sul Web

Incorporamento in app personalizzate

Incorporamento in PowerPoint

App modello

Sottoscrizioni tramite posta elettronica

Aggiorna dati

Proprietario del modello semantico

Proprietario del flusso di dati

Contenuto correlato

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive