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 sul carico di lavoro di Power BI all'interno di Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

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

  • Amministratori di 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.
  • Centro di eccellenza, IT e team bi: i team responsabili della supervisione di Power BI. Potrebbe essere necessario collaborare con gli amministratori di Power BI 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 distribuite 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 sui motivi per cui i dati di controllo sono così utili, vedere Panoramica del controllo e del 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 che si abbia familiarità con ciò che è coinvolto. 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 downstream 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.

  • 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 creatori 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 vuole 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 a diventare 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 Centro di eccellenza. È 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 non è guidato 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 Panoramica del controllo e del 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à dei requisiti: impostare priorità per i requisiti, classificandoli come immediato, 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 i dati in modo che sia disponibile quando necessario.
  • Rivaluta regolarmente i requisiti: creare un piano per rivalutare i requisiti a intervalli regolari (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 un'ampia gamma di metadati sul tenant di Power BI. Per altre informazioni, vedere Scegliere un'API utente o un'API amministratore più avanti in questo articolo.

Dati dell'attività utente

Rendere la prima priorità per ottenere i dati sulle attività degli utenti. Le attività utente, chiamate anche eventi o operazioni, sono utili per un'ampia gamma di scopi.

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

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

  • Trovare gli utenti principali e il contenuto principale
    • 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 di tendenza verso l'alto o verso il basso?
    • 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 creatori 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 formazione e formazione degli utenti
    • Chi sta facendo (troppo) condivisione dall'area di lavoro personale?
    • Chi sta facendo una notevole quantità di esportazione?
    • Chi scarica regolarmente i contenuti?
    • Chi pubblica molti nuovi modelli semantici, noti in precedenza come set di dati?
    • Chi usa pesantemente 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 viene creata o aggiornata e da quale utente?

Per altre informazioni su come 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 archiviarlo in una posizione sicura. In questo modo, i dati saranno disponibili quando si è pronti per analizzarli. La cronologia è disponibile per 30 giorni o 90 giorni, a seconda dell'origine usata.

Per altre informazioni, vedere Accedere ai dati delle 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.

  • Comprendere la quantità di contenuti che hai e dove
    • 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 si sta verificando il riutilizzo del modello semantico?
    • Esistono modelli semantici duplicati o altamente simili?
    • Ci sono opportunità di consolidare i modelli semantici?
  • Comprendere le tendenze tra punti nel tempo
    • Il numero di report aumenta nel tempo?
    • Il numero di modelli semantici aumenta nel tempo?
  • Trovare il 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 sui modi per usare un inventario tenant, vedere Informazioni sui contenuti pubblicati.

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, sarà necessario 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 di inventario tenant più avanti in questo articolo.

Dati di utenti e gruppi

Man mano che le esigenze analitiche aumentano, è probabile che si determini che si vogliono 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 Microsoft Entra ID (noto in precedenza come Azure Active Directory) utenti e gruppi.

I dati recuperati dalle API REST di Power BI includono un indirizzo di posta elettronica 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
    • Qual è il nome utente completo (oltre all'indirizzo di posta elettronica), al reparto o alla posizione originata 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 aggiuntive sull'utente
    • 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 ai 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 che le API REST di Power BI possono rispondere.

  • Identificare persone e applicazioni
    • Quali report hanno accesso a un utente, un gruppo o un'entità servizio?
    • Quali utenti, gruppi o entità servizio sono sottoscrittori per ricevere report con una sottoscrizione di posta elettronica?
  • Informazioni sulle autorizzazioni per il contenuto
  • Informazioni sulle altre autorizzazioni
    • Chi ha l'autorizzazione per la pubblicazione usando una pipeline di distribuzione?
    • Chi ha l'autorizzazione per gestire gateway e connessioni dati?
    • Chi ha l'autorizzazione per gestire una capacità Premium?

Importante

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

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

Suggerimento

Per altre considerazioni sulla sicurezza, vedere gli articoli sulla 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 influisce 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 delle attività utente: convalidare i requisiti raccolti. Identificare i dati di controllo necessari per soddisfare ogni requisito per i dati delle attività utente.
  • Identificare specifiche esigenze di dati per i dati di inventario tenant: convalidare i requisiti raccolti. Identificare i dati di controllo necessari per compilare un inventario tenant.
  • Identificare le esigenze specifiche dei dati per 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 i dati di 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 prima cosa sviluppare.
  • 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 l'intervallo per acquisire i dati degli snapshot, ad esempio un inventario tenant o gli utenti e i dati dei 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 occasionali.
  • 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 normale, ricorrente, è necessario ottenere i dati di controllo attualmente gestiti manualmente, è consigliabile investire tempo per automatizzarlo. 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 i dati mancanti siano in caso di problemi o in vacanza.

Elenco di controllo : quando si considera il tipo di soluzione di controllo da sviluppare, le decisioni chiave e le azioni 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 è temporanea o permanente.
  • Creare un piano per automatizzare: quando è appropriato per un determinato requisito di controllo, creare un piano per automatizzarlo, quando e da chi.

Autorizzazioni e responsabilità

A questo punto, è necessario avere un'idea chiara di ciò che si vuole eseguire e dei dati necessari inizialmente. Ora è 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 utente per altri utenti che dovranno accedere ai dati. In particolare, decidere chi potrà accedere e visualizzare i dati di controllo.

Ecco alcune considerazioni da tenere in considerazione.

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 (anziché le 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 settori.
  • Sono presenti volumi di dati di attività di grandi dimensioni? Per evitare di raggiungere i limiti di limitazione 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 Centro di eccellenza (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 saranno coinvolti nella 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 it e in collaborazione con il COE.
Creare i dati curati Pulizia dei dati, trasformazione e creazione dei dati curati nella progettazione dello schema star. Personale di ingegneria dei dati, in genere it e in collaborazione con il COE.
Creare un modello di dati Creazione di un modello di dati analitici basato sui dati curati. Creatori di contenuti di Power BI, in genere in 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. Creatori di report di Power BI, in genere in 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, in genere il COE. Può includere anche altri team a seconda dei risultati del controllo e dell'azione. Altri team possono includere sicurezza, conformità, legale, 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. Creatori 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 di sistema 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 it e in collaborazione con il COE.
Supportare la soluzione Monitorare la soluzione di controllo, incluse 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.

Si considerino diversi 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 pertinenti dell'ID Entra di Microsoft 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 gli 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 eseguita: il comitato di governance dei dati avvia un progetto per definire definizioni comuni. La coe aggiorna la documentazione e il training per gli autori di contenuti che creano modelli di dati. Il COE collabora anche con i creatori 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 tenant più avanti in questo articolo.

Nota

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

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

  • Identificare i team coinvolti: determinare quali team saranno coinvolti nella creazione end-to-end e nel 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: definire un piano per il personale di formazione quando richiedono 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 di rielaborare e migliorare la sicurezza, è consigliabile prendere queste decisioni il prima possibile.

La prima fase di pianificazione prevede di prendere 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 LE API o i 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 lingua preferita. 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 iniziare.

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

Tecnologia Buona scelta per i processi di controllo manuale Buona scelta per i processi di controllo automatizzati
Area di lavoro monitoraggio amministratore Amministrazione'area di lavoro di monitoraggio è una scelta ottimale per i processi di controllo manuali.
Prova Try-it è una buona scelta per i processi di controllo manuali.
PowerShell PowerShell è una buona scelta per i processi di controllo manuali. PowerShell è una buona scelta per i processi di controllo automatizzati.
Power BI Desktop Power BI Desktop è una buona scelta 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 ottimale per i processi di controllo automatizzati.
Strumento/linguaggio preferito Strumento/linguaggio preferito è una buona scelta per i processi di controllo manuale. Strumento/linguaggio preferito è una buona scelta per i processi di controllo automatizzati.
Ricerca log di controllo di Microsoft Purview La ricerca nei log di controllo di Microsoft Purview è una buona scelta per i processi di controllo manuali.
Defender per app cloud Defender per il cloud App è una buona scelta per i processi di controllo manuali.
Microsoft Sentinel Microsoft Sentinel è una buona scelta 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 amministratore contiene report predefiniti e modelli semantici nel servizio Power BI. È un modo pratico per gli amministratori di Fabric e gli amministratori globali di visualizzare i dati di controllo recenti e aiutarli a comprendere le attività degli utenti.

Documentazione dell'API try-it

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 autenticato. Segue il modello di autorizzazioni standard, ovvero 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: 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: 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 un'estensione 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 buona scelta 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 offre fino a 30 giorni di dati, la creazione dell'intera soluzione di controllo comporta l'accumulo di un set di file nel tempo che archivia tutti gli eventi cronologici. L'accumulo di file cronologici è più semplice da eseguire con altri strumenti.
  • Gestione sicura delle credenziali e delle chiavi: molte soluzioni disponibili online dai blogger della community non sono sicure perché hardcoded credenziali e chiavi 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 possa 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 che non si:
    • Usare un connettore personalizzato sviluppato con Power Query SDK. Ad esempio, un connettore personalizzato potrebbe leggere 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. Tuttavia, non è possibile archiviare il valore della chiave nel servizio Power BI.
  • Tipi di richieste: è possibile che si verifichino 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 aggiornamento: è necessario seguire modelli di sviluppo specifici di Power Query per aggiornare correttamente un modello semantico nella 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. È consigliabile usarlo 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 preferito e/o lingua

È 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 nella 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 di ricerca log di controllo 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 per il cloud Apps

Defender per il cloud App è 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. Visualizza 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 per il cloud Apps è un'opzione valida per i processi di controllo manuali. Per altre informazioni, vedere Defender per il cloud App 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 alla 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 il Linguaggio di query Kusto (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 all'elaborazione automatizzata. Ad esempio, un utente esegue sempre la funzionalità Try-it in modo interattivo, quindi è adatta solo ai processi di controllo manuali.
  • Come si esegue 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 il tuo team è già esperto? Se c'è uno strumento che il team preferisce ed è comodo usare, iniziare da lì.
  • Qual è il tuo team in grado di supportare? Se un team diverso supporterà la soluzione distribuita, valutare se il team è in grado di supportarlo in modo adeguato. Considerare anche che i team interni potrebbero supportare lo sviluppo svolto dai consulenti.
  • Quale strumento si dispone dell'approvazione da usare? Alcuni strumenti e tecnologie potrebbero richiedere l'approvazione. Potrebbe essere dovuto al costo. Potrebbe anche essere dovuto ai criteri di sicurezza IT.
  • Qual è la preferenza per la pianificazione? Alcune tecnologie prendere la decisione per te. Altre volte sarà un'altra decisione che dovete 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: rivolgersi ai 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 concentrarsi sulla decisione su cosa usare in futuro.

Determinare il metodo di autenticazione

Il modo in cui si prevede di configurare l'autenticazione è una decisione critica. È spesso uno degli aspetti più difficili quando si inizia 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 alla 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 eseguire l'autenticazione, nota come accesso. I concetti relativi all'autenticazione e all'autorizzazione sono separati, ma correlati. Un processo di autenticazione verifica l'identità di chi effettua la richiesta. Un processo di autorizzazione concede (o nega) l'accesso a un sistema o a una risorsa verificando le operazioni che l'utente o l'entità servizio ha per fare.

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: emessi per conto di un utente con un'identità nota.
  • Token solo app: emessi per conto di un'applicazione Microsoft Entra (entità servizio).

Per altre informazioni, vedere Oggetti applicazione e 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. Il termine entità servizio viene usato comunemente anche 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 Connessione-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 Login-PowerBI cmdlet e Login-PowerBIServiceAccount , ovvero alias per Connect-PowerBIServiceAccount il cmdlet . È 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 Buona scelta per i processi di controllo manuale Buona scelta per i processi di controllo automatizzati
Autenticazione dell'utente Accedere come utente usando il nome dell'entità utente (indirizzo di posta elettronica) e una password. Uso occasionale interattivo L'autenticazione utente è una buona scelta 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 buona scelta 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:
    • Amministrazione istrator autorizzazioni per le API di amministrazione: È necessario usare le autorizzazioni di amministratore di Power BI per inviare una richiesta a un'API di amministrazione.
    • 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 amministratore.
  • Accesso interattivo: si vuole accedere in modo interattivo, 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 di seguito), 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. Anziché 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: a volte 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 ha un tenant Microsoft Entra, quindi i termini registrazione dell'app e entità servizio tendono a essere usati in modo intercambiabile. Quando si registra un'app Microsoft Entra, sono disponibili due componenti.

  • Registrazione dell'app: la registrazione di un'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. Nella 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. Nella portale di Azure le entità servizio sono disponibili nella pagina Applicazioni aziendali 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 a chi è autorizzato a creare e fornire il consenso per la registrazione di un'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).
  • Usare da 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:
    • Multi-Factor Authentication (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 descrive lo scopo e il gruppo di destinatari (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 Read e ReadWrite. 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 Target
PowerBIData-Read-Amministrazione APIs-EntraApp Estrarre metadati a livello di tenant per il controllo e l'amministrazione di Power BI. Amministrazione API 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 Centro di eccellenza
PowerBIData-ReadWrite-PowerBI Amministrazione istrators-EntraApp Gestire il tenant di Power BI. Sono necessarie autorizzazioni di lettura/scrittura per creare o aggiornare le risorse. Amministratori di Power BI e Centro di eccellenza
GraphData-Read-PowerBI Amministrazione istrators-EntraApp Estrarre i dati di utenti e gruppi per il controllo e l'amministrazione di Power BI. Richiede autorizzazioni di lettura. Amministratori di Power BI e Centro di eccellenza

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

  • Scopri come usare la registrazione dell'app e perché: quando viene visualizzato l'ID client dalla registrazione dell'app vengono visualizzati nei dati di controllo, hai un'idea di cosa è stato usato e perché. Questo è un vantaggio significativo della creazione di registrazioni di app separate (anziché usare solo una per tutti gli scopi).
  • Vedere chi deve essere usata dalla registrazione dell'app: quando viene visualizzato l'ID client dalla registrazione dell'app nei dati di controllo, si avrà un'idea di chi l'usa.
  • 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; 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 che gestiscono a livello di codice i modelli semantici; devono 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 (descritto 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. Implica 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 delle 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 Impostare le impostazioni del tenant di Power BI più avanti in questo articolo.
    • Per l'esecuzione di API utente: si applicano le autorizzazioni per l'area di lavoro di Power BI e gli elementi. 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 non può accedere a nulla oltre a ciò che l'utente connesso può accedere. Tenere presente che si tratta di un concetto diverso rispetto all'autenticazione solo utente, descritto 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, causando molte registrazioni di app con provisioning eccessivo con 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 dell'app

A una registrazione dell'app viene spesso assegnato un segreto . Il segreto viene usato come chiave per l'autenticazione e ha una data di scadenza. Pertanto, è necessario pianificare come ruotare regolarmente la chiave e come comunicare la nuova chiave 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'opzione valida per l'analisi.

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 le credenziali e le 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 Secret Management per PowerShell pubblicato da Microsoft. Può archiviare i valori usando un insieme di credenziali locale. Può anche essere integrato con un insieme di credenziali delle chiavi di Azure remoto, 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 Autenticazione di Azure AD 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 PowerShell Connessione-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 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 è 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 semplifica 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 per 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: si basano 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 la lettura di modelli semantici 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 disporre dell'autorizzazione per accedere all'area di lavoro o all'elemento.
    • Autenticazione dell'entità servizio: l'entità servizio deve avere l'autorizzazione per accedere all'area di lavoro o all'elemento.
  • API 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 amministrazione.
    • Autenticazione dell'entità servizio: l'entità servizio deve avere l'autorizzazione per eseguire le API di amministrazione (senza basarsi sulle autorizzazioni di sicurezza come un'API utente).

Suggerimento

Tutte le API di amministrazione appartengono al gruppo di operazioni Amministrazione. Qualsiasi API con il suffisso As Amministrazione è 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
Ottenere il set di dati User Area di lavoro personale Uno
Ottenere set di dati User Area di lavoro personale Tutte le date
Ottenere un set di dati nel gruppo User Un'area di lavoro Uno, purché l'utente connesso abbia l'autorizzazione per leggere il modello semantico
Ottenere set di dati in un gruppo User Un'area di lavoro Tutto, purché l'utente connesso disponga dell'autorizzazione per leggere ogni modello semantico
Ottenere set di dati in gruppo come Amministrazione Amministratore Un'area di lavoro Tutte le date
Ottenere set di dati come Amministrazione Amministratore Intero tenant Tutte le date

Nota

Alcuni nomi api includono il termine Group 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 Impostare 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 un ambito utente o un ambito aziendale è appropriato.
  • Testare i risultati: eseguire alcune sperimentazioni. 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 LE API o i cmdlet di PowerShell

Una decisione chiave da prendere è se usare i cmdlet di PowerShell quando 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 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) gli 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é 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 professionisti con più valori (MVP).

A partire da una soluzione community può svolgere un ruolo importante nella 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 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 l'amministrazione, le capacità, le 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 è possibile eseguire PowerShell Core). Usare invece uno degli editor di codice moderni che supporta PowerShell Core. Windows PowerShell I edizione Standard (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 Connessione-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 usando il Connect-PowerBIServiceAccount cmdlet 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. È necessario almeno il modulo Profile (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 le versioni precedenti di un modulo quando si installa o si aggiorna una versione più recente. Vengono installate versioni più recenti insieme alle versioni precedenti. È consigliabile verificare la presenza di versioni installate e disinstallare periodicamente le versioni 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 le API del 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
Connessione-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 è una decisione 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 coltello svizzero perché è possibile usarlo per chiamare una qualsiasi delle API REST di Power BI. Il vantaggio dell'uso di questa tecnica è semplificare l'autenticazione e quindi chiamare qualsiasi API REST di Power BI. È consigliabile usare questa tecnica. Dopo l'autenticazione con il cmdlet Connessione-PowerBIServiceAccount, usare il cmdlet Invoke-PowerBIRestMethod per recuperare i dati dall'API preferita, ad esempio Get Pipeline Users As Amministrazione.
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 da più aspetti. Dopo l'autenticazione con il cmdlet Connessione-PowerBIServiceAccount, usare un cmdlet (ad esempio 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 di richiamo. 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, Get Pipeline Users As Amministrazione) 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, XMLA e TMSL . Tuttavia, questi casi d'uso non rientrano nell'ambito di questo articolo. Per altre informazioni sull'esecuzione di query su DMV (Dynamic Management Views), 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 -Scope parametro 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 -Scope parametro su Individual (o omettere il parametro) 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 per 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 -Scope parametro per recuperare un elenco semantico specifico dell'utente o a livello di tenant. La scelta 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 dei cmdlet API usata dal cmdlet Tipo di API Scope Elementi recuperati
-DatasetID {DatasetID}
-Scope Individual		 Ottenere il set di dati User Area di lavoro personale Un modello semantico
-Scope Individual Ottenere set di dati User Area di lavoro personale Tutti i modelli semantici
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Ottenere un set di dati nel gruppo User Un'area di lavoro Un modello semantico, purché l'utente connesso disponga dell'autorizzazione per leggere il modello semantico
-GroupID {WorkspaceID} Ottenere set di dati in un gruppo User Un'area di lavoro Tutti i modelli semantici, purché l'utente connesso disponga dell'autorizzazione per accedere all'area di lavoro e leggere il modello semantico
-GroupID {WorkspaceID}
-Scope Organization		 Ottenere set di dati in gruppo come Amministrazione Amministratore Un'area di lavoro Tutti i modelli semantici
-Scope Organization Ottenere set di dati come Amministrazione Amministratore Intero tenant Tutti i modelli semantici
Considerazioni sull'uso dei cmdlet di PowerShell

I cmdlet di 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 Connect-PowerBIServiceAccount cmdlet .
  • 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 Recupera eventi attività, 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.
  • Impaginazione 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 viene ricevuto alcun token di continuazione. Per un esempio di uso di un token di continuazione, vedere API REST 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 vengono formattati leggermente più bene rispetto ai 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ù bella potrebbe essere utile.
Considerazioni sull'uso diretto delle API REST

A volte esistono vantaggi per chiamare direttamente le API REST di Power BI.

  • Molte altre API disponibili: 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 dell'API Get Dataset, potrebbe essere necessario del tempo prima che diventi disponibile nei risultati del cmdlet Get-PowerBIDataset.
  • Minore dipendenza da linguaggio/strumento: 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 è 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 tenere in considerazione.

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 per modificare.

Elenco di controllo : quando si sceglie se accedere direttamente alle API REST 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 è necessaria la comunicazione interna o la formazione.
  • Eseguire l'aggiornamento a PowerShell Core: ricerca 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) a usare i 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 i progetti della community di PowerShell sono consentiti, prendere in considerazione chi sarà responsabile del loro supporto una volta usati internamente.
  • Completare un piccolo modello di verifica (POC): esperimento con un modello di verifica tecnico. Verificare gli strumenti client preferiti e il metodo di accesso ai dati.
  • Determinare come supportare gli utenti avanzati: valutare 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, illustrati nella sezione successiva. Le decisioni relative all'archiviazione dei dati sono correlate alle preferenze per la gestione dell'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 corso del 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 quando ci vuole tempo, che potrebbe essere di 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 di dati non elaborato 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à: i diversi membri del team( ad esempio data engineer o amministratori globali) potrebbero essere responsabili della creazione dei processi per accedere, estrarre e archiviare i dati di controllo non elaborati. Semplificando il processo di estrazione dei dati, è più semplice collaborare tra più team.

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

  • Data lake o archiviazione di oggetti: un servizio cloud come 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 i 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à: > ActivityLog > non elaborato AAAA > MM. Le cartelle vengono partizionate per anno e mese. Un file archiviato nella cartella month usa il formato seguente: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. AAAAMMGG rappresenta i dati effettivi e YYYYMMDDTTTT rappresenta il timestamp di estrazione. Includendo il timestamp di estrazione, è possibile determinare quale file è l'ultimo (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 consente di scrivere i dati non elaborati nell'archiviazione non modificabile. L'archiviazione non modificabile garantisce che una volta scritti i dati, non è 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, in genere per i data engineer e gli amministratori di sistema. I revisori interni potrebbero anche 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 che consentono di scegliere l'archiviazione dati non elaborata.

  • 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 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 di 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:

  • Rivolgersi all'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: determinare se sono presenti requisiti legali o normativi per la posizione in 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: durante la progettazione della posizione 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 ed è progettato per essere intuitivo. È necessario prendere alcune decisioni su come e dove verranno creati i dati curati. La tecnologia che si sceglie di archiviare i dati curati potrebbe essere una delle tecnologie 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, quindi si usa un modello di dati di Power BI per analizzare l'utilizzo di Power BI nell'organizzazione. Si applicano le linee guida fondamentali per il modello di dati: è consigliabile adottare una progettazione dello schema star, ottimizzata per prestazioni e usabilità.

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

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 che servono la creazione di report (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 di 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 a nessuno dei 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 essere in grado di analizzarlo dal momento che è 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 (descritto in precedenza in questo articolo).

Per altre informazioni sulle tabelle delle dimensioni e sulle tabelle dei fatti che è possibile includere nello schema star, 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 modo in cui eseguire il lavoro di trasformazione a monte e dove si inserisce il piano per l'intera architettura.
  • Decidere quale strumento usare per trasformare i dati in uno schema star: verificare 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 star. 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 curato, considerare chi dovrà accedere ai dati e come verrà assegnata la sicurezza.

Decisioni relative alle origini 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 delle attività utente

I dati delle attività utente di Power BI, a volte 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 delle 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, la storia preziosa sarà disponibile per l'analisi.

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

Tecnica Descrizione Giorni predefiniti della cronologia disponibili Buona scelta per i processi di controllo manuale Buona scelta per i processi di controllo automatizzati Buona scelta per configurare gli avvisi Buona scelta per iniziare rapidamente
Manuale (interfaccia utente) Portale di conformità di Microsoft Purview 90 Portale di conformità di Microsoft Purview è una buona scelta per i processi di controllo manuali. Portale di conformità di Microsoft Purview è una buona scelta per iniziare rapidamente.
Manuale (interfaccia utente) Defender per app cloud 30 Defender per il cloud App è una buona scelta per i processi di controllo manuali. Defender per il cloud App è una buona scelta 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 ottimale 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 attività di gestione di Office 365 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 buona scelta per i processi di controllo automatizzati. Microsoft Sentinel (Monitoraggio di Azure) è una buona scelta per configurare gli avvisi.

Nella parte restante di questa sezione vengono presentate ognuna delle tecniche presentate 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) è un luogo pratico 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 prima di quel giorno, in modo che possa contattare rapidamente la persona per discutere la situazione.

Gli ultimi 90 giorni di cronologia sono disponibili con Audit (Standard).The most most recent 90 days of history are available with Audit (Standard). Con Audit (Premium) la conservazione a lungo termine consente di conservare (facoltativamente) i log di controllo più a lungo. Poiché la conservazione a lungo termine si applica solo agli utenti con licenza E5, 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. Le autorizzazioni di Exchange Online con privilegi elevati sono necessarie anche per accedere ai log di controllo.

Suggerimento

Per impostazione predefinita, gli amministratori di Power BI non hanno l'autorizzazione per accedere alla ricerca unificata nel log di controllo nella 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, tali 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 nella Portale di conformità di Microsoft Purview è utile per i processi di controllo manuali e le indagini occasionali sulle attività degli utenti.

Defender per app cloud

Il portale in Defender per il cloud App è 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 per il cloud App 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.

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

Esistono requisiti di licenza per accedere alle app Defender per il cloud. Sono necessarie anche autorizzazioni separate.

Suggerimento

Per impostazione predefinita, gli amministratori di Power BI non hanno l'autorizzazione per accedere alle app Defender per il cloud. Esiste un ruolo di Power BI nelle app di Defender per il cloud. 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 app di Defender per il cloud è 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 sull'opzione da 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 Power BI, gli amministratori di Power Platform e gli amministratori globali. È 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 attività di gestione di Office 365

È 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 archivii 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 Search-UnifiedAuditLog cmdlet non viene ridimensionato correttamente e richiede l'implementazione di una strategia di ciclo per superare il limite 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 invece il cmdlet Get-PowerBIActivityEvent .

In generale, iniziare a usare l'API Attività di gestione di Office 365 è più complessa 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 pesantemente questa API, Microsoft implementa la limitazione per garantire che l'uso del servizio non influisca negativamente sugli altri utenti (noto come problema del vicino rumoroso). Pertanto, il recupero di grandi volumi di cronologia può essere una sfida nelle organizzazioni più grandi. Per altre informazioni, vedere questo articolo sulla 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 Attività di gestione di Office 365.

Suggerimento

Per impostazione predefinita, gli amministratori di Power BI non hanno l'autorizzazione per accedere all'API Attività di gestione di Office 365. Poiché contiene dati per molti servizi di Microsoft 365, l'accesso richiede l'amministratore con privilegi elevati o i ruoli 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 alla 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 ad 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 degli 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 eseguire Linguaggio di query Kusto (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, sono disponibili molte analogie con KQL.

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

  • L'app modello Di modelli semantici di Log Analytics predefinita per Power BI.
  • Connettore Power BI Desktop per Azure Esplora dati (Kusto).
  • Esperienza di query basata sul Web in Azure Esplora dati.
  • 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 Log Analytics di Azure. 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, il livello di dettaglio acquisito soddisfa le proprie esigenze e 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 che consentono di 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 occasionali, soprattutto quando è necessario analizzare un'attività specifica. Per supportare l'analisi cronologica dei dati cronologici, sarà necessario anche un processo di controllo automatizzato che estrae 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 che sono 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 quando si estraggono sempre un'intera 24 ore alla volta, evitando così risultati parziali del giorno.
    • 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 arrivare nel log di controllo unificato.
  • Sono necessari più dati di Power BI? Prendere in considerazione il modo più efficiente per accedere a ciò che serve.
    • Quando sono necessari solo i dati delle attività utente di Power BI, usare il log attività di Power BI.
    • Quando sono necessari log di controllo da più servizi, usare l'API Office 365 Management Activity per accedere al log di controllo unificato.
  • 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 è necessario accedere solo ai record di controllo di Power BI o ai dati di controllo per più servizi.
  • Consultare l'IT: scoprire se l'IT estrae attualmente i log di controllo e se è possibile ottenere l'accesso ai dati non elaborati in modo che non sia necessario creare una nuova soluzione.
  • Scegliere 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 una piccola verifica tecnica (POC). Usarlo per convalidare le decisioni relative alla modalità di compilazione della soluzione finale.
  • Tenere traccia delle esigenze di dati aggiuntivi: è 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 contenuto (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 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 a 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 del giorno 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 consente di comprendere quanto contenuto si ha e dove si trova. Consente anche di trovare contenuto inutilizzato o sottoutilizzato (perché non ci saranno eventi per esso 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 (Ottieni artefatti inutilizzati) come AMMINISTRAZIONE 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 Più adatto a Buona scelta per i processi di controllo manuale Buona scelta per i processi di controllo automatizzati
Programmatica L'API Get Groups as Admin o il Get-PowerBIWorkspace cmdlet di PowerShell può 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 Get Groups as Amministrazione API or the Get-PowerBIWorkspace PowerShell cmdlet is a good choice for manual auditing processes.The Get Groups as Amministrazione API or the Get-PowerBIWorkspace PowerShell cmdlet is a good choice for manual auditing processes. Get Groups as Amministrazione API or the Get-PowerBIWorkspace PowerShell cmdlet is a good choice for automated auditing processes.The Get-PowerBIWorkspace PowerShell cmdlet is a good choice for automated auditing processes.
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 buona scelta per i processi di controllo automatizzati.

Nella parte restante di questa sezione vengono presentate ognuna delle tecniche presentate 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 Get Groups come API Amministrazione (usando lo strumento preferito). 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 gruppo di termini 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 Get Groups as Admin REST include il parametro utile $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 users tipo di dati al $expand parametro per includere gli utenti assegnati a un ruolo dell'area di lavoro.

È anche possibile usare il cmdlet PowerShell Get-PowerBIWorkspace . Proviene dal modulo Aree di lavoro di gestione di Power BI. Quando si imposta il -Scope parametro organization, funziona come l'API Get Groups as Admin . Il cmdlet accetta anche il -Include parametro (equivalente al $expand parametro 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 -Scope parametro , vedere Scegliere un'API utente o un'API di amministrazione in precedenza in questo articolo.

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

L'API Get Groups as Admin REST o il Get-PowerBIWorkspace cmdlet di PowerShell è più adatta ai processi di controllo manuali e alle 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, in modo da richiedere molto tempo per l'esecuzione. È quindi probabile che le organizzazioni di grandi dimensioni si verifichino limitazioni sul numero di richieste consentite all'ora (nota come limitazione delle richieste, che viene eseguita 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 dello 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 e più adatto per estrarre l'inventario tenant.

Nota

Si noti che alcune persone usano le API dello scanner di termini o la frase che analizza il tenant. Spesso usano questi termini per indicare la compilazione di un inventario tenant, distinguendolo 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 Get Groups as Admin REST o il Get-PowerBIWorkspace cmdlet (descritto in precedenza).

  • Estrazione incrementale dei dati: le API dello scanner estraggono solo i dati modificati dall'ultima esecuzione. Viceversa, l'API Get Groups as Admin REST e il Get-PowerBIWorkspace cmdlet 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), fornendo l'autorizzazione viene concessa dalle due impostazioni del tenant per i metadati dettagliati. Viceversa, il livello di dettaglio più basso disponibile con l'API Get Groups as Admin REST e il Get-PowerBIWorkspace cmdlet è per 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. Accesso: 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 amministrazione. Per altre informazioni, vedere Determinare il metodo di autenticazione in precedenza in questo articolo.
  2. Ottenere gli ID dell'area di lavoro: inviare una richiesta per recuperare un elenco di ID area di lavoro. La prima volta che viene eseguita, non si avrà una data modificata, quindi restituirà 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 (anziché di un'API GET , che è 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 dell'analisi. Potrebbe essere necessario chiamare questa API più volte. Quando lo stato restituito è Succeeded, 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 nella posizione di archiviazione dei dati preferita. 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 in modo da 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 di estrazione dell'inventario tenant: verificare la frequenza con cui sarà necessario un nuovo inventario tenant, ad esempio ogni settimana.
  • Decidere come estrarre l'inventario tenant: verificare 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 una piccola verifica tecnica (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: identità presente 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 è il 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 che sono account di servizio usati per le attività automatizzate o per le attività amministrative.
  • Entità servizio: tipo di identità diverso, 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 in precedenza in questo articolo.
  • Gruppo: raccolta di utenti e entità servizio. Esistono diversi tipi di gruppi che è possibile usare per semplificare la gestione delle autorizzazioni. Per altre informazioni, vedere Strategia per l'uso dei gruppi.

Nota

Quando questo articolo fa riferimento a utenti e gruppi, questo termine include anche le entità servizio. Questo termine più breve 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 di posta elettronica dell'utente che ha eseguito un'attività o chi è 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à di un singolo utente o di avere accesso.
  • 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 stanno 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 e gli amministratori globali.

Per informazioni 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. Sarà necessario eseguire una ricerca transitiva per rendere flat tutti i membri annidati e i gruppi annidati. È possibile eseguire una ricerca transitiva per i 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 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 i 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 disabilita il proprio 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 per una licenza di valutazione. È possibile combinare tale evento con i dati delle licenze utente (originati dall'ID Microsoft Entra) 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 Buona scelta per i processi di controllo manuale Buona scelta per i processi di controllo automatizzati
Manuale Graph Explorer Graph Explorer è una buona scelta per i processi di controllo manuali.
Programmatica API e SDK di 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 buona scelta per i processi di controllo automatizzati.

Nella parte restante di questa sezione vengono presentate ognuna delle tecniche presentate nella tabella. Altre tecniche, deprecate e non devono essere usate 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 sulle 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 di Microsoft Graph

Usare le API Di Microsoft Graph per recuperare i dati di utenti e gruppi. È anche possibile usarlo 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 sopra le 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 in precedenza in questo articolo.

Gli SDK di Microsoft Graph supportano diversi linguaggi e sono disponibili anche i moduli di 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 numerosi vantaggi e funzionalità. Per altre informazioni, vedere Eseguire l'aggiornamento da Azure AD PowerShell a Microsoft Graph PowerShell.

È possibile installare i moduli di PowerShell di Microsoft Graph da PowerShell Gallery. Poiché Microsoft Graph funziona con molti servizi di Microsoft 365, sono disponibili molti moduli di PowerShell installati.

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, deprecati. Non è consigliabile creare nuove soluzioni con moduli deprecati.

È possibile usare il cmdlet Invoke-AzRestMethod quando non esiste 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/o eseguire la migrazione delle soluzioni esistenti) usando una delle API o dei moduli seguenti.

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

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 sull'annuncio di 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 ai dati di utenti e gruppi, le decisioni chiave e le azioni includono:

  • Confermare i requisiti: chiarire le esigenze di compilazione dei dati correlati a utenti, gruppi e licenze.
  • Assegnare priorità ai requisiti: verificare quali sono le priorità principali in modo da sapere cosa dedicare tempo per la prima volta.
  • Decidere la frequenza per l'estrazione dei dati: determinare la frequenza con cui sarà necessario un nuovo snapshot dei dati degli utenti e dei gruppi, ad esempio ogni settimana o ogni mese.
  • Decidere come estrarre i dati con Microsoft Graph: determinare quale metodo si userà per recuperare i dati.
  • Completare un modello di verifica: pianificare il completamento di una piccola verifica tecnica (POC) per estrarre i 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 Power BI, le decisioni chiave e le azioni includono:

  • Ottenere i requisiti: compilare i requisiti analitici man mano che si verificano. Tienine traccia nel backlog.
  • Definizione delle priorità dei requisiti: 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 di 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, potrebbe comportare l'invio di una richiesta all'IT.

Come descritto in precedenza, è consigliabile usare una tecnologia che consente di scrivere i dati non elaborati nell'archiviazione non modificabile. Dopo aver scritto i dati, non è possibile modificarli o eliminarli. È quindi possibile avere fiducia nei 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 rigenerarli.

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 le autorizzazioni da impostare 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 il software e configurare i servizi

A questo punto, sono state prese decisioni su quale tecnologia usare per accedere 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, è necessario eseguirne il provisioning e configurarli.

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

  • Configurare 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 macchine virtuali presenti 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 eseguire l'autenticazione. È consigliabile registrare un'applicazione Microsoft Entra (entità servizio). Comunemente definita registrazione dell'app, deve essere usata per le operazioni automatiche 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 di amministratore di sola lettura.

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

  • Controllare 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 quello esistente o se crearne uno nuovo.
  • 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-Amministrazione APIs-EntraApp, che ne descrive chiaramente lo scopo.
  • Creare un segreto per la registrazione dell'app: dopo l'esistenza della registrazione dell'app, creare un segreto per esso. 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 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 le autorizzazioni per la registrazione dell'app (otterrà l'accesso ai dati di controllo a livello di tenant di Power BI tramite Power BI Consenti alle entità servizio di usare l'impostazione del tenant di amministrazione di Power BI di sola lettura).
  • 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 Migliorare le risposte dell'API di amministrazione con l'impostazione del tenant Migliorare le risposte dell'API di amministrazione con DAX e 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 le impostazioni del 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 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 amministrazione. Questa impostazione consente anche a Microsoft Purview di analizzare l'intero tenant di Power BI in modo che possa popolare il catalogo dati.

Nota

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

L'impostazione Migliora le risposte dell'API di amministrazione con i metadati dettagliati consente 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 che possa archiviarla nel catalogo dati.

L'impostazione del tenant Migliorare le risposte dell'API amministratore con le espressioni DAX e mashup 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 di amministrazione. Il 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 Consenti alle entità servizio di usare API Power BI s tenant consente di impostare le entità servizio a cui le entità servizio hanno accesso per eseguire le API REST (escluse le API amministratore, 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 delle 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 si trova nel gruppo corretto: verificare che il gruppo di 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 Consenti alle entità servizio di usare l'impostazione del tenant delle API di amministrazione di Power BI di sola lettura, che consente di usare le API amministratore 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 all'impostazione Migliorare le risposte dell'API di amministrazione con l'impostazione del tenant Migliorare le risposte dell'API di amministrazione con DAX e espressioni mashup.
  • 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 Consenti alle entità servizio di usare API Power BI s tenant, 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 e il processo decisionale e sono stati soddisfatti i prerequisiti e completato la 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 in cui 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, potrebbe essere stato completato 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 autodescrittura 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 di 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à, verranno visualizzate nuove attività che non esistono oggi. 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 in precedenza in questo articolo.
  • Quanto 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 storia. 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 di 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. Al successivo esecuzione del processo, può recuperare questi timestamp. È particolarmente importante archiviare i 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 Archiviazione Gen2) o l'archiviazione di 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 chiave e le azioni 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 dati non elaborata: 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 archiviate e comunicate 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 sulla crescita di una soluzione di controllo e monitoraggio nel tempo, 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 star. Uno schema star 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 dati curato, 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 star. 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 analitici. 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 star. Quando i dati di origine sono il livello dati curato, lo schema star del modello di dati di Power BI deve rispecchiare lo schema star del livello dati curato.

Suggerimento

Per una panoramica della progettazione dello schema star, vedere Informazioni sullo schema star e sull'importanza di 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. In 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 per giorno, settimana, mese, trimestre, anno e 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: 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 archivia solo lo stato corrente dell'area di lavoro o se archivia 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: elenco di tipi di elementi di Power BI (modelli semantici, report e altri).
  • Capacità: elenco delle capacità Premium nel tenant.
  • Gateway: 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: snapshot temporizzato di tutti gli elementi pubblicati nel tenant. Per altre informazioni, vedere Inventario tenant in precedenza 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: snapshot temporizzato delle assegnazioni di ruolo dell'area di lavoro.
  • Licenze utente: snapshot temporizzato delle licenze utente. Anche se si potrebbe essere tentati di archiviare la licenza utente nella tabella delle dimensioni Users , questo approccio non supporterà l'analisi delle modifiche delle licenze e delle tendenze nel tempo.
  • Appartenenze ai gruppi di utenti: 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 Centro di eccellenza a identificare potenziali nuovi promotori.

Le tabelle dei fatti non devono includere colonne filtrate dai creatori 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 (noto come drill-through). Questo ultimo punto è importante per produrre un modello di dati utile e intuitivo che è estendibile quando si aggiungono nuove tabelle dei fatti (soggetti).

Ad esempio, la tabella delle dimensioni Users sarà correlata a ogni tabella dei fatti. Deve essere correlato alla tabella dei fatti Attività utente (che ha eseguito l'attività), alla tabella dei fatti dell'inventario tenant (che ha creato l'elemento pubblicato) e a tutte le altre tabelle dei fatti. Quando un report filtra in base a un utente nella tabella delle dimensioni Users , gli oggetti visivi di 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 e una sola volta nel modello. Ad esempio, l'indirizzo di posta elettronica dell'utente deve essere visibile solo nella tabella delle dimensioni Users . 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 gestito.

Valutare la possibilità di configurare la sicurezza a livello di riga in modo che altri utenti, oltre al Centro di eccellenza, ai revisori e agli amministratori, possano analizzare e creare report sui dati di controllo. Ad esempio, è possibile usare regole di sicurezza a livello di riga per consentire ai creatori 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 star. Convalidare il funzionamento delle relazioni come previsto. Durante lo sviluppo del modello, creare misure in modo iterativo e aggiungere dati aggiuntivi 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 restituisca 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 gli utenti in base al livello di utilizzo o di classificare il contenuto in base al livello di utilizzo.

Classificazione dell'utilizzo degli utenti

Considerare le classificazioni seguenti per l'utilizzo degli utenti.

  • 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 senza attività negli ultimi un 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 all'orario di ufficio o partecipare alla formazione. I creatori di contenuti più attivi potrebbero essere candidati per partecipare alla rete dei promotori.

Classificazione dell'utilizzo del 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 senza attività negli ultimi un mese.
  • Contenuto inutilizzato: nessuna attività registrata negli ultimi nove mesi.
Classificazione dei tipi utente

Considerare le classificazioni seguenti per il tipo di utente.

  • Creatore di contenuti: attività registrata negli ultimi sei mesi che hanno creato, pubblicato o modificato contenuto.
  • Visualizzatore contenuto: attività registrata negli ultimi sei mesi che hanno visualizzato il contenuto, ma senza alcuna attività di creazione del contenuto.

È necessario decidere se le classificazioni di utilizzo per gli utenti o il contenuto devono essere basate solo sulla modalità di recente di un'attività. È anche consigliabile prendere in considerazione il factoring nell'utilizzo medio o di tendenza nel 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 del report) ogni volta che modifica il report. Sarebbe utile che l'autore del report abbia più training.
  • 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, usare il modulo di apprendimento Usare funzioni di business intelligence per le gerarchie temporali DAX nei modelli di Power BI Desktop.

Elenco di controllo : durante la creazione della classificazione dei dati di utilizzo, le decisioni chiave e le azioni includono:

  • Ottenere il consenso sulle definizioni di classificazione: discutere le 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 consentire agli 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 che è possibile usare con i report includono:

  • Sponsor esecutivo
  • Centro di eccellenza
  • Amministratori di Power BI
  • Amministratori dell'area di lavoro
  • Amministratori della capacità Premium
  • Amministratori gateway
  • Sviluppatori e creatori di contenuti di Power BI
  • Revisori

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

  • Visualizzazioni principali del contenuto: lo sponsor esecutivo e i team di leadership potrebbero essere interessati principalmente 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.
  • Attività utente principali: il Centro di eccellenza 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 di Power BI, gli amministratori dell'area di lavoro e i revisori saranno interessati a comprendere quali contenuti esistono, dove, derivazione e impostazioni di sicurezza.

Questo elenco non è all-inclusive. È destinato a fornire idee su come creare report analitici destinati a esigenze specifiche. Per altre considerazioni, vedere Informazioni sulle esigenze dei dati più indietro in questo articolo e Panoramica sul controllo e sul 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 è tentata di presentare molti dati, includere solo informazioni su cui si è pronti ad agire. Assicurarsi che ogni pagina del report sia chiara sullo scopo, sull'azione da intraprendere e su chi.

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

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

  • Esaminare i requisiti: classificare in ordine di priorità la 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 di base. Estenderli e migliorarli gradualmente nel tempo.
  • Distribuire report in un'app: è consigliabile creare un'app che includa tutti i report di controllo e monitoraggio.
  • Verificare chi ha accesso ai report: assicurarsi che i report (o l'app) siano resi disponibili per il set corretto di utenti.
  • Creare un ciclo di feedback: 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 trascurato. Per questo motivo, è consigliabile assegnare a 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 spesso usato (giornaliero o settimanale): 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 il motivo per cui un modello semantico viene aggiornato regolarmente senza l'uso recente del modello semantico 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 a creator, che è possibile identificare quando pubblicano il contenuto per la prima volta. È un'ottima opportunità inviare loro un messaggio di posta elettronica standard che fornisce indicazioni e collegamenti a risorse utili.
  • Engagement con i creatori di contenuti più frequenti: invita i tuoi creatori più attivi a partecipare alla tua rete di campioni o a partecipare alla tua community di pratica.
  • Gestione delle 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 del termine 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 creatore 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 esegue molte condivisioni dall'area di lavoro personale. Insegnare loro informazioni sulle aree di lavoro standard.
  • Visualizzazioni significative dei report da un'area di lavoro personale: contattare un utente proprietario di contenuto con un numero elevato di visualizzazioni report. Insegnare loro come 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 interna di Power BI e i problemi inviati all'help desk.

Sicurezza

Ecco alcune situazioni di sicurezza che è possibile monitorare attivamente.

Per altre informazioni, vedere gli articoli Sulla pianificazione della sicurezza.

Governance e mitigazione dei rischi

Ecco alcune situazioni che potresti incontrare. È consigliabile cercare in modo esplicito questi tipi di situazioni nei report di controllo, quindi si è pronti ad agire rapidamente.

  • Numero elevato di visualizzazioni per i report (e i modelli semantici sottostanti) non 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 dei gateway personali.

Le azioni specifiche da intraprendere in ogni situazione dipendono dai criteri di governance. Per altre informazioni, vedere Governance nella roadmap per l'adozione dell'infrastruttura.

Elenco di controllo : quando si pianificano azioni potenziali in base ai dati di controllo, le decisioni chiave e le azioni 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 l'automazione: quando possibile, automatizzare le azioni note ripetibili.
  • Usa un sistema di rilevamento: usa un sistema per tenere traccia di una situazione osservata, tra cui contatti, azione pianificata successiva, responsabile, risoluzione e 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.

È stato operativo un processo di controllo a livello di produzione. 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: è in atto un sistema di pianificazione affidabile.
  • Gestione delle modifiche: l'uso delle procedure di gestione delle modifiche e di più ambienti viene usato 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 addestrati e comprendono le aspettative operative. I membri di backup sono stati identificati e il training incrociato avviene quando appropriato.
  • Avviso: quando si verifica un problema, gli avvisi avvisano automaticamente il team di supporto. Preferibilmente, l'invio di avvisi include sia log che messaggi di posta elettronica (anziché solo messaggi di posta elettronica). 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 registrare l'ora di inizio, l'ora di fine e l'identità dell'utente o dell'app che ha eseguito il processo.
  • Gestione degli errori: gli script e i processi gestiscono correttamente e registrano 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: vengono usate tecniche di codifica valide. Ad esempio, i cicli vengono evitati intenzionalmente tranne quando necessario. Vengono usati standard di codifica coerenti, commenti, formattazione e sintassi 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 stringa di connessione o indirizzi di posta elettronica per le notifiche) vengono modularizzati in modo che altri script e processi possano riutilizzarli.

Suggerimento

Non è necessario eseguire tutte le operazioni elencate in precedenza in una sola volta. 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 uno-off che potrebbero non essere di qualità di produzione.

Elenco di controllo : quando si pianifica 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à per migliorare e stabilizzare le soluzioni di controllo esistenti automatizzate.
  • Stabilire gli standard a livello di produzione: decidere quali standard si vogliono avere per i processi di controllo automatizzati. Fattore di miglioramenti che è possibile aggiungere realisticamente nel tempo.
  • Creare un piano di miglioramento: pianificare il miglioramento della qualità e della stabilità delle soluzioni di controllo di produzione.
  • Determinare se è 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 è 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.
  • Diagramma dell'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 delle modifiche.
  • Istruzioni per la distribuzione, l'installazione 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 verificarsi un help desk o un team di supporto. 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 dell'autore di contenuti è destinata agli autori di contenuti self-service che creano report e modelli di dati che generano i dati di controllo curati. Include informazioni sul modello di dati, incluse le definizioni di dati comuni.

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

  • Verificare chi deve supportare la soluzione: determinare chi supporterà le soluzioni di controllo considerate a livello di produzione (o che hanno dipendenze del report downstream).
  • Assicurarsi che il team di supporto sia idoneo: 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 training incrociato 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 chiunque deve essere su chiamata per risolvere rapidamente i problemi relativi alla soluzione di controllo.
  • Creare la documentazione tecnica: creare la documentazione relativa all'architettura tecnica e alle decisioni di progettazione.
  • Creare la documentazione del 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 in corso

È 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 chiave e le azioni includono:

  • Assegnare un proprietario tecnico: assicurarsi che sia presente 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 può essere coinvolto in caso di problema urgente che il supporto non possa risolvere.
  • Mantenere un sistema di rilevamento: assicurarsi di avere un modo per acquisire nuove richieste e un modo per classificare le priorità immediate, nonché priorità a breve termine, a medio termine e a lungo termine (backlog).

Contenuto correlato

Nell'articolo successivo di questa serie vengono fornite informazioni sul monitoraggio a livello di tenant.