Condividi tramite

Pianificazione dell'implementazione di Power BI: controllo a livello di tenant

  • Articolo

Nota

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

Questo articolo sulla pianificazione dei controlli a livello di tenant è destinato principalmente a:

  • Amministratori Power BI: amministratori responsabili della supervisione di Power BI nell'organizzazione. Gli amministratori di Power BI potrebbero dover collaborare con IT, sicurezza, controllo interno e altri team pertinenti.
  • Center of Excellence, team IT e BI: altri team responsabili della supervisione di Power BI. Potrebbe essere necessario collaborare con gli amministratori di Power BI e altri team pertinenti.

Importante

È consigliabile seguire attentamente il piano di versione di Power BI per informazioni sui miglioramenti futuri delle funzionalità di controllo e monitoraggio.

Lo scopo di una soluzione di controllo a livello di tenant è acquisire e analizzare i dati per tutti gli utenti, le attività e le soluzioni distribuiti in un tenant di Power BI. Questi dati di controllo a livello di tenant sono utili per molti scopi, consentendo di analizzare le attività di adozione, comprendere i modelli di utilizzo, informare gli utenti, supportare gli utenti, ridurre i rischi, migliorare la conformità, gestire i costi delle licenze e monitorare le prestazioni.

La creazione di una soluzione di controllo end-to-end sicura e pronta per la produzione è un progetto significativo che richiede tempo. Si pensi alla creazione di business intelligence in business intelligence (BI in BI). Per informazioni sul motivo per cui i dati di controllo sono così importanti, vedere la Panoramica di controllo e monitoraggio.

Per il controllo a livello di report, destinato agli autori di report, vedere Controllo a livello di report.

Per il controllo degli asset di dati, destinati agli autori di dati, vedere Controllo a livello di dati.

La parte restante di questo articolo è incentrata sul controllo a livello di tenant.

Suggerimento

L'obiettivo principale di questo articolo è aiutare a pianificare la creazione di una soluzione di controllo end-to-end. Poiché il contenuto di questo articolo è organizzato in quattro fasi, saranno necessarie informazioni in più fasi. Ad esempio, si troveranno informazioni nella fase 1 sulla pianificazione dell'uso di un'entità servizio e informazioni nella fase 2 sui prerequisiti e sulla configurazione.

Pertanto, è consigliabile leggere prima l'intero articolo in modo da avere familiarità con i vari elementi. Si dovrebbe quindi essere ben preparati a pianificare e creare la soluzione di controllo in modo iterativo.

Quando si prevede di creare una soluzione di controllo a livello di tenant, pianificare di dedicare tempo alle quattro fasi seguenti.

Fase 1: Pianificazione e decisioni

La prima fase è incentrata sulla pianificazione e sul processo decisionale. Esistono molti requisiti e priorità da considerare, pertanto è consigliabile dedicare tempo sufficiente per comprendere gli argomenti presentati in questa sezione. L'obiettivo è prendere decisioni iniziali ottimali in modo che le fasi successive vengano eseguite senza problemi.

Diagramma di flusso che descrive la fase 1, che è incentrata sulla pianificazione e sulle decisioni per la creazione di una soluzione di controllo a livello di tenant.

Requisiti e priorità

Nella fase iniziale, l'obiettivo è identificare ciò che è più importante. Concentrarsi sugli aspetti più importanti e su come misurare l'impatto nell'organizzazione. Cercare di definire requisiti orientati all'azienda anziché requisiti orientati alla tecnologia.

Ecco alcune domande a cui rispondere.

  • A quali domande chiave è necessario rispondere? È possibile esplorare un volume elevato di dati di controllo. Il modo più efficace per affrontare il controllo consiste nel concentrarsi sulla risposta a domande specifiche.
  • Quali sono gli obiettivi di adozione e cultura dei dati? Si supponga, ad esempio, di avere l'obiettivo di aumentare il numero di autori di contenuti BI self-service nell'organizzazione. In tal caso, è necessario misurare le attività degli utenti correlate alla creazione, alla modifica e alla pubblicazione di contenuto.
  • Quali rischi immediati sono presenti? Ad esempio, è possibile che si sia verificato un oversharing del contenuto in passato. La formazione degli utenti è stata migliorata e ora si vogliono controllare le impostazioni e le attività di sicurezza in modo continuativo.
  • Sono presenti indicatori di prestazioni chiave (KPI) o obiettivi dell'organizzazione? Ad esempio, si ha un indicatore KPI aziendale correlato alla trasformazione digitale o al mutamento in un'organizzazione più guidata dai dati. I dati di controllo a livello di tenant consentono di misurare se l'implementazione di Power BI è allineata a questi obiettivi.

Suggerimento

Verificare i requisiti di controllo e impostare le priorità con lo sponsor esecutivo e il Center of Excellence. È consigliabile estrarre i dati di controllo e iniziare a creare report basati su molti dati interessanti. Tuttavia, è improbabile che si derivi un valore elevato dalla soluzione di controllo quando questa non è guidata da domande a cui è necessario rispondere e azioni che si intende eseguire.

Per altre idee sui modi in cui è possibile usare i dati di controllo, vedere la Panoramica di controllo e monitoraggio.

Elenco di controllo: quando si identificano i requisiti e le priorità, le decisioni e le azioni principali includono:

  • Identificare i requisiti: raccogliere e documentare i requisiti aziendali principali per il controllo del tenant di Power BI.
  • Definizione delle priorità: impostare le priorità per i requisiti, classificandole come immediate, a breve termine, a medio termine e a lungo termine (backlog).
  • Creare un piano per le priorità immediate: mettere in atto un piano per iniziare a raccogliere dati in modo che siano disponibili quando necessario.
  • Rivalutare regolarmente i requisiti: creare un piano per rivalutare regolarmente i requisiti (ad esempio due volte all'anno). Verificare se la soluzione di controllo e monitoraggio soddisfa i requisiti indicati. Aggiornare gli elementi delle azioni nel piano in base alle esigenze.

Esigenze dei dati

Dopo aver definito i requisiti e le priorità (descritti in precedenza), si è pronti per identificare i dati necessari. In questa sezione sono illustrate quattro categorie di dati.

La maggior parte dei dati necessari proviene dalle API di amministrazione, che offrono una vasta gamma di metadati sul tenant di Power BI. Per altre informazioni, vedere Scegliere un'API utente o un'API di amministrazione più avanti in questo articolo.

Dati delle attività utente

Innanzitutto, ottenere i dati sulle attività degli utenti. Le attività utente, dette anche eventi o operazioni, sono utili per un'ampia gamma di scopi.

Nella maggior parte dei casi, questi dati vengono definiti come il log attività o il registro eventi. Tecnicamente, esistono diversi modi per acquisire i dati dell'attività utente (il log attività è uno di questi). Per altre informazioni sulle decisioni e sulle attività coinvolte, vedere Accedere ai dati dell'attività degli utenti più avanti in questo articolo.

Ecco alcune domande comuni a cui i dati delle attività utente possono rispondere.

  • Trovare utenti principali e contenuti principali
    • Quali contenuti vengono visualizzati più spesso e da quali utenti?
    • Quali sono le tendenze giornaliere, settimanali e mensili per la visualizzazione dei contenuti?
    • Le visualizzazioni dei report sono tendenti al rialzo o al ribasso?
    • Quanti utenti sono attivi?
  • Comprendere il comportamento degli utenti
    • Quale tipo di sicurezza viene usato più spesso (app, aree di lavoro o condivisione per elemento)?
    • Gli utenti usano più spesso browser o app per dispositivi mobili?
    • Quali autori di contenuti stanno pubblicando e aggiornando più attivamente il contenuto?
    • Quali contenuti vengono pubblicati o aggiornati, quando e da quali utenti?
  • Identificare le opportunità di istruzione e formazione degli utenti
    • Chi sta effettuando (troppe) condivisioni dall'area di lavoro personale?
    • Chi sta effettuando una notevole quantità di esportazioni?
    • Chi scarica regolarmente i contenuti?
    • Chi pubblica molti nuovi modelli semantici?
    • Chi usa molto le sottoscrizioni?
  • Migliorare le attività di governance e conformità
    • Quando vengono modificate le impostazioni del tenant e da quale amministratore di Power BI?
    • Chi ha avviato una versione di valutazione di Power BI?
    • Quali contenuti sono accessibili da utenti esterni, chi, quando e come?
    • Chi ha aggiunto o aggiornato un'etichetta di riservatezza?
    • Quale percentuale di visualizzazioni del report si basa su modelli semantici certificati?
    • Quale percentuale di modelli semantici supporta più report?
    • Quando un gateway o un'origine dati vengono creati o aggiornati e da quale utente?

Per altre informazioni sui modi per usare questi dati, vedere Informazioni sui modelli di utilizzo.

Importante

Se non si stanno già estraendo e archiviando i dati delle attività utente, fare in modo che sia una priorità urgente. Assicurarsi almeno di estrarre i dati non elaborati e archiviarli in una posizione sicura. In questo modo, i dati saranno disponibili quando si è pronti per analizzarli. La cronologia è disponibile per 30 o 90 giorni, a seconda dell'origine usata.

Per altre informazioni, vedere Accedere ai dati dell'attività utente più avanti in questo articolo.

Inventario tenant

Spesso, la seconda priorità consiste nel recuperare i dati per creare un inventario tenant. In alcuni casi viene definito inventario dell'area di lavoro, metadati dell'area di lavoro o metadati del tenant.

Un inventario tenant è uno snapshot in un determinato momento. Descrive gli elementi pubblicati nel tenant. L'inventario tenant non include i dati effettivi o i report effettivi. Si tratta invece di metadati che descrivono tutte le aree di lavoro e i relativi elementi, ad esempio modelli semantici e report.

Ecco alcune domande comuni a cui l'inventario tenant può rispondere.

  • Informazioni sulla quantità di contenuto disponibile e sulla sua posizione
    • Quali aree di lavoro hanno il maggior numero di contenuti?
    • Quale tipo di contenuto viene pubblicato in ogni area di lavoro (in particolare quando si separano le aree di lavoro di report e le aree di lavoro dati)?
    • Quali dipendenze esistono tra elementi (ad esempio flussi di dati che supportano molti modelli semantici o un modello semantico che rappresenta un'origine per altri modelli compositi)?
    • Qual è la derivazione dei dati (dipendenze tra gli elementi di Power BI, incluse le origini dati esterne)?
    • Sono presenti report orfani (disconnessi dal modello semantico)?
  • Comprendere il rapporto tra modelli semantici e report
    • Quanto riutilizzo si sta verificando per il modello semantico?
    • Esistono modelli semantici duplicati o altamente simili?
    • Ci sono opportunità di consolidare i modelli semantici?
  • Informazioni sulle tendenze tra i punti nel tempo
    • Il numero di report aumenta nel tempo?
    • Il numero di modelli semantici aumenta nel tempo?
  • Trovare contenuto inutilizzato
    • Quali report sono inutilizzati (o sottoutilizzati)?
    • Quali modelli semantici sono inutilizzati (o sottoutilizzati)?
    • Ci sono opportunità di ritirare il contenuto?

Un inventario tenant consente di usare i nomi correnti durante l'analisi delle attività cronologiche. Lo snapshot degli elementi nel tenant contiene i nomi di tutti gli elementi in quel momento. È utile usare i nomi degli elementi correnti per la creazione di report cronologici. Ad esempio, se un report è stato rinominato tre mesi fa, il log attività in quel momento registra il nome del report precedente. Con un modello di dati definito correttamente, è possibile usare l'inventario tenant più recente per individuare un elemento in base al nome corrente anziché al nome precedente. Per altre informazioni, vedere Creare un modello di dati più avanti in questo articolo.

Per altre informazioni su come usare un inventario tenant, vedere Informazioni sul contenuto pubblicato.

Suggerimento

Spesso si useranno gli eventi di attività utente (descritti nella sezione precedente) e l'inventario tenant per produrre un quadro completo. In questo modo, si migliora il valore di tutti i dati.

Poiché un inventario tenant è uno snapshot in un determinato momento, è necessario decidere con quale frequenza estrarre e archiviare i metadati. Uno snapshot settimanale è utile per eseguire confronti tra i due punti nel tempo. Ad esempio, se si desidera analizzare le impostazioni di sicurezza per un'area di lavoro, saranno necessari lo snapshot di inventario tenant precedente, gli eventi del log attività e lo snapshot di inventario del tenant corrente.

Esistono due modi principali per creare un inventario tenant. Per altre informazioni sulle decisioni e sulle attività coinvolte, vedere Accedere ai dati dell'inventario tenant più avanti in questo articolo.

Dati di utenti e gruppi

Man mano che le esigenze analitiche aumentano, è probabile che si voglia includere dati su utenti e gruppi nella soluzione di controllo end-to-end. Per recuperare tali dati, è possibile usare Microsoft Graph, che è l'origine autorevole per informazioni su utenti e gruppi di Microsoft Entra ID.

I dati recuperati dalle API REST di Power BI includono un indirizzo e-mail per descrivere l'utente o il nome di un gruppo di sicurezza. Questi dati sono uno snapshot in un determinato momento.

Ecco alcune domande comuni a cui Microsoft Graph può rispondere.

  • Identificare utenti e gruppi
    • Quali sono nome utente completo (oltre all'indirizzo di posta elettronica), reparto o posizione originati dal profilo utente?
    • Chi sono i membri di un gruppo di sicurezza?
    • Chi è il proprietario di un gruppo di sicurezza (per gestire i membri)?
  • Ottenere informazioni utente aggiuntive
    • Quali licenze, Power BI Pro o Power BI Premium per utente (PPU), vengono assegnate agli utenti?
    • Quali utenti accedono più frequentemente?
    • Quali utenti non hanno eseguito l'accesso al servizio Power BI di recente?

Avviso

Alcuni metodi meno recenti (ampiamente documentati online) per l'accesso ai dati di utenti e gruppi sono deprecati e non devono essere usati. Quando possibile, usare Microsoft Graph come origine autorevole di utenti e gruppi di dati.

Per altre informazioni e consigli su come accedere ai dati da Microsoft Graph, vedere Accedere a dati di utenti e gruppi più avanti in questo articolo.

Dati di sicurezza

Potrebbe essere necessario eseguire controlli di sicurezza regolari.

Ecco alcune domande comuni a cui le API REST di Power BI possono rispondere.

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 con capacità Fabric (SKU F).

Per altre informazioni, vedere Aggiornamento importante disponibile per le licenze Power BI Premium e Domande frequenti su Power BI Premium.

Suggerimento

Per altre considerazioni sulla sicurezza, vedere gli articoli Pianificazione della sicurezza.

Queste domande comuni non sono un elenco completo; sono disponibili un'ampia gamma di API REST di Power BI. Per altre informazioni, vedere Uso delle API REST di Power BI.

Per altre informazioni sull'uso delle API di amministrazione e delle API utente (incluso il modo in cui influiscono sulle autorizzazioni necessarie per l'utente che estrae i dati), vedere Scegliere un'API utente o un'API amministratore più avanti in questo articolo.

Elenco di controllo: quando si identificano i dati necessari per il controllo, le decisioni chiave e le azioni includono:

  • Identificare specifiche esigenze di dati per i dati dell'attività utente: convalidare i requisiti raccolti. Identificare i dati di controllo necessari per soddisfare ogni requisito per i dati di attività degli utenti.
  • Identificare specifiche esigenze di dati per i dati dell'inventario tenant: convalidare i requisiti raccolti. Identificare i dati di controllo necessari per compilare un inventario tenant.
  • Identificare specifiche esigenze di dati per i dati di utenti e gruppi: convalidare i requisiti raccolti. Identificare i dati di controllo necessari per soddisfare ogni requisito per i dati di utenti e gruppi.
  • Identificare specifiche esigenze di dati per la sicurezza: convalidare i requisiti raccolti. Identificare i dati di controllo necessari per soddisfare ogni requisito per i dati di sicurezza.
  • Verificare le priorità: verificare l'ordine delle priorità in modo da sapere cosa sviluppare prima.
  • Decidere con quale frequenza acquisire le attività: decidere con quale frequenza acquisire eventi di attività, ad esempio una volta al giorno.
  • Decidere con quale frequenza acquisire gli snapshot: decidere con quale intervallo acquisire i dati degli snapshot, ad esempio un inventario tenant o i dati di utenti e gruppi.

Tipo di soluzione di controllo

Il controllo a livello di tenant viene eseguito manualmente o con processi automatizzati.

La maggior parte dei nuovi processi di controllo inizia come processo manuale, in particolare durante lo sviluppo e durante i test. Un processo di controllo manuale può evolversi per diventare un processo automatizzato. Tuttavia, non tutti i processi di controllo devono essere completamente automatizzati.

Processi di controllo manuali

Il controllo manuale si basa su script e processi eseguiti su richiesta da un utente (in genere un amministratore di Power BI). Quando necessario, l'utente esegue query in modo interattivo per recuperare i dati di controllo.

Il controllo manuale è più adatto per:

  • Nuovi script che vengono sviluppati e testati.
  • Occasionali esigenze di controllo.
  • Esigenze di controllo esplorativo.
  • Processi di controllo non essenziali che non richiedono il supporto completo.

Processi di controllo automatizzati

Il controllo dei dati necessari su base ricorrente deve essere automatizzato. Viene estratto ed elaborato in base a una pianificazione regolare ed è noto come processo automatizzato. A volte viene definito processo automatico.

Gli obiettivi di un processo automatizzato sono ridurre il lavoro manuale, ridurre il rischio di errore, aumentare la coerenza ed eliminare la dipendenza da un singolo utente per eseguirlo.

Il controllo automatizzato è più adatto per:

  • Processi di controllo eseguiti nell'ambiente di produzione.
  • Processi automatici eseguiti in base a una pianificazione regolare.
  • Script completamente testati.
  • Processi di controllo essenziali con altri report (o altri processi) che dipendono da esso come origine dati.
  • Processi di controllo documentati e supportati.

Il tipo di processo, manuale o automatizzato, potrebbe influire sulla modalità di gestione dell'autenticazione. Ad esempio, un amministratore di Power BI potrebbe usare l'autenticazione utente per un processo di controllo manuale, ma usare un'entità servizio per un processo automatizzato. Per altre informazioni, vedere Determinare il metodo di autenticazione più avanti in questo articolo.

Suggerimento

Se è presente una necessità periodica e ricorrente di ottenere i dati di controllo attualmente gestiti in modo manuale, è consigliabile investire tempo per trovare un'alternativa automatizzata. Ad esempio, se un amministratore di Power BI esegue manualmente uno script ogni giorno per recuperare i dati dal log attività di Power BI, è possibile che manchino dei dati in caso tale persone sia assente o in ferie.

Elenco di controllo: quando si considera il tipo di soluzione di controllo da sviluppare, le decisioni e le azioni principali includono:

  • Determinare lo scopo principale per ogni nuovo requisito di controllo: decidere se usare un processo manuale o automatizzato per ogni nuovo requisito. Valutare se tale decisione debba essere temporanea o permanente.
  • Creare un piano per automatizzare: quando è appropriato per un determinato requisito di controllo, creare un piano per automatizzarlo, decidendo modalità, tempistiche e utenti.

Autorizzazioni e responsabilità

A questo punto, è necessario avere un'idea chiara di ciò che si vuole eseguire e dei dati necessari nella fase iniziale. Questo è un buon momento per prendere decisioni sulle autorizzazioni utente, nonché sui ruoli e sulle responsabilità.

Autorizzazioni utenti

Quando si prevede di creare una soluzione di controllo end-to-end, prendere in considerazione le autorizzazioni per altri utenti che dovranno accedere ai dati. In particolare, decidere chi potrà accedere e visualizzare i dati di controllo.

Ecco alcune considerazioni importanti.

Accesso diretto ai dati di controllo

È necessario decidere chi può accedere direttamente ai dati di controllo. Ci sono diversi modi per pensarci.

  • Chi deve essere un amministratore di Power BI? Un amministratore di Power BI ha accesso a tutti i metadati del tenant, incluse le API di amministrazione. Per altre informazioni sulla scelta di chi deve essere un amministratore di Power BI, vedere pianificazione della sicurezza a livello di tenant.
  • Chi può usare un'entità servizio esistente? Per usare un'entità servizio (al posto delle autorizzazioni utente) per accedere ai dati di controllo, è necessario fornire un segreto agli utenti autorizzati in modo che possano eseguire l'autenticazione basata su password. L'accesso ai segreti (e alle chiavi) deve essere strettamente controllato.
  • L'accesso deve essere strettamente controllato? Alcuni settori con requisiti normativi e di conformità devono controllare l'accesso più strettamente rispetto ad altri.
  • Sono presenti volumi di dati di attività di grandi dimensioni? Per evitare di raggiungere i limiti delle API, potrebbe essere necessario controllare rigorosamente chi è autorizzato ad accedere direttamente alle API che producono dati di controllo. In questo caso, è utile assicurarsi che non siano presenti attività duplicate o sovrapposte.
Accesso ai dati non elaborati estratti

È necessario decidere chi può visualizzare i dati non elaborati estratti e scritti in una posizione di archiviazione. In genere, l'accesso ai dati non elaborati è limitato agli amministratori e ai revisori. Anche il Center of Excellence (COE) potrebbe richiedere l'accesso. Per altre informazioni, vedere Determinare dove archiviare i dati di controllo più avanti in questo articolo.

Accesso ai dati analitici curati

È necessario decidere chi può visualizzare i dati curati e trasformati pronti per l'analisi. Questi dati devono essere sempre resi disponibili agli amministratori e ai revisori. A volte un modello di dati viene reso disponibile ad altri utenti dell'organizzazione, in particolare quando si crea un modello semantico di Power BI con sicurezza a livello di riga. Per altre informazioni, vedere Pianificare la creazione di dati curati più avanti in questo articolo.

Ruoli e responsabilità

Dopo aver deciso il funzionamento delle autorizzazioni utente, è possibile iniziare a pensare a ruoli e responsabilità. È consigliabile coinvolgere le persone giuste all'inizio, soprattutto quando più sviluppatori o team parteciperanno alla creazione della soluzione di controllo end-to-end.

Decidere quali utenti o team saranno responsabili delle attività seguenti.

Ruolo Tipi di responsabilità Ruolo in genere eseguito da
Comunicare con gli stakeholder Attività di comunicazione e raccolta dei requisiti. COE in collaborazione con l'IT. Può includere anche le persone selezionate dalle business unit chiave.
Decidere le priorità e fornire indicazioni sui requisiti Attività decisionali correlate alla soluzione di controllo end-to-end, incluse le procedure per soddisfare i requisiti. Il team che supervisiona Power BI nell'organizzazione, ad esempio il COE. Lo sponsor esecutivo o un comitato responsabile della governance dei dati potrebbe essere coinvolto per prendere decisioni critiche o inoltrare i problemi.
Estrarre e archiviare i dati non elaborati Creazione di script e processi per accedere ed estrarre i dati. Comporta anche la scrittura dei dati non elaborati nell'archiviazione. Personale di ingegneria dei dati, in genere nell'IT e in collaborazione con il COE.
Creare i dati curati Pulizia dei dati, trasformazione e creazione dei dati curati nella progettazione dello schema a stella. Personale di ingegneria dei dati, in genere nell'IT e in collaborazione con il COE.
Creare un modello di dati Creazione di un modello di dati analitici basato sui dati curati. Autori di contenuti di Power BI, in genere nel reparto IT o COE.
Creare report di analisi Creazione di report per analizzare i dati curati. Modifiche in corso ai report in base ai nuovi requisiti e quando diventano disponibili nuovi dati di controllo. Autori di report di Power BI, in genere nel reparto IT o COE.
Analizzare i dati e agire sui risultati Analizzare i dati e agire in risposta ai dati di controllo. Il team che supervisiona Power BI nell'organizzazione, solitamente il COE. Può includere anche altri team a seconda dei risultati del controllo e dell'azione. Altri team possono includere sicurezza, conformità, aspetti legali, gestione dei rischi o gestione delle modifiche.
Test e convalida Verificare che i requisiti di controllo siano soddisfatti e che i dati presentati siano accurati. Autori di contenuti di Power BI, in collaborazione con il team che supervisiona Power BI nell'organizzazione.
Protezione dei dati Impostare e gestire la sicurezza per ogni livello di archiviazione, inclusi i dati non elaborati e i dati curati. Gestire l'accesso ai modelli semantici creati per l'analisi dei dati. Amministratore per il sistema che archivia i dati, in collaborazione con il team che supervisiona Power BI nell'organizzazione.
Pianificazione e automazione Rendere operativa una soluzione e pianificare il processo con lo strumento preferito. Personale di ingegneria dei dati, in genere nell'IT e in collaborazione con il COE.
Supportare la soluzione Monitorare la soluzione di controllo, inclusi le esecuzioni dei processi, gli errori e il supporto per i problemi tecnici. Il team che gestisce il supporto del sistema di Power BI, che in genere è IT o COE.

Molti dei ruoli e delle responsabilità precedenti possono essere consolidati se verranno eseguiti dallo stesso team o dalla stessa persona. Ad esempio, gli amministratori di Power BI potrebbero eseguire alcuni di questi ruoli.

È anche possibile che persone diverse eseguano ruoli diversi, a seconda della circostanza. Le azioni saranno contestuali a seconda dei dati di controllo e dell'azione proposta.

Prendere in considerazione vari esempi.

  • Esempio 1: i dati di controllo mostrano che alcuni utenti esportano di frequente i dati in Excel. Azione intrapresa: il COE contatta gli utenti specifici per comprendere le proprie esigenze e per insegnare loro alternative migliori.
  • Esempio 2: i dati di controllo mostrano che l'accesso utente esterno si verifica in modo imprevisto. Azioni eseguite: un amministratore di sistema IT aggiorna le impostazioni relative a Microsoft Entra ID per l'accesso degli utenti esterni. L'amministratore di Power BI aggiorna l'impostazione del tenant correlata all'accesso utente esterno. Il COE aggiorna la documentazione e la formazione per gli autori di contenuti che gestiscono la sicurezza. Per altre informazioni, vedere Strategia per utenti esterni.
  • Esempio 3: i dati di controllo mostrano che diversi modelli di dati definiscono la stessa misura in modo diverso (disponibile dalle API di analisi dei metadati, se consentite dalle impostazioni dettagliate del tenant dei metadati). Azione intrapresa: il comitato di governance dei dati avvia un progetto per creare definizioni comuni. Il COE aggiorna la documentazione e la formazione per gli autori di contenuti che creano modelli di dati. Il COE collabora anche con gli autori di contenuti per aggiornare i propri modelli, in base alle esigenze. Per altre informazioni sul recupero di metadati dettagliati, vedere Accedere ai dati di inventario del tenant più avanti in questo articolo.

Nota

La configurazione dei processi di estrazione dei dati è in genere un'operazione monouso con miglioramenti e risoluzione di problemi occasionali. L'analisi e l'azione sui dati sono un impegno continuo su base ricorrente.

Elenco di controllo: quando si considerano le autorizzazioni e le responsabilità, le decisioni e le azioni principali includono:

  • Identificare quali team sono coinvolti: determinare quali team saranno coinvolti con la creazione end-to-end e il supporto della soluzione di controllo.
  • Decidere le autorizzazioni utente: determinare come verranno configurate le autorizzazioni utente per l'accesso ai dati di controllo. Creare la documentazione delle decisioni chiave per informazioni di riferimento successive.
  • Decidere ruoli e responsabilità: assicurarsi che le aspettative siano chiare per chi fa cosa, in particolare quando sono coinvolti più team. Creare la documentazione per ruoli e responsabilità, incluse le azioni previste.
  • Assegnare ruoli e responsabilità: assegnare ruoli e responsabilità specifici a persone o team specifici. Aggiornare le descrizioni dei singoli processi con le risorse umane, se appropriato.
  • Creare un piano di formazione: stabilire un piano per la formazione del personale quando sono richieste nuove competenze.
  • Creare un piano di training incrociato: assicurarsi che siano presenti backup e training incrociato per i ruoli chiave.

Decisioni tecniche

Quando si pianifica una soluzione di controllo a livello di tenant, è necessario prendere alcune decisioni tecniche importanti. Per migliorare la coerenza, evitare rielaborazioni e migliorare la sicurezza, è consigliabile prendere queste decisioni il prima possibile.

La prima fase di pianificazione prevede le decisioni seguenti.

Selezionare una tecnologia per accedere ai dati di controllo

La prima cosa da decidere è come accedere ai dati di controllo.

Il modo più semplice per iniziare consiste nell'usare i report predefiniti disponibili nell'area di lavoro di monitoraggio dell'amministratore.

Quando è necessario accedere direttamente ai dati e creare una soluzione personalizzata, si userà un'API (interfaccia del programma dell'applicazione). Le API sono progettate per lo scambio di dati tramite Internet. Le API REST di Power BI supportano le richieste di dati usando il protocollo HTTP. Qualsiasi linguaggio o strumento può richiamare API REST di Power BI quando è in grado di inviare una richiesta HTTP e ricevere una risposta JSON.

Suggerimento

I cmdlet di PowerShell usano le API REST di Power BI per accedere ai dati di controllo. Per altre informazioni, vedere Scegliere API o cmdlet di PowerShell più avanti in questo articolo.

Questa sezione è incentrata sulla scelta della tecnologia. Per considerazioni sull'origine per l'accesso a tipi specifici di dati di controllo, vedere Decisioni sull'origine dati più avanti in questo articolo.

Opzioni della piattaforma

Esistono molti modi diversi per accedere ai dati di controllo. A seconda della tecnologia scelta, si potrebbe preferire una determinata lingua. Potrebbe anche essere necessario prendere una decisione specifica su come pianificare l'esecuzione degli script. Le tecnologie differiscono notevolmente nella curva di apprendimento e nella facilità di inizio.

Ecco alcune tecnologie che è possibile usare per recuperare i dati usando le API REST di Power BI.

Tecnologia Scelta ottimale per i processi di controllo manuali Scelta ottimale per i processi di controllo automatizzati
Area di lavoro monitoraggio amministratore L'area di lavoro di monitoraggio dell'amministratore è una scelta ottimale per i processi di controllo manuale.
Try-it Try-it è una scelta ottimale per i processi di controllo manuali.
PowerShell PowerShell è una scelta ideale per i processi di controllo manuali. PowerShell è una scelta ideale per i processi di controllo automatizzati.
Power BI Desktop Power BI Desktop è una scelta ideale per i processi di controllo manuali.
Power Automate Power Automate è una buona scelta per i processi di controllo automatizzati.
Servizio di Azure preferito Il servizio di Azure preferito è una scelta ideale per i processi di controllo automatizzati.
Strumento/linguaggio preferito Lo strumento/linguaggio preferito è una scelta ideale per i processi di controllo manuale. Lo strumento/linguaggio preferito è una scelta ideale per i processi di controllo automatizzati.
Ricerca nel log di audit di Microsoft Purview La ricerca nei log di controllo di Microsoft Purview è una scelta ideale per i processi di controllo manuali.
Defender for Cloud Apps Defender for Cloud Apps è una buona scelta per i processi di controllo manuali.
Microsoft Sentinel Microsoft Sentinel è una scelta ideale per i processi di controllo automatizzati.

Nella parte restante di questa sezione viene fornita una breve introduzione a ognuna delle opzioni presentate nella tabella.

Area di lavoro monitoraggio amministratore

L'area di lavoro di monitoraggio dell'amministratore contiene report e modelli semantici predefiniti nel servizio Power BI. È un modo pratico per gli amministratori di Fabric di visualizzare i dati di controllo recenti e comprendere le attività degli utenti.

Try-it nella documentazione API

Try-it è uno strumento interattivo che consente di sperimentare l'API REST di Power BI direttamente nella documentazione Microsoft. È un modo semplice per esplorare le API perché non richiede altri strumenti o alcuna configurazione nel computer.

È possibile usare Try-it per:

  • Inviare manualmente una richiesta a un'API per determinare se restituisce le informazioni desiderate.
  • Informazioni su come viene costruito l'URL prima di scrivere uno script.
  • Archiviare i dati in modo informale.

Nota

Per usare Try-it, è necessario essere un utente di Power BI con licenza e autenticazione. Segue il modello di autorizzazioni standard, vale a dire che le API utente si basano sulle autorizzazioni utente e le API di amministrazione richiedono autorizzazioni di amministratore di Power BI. Non è possibile eseguire l'autenticazione con Try-it usando un'entità servizio.

Poiché è interattivo, Try-it è più adatto per l'apprendimento, l'esplorazione e i nuovi processi di controllo manuale.

PowerShell e Azure Cloud Shell

È possibile creare ed eseguire script di PowerShell in diversi modi.

Ecco alcune opzioni comuni.

  • Visual Studio Code: un editor di codice sorgente moderno e leggero. Si tratta di uno strumento open source disponibile gratuitamente supportato in più piattaforme, tra cui Windows, macOS e Linux. È possibile usare Visual Studio Code con molti linguaggi, tra cui PowerShell (usando l'estensione PowerShell).
  • Azure Data Studio: uno strumento per la creazione di script e notebook. Si basa su Visual Studio Code. Azure Data Studio è disponibile in modo indipendente o con SQL Server Management Studio (SSMS). Sono disponibili molte estensioni, tra cui una per PowerShell.
  • Azure Cloud Shell: alternativa all'uso di PowerShell in locale. È possibile accedere ad Azure Cloud Shell da un browser.
  • Funzioni di Azure: alternativa all'uso di PowerShell in locale. Funzioni di Azure è un servizio di Azure che consente di scrivere ed eseguire codice in un ambiente serverless. PowerShell è uno dei diversi linguaggi supportati.

Importante

È consigliabile usare la versione più recente di PowerShell (PowerShell Core) per tutte le nuove attività di sviluppo. È consigliabile interrompere l'uso di Windows PowerShell (che non può eseguire PowerShell Core) e usare invece uno degli editor di codice moderni che supportano PowerShell Core. Prestare attenzione quando si fa riferimento a molti esempi online che usano Windows PowerShell (versione 5.1) perché potrebbero non usare gli approcci di codice più recenti (e migliori).

È possibile usare PowerShell in diversi modi. Per altre informazioni su questa decisione tecnica, vedere Scegliere API o cmdlet di PowerShell più avanti in questo articolo.

Sono disponibili molte risorse online per l'uso di PowerShell ed è spesso possibile trovare sviluppatori esperti che possono creare e gestire soluzioni PowerShell. PowerShell è una scelta ideale per la creazione di processi di controllo manuali e automatizzati.

Power BI Desktop

Poiché Power BI Desktop può connettersi alle API, potrebbe essere possibile usarlo per creare la soluzione di controllo. Tuttavia, esistono alcuni svantaggi e complessità significativi.

  • Cronologia di accumulo: poiché il log attività di Power BI fornisce fino a 30 giorni di dati, la creazione dell'intera soluzione di controllo comporta l'accumulo di un set di file che nel tempo archivia tutti gli eventi cronologici. L'accumulo di file cronologici è più semplice da eseguire con altri strumenti.
  • Gestire le credenziali e le chiavi in modo sicuro: molte soluzioni disponibili online dai blogger della community non sono sicure perché applicano credenziali e chiavi hardcoded in testo non crittografato nelle query di Power Query. Anche se questo approccio è semplice, non è consigliabile perché chiunque ottenga il file di Power BI Desktop potrà leggere i valori. Non è possibile archiviare la password (quando si usa l'autenticazione utente) o il segreto (quando si usa un'entità servizio) in modo sicuro in Power BI Desktop, a meno di non effettuare le operazioni seguenti:
    • Usare un connettore personalizzato sviluppato con Power Query SDK. Ad esempio, un connettore personalizzato può leggere i valori riservati da Azure Key Vault o da un altro servizio che archivia in modo sicuro il valore crittografato. Sono disponibili anche varie opzioni di connettore personalizzato dalla community globale di Power BI.
    • Usare l'opzione ApiKeyName, che funziona bene in Power BI Desktop. Non è tuttavia possibile archiviare il valore della chiave nel servizio Power BI.
  • Tipi di richieste: potrebbero verificarsi alcune limitazioni per ciò che è possibile eseguire in Power BI Desktop. Ad esempio, Power Query non supporta ogni tipo di richiesta API. Ad esempio, solo le richieste GET e POST sono supportate quando si usa la funzione Web.Contents. Per il controllo, in genere si inviano richieste GET.
  • Possibilità di aggiornare: è necessario seguire modelli di sviluppo specifici di Power Query per aggiornare correttamente un modello semantico nel servizio Power BI. Ad esempio, l'opzione RelativePath deve essere presente quando si usa Web.Contents in modo che Power BI possa verificare correttamente la posizione di un'origine dati senza generare un errore nel servizio Power BI.

Nella maggior parte dei casi, è consigliabile usare Power BI Desktop solo per due scopi. Da usare per:

  • Creare il modello di dati in base ai dati curati esistenti anziché usarli per estrarre inizialmente i dati di controllo.
  • Creare report analitici basati sul modello di dati.
Power Automate

È possibile usare Power Automate con Power BI in molti modi. In relazione al controllo, è possibile usare Power Automate per inviare richieste alle API REST di Power BI e quindi archiviare i dati estratti nella posizione desiderata.

Suggerimento

Per inviare richieste alle API REST di Power BI, è possibile usare un connettore personalizzato per Power Automate per autenticare ed estrarre in modo sicuro i dati di controllo. In alternativa, è possibile usare Azure Key Vault per fare riferimento a una password o a un segreto. Entrambe le opzioni sono migliori rispetto all'archiviazione di password e segreti in testo non crittografato all'interno del flusso di Power Automate.

Per altre idee su come usare Power Automate, cercare Power BI nei modelli di Power Automate.

Servizio di Azure preferito

Sono disponibili diversi servizi di Azure che possono inviare richieste alle API REST di Power BI. È possibile usare il servizio di Azure preferito, ad esempio:

Nella maggior parte dei casi, è possibile combinare un servizio di calcolo che gestisce la logica per l'estrazione dei dati con un servizio di archiviazione che archivia i dati non elaborati (e i dati curati, se appropriato). Le considerazioni per prendere decisioni tecniche sull'architettura sono descritte più avanti in questo articolo.

Strumento e/o linguaggio preferito

È possibile usare lo strumento preferito e la lingua preferita per inviare richieste alle API REST di Power BI. È un approccio ottimale quando il team ha competenze con uno strumento o un linguaggio specifico, ad esempio:

  • Python
  • C# in .NET framework. Facoltativamente, è possibile usare Power BI .NET SDK, che funge da wrapper sulle API REST di Power BI, per semplificare alcuni processi e aumentare la produttività.
  • JavaScript

Il portale di conformità di Microsoft Purview (in precedenza il Centro conformità Microsoft 365) include un'interfaccia utente che consente di visualizzare ed eseguire ricerche nei log di controllo. I log di controllo unificati includono Power BI e tutti gli altri servizi che supportano i log di controllo unificati di Microsoft 365.

I dati acquisiti nel log di controllo unificato sono gli stessi dati contenuti nel log attività di Power BI. Quando si esegue una ricerca nel log di controllo nel portale di conformità di Microsoft Purview, la richiesta viene aggiunta alla coda. La preparazione dei dati può richiedere alcuni minuti (o più, a seconda del volume di dati).

Ecco alcuni modi comuni per usare lo strumento di ricerca log di controllo. È possibile:

  • Selezionare il carico di lavoro di Power BI per visualizzare gli eventi per una serie di date.
  • Cercare una o più attività specifiche, ad esempio:
    • Report di Power BI eliminato
    • Aggiunta dell'accesso amministratore a un'area di lavoro personale in Power BI
  • Visualizzare le attività di uno o più utenti.

Per gli amministratori con autorizzazioni sufficienti, lo strumento Ricerca log di audit nel portale di conformità di Microsoft Purview è un'opzione valida per i processi di controllo manuali. Per altre informazioni, vedere Portale di conformità di Microsoft Purview più avanti in questo articolo.

Interfaccia utente di Defender for Cloud Apps

Defender for Cloud Apps è disponibile per gli amministratori in Microsoft Defender XDR (portale di Microsoft 365). Include un'interfaccia utente per visualizzare e cercare i log attività per vari servizi cloud, tra cui Power BI. Vengono visualizzati gli stessi eventi di log che hanno origine nel portale di conformità di Microsoft Purview, oltre ad altri eventi come l'attività di accesso utente da Microsoft Entra ID.

L'interfaccia del log di controllo in Defender for Cloud Apps è un'opzione valida per i processi di controllo manuali. Per altre informazioni, vedere la sezione Defender for Cloud Apps più avanti in questo articolo.

Microsoft Sentinel e KQL

Microsoft Sentinel è un servizio di Azure che consente di raccogliere, rilevare, analizzare e rispondere a eventi imprevisti e minacce per la sicurezza. Power BI può essere configurato in Microsoft Sentinel come connettore dati in modo che i log di controllo vengano trasmessi da Power BI in Microsoft Sentinel Azure Log Analytics (che è un componente del servizio Monitoraggio di Azure). È possibile usare Kusto Query Language (KQL) per analizzare gli eventi del log attività archiviati in Azure Log Analytics.

L'uso di KQL per cercare i dati in Monitoraggio di Azure è un'ottima opzione per visualizzare parte del log di controllo. È una buona opzione anche per i processi di controllo manuali. Per altre informazioni, vedere Microsoft Sentinel più avanti in questo articolo.

Considerazioni relative alla piattaforma

Ecco alcune considerazioni su come accedere ai dati di controllo.

  • Si sta implementando un processo di controllo manuale o automatizzato? Alcuni strumenti sono strettamente allineati all'elaborazione manuale o a quella automatizzata. Ad esempio, un utente esegue sempre la funzionalità Try-it in modo interattivo, quindi è adatta solo ai processi di controllo manuali.
  • Come si eseguirà l'autenticazione? Non tutte le opzioni supportano ogni opzione di autenticazione. Ad esempio, la funzionalità Try-it supporta solo l'autenticazione utente.
  • Come si archivieranno le credenziali in modo sicuro? Diverse tecnologie hanno diverse opzioni per l'archiviazione delle credenziali. Per altre informazioni, vedere Determinare il metodo di autenticazione più avanti in questo articolo.
  • Con quale tecnologia si trova già a proprio agio il team? Se c'è uno strumento che il team preferisce e usa senza problemi, iniziare da lì.
  • Cosa può supportare il tuo team? Se un team diverso supporterà la soluzione distribuita, valutare se sarà in grado di supportarla in modo adeguato. Considerare anche che i team interni potrebbero supportare lo sviluppo svolto dai consulenti.
  • Quale strumento si è autorizzati a usare? Alcuni strumenti e tecnologie potrebbero richiedere l'approvazione. Potrebbe essere dovuto al costo. Ciò potrebbe anche essere dovuto ai criteri di sicurezza IT.
  • Qual è la preferenza per la pianificazione? Alcune tecnologie decidono per conto dell'utente. Altre volte sarà semplicemente un'altra decisione da prendere. Ad esempio, se si sceglie di scrivere script di PowerShell, è possibile pianificare l'esecuzione in diversi modi. Viceversa, se si usa un servizio cloud come Azure Data Factory, la pianificazione è incorporata.

È consigliabile esaminare il resto di questo articolo prima di scegliere una tecnologia per accedere ai dati di controllo.

Elenco di controllo: quando si decide quale tecnologia usare per accedere ai dati di controllo, le decisioni chiave e le azioni includono:

  • Discutere con il personale IT: parlare con i team IT per scoprire se sono disponibili alcuni strumenti approvati o preferiti.
  • Esplorare le opzioni con un modello di verifica (POC) di piccole dimensioni: eseguire alcune sperimentazioni con un modello di verifica tecnico. Concentrarsi inizialmente sull'apprendimento. Quindi pensare bene a cosa usare in futuro.

Determinare il metodo di autenticazione

Il modo in cui si prevede di configurare l'autenticazione è una decisione fondamentale. È spesso uno degli aspetti più difficili quando si iniziano a eseguire il controllo e il monitoraggio. È consigliabile prendere attentamente in considerazione le opzioni disponibili per prendere una decisione informata.

Importante

Rivolgersi ai team IT e di sicurezza su questa questione. Dedicare il tempo necessario per apprendere le nozioni di base sul funzionamento della sicurezza in Microsoft Entra ID.

Non tutte le API su Internet richiedono l'autenticazione. Tuttavia, tutte le API REST di Power BI richiedono l'autenticazione. Quando si accede ai dati di controllo a livello di tenant, il processo di autenticazione viene gestito da Microsoft Identity Platform. Si tratta di un'evoluzione del servizio di gestione delle identità di Microsoft Entra basato su protocolli standard del settore.

Suggerimento

Il glossario dei termini di Microsoft Identity Platform è una risorsa che consente di acquisire familiarità con i concetti di base.

Prima di recuperare i dati di controllo, è necessario autenticarsi, un processo noto come accesso. I concetti relativi all'autenticazione e all'autorizzazione sono separati, ma correlati. Un processo di autenticazione verifica l'identità di chi sta effettuando la richiesta. Un processo di autorizzazione concede o nega l'accesso a un sistema o a una risorsa verificando per cosa l'utente o l'entità servizio dispone delle autorizzazioni necessarie.

Quando un utente o un'entità servizio esegue l'autenticazione, viene rilasciato un token di accesso Microsoft Entra a un server di risorse, ad esempio un'API REST di Power BI o un'API Microsoft Graph. Per impostazione predefinita, un token di accesso scade dopo un'ora. È possibile richiedere un token di aggiornamento, se necessario.

Esistono due tipi di token di accesso:

  • Token utente: rilasciato per conto di un utente con un'identità nota.
  • Token solo app: rilasciati per conto di un'applicazione Microsoft Entra (entità servizio).

Per altre informazioni, vedere Oggetti applicazione ed entità servizio in Microsoft Entra ID.

Nota

Un'applicazione Microsoft Entra è una configurazione di identità che consente a un processo automatizzato di integrarsi con Microsoft Entra ID. In questo articolo viene definita registrazione dell'app. Anche il termine entità servizio viene usato comunemente in questo articolo. Questi termini sono descritti in modo più dettagliato più avanti in questa sezione.

Suggerimento

Il modo più semplice per eseguire l'autenticazione consiste nell'usare il cmdlet Connect-PowerBIServiceAccount dal modulo di gestione di Power BI. È possibile che vengano visualizzati altri cmdlet correlati all'autenticazione negli articoli e nei post di blog online. Ad esempio, sono disponibili i cmdlet Login-PowerBI e Login-PowerBIServiceAccount, ovvero alias per il cmdlet Connect-PowerBIServiceAccount. È anche disponibile il cmdlet Disconnect-PowerBIServiceAccount che è possibile usare per disconnettersi in modo esplicito alla fine di un processo.

Nella tabella seguente vengono descritte le due opzioni di autenticazione.

Tipo di autenticazione Descrizione Destinato a Scelta ottimale per i processi di controllo manuali Scelta ottimale per i processi di controllo automatizzati
Autenticazione dell'utente Accedere come utente usando il nome dell'entità utente (indirizzo e-mail) e una password. Uso occasionale interattivo L'autenticazione utente è una scelta ideale per i processi di controllo manuale
Autenticazione dell'entità servizio Accedere come entità servizio usando un segreto (chiave) assegnato a una registrazione dell'app. Operazioni continue, pianificate e automatiche L'autenticazione dell'entità servizio è una scelta ideale per i processi di controllo automatizzati

Ogni opzione di autenticazione è descritta in modo più dettagliato nella sezione seguente.

Autenticazione dell'utente

L'autenticazione utente è utile nelle situazioni seguenti.

  • Processi di controllo manuali: si vuole eseguire uno script usando le autorizzazioni utente. Le autorizzazioni possono essere a uno dei due livelli, a seconda del tipo di richiesta API:
    • Autorizzazioni di amministratore per le API amministratore: è necessario usare le autorizzazioni di amministratore di Power BI per inviare una richiesta a un'API amministratore.
    • Autorizzazioni utente per le API utente: è necessario usare le autorizzazioni utente di Power BI per inviare una richiesta a un'API utente. Per altre informazioni, vedere Scegliere un'API utente o un'API di amministrazione.
  • Accesso interattivo: si vuole accedere in modo interattivo, cosa che richiede di immettere l'indirizzo e-mail e la password. Ad esempio, è necessario accedere in modo interattivo per usare l'esperienza Try-it disponibile nella documentazione dell'API Microsoft.
  • Tenere traccia degli utenti che hanno eseguito l'accesso ai metadati del tenant: quando singoli utenti e amministratori inviano richieste API, è possibile controllare chi sono gli utenti. Quando si esegue l'autenticazione con un'entità servizio (descritta più avanti), l'ID utente acquisito dal log attività è l'ID applicazione. Se più amministratori eseguono l'autenticazione con la stessa entità servizio, potrebbe essere difficile sapere quale amministratore ha eseguito l'accesso ai dati.
  • Account amministratore condiviso: alcuni team IT usano un account amministratore condiviso. A seconda del modo in cui viene implementato e controllato, potrebbe non essere una procedura consigliata. Invece di un account condiviso, è consigliabile usare Microsoft Entra Privileged Identity Management (PIM), che può concedere diritti di amministratore occasionali e temporanei di Power BI per un utente.
  • API che supportano solo l'autenticazione utente: occasionalmente, potrebbe essere necessario usare un'API che non supporta l'autenticazione da parte di un'entità servizio. Nella documentazione ogni API indica se un'entità servizio può chiamarla.

Importante

Quando possibile, è consigliabile usare l'autenticazione dell'entità servizio per i processi automatizzati.

Autenticazione dell'entità servizio

La maggior parte delle organizzazioni dispone di un tenant di Microsoft Entra, quindi i termini registrazione delle app ed entità servizio tendono a essere usati in modo intercambiabile. Quando si registra un'app Microsoft Entra, sono presenti due componenti.

  • Registrazione dell'app: una registrazione dell'app è globalmente univoca. Si tratta della definizione globale di un'app Microsoft Entra registrata che può essere usata da più tenant. Una registrazione dell'app è nota anche come applicazione client o attore. In genere, il termine applicazione client implica un computer utente. Tuttavia, questa non è la situazione per le registrazioni delle app. Nel portale di Azure le applicazioni Microsoft Entra sono disponibili nella pagina Registrazioni app in Microsoft Entra ID.
  • Entità servizio: un'entità servizio è la rappresentazione locale della registrazione dell'app da usare nel tenant specifico. L'entità servizio è derivata dall'app Microsoft Entra registrata. Per le organizzazioni con più tenant di Microsoft Entra, è possibile fare riferimento alla stessa registrazione dell'app da più di un'entità servizio. Nel portale di Azure le entità servizio sono disponibili nella pagina Applicazioni Enterprise in Microsoft Entra ID.

Poiché l'entità servizio è la rappresentazione locale, il termine Autenticazione dell'entità servizio è il modo più comune per fare riferimento agli accessi.

Suggerimento

L'amministratore di Microsoft Entra può indicare chi può crearee fornire il consenso a una registrazione dell'app nell'organizzazione.

L'autenticazione dell'entità servizio è utile nelle situazioni seguenti.

  • Processi di controllo automatizzati: si vuole eseguire un processo automatico in base a una pianificazione.
  • Non è necessario accedere al servizio Power BI: è sufficiente connettersi ed estrarre i dati. Un'entità servizio non può accedere al servizio Power BI.
  • Accesso condiviso ai dati: l'utente (personalmente) non è un amministratore di Power BI, ma è autorizzato a usare un'entità servizio. L'entità servizio dispone dell'autorizzazione per eseguire le API di amministrazione per recuperare i dati a livello di tenant (o altre autorizzazioni specifiche).
  • Usa con più amministratori: si vuole consentire a più amministratori o utenti di usare la stessa entità servizio.
  • Blocchi tecnici: esiste un blocco tecnico che impedisce l'uso dell'autenticazione utente. I blocchi tecnici comuni includono:
    • Autenticazione a più fattori (MFA): i processi di controllo automatizzati (che vengono eseguiti automaticamente) non possono eseguire l'autenticazione usando un account utente quando è abilitata l'autenticazione a più fattori.
    • Sincronizzazione dell'hash delle password: Microsoft Entra ID richiede la sincronizzazione dell'hash delle password per l'autenticazione di un account utente. In alcuni casi, l'IT o un team addetto alla sicurezza informatica potrebbe disabilitare questa funzionalità.
Convenzione di denominazione e scopo della registrazione dell'app

Ogni registrazione dell'app deve avere un nome chiaro che ne descriva lo scopo e il gruppo di destinatari (coloro che possono usare la registrazione dell'app).

Prendere in considerazione l'implementazione di una convenzione di denominazione, ad esempio: <Carico di lavoro> - <Scopo> - <Destinatari> - <Tipo di oggetto>

Ecco le parti della convenzione di denominazione.

  • Carico di lavoro: in genere equivalente a un'origine dati (ad esempio dati di Power BI o dati di Microsoft Graph).
  • Scopo: simile al livello di autorizzazioni, ad esempio Lettura e LetturaScrittura. Come descritto di seguito, lo scopo consente di seguire il principio dei privilegi minimi quando si creano registrazioni di app separate in grado di leggere solo i dati.
  • Destinatari: facoltativo. A seconda del carico di lavoro e dello scopo, il gruppo di destinatari consente di determinare gli utenti desiderati della registrazione dell'app.
  • Tipo di oggetto: EntraApp è incluso per maggiore chiarezza.

La convenzione di denominazione può essere più specifica quando si hanno più tenant o più ambienti, ad esempio sviluppo e produzione.

La tabella seguente mostra esempi di registrazioni di app che possono essere usate per estrarre i dati di controllo a livello di tenant:

Nome registrazione app Scopo Destinatari
PowerBIData-Read-AdminAPIs-EntraApp Estrarre metadati a livello di tenant per il controllo e l'amministrazione di Power BI. Le API di amministrazione sono sempre di sola lettura e potrebbero non avere autorizzazioni concesse in Microsoft Entra ID (solo impostazione del tenant di Power BI). Amministratori di Power BI e Center of Excellence
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp Gestire il tenant di Power BI. Sono necessarie autorizzazioni di lettura/scrittura per creare o aggiornare le risorse. Amministratori di Power BI e Center of Excellence
GraphData-Read-PowerBIAdministrators-EntraApp Estrarre i dati di utenti e gruppi per il controllo e l'amministrazione di Power BI. Richiede l'autorizzazione di lettura. Amministratori di Power BI e Center of Excellence

La gestione di più registrazioni di app per scopi diversi comporta un maggiore impegno. Tuttavia, è possibile sfruttare diversi vantaggi.

  • Vedere quale registrazione dell'app si vuole usare e perché: quando viene visualizzato l'ID client dalla registrazione dell'app nei dati di controllo, si avrà un'idea di cosa è stato usato e perché. Questo è un vantaggio significativo della creazione di registrazioni di app separate (rispetto all'uso di un'unica registrazione per tutti gli scopi).
  • Vedere chi deve usare la registrazione dell'app: quando viene visualizzato l'ID client dalla registrazione dell'app nei dati di controllo, si avrà un'idea di chi la stava usando.
  • Evitare l'overprovisioning delle autorizzazioni: è possibile seguire il principio dei privilegi minimi fornendo registrazioni di app separate a diversi set di persone che hanno esigenze diverse. È possibile evitare l'overprovisioning delle autorizzazioni usando una registrazione dell'app di sola lettura quando le autorizzazioni di scrittura non sono necessarie. Ad esempio, potrebbero essere presenti alcuni utenti self-service altamente capaci che vogliono raccogliere dati sui modelli semantici; in questo caso, devono accedere a un'entità servizio con autorizzazione di lettura. Considerando che potrebbero esserci membri satellite del Center of Excellence che lavorano per il team finanziario e che gestiscono a livello di codice i modelli semantici, dovranno accedere a un'entità servizio con autorizzazione di scrittura.
  • Sapere chi deve essere in possesso del segreto: il segreto per ogni registrazione dell'app deve essere condiviso solo con le persone che ne hanno bisogno. Quando il segreto viene ruotato (operazione descritta più avanti in questa sezione), l'impatto è minore quando si usano registrazioni di app separate per esigenze diverse. Questo è utile quando è necessario ruotare il segreto perché un utente lascia l'organizzazione o modifica i ruoli.
Autorizzazioni per la registrazione di app

Esistono due modi principali per accedere ai dati e alle risorse di una registrazione dell'app. Include autorizzazioni e consenso.

  • Autorizzazioni solo app: l'accesso e l'autorizzazione vengono gestiti dall'entità servizio senza un utente connesso. Questo metodo di autenticazione è utile per gli scenari di automazione. Quando si usano autorizzazioni solo app, è fondamentale comprendere che le autorizzazioni non vengono assegnate in Microsoft Entra ID. Le autorizzazioni vengono invece assegnate in uno dei due modi seguenti:
    • Per l'esecuzione di API di amministrazione: alcune impostazioni del tenant di Power BI consentono l'accesso agli endpoint per le API di amministrazione (che restituiscono metadati di controllo a livello di tenant). Per altre informazioni, vedere Configurare le impostazioni del tenant di Power BI più avanti in questo articolo.
    • Per l'esecuzione di API utente: si applicano le autorizzazioni di area di lavoro ed elementi di Power BI. Le autorizzazioni standard di Power BI controllano quali dati possono essere restituiti a un'entità servizio durante l'esecuzione di API utente (che restituiscono dati di controllo in base alle autorizzazioni dell'utente o dell'entità servizio che richiamano l'API).
  • Autorizzazioni delegate: vengono usate autorizzazioni basate sull'ambito. L'entità servizio accede ai dati per conto dell'utente attualmente connesso. Significa che l'entità servizio può accedere solo a ciò a cui può accedere l'utente connesso. Tenere presente che si tratta di un concetto diverso rispetto all'autenticazione solo utente, descritta in precedenza. Poiché un'applicazione personalizzata è necessaria per gestire correttamente la combinazione di autorizzazioni utente e app, le autorizzazioni delegate vengono usate raramente per gli scenari di controllo. Questo concetto è comunemente frainteso e causa molte registrazioni di app con provisioning eccessivo di autorizzazioni.

Importante

In questo articolo lo stato attivo riguarda solo l'autenticazione utente o l'autenticazione solo app. Le autorizzazioni delegate (con un utente interattivo e l'entità servizio) possono svolgere un ruolo importante durante l'incorporamento a livello di codice del contenuto di Power BI. Tuttavia, è consigliabile configurare autorizzazioni delegate per estrarre i dati di controllo. Ogni API limita la frequenza con cui può essere eseguita (con limitazione sul posto), quindi non è pratico avere utenti diversi che accedono direttamente ai dati di controllo non elaborati. È invece consigliabile estrarre i dati di controllo non elaborati una sola volta (con un processo centralizzato) e quindi rendere i dati di controllo curati disponibili per gli utenti autorizzati downstream.

Per altre informazioni, vedere Registrare un'app Microsoft Entra più avanti in questo articolo.

Segreti di registrazione app

Una registrazione dell'app ha spesso un segreto assegnato. Il segreto viene usato come chiave per l'autenticazione e ha una data di scadenza. Pertanto, è necessario pianificare come ruotare regolarmente la nuova chiave e come comunicarla agli utenti autorizzati.

È anche necessario preoccuparsi di dove archiviare in modo sicuro il segreto. Un insieme di credenziali delle password dell'organizzazione, ad esempio Azure Key Vault, è un'ottima scelta.

Suggerimento

Come approccio alternativo all'uso di un segreto, è possibile usare un'identità gestita. Un'identità gestita elimina la necessità di gestire le credenziali. Se si intende usare servizi come Funzioni di Azure o Azure Data Factory per estrarre i dati, un'identità gestita è un'ottima opzione da prendere in considerazione.

Gestire in modo sicuro le credenziali

Indipendentemente dal fatto che si usi l'autenticazione utente o l'autenticazione dell'entità servizio, una delle principali sfide consiste nel gestire in modo sicuro password, segreti e chiavi.

Attenzione

La prima regola è quella che molte persone violano: le password e le chiavi non dovrebbero mai apparire in testo non crittografato in uno script. Molti articoli, blog ed esempi online lo fanno per semplicità. Tuttavia, è una pratica scadente che dovrebbe essere evitata. Chiunque ottenga lo script (o il file) può potenzialmente ottenere l'accesso agli stessi dati a cui l'autore può accedere.

Ecco diversi metodi sicuri che è possibile usare per gestire password, segreti e chiavi.

  • Eseguire l'integrazione con Azure Key Vault o un altro sistema dell'insieme di credenziali delle password dell'organizzazione, quando possibile.
  • Usare credenziali e stringhe sicure negli script di PowerShell. Una credenziale funziona sia per l'autenticazione utente che per l'autenticazione dell'entità servizio. Tuttavia, non è possibile usare credenziali quando l'autenticazione a più fattori è abilitata per un account utente.
  • Richiedere una password nello script di PowerShell o usare l'autenticazione interattiva con un browser.
  • Usare il modulo Gestione segreti per PowerShell pubblicato da Microsoft. Può archiviare i valori usando un insieme di credenziali locale. Può anche essere integrato con un Azure Key Vault remoto, un approccio utile quando nell'organizzazione sono presenti più amministratori che lavorano con gli stessi script.
  • Creare un connettore personalizzato per Power BI Desktop in modo che possa gestire in modo sicuro le credenziali. Alcuni connettori personalizzati sono disponibili dai membri della community (in genere in GitHub).

Suggerimento

È consigliabile rivolgersi ai team IT e della sicurezza per scegliere il metodo migliore o verificare che la soluzione gestisca le credenziali in modo sicuro.

Libreria di Autenticazione Microsoft

Il supporto per Azure AD Authentication Library (ADAL) è terminato nel dicembre 2022. In futuro, è consigliabile usare Microsoft Authentication Library (MSAL). Il team di sicurezza dell'organizzazione deve avere familiarità con questo cambiamento significativo.

Anche se non è importante per i professionisti di Power BI comprendere in modo approfondito la transizione a MSAL, è consigliabile attenersi alle raccomandazioni seguenti.

  • Usare la versione più recente del modulo di gestione di Power BI quando si esegue l'autenticazione con il cmdlet di PowerShell Connect-PowerBIServiceAccount. È passato da ADAL a MSAL nella versione 1.0.946 (26 febbraio 2021).
  • Usare l'endpoint Microsoft Entra V2 quando si esegue l'autenticazione direttamente nello script. L'endpoint Microsoft Entra V2 usa MSAL, mentre l'endpoint Microsoft Entra V1 usa ADAL.
  • Interrompere l'uso di API e moduli deprecati. Per altre informazioni, vedere API e moduli deprecati più avanti in questo articolo.
  • Se si trova una soluzione della community online, assicurarsi che usi MSAL per l'autenticazione anziché ADAL.

Elenco di controllo: quando si decide come gestire l'autenticazione, le decisioni chiave e le azioni includono:

  • Decidere quale tipo di autenticazione usare: determinare se l'autenticazione utente o l'autenticazione dell'entità servizio sia più adatta, a seconda del tipo di soluzione di controllo che si intende creare.
  • Pianificare le registrazioni delle app necessarie: prendere in considerazione i requisiti, i carichi di lavoro e i destinatari (utenti di ogni registrazione dell'app). Pianificare il numero di registrazioni di app che è necessario creare per supportare queste esigenze.
  • Creare una convenzione di denominazione per le registrazioni di app: configurare una convenzione di denominazione che semplifichi la comprensione dello scopo previsto e degli utenti previsti di ogni registrazione dell'app.
  • Pianificare la gestione sicura delle credenziali: prendere in considerazione i modi per gestire in modo sicuro password, segreti e chiavi. Prendere in considerazione la documentazione e il training necessari.
  • Confermare l'uso di MSAL: determinare se sono presenti soluzioni di controllo manuali o automatizzate esistenti che si basano su ADAL. Se necessario, creare un piano per riscrivere queste soluzioni in modo da usare la nuova libreria di autenticazione MSAL.

Scegliere un'API utente o un'API amministratore

Quando si prevede di recuperare i dati di controllo, è importante usare il tipo corretto di API.

Esistono due tipi di API da considerare.

  • API utente: fare affidamento sulle autorizzazioni dell'utente connesso (o dell'entità servizio) per inviare richieste all'API. Ad esempio, un modo per restituire un elenco di modelli semantici in un'area di lavoro è con un'API utente. L'autorizzazione per i modelli semantici di lettura può essere concessa dal ruolo dell'area di lavoro o dalle autorizzazioni per elemento. Esistono due modi per eseguire le API utente:
    • Autenticazione utente: l'utente connesso deve avere l'autorizzazione per accedere all'area di lavoro o all'elemento.
    • Autenticazione dell'entità servizio: l'entità servizio deve disporre dell'autorizzazione per accedere all'area di lavoro o all'elemento.
  • API di amministrazione: recuperare i metadati dal tenant. Viene talvolta definito ambito dell'organizzazione. Ad esempio, per restituire un elenco di tutti i modelli semantici nel tenant, si usa un'API di amministrazione. Esistono due modi per eseguire le API di amministrazione:
    • Autenticazione utente: l'utente connesso deve essere un amministratore di Power BI per eseguire le API di amministratore.
    • Autenticazione dell'entità servizio: l'entità servizio deve avere l'autorizzazione per eseguire le API di amministratore (senza basarsi sulle autorizzazioni di sicurezza come un'API utente).

Suggerimento

Tutte le API di amministrazione appartengono al gruppo Operazioni di amministrazione. Qualsiasi API con il suffisso come amministratore è un'API amministratore; tutte le API rimanenti sono API utente.

Si consideri un esempio in cui è necessario ottenere un elenco di modelli semantici. La tabella seguente illustra sei opzioni API che è possibile usare per eseguire questa operazione. Quattro opzioni sono le API utente e due opzioni sono le API di amministrazione. L'ambito e il numero di elementi restituiti sono diversi, a seconda dell'API scelta.

Nome API Tipo di API Scope Numero di modelli semantici
Recupera set di dati User Area di lavoro personale Uno
Recupera set di dati User Area di lavoro personale Tutte le date
Recupera set di dati in gruppo User Un'area di lavoro Uno, purché l'utente connesso abbia l'autorizzazione per leggere il modello semantico
Recupera set di dati in gruppo User Un'area di lavoro Tutto, purché l'utente connesso disponga dell'autorizzazione per leggere ogni modello semantico
Recupera set di dati come amministratore Amministratore Un'area di lavoro Tutte le date
Recupera set di dati come amministratore Amministratore Intero tenant Tutte le date

Nota

Alcuni nomi di API includono il termine Gruppo come riferimento a un'area di lavoro. Questo termine ha origine dal modello di sicurezza originale di Power BI, che si basava sui gruppi di Microsoft 365. Anche se il modello di sicurezza di Power BI si è evoluto in modo significativo nel corso degli anni, i nomi delle API esistenti rimangono invariati per evitare di interrompere le soluzioni esistenti.

Per informazioni sulle impostazioni del tenant, vedere Configurare le impostazioni del tenant di Power BI più avanti in questo articolo.

Elenco di controllo: quando si sceglie se usare un'API utente o un'API amministratore, le decisioni chiave e le azioni includono:

  • Fare riferimento ai requisiti dei dati: raccogliere e documentare i requisiti aziendali principali per una soluzione di controllo. In base al tipo di dati necessari, determinare se sia appropriato un ambito utente o aziendale.
  • Testare i risultati: fare varie prove. Testare l'accuratezza dei risultati restituiti dalle diverse API.
  • Esaminare le autorizzazioni: per tutte le soluzioni di controllo esistenti, verificare che le autorizzazioni siano assegnate correttamente per gli amministratori e le entità servizio di Power BI. Per le nuove soluzioni di controllo, verificare quale metodo di autenticazione verrà usato.

Scegliere API o cmdlet di PowerShell

Una decisione chiave da prendere è se usare i cmdlet di PowerShell quando questi sono disponibili per i dati specifici da recuperare. Questa decisione è importante se si è deciso che PowerShell è una delle tecnologie che si useranno per accedere ai dati di controllo.

PowerShell è una soluzione di automazione delle attività. Il termine PowerShell è un termine collettivo che fa riferimento al linguaggio di scripting, a un'applicazione della shell della riga di comando e a un framework di gestione della configurazione. PowerShell Core è la versione più recente di PowerShell, che viene eseguita in Windows, Linux e macOS.

Un cmdlet di PowerShell è un comando che esegue un'azione. Un modulo di PowerShell è un pacchetto che contiene membri di PowerShell, ad esempio cmdlet, provider, funzioni, flussi di lavoro, variabili e alias. Scaricare e installare i moduli.

Un modulo di PowerShell crea un livello di astrazione sulle API. Ad esempio, il cmdlet Get-PowerBIActivityEvent recupera (o ottiene) eventi di controllo per un tenant di Power BI. Questo cmdlet di PowerShell recupera i dati dall'API REST Get Activity Events. In genere, è più semplice iniziare usando i cmdlet perché si semplifica l'accesso alle API sottostanti.

Solo un subset delle API è disponibile come cmdlet di PowerShell. Man mano che si continua ad espandere l'intera soluzione di controllo, è probabile che si userà una combinazione di cmdlet e API. La parte restante di questa sezione consente di decidere in quale modo si accederà ai dati.

Moduli PowerShell

Microsoft ha pubblicato due moduli di PowerShell contenenti cmdlet correlati a Power BI. Si tratta del modulo di gestione di Power BI e del modulo Gateway dati. Questi moduli di PowerShell fungono da wrapper API sopra le API REST di Power BI sottostanti. L'uso di questi moduli di PowerShell può semplificare la scrittura di script.

Suggerimento

Oltre ai moduli pubblicati da Microsoft, sono disponibili gratuitamente moduli e script di PowerShell pubblicati (in genere in GitHub) dai membri della community di Power BI, dai partner e dai Most Valued Professional (MVP) Microsoft.

Partire da una soluzione della community può essere una buona idea per la creazione della soluzione di controllo end-to-end. Se si sceglie di usare una soluzione disponibile gratuitamente, assicurarsi di testarla completamente. Acquisire familiarità con il funzionamento in modo da poter gestire in modo efficace la soluzione nel tempo. Il reparto IT potrebbe avere criteri per l'uso di soluzioni della community disponibili pubblicamente.

Modulo di gestione di Power BI

Il modulo di gestione di Power BI è un modulo di rollup che contiene moduli di Power BI specifici per amministrazione, capacità, aree di lavoro e altro ancora. È possibile scegliere di installare il modulo di rollup per ottenere tutti i moduli oppure installare moduli specifici. Tutti i moduli di gestione di Power BI sono supportati sia in Windows PowerShell che in PowerShell Core.

Importante

È consigliabile interrompere l'uso di Windows PowerShell (che non è in grado di eseguire PowerShell Core). Usare invece uno degli editor di codice moderni che supporta PowerShell Core. Windows PowerShell ISE (ambiente di script integrato) è in grado di eseguire solo PowerShell versione 5.1, che non è più aggiornata. Windows PowerShell è ora deprecato, quindi è consigliabile usare PowerShell Core per tutte le nuove attività di sviluppo.

Di seguito sono riportati diversi cmdlet comunemente usati che è possibile usare per recuperare i dati di controllo.

Modulo di gestione Cmdlet Scopo
Profilo Connect-PowerBIServiceAccount Autenticare un utente o un'entità servizio di Power BI.
Amministratore Get-PowerBIActivityEvent Visualizzare o estrarre gli eventi del log attività di Power BI per il tenant.
Aree di lavoro Get-PowerBIWorkspace Compilare un elenco di aree di lavoro.
Report Get-PowerBIReport Compilare un elenco di report per un'area di lavoro o il tenant.
Dati Get-PowerBIDataset Compilare un elenco di modelli semantici per un'area di lavoro o il tenant.
Profilo Invoke-PowerBIRestMethod Inviare una richiesta API REST (comando). Questo cmdlet è un'opzione valida perché può richiamare qualsiasi API REST di Power BI. È anche una buona scelta quando si vuole usare la forma più semplice di autenticazione tramite il cmdlet Connect-PowerBIServiceAccount e poter richiamare un'API che non dispone di un cmdlet di PowerShell corrispondente. Per altre informazioni, vedere Considerazioni sull'uso dei cmdlet di PowerShell più avanti in questa sezione.

Suggerimento

Sono disponibili altri cmdlet per la gestione e la pubblicazione del contenuto. Tuttavia, l'obiettivo di questo articolo è il recupero dei dati di controllo.

È possibile scaricare il modulo di gestione di Power BI da PowerShell Gallery. Il modo più semplice per installare i moduli consiste nell'usare PowerShellGet.

È consigliabile installare il modulo di rollup di gestione di Power BI. In questo modo, tutti i cmdlet necessari potrebbero essere disponibili. Sono necessari almeno il modulo Profilo (per l'autenticazione) e tutti i moduli specifici che contengono i cmdlet da usare.

Attenzione

Assicurarsi di mantenere aggiornati i moduli in ogni server, computer utente e servizio cloud, ad esempio Automazione di Azure, in cui si usa PowerShell. Se i moduli non vengono aggiornati regolarmente, potrebbero verificarsi errori o problemi imprevedibili. Alcuni strumenti (ad esempio Visual Studio Code) consentono di mantenere aggiornati i moduli. Tenere inoltre presente che PowerShellGet non disinstalla automaticamente versioni precedenti di un modulo quando si installa o si aggiorna una versione più recente. Vengono installate versioni più recenti insieme a quelle precedenti. È consigliabile controllare le versioni installate e disinstallare periodicamente quelle precedenti.

Modulo Gateway dati

Il modulo Gateway dati contiene cmdlet che recuperano dati da un gateway dati locale e dalle relative origini dati. Il modulo Gateway dati è supportato solo in PowerShell Core. Non è supportato in Windows PowerShell.

A differenza del modulo di gestione di Power BI (descritto in precedenza), il modulo Gateway dati non include cmdlet di amministrazione. Molti dei cmdlet (e delle API gateway corrispondenti), richiedono che l'utente disponga dei diritti di amministratore del gateway.

Avviso

Non è possibile assegnare un'entità servizio come amministratore del gateway (anche quando l'entità servizio è membro di un gruppo di sicurezza). Pertanto, pianificare l'uso delle credenziali utente durante il recupero di informazioni sui gateway dati.

Di seguito sono riportati diversi cmdlet del modulo Gateway dati che è possibile usare per recuperare i dati di controllo.

Cmdlet Scopo
Connect-DataGatewayServiceAccount Autenticare un utente di Power BI (in genere richiede che l'utente appartenga al ruolo di amministratore del gateway).
Get-DataGatewayCluster Compilare un elenco di cluster gateway.
Get-DataGatewayClusterDataSource Compilare un elenco di origini dati per un cluster gateway.
Get-DataGatewayInstaller Verificare quali utenti sono autorizzati a installare e registrare i gateway nell'organizzazione.

È possibile scaricare il modulo Gateway dati da PowerShell Gallery.

Tecniche per l'uso di PowerShell

È possibile usare PowerShell in diversi modi. La decisione presa è importante.

La tabella seguente descrive tre tecniche diverse per l'uso di PowerShell.

Tecnica Descrizione Esempio
Usare i cmdlet di PowerShell per semplificare l'autenticazione e chiamare direttamente le API. Approccio consigliato Con questa tecnica, c'è un equilibrio tra semplicità e flessibilità. Il cmdlet Invoke-PowerBIRestMethod è disponibile nel modulo Profilo di gestione di Power BI. Questo cmdlet viene spesso definito "coltellino svizzero" perché è possibile usarlo per chiamare una qualsiasi delle API REST di Power BI. Il vantaggio dell'uso di questa tecnica è la possibilità di semplificare l'autenticazione e quindi chiamare qualsiasi API REST di Power BI. Si consiglia fortemente di usare questa tecnica. Dopo l'autenticazione con il cmdlet Connect-PowerBIServiceAccount, usare il cmdlet Invoke-PowerBIRestMethod per recuperare dati dall'API preferita, ad esempio Ottenere utenti della pipeline come amministratore.
Usare i cmdlet di PowerShell il più possibile, sia per l'autenticazione che per il recupero dei dati. Con questa tecnica, PowerShell viene usato ampiamente. PowerShell viene usato per coordinare l'esecuzione dello script e i moduli di PowerShell vengono usati quando possibile per l'accesso ai dati. In questo modo si crea una dipendenza maggiore da PowerShell in più aspetti. Dopo l'autenticazione con il cmdlet Connect-PowerBIServiceAccount, usare un cmdlet come Get-PowerBIActivityEvent per recuperare i dati.
Usare PowerShell solo per coordinare l'esecuzione del processo. I moduli di PowerShell vengono usati il minor tempo possibile. Con questa tecnica, c'è meno dipendenza da PowerShell come strumento perché l'uso principale consiste nell'orchestrare le chiamate API. Per accedere alle API viene usato un solo modulo di PowerShell generico (non vengono usati moduli dai moduli di gestione di Power BI). Dopo l'autenticazione tramite Microsoft Authentication Library (MSAL), chiamare l'API preferita, ad esempio Ottenere utenti della pipeline come amministratore, usando il cmdlet Invoke-RestMethod generico per recuperare i dati.

Nella tabella precedente la prima tecnica descrive un approccio che bilancia la facilità d'uso con la flessibilità. Questo approccio offre il miglior equilibrio per le esigenze della maggior parte delle organizzazioni, motivo per cui è consigliabile. Alcune organizzazioni potrebbero avere criteri IT e preferenze del personale esistenti che influenzano il modo in cui si decide di usare PowerShell.

Suggerimento

È possibile usare il cmdlet di PowerShell Invoke-ASCmd per creare ed eseguire script DAX, XMLAe TMSL. Tuttavia, questi casi d'uso non rientrano nell'ambito di questo articolo. Per altre informazioni sull'esecuzione di query sulle viste a gestione dinamica, vedere Controllo a livello di dati.

Gli utenti tecnici (e gli amministratori) possono usare i moduli di gestione di Power BI per recuperare i dati o automatizzare determinati aspetti della gestione dei contenuti.

  • Per gli amministratori: impostare il parametro -Scope su Organization per accedere alle entità nell'intero tenant, ad esempio per recuperare un elenco di tutte le aree di lavoro.
  • Per gli utenti tecnici: impostare il parametro -Scope su Individual (o ometterlo) per accedere alle entità che appartengono all'utente, ad esempio per recuperare un elenco di aree di lavoro a cui l'utente ha l'autorizzazione ad accedere.

Si consideri uno scenario in cui è necessario ottenere un elenco di modelli semantici. Se si sceglie di usare direttamente le API, è necessario specificare l'API da chiamare. Tuttavia, se si sceglie di usare il cmdlet Get-PowerBIDataset, è possibile impostare il parametro -Scope per recuperare un elenco semantico specifico dell'utente o a livello di tenant. La scelta dipende dalla decisione relativa all'uso di PowerShell (illustrato nella tabella precedente).

Nella tabella seguente viene descritto il modo in cui i parametri usati nel cmdlet di PowerShell vengono convertiti nelle chiamate API di PowerShell.

Parametri del cmdlet API usata dal cmdlet Tipo di API Scope Elementi recuperati
-DatasetID {DatasetID}
-Scope Individual		 Recupera set di dati User Area di lavoro personale Un modello semantico
-Scope Individual Recupera set di dati User Area di lavoro personale Tutti i modelli semantici
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Recupera set di dati in gruppo User Un'area di lavoro Un modello semantico, purché l'utente connesso abbia l'autorizzazione per leggere il modello semantico
-GroupID {WorkspaceID} Recupera set di dati in gruppo User Un'area di lavoro Tutti i modelli semantici, purché l'utente connesso abbia l'autorizzazione per accedere all'area di lavoro e leggere il modello semantico
-GroupID {WorkspaceID}
-Scope Organization		 Recupera set di dati come amministratore Amministratore Un'area di lavoro Tutti i modelli semantici
-Scope Organization Recupera set di dati come amministratore Amministratore Intero tenant Tutti i modelli semantici
Considerazioni sull'uso dei cmdlet di PowerShell

I cmdlet PowerShell di Power BI sono più semplici da usare perché astraggono alcune delle complessità delle chiamate API REST.

Ecco alcuni dei modi in cui i cmdlet semplificano l'accesso ai dati di controllo.

  • Autenticazione: il modo più semplice per eseguire l'autenticazione in uno script di PowerShell consiste nell'usare il cmdlet Connect-PowerBIServiceAccount.
  • Semplicità: è più semplice iniziare perché le tecniche per recuperare i dati di controllo sono semplici. Si consideri che quando si usa il cmdlet Get-PowerBIActivityEvent, si recupera un giorno di dati di controllo. Tuttavia, quando si chiama direttamente l'API REST Get Activity Events, si recupera un'ora di dati di controllo. Pertanto, quando si usa l'API REST per recuperare un giorno di dati di controllo, è necessario usare un ciclo per chiamare l'API 24 volte per estrarre ogni ora del giorno.
  • Paginazione di set di risultati di grandi dimensioni: i set di risultati di grandi dimensioni vengono recuperati in modo efficiente dalla paginazione. L'impaginazione comporta il recupero di un blocco dei risultati alla volta. I cmdlet gestiscono automaticamente la paginazione. Tuttavia, quando si usano direttamente le API REST, lo script deve controllare un token di continuazione per determinare se sono presenti altri risultati da ottenere. Lo script deve continuare a recuperare blocchi di risultati fino a quando non vengono ricevuti token di continuazione. Per un esempio di uso di un token di continuazione, vedere API REST di eventi attività.
  • Scadenza del token di accesso: al momento dell'autenticazione viene restituito un token di accesso. Per impostazione predefinita, scade dopo un'ora. I cmdlet gestiscono automaticamente le scadenze dei token di accesso. In questo modo, non è necessario scrivere la logica per richiedere un token di aggiornamento.
  • Formattazione: i dati restituiti da un cmdlet sono leggermente più eleganti dei dati restituiti dall'API REST. L'output è più facile da usare. Per i processi di controllo automatizzati, probabilmente non si tratta di un problema. Tuttavia, per i processi di controllo manuali la formattazione più elegante potrebbe essere utile.
Considerazioni sull'uso diretto delle API REST

A volte esistono vantaggi se si chiamano direttamente le API REST di Power BI.

  • Disponibili molte altre API: sono disponibili più API REST rispetto ai cmdlet di PowerShell. Tuttavia, non trascurare la flessibilità del cmdlet Invoke-PowerBIRestMethod, che è possibile usare per chiamare una qualsiasi delle API REST di Power BI.
  • Frequenza degli aggiornamenti: Microsoft aggiorna le API REST più frequentemente rispetto agli aggiornamenti dei moduli di PowerShell. Ad esempio, se un nuovo attributo viene aggiunto alla risposta Get Dataset dell'API, potrebbe essere necessario del tempo prima che diventi disponibile nei risultati del cmdlet Get-PowerBIDataset.
  • Meno dipendenza da linguaggi/strumenti: quando si usano direttamente le API REST (anziché un cmdlet), non è necessario usare PowerShell. In alternativa, è possibile scegliere di usare PowerShell solo per orchestrare la chiamata a molte API in uno script. Rimuovendo (o evitando) qualsiasi dipendenza da PowerShell, in futuro sarà possibile riscrivere la logica in un linguaggio diverso. Quando il team IT o sviluppatore ha preferenze forti per strumenti e linguaggi, una minore dipendenza può essere una considerazione importante da fare.

Indipendentemente dal metodo che si sceglie di usare, le API REST possono cambiare nel tempo. Quando una tecnologia si evolve, le API (e i moduli di PowerShell) possono essere deprecate e sostituite. È pertanto consigliabile creare script semplici da gestire e resilienti alle modifiche.

Elenco di controllo: quando si sceglie se accedere alle API REST direttamente o usando i cmdlet di PowerShell, le decisioni chiave e le azioni includono:

  • Consultare l'IT sull'uso di PowerShell: contattare i team IT pertinenti per determinare se sono presenti requisiti interni o preferenze su come usare PowerShell.
  • Decidere come usare PowerShell: determinare le tecniche di PowerShell da usare e se si vuole aumentare o ridurre intenzionalmente la dipendenza da PowerShell. Valutare se siano necessarie la comunicazione interna o la formazione.
  • Eseguire l'aggiornamento a PowerShell Core: ricercare con PowerShell Core. Determinare se i computer amministratore devono essere aggiornati. Considerare quali script esistenti devono essere testati. Determinare se gli amministratori o gli sviluppatori devono avere una formazione aggiuntiva per aggiornare le proprie competenze.
  • Determinare quali moduli di PowerShell usare: valutare se verranno usati i moduli di gestione di Power BI e/o il modulo Gateway dati.
  • Decidere se i progetti della community sono consentiti: determinare se è consentito (o addirittura incoraggiato) l'uso dei moduli di PowerShell disponibili online (rispetto ai moduli pubblicati da Microsoft). Rivolgersi all'IT per determinare se sono presenti criteri per i progetti della community ottenuti online.
  • Chiarire come supportare i progetti della community: se sono consentiti progetti della community di PowerShell, prendere in considerazione chi sarà responsabile di supportarli una volta usati internamente.
  • Completare un modello di verifica (POC) di piccole dimensioni: Provare un modello di verifica tecnico. Verificare gli strumenti client preferiti e il metodo di accesso ai dati.
  • Determinare come supportare gli utenti avanzati: considerare come si intende supportare gli utenti tecnici che creano l'automazione autonomamente usando le API utente.

Determinare dove archiviare i dati di controllo

Quando si prevede di creare una soluzione di controllo end-to-end, è necessario decidere dove archiviare i dati non elaborati e i dati curati, un'operazione illustrata nella sezione successiva. Le decisioni relative all'archiviazione dei dati sono correlate alle preferenze per gestire l'integrazione dei dati.

Quando si estraggono dati di controllo non elaborati, mantenerli semplici. È consigliabile non selezionare attributi specifici, eseguire trasformazioni o applicare alcuna formattazione quando si estraggono inizialmente i dati. Estrarre invece tutti gli attributi disponibili e archiviare i dati nello stato originale.

Ecco diversi motivi per cui l'archiviazione dei dati non elaborati nello stato originale è una procedura consigliata.

  • Tutti i dati disponibili nella cronologia: nuovi attributi e nuovi tipi di eventi diventeranno disponibili nel tempo. L'archiviazione di tutti i dati non elaborati è un buon modo per assicurarsi di avere sempre accesso a tutti i dati disponibili al momento dell'estrazione. Anche se è necessario molto tempo (persino settimane o mesi) per rendersi conto che sono disponibili nuovi attributi di dati, è possibile analizzarli storicamente perché sono stati acquisiti nei dati non elaborati.
  • Resiliente alla modifica: se il formato dati non elaborati cambia, il processo che estrae i dati non è interessato. Poiché alcuni dati di controllo sono sensibili al tempo, è importante assicurarsi di progettare un processo di estrazione dati che non avrà esito negativo quando si verifica una modifica nell'origine.
  • Ruoli e responsabilità: membri del team diversi (come ingegneri dei dati o amministratori di Fabric) potrebbero essere responsabili della creazione dei processi per accedere, estrarre e archiviare i dati di controllo non elaborati. Semplificare il processo di estrazione dei dati permette a più team di collaborare.

Ecco alcune opzioni per l'archiviazione di dati non elaborati.

  • Data lake o archiviazione di oggetti: un servizio cloud, ad esempio OneLake specializzato nell'archiviazione di file di qualsiasi struttura. È una scelta ideale per archiviare i dati di controllo non elaborati. In un'architettura data lake, i dati non elaborati devono essere archiviati nel livello bronze.
  • File system: un file system (ad esempio Windows o Linux) è una scelta comune per l'archiviazione dei dati di controllo non elaborati.
  • database: è possibile archiviare dati JSON in un database relazionale, ad esempio Database SQL di Azure. Tuttavia, è meno comune rispetto all'archiviazione dei dati in un data lake o in un file system. Ciò è dovuto al fatto che l'esecuzione di query e la gestione dei dati JSON possono diventare complesse e costose, soprattutto quando i volumi di dati aumentano.

Suggerimento

Quando si usa un data lake, un archivio oggetti o un file system, è consigliabile archiviare i dati in modo semplice da organizzare e proteggere. È anche importante chiarire se i dati comprendono eventi (che in genere vengono accodati) o se si tratta di uno snapshot temporizzato (che richiede la selezione di una data da analizzare).

Si consideri un esempio relativo a una zona dati non elaborata di un data lake. La zona ha una gerarchia di cartelle per l'archiviazione dei dati del log attività: Raw > ActivityLog > AAAA > MM. Le cartelle vengono partizionate per anno e mese. Un file archiviato nella cartella del mese usa il formato seguente: PBIActivityLog-AAAAMMGG-AAAAMMGGTTTT.json. AAAAAMMGG rappresenta i dati effettivi e AAAAAMMGGTTTT rappresenta il timestamp di estrazione. Includendo il timestamp di estrazione, è possibile determinare quale sia l'ultimo file (nel caso in cui sia necessario estrarre nuovamente i dati). Ad esempio, se si estraggono dati alle 9:00 (UTC) il 25 aprile 2023 per l'attività il 23 aprile 2023, il nome del file sarà PBIActivityLog-20230523-202305250900.

È consigliabile usare una tecnologia che consenta di scrivere i dati non elaborati nell'archiviazione non modificabile. L'archiviazione non modificabile garantisce che, una volta scritti i dati, non sia possibile sovrascriverli o eliminarli. Questa distinzione è importante per i revisori e consente di considerare attendibili i dati non elaborati.

È anche necessario considerare come archiviare in modo sicuro i dati non elaborati. In genere, pochissimi utenti richiedono l'accesso ai dati non elaborati. L'accesso ai dati non elaborati viene in genere fornito in base alle esigenze, solitamente per i data engineer e gli amministratori di sistema. Anche i revisori interni potrebbero richiedere l'accesso. I membri del team responsabili della creazione dei dati curati (descritti di seguito) richiedono anche l'accesso ai dati non elaborati.

Ecco alcune considerazioni per aiutare nella scelta dell'archiviazione di dati non elaborati.

  • Si tratta di un processo di controllo manuale o automatizzato? Un processo di controllo automatizzato presenta in genere requisiti più rigorosi per la modalità e la posizione in cui vengono archiviati i dati.
  • L'area di interesse è particolarmente sensibile? A seconda del tipo di dati e della relativa riservatezza, l'organizzazione potrebbe avere un requisito per la modalità e la posizione in cui questi vengono archiviati. I dati di controllo di Power BI contengono informazioni sull'utente e indirizzi IP, quindi devono essere archiviati in un'area sicura.
  • Esiste una tecnologia di archiviazione preferita? Potrebbe esserci una tecnologia di archiviazione esistente in uso all'interno dell'organizzazione, quindi è una scelta logica.
  • Gli utenti accederanno direttamente all'archiviazione? Il modello di sicurezza è una considerazione importante. In genere, a pochi utenti viene concesso l'accesso ai dati non elaborati. L'accesso ai dati curati viene in genere reso disponibile agli autori di contenuti di Power BI responsabili della creazione del modello di dati centralizzato (il modello semantico che funge da livello per la creazione di report).
  • Sono previsti requisiti di residenza dei dati? Alcune organizzazioni hanno requisiti di residenza dei dati legali o normativi per archiviare i dati in un'area dati specifica.
  • Come verranno organizzati i dati? L'uso dell'architettura medallion è una pratica comune, in particolare nelle implementazioni data lake e lakehouse. L'obiettivo è archiviare i dati in livelli di dati bronze, silver e gold. Il livello bronzo contiene i dati non elaborati originali. Il livello silver contiene dati convalidati e deduplicati usati per le trasformazioni. Il livello oro contiene i dati curati e altamente raffinati pronti per l'analisi.

Elenco di controllo: quando si pianifica la posizione in cui archiviare i dati non elaborati, le decisioni chiave e le azioni includono:

  • Consultare l'IT: contattare i team IT pertinenti per determinare se sono in esecuzione processi esistenti per estrarre i dati di controllo non elaborati. In tal caso, verificare se è possibile accedere ai dati esistenti. Se è necessario un nuovo processo di estrazione dei dati, determinare se sono presenti preferenze o requisiti per la posizione in cui archiviare i dati.
  • Decidere dove archiviare i dati non elaborati: determinare la posizione e la struttura di archiviazione migliori per l'archiviazione dei dati non elaborati.
  • Determinare i requisiti di residenza dei dati: scoprire se sono presenti requisiti legali o normativi per cui è possibile archiviare i dati.
  • Creare una struttura di cartelle e una convenzione di denominazione: determinare quale convenzione di denominazione usare per i file di dati non elaborati, inclusa la struttura di cartelle. Includere questi dettagli nella documentazione tecnica.
  • Valutare il funzionamento della sicurezza per i dati non elaborati: mentre si progetta il percorso di archiviazione dei dati non elaborati, considerare chi dovrà accedere ai dati e come verrà concesso l'accesso.

Pianificare la creazione di dati curati

I dati curati supportano l'analisi e sono progettati per essere intuitivi. È necessario prendere alcune decisioni su come e dove verranno creati i dati curati. La tecnologia che si sceglie per archiviare i dati curati potrebbe essere una di quelle elencate nella sezione precedente.

L'obiettivo dei dati curati è trasformare i dati in un formato più descrittivo ottimizzato per l'analisi e la creazione di report. Costituisce l'origine dati di un modello di dati di Power BI, il che significa che si usa un modello di dati di Power BI per analizzare l'utilizzo di Power BI nell'organizzazione. Si applicano le linee guida fondamentali sul modello di dati: è consigliabile adottare una progettazione con schema a stella, ottimizzata per prestazioni e usabilità.

È possibile scegliere di creare dati curati in modi diversi. È necessario decidere come eseguire l'integrazione dei dati e quanto far estendere l'upstream per applicare le trasformazioni che preparano i dati per il caricamento in uno schema a stella.

Data lake

È possibile applicare trasformazioni e creare file di dati curati in un data lake. È consigliabile usare un livello oro per i dati curati in modo che sia logicamente separato dai dati non elaborati archiviati nel livello bronzo. La separazione dei dati nei livelli semplifica anche l'impostazione di autorizzazioni di accesso utente diverse.

Usare un data lake per trasformare e curare i dati quando:

  • Ci si aspetta che ci saranno più modelli di dati di Power BI necessari per la creazione di report (cosa che giustifica la creazione di un livello silver intermedio).
  • È necessario supportare più autori di contenuti self-service che devono accedere ai dati di controllo a livello di tenant.
  • Sono disponibili strumenti e processi esistenti da usare per trasformare e caricare i dati.
  • Si vuole ridurre al minimo la preparazione dei dati che deve essere eseguita (e potenzialmente duplicata) in uno o più modelli di dati di Power BI.
Modello di dati Power BI

Potrebbe essere possibile completare tutto il lavoro di trasformazione in Power BI. Usare Power Query per accedere e trasformare i dati dallo stato non elaborato al formato curato.

Usare un modello di dati di Power BI quando:

  • Si vuole semplificare l'architettura end-to-end e caricare il modello di dati direttamente dai dati non elaborati. L'aggiornamento incrementale consente di ridurre le durate degli aggiornamenti.
  • La preferenza consiste nell'eseguire tutte le operazioni di trasformazione durante il caricamento del modello di dati.
  • Si prevede di avere un modello di dati centralizzato per i dati di controllo a livello di tenant. Tutti i report (o altri modelli di dati) possono usare il modello semantico di Power BI centralizzato come origine.
  • Si vuole fornire l'accesso utente solo al modello semantico di Power BI centralizzato (e non ai dati di origine).

Suggerimento

Quando si creano i dati curati, impostarli in modo da poter eseguire di nuovo facilmente il processo per intervalli di date precedenti. Ad esempio, se si scopre che un nuovo attributo è apparso nei log di controllo tre mesi fa, sarà necessario poterlo analizzare da quando è apparso per la prima volta. La possibilità di ricaricare la cronologia dei dati curati è uno dei motivi per cui è importante archiviare i dati non elaborati nello stato originale (operazione descritta in precedenza in questo articolo).

Per altre informazioni sulle tabelle delle dimensioni e sulle tabelle dei fatti che è possibile includere nello schema a stella, vedere Creare un modello di dati più avanti in questo articolo.

Elenco di controllo: quando si pianifica come creare dati curati, le decisioni chiave e le azioni includono:

  • Decidere dove eseguire le trasformazioni: prendere in considerazione il lavoro di trasformazione a monte e il punto in cui rientra nel piano per l'intera architettura.
  • Decidere quale strumento usare per trasformare i dati in uno schema a stella: confermare quali strumenti e servizi verranno usati per trasformare i dati non elaborati in dati curati.
  • Decidere dove archiviare i dati curati: determinare la scelta migliore per archiviare i dati non elaborati trasformati in un formato di schema a stella. Decidere se un livello silver intermedio è utile nell'architettura end-to-end.
  • Creare una convenzione di denominazione: determinare quale convenzione di denominazione usare per i file di dati e le cartelle curati (se applicabile). Includere i dettagli nella documentazione tecnica.
  • Valutare il funzionamento della sicurezza per i dati curati: durante la progettazione del percorso di archiviazione dei dati curati, considerare chi dovrà accedere ai dati e come verrà assegnata la sicurezza.

Decisioni sull'origine dati

A questo punto, è necessario essere chiari in base ai requisiti, alle esigenze dei dati e alle autorizzazioni. Sono state prese decisioni tecniche chiave. È ora necessario prendere alcune decisioni sull'approccio per ottenere determinati tipi di dati.

Accedere ai dati dell'attività degli utenti

I dati dell'attività utente di Power BI, talvolta definiti log attività o log di controllo, includono un'ampia gamma di informazioni che consentono di comprendere cosa accade nel tenant di Power BI. Per altre informazioni sull'identificazione delle esigenze dei dati, vedere Dati attività utente più indietro in questo articolo.

Power BI integra i log con il log di controllo unificato di Microsoft Purview (noto in precedenza come log di controllo unificato di Microsoft 365). Questa integrazione è un vantaggio perché significa che ogni servizio all'interno di Microsoft 365 non deve implementare il proprio modo univoco di registrazione. È abilitata per impostazione predefinita.

Importante

Se non si estraggono già i dati dell'attività utente, fare in modo che sia una priorità urgente. I dati dell'attività utente sono disponibili per gli ultimi 30 o 90 giorni (a seconda dell'origine). Anche quando non si è pronti per eseguire analisi approfondite, è importante iniziare a estrarre e archiviare i dati il prima possibile. In questo modo, sarà disponibile per l'analisi una cronologia preziosa.

Sono disponibili diverse opzioni per recuperare i dati dell'attività utente.

Tecnica Descrizione Giorni predefiniti della cronologia disponibili Scelta ottimale per i processi di controllo manuali Scelta ottimale per i processi di controllo automatizzati Scelta consigliata per configurare gli avvisi Scelta ideale per iniziare rapidamente
Manuale (interfaccia utente) Portale di conformità di Microsoft Purview 90 Il Portale di conformità di Microsoft Purview è una scelta ideale per i processi di controllo manuali. Il portale di conformità di Microsoft Purview è una scelta ideale per iniziare rapidamente.
Manuale (interfaccia utente) Defender for Cloud Apps 30 Defender for Cloud Apps è una buona scelta per i processi di controllo manuali. Defender for Cloud Apps è una scelta ideale per configurare gli avvisi.
Programmatica Log attività di Power BI (cmdlet API o PowerShell) 30 Il log attività di Power BI (API o cmdlet di PowerShell) è una scelta ideale per i processi di controllo automatizzati. Il log attività di Power BI (API o cmdlet di PowerShell) è una scelta ottimale per iniziare rapidamente.
Programmatica API Office 365 Management Activity 7 L'API Attività di gestione di Office 365 è una buona scelta per i processi di controllo automatizzati.
Programmatica Microsoft Sentinel (Monitoraggio di Azure) 30 Microsoft Sentinel (Monitoraggio di Azure) è una scelta ideale per i processi di controllo automatizzati. Microsoft Sentinel (Monitoraggio di Azure) è una scelta ideale per configurare gli avvisi.

Nella parte restante di questa sezione vengono presentate le varie tecniche indicate nella tabella.

Portale di conformità di Microsoft Purview

Lo strumento di ricerca di controllo nel portale di conformità di Microsoft Purview (noto in precedenza come Centro conformità Microsoft 365) è una posizione comoda per visualizzare attività e avvisi. Questo strumento non richiede la creazione di uno script per estrarre e scaricare i dati. È possibile scegliere un carico di lavoro di Power BI per visualizzare tutti i record del log di controllo per un intervallo di tempo. È anche possibile limitare i risultati selezionando attività e utenti specifici. Ad esempio, un responsabile chiede di scoprire chi ha eliminato un'area di lavoro a inizio giornata, in modo che possa contattare rapidamente la persona per discutere la situazione.

Gli ultimi 90 giorni di cronologia sono disponibili con Audit (standard). Con Audit (Premium), la conservazione a lungo termine consente di conservare (facoltativamente) i log di controllo. Poiché la conservazione a lungo termine si applica solo agli utenti E5 con licenza, esclude i record di controllo per utenti non E5 e utenti guest. Pertanto, è consigliabile basarsi solo sulla cronologia predefinita di 90 giorni per assicurarsi che tutte le attività vengano acquisite.

Esistono requisiti di licenza per accedere ai log di controllo nel portale di conformità di Microsoft Purview. Per accedere ai log di controllo sono necessarie anche autorizzazioni elevate di Exchange Online.

Suggerimento

Per impostazione predefinita, gli amministratori di Power BI non hanno l'autorizzazione per accedere alla ricerca unificata dei log di controllo nel portale di conformità di Microsoft Purview. Poiché contiene dati per molti servizi di Microsoft 365, si tratta di un ruolo con privilegi elevati. Nella maggior parte delle organizzazioni, queste autorizzazioni sono riservate a un numero ridotto di amministratori IT. Sono disponibili altre opzioni per gli amministratori di Power BI, descritte più avanti in questa sezione.

L'interfaccia utente nel portale di conformità di Microsoft Purview è utile per i processi di controllo manuali e le indagini occasionali sulle attività degli utenti.

Defender for Cloud Apps

Il portale in Defender for Cloud Apps è una posizione comoda per visualizzare attività e avvisi senza la necessità di creare uno script per estrarre e scaricare i dati. Consente anche di visualizzare i dati dal log attività di Power BI e dagli accessi utente.

Defender for Cloud Apps include un'interfaccia utente per visualizzare e cercare i log attività per vari servizi cloud, tra cui Power BI. Visualizza gli stessi eventi di log che hanno origine nel log di controllo unificato di Microsoft Purview e include altri eventi come l'attività di accesso utente da Microsoft Entra ID.

Analogamente al portale di conformità di Microsoft Purview (descritto nella sezione precedente), Defender for Cloud Apps ha un'interfaccia utente ricercabile. Tuttavia, le opzioni di filtro sono diverse. Oltre alla cronologia standard di 30 giorni, è possibile usare Defender for Cloud Apps per visualizzare fino a sei mesi di cronologia dei log attività (in incrementi di sette giorni).

Esistono requisiti di licenza per accedere a Defender for Cloud Apps. Sono necessarie anche autorizzazioni separate.

Suggerimento

Per impostazione predefinita, gli amministratori di Power BI non hanno l'autorizzazione per accedere a Defender for Cloud Apps. È disponibile un ruolo Power BI in Defender for Cloud Apps. L'aggiunta di amministratori di Power BI a questo ruolo è un buon modo per concedere loro l'accesso a un set limitato di dati.

L'interfaccia utente in Defender for Cloud Apps è utile per i processi di controllo manuali e le indagini occasionali sulle attività degli utenti.

Log attività di Power BI

Il log attività di Power BI ha origine dal log di controllo unificato. Contiene solo le attività utente correlate al servizio Power BI.

Suggerimento

Per le organizzazioni che pianificano di estrarre le attività degli utenti, è consigliabile iniziare con il log attività di Power BI. È l'origine più semplice per accedere a livello di codice.

Sono disponibili due opzioni per accedere al log attività di Power BI.

Per informazioni su quale opzione usare, vedere Scegliere API o cmdlet di PowerShell in precedenza in questo articolo.

Suggerimento

Per esempi di come accedere al log attività di Power BI con PowerShell, vedere Accedere al log attività di Power BI.

I dati del log attività di Power BI sono disponibili per tutti gli amministratori di Fabric e gli amministratori di Power Platform. È possibile accedere ai dati dal log di controllo unificato, disponibile per determinati ruoli di Exchange Online. Per altre informazioni, vedere Tenere traccia delle attività degli utenti in Power BI.

È consigliabile usare il log attività di Power BI quando si intende recuperare solo i record del log di controllo di Power BI.

Nota

Nei dati del log di controllo le aree di lavoro vengono definite cartelle. Nell'API REST di Power BI le aree di lavoro vengono definite gruppi.

API Office 365 Management Activity

È possibile estrarre dati dal log di controllo unificato per altri servizi, ad esempio SharePoint Online, Teams, Exchange Online, Dynamics 365 e Power BI. Quando l'obiettivo è implementare una soluzione di controllo e monitoraggio per più servizi, è consigliabile usare l'API Office 365 Management Activity. Poiché questa API restituisce dati da molti servizi, è nota come API di controllo unificato (o log di controllo unificato). Si tratta di una delle API di gestione di Office 365.

Prima di creare una nuova soluzione, è consigliabile contattare il reparto IT per determinare se sono disponibili record di controllo di Power BI esistenti. È possibile che un processo estragga e archivi i dati. È anche possibile ottenere l'autorizzazione per accedere a questi dati anziché creare una nuova soluzione.

È possibile accedere ai dati in due modi.

Importante

Il cmdlet Search-UnifiedAuditLog non è scalabile in modo efficace e richiede di implementare una strategia con cicli per superare il limiti di 5.000 righe. Per questi motivi, è adatto a query occasionali o per organizzazioni di piccole dimensioni che riscontrano attività ridotte. Quando sono necessari solo i dati di Power BI, è consigliabile usare il cmdlet Get-PowerBIActivityEvent.

In generale, iniziare con l'API Office 365 Management Activity è un approccio più complesso rispetto all'uso del log attività di Power BI (descritto in precedenza). Ciò è dovuto al fatto che l'API restituisce BLOB di contenuto e ogni BLOB di contenuto contiene singoli record di controllo. Per le organizzazioni di grandi dimensioni, potrebbero esserci migliaia di BLOB di contenuto al giorno. Poiché i clienti e le applicazioni di terze parti usano molto questa API, Microsoft implementa la limitazione per garantire che l'uso del servizio non influisca negativamente sugli altri utente (noto come problema "noisy neighbor"). Pertanto, il recupero di grandi volumi di cronologia può essere una sfida nelle organizzazioni più grandi. Per altre informazioni, vedere questo articolo di risoluzione dei problemi.

Per usare questa API, è necessario eseguire l'autenticazione con un'entità servizio a cui è stata concessa l'autorizzazione per recuperare i dati dall'API dell'attività di gestione di Office 365.

Suggerimento

Per impostazione predefinita, gli amministratori di Power BI non hanno l'autorizzazione per accedere all'API Office 365 Management Activity. Poiché contiene dati per molti servizi di Microsoft 365, l'accesso richiede un ruolo di amministratore con privilegi elevati o di controllo. Nella maggior parte delle organizzazioni, questi ruoli sono riservati a un numero ridotto di amministratori IT. Il log attività di Power BI è destinato all'uso da parte degli amministratori di Power BI.

Il recupero dei dati di controllo a livello di codice dall'API Office 365 Management Activity è una scelta ottimale quando l'IT deve estrarre e archiviare i log di controllo da vari servizi (oltre a Power BI).

Microsoft Sentinel

Microsoft Sentinel è un servizio di Azure che consente di raccogliere, rilevare, analizzare e rispondere a eventi imprevisti e minacce per la sicurezza. È possibile configurare Power BI in Microsoft Sentinel come connettore dati. Quando si è connessi, i log di controllo (che contengono un subset di dati) vengono trasmessi da Power BI in Azure Log Analytics, che è una funzionalità di Monitoraggio di Azure.

Suggerimento

Azure Log Analytics si basa sulla stessa architettura usata dai log eventi del modello semantico a livello di area di lavoro. Per altre informazioni sui log eventi del modello semantico, vedere Controllo a livello di dati.

Poiché si tratta di un servizio di Azure separato, a qualsiasi amministratore o utente che si vuole esegua query Kusto Query Language (KQL) devono essere concesse le autorizzazioni in Azure Log Analytics (Monitoraggio di Azure). Quando hanno l'autorizzazione, possono eseguire query sui dati di controllo archiviati nella tabella PowerBIActivity. Tenere tuttavia presente che nella maggior parte dei casi si concederà agli utenti l'accesso ai dati curati nel livello oro anziché ai dati non elaborati nel livello bronzo.

Si usa KQL per analizzare gli eventi del log attività archiviati in Azure Log Analytics. Se si ha esperienza con SQL, si riscontreranno molte analogie con KQL.

Esistono diversi modi per accedere agli eventi archiviati in Azure Log Analytics. Puoi usare:

  • L'app modello predefinita Log Analytics per i modelli semantici di Power BI.
  • Connettore Power BI Desktop per Esplora dati di Azure (Kusto).
  • Esperienza di query basata sul Web in Esplora dati di Azure.
  • Qualsiasi strumento di query in grado di inviare query KQL.

Attenzione

Tenere presente che solo un subset dei dati del log attività di Power BI viene archiviato in Monitoraggio di Azure. Quando si prevede di eseguire un'analisi completa dell'utilizzo e dell'adozione di Power BI nell'organizzazione, è consigliabile usare altre opzioni (descritte in precedenza in questa sezione) per recuperare i dati delle attività.

Il periodo di cronologia che è possibile recuperare dipende dai criteri di conservazione dei dati per l'area di lavoro Azure Log Analytics. Valutare i costi e l'accesso ai dati non elaborati quando si decide la quantità di dati da conservare.

Microsoft Sentinel e Monitoraggio di Azure sono opzioni valide quando l'IT ha già effettuato un investimento con Microsoft Sentinel, se il livello di dettaglio acquisito soddisfa le proprie esigenze e se le attività come il rilevamento delle minacce sono una priorità. Tuttavia, poiché Microsoft Sentinel non acquisisce tutti i dati delle attività di Power BI, non supporta l'esecuzione di analisi complete dell'utilizzo e dell'adozione di Power BI.

Considerazioni relative ai dati delle attività utente

Ecco alcune considerazioni per scegliere l'origine per i dati delle attività utente.

  • Sarà un processo di controllo manuale o automatizzato? Le opzioni dell'interfaccia utente funzionano bene per i processi di controllo manuali e per le query occasionali, soprattutto quando è necessario analizzare un'attività specifica. Per supportare l'analisi cronologica dei dati storici, sarà necessario anche un processo di controllo automatizzato che estragga i dati dell'utente in base a una pianificazione.
  • Con quale frequenza sono necessari i dati dell'attività utente? Per i processi di controllo automatizzati, pianificare l'estrazione di dati in modo che abbia luogo almeno un giorno prima della data corrente usando l'ora UTC (Coordinated Universal Time), anziché l'ora locale. Ad esempio, se il processo viene eseguito venerdì mattina (ora UTC), è necessario estrarre i dati da mercoledì. Esistono diversi motivi per cui è consigliabile estrarre i dati con una latenza di un giorno.
    • I file saranno più semplici da usare se si estraggono sempre 24 ore complete alla volta, evitando così risultati parziali delle giornate.
    • Si ridurrà al minimo il rischio di mancanza di alcuni eventi di controllo. In genere, gli eventi di controllo arrivano entro 30 minuti. In alcuni casi, alcuni eventi possono richiedere fino a 24 ore per essere visualizzati nel log di controllo unificato.
  • Sono necessari altri elementi oltre ai dati di Power BI? Prendere in considerazione il modo più efficiente per accedere a ciò che serve.
  • Chi svilupperà la soluzione? Pianificare di investire del tempo per creare la soluzione. Può richiedere un impegno significativo per produrre uno script pronto per la produzione.

Elenco di controllo: quando si pianifica come accedere ai dati delle attività utente, le decisioni chiave e le azioni includono:

  • Chiarire l'ambito delle esigenze: determinare se sia necessario accedere solo ai record di controllo di Power BI o controllare i dati per più servizi.
  • Consultarsi con l'IT: scoprire se l'IT estrae attualmente i log di controllo e se sia possibile ottenere l'accesso ai dati non elaborati in modo che non sia necessario creare una nuova soluzione.
  • Decidere un'origine dati: determinare l'origine migliore da usare per accedere ai dati delle attività utente.
  • Completare un modello di verifica: pianificare il completamento di un piccolo modello di verifica (POC). Usarlo per convalidare le decisioni relative alla modalità di compilazione della soluzione finale.
  • Tenere traccia delle esigenze aggiuntive dei dati: è possibile correlare i dati del log attività con altre origini per migliorare il valore dei dati. Tenere traccia di queste opportunità man mano che si presentano in modo che possano essere aggiunte all'ambito del progetto.

Accedere ai dati di inventario tenant

Un inventario tenant è una soluzione di controllo e monitoraggio avanzata. Consente di comprendere quali aree di lavoro e contenuti (modelli semantici, report e altri elementi) esistono in Power BI ed è un ottimo complemento ai dati delle attività utente (descritti nella sezione precedente). Per altre informazioni sull'identificazione delle esigenze dei dati, vedere l'Inventario tenant più indietro in questo articolo.

Le attività degli utenti (descritte in precedenza) sono eventi controllati; sono un record di azioni eseguite da un utente in una data e un'ora specifiche. Tuttavia, l'inventario tenant è diverso. L'inventario tenant è uno snapshot in un determinato momento. Descrive lo stato corrente di tutti gli elementi pubblicati nel servizio Power BI al momento dell'estrazione.

Nota

La documentazione dell'API REST di Power BI fa riferimento agli elementi pubblicati come artefatti.

Suggerimento

Molte organizzazioni trovano utile estrarre l'inventario tenant nello stesso momento della giornata ogni settimana.

Per analizzare correttamente ciò che accade nel tenant di Power BI, sono necessari sia i dati delle attività utente che l'inventario tenant. La combinazione di questi elementi consente di comprendere quanto contenuto si ha e dove si trova. Consente anche di trovare contenuto inutilizzato o sottoutilizzato (perché non ci saranno eventi a riguardo nel log attività). L'inventario tenant consente anche di compilare un elenco di nomi correnti per tutti gli elementi, utile quando i nomi degli elementi cambiano.

Per altre informazioni sul valore dell'inventario tenant, vedere Inventario tenant in precedenza in questo articolo.

Suggerimento

È possibile usare l'API Get Unused Artifacts as Admin per cercare gli elementi che non hanno alcuna attività utente negli ultimi 30 giorni. Tuttavia, non è possibile personalizzare tale periodo di tempo. Ad esempio, potrebbe essere disponibile contenuto critico usato solo trimestralmente. Combinando l'inventario tenant con i dati delle attività utente, è possibile trovare elementi inutilizzati in modi che è possibile personalizzare.

È possibile ottenere i dati di inventario dei tenant in due modi diversi.

Tecnica Descrizione Ideale per Scelta ottimale per i processi di controllo manuali Scelta ottimale per i processi di controllo automatizzati
Programmatica L'API Get Groups as Admin o il cmdlet di PowerShell Get-PowerBIWorkspace possono fornire un elenco di aree di lavoro per l'intero tenant. Facoltativamente, è possibile includere singoli elementi (ad esempio modelli semantici e report) per area di lavoro. Organizzazioni più piccole o volumi di dati bassi L'API Get Groups as Admin o il cmdlet Get-PowerBIWorkspace di PowerShell sono una scelta ideale per i processi di controllo manuali. L'API Get Groups as Admin o il cmdlet Get-PowerBIWorkspace di PowerShell sono una scelta ideale per i processi di controllo automatizzati.
Programmatica Un set di API di amministrazione asincrone, note collettivamente come API di analisi dei metadati o API scanner, può restituire un elenco di aree di lavoro e singoli elementi. Facoltativamente, è possibile includere anche metadati dettagliati (ad esempio tabelle, colonne ed espressioni di misura). Organizzazioni con un volume di dati elevato e/o una necessità di ottenere risultati dettagliati Le API di analisi dei metadati sono una scelta ideale per i processi di controllo automatizzati.

Nella parte restante di questa sezione vengono presentate le varie tecniche indicate nella tabella.

Cmdlet per le API o le aree di lavoro di gruppi

Per recuperare un elenco di aree di lavoro, è possibile usare una delle diverse API REST, ad esempio Ottenere gruppi come API di amministrazione (usando lo strumento di propria scelta). I risultati includono metadati aggiuntivi, ad esempio la descrizione e se l'area di lavoro viene archiviata in una capacità Premium.

Nota

L'API denominata include il termine gruppo come riferimento a un'area di lavoro. Questo termine ha origine dal modello di sicurezza originale di Power BI, che si basava sui gruppi di Microsoft 365. Anche se il modello di sicurezza di Power BI si è evoluto in modo significativo nel corso degli anni, i nomi delle API esistenti rimangono invariati per evitare di interrompere le soluzioni esistenti.

L'API REST Get Groups as Admin include l'utile parametro $expand. Questo parametro consente di espandere facoltativamente i risultati in modo che includano un elenco di elementi pubblicati nell'area di lavoro, ad esempio modelli semantici e report. È anche possibile passare il tipo di dati users al parametro $expand per includere gli utenti assegnati a un ruolo dell'area di lavoro.

È anche possibile usare il cmdlet di PowerShell Get-PowerBIWorkspace. Proviene dal modulo Aree di lavoro di gestione di Power BI. Quando si imposta il parametro -Scope organization, funziona come l'API Get Groups as Admin. Il cmdlet accetta anche il parametro -Include (equivalente al parametro $expand nell'API REST) per includere gli elementi pubblicati nell'area di lavoro, ad esempio modelli semantici e report.

Suggerimento

Passando parametri, è possibile usare il cmdlet in modi diversi. Questa sezione è incentrata sul recupero di un inventario a livello di tenant. Per altre informazioni sull'uso del parametro -Scope, vedere Scegliere un'API utente o un'API amministratore in precedenza in questo articolo.

Per facilitare la scelta dell'opzione da usare, vedere Scegliere API o cmdlet di PowerShell in precedenza in questo articolo.

L'API REST Get Groups as Admin o il cmdlet di PowerShell Get-PowerBIWorkspace sono più adatti per i processi di controllo manuali e le indagini occasionali. Le organizzazioni di grandi dimensioni con un volume di dati elevato in genere trovano queste opzioni difficili da usare. L'API REST e il cmdlet estraggono sempre un set completo di dati, pertanto richiedono molto tempo per l'esecuzione. È quindi probabile che nelle organizzazioni di grandi dimensioni si verifichino limitazioni sul numero di richieste consentite all'ora (note come limitazioni delle richieste, eseguite per proteggere l'integrità del servizio). Le API di analisi dei metadati (descritte di seguito) offrono un'alternativa più affidabile e scalabile.

API di analisi dei metadati

Le API di analisi dei metadati, comunemente denominate API scanner, sono un set di API che restituiscono un elenco di aree di lavoro e i relativi elementi di Power BI (modelli semantici, report e altri elementi). Concettualmente, forniscono gli stessi dati (e altro ancora) delle API Gruppi o del cmdlet dell'area di lavoro, descritti nella sezione precedente. Tuttavia, il metodo usato per recuperare i dati è diverso ed è più efficace per l'estrazione dell'inventario del tenant.

Nota

Si noti come alcuni utenti usano il termine API scanner o la frase analizzare il tenant. Spesso usano questi termini per indicare la compilazione di un inventario tenant, distinguendola dagli eventi dell'attività utente. Potrebbero o meno fare riferimento letteralmente all'uso delle API di analisi dei metadati.

Esistono due motivi principali per cui è consigliabile usare le API di analisi dei metadati anziché l'API REST Get Groups as Admin o il cmdlet Get-PowerBIWorkspace (descritto in precedenza).

  • Estrazione incrementale dei dati: le API dello scanner estraggono solo i dati modificati dall'ultima esecuzione. Viceversa, l'API REST Get Groups as Admin e il cmdlet Get-PowerBIWorkspace sono operazioni sincrone che estraggono il set completo di dati ogni volta che vengono eseguiti.
  • Livello di dettaglio più granulare: le API dello scanner possono recuperare dettagli granulari (ad esempio tabelle, colonne ed espressioni di misura), se viene concessa l'autorizzazione dalle due impostazioni del tenant per metadati dettagliati. Viceversa, il livello di dettaglio più basso disponibile con l'API REST Get Groups as Admin e il cmdlet Get-PowerBIWorkspace è di tipo di elemento, ad esempio un elenco di report in un'area di lavoro.

L'uso delle API dello scanner comporta un maggiore impegno perché è necessario chiamare una serie di API. Inoltre, vengono eseguiti come processo asincrono. Un processo asincrono viene eseguito in background e quindi non è necessario attendere il completamento. Potrebbe essere necessario collaborare con l'IT o con uno sviluppatore quando è il momento di creare uno script pronto per la produzione che verrà pianificato.

Ecco la sequenza di passaggi che il processo deve seguire quando si usano le API dello scanner.

  1. Accedere: accedere al servizio Power BI usando un account amministratore di Power BI o un'entità servizio che dispone dell'autorizzazione per eseguire le API di amministratore. Per altre informazioni, vedere Determinare il metodo di autenticazione più indietro in questo articolo.
  2. Ottenere gli ID dell'area di lavoro: inviare una richiesta per recuperare un elenco di ID dell'area di lavoro. Durante la prima esecuzione non si avrà una data modificata, quindi verrà restituito un elenco completo di aree di lavoro. In genere, si passerà la data modificata per recuperare solo le aree di lavoro che sono state modificate a partire da quel momento. La data di modifica deve essere compresa negli ultimi 30 giorni.
  3. Avviare un'analisi dei metadati: avviare una chiamata per richiedere un'analisi delle informazioni sull'area di lavoro passando gli ID dell'area di lavoro recuperati nel passaggio 2. Si noti che si tratta di un'API POST (e non di un'API GET, che è invece più comune durante il recupero dei dati di controllo). Un'API POST è una richiesta HTTP che crea o scrive dati per una risorsa specificata. Questa query specifica il livello di dettaglio che verrà estratto, ad esempio i dettagli dell'origine dati, lo schema del modello semantico, le espressioni del modello semantico o gli utenti. Quando viene inviato, un ID per l'analisi viene restituito dall'API. Restituisce anche la data e l'ora dell'analisi, che è necessario registrare come data di snapshot.
  4. Controllare lo stato dell'analisi: usare l'ID di analisi ottenuto nel passaggio 3 per ottenere lo stato di analisi. Potrebbe essere necessario chiamare questa API più volte. Quando lo stato restituito è Operazione completata, si può procedere con il passaggio successivo. Il tempo necessario per l'analisi dipende dalla quantità di dati richiesti.
  5. Ottenere i risultati: usare l'ID di analisi ottenuto nel passaggio 3 per ottenere il risultato dell'analisi ed estrarre i dati. È necessario eseguire questo passaggio entro 24 ore dal completamento del passaggio 4. Tenere presente che il timestamp dello snapshot deve essere correlato al passaggio 3 anziché al passaggio 5 (quando si verifica un ritardo significativo). In questo modo, si avrà un timestamp preciso dello snapshot. Salvare i risultati nel percorso di archiviazione dei dati preferito. Come già descritto in questo articolo, è consigliabile archiviare i dati non elaborati nello stato originale.
  6. Prepararsi per il processo successivo: registrare il timestamp dell'analisi dal passaggio 3 per poterlo usare nel passaggio 2 alla successiva esecuzione del processo. In questo modo, verranno estratti solo i dati modificati da quel momento. In futuro, tutti gli estratti di dati successivi saranno modifiche incrementali anziché snapshot completi.

Elenco di controllo: quando si pianifica l'accesso ai dati di inventario tenant, le decisioni chiave e le azioni includono:

  • Verificare i requisiti: chiarire le esigenze per la compilazione di un inventario tenant e i requisiti analitici per i dati.
  • Decidere la frequenza per estrarre l'inventario tenant: confermare la frequenza con cui è necessario un nuovo inventario tenant (ad esempio ogni settimana).
  • Decidere come estrarre l'inventario tenant: confermare quale metodo si userà per ottenere i dati di inventario tenant (API, cmdlet o API di analisi dei metadati).
  • Completare un modello di verifica: pianificare il completamento di un piccolo modello di verifica (POC). Usarlo per convalidare le decisioni relative alla modalità di compilazione della soluzione finale.

Accedere ai dati di utenti e gruppi

Oltre alle informazioni di identificazione (ad esempio un indirizzo di posta elettronica) incluse nei dati delle attività dell'utente, è utile recuperare informazioni aggiuntive, ad esempio la posizione o i dettagli dell'organizzazione. È possibile usare Microsoft Graph per recuperare dati su utenti, gruppi, entità servizio e licenze. Microsoft Graph include un set di API e librerie client che consentono di recuperare i dati di controllo da un'ampia gamma di servizi.

Ecco alcuni dettagli sugli oggetti Microsoft Entra a cui è possibile accedere.

  • Utente: un'identità esistente in Microsoft Entra ID come account aziendale, dell'istituto di istruzione o Microsoft. Il termine utente di dominio viene spesso usato per descrivere gli utenti dell'organizzazione, mentre il termine formale è nome dell'entità utente (UPN). Un UPN è in genere lo stesso valore dell'indirizzo di posta elettronica dell'utente (tuttavia, se un indirizzo di posta elettronica cambia, l'UPN non cambia perché non è modificabile). È disponibile anche un ID Microsoft Graph univoco per ogni utente. Spesso, un account utente è associato a una sola persona. Alcune organizzazioni creano utenti come account di servizio usati per le attività automatizzate o per le attività amministrative.
  • Entità servizio: un tipo diverso di identità, di cui viene effettuato il provisioning quando si crea una registrazione dell'app. Un'entità servizio è destinata alle attività automatiche e automatizzate. Per altre informazioni, vedere Determinare il metodo di autenticazione più indietro in questo articolo.
  • Gruppo: raccolta di utenti ed entità servizio. Esistono diversi tipi di gruppi che è possibile usare per semplificare la gestione delle autorizzazioni. Per altre informazioni, vedere Strategia per l'uso di gruppi.

Nota

Quando questo articolo fa riferimento a utenti e gruppi, questo termine include anche le entità servizio. Questo termine viene usato per brevità.

Gli utenti e i dati dei gruppi recuperati sono uno snapshot che descrive lo stato corrente in un determinato momento.

Suggerimento

Per altre informazioni su utenti, entità servizio e gruppi, vedere Integrazione con Microsoft Entra ID.

Attributi analitici

Per il controllo a livello di tenant di Power BI, è possibile estrarre e archiviare gli attributi seguenti da Microsoft Graph.

  • Nome completo degli utenti: molte origini dati includono solo l'indirizzo e-mail dell'utente che ha eseguito un'attività o che è stato assegnato a un ruolo. Usare questo attributo quando si desidera visualizzare il nome completo (nome visualizzato) nei report analitici. L'uso del nome completo rende i report più descrittivi.
  • Altre proprietà utente: altri attributi descrittivi sugli utenti potrebbero essere disponibili in Microsoft Entra ID. Alcuni esempi di attributi predefiniti del profilo utente con valore analitico includono il titolo del lavoro, il reparto, il responsabile, l'area geografica e la posizione dell'ufficio.
  • Membri di un gruppo di sicurezza: la maggior parte delle origini dati specifica il nome di un gruppo, ad esempio i record del log attività di Power BI assegnati a un ruolo dell'area di lavoro. Il recupero dell'appartenenza al gruppo migliora la possibilità di analizzare completamente le attività o gli accessi di un singolo utente.
  • Licenze utente: è utile analizzare quali licenze utente (gratuite, Power BI Pro o Power BI Premium per utente (PPU)) vengono assegnate agli utenti. Questi dati consentono di identificare chi non usa la licenza. Consente anche di analizzare tutti gli utenti (utenti distinti con una licenza) rispetto agli utenti attivi (con attività recenti). Se si sta valutando l'aggiunta o l'espansione delle licenze di Power BI Premium, è consigliabile analizzare i dati delle licenze utente insieme ai dati delle attività utente per eseguire un'analisi dei costi.
  • Membri dei ruoli di amministratore: è possibile compilare un elenco degli amministratori di Power BI (inclusi gli amministratori di Power Platform).

Per i riferimenti autorevoli sulle licenze di Power BI disponibili nei dati di controllo di Microsoft Graph, vedere Nomi dei prodotti e identificatori del piano di servizio per le licenze.

Suggerimento

Il recupero di membri da gruppi può essere uno degli aspetti più complessi dell'acquisizione dei dati di controllo. È necessario eseguire una ricerca transitiva per rendere flat tutti i membri annidati e i gruppi annidati. È possibile eseguire una ricerca transitiva per membri del gruppo. Questo tipo di ricerca è particolarmente complesso quando nell'organizzazione sono presenti migliaia di gruppi. In tal caso, potrebbero essere considerate alternative migliori per recuperare i dati. Un'opzione consiste nell'estrarre tutti i gruppi e i membri del gruppo da Microsoft Graph. Tuttavia, questo metodo potrebbe non essere pratico quando viene usato solo un numero ridotto di gruppi per la sicurezza di Power BI. Un'altra opzione consiste nel precompilare un elenco di riferimenti di gruppi usati da qualsiasi tipo di sicurezza di Power BI (ruoli dell'area di lavoro, autorizzazioni per app, condivisione per elemento, sicurezza a livello di riga e altri). È quindi possibile scorrere l'elenco di riferimenti per recuperare membri del gruppo da Microsoft Graph.

Ecco alcuni altri attributi che è possibile estrarre e archiviare.

  • Tipo di utente: gli utenti sono membri o guest. In genere, i membri sono utenti interni e gli utenti guest sono utenti esterni (B2B). L'archiviazione del tipo di utente è utile quando è necessario analizzare le attività degli utenti esterni.
  • Modifiche al ruolo: quando si esegue un controllo di sicurezza, è utile comprendere quando un utente ha modificato i ruoli nell'organizzazione, ad esempio quando viene trasferito a un reparto diverso. In questo modo, è possibile verificare se le impostazioni di sicurezza di Power BI sono state (o devono essere) aggiornate.
  • Utenti disabilitati: quando un utente lascia l'organizzazione, in genere un amministratore ne disabilita l'account. È possibile creare un processo per verificare se gli utenti disabilitati sono amministratori dell'area di lavoro o proprietari di modelli semantici.

Suggerimento

Il log attività di Power BI include un evento che registra quando un utente effettua l'iscrizione a una licenza di valutazione. È possibile combinare tale evento con i dati delle licenze utente (originati da Microsoft Entra ID) per produrre un'immagine completa.

Recuperare i dati di utenti e gruppi

È possibile recuperare i dati relativi a utenti e gruppi in modi diversi.

Tecnica Descrizione Scelta ottimale per i processi di controllo manuali Scelta ottimale per i processi di controllo automatizzati
Manuale Graph Explorer Graph explorer è una scelta ideale per i processi di controllo manuali.
Programmatica API e SDK Microsoft Graph Le API e gli SDK di Microsoft Graph sono scelte valide per i processi di controllo automatizzati.
Programmatica Modulo di Azure PowerShell Il modulo Az PowerShell è una scelta ideale per i processi di controllo automatizzati.

Nella parte restante di questa sezione vengono presentate le varie tecniche indicate nella tabella. Altre tecniche, deprecate e da non usare per le nuove soluzioni, sono descritte alla fine di questa sezione.

Nota

Prestare attenzione quando si leggono informazioni online perché molti nomi di strumenti sono simili. Alcuni strumenti nell'ecosistema Microsoft includono il termine Graph nel nome, ad esempio Azure Resource Graph, GraphQL e l'API Microsoft Security Graph. Questi strumenti non sono correlati a Microsoft Graph e non rientrano nell'ambito di questo articolo.

Microsoft Graph Explorer

Microsoft Graph explorer è uno strumento di sviluppo che consente di ottenere informazioni su API Microsoft Graph. È un modo semplice per iniziare perché non richiede altri strumenti o configurazioni nel computer. È possibile accedere per recuperare dati dal tenant o recuperare dati di esempio da un tenant predefinito.

È possibile usare Graph explorer per:

  • Inviare manualmente una richiesta a un'API Microsoft Graph per verificare se restituisce le informazioni desiderate.
  • Vedere come costruire l'URL, le intestazioni e il corpo prima di scrivere uno script.
  • Archiviare i dati in modo informale.
  • Determinare le autorizzazioni necessarie per ogni API. È anche possibile fornire il consenso per le nuove autorizzazioni.
  • Ottenere frammenti di codice da usare quando si creano script.

Usare questo collegamento per aprire Graph explorer.

API e SDK Microsoft Graph

Usare le API di Microsoft Graph per recuperare i dati di utenti e gruppi. È anche possibile usarle per recuperare dati da servizi come Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook e altro ancora.

Gli SDK di Microsoft Graph fungono da wrapper API sulle API Microsoft Graph sottostanti. Un SDK è un software development kit che raggruppa strumenti e funzionalità. Gli SDK di Microsoft Graph espongono l'intero set di API Microsoft Graph.

È possibile scegliere di inviare richieste direttamente alle API. In alternativa, è possibile aggiungere un livello di semplificazione usando il linguaggio preferito e uno degli SDK. Per altre informazioni, vedere Scegliere API o cmdlet di PowerShell più indietro in questo articolo.

Gli SDK di Microsoft Graph supportano diversi linguaggi e sono disponibili anche i moduli Microsoft Graph PowerShell. Altri SDK sono disponibili per Python, C# e altri linguaggi.

Importante

Il modulo Microsoft Graph PowerShell sostituisce i moduli di Azure AD PowerShell e i moduli MSOnline (MSOL), entrambi deprecati. Non è consigliabile creare nuove soluzioni con moduli deprecati. Il modulo Microsoft Graph PowerShell offre molte funzionalità e molti vantaggi. Per altre informazioni, vedere Eseguire l'aggiornamento da Azure AD PowerShell a Microsoft Graph PowerShell.

È possibile installare i moduli di PowerShell di Microsoft Graph dal PowerShell Gallery. Poiché Microsoft Graph funziona con diversi servizi Microsoft 365, esistono vari moduli PowerShell da installare.

Per il controllo a livello di tenant di Power BI, ecco i moduli di PowerShell più comuni da installare.

Suggerimento

Microsoft aggiorna regolarmente i moduli di Microsoft Graph PowerShell. In alcuni casi, i moduli di anteprima vengono resi disponibili in base alla versione non definitiva o a un endpoint beta. È possibile specificare la versione a cui si è interessati quando si installano e si aggiornano i moduli. Inoltre, quando si esamina la documentazione online, si noti che il numero di versione corrente viene aggiunto automaticamente alla fine dell'URL (quindi prestare attenzione quando si salvano o si condividono gli URL).

Modulo di Azure PowerShell

È anche possibile usare il modulo Az PowerShell per recuperare i dati di utenti e gruppi. Si concentra sulle risorse di Azure.

Importante

Il modulo Az PowerShell sostituisce i moduli di AzureRM PowerShell, che sono deprecati. Non è consigliabile creare nuove soluzioni con moduli deprecati.

È possibile usare il cmdlet Invoke-AzRestMethod quando non è presente un cmdlet corrispondente per un'API. Si tratta di un approccio flessibile che consente di inviare una richiesta a qualsiasi API Microsoft Graph usando il modulo Az PowerShell.

A partire da Az versione 7, i cmdlet Az ora fanno riferimento all'API Microsoft Graph. Di conseguenza, il modulo Az funge da wrapper API su Microsoft Graph. I moduli Az hanno un subset di funzionalità contenute nelle API Microsoft Graph e nei moduli di PowerShell. Per le nuove soluzioni, è consigliabile usare Microsoft Graph PowerShell SDK.

API e moduli deprecati

È possibile trovare articoli e post di blog online che suggeriscono opzioni alternative non presentate in questa sezione. È consigliabile non creare nuove soluzioni (e anche di non eseguire la migrazione delle soluzioni esistenti) usando una delle API o dei moduli seguenti.

  • Moduli di AzureRM PowerShell: sono deprecati e verranno ritirati. Sono stati sostituiti con il modulo Az PowerShell.
  • API Graph di Azure AD e modulo Azure AD PowerShell: sono deprecati e verranno ritirati. Questa modifica è il risultato della migrazione da Azure AD Graph a Microsoft Graph (si noti che Graph è un termine presente in entrambi i nomi, ma Microsoft Graph è la direzione futura). Tutti gli investimenti futuri di PowerShell verranno effettuati nell'SDK Microsoft Graph PowerShell.
  • Modulo PowerShell MS Online (MSOL): è deprecato e verrà ritirato. Tutti gli investimenti futuri di PowerShell verranno effettuati nell'SDK Microsoft Graph PowerShell.

Attenzione

Assicurarsi di confermare lo stato di qualsiasi API o modulo deprecato in uso. Per altre informazioni sul ritiro di AzureRM, vedere questo annuncio.

Per altre informazioni su Microsoft Entra ID e MSOL, vedere questo post che annuncia il ritiro.

Se si hanno domande o si richiedono chiarimenti sulla direzione futura dell'accesso ai dati a livello di codice, contattare il team dell'account Microsoft.

Elenco di controllo: quando si pianifica l'accesso a dati di utenti e gruppi, le decisioni chiave e le azioni includono:

  • Verificare i requisiti: chiarire le esigenze di compilazione dei dati correlati a utenti, gruppi e licenze.
  • Definizione delle priorità dei requisiti: verificare quali sono le priorità principali per sapere a cosa dedicare innanzitutto il proprio tempo.
  • Decidere la frequenza per l'estrazione dei dati: determinare la frequenza con cui è necessario un nuovo snapshot dei dati di utenti e gruppi, ad esempio ogni settimana o ogni mese.
  • Decidere come estrarre dati con Microsoft Graph: determinare quale metodo si userà per recuperare i dati.
  • Completare un modello di verifica: pianificare il completamento di un piccolo modello di verifica (POC) per estrarre dati di utenti e gruppi. Usarlo per convalidare le decisioni relative alla modalità di compilazione della soluzione finale.

Accedere ai dati dalle API REST di Power BI

Ad esempio, come priorità più bassa, è anche possibile recuperare altri dati usando le API REST di Power BI.

Ad esempio, è possibile recuperare i dati relativi a:

Durante un controllo di sicurezza, potrebbe essere necessario identificare:

Per altre informazioni sugli altri tipi di API, vedere Scegliere un'API utente o un'API amministratore in precedenza in questo articolo.

Elenco di controllo: quando si pianifica l'accesso ai dati dalle API di Power BI, le decisioni e le azioni principali includono:

  • Ottenere i requisiti: compilare i requisiti analitici man mano che si verificano. Tenerne traccia nel backlog.
  • Requisiti di priorità: impostare le priorità per i nuovi requisiti che si verificano.

Fase 2: Prerequisiti e configurazione

La seconda fase di pianificazione e implementazione di una soluzione di controllo a livello di tenant è incentrata sui prerequisiti e sulla configurazione che devono essere eseguiti prima di iniziare lo sviluppo della soluzione.

Diagramma di flusso che descrive la fase 2, che è incentrata sui prerequisiti e sulla configurazione per la creazione di una soluzione di controllo a livello di tenant.

Creare un account di archiviazione

A questo punto, si è deciso un percorso per archiviare i dati non elaborati e come creare dati curati. In base a queste decisioni, è ora possibile creare un account di archiviazione. A seconda dei processi dell'organizzazione, ciò potrebbe comportare l'invio di una richiesta all'IT.

Come descritto in precedenza, è consigliabile usare una tecnologia che consenta di scrivere i dati non elaborati nell'archiviazione non modificabile. Dopo aver scritto i dati, non è possibile modificarli o eliminarli. È quindi possibile affidarsi ai dati non elaborati perché si sa che un amministratore con accesso non può modificarli in alcun modo. I dati curati, tuttavia, non devono (in genere) essere archiviati in una risorsa di archiviazione non modificabile. I dati curati possono cambiare o essere rigenerati.

Elenco di controllo: quando si crea un account di archiviazione, le decisioni chiave e le azioni includono:

  • Creare un account di archiviazione: creare o inviare una richiesta per la creazione di un account di archiviazione. Usare le impostazioni di archiviazione non modificabili per i dati non elaborati, quando possibile.
  • Impostare le autorizzazioni: determinare quali autorizzazioni devono essere impostate per l'account di archiviazione.
  • Test di accesso: eseguire un piccolo test per assicurarsi di poter leggere e scrivere nell'account di archiviazione.
  • Confermare le responsabilità: assicurarsi di essere chiari su chi gestirà l'account di archiviazione in modo continuativo.

Installare software e configurare i servizi

A questo punto, sono state prese decisioni su quale tecnologia usare per l'accesso ai dati di controllo. In base a queste decisioni, è ora possibile installare il software e configurare i servizi.

Configurare l'ambiente di sviluppo preferito per ogni amministratore. L'ambiente di sviluppo consentirà di scrivere e testare script. Visual Studio Code è uno strumento moderno per lo sviluppo di script, quindi è una buona opzione. Inoltre, molte estensioni sono disponibili per l'uso con Visual Studio Code.

Se si è presa la decisione (descritta in precedenza) di usare PowerShell, è necessario installare PowerShell Core e i moduli di PowerShell necessari in:

  • Computer di ogni amministratore/sviluppatore che scrive o testa gli script di controllo.
  • Ogni macchina virtuale o server che eseguirà script pianificati.
  • Ogni servizio online, ad esempio Funzioni di Azure o Automazione di Azure.

Se si è scelto di usare qualsiasi servizio di Azure, ad esempio Funzioni di Azure, Automazione di Azure, Azure Data Factory o Azure Synapse Analytics, è consigliabile eseguirne il provisioning e la configurazione.

Elenco di controllo: quando si installano software e si configurano servizi, le decisioni e le azioni principali includono:

  • Configurare il computer amministratore/sviluppatore:, se applicabile, installare gli strumenti necessari che verranno usati per lo sviluppo.
  • Configurare i server: se applicabile, installare gli strumenti necessari in qualsiasi server o macchina virtuale presente nell'architettura.
  • Configurare i servizi di Azure: se applicabile, effettuare il provisioning e configurare ogni servizio di Azure. Assegnare le autorizzazioni per ogni amministratore/sviluppatore che eseguirà il lavoro di sviluppo.

Registrare un'applicazione Microsoft Entra

A questo punto, si è deciso come autenticare. È consigliabile registrare un'applicazione Microsoft Entra (entità servizio). Comunemente definita registrazione app, deve essere usata per le operazioni senza operatore che verranno automatizzate.

Per altre informazioni su come creare una registrazione dell'app per recuperare i dati di controllo a livello di tenant, vedere Abilitare l'autenticazione dell'entità servizio per le API amministratore di sola lettura.

Elenco di controllo: quando si registra un'applicazione Microsoft Entra, le decisioni e le azioni principali includono:

  • Verificare se esiste una registrazione dell'app esistente: verificare con l'IT se è disponibile una registrazione dell'app esistente per l'esecuzione delle API di amministrazione. In tal caso, determinare se usare quella esistente o se crearne una nuova.
  • Creare una nuova registrazione dell'app: creare una registrazione dell'app quando appropriato. Prendere in considerazione l'uso di un nome dell'app, ad esempio PowerBI-AdminAPIs-EntraApp, che ne descrive chiaramente lo scopo.
  • Creare un segreto per la registrazione dell'app: dopo aver registrato l'app, creare un segreto per quest'ultima. Impostare la data di scadenza in base alla frequenza con cui si intende ruotare il segreto.
  • Salvare in modo sicuro i valori: archiviare il segreto, l'ID app (ID client) e l'ID tenant perché saranno necessari per l'autenticazione con l'entità servizio. Usare una posizione sicura, ad esempio un insieme di credenziali delle password dell'organizzazione. Se è necessario richiedere la creazione di una registrazione dell'app dall'IT, specificare che sono necessari questi valori restituiti.
  • Creare un gruppo di sicurezza: creare (o richiedere) un gruppo di sicurezza che verrà usato per Power BI. Prendere in considerazione l'uso del nome del gruppo, ad esempio le entità servizio di amministrazione di Power BI, che indica che il gruppo verrà usato per accedere ai metadati a livello di tenant.
  • Aggiungere l'entità servizio come membro del gruppo di sicurezza: usare l'ID app (ID client) per aggiungere l'entità servizio nuova (o esistente) come membro del nuovo gruppo di sicurezza.
  • Aggiornare l'impostazione del tenant dell'API amministratore in Power BI: nel portale di amministrazione di Power BI aggiungere il gruppo di sicurezza all'impostazione del tenant Consenti alle entità servizio di usare le API di amministrazione di Power BI di sola lettura.
  • Ignorare l'assegnazione delle autorizzazioni in Azure: non delegare alcuna autorizzazione alla registrazione dell'app (otterrà l'accesso ai dati di controllo a livello di tenant di Power BI tramite l'impostazione del tenant Consenti alle entità servizio di usare le API di amministrazione di Power BI di sola lettura di Power BI).
  • Decidere se la registrazione dell'app deve accedere ai metadati dettagliati: determinare se si vogliono estrarre informazioni dettagliate sulle tabelle, le colonne e le espressioni di misura del modello semantico quando si compila l'inventario tenant.
  • Aggiornare le impostazioni dettagliate del tenant dei metadati in Power BI: facoltativamente, nel portale di amministrazione di Power BI aggiungere il gruppo di sicurezza all'impostazione del tenant Migliora le risposte dell'API di amministrazione con metadati dettagliati e anche all'impostazione Migliora le risposte dell'API di amministrazione con DAX ed espressioni mashup.
  • Testare l'entità servizio: creare uno script semplice per accedere usando l'entità servizio e verificare che possa recuperare i dati da un'API amministratore.
  • Creare un processo per gestire i segreti di registrazione delle app: creare la documentazione e un processo per ruotare regolarmente i segreti. Determinare come comunicare in modo sicuro un nuovo segreto a tutti gli amministratori e gli sviluppatori che ne hanno bisogno.

Impostare il tenant di Power BI

Esistono diverse impostazioni del tenant nel portale di amministrazione di Power BI rilevanti per l'estrazione dei dati di controllo a livello di tenant.

API di amministrazione

Esistono tre impostazioni del tenant rilevanti per l'esecuzione delle API di amministrazione.

Importante

Poiché queste impostazioni concedono l'accesso ai metadati per l'intero tenant (senza assegnare autorizzazioni dirette a Power BI), è consigliabile controllarle strettamente.

L'impostazione del tenant Consenti alle entità servizio di usare le API di amministrazione di Power BI di sola lettura consente di impostare le entità servizio che possono chiamare le API di amministratore. Questa impostazione consente anche a Microsoft Purview di analizzare l'intero tenant di Power BI in modo da popolare il catalogo dati.

Nota

Non è necessario assegnare in modo esplicito altri amministratori di Power BI all'impostazione del tenant Consenti alle entità servizio di usare le API di amministrazione di Power BI di sola lettura perché hanno già accesso ai metadati a livello di tenant.

L'impostazione del tenant Migliora le risposte dell'API di amministrazione con metadati dettagliaticonsente di impostare quali utenti e entità servizio possono recuperare metadati dettagliati. I metadati vengono recuperati usando le API di analisi dei metadati e includono tabelle, colonne e altro ancora. Questa impostazione consente anche a Microsoft Purview di accedere alle informazioni a livello di schema sui modelli semantici di Power BI in modo da archiviarle nel catalogo dati.

L'impostazione del tenant Migliora le risposte dell'API di amministrazione con espressioni e mashup DAX consente di impostare quali utenti e entità servizio possono recuperare metadati dettagliati. I metadati vengono recuperati dalle API di analisi dei metadati e possono includere query ed espressioni di misura del modello semantico.

Nota

L'impostazione del tenant Consenti alle entità servizio di usare le API di amministrazione di Power BI di sola lettura riguarda in particolare l'accesso alle API amministratore. Il suo nome è molto simile all'impostazione del tenant destinata all'accesso alle API utente (descritta di seguito). Per altre informazioni sulla differenza tra le API di amministrazione e le API utente, vedere Scegliere un'API utente o un'API amministratore in precedenza in questo articolo.

API utente

Esiste un'impostazione del tenant che si applica alle API utente chiamanti. In questo caso, le autorizzazioni di Power BI sono necessarie anche per l'entità servizio, ad esempio un ruolo dell'area di lavoro.

L'impostazione del tenant Consenti alle entità servizio di usare le API di Power BI consente di impostare quali entità servizio hanno accesso per l'esecuzione di API REST (escluse le API di amministrazione, concesse da un'impostazione del tenant diversa, descritta in precedenza).

Esistono altre impostazioni del tenant correlate alle API, che consentono l'accesso alle API di incorporamento, alle API di streaming, alle API di esportazione e all'API di esecuzione query. Tuttavia, queste API non rientrano nell'ambito di questo articolo.

Per altre informazioni sulle impostazioni del tenant per le metriche di utilizzo, vedere Controllo a livello di report.

Elenco di controllo: quando si configurano le impostazioni del tenant di Power BI, le decisioni chiave e le azioni includono:

  • Verificare che ogni entità servizio sia nel gruppo corretto: verificare che il gruppo Entità servizio di amministrazione di Power BI includa le entità servizio corrette.
  • Aggiornare l'impostazione del tenant dell'API di amministrazione in Power BI: aggiungere il gruppo di sicurezza all'impostazione del tenant Consenti alle entità servizio di usare le API di amministrazione di Power BI di sola lettura, cosa che consente di usare le API di amministrazione per recuperare i metadati a livello di tenant.
  • Aggiornare le impostazioni dettagliate del tenant dei metadati in Power BI: se necessario, aggiungere il gruppo di sicurezza alle impostazioni del tenant Migliora le risposte dell'API di amministrazione con metadati dettagliati e Migliora le risposte dell'API di amministrazione con le espressioni mashup e DAX.
  • Verificare quali API utente saranno accessibili: verificare se saranno necessarie una o più API utente (oltre a usare le API di amministrazione).
  • Aggiornare l'impostazione del tenant dell'API utente in Power BI: aggiungere il gruppo di sicurezza all'impostazione del tenant Consenti alle entità servizio di usare le API di Power BI, destinata alle API utente.

Fase 3: Sviluppo e analisi delle soluzioni

La terza fase di pianificazione e implementazione di una soluzione di controllo a livello di tenant è incentrata sullo sviluppo e l'analisi delle soluzioni. A questo punto, è stata eseguita tutta la pianificazione così come il processo decisionale e sono stati soddisfatti i prerequisiti. In più, è stata completatala configurazione. A questo punto si è pronti per iniziare lo sviluppo di soluzioni in modo da poter eseguire analisi e ottenere informazioni dettagliate dai dati di controllo.

Diagramma di flusso che descrive la fase 3, che è incentrata sullo sviluppo e l'analisi della soluzione di controllo a livello di tenant.

Estrarre e archiviare i dati non elaborati

A questo punto, i requisiti e le priorità devono essere chiari. Le decisioni tecniche principali sono state prese su come accedere ai dati di controllo e sulla posizione per archiviare i dati di controllo. Sono stati selezionati gli strumenti preferiti e sono stati configurati i prerequisiti e le impostazioni. Durante le due fasi precedenti, potrebbero essere stati completati uno o più progetti di piccole dimensioni (modelli di verifica) per dimostrare la fattibilità. Il passaggio successivo consiste nel configurare un processo per estrarre e archiviare i dati di controllo non elaborati.

Analogamente ai dati restituiti dalla maggior parte delle API Microsoft, i dati di controllo vengono formattati come JSON. I dati in formato JSON sono autodescrittivi perché sono testo leggibile che contiene struttura e dati.

JSON rappresenta gli oggetti dati costituiti da coppie di valori di attributo e matrici. Ad esempio, "state": "Active" è un esempio in cui il valore dell'attributo stato è Attivo. Una matrice JSON contiene un elenco ordinato di elementi separati da una virgola e racchiusi tra parentesi quadre ([ ]). È comune trovare matrici annidate nei risultati JSON. Dopo aver acquisito familiarità con la struttura gerarchica di un risultato JSON, è semplice comprendere la struttura dei dati, ad esempio un elenco (matrice) di modelli semantici in un'area di lavoro.

Ecco alcune considerazioni per l'estrazione e l'archiviazione dei dati non elaborati recuperati dalle API.

  • Quale convenzione di denominazione verrà usata? Per un sistema basato su file, è necessaria una convenzione di denominazione per file, cartelle e zone data lake. Per un database, è necessaria una convenzione di denominazione per tabelle e colonne.
  • Quale formato verrà usato per archiviare i dati non elaborati? Man mano che Power BI continua a introdurre nuove funzionalità, compariranno nuove attività. Per questo motivo, è consigliabile estrarre e conservare i risultati JSON originali. Non analizzare, filtrare o formattare i dati durante l'estrazione. In questo modo, è possibile usare i dati non elaborati originali per rigenerare i dati di controllo curati.
  • Quale posizione di archiviazione verrà usata? Un data lake o un archivio BLOB viene comunemente usato per archiviare dati non elaborati. Per altre informazioni, vedere Determinare dove archiviare i dati di controllo più indietro in questo articolo.
  • Quanta cronologia si archivierà? Esportare i dati di controllo in una posizione in cui è possibile archiviare la cronologia. Pianificare l'accumulo di almeno due anni di cronologia. In questo modo, è possibile analizzare le tendenze e le modifiche oltre il periodo di conservazione predefinito di 30 giorni. È possibile scegliere di archiviare i dati per un periodo illimitato o decidere un periodo più breve, a seconda dei criteri di conservazione dei dati per l'organizzazione.
  • Come si tiene traccia dell'ultima esecuzione del processo? Configurare un file di configurazione o l'equivalente per registrare i timestamp all'avvio e al termine di un processo. Alla successiva esecuzione del processo, può recuperare questi timestamp. È particolarmente importante archiviare timestamp quando si estraggono dati usando le API di analisi dei metadati.
  • Come si gestirà la limitazione? Alcune API REST di Power BI e l'API Microsoft Graph implementano la limitazione. Se la richiesta API è limitata, si riceverà un errore 429 (troppe richieste). La limitazione può essere un problema comune per le organizzazioni di grandi dimensioni che devono recuperare un volume elevato di dati. Il modo in cui si evitano tentativi non riusciti a causa della limitazione dipende dalla tecnologia usata per accedere ed estrarre i dati. Un'opzione consiste nello sviluppare logica negli script che rispondono a un errore 429 "Troppe richieste" ritentando dopo un periodo di attesa.
  • I dati di controllo sono necessari per la conformità? Molte organizzazioni usano i record del log di controllo non elaborati per eseguire controlli di conformità o per rispondere alle indagini sulla sicurezza. In questi casi, è consigliabile archiviare i dati non elaborati nell'archiviazione non modificabile. In questo modo, una volta scritti i dati, non possono essere modificati o eliminati da un amministratore o da un altro utente.
  • Quali livelli di archiviazione sono necessari per supportare i requisiti? Le posizioni migliori per archiviare i dati non elaborati sono un data lake (ad esempio Azure Data Lake Storage Gen2) o un archivio oggetti (ad esempio Archiviazione BLOB di Azure). Un file system può essere usato anche se i servizi cloud non sono un'opzione.

Elenco di controllo: quando si estraggono e archiviano i dati non elaborati, le decisioni e le azioni principali includono:

  • Confermare i requisiti e le priorità: chiarire i requisiti e le priorità per i dati che verranno estratti per primi.
  • Confermare l'origine dei dati da estrarre: verificare l'origine per ogni tipo di dati necessario.
  • Configurare un processo per estrarre i dati e caricarli nell'area dei dati non elaborati: creare il processo iniziale per estrarre e caricare i dati non elaborati nello stato originale, senza alcuna trasformazione. Verificare che il processo funzioni come previsto.
  • Creare una pianificazione per eseguire i processi: configurare una pianificazione ricorrente per eseguire i processi di estrazione, caricamento e trasformazione.
  • Verificare che le credenziali siano gestite in modo sicuro: verificare che le password, i segreti e le chiavi vengano archiviati e comunicati in modo sicuro.
  • Verificare che la sicurezza sia configurata correttamente: verificare che le autorizzazioni di accesso siano configurate correttamente per i dati non elaborati. Assicurarsi che gli amministratori e i revisori possano accedere ai dati non elaborati.

Per altre informazioni sull'aumento nel tempo di una soluzione di controllo e monitoraggio, vedere Rendere operativo e migliorare più avanti in questo articolo.

Creare i dati curati

A questo punto, i dati non elaborati vengono estratti e archiviati. Il passaggio successivo consiste nel creare un livello dati gold separato per i dati curati. L'obiettivo è trasformare e archiviare i file di dati in uno schema stella. Uno schema a stella include tabelle delle dimensioni e tabelle dei fatti ed è intenzionalmente ottimizzato per l'analisi e la creazione di report. I file nel livello dati curato diventano l'origine di un modello di dati di Power BI (descritto nell'argomento successivo).

Suggerimento

Quando si prevede che siano presenti più modelli di dati, l'investimento in un livello dati curato centralizzato è particolarmente utile.

Elenco di controllo: quando si crea il livello di dati curati, le decisioni chiave e le azioni includono:

  • Confermare i requisiti e le priorità: se si intende usare un livello silver intermedio per i dati trasformati, chiarire i requisiti e gli obiettivi necessari.
  • Configurare un processo per trasformare i dati non elaborati e caricarli nell'area dati curata: creare un processo per trasformare e caricare i dati in uno schema a stella. Verificare che il processo funzioni come previsto.
  • Creare una pianificazione per eseguire i processi: configurare una pianificazione ricorrente per popolare il livello dati curato.
  • Verificare che la sicurezza sia configurata correttamente: verificare che le autorizzazioni di accesso siano configurate correttamente per i dati curati. Assicurarsi che gli sviluppatori del modello di dati possano accedere ai dati curati.

Creare un modello di dati

L'argomento riguarda la configurazione di un modello di dati analitico. Un modello di dati è ottimizzato per le risorse di dati in grado di eseguire query per l'analisi. A volte viene definito modello semantico o semplicemente modello. Per la soluzione di controllo e monitoraggio, è probabile che il modello di dati venga implementato come modello semantico di Power BI.

Nel contesto del controllo e del monitoraggio, i dati di un modello di dati provengono dal livello dati curato (oro). Se si sceglie di non creare un livello dati curato, il modello di dati esegue l'origine dei dati direttamente dai dati non elaborati.

È consigliabile che il modello di dati di Power BI implementi una progettazione dello schema a stella. Quando i dati di origine sono il livello dati curato, lo schema a stella del modello di dati di Power BI deve rispecchiare quello del livello dati curato.

Suggerimento

Per una panoramica della progettazione di uno schema a stella, vedere Informazioni su uno schema star e sull'importanza di questo schema per Power BI.

Come per qualsiasi progetto di Power BI, la creazione di un modello di dati è un processo iterativo. È possibile aggiungere nuove misure in base alle esigenze. È anche possibile aggiungere nuove tabelle e colonne man mano che diventano disponibili nuovi eventi di controllo. Nel tempo è anche possibile integrare nuove origini dati.

Ecco alcune tabelle delle dimensioni utili che è possibile includere nel modello di dati.

  • Data: set di attributi di data per abilitare l'analisi (sezionamento e dicing) dei dati in base al giorno, alla settimana, al mese, al trimestre, all'anno e ad altri periodi di tempo pertinenti.
  • Ora: se è necessario analizzare in base all'ora del giorno e si dispone di un volume molto elevato di dati di controllo, è consigliabile archiviare la parte dell'ora separatamente dalla data. Questo approccio consente di migliorare le prestazioni delle query.
  • Utenti: attributi che descrivono gli utenti (ad esempio reparto e area geografica) che possono filtrare molti soggetti dei dati di controllo. L'obiettivo è rimuovere tutti i dettagli utente dalle tabelle dei fatti e archiviarli in questa tabella delle dimensioni in modo che possano filtrare molte tabelle dei fatti. È anche possibile archiviare le entità servizio in questa tabella.
  • Eventi attività: attributi che raggruppano e descrivono gli eventi di attività (operazioni). Per migliorare la creazione di report, è possibile creare un dizionario dati che descrive ogni evento di attività. È anche possibile creare una gerarchia che raggruppa e classifica eventi di attività simili. Ad esempio, è possibile raggruppare tutti gli eventi di creazione di elementi, eliminare eventi e così via.
  • Aree di lavoro: un elenco di aree di lavoro nelle proprietà del tenant e dell'area di lavoro, ad esempio tipo (personale o standard) e descrizione. Alcune organizzazioni registrano altri dettagli sulle aree di lavoro (possibilmente usando un elenco di SharePoint). È possibile integrare questi dettagli in questa tabella delle dimensioni. È necessario decidere se questa tabella delle dimensioni archivierà solo lo stato corrente dell'area di lavoro o se archivierà i dati con controllo delle versioni che riflettono modifiche significative dell'area di lavoro nel tempo. Ad esempio, quando cambia il nome di un'area di lavoro, la segnalazione cronologica mostra il nome dell'area di lavoro corrente o il nome dell'area di lavoro corrente in quel momento? Per altre informazioni sul controllo delle versioni, vedere Dimensioni a modifica lenta.
  • Tipi di elemento: un elenco di tipi di elementi di Power BI (modelli semantici, report e altri).
  • Capacità: elenco di capacità Premium nel tenant.
  • Gateway: un elenco di gateway dati nel tenant.
  • Origini dati: elenco di origini dati usate da qualsiasi modello semantico, flusso di dati o datamart.

Ecco alcune utili tabelle dei fatti (soggetti) che è possibile includere nel modello di dati.

  • Attività utente: i dati dei fatti originati dai dati JSON originali. Tutti gli attributi senza valore analitico vengono rimossi. Anche gli attributi appartenenti alle tabelle delle dimensioni (sopra) vengono rimossi.
  • Inventario tenant: uno snapshot temporizzato di tutti gli elementi pubblicati nel tenant. Per altre informazioni, vedere Inventario tenant più indietro in questo articolo.
  • Modelli semantici: include attività utente che coinvolgono modelli semantici (ad esempio modifiche del modello semantico) o origini dati correlate.
  • Aggiornamenti del modello semantico: archivia le operazioni di aggiornamento dei dati, inclusi i dettagli sul tipo (pianificato o su richiesta), la durata, lo stato e l'utente che ha avviato l'operazione.
  • Ruoli dell'area di lavoro: uno snapshot temporizzato delle assegnazioni di ruolo dell'area di lavoro.
  • Licenze utente: uno snapshot temporizzato delle licenze utente. Anche se si potrebbe essere tentati di archiviare la licenza utente nella tabella delle dimensioni Utenti, questo approccio non supporterà l'analisi delle modifiche e delle tendenze delle licenze nel tempo.
  • Appartenenze ai gruppi utente: uno snapshot temporizzato degli utenti (e delle entità servizio) assegnati a un gruppo di sicurezza.
  • Attività della community: include fatti correlati alla community, ad esempio eventi di formazione. Ad esempio, è possibile analizzare le attività degli utenti di Power BI rispetto alla partecipazione alla formazione. Questi dati potrebbero aiutare il COE a identificare potenziali nuovi campioni.

Le tabelle dei fatti non devono includere colonne filtrate dagli autori di report. Queste colonne appartengono invece alle tabelle delle dimensioni correlate. Non solo questa progettazione è più efficiente per le query, ma promuove anche il riutilizzo delle tabelle delle dimensioni da più fatti (approccio noto come drill-through). Questo ultimo punto è importante per produrre un modello di dati utile e intuitivo che sia estendibile quando si aggiungono nuove tabelle dei fatti (soggetti).

Ad esempio, la tabella delle dimensioni Utenti sarà correlata a ogni tabella dei fatti. Deve essere correlata alla tabella dei fatti Attività utenti (chi ha eseguito l'attività), a quella Inventario tenant (chi ha creato l'elemento pubblicato) e a tutte le altre tabelle dei fatti. Quando un report viene filtrato da un utente nella tabella delle dimensioni Utenti, gli oggetti visivi in tale report possono mostrare fatti per tale utente da qualsiasi tabella dei fatti correlata.

Quando si progetta il modello, assicurarsi che un attributo sia visibile una sola volta al suo interno. Ad esempio, l'indirizzo e-mail dell'utente deve essere visibile solo nella tabella delle dimensioni Utenti. Esisterà anche in altre tabelle dei fatti (come chiave della dimensione per supportare una relazione di modello). Tuttavia, è consigliabile nasconderlo in ogni tabella dei fatti.

È consigliabile creare il modello di dati separato dai report. Il disaccoppiamento di un modello semantico e dei relativi report comporta un modello semantico centralizzato in grado di gestire molti report. Per altre informazioni sull'uso di un modello semantico condiviso, vedere lo scenario di utilizzo di business intelligence self-service gestita.

Valutare la possibilità di configurare la sicurezza a livello di riga (RLS) in modo che altri utenti al di là di Centro di eccellenza, revisori e amministratori possano analizzare e segnalare i dati di controllo. Ad esempio, è possibile usare regole di sicurezza a livello di riga per consentire agli autori di contenuti e ai consumer di segnalare le proprie attività utente o attività di sviluppo.

Elenco di controllo : quando si crea il modello di dati, le decisioni chiave e le azioni includono:

  • Pianificare e creare il modello di dati: progettare il modello di dati come schema a stella. Convalidare che le relazioni funzionino come previsto. Durante lo sviluppo del modello, creare misure in modo iterativo e aggiungere altri dati in base ai requisiti analitici. Includere miglioramenti futuri in un backlog, se necessario.
  • Configurare la sicurezza a livello di riga: se si intende rendere disponibile il modello di dati ad altri utenti generali, configurare la sicurezza a livello di riga per limitare l'accesso ai dati. Verificare che i ruoli di sicurezza a livello di riga restituiscano i dati corretti.

Migliorare il modello di dati

Per analizzare in modo efficace l'utilizzo del contenuto e le attività degli utenti, è consigliabile arricchire il modello di dati. I miglioramenti del modello di dati possono essere eseguiti gradualmente e in modo iterativo nel corso del tempo man mano che si individuano opportunità e nuovi requisiti.

Creare classificazioni

Un modo per migliorare il modello e aumentare il valore dei dati consiste nell'aggiungere classificazioni al modello di dati. Assicurarsi che queste classificazioni vengano usate in modo coerente dai report.

È possibile scegliere di classificare utenti in base al livello di utilizzo o classificare il contenuto in base al livello di utilizzo.

Classificazione utilizzo utenti

Considerare le classificazioni seguenti per utilizzo utente.

  • Utente frequente: attività registrata nell'ultima settimana e in nove degli ultimi 12 mesi.
  • Utente attivo: attività registrata nell'ultimo mese.
  • Utente occasionale: attività registrata negli ultimi nove mesi, ma nessuna attività nell'ultimo mese.
  • Utente inattivo: nessuna attività registrata negli ultimi nove mesi.

Suggerimento

È utile sapere chi sono gli utenti occasionali o inattivi, soprattutto quando hanno licenze Pro o PPU (che comportano costi). È anche utile sapere chi sono gli utenti più attivi e frequenti. È consigliabile invitarli a partecipare nelle ore di ufficio o a unirsi alla formazione. Gli autori di contenuti più attivi potrebbero essere candidati per partecipare alla rete campioni.

Classificazione utilizzo contenuto

Considerare le classificazioni seguenti per l'utilizzo del contenuto.

  • Contenuto usato di frequente: attività registrata nell'ultima settimana e in nove degli ultimi 12 mesi.
  • Contenuto usato attivamente: attività registrata nell'ultimo mese.
  • Contenuto usato occasionalmente: attività registrata negli ultimi nove mesi, ma nessuna attività nell'ultimo mese.
  • Contenuto inutilizzato: nessuna attività registrata negli ultimi nove mesi.
Classificazione tipo utente

Considerare le classificazioni seguenti per tipo di utente.

  • Autore di contenuti: attività registrata negli ultimi sei mesi in termini di creazione, pubblicazione o modifica di contenuto.
  • Visualizzatore contenuto: attività registrata negli ultimi sei mesi per la visualizzazione di contenuto ma non per la creazione.

È consigliabile decidere se le classificazioni di utilizzo per utenti o contenuti devono basarsi solo su quanto di recente si è verificata un'attività. È anche consigliabile prendere in considerazione l'utilizzo medio o di tendenza nel corso del tempo.

Si considerino alcuni esempi che illustrano in che modo la logica di classificazione semplice potrebbe rappresentare in modo errato la realtà.

  • Un manager ha visualizzato un report questa settimana. Tuttavia, prima di quella settimana, il manager non aveva visualizzato alcun report negli ultimi sei mesi. Non è consigliabile considerare questo manager come un utente frequente in base solo all'utilizzo recente.
  • Un autore di report pubblica un nuovo report ogni settimana. Quando si analizza l'utilizzo da parte di utenti frequenti, l'attività regolare dell'autore del report sembra essere positiva. Tuttavia, dopo ulteriori indagini, si scopre che l'utente ha ripubblicato un nuovo report (con un nuovo nome) ogni volta che lo modificava. Sarebbe utile che l'autore del report disponga di maggiore formazione.
  • Un dirigente visualizza un report sporadicamente, quindi la classificazione dell'utilizzo cambia frequentemente. Potrebbe essere necessario analizzare determinati tipi di utenti, ad esempio dirigenti, in modo diverso.
  • Un revisore interno visualizza report critici una volta all'anno. Il revisore interno potrebbe sembrare un utente inattivo a causa dell'utilizzo poco frequente. Un utente potrebbe eseguire le operazioni necessarie per rimuovere la licenza Pro o PPU. In alternativa, qualcuno potrebbe credere che un report debba essere ritirato perché viene usato raramente.

Suggerimento

È possibile calcolare le medie e le tendenze usando le funzioni di business intelligence per le gerarchie temporali DAX. Per informazioni su come usare queste funzioni, seguire il modulo di apprendimento Funzioni di business intelligence per le gerarchie temporali DAX nei modelli di Power BI Desktop.

Elenco di controllo: quando si crea la classificazione dei dati di utilizzo, le decisioni chiave e le azioni includono:

  • Ottenere il consenso sulle definizioni di classificazione: discutere delle definizioni di classificazione con gli stakeholder pertinenti. Assicurarsi che sia presente un accordo quando si effettuano le decisioni.
  • Creare la documentazione: assicurarsi che le definizioni di classificazione siano incluse nella documentazione per autori di contenuti e consumer.
  • Creare un ciclo di feedback: assicurarsi che sia disponibile un modo per gli utenti di porre domande o proporre modifiche alle definizioni di classificazione.

Creare report analitici

A questo punto, i dati di controllo sono stati estratti e archiviati ed è stato pubblicato un modello di dati. Il passaggio successivo consiste nel creare report analitici.

Concentrarsi sulle informazioni chiave più rilevanti per ogni pubblico. Potrebbero essere presenti diversi gruppi di destinatari per i report di controllo. Ogni gruppo di destinatari sarà interessato a informazioni diverse e a scopi diversi. I destinatari potenziali dei report includono:

  • Sponsor esecutivo
  • COE (Center of Excellence)
  • Amministratori di Power BI
  • Amministratori area di lavoro
  • Amministratori della capacità Premium
  • Amministratori gateway
  • Sviluppatori e autori di contenuti di Power BI
  • Revisori

Ecco alcuni dei requisiti analitici più comuni da cui iniziare quando si creano i report di controllo.

  • Visualizzazioni dei contenuti principali: lo sponsor esecutivo e i team di leadership potrebbero essere principalmente interessati a informazioni di riepilogo e tendenze nel tempo. Gli amministratori, gli sviluppatori e gli autori di contenuti dell'area di lavoro saranno più interessati ai dettagli.
  • Principali attività utente: il COE sarà interessato a chi usa Power BI, come e quando. Gli amministratori della capacità Premium saranno interessati a chi usa la capacità per garantire l'integrità e la stabilità.
  • Inventario tenant: gli amministratori, gli amministratori dell'area di lavoro e i revisori di Power BI saranno interessati a comprendere quali contenuti esistono, dove, la derivazione e le impostazioni di sicurezza.

Questo elenco non è all-inclusive. È destinato a fornire idee su come creare report analitici per esigenze specifiche. Per altre considerazioni, vedere Esigenze dei dati in precedenza in questo articolo e Panoramica del controllo e del monitoraggio. Queste risorse includono molte idee su come usare i dati di controllo e i tipi di informazioni che è possibile scegliere di presentare nei report.

Suggerimento

Anche se può sembrare ideale presentare molti dati, includere solo le informazioni su cui si è pronti ad agire. Assicurarsi che ogni pagina del report sia chiara in merito allo scopo, l'azione da intraprendere e chi dovrà intraprenderla.

Per informazioni su come creare report analitici, usare il percorso di apprendimento Progettare report efficaci in Power BI.

Elenco di controllo: quando si pianificano report di controllo analitico, le decisioni chiave e le azioni includono:

  • Esaminare i requisiti: assegnare priorità alla creazione di report in base alle esigenze note e a domande specifiche a cui rispondere.
  • Confermare i destinatari: chiarire chi userà i report di controllo e quali saranno gli scopi previsti.
  • Creare e distribuire report: sviluppare il primo set di report principali. Estenderli e migliorarli gradualmente nel tempo.
  • Distribuire i report in un'app: prendere in considerazione la creazione di un'app che includa tutti i report di controllo e monitoraggio.
  • Verificare chi può accedere ai report: assicurarsi che i report (o l'app) siano resi disponibili per il set corretto di utenti.
  • Creare un ciclo di commenti e suggerimenti: assicurarsi che sia disponibile un modo per consentire agli utenti del report di fornire commenti o suggerimenti o segnalare problemi.

Intervenire in base ai dati

Il controllo dei dati è utile perché consente di comprendere cosa accade nel tenant di Power BI. Anche se potrebbe sembrare ovvio, agire in modo esplicito su ciò che si apprende dai dati di controllo può essere facilmente un aspetto trascurato. Per questo motivo, è consigliabile assegnare un utente responsabile del rilevamento dei miglioramenti misurabili, invece di esaminare semplicemente i report di controllo. In questo modo, è possibile fare progressi graduali e misurabili nell'adozione e nel livello di maturità con Power BI.

È possibile eseguire molte azioni diverse in base agli obiettivi e alle informazioni apprese dai dati di controllo. Nella parte restante di questa sezione vengono fornite diverse idee.

Utilizzo del contenuto

Ecco alcune azioni che è possibile eseguire in base alla modalità di utilizzo del contenuto.

  • Il contenuto viene usato di frequente (ogni giorno o settimana): verificare che qualsiasi contenuto critico sia certificato. Verificare che la proprietà sia chiara e che la soluzione sia supportata in modo adeguato.
  • Numero elevato di visualizzazioni dell'area di lavoro: quando si verifica un numero elevato di visualizzazioni dell'area di lavoro, esaminare il motivo per cui le app Power BI non sono in uso.
  • Il contenuto viene usato raramente: contattare gli utenti di destinazione per determinare se la soluzione soddisfa le proprie esigenze o se i requisiti sono stati modificati.
  • L'attività di aggiornamento si verifica più frequentemente rispetto alle visualizzazioni: contattare il proprietario del contenuto per comprendere perché un modello semantico viene aggiornato regolarmente senza alcun uso recente suo o dei report correlati.

Attività utente

Ecco alcune azioni che è possibile eseguire in base alle attività degli utenti.

  • Prima azione di pubblicazione da parte di un nuovo utente: identificare quando un tipo di utente cambia da consumer ad autore, cosa che è possibile identificare quando pubblica il contenuto per la prima volta. È un'ottima opportunità per inviare loro un messaggio di posta elettronica standard che fornisca indicazioni e collegamenti a risorse utili.
  • Engagement con gli autori di contenuti più attivi: invita i tuoi autori più attivi a partecipare alla tua rete di campioni o a partecipare alla community di pratica.
  • Gestione licenze: verificare se gli autori inattivi necessitano ancora di una licenza Pro o PPU.
  • Attivazione della versione di valutazione utente: un'attivazione della licenza di valutazione può richiedere di assegnare una licenza permanente all'utente prima della fine della versione di valutazione.

Opportunità di formazione degli utenti

Ecco alcune opportunità di formazione utente che è possibile identificare dai dati di controllo.

  • Numero elevato di modelli semantici pubblicati dallo stesso autore di contenuti: insegnare agli utenti i modelli semantici condivisi e perché è importante evitare di creare modelli semantici duplicati.
  • Condivisione eccessiva da un'area di lavoro personale: contattare un utente che sta condividendo molti contenuti dall'area di lavoro personale. Insegnare loro informazioni sulle aree di lavoro standard.
  • Visualizzazioni di report significative da un'area di lavoro personale: contattare un utente proprietario di contenuto con un numero elevato di visualizzazioni report. Insegnargli in che modo le aree di lavoro standard sono migliori rispetto alle aree di lavoro personali.

Suggerimento

È anche possibile migliorare il contenuto o la documentazione di training esaminando le domande fornite dalla community di Power BI interna e i problemi inviati all'help desk.

Sicurezza

Ecco alcune situazioni di sicurezza che è possibile monitorare attivamente.

Per altre informazioni, vedere gli articoli Pianificazione della sicurezza.

Governance e mitigazione dei rischi

Ecco alcune situazioni possibili. È consigliabile cercare in modo esplicito questi tipi di situazioni nei report di controllo, per poter agire rapidamente.

  • Numero elevato di visualizzazioni per i report (e i modelli semantici sottostanti) che non sono approvati.
  • Uso significativo di origini dati sconosciute o non approvate.
  • Percorsi di file che non sono allineati alle linee guida di governance per la posizione dei file di origine.
  • I nomi delle aree di lavoro non sono allineati ai requisiti di governance.
  • Le etichette di riservatezza vengono usate per la protezione delle informazioni.
  • Errori di aggiornamento dei dati coerenti.
  • Uso significativo e ricorrente della stampa.
  • Uso imprevisto o eccessivo delle sottoscrizioni.
  • Uso imprevisto di gateway personali.

Le azioni specifiche da intraprendere in ogni situazione dipendono dai criteri di governance. Per altre informazioni, vedere Governance nella roadmap di adozione di Fabric.

Elenco di controllo: quando si pianificano azioni potenziali in base ai dati di controllo, le decisioni e le azioni principali includono:

  • Chiarire le aspettative: creare report di controllo con un set chiaro di aspettative per le azioni previste.
  • Chiarire chi sarà responsabile delle azioni: assicurarsi che vengano assegnati ruoli e responsabilità.
  • Creare automazione: quando possibile, automatizzare le azioni note ripetibili.
  • Usare un sistema di rilevamento: usare un sistema per tenere traccia di una situazione osservata, inclusi i contatti effettuati, l'azione pianificata successiva, il responsabile, la risoluzione e lo stato.

Fase 4: Gestire, migliorare e monitorare

La quarta fase di pianificazione e implementazione di una soluzione di controllo a livello di tenant è incentrata sulla manutenzione, i miglioramenti e il monitoraggio. A questo punto, la soluzione di controllo è in uso nell'ambiente di produzione. Si è interessati principalmente alla gestione, al miglioramento e al monitoraggio della soluzione.

Diagramma di flusso che descrive la fase 4, che si concentra sulla gestione, il miglioramento e il monitoraggio di una soluzione di controllo a livello di tenant.

Rendere operativo e migliorare

I processi di controllo vengono in genere considerati in esecuzione nell'ambiente di produzione quando lo sviluppo iniziale e i test sono stati completati ed è stato automatizzato il processo. I processi di controllo automatizzati in esecuzione nell'ambiente di produzione hanno aspettative maggiori (rispetto ai processi manuali) per qualità, affidabilità, stabilità e supporto.

Un processo di controllo a livello di produzione è stato reso operativo. Una soluzione operativa include in genere molte delle caratteristiche seguenti.

  • Sicuro: le credenziali vengono archiviate e gestite in modo sicuro. Gli script non contengono password o chiavi in testo non crittografato.
  • Pianificazione: è disponibile un sistema di pianificazione affidabile.
  • Gestione modifiche: l'uso di procedure di gestione delle modifiche e di più ambienti è per garantire che l'ambiente di produzione sia protetto. È anche possibile usare ambienti di sviluppo e test o solo un ambiente di sviluppo.
  • Supporto: il team che supporta la soluzione è chiaramente definito. I membri del team sono stati formati e comprendono le aspettative operative. I membri di backup sono stati identificati e il training incrociato avviene quando appropriato.
  • Avvisi: in caso di problemi, il team di supporto riceve automaticamente degli avvisi. Preferibilmente, l'invio di avvisi include sia log che e-mail (anziché solo e-mail). Un log è utile per analizzare gli errori e gli avvisi registrati.
  • Registrazione: i processi vengono registrati in modo che sia presente una cronologia di quando i dati di controllo sono stati aggiornati. Le informazioni registrate devono indicare l'ora di inizio, l'ora di fine e l'identità dell'utente o dell'app che ha eseguito il processo.
  • Gestione degli errori: script e processi gestiscono e registrano correttamente gli errori, ad esempio se uscire immediatamente, continuare o attendere e riprovare. Le notifiche di avviso vengono inviate al team di supporto quando si verifica un errore.
  • Standard di codifica: tecniche di codifica valide e ottimali. Ad esempio, i cicli vengono evitati intenzionalmente tranne quando necessario. Vengono usati standard di codifica, commenti, formattazione e sintassi coerenti in modo che la soluzione sia più semplice da gestire e supportare.
  • Riutilizzo e modularizzazione: per ridurre al minimo la duplicazione, i valori di codice e configurazione (ad esempio stringhe di connessione o indirizzi di posta elettronica per le notifiche) sono modularizzati in modo che altri script e processi possano riutilizzarli.

Suggerimento

Non è necessario eseguire in una sola volta tutte le operazioni elencate in precedenza. Man mano che si acquisisce esperienza, è possibile migliorare in modo incrementale la soluzione in modo che diventi completa e affidabile. Tenere presente che la maggior parte degli esempi che si trovano online sono semplici frammenti di script usa e getta che potrebbero non avere la qualità adatta per un ambiente di produzione.

Elenco di controllo: quando si pianificano l'operazionalizzazione e il miglioramento di una soluzione di controllo, le decisioni e le azioni principali includono:

  • Valutare il livello di soluzioni esistenti: determinare se sono disponibili opportunità di miglioramento e stabilizzazione delle soluzioni di controllo esistenti automatizzate.
  • Stabilire standard a livello di produzione: decidere di quali standard disporre per i processi di controllo automatizzati. Prendere in considerazione i miglioramenti che è possibile aggiungere realisticamente nel tempo.
  • Creare un piano di miglioramento: pianificare di migliorare la qualità e la stabilità delle soluzioni di controllo di produzione.
  • Determinare se sia necessario un ambiente di sviluppo separato: valutare il livello di rischio e la dipendenza dai dati di produzione. Decidere quando creare ambienti di sviluppo e produzione (e test) separati.
  • Prendere in considerazione una strategia di conservazione dei dati: determinare se sia necessario implementare un processo di conservazione dei dati che elimina i dati dopo un determinato periodo di tempo o su richiesta.

Documentazione e supporto

La documentazione e il supporto sono fondamentali per qualsiasi soluzione a livello di produzione. È utile creare diversi tipi di documentazione, a seconda del gruppo di destinatari e dello scopo.

Documentazione tecnica

La documentazione tecnica è destinata al team tecnico che ha creato la soluzione e che migliorerà gradualmente ed espanderà la soluzione nel tempo. È anche una risorsa utile per il team di supporto.

La documentazione tecnica deve includere:

  • Riepilogo dei componenti e dei prerequisiti dell'architettura.
  • Chi possiede e gestisce la soluzione.
  • Chi supporta la soluzione.
  • Un diagramma di architettura.
  • Decisioni di progettazione, tra cui obiettivi, motivi per cui sono state effettuate determinate scelte tecniche e vincoli (ad esempio costi o competenze).
  • Decisioni e scelte sulla sicurezza.
  • Convenzioni di denominazione usate.
  • Codifica e standard tecnici e linee guida.
  • Requisiti di gestione del cambiamento.
  • Istruzioni per la distribuzione, l'impostazione e l'installazione.
  • Aree note di debito tecnico (aree che possono essere migliorate se è possibile farlo).

Documentazione di supporto

A seconda del livello di criticità per la soluzione di controllo, potrebbe essere utile sfruttare un help desk o un team di supporto in caso di problemi urgenti. Potrebbero essere disponibili tutto il giorno, ogni giorno.

La documentazione di supporto viene talvolta definita knowledge base o runbook. Questa documentazione è destinata all'help desk o al team di supporto e deve includere:

  • Indicazioni per la risoluzione dei problemi relativi a un errore. Ad esempio, quando si verifica un errore di aggiornamento dati.
  • Azioni da intraprendere in modo continuativo. Ad esempio, potrebbero essere necessari alcuni passaggi manuali che un utente deve eseguire regolarmente fino a quando non viene risolto un problema.

Documentazione dell'autore del contenuto

Si deriva un valore maggiore dalla soluzione di controllo fornendo analisi di utilizzo e adozione ad altri team dell'organizzazione (con sicurezza a livello di riga applicata, se necessario).

La documentazione degli autori di contenuti è destinata agli autori self-service che creano report e modelli di dati che generano i dati di controllo curati. Include informazioni sul modello di dati, ad esempio le definizioni di dati comuni.

Elenco di controllo: quando si pianificano la documentazione e il supporto per la soluzione di controllo, le decisioni e le azioni principali includono:

  • Confermare chi deve supportare la soluzione: determinare chi supporterà le soluzioni di controllo considerate a livello di produzione (o con dipendenze del report downstream).
  • Garantire l'idoneità del team di supporto: verificare che il team di supporto sia pronto a supportare la soluzione di controllo. Identificare se sono presenti lacune di idoneità che devono essere affrontate.
  • Organizzare la formazione incrociata: eseguire sessioni di trasferimento delle conoscenze o sessioni di formazione incrociata per il team di supporto.
  • Chiarire le aspettative del team di supporto: assicurarsi che le aspettative per la risposta e la risoluzione siano chiaramente documentate e comunicate. Decidere se debba rimanere qualcuno a disposizione per risolvere rapidamente i problemi relativi alla soluzione di controllo.
  • Creare documentazione tecnica: creare documentazione sull'architettura tecnica e sulle decisioni di progettazione.
  • Creare la documentazione di supporto: aggiornare la knowledge base dell'help desk per includere informazioni su come supportare la soluzione.
  • Creare la documentazione per gli autori di contenuti: creare la documentazione per aiutare gli autori self-service a usare il modello di dati. Descrivere le definizioni di dati comuni per migliorare la coerenza dell'uso.

Abilitare gli avvisi

Potrebbe essere necessario generare avvisi in base a condizioni specifiche nei dati di controllo. Ad esempio, è possibile generare un avviso quando un utente elimina un gateway o quando un amministratore di Power BI modifica un'impostazione del tenant.

Per altre informazioni, vedere Monitoraggio a livello di tenant.

Gestione continuativa

È necessario eseguire la gestione continuativa dell'intera soluzione di controllo. Potrebbe essere necessario estendere o modificare la soluzione di controllo quando:

  • L'organizzazione individua nuovi requisiti per i dati.
  • I nuovi eventi di controllo vengono visualizzati nei dati non elaborati esatti dalle API REST di Power BI.
  • Microsoft apporta modifiche alle API REST di Power BI.
  • I dipendenti identificano i modi per migliorare la soluzione.

Importante

Le modifiche di rilievo sono rare, ma possono verificarsi. È importante avere a disposizione un utente che può risolvere rapidamente i problemi o aggiornare la soluzione di controllo quando necessario.

Elenco di controllo: quando si pianifica la gestione continuativa della soluzione di controllo, le decisioni e le azioni principali includono:

  • Assegnare un proprietario tecnico: assicurarsi che siano presenti una proprietà e una responsabilità chiare per l'intera soluzione di controllo.
  • Verificare che esista un backup: assicurarsi che sia presente un proprietario tecnico del backup che possa essere coinvolto in caso di problema urgente che il supporto non è in grado di risolvere.
  • Mantenere un sistema di rilevamento: assicurarsi di avere un modo per acquisire nuove richieste e un modo per classificare le priorità immediate e anche a breve termine, a medio termine e a lungo termine (backlog).

Contenuto correlato

Nell'articolo successivo di questa serie sono presenti informazioni sul monitoraggio a livello di tenant.