White paper di sicurezza Power BI

Riepilogo: Power BI è un servizio software online (SaaS o Software as a Service) offerto da Microsoft che consente di creare facilmente e rapidamente dashboard di Business Intelligence self-service, report, modelli semantici e visualizzazioni. Con Power BI è possibile connettersi a numerose origini dati diverse, combinare e definire le proprietà della forma dei dati provenienti dalle connessioni, quindi creare report e dashboard che possono essere condivisi con altri utenti.

Autori: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Revisori tecnici: Cristian Petculescu, Amir Netz, Sergei Gundorov

Si applica a: Power BI SaaS, Power BI Desktop, Power BI Premium, Analisi incorporata di Power BI, Power BI per dispositivi mobili.

Nota

Per salvare o stampare questo white paper, selezionare Stampa nel browser, quindi selezionare Salva come PDF.

Introduzione

Power BI è un servizio software online (SaaS, Software as a Service) offerto da Microsoft che consente di creare in modo semplice e rapido dashboard, report, modelli semantici e visualizzazioni di business intelligence in modalità self-service. Con Power BI è possibile connettersi a numerose origini dati diverse, combinare e definire le proprietà della forma dei dati provenienti dalle connessioni, quindi creare report e dashboard che possono essere condivisi con altri utenti.

Il mondo sta cambiando rapidamente; le organizzazioni stanno attraversando una trasformazione digitale accelerata e stiamo riscontrando un aumento massiccio del lavoro remoto, una maggiore domanda dei clienti per i servizi online e l'aumento dell'uso di tecnologie avanzate nelle operazioni e nel processo decisionale aziendale. E tutto questo è basato sul cloud.

Man mano che la transizione al cloud si è ingrandita esponenzialmente e con la nuova superficie esposta conseguente, più aziende si chiedono Quanto sono sicuri i dati nel cloud? e Quale protezione end-to-end è disponibile per impedire la perdita dei dati sensibili? E per le piattaforme BI che spesso gestiscono alcune delle informazioni più strategiche dell'azienda, queste domande sono doppiamente importanti.

Le basi storiche del modello di sicurezza BI, ovvero la sicurezza a livello di oggetto e a livello di riga, pur ancora importanti, non sono più sufficienti per fornire il tipo di sicurezza necessario nell'era del cloud. Le organizzazioni devono invece cercare una soluzione di sicurezza avanzata a più livelli nativa del cloud per i dati di business intelligence.

Power BI è stato creato per offrire protezione completa e aritmetica, leader del settore per i dati. Il prodotto ha guadagnato le classificazioni di sicurezza più elevate disponibili nel settore, e oggi molte agenzie nazionali di sicurezza, istituzioni finanziarie e provider di assistenza sanitaria gli affidano le loro informazioni più sensibili.

Tutto inizia con le fondamenta. Dopo un periodo non facile all'inizio del nuovo millennio, Microsoft ha effettuato enormi investimenti per risolvere le proprie vulnerabilità di sicurezza e negli ultimi decenni ha creato uno stack di sicurezza robusto che arriva fino al kernel BIOS su chip del computer e si estende fino alle esperienze degli utenti finali. Questi investimenti approfonditi continuano in modo costante e, oggi, oltre 3.500 tecnici Microsoft sono impegnati a creare e migliorare lo stack di sicurezza di Microsoft e affrontare in modo proattivo il panorama delle minacce in continua evoluzione. Con miliardi di computer, trilioni di account di accesso e innumerevoli zettabyte di informazioni affidati alla protezione di Microsoft, l'azienda ora possiede lo stack di sicurezza più avanzato nel settore tecnologico ed è ampiamente considerata leader globale nella lotta contro gli attori malintenzionati.

Power BI si basa su queste solide fondamenta. Usa lo stesso stack di sicurezza che ha reso Azure una soluzione ideale per servire e proteggere i dati più sensibili del mondo e si integra con gli strumenti di protezione e conformità delle informazioni più avanzati di Microsoft 365. Oltre a ciò, offre sicurezza tramite misure a più livelli, con conseguente protezione end-to-end progettata per affrontare le sfide uniche dell'era del cloud.

Per fornire una soluzione end-to-end per la protezione degli asset sensibili, il team di prodotto ha bisogno di affrontare problematiche complesse dei clienti su più fronti simultanei:

• Come possiamo controllare chi può connettersi, da dove si connette e come si connette? Come è possibile controllare le connessioni?
• Come vengono archiviati i dati? Come viene crittografato? Quali controlli sono presenti sui dati?
• Come si controllano e si proteggono i dati sensibili? Come si garantisce che questi dati non vadano persi all'esterno dell'organizzazione?
• Come si controlla chi esegue le operazioni? Come si reagisce rapidamente se si verifica un'attività sospetta nel servizio?

Questo articolo fornisce una risposta completa a tutte queste domande. Inizia con una panoramica dell'architettura del servizio e spiega come funzionano i flussi principali del sistema. Viene quindi illustrato come gli utenti eseguono l'autenticazione in Power BI, il modo in cui vengono stabilite le connessioni dati e il modo in cui Power BI archivia e sposta i dati attraverso il servizio. L'ultima sezione illustra le funzionalità di sicurezza che consentono, come amministratore del servizio, di proteggere gli asset più preziosi.

Il servizio Power BI è disciplinato dalle Condizioni di Microsoft Online Services e dall'Informativa sulla privacy di Microsoft. Per la posizione di elaborazione dei dati, fare riferimento alle condizioni sulla posizione di elaborazione dei dati nelle Condizioni per l'Utilizzo dei Servizi Online Microsoft e nell'Addendum sulla protezione dati. Per informazioni sulla conformità, il Centro protezione Microsoft rappresenta la risorsa principale per Power BI. Il team di Power BI si sta impegnando per offrire ai propri clienti innovazioni più recenti e produttività. Altre informazioni sulla conformità nelle offerte di conformità Microsoft.

Il servizio Power BI segue il ciclo di vita dello sviluppo della sicurezza (SDL), procedure di sicurezza rigorose che supportano i requisiti di sicurezza e conformità. SDL consente agli sviluppatori di creare software più sicuro riducendo il numero e la gravità delle vulnerabilità nel software e diminuendo al contempo i costi di sviluppo. Ulteriori informazioni in Procedure Microsoft Security Development Lifecycle.

Architettura di Power BI

Il servizio Power BI è basato su Azure, la piattaforma di cloud computing di Microsoft. Power BI è attualmente distribuito in numerosi data center nel mondo. Per i clienti sono disponibili diverse distribuzioni attive nelle aree servite dai data center e un numero equivalente di distribuzioni passive che svolgono la funzione di backup per ogni distribuzione attiva.

Cluster front-end Web (WFE)

Il cluster WFE fornisce al browser dell'utente il contenuto iniziale della pagina HTML dopo aver caricato il sito, così come i puntatori al contenuto della rete CDN usati per eseguire il rendering del sito nel browser.

Un cluster WFE è costituito da un sito Web ASP.NET in esecuzione nell'ambiente del servizio app di Azure. Quando gli utenti provano a connettersi al servizio Power BI, il servizio DNS del client può comunicare con Gestione traffico di Microsoft Azure per trovare il data center più appropriato (solitamente il più vicino) con una distribuzione di Power BI. Per altre informazioni su questo processo, vedere Metodi di routing di Gestione traffico.

Le risorse statiche, ad esempio *.js, *.css e i file di immagine vengono archiviati principalmente in una rete per la distribuzione di contenuti di Azure (CDN) e recuperati direttamente dal browser. Si noti che le distribuzioni di cluster sovrani per enti pubblici sono un'eccezione a questa regola e, per motivi di conformità, ometteranno la rete CDN e useranno invece un cluster WFE da un'area conforme per l'hosting di contenuto statico.

Cluster back-end di Power BI (BE)

Il cluster back-end è il backbone di tutte le funzionalità disponibili in Power BI. È costituito da diversi endpoint di servizio utilizzati dai client Web Front End e API, nonché da servizi di lavoro in background, database, cache e vari altri componenti.

Il back-end è disponibile nella maggior parte delle aree di Azure e viene distribuito in nuove aree non appena diventano disponibili. Una singola area di Azure ospita uno o più cluster back-end che consentono un ridimensionamento orizzontale illimitato del servizio Power BI dopo l'esaurimento dei limiti di scalabilità verticale e orizzontale di un singolo cluster.

Ogni cluster back-end ha uno stato e ospita tutti i dati di tutti i tenant assegnati al cluster. Un cluster che contiene i dati di un tenant specifico viene definito cluster home del tenant. Le informazioni del cluster home di un utente autenticato vengono fornite dal servizio globale e usate dal front-end Web per instradare le richieste al cluster home del tenant.

Ogni cluster back-end è costituito da più macchine virtuali combinate in più set di scalabilità ridimensionabili ottimizzati per l'esecuzione di attività specifiche, risorse con stato come database SQL, account di archiviazione, bus di servizio, cache e altri componenti cloud necessari.

I metadati e i dati del tenant vengono archiviati entro i limiti del cluster, ad eccezione della replica dei dati in un cluster back-end secondario in un'area di Azure abbinata nella stessa area geografica di Azure. Il cluster back-end secondario funge da cluster di failover in caso di interruzione a livello di area ed è passivo in qualsiasi altro momento.

La funzionalità back-end viene gestita da microservizi in esecuzione in computer diversi all'interno della rete virtuale del cluster che non sono accessibili dall'esterno, ad eccezione di due componenti a cui è possibile accedere dalla rete Internet pubblica:

• Servizio gateway
• Gestione API di Azure

Infrastruttura di Power BI Premium

Power BI Premium offre un servizio per i sottoscrittori che richiedono funzionalità premium di Power BI, ad esempio intelligenza artificiale avanzata, distribuzione a utenti senza licenza e così via. Quando un cliente effettua l'iscrizione per una sottoscrizione Power BI Premium, la capacità Premium viene creata tramite Azure Resource Manager.

Le capacità di Power BI Premium sono ospitate in cluster back-end indipendenti dal normale back-end di Power BI. Ciò garantisce isolamento, allocazione delle risorse, supporto, isolamento della sicurezza e scalabilità migliori rispetto all'offerta Premium.

Il diagramma seguente illustra l'architettura dell'infrastruttura Power BI Premium:

La connessione all'infrastruttura di Power BI Premium può essere eseguita in molti modi, a seconda dello scenario utente. I client Power BI Premium possono essere un browser di un utente, un back-end di Power BI normale, connessioni dirette tramite client XMLA, API ARM e così via.

L'infrastruttura di Power BI Premium in un'area di Azure è costituita da più cluster Power BI Premium (il minimo è un cluster). La maggior parte delle risorse Premium viene incapsulata all'interno di un cluster (ad esempio, calcolo) e alcune risorse di area comuni, ad esempio l'archiviazione dei metadati. L'infrastruttura Premium consente due modi per raggiungere la scalabilità orizzontale in un'area: l'aumento delle risorse all'interno di cluster e/o l'aggiunta di più cluster su richiesta in base alle esigenze (se le risorse del cluster stanno raggiungendo i limiti).

Il backbone di ogni cluster è costituito da risorse di calcolo gestite da set di scalabilità di macchine virtuali e Azure Service Fabric. I set di scalabilità di macchine virtuali e Service Fabric consentono un aumento rapido e senza problemi dei nodi di calcolo man mano che l'utilizzo aumenta e orchestra la distribuzione, la gestione e il monitoraggio dei servizi e delle applicazioni Power BI Premium.

Esistono molte risorse circostanti che garantiscono un'infrastruttura sicura e affidabile: bilanciamenti del carico, reti virtuali, gruppi di sicurezza di rete, bus di servizio, archiviazione e così via. Tutti i segreti, le chiavi e i certificati necessari per Power BI Premium vengono gestiti esclusivamente da Azure Key Vault. Tutte le autenticazioni vengono eseguite tramite l'integrazione con Microsoft Entra ID esclusivamente.

Tutte le richieste che arrivano all'infrastruttura di Power BI Premium passano prima ai nodi front-end, che sono gli unici nodi disponibili per le connessioni esterne. Le altre risorse sono nascoste dietro le reti virtuali. I nodi front-end autenticano la richiesta, la gestiscono o la inoltrano alle risorse appropriate, ad esempio i nodi back-end.

I nodi back-end offrono la maggior parte delle funzionalità e delle capacità di Power BI Premium.

Power BI per dispositivi mobili

Power BI per dispositivi mobili è una raccolta di applicazioni progettate per le tre principali piattaforme per dispositivi mobili: Android, iOS e Windows (UWP). Le considerazioni sulla sicurezza per le app Power BI per dispositivi mobili rientrano in due categorie:

• Comunicazione del dispositivo
• Applicazione e dati nel dispositivo

Per quanto riguarda la comunicazione del dispositivo, tutte le applicazioni Power BI per dispositivi mobili comunicano con il servizio Power BI e usano le stesse sequenze di autenticazione e connessione usate dai browser descritte in dettaglio in precedenza in questo white paper. Le applicazioni Power BI per dispositivi mobili per iOS e Android visualizzano una sessione del browser all'interno dell'applicazione stessa, mentre l'app per dispositivi mobili di Windows apre un broker per stabilire il canale di comunicazione con Power BI (per il processo di accesso).

La tabella seguente illustra il supporto dell'autenticazione basata su certificati per Power BI per dispositivi mobili, in base alla piattaforma per dispositivi mobili:

Supporto CBA	iOS	Android	Finestre
Power BI (accesso al servizio)	Supportata	Supportato	Non supportato
SSRS ADFS locale (connettersi al server SSRS)	Non supportato	Supportato	Non supportato
Proxy app SSRS	Supportato	Supportato	Non supportato

Le app Power BI per dispositivi mobili comunicano attivamente con il servizio Power BI. Per raccogliere statistiche sull'utilizzo delle app per dispositivi mobili e dati simili per la trasmissione a servizi di monitoraggio dell'utilizzo e dell'attività, viene usata la telemetria. Con i dati di telemetria non vengono inviati dati del cliente.

L'applicazione Power BI archivia i dati nel dispositivo per facilitare l'uso dell'app:

• I token di Microsoft Entra ID e di aggiornamento vengono archiviati in un meccanismo protetto nel dispositivo applicando misure di sicurezza standard di settore.
• I dati e le impostazioni (coppie chiave-valore per la configurazione utente) vengono memorizzati nella cache nell'archiviazione nel dispositivo e possono essere crittografati dal sistema operativo. In iOS questa operazione viene eseguita automaticamente quando l'utente imposta un passcode. In Android questa opzione può essere configurata nelle impostazioni. In Windows viene eseguita usando BitLocker.
• Per le app Android e iOS, i dati e le impostazioni (coppie chiave-valore per la configurazione utente) vengono memorizzati nella cache nel dispositivo in una sandbox e in una risorsa di archiviazione interna accessibile solo all'app. Per l'app di Windows, i dati sono accessibili solo dall'utente (e dall'amministratore di sistema).
• La geolocalizzazione è abilitata o disabilitata esplicitamente dall'utente. Se abilitata, i dati di geolocalizzazione non vengono salvati sul dispositivo e non vengono condivisi con Microsoft.
• Le notifiche sono abilitate o disabilitate esplicitamente dall'utente. Se abilitata, Android e iOS non supportano i requisiti di residenza dei dati geografici per le notifiche.

La crittografia dei dati può essere migliorata applicando la crittografia a livello di file tramite Microsoft Intune, un servizio software che fornisce la gestione di dispositivi mobili e applicazioni. Tutte e tre le piattaforme per cui Power BI per dispositivi mobili è disponibile supportano Intune. Se il servizio Intune è abilitato e configurato, i dati nel dispositivo mobile vengono crittografati e l'applicazione Power BI non può essere installata in una scheda SD. Altre informazioni su Microsoft Intune.

L'app di Windows supporta anche Windows Information Protection (WIP).

Per implementare l'accesso Single Sign-On, alcuni valori di archiviazione protetti correlati all'autenticazione basata su token sono disponibili per altre app proprietarie Microsoft (ad esempio Microsoft Authenticator) e vengono gestiti dal Microsoft Authentication Library (MSAL).

I dati memorizzati nella cache di Power BI per dispositivi mobili vengono eliminati quando l'app viene rimossa, quando l'utente si disconnette da Power BI Mobile o quando l'utente non riesce ad accedere, ad esempio dopo un evento di scadenza del token o una modifica della password. La cache dei dati include i dashboard e i report a cui l'utente ha effettuato l'accesso in precedenza dall'app Power BI per dispositivi mobili.

Power BI per dispositivi mobili non accede ad altre cartelle o file dell'applicazione nel dispositivo.

Le app Power BI per iOS e Android consentono di proteggere i dati configurando un'identificazione aggiuntiva, ad esempio fornendo Face ID, Touch ID o un passcode per iOS e dati biometrici (ID impronta digitale) per Android. Altre informazioni sull'identificazione aggiuntiva.

Autenticazione al servizio Power BI

L'autenticazione utente per il servizio Power BI è costituita da una serie di richieste, risposte e operazioni di reindirizzamento tra il browser dell'utente e il servizio Power BI o i servizi di Azure usati da Power BI. Questa sequenza descrive il processo di autenticazione dell'utente in Power BI, che segue il flusso di concessione del codice di autorizzazione di Microsoft Entra. Per altre informazioni sulle opzioni per i modelli di autenticazione utente di un'organizzazione (i modelli di accesso), vedere Choosing a sign-in model for Office 365 (Scelta di un modello di accesso per Microsoft 365).

Sequenza di autenticazione

La sequenza di autenticazione utente per il servizio Power BI avviene come descritto nella procedura e nelle immagini seguenti.

1. L'utente avvia una connessione al servizio Power BI da un browser, digitando l'indirizzo di Power BI nella barra degli indirizzi o selezionando Accesso dalla pagina di marketing di Power BI (https://powerbi.microsoft.com). La connessione si stabilisce tramite TLS e HTTPS e tutte le comunicazioni successive tra il browser e il servizio Power BI usano il protocollo HTTPS.

2. Gestione traffico di Azure controlla il record DNS dell'utente per determinare il data center più appropriato (solitamente il più vicino) in cui Power BI viene distribuito e risponde al DNS con l'indirizzo IP del cluster front-end Web a cui deve essere inviato l'utente.

3. WFE restituisce quindi una pagina HTML al client del browser, che contiene un riferimento alla libreria MSAL.js necessario per avviare il flusso di accesso.

4. Il client del browser carica la pagina HTML ricevuta dal WFE e reindirizza l'utente alla pagina di accesso di Microsoft Online Services.

5. Dopo l'autenticazione dell'utente, la pagina di accesso reindirizza l'utente alla pagina WFE di Power BI con un codice di autenticazione.

6. Il client del browser carica la pagina HTML e usa il codice di autenticazione per richiedere token (accesso, ID, aggiornamento) da Microsoft Entra ID.

7. L'ID tenant dell'utente viene usato dal client del browser per eseguire query sul servizio globale di Power BI, che gestisce un elenco di tenant e i relativi percorsi del cluster back-end di Power BI. Il servizio globale di Power BI determina il cluster del servizio back-end di Power BI che contiene il tenant dell'utente e restituisce l'URL del cluster back-end di Power BI al client.

8. Il client è ora in grado di comunicare con l'API URL del cluster back-end di Power BI, usando il token di accesso nell'intestazione autorizzazione per le richieste HTTP. Il token di accesso di Microsoft Entra avrà una data di scadenza impostata in base ai criteri di Microsoft Entra e, per mantenere la sessione corrente, il client Power BI nel browser dell'utente effettuerà richieste periodiche per rinnovare il token di accesso prima della scadenza.

Nei rari casi in cui l'autenticazione lato client non riesce a causa di un errore imprevisto, il codice tenta di eseguire il fallback all'uso dell'autenticazione lato server in WFE. Fare riferimento alla sezione domande e risposte alla fine di questo documento per informazioni dettagliate sul flusso di autenticazione lato server.

Residenza dei dati

Se non diversamente indicato nella documentazione, Power BI archivia i dati dei clienti in un'area geografica di Azure assegnata quando un tenant Microsoft Entra accede ai servizi Power BI per la prima volta. Un tenant di Microsoft Entra ospita identità, gruppi e altre informazioni rilevanti relative a un'organizzazione e alla relativa sicurezza.

L'assegnazione di un'area geografica di Azure per l'archiviazione dei dati del tenant viene eseguita tramite il mapping del paese o dell'area geografica selezionati come parte della configurazione del tenant di Microsoft Entra all'area geografica di Azure più adatta in cui esiste una distribuzione di Power BI. Una volta effettuata questa determinazione, tutti i dati dei clienti di Power BI verranno archiviati in questa area geografica di Azure selezionata (nota anche come Home Geo), tranne nei casi in cui le organizzazioni usino distribuzioni Multi-Geo.

Aree geografiche multiple (Multi-Geo)

Alcune organizzazioni hanno una presenza globale e possono richiedere servizi Power BI in più aree geografiche di Azure. Ad esempio, un'azienda può avere sede centrale negli Stati Uniti, ma può anche svolgere attività in altre aree geografiche, ad esempio l'Australia. In questi casi l'azienda potrebbe richiedere che determinati dati di Power BI rimangano archiviati inattivi nell'area remota per rispettare le normative locali. Questa funzionalità del servizio Power BI viene definita Multi-Geo.

Il livello di esecuzione delle query, le cache delle query e i dati degli artefatti assegnati a un'area di lavoro multi-geografica sono ospitati e rimangono nella geografia di Azure per la capacità remota. Tuttavia, alcuni metadati dell'artefatto, ad esempio la struttura del report, possono rimanere archiviati come inattivi nella replica geografica principale del tenant. Inoltre, alcune operazioni di transito ed elaborazione dei dati possono essere ancora eseguite nell'area geografica principale del tenant, anche per le aree di lavoro ospitate in una capacità Premium Multi-Geo.

Per altre informazioni sulla creazione e la gestione di distribuzioni di Power BI che si estendono su più aree geografiche di Azure vedere Configurare il supporto Multi-Geo per Power BI Premium.

Aree e data center

I servizi Power BI sono disponibili in aree geografiche di Azure specifiche, come descritto nel Centro protezione Microsoft. Per altre informazioni su dove vengono archiviati i dati e su come vengono usati, fare riferimento al Centro protezione Microsoft. Le direttive sulla posizione di archiviazione dei dati inattivi dei clienti sono specificate nelle Condizioni dell'elaborazione dati delle Condizioni dei servizi online Microsoft.

Microsoft offre anche data center per le entità sovrane. Per altre informazioni sulla disponibilità del servizio Power BI per i cloud nazionali/regionali, vedere Cloud nazionali/regionali di Power BI.

Trattamento dei dati

Questa sezione illustra le procedure di gestione dei dati di Power BI per l'archiviazione, l'elaborazione e il trasferimento dei dati dei clienti.

Dati inattivi

Power BI usa due tipi di risorse di archiviazione dati principali:

• Archiviazione di Azure
• Database SQL di Azure

Nella maggior parte degli scenari, Archiviazione di Azure viene usata per rendere persistenti i dati degli artefatti di Power BI, mentre i database SQL di Azure vengono usati per rendere persistenti i metadati degli artefatti.

Tutti i dati salvati in modo permanente da Power BI vengono crittografati per impostazione predefinita usando chiavi gestite da Microsoft. I dati dei clienti archiviati nel database SQL di Azure vengono crittografate completamente usando la tecnologia Transparent Data Encryption (TDE) di SQL di Azure. I dati dei clienti archiviati nell'Archiviazione BLOB di Azure vengono crittografati usando Crittografia di Archiviazione di Azure.

Facoltativamente, le organizzazioni possono usare Power BI Premium in modo da usare le proprie chiavi per crittografare i dati inattivi importati in un modello semantico. Questo approccio viene spesso descritto come BYOK (Bring Your Own Key). L'uso di BYOK consente di garantire che, anche in caso di errore di un operatore di servizio, i dati dei clienti non vengano esposti, un approccio che non può essere facilmente adottato usando la crittografia trasparente lato servizio. Per altre informazioni, vedere Usare chiavi di crittografia personalizzate per Power BI.

I modelli semantici di Power BI consentono diverse modalità di connessione all'origine dati che determinano se i dati dell'origine dati sono persistenti nel servizio o meno.

Modalità modello semantico (tipo)	Dati persistenti in Power BI
Importa	Sì
DirectQuery	No
Live Connect	No
Composito	Se contiene un'origine dati di importazione
Streaming	Se con configurazione per la persistenza

Indipendentemente dalla modalità del modello semantico utilizzata, Power BI può memorizzare temporaneamente nella cache tutti i dati recuperati per ottimizzare le prestazioni di caricamento delle query e dei report.

Dati in elaborazione

I dati vengono elaborati quando vengono usati attivamente da uno o più utenti come parte di uno scenario interattivo o quando un processo in background, ad esempio l'aggiornamento, li usa. Power BI carica attivamente i dati elaborati nello spazio di memoria di uno o più carichi di lavoro del servizio. Per facilitare la funzionalità richiesta dal carico di lavoro, i dati elaborati in memoria non vengono crittografati.

Dati in transito

Power BI richiede che tutto il traffico HTTP in ingresso venga crittografato con TLS 1.2 o versione successiva. Tutte le richieste che tentano di usare il servizio con TLS 1.1 o versione precedente verranno rifiutate.

Autenticazione alle origini dati

Quando ci si connette a un'origine dati, un utente può scegliere di importare una copia dei dati in Power BI o di connettersi direttamente all'origine dati.

Nel caso di importazione, un utente stabilisce una connessione in base all'accesso e accede ai dati con le credenziali. Dopo la pubblicazione del modello semantico nel servizio Power BI, Power BI usa sempre le credenziali di questo utente per importare i dati. Dopo l'importazione dei dati, la visualizzazione dei dati nei report e nel dashboard non accede all'origine dati sottostante. Power BI supporta l'autenticazione Single Sign-On per le origini dati selezionate. Se la connessione è configurata per l'uso dell'accesso Single Sign-On, le credenziali del proprietario del modello semantico vengono usate per connettersi all'origine dati.

Se un'origine dati è connessa direttamente tramite credenziali preconfigurate, queste ultime vengono usate per connettersi all'origine dati quando un utente visualizza i dati. Se un'origine dati è connessa direttamente tramite Single Sign-On, le credenziali dell'utente corrente vengono usate per connettersi all'origine quando un utente visualizza i dati. Se usata con l'accesso Single Sign-On, è possibile implementare la sicurezza a livello di riga e/o la sicurezza a livello di oggetto nell'origine dati. In questo modo gli utenti possono visualizzare solo i dati per cui dispongono dei privilegi di accesso. Quando la connessione è alle origini dati nel cloud, l'autenticazione di Microsoft Entra viene usata per l'accesso Single Sign-On; per le origini dati locali, sono supportati Kerberos, Security Assertion Markup Language (SAML) e Microsoft Entra ID.

Se l'origine dati è Azure Analysis Services o Analysis Services locale e la sicurezza a livello di riga e/o la sicurezza a livello di oggetto sono configurate, il servizio Power BI applicherà la sicurezza a livello di riga e gli utenti che non dispongono di credenziali sufficienti per accedere ai dati sottostanti (che potrebbero essere una query usata in un dashboard, un report o un altro artefatto di dati) non visualizzeranno i dati per i quali non dispongono di privilegi sufficienti.

Funzionalità Premium

Architettura dei flussi di dati

I flussi di dati offrono agli utenti la possibilità di configurare operazioni di elaborazione dati back-end che estraggono i dati da origini dati polimorfiche, eseguono la logica di trasformazione sui dati e quindi li usano in un modello di destinazione in varie tecnologie di presentazione di report. Qualsiasi utente con ruolo membro, collaboratore o amministratore in un'area di lavoro può creare un flusso di dati. Gli utenti nel ruolo visualizzatore possono visualizzare i dati elaborati dal flusso di dati, ma non possono apportare modifiche alla relativa composizione. Dopo aver creato un flusso di dati, qualsiasi membro, collaboratore o amministratore dell'area di lavoro può pianificare gli aggiornamenti, nonché visualizzare e modificare il flusso di dati prendendone la proprietà.

Ogni origine dati configurata è associata a una tecnologia client per l'accesso a tale origine. La struttura delle credenziali necessarie per accedervi viene creata in modo da corrispondere ai dettagli di implementazione necessari dell'origine dati. La logica di trasformazione viene applicata dai servizi Power Query mentre i dati sono in anteprima. Per i flussi di dati Premium, i servizi Power Query sono eseguiti nei nodi back-end. I dati possono essere estratti direttamente dalle origini cloud o tramite un gateway installato in locale. Quando viene eseguito il pull direttamente da un'origine cloud al servizio o al gateway, il trasporto usa la metodologia di protezione specifica per la tecnologia client, se applicabile. Quando i dati vengono trasferiti dal gateway al servizio cloud, vengono crittografati. Vedere la sezione Dati in movimento precedente.

Quando le origini dati specificate dal cliente richiedono credenziali per l'accesso, il proprietario o l'autore del flusso di dati le fornirà durante la creazione. Vengono archiviati usando l'archiviazione delle credenziali standard a livello di prodotto. Vedere la sezione Autenticazione alle origini dati precedente. Esistono diversi approcci che gli utenti possono configurare per ottimizzare la persistenza e l'accesso ai dati. Per impostazione predefinita, i dati vengono inseriti in un account di archiviazione di proprietà di Power BI e protetti. La crittografia dell'archiviazione è abilitata nei contenitori di archiviazione BLOB per proteggere i dati mentre sono inattivi. Vedere la sezione Dati inattivi più avanti. Gli utenti possono tuttavia configurare il proprio account di archiviazione associato alla propria sottoscrizione di Azure. In questo caso, a un'entità servizio Power BI viene concesso l'accesso a tale account di archiviazione in modo che possa scrivere i dati durante l'aggiornamento. In questo caso, il proprietario della risorsa di archiviazione è responsabile della configurazione della crittografia nell'account di archiviazione ADLS configurato. I dati vengono sempre trasmessi all'archivio BLOB usando la crittografia.

Poiché le prestazioni durante l'accesso agli account di archiviazione potrebbero risultare non ottimali per alcuni dati, gli utenti possono anche usare un motore di calcolo ospitato in Power BI per migliorarle. In questo caso, i dati vengono archiviati in modo ridondante in un database SQL disponibile per DirectQuery tramite l'accesso dal sistema Power BI back-end. I dati vengono sempre crittografati nel file system. Se l'utente fornisce una chiave per crittografare i dati archiviati nel database SQL, tale chiave verrà usata per crittografarli manualmente.

Quando si eseguono query con DirectQuery, il protocollo di trasporto crittografato HTTPS viene usato per accedere all'API. Tutti gli usi secondari o indiretti di DirectQuery sono controllati dagli stessi controlli di accesso descritti in precedenza. Poiché i flussi di dati sono sempre associati a un'area di lavoro, l'accesso ai dati viene sempre gestito dal ruolo dell'utente in tale area di lavoro. Un utente deve avere almeno l'accesso in lettura per poter eseguire query sui dati tramite qualsiasi mezzo.

Quando Power BI Desktop viene usato per accedere ai dati in un flusso di dati, deve prima autenticare l'utente usando Microsoft Entra ID per determinare se dispone di diritti sufficienti per visualizzare i dati. In tal caso, viene acquisita e usata una chiave SaS per accedere direttamente all'archiviazione usando il protocollo di trasporto crittografato HTTPS.

L'elaborazione dei dati in tutta la pipeline genera eventi di controllo di Office 365. Alcuni di questi eventi acquisiranno operazioni correlate alla sicurezza e alla privacy.

Report impaginati

I report impaginati sono progettati per essere stampati o condivisi. Vengono definiti impaginati perché sono formattati in modo da adattarsi meglio alla pagina. Visualizzano tutti i dati in una tabella, anche se la tabella si estende su più pagine. È possibile controllare esattamente il layout della pagina del report.

I report impaginati supportano espressioni avanzate e potenti scritte in Microsoft Visual Basic .NET. Nei report impaginati di Power BI Report Builder le espressioni vengono ampiamente usate per recuperare, calcolare, visualizzare, raggruppare, ordinare, filtrare, parametrizzare e formattare i dati.

Le espressioni vengono create dall'autore del report con accesso all'ampia gamma di funzionalità di .NET Framework. L'elaborazione e l'esecuzione di report impaginati viene eseguita all'interno di una sandbox.

Le definizioni di report impaginati (con estensione rdl) vengono archiviate in Power BI e per pubblicare e/o eseguire il rendering di un report impaginato un utente deve autenticarsi e autorizzarsi nello stesso modo descritto nella sezione Autenticazione al servizio Power BI precedente.

Il token Microsoft Entra ottenuto durante l'autenticazione viene usato per comunicare direttamente dal browser con il cluster Power BI Premium.

In Power BI Premium, il runtime del servizio Power BI fornisce un ambiente di esecuzione isolato appropriato per ogni rendering del report. Sono inclusi i casi in cui il rendering dei report appartiene alle aree di lavoro assegnate alla stessa capacità.

Un report impaginato può accedere a un ampio set di origini dati come parte del rendering. La sandbox non comunica direttamente con alcuna origine dati, ma comunica con il processo attendibile per richiedere i dati. Quindi, il processo attendibile aggiunge le credenziali necessarie alla connessione. In questo modo, la sandbox non ha mai accesso a credenziali o segreti.

Per supportare funzionalità come Bing Maps o chiamate a Funzioni di Azure, la sandbox ha accesso a Internet.

Analisi incorporata di Power BI

I fornitori di software indipendenti (ISV) e i provider di soluzioni hanno due modalità principali per incorporare gli artefatti di Power BI nelle applicazioni Web e nei portali: incorporare per l'organizzazione e incorporare per i clienti. L'artefatto è incorporato in un IFrame nell'applicazione o nel portale. Un IFrame non è autorizzato a leggere o scrivere dati dall'applicazione Web esterna o dal portale e la comunicazione con l'IFrame viene eseguita usando Power BI Client SDK tramite messaggi POST.

In uno scenario di incorporamento di per l'organizzazione, gli utenti di Microsoft Entra accedono ai propri contenuti di Power BI tramite portali personalizzati dalle aziende e dagli ITS. Tutti i criteri e le funzionalità di Power BI descritti in questo documento, ad esempio sicurezza a livello di riga e sicurezza a livello di oggetto, vengono applicati automaticamente a tutti gli utenti indipendentemente dal fatto che accedano a Power BI tramite il portale di Power BI o tramite portali personalizzati.

In uno scenario di incorporamento per i clienti, gli ISV in genere possiedono tenant di Power BI ed elementi di Power BI (dashboard, report, modelli semantici e altro). È responsabilità di un servizio back-end ISV autenticare gli utenti finali e decidere quali artefatti e quale livello di accesso siano appropriati per l'utente finale. Le decisioni dei criteri ISV vengono crittografate in un token di incorporamento generato da Power BI e passate al back-end ISV per un'ulteriore distribuzione agli utenti finali in base alla logica di business dell'ISV. Gli utenti finali che usano un browser o altre applicazioni client non sono in grado di decrittografare o modificare i token di incorporamento. Gli SDK lato client, ad esempio API client di Power BI, accodano automaticamente il token di incorporamento crittografato alle richieste di Power BI come intestazione di Authorization: EmbedToken. In base a questa intestazione, Power BI applicherà tutti i criteri (ad esempio l'accesso o la sicurezza a livello di riga) esattamente come specificato dall'ISV durante la generazione.

Per abilitare l'incorporamento e l'automazione e generare i token di incorporamento descritti in precedenza, Power BI espone un set completo di API REST. Queste API REST di Power BI supportano sia i metodi di autenticazione e autorizzazione delegato dall'utente che l'entità servizio di Microsoft Entra.

L'analisi incorporata di Power BI e le API REST supportano tutte le funzionalità di isolamento rete di Power BI descritte in questo articolo: ad esempio Tag del servizio e Collegamenti privati.

Funzionalità di intelligenza artificiale

Power BI supporta attualmente due ampie categorie di funzionalità di intelligenza artificiale nel prodotto: oggetti visivi di intelligenza artificiale e arricchimenti tramite intelligenza artificiale. Le funzionalità di intelligenza artificiale a livello visivo includono funzionalità quali Fattori di influenza chiave, Albero di scomposizione, Smart-Narrative, Rilevamento anomalie, R-visual, Python-visual, Clustering, Previsione, Q&A, Quick-Insights e così via. Le funzionalità di arricchimento tramite intelligenza artificiale includono funzionalità come AutoML, Azure Machine Learning, CognitiveServices, trasformazioni R/Python e così via.

La maggior parte delle funzionalità indicate in precedenza è supportata nelle aree di lavoro condivise e Premium. Tuttavia, AutoML e CognitiveServices sono supportati solo nelle aree di lavoro Premium, a causa di restrizioni IP. Oggi, con l'integrazione di AutoML in Power BI, un utente può compilare ed eseguire il training di un modello di Machine Learning personalizzato (ad esempio Stima, Classificazione, Regressione e così via) e applicarlo per ottenere stime durante il caricamento dei dati in un flusso di dati definito in un'area di lavoro Premium. Inoltre, gli utenti di Power BI possono applicare diverse API CognitiveServices, ad esempio TextAnalytics e ImageTagging, per trasformare i dati prima di caricarli in un modello semantico/flusso di dati definito in un'area di lavoro Premium.

Le funzionalità di arricchimento tramite intelligenza artificiale Premium possono essere visualizzate meglio come una raccolta di funzioni/trasformazioni di intelligenza artificiale senza stato che possono essere usate dagli utenti di Power BI nelle pipeline di integrazione dei dati usate da un modello semantico o da un flusso di dati di Power BI. Si noti che è possibile accedere a queste funzioni anche dagli ambienti di creazione di flussi di dati/semantici correnti nel servizio Power BI e in Power BI Desktop. Queste funzioni/trasformazioni di intelligenza artificiale vengono sempre eseguite in un'area di lavoro/capacità Premium. Queste funzioni vengono visualizzate in Power BI come origine dati che richiede un token Microsoft Entra per l'utente di Power BI che usa la funzione di intelligenza artificiale. Queste origini dati di intelligenza artificiale sono speciali perché non presentano dati personali e forniscono solo queste funzioni/trasformazioni. Durante l'esecuzione, queste funzionalità non effettuano chiamate in uscita ad altri servizi per trasmettere i dati del cliente. Esaminiamo gli scenari Premium singolarmente per comprendere i modelli di comunicazione e i relativi dettagli di sicurezza pertinenti.

Per il training e l'applicazione di un modello AutoML, Power BI usa Azure AutoML SDK ed esegue tutto il training nella capacità di Power BI del cliente. Durante le iterazioni di training, Power BI chiama un servizio di sperimentazione di Azure Machine Learning per selezionare un modello appropriato e iper parametri per l'iterazione corrente. In questa chiamata in uscita vengono inviati solo i metadati dell'esperimento pertinenti (ad esempio accuratezza, algoritmo ML, parametri dell'algoritmo e così via) dell'iterazione precedente. Il training AutoML produce un modello ONNX e dati del report di training che vengono quindi salvati nel flusso di dati. Successivamente, gli utenti di Power BI possono applicare il modello di Machine Learning sottoposto a training come trasformazione per renderlo operativo in base a una pianificazione. Per le API TextAnalytics e ImageTagging, Power BI non chiama direttamente le API del servizio CognitiveServices, ma usa un SDK interno per eseguire le API nella capacità di Power BI Premium. Attualmente queste API sono supportate sia nei flussi di dati che nei modelli semantici di Power BI. Durante la creazione di un modello di dati in Power BI Desktop, gli utenti possono accedere a questa funzionalità solo se hanno accesso a un'area di lavoro di Power BI Premium. Di conseguenza, ai clienti viene chiesto di fornire le credenziali di Microsoft Entra.

Isolamento della rete

Questa sezione descrive le funzionalità di sicurezza avanzate in Power BI. Alcune delle funzionalità hanno requisiti di licenza specifici. Per informazioni dettagliate, vedere le sezioni seguenti.

Tag di servizio

Un tag del servizio rappresenta un gruppo di prefissi di indirizzi IP di un determinato servizio di Azure. Consente di ridurre al minimo la complessità degli aggiornamenti frequenti alle regole di sicurezza di rete. I clienti possono usare i tag di servizio per definire i controlli di accesso di rete nei gruppi di sicurezza di rete o Firewall di Azure. I clienti possono usare tag di servizio al posto di indirizzi IP specifici durante la creazione di regole di sicurezza. Specificando il nome del tag del servizio ( ad esempio PowerBI) nel campo di origine o destinazione appropriato (per le API) di una regola, i clienti possono consentire o negare il traffico per il servizio corrispondente. I prefissi di indirizzo inclusi nel tag di servizio sono gestiti da Microsoft, che aggiorna automaticamente il tag in caso di modifica degli indirizzi.

Integrazione di Collegamento privato

Rete di Azure include la funzionalità collegamenti privati di Azure che consente a Power BI di fornire un accesso sicuro tramite gli endpoint privati di Rete di Azure. Con i collegamenti privati di Azure e gli endpoint privati, il traffico dati viene inviato privatamente usando l'infrastruttura di rete backbone di Microsoft e quindi i dati non attraversano Internet.

Il collegamento privato assicura che gli utenti di Power BI usino il backbone della rete privata di Microsoft per accedere alle risorse nel servizio Power BI.

L'uso di Collegamento privato con Power BI offre i vantaggi seguenti:

• Il collegamento privato assicura che il traffico venga trasferito attraverso il backbone di Azure a un endpoint privato per le risorse basate sul cloud di Azure.
• L'isolamento del traffico di rete dall'infrastruttura non basata su Azure, ad esempio l'accesso locale, richiederebbe ai clienti di configurare ExpressRoute o una rete privata virtuale (VPN).

Per altre informazioni, vedere Collegamenti privati per l'accesso a Power BI.

Connettività della rete virtuale

Sebbene la funzionalità di integrazione Collegamento privato fornisca connessioni in ingresso sicure a Power BI, la funzionalità di connettività della rete virtuale consente la connettività in uscita sicura da Power BI alle origini dati all'interno di una rete virtuale.

I gateway di rete virtuale (gestiti da Microsoft) eliminano il sovraccarico dell'installazione e del monitoraggio dei gateway dati locali per la connessione alle origini dati associate a una rete virtuale. Tuttavia, seguono comunque il processo familiare di gestione delle origini dati e della sicurezza, come con un gateway dati locale.

Di seguito è riportata una panoramica di cosa accade quando si interagisce con un report di Power BI connesso a un'origine dati all'interno di una rete virtuale usando i gateway di rete virtuale:

1. Il servizio cloud di Power BI (o uno degli altri servizi cloud supportati) avvia una query e quindi invia la query, i dettagli sull'origine dati e le credenziali di accesso al servizio di rete virtuale Power Platform (PP VNet).

2. Il servizio di rete virtuale PP inserisce quindi in modo sicuro un contenitore che esegue un gateway di rete virtuale nella subnet. Questo contenitore può ora connettersi ai servizi dati accessibili dall'interno di questa subnet.

3. Il servizio di rete virtuale PP invia quindi la query, i dettagli dell'origine dati e le credenziali al gateway di rete virtuale.

4. Il gateway di rete virtuale riceve la query e si connette alle origini dati con le credenziali ottenute.

5. La query viene quindi inviata all'origine dati per l'esecuzione.

6. Dopo l'esecuzione, i risultati vengono inviati al gateway di rete virtuale e il servizio di rete virtuale PP invia in sicurezza i dati dal contenitore al servizio cloud Power BI.

Entità servizio

Power BI supporta l'uso di entità servizio. Archiviare le credenziali delle entità servizio usate per la crittografia o l'accesso a Power BI in un insieme di credenziali delle chiavi, assegnare criteri di accesso appropriati all'insieme di credenziali e verificare periodicamente le autorizzazioni di accesso.

Per altri dettagli, vedere Automatizzare le attività dell'area di lavoro Premium e del modello semantico con le entità servizio.

Microsoft Purview per Power BI

Microsoft Purview Information Protection

Power BI è completamente integrato con Microsoft Purview Information Protection. Microsoft Purview Information Protection consente alle organizzazioni di avere una singola soluzione integrata per la classificazione, l'etichettatura, il controllo e la conformità in Azure, Power BI e Office.

Quando la protezione delle informazioni è abilitata in Power BI:

• I dati sensibili, sia nel servizio Power BI che in Power BI Desktop, possono essere classificati ed etichettati usando le stesse etichette di riservatezza usate in Office e in Azure.
• I criteri di governance possono essere applicati quando il contenuto di Power BI viene esportato in Excel, PowerPoint, PDF, Word o file con estensione pbix, per garantire la protezione dei dati anche quando esce da Power BI.
• È facile classificare e proteggere file con estensione pbix in Power BI Desktop, proprio come avviene nelle applicazioni Excel, Word e PowerPoint. I file possono essere facilmente contrassegnati in base al livello di riservatezza. Inoltre, possono essere crittografati se contengono dati aziendali riservati, assicurando così che solo gli utenti autorizzati possano modificare questi file.
• Le cartelle di lavoro di Excel ereditano automaticamente le etichette di riservatezza quando si connettono a Power BI (anteprima), rendendo possibile mantenere la classificazione end-to-end e applicare la protezione quando i modelli semantici di Power BI vengono analizzati in Excel.
• Le etichette di riservatezza applicate ai report e ai dashboard di Power BI sono visibili nelle app Power BI per dispositivi mobili iOS e Android.
• Le etichette di riservatezza vengono mantenute quando un report di Power BI viene incorporato in Teams, SharePoint o in un sito Web sicuro. Ciò consente alle organizzazioni di mantenere la classificazione e la protezione durante l'esportazione quando incorporano contenuto di Power BI.
• L'ereditarietà delle etichette al momento della creazione di nuovo contenuto nel servizio Power BI garantisce che le etichette applicate ai modelli semantici o ai datamart nel servizio Power BI vengano applicate al nuovo contenuto creato sopra a tali modelli semantici e ai datamart.
• Le API di analisi dell'amministratore di Power BI possono estrarre l'etichetta di riservatezza di un elemento di Power BI, consentendo agli amministratori di Power BI e InfoSec di monitorare l'etichettatura nel servizio Power BI e produrre report esecutivi.
• Le API di amministrazione di Power BI consentono ai team centrali di applicare etichette di riservatezza a livello di codice al contenuto nel servizio Power BI.
• I team centrali possono creare criteri di etichetta obbligatori per applicare etichette al contenuto nuovo o modificato in Power BI.
• I team centrali possono creare criteri di etichetta predefiniti per assicurarsi che un'etichetta di riservatezza venga applicata a tutto il contenuto di Power BI nuovo o modificato.
• L'etichettatura di riservatezza downstream automatica nel servizio Power BI garantisce che quando un'etichetta in un modello semantico o un datamart viene applicata o modificata, verrà applicata o modificata automaticamente in tutto il contenuto downstream connesso al modello semantico o al datamart.

Per altre informazioni, vedere Etichette di riservatezza in Power BI.

Criteri di prevenzione della perdita dei dati di Microsoft Purview per Power BI

I criteri di prevenzione della perdita dei dati di Microsoft Purview consentono alle organizzazioni di ridurre il rischio di perdita di dati aziendali sensibili da Power BI. I criteri di prevenzione della perdita dei dati consentono loro di soddisfare i requisiti di conformità delle normative governative o del settore, ad esempio il GDPR (Regolamento generale sulla protezione dei dati) o il CCPA (California Consumer Privacy Act) e ad assicurare la gestione dei dati in Power BI.

Quando vengono configurati i criteri di prevenzione della perdita dei dati per Power BI:

• Tutti i modelli semantici all'interno delle aree di lavoro specificate nei criteri vengono valutati dai criteri.
• È possibile rilevare quando i dati sensibili vengono caricati nelle capacità Premium. I criteri DLP possono rilevare:
  • Etichette di riservatezza.
  • Tipi di informazioni sensibili. Sono supportati oltre 260 tipi. Il rilevamento dei tipi di informazioni sensibili si basa sull'analisi dei contenuti di Microsoft Purview.
• Quando si rileva un modello semantico identificato come sensibile, è possibile visualizzare una descrizione dei criteri personalizzata che consente di comprendere le operazioni da eseguire.
• Se si è proprietari di un modello semantico, è possibile eseguire l'override di un criterio e impedire che il modello venga identificato come "sensibile" se si ha un motivo valido per farlo.
• Se si è proprietari di un modello semantico, è possibile segnalare un problema con un criterio se si conclude che un tipo di informazioni sensibili è stato identificato in modo falso.
• È possibile richiamare le mitigazioni automatiche dei rischi, ad esempio gli avvisi per l'amministratore della sicurezza.

Per altre informazioni, vedere Criteri di prevenzione della perdita dei dati per Fabric Power BI.

Microsoft Defender for Cloud Apps per Power BI

Microsoft Defender for Cloud Apps è uno dei principali broker di sicurezza per l'accesso al cloud, riconosciuto come leader nel Magic Quadrant di Gartner per il mercato CASB (Cloud Access Security Broker). Defender for Cloud Apps viene usato per proteggere l'uso delle app cloud. Consente alle organizzazioni di monitorare e controllare, in tempo reale, sessioni di Power BI rischiose, ad esempio l'accesso degli utenti da dispositivi non gestiti. Gli amministratori della sicurezza possono definire criteri per controllare le azioni degli utenti, ad esempio il download di report con informazioni riservate.

Con Defender for Cloud Apps, le organizzazioni possono ottenere le funzionalità DLP seguenti:

• Impostare controlli in tempo reale per applicare sessioni utente rischiose in Power BI. Ad esempio, se un utente si connette a Power BI dall'esterno del proprio paese o area geografica, la sessione può essere monitorata dai controlli in tempo reale di Defender for Cloud Apps e le azioni rischiose, ad esempio il download di dati contrassegnati con un'etichetta di riservatezza "Estremamente riservato", possono essere bloccate immediatamente.
• Esaminare l'attività utente di Power BI con il log attività di Defender for Cloud Apps. Il log attività di Defender for Cloud Apps include le attività di Power BI acquisite nel log di controllo di Office 365, che contiene informazioni su tutte le attività utente e amministrative, nonché informazioni sulle etichette di riservatezza per le attività pertinenti, ad esempio applicazione, modifica e rimozione dell'etichetta. Gli amministratori possono sfruttare i filtri avanzati di Defender for Cloud Apps e le azioni rapide per un'analisi efficace dei problemi.
• Creare criteri personalizzati per segnalare attività utente sospette in Power BI. La funzionalità dei criteri di attività di Defender for Cloud Apps può essere sfruttata per definire regole personalizzate, per rilevare il comportamento dell'utente che devia dalla norma e persino per intervenire automaticamente, se sembra troppo pericoloso.
• Usare il rilevamento anomalie predefinito di Defender for Cloud Apps. I criteri di rilevamento anomalie di Defender for Cloud Apps forniscono analisi del comportamento utente predefinite e Machine Learning, in modo da essere pronti fin dall'inizio per eseguire il rilevamento avanzato delle minacce nell'ambiente cloud. Quando un criterio di rilevamento anomalie identifica un comportamento sospetto, attiva un avviso di sicurezza.
• Ruolo di amministratore di Power BI nel portale di Defender for Cloud Apps. Defender for Cloud Apps offre un ruolo di amministratore specifico dell'app che può essere usato per concedere agli amministratori di Power BI solo le autorizzazioni necessarie per accedere ai dati rilevanti per Power BI nel portale, ad esempio avvisi, utenti a rischio, log attività e altre informazioni correlate a Power BI.

Per altri dettagli, vedere Uso dei controlli di Microsoft Defender for Cloud Apps in Power BI.

Funzionalità di sicurezza in anteprima

Questa sezione elenca le funzionalità pianificate per il rilascio fino a marzo 2021. Poiché in questo argomento sono elencate funzionalità che potrebbero non essere state ancora rilasciate, le tempistiche di recapito potrebbero cambiare e le funzionalità previste potrebbero essere state rilasciate dopo marzo 2021 o non essere state rilasciate affatto. Per altre informazioni sulle anteprime, vedere le Condizioni per l'Utilizzo dei Servizi Online.

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics consente l'integrazione tra Power BI e Azure Log Analytics. Questa integrazione include il motore analitico avanzato di Azure Log Analytics, il linguaggio di query interattivo e i costrutti di Machine Learning predefiniti.

Domande e risposte sulla sicurezza di Power BI

Di seguito sono riportate domande comuni sulla sicurezza e le relative risposte per Power BI. Le domande sono organizzate in base all'ordine cronologico in cui sono state aggiunte al presente white paper, per consentire una maggiore rapidità nella ricerca delle nuove domande e risposte quando il white paper viene aggiornato. Le domande più recenti vengono aggiunte alla fine dell'elenco.

In che modo gli utenti possono connettersi e ottenere l'accesso alle origini dati con Power BI?

• Power BI gestisce le credenziali delle origini dati per ogni utente in termini di credenziali cloud o connettività tramite un gateway personale. Le origini dati gestite da un gateway dati locale possono essere condivise in tutta l'organizzazione e le autorizzazioni per queste origini dati possono essere gestite dall'amministratore del gateway. Quando si configura un modello semantico, l'utente può selezionare una credenziale dall'archivio personale o usare un gateway dati locale per usare credenziali condivise.

  Nel caso di importazione, un utente stabilisce una connessione in base all'accesso e accede ai dati con le credenziali. Dopo la pubblicazione del modello semantico nel servizio Power BI, Power BI usa sempre le credenziali di questo utente per importare i dati. Dopo l'importazione dei dati, la visualizzazione dei dati nei report e nel dashboard non accede all'origine dati sottostante. Power BI supporta l'autenticazione Single Sign-On per le origini dati selezionate. Se la connessione è configurata per l'uso dell'accesso Single Sign-On, le credenziali del proprietario del modello semantico vengono usate per connettersi all'origine dati.

  Per i report connessi a DirectQuery, se un'origine dati è connessa direttamente tramite credenziali preconfigurate, queste ultime vengono usate per connettersi all'origine dati quando un utente visualizza i dati. Se un'origine dati è connessa direttamente tramite Single Sign-On, le credenziali dell'utente corrente vengono usate per connettersi all'origine quando un utente visualizza i dati. Quando si usa con l'accesso Single Sign-On, la sicurezza a livello di riga e/o la sicurezza a livello di oggetto (OLS) può essere implementata nell'origine dati e ciò consente agli utenti di visualizzare i dati a cui hanno privilegi di accesso. Quando la connessione è alle origini dati nel cloud, l'autenticazione di Microsoft Entra viene usata per l'accesso Single Sign-On; per le origini dati locali, sono supportati Kerberos, SAML e Microsoft Entra ID.

  Quando ci si connette con Kerberos, l'UPN dell'utente viene passato al gateway e, tramite la delega vincolata Kerberos, l'utente viene rappresentato e connesso alle rispettive origini dati. SAML è supportato anche nel gateway per l'origine dati SAP HANA. Altre informazioni sono disponibili in panoramica dell'accesso Single Sign-On per i gateway.

  Se l'origine dati è Azure Analysis Services o Analysis Services locale e la sicurezza a livello di riga (RLS) e/o la sicurezza a livello di oggetto (OLS) sono configurate, il servizio Power BI applicherà la sicurezza a livello di riga e gli utenti che non dispongono di credenziali sufficienti per accedere ai dati sottostanti (che potrebbero essere una query usata in un dashboard, un report o un altro artefatto di dati) non visualizzeranno i dati per i quali non dispongono di privilegi sufficienti.

  La sicurezza a livello di riga con Power BI può essere usata per limitare l'accesso ai dati per gli utenti specificati. I filtri limitano l'accesso ai dati a livello di riga ed è possibile definirli all'interno dei ruoli.

  La Sicurezza a livello di oggetto (OLS) può essere usata per proteggere tabelle o colonne sensibili. Tuttavia, a differenza della sicurezza a livello di riga, la sicurezza a livello di oggetto protegge anche i nomi degli oggetti e i metadati. Ciò consente di impedire agli utenti malintenzionati di individuare anche l'esistenza di tali oggetti. Le tabelle e le colonne protette vengono oscurate nell'elenco dei campi quando si usano strumenti di creazione report come Excel o Power BI e, inoltre, gli utenti senza autorizzazioni non possono accedere agli oggetti metadati protetti tramite DAX o altri metodi. Dal punto di vista degli utenti senza autorizzazioni di accesso appropriate, le tabelle protette e le colonne semplicemente non esistono.

  La sicurezza a livello di oggetto, insieme a quella a livello di riga, consente una sicurezza di livello aziendale avanzata nei report e nei modelli semantici, assicurando che solo gli utenti con le autorizzazioni necessarie abbiano accesso alla visualizzazione e all'interazione con i dati sensibili.

Come vengono trasferiti i dati in Power BI?

• Per la connessione dall'origine dati al servizio Power BI, tutti i dati richiesti e trasmessi da Power BI vengono crittografati in transito con il protocollo HTTPS (tranne quando l'origine dati scelta dal cliente non supporta HTTPS). Viene stabilita una connessione sicura con il provider di dati e i dati passano attraverso la rete solo dopo che tale connessione è stata stabilita.

In che modo Power BI memorizza nella cache i dati dei report, dei dashboard o dei modelli? Tale memorizzazione è sicura?

• Quando si accede a un'origine dati, il servizio Power BI segue il processo descritto nella sezione Autenticazione alle origini dati in precedenza in questo documento.

I client memorizzano i dati delle pagine Web nella cache locale?

• Quando i browser dei client accedono a Power BI, i server Web di Power BI impostano la direttiva Cache-Control su no-store. La direttiva no-store indica al browser di non memorizzare nella cache la pagina Web visualizzata dall'utente e di non archiviare la pagina Web nella cartella della cache del client.

E a proposito di sicurezza basata sui ruoli, condivisione di report e di dashboard e connessioni dati? Come funzionano in termini di accesso ai dati, visualizzazione dei dashboard e accesso e aggiornamento dei report?

• Per le origini dati non abilitate per la sicurezza a livello di ruolo, se un dashboard, un report o un modello di dati è condiviso con altri utenti tramite Power BI, gli utenti con cui il dashboard, il report o il modello è condiviso possono visualizzare i dati contenuti e interagire con essi. Power BI non ripete l'autenticazione degli utenti con l'origine dati originaria. Dopo che i dati sono stati caricati in Power BI, l'utente che ha effettuato l'autenticazione con l'origine dati ha la responsabilità di gestire quali altri utenti e gruppi possono visualizzare i dati.

  Se si creano connessioni dati a un'origine dati abilitata per la sicurezza a livello di ruolo, ad esempio un'origine dati Analysis Services, in Power BI vengono memorizzati nella cache solo i dati del dashboard. Ogni volta che in Power BI si visualizza o si accede a un report o a un modello semantico che usa i dati di un'origine dati abilitata per la sicurezza a livello di ruolo, il servizio Power BI accede all'origine dati per ottenere i dati in base alle credenziali dell'utente. Se le autorizzazioni utente sono sufficienti, i dati vengono caricati nel report o nel modello. Se l'autenticazione non riesce, l'utente visualizzerà un errore.

  Per altre informazioni, vedere la sezione Autenticazione alle origini dati più indietro in questo documento.

Gli utenti si connettono sempre alle stesse origini dati, alcune delle quali richiedono credenziali diverse dalle credenziali del dominio. Come possono evitare di dover immettere queste credenziali ogni volta che effettuano una connessione dati?

• Power BI offre la funzionalità Power BI Personal Gateway, che consente di creare credenziali per più origini dati diverse e quindi usare automaticamente le credenziali corrette quando si accede a ognuna di tali origini dati. Per altre informazioni, vedere Power BI Personal Gateway.

Quali porte vengono usate dal gateway dati locale e dal gateway personale? Ci sono nomi di dominio che devono essere consentiti a scopo di connettività?

• La risposta dettagliata a questa domanda è disponibile nella pagina corrispondente al collegamento seguente: Porte del gateway

Quando si usa il gateway dati locale, come si usano le chiavi di ripristino e dove sono archiviate? Ci sono indicazioni per una gestione sicura delle credenziali?

• Durante l'installazione e la configurazione del gateway, l'amministratore digita una chiave di ripristino del gateway. Tale chiave di ripristino viene usata per generare una chiave simmetrica AES complessa. Viene creata contemporaneamente anche una chiave asimmetrica RSA.

  Queste chiavi generate (RSA e AES) vengono archiviate in un file all'interno del computer locale. Anche questo file è crittografato. Il contenuto del file può essere decrittografato solo da quel computer Windows e solo da quell'account del servizio gateway.

  Quando un utente immette le credenziali dell'origine dati nell'interfaccia utente del servizio Power BI, le credenziali vengono crittografate con la chiave pubblica nel browser. Il gateway decrittografa le credenziali usando la chiave privata RSA e le crittografa nuovamente con una chiave simmetrica AES prima di archiviarli nel servizio Power BI. Con questo processo, il servizio Power BI non ha mai accesso ai dati non crittografati.

Quali protocolli di comunicazione vengono usati dal gateway dati locale e come vengono protetti?

• Il gateway supporta i due protocolli di comunicazione seguenti:

  • AMQP 1.0 - TCP + TLS: questo protocollo richiede che le porte 443, 5671-5672 e 9350-9354 siano aperte per le comunicazioni in uscita. Questo protocollo è preferibile, perché ha un overhead di comunicazione più basso.

  • HTTPS - WebSocket su HTTPS + TLS: questo protocollo usa solo la porta 443. L'avvio di WebSocket viene attivato da un unico messaggio HTTP CONNECT. Dopo che il canale è stato stabilito, la comunicazione è essenzialmente TCP + TLS. È possibile imporre al gateway di usare questo protocollo modificando un'impostazione descritta nell'articolo Gateway dati locali.

Qual è il ruolo della Rete di distribuzione dei contenuti di Azure in Power BI?

• Come affermato in precedenza, Power BI usa la Rete di distribuzione dei contenuti di Azure per distribuire in modo efficiente i file e i contenuti statici necessari agli utenti in base alle impostazioni locali geografiche. Per un livello di dettaglio maggiore, il servizio Power BI usa più reti di distribuzione dei contenuti per distribuire in modo efficiente i file e i contenuti statici necessari agli utenti tramite la rete Internet pubblica. I file statici includono download di prodotti (ad esempio Power BI Desktop, gateway dati locale o app Power BI da diversi provider di servizi indipendenti), file di configurazione del browser usati per avviare e stabilire le connessioni successive con il servizio Power BI, nonché la pagina iniziale di accesso protetto a Power BI.

  In base alle informazioni specificate durante la connessione iniziale al servizio Power BI, il browser dell'utente contatta la rete di distribuzione dei contenuti di Azure specificata (o, per alcuni file, il WFE) per scaricare la raccolta di file comuni specifici, necessari per consentire l'interazione del browser con il servizio Power BI. Per l'intera durata della sessione del browser del servizio Power BI, la pagina del browser include quindi il token Microsoft Entra, le informazioni sulla sessione, il percorso del cluster back-end associato e la raccolta di file scaricati dalla rete CDN di Azure e dal cluster Web front-end.

Per gli oggetti visivi Power BI, Microsoft esegue valutazioni sulla sicurezza o la privacy del codice dell'oggetto visivo personalizzato prima di pubblicare gli elementi nella raccolta?

• No. È responsabilità del cliente esaminare il codice dell'oggetto visivo personalizzato per determinare se possa essere ritenuto affidabile. L'intero codice dell'oggetto visivo personalizzato viene gestito in un ambiente sandbox per evitare che qualsiasi codice fuori controllo di un oggetto visivo personalizzato possa compromettere il resto del servizio Power BI.

Esistono altri oggetti visivi di Power BI che inviano informazioni all'esterno della rete del cliente?

• Sì. Gli oggetti visivi Bing Map ed ESRI trasmettono i dati degli oggetti visivi che usano tali servizi all'esterno del servizio Power BI.

Per le app modello, Microsoft esegue una valutazione della sicurezza o della privacy dell'app modello prima di pubblicare elementi nella raccolta?

• No. L'autore dell'app è responsabile del contenuto, mentre è responsabilità del cliente esaminare e determinare se considerare attendibile l'autore dell'app modello.

Sono disponibili app modello che possono inviare informazioni all'esterno della rete del cliente?

• Sì. È responsabilità del cliente esaminare l'informativa sulla privacy dell'editore e determinare se installare l'app modello nel tenant. L'editore deve informare il cliente sul comportamento e sulle funzionalità dell'app.

Come viene gestita la sovranità dei dati? È possibile eseguire il provisioning dei tenant in data center situati in aree geografiche specifiche, affinché i dati restino all'interno dei confini del paese o della regione?

• Alcuni clienti di determinate aree geografiche hanno l'opzione di creare un tenant in un cloud nazionale/regionale, in cui le operazioni di elaborazione e archiviazione dei dati vengono mantenute separate rispetto a tutti gli altri data center. I cloud nazionali/regionali sono caratterizzati da un tipo di sicurezza leggermente diverso perché il servizio Power BI del cloud nazionale/regionale viene eseguito da un trustee dei dati separato per conto di Microsoft.

  In alternativa, i clienti possono anche configurare un tenant in un'area specifica. Tuttavia, tali tenant non dispongono di un trustee di dati separato da Microsoft. Il prezzo del servizio Power BI per i cloud nazionali/regionali è diverso da quello del servizio a pagamento disponibile a livello generale. Per altre informazioni sulla disponibilità del servizio Power BI per i cloud nazionali/regionali, vedere Cloud nazionali/regionali di Power BI.

In che modo Microsoft tratta le connessioni dei clienti che dispongono di sottoscrizioni di Power BI Premium? Si tratta di connessioni diverse rispetto a quelle stabilite per il servizio Power BI non Premium?

• Le connessioni stabilite per i clienti con sottoscrizioni di Power BI Premium implementano un processo di autorizzazione Microsoft Entra Business to Business (B2B) usando Microsoft Entra ID per abilitare il controllo di accesso e autorizzazione. Power BI gestisce le connessioni provenienti dai sottoscrittori di Power BI Premium verso le risorse di Power BI Premium esattamente come gestisce qualsiasi altro utente di Microsoft Entra.

Come funziona l'autenticazione lato server in WFE?

• La sequenza di autenticazione utente per l'autenticazione lato servizio avviene come descritto nella procedura e nelle immagini seguenti.

1. L'utente avvia una connessione al servizio Power BI da un browser, digitando l'indirizzo di Power BI nella barra degli indirizzi o selezionando Accesso dalla pagina di marketing di Power BI (https://powerbi.microsoft.com). La connessione si stabilisce tramite TLS 1.2 e HTTPS e tutte le comunicazioni successive tra il browser e il servizio Power BI usano il protocollo HTTPS.

2. Gestione traffico di Azure controlla il record DNS dell'utente per determinare il data center più appropriato (solitamente il più vicino) in cui Power BI viene distribuito e risponde al DNS con l'indirizzo IP del cluster front-end Web a cui deve essere inviato l'utente.

3. Il front-end Web reindirizza poi l'utente alla pagina di accesso di Microsoft Online Services.

4. Dopo l'autenticazione dell'utente, la pagina di accesso reindirizza l'utente al cluster WFE del servizio Power BI più vicino determinato in precedenza con un codice di autenticazione.

5. Il cluster WFE effettua una verifica con Microsoft Entra ID per ottenere un token di sicurezza di Microsoft Entra usando il codice di autenticazione. Quando Microsoft Entra ID restituisce l'autenticazione corretta dell'utente e restituisce un token di sicurezza Microsoft Entra, il cluster WFE consulta il servizio globale di Power BI, che gestisce un elenco di tenant e i relativi percorsi del cluster back-end di Power BI e determina il cluster del servizio back-end di Power BI che contiene il tenant dell'utente. Il cluster WFE restituisce quindi una pagina dell'applicazione al browser dell'utente con le informazioni di sessione, accesso e routing necessarie per l'operazione.

6. Ora, quando il browser del client richiede i dati dei clienti, invierà richieste all'indirizzo del cluster back-end con il token di accesso Microsoft Entra nell'intestazione Autorizzazione. Il cluster back-end di Power BI legge il token di accesso di Microsoft Entra e convalida la firma per assicurarsi che l'identità per la richiesta sia valida. Il token di accesso di Microsoft Entra avrà una data di scadenza impostata in base ai criteri di Microsoft Entra e, per mantenere la sessione corrente, il client Power BI nel browser dell'utente effettuerà richieste periodiche per rinnovare il token di accesso prima della scadenza.

Risorse aggiuntive

Per altre informazioni su Power BI, vedere le risorse seguenti.

• Introduzione a Power BI Desktop
• Panoramica dell'API REST di Power BI
• Riferimento all'API di Power BI
• Gateway dati locale
• Cloud nazionali/regionali di Power BI
• Power BI Premium
• Panoramica dell'accesso Single Sign-On (SSO) per i gateway in Power BI