White paper sulla sicurezza di 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 (noti in precedenza come set di dati) e visualizzazioni. Con Power BI è possibile connettersi a molte origini dati diverse, combinare e modellare i dati da tali connessioni, quindi creare report e dashboard che possono essere condivisi con altri utenti.

Scrittori: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculbru, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheienberg, 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 Petculeau, Amir Netz, Sergei Gundorov

Si applica a: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI per dispositivi mobili.

Nota

È possibile salvare o stampare il white paper selezionando Stampa dal browser, quindi selezionando Salva come PDF.

Introduzione

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 molte origini dati diverse, combinare e modellare i dati da tali 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, un aumento della domanda di clienti per 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 è cambiata da un inondamento a un'inondazione e con la nuova superficie esposta fornita da essa, più aziende 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 doubly importanti.

Le basi precedenti del modello di sicurezza BI , ovvero la sicurezza a livello di oggetto e a livello di riga, pur ancora importante, 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 lo affidano alle loro informazioni più sensibili.

Tutto inizia con la fondazione. Dopo un periodo approssimativo all'inizio degli anni '2000, Microsoft ha effettuato enormi investimenti per risolvere le sue vulnerabilità di sicurezza e negli ultimi decenni ha creato uno stack di sicurezza forte che va fino a fondo come il kernel bios su chip del computer ed estende fino alle esperienze degli utenti finali. Questi investimenti approfonditi continuano 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 affidate alla protezione di Microsoft, l'azienda ora possiede lo stack di sicurezza più avanzato nel settore tecnologico ed è ampiamente considerato leader globale nella lotta contro gli attori malintenzionati.

Power BI si basa su questa solida base. Usa lo stesso stack di sicurezza che ha ottenuto azure il diritto di 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 questi, offre sicurezza tramite misure di sicurezza 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 connettono e come si connettono?Come possiamo controllare le connessioni?
• Come vengono archiviati i dati?Come viene crittografato?Quali controlli sono presenti sui dati?
• Ricerca per categorie controllare e proteggere i dati sensibili?Ricerca per categorie assicurarsi che questi dati non possano trapelare all'esterno dell'organizzazione?
• Ricerca per categorie controllare chi esegue le operazioni?Ricerca per categorie reagire rapidamente se è presente 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 Enterprise. Per la posizione dell'elaborazione dei dati, fare riferimento alla posizione delle condizioni per il trattamento dei dati nelle Condizioni per i Servizi online Microsoft e all'addendum per la protezione dei dati. Per informazioni sulla conformità, il Centro protezione Microsoft è la risorsa primaria per Power BI. Il team di Power BI sta lavorando duramente per offrire ai propri clienti le innovazioni e la produttività più recenti. Altre informazioni sulla conformità nelle offerte di conformità Microsoft.

L'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, riducendo al contempo i costi di sviluppo. Ulteriori informazioni in Procedure Microsoft Security Development Lifecycle.

Architettura di Power BI

Il servizio Power BI si basa su Azure, la piattaforma di cloud computing di Microsoft. Power BI è attualmente distribuito in molti data center in tutto il mondo. Esistono molte distribuzioni attive rese disponibili ai clienti nelle aree gestite da tali data center e un numero uguale di distribuzioni passive che fungono da backup per ogni distribuzione attiva.

Cluster front-end Web (WFE)

Il cluster WFE fornisce al browser dell'utente il contenuto iniziale della pagina HTML sul caricamento del sito e puntatori a rete CDN contenuto usato 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 Azure. Quando gli utenti tentano di connettersi al servizio Power BI, il servizio DNS del client può comunicare con il Gestione traffico di Azure per trovare il data center più appropriato (in genere più vicino) con una distribuzione di Power BI. Per altre informazioni su questo processo, vedere Metodo di routing del traffico delle prestazioni per Gestione traffico di Azure.

Le risorse statiche, ad esempio *.js, *.css e i file di immagine, vengono archiviati principalmente in un rete per la distribuzione di contenuti di Azure (rete 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 il 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 una volta esauriti i limiti di scalabilità verticale e orizzontale di un singolo cluster.

Ogni cluster back-end è con 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 a una sottoscrizione di 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. Vedere sopra. Ciò garantisce un migliore isolamento, allocazione delle risorse, supporto, isolamento della sicurezza e scalabilità dell'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 è uno). 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 Da Azure Service Fabric. set di scalabilità di macchine virtuali e Service Fabric consentono un aumento rapido e doloroso 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: servizi di bilanciamento 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 . Qualsiasi autenticazione viene eseguita tramite l'integrazione con Microsoft Entra ID (noto in precedenza come Azure Active Directory) esclusivamente.

Qualsiasi richiesta che arriva all'infrastruttura di Power BI Premium passa prima ai nodi front-end, ovvero 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 funzionalità di Power BI Premium.

Power BI per dispositivi mobili

Power BI per dispositivi mobili è una raccolta di app progettate per le tre piattaforme per dispositivi mobili principali: 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 la comunicazione dei dispositivi, tutte le applicazioni Power BI per dispositivi mobili comunicano con il servizio Power BI e usano le stesse sequenze di connessione e autenticazione 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 (CBA) per Power BI per dispositivi mobili, in base alla piattaforma dei 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

Power BI per dispositivi mobili le app comunicano attivamente con il servizio Power BI. I dati di telemetria vengono usati per raccogliere statistiche di utilizzo delle app per dispositivi mobili e dati simili, trasmessi ai servizi usati per monitorare l'utilizzo e l'attività; nessun dato del cliente viene inviato con dati di telemetria.

L'applicazione Power BI archivia i dati nel dispositivo che facilitano l'uso dell'app:

• Microsoft Entra ID e token di aggiornamento vengono archiviati in un meccanismo sicuro nel dispositivo, usando misure di sicurezza standard del 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 le quali Power BI per dispositivi mobili è disponibile il supporto di Intune. Con Intune abilitato e configurato, i dati nel dispositivo mobile vengono crittografati e l'applicazione Power BI stessa 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 di Microsoft first party (ad esempio Microsoft Authenticator) e vengono gestiti da Microsoft Authentication Library (MSAL).

Power BI per dispositivi mobili i dati memorizzati nella cache vengono eliminati quando l'app viene rimossa, quando l'utente si disconnette da Power BI per dispositivi mobili 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 dashboard e report a cui si accede 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 al servizio Power BI è costituita da una serie di richieste, risposte e reindirizzamenti 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 utente in Power BI, che segue il flusso di concessione del codice di autenticazione di Microsoft Entra. Per altre informazioni sulle opzioni per i modelli di autenticazione utente di un'organizzazione (modelli di accesso), vedere Scelta di un modello di accesso per Microsoft 365.

Sequenza di autenticazione

La sequenza di autenticazione utente per il servizio Power BI viene eseguita come descritto nei passaggi seguenti, illustrati nell'immagine che li segue.

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

2. Il Gestione traffico di Azure controlla il record DNS dell'utente per determinare il data center più appropriato (in genere più vicino) in cui viene distribuito Power BI e risponde al DNS con l'indirizzo IP del cluster WFE a cui inviare 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 di Microsoft Entra si iscrive per servizio 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 eseguendo il mapping del paese o dell'area geografica selezionata 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 area geografica principale), tranne nei casi in cui le organizzazioni usano distribuzioni multi-geografiche.

Più aree geografiche (multi-geo)

Alcune organizzazioni hanno una presenza globale e possono richiedere servizio Power BI in più aree geografiche di Azure. Ad esempio, un'azienda può avere la sede centrale nel 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 inattivi nel recinto geografico 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.

Vedere Configurare il supporto multi-geografico per Power BI Premium per altre informazioni sulla creazione e la gestione di distribuzioni di Power BI che si estendono su più aree geografiche di Azure.

Aree e data center

servizio Power BI sono disponibili in aree geografiche di Azure specifiche, come descritto in Centro protezione Microsoft. Per altre informazioni sulla posizione in cui 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 fornisce anche data center per le entità sovrane. Per altre informazioni sulla disponibilità di 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 usato per rendere persistenti i dati degli artefatti di Power BI, mentre 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 in database SQL di Azure vengono crittografati completamente usando la tecnologia Transparent Data Encryption (TDE) di Azure SQL. I dati dei clienti archiviati nell'archivio BLOB di Azure vengono crittografati usando Archiviazione di Azure Crittografia.

Facoltativamente, le organizzazioni possono usare Power BI Premium per usare le proprie chiavi per crittografare i dati inattivi importati in un modello semantico. Questo approccio viene spesso descritto come bring your own key (BYOK). L'uso di BYOK consente di garantire che, anche in caso di errore dell'operatore di servizio, i dati dei clienti non vengano esposti, ovvero qualcosa che non può essere facilmente ottenuto 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
Import	Sì
DirectQuery	No
Connessione live	No
Composito	Se contiene un'origine dati di importazione
Streaming	Se configurata 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, tocca questi dati. 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 dell'importazione, un utente stabilisce una connessione in base all'accesso dell'utente e accede ai dati con le credenziali. Dopo la pubblicazione del modello semantico nella 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 nei 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, le credenziali preconfigurate 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 dati quando un utente visualizza i dati. Se usato 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 a 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 OLS è configurata, il servizio Power BI applicherà tale 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 vedranno i dati per cui 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 polimorfie, eseguono la logica di trasformazione sui dati e quindi lo usano in un modello di destinazione per l'uso 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 potrebbero non 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 prendendo la proprietà di esso.

Ogni origine dati configurata è associata a una tecnologia client per l'accesso a tale origine dati. 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 transito sopra.

Quando le origini dati specificate dal cliente richiedono credenziali per l'accesso, il proprietario o l'autore del flusso di dati li 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 protetto. Archiviazione crittografia è abilitata nei contenitori di archiviazione BLOB per proteggere i dati mentre sono inattivi. Vedere la sezione Dati inattivi di seguito. Gli utenti possono tuttavia configurare il proprio account di archiviazione associato alla propria sottoscrizione di Azure. In questo caso, a un'entità di 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 migliorare le prestazioni. 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 l'utente 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 chiamati impaginati perché sono formattati per adattarsi bene a una 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. Le espressioni vengono ampiamente usate in Power BI Generatore report report impaginati 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 che un utente deve autenticare e autorizzare nello stesso modo descritto nella sezione Autenticazione nel servizio Power BI precedente.

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

In Power BI Premium, il runtime di servizio Power BI fornisce un ambiente di esecuzione isolato in modo 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 del report. La sandbox non comunica direttamente con alcuna origine dati, ma comunica con il processo attendibile per richiedere i dati e 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 di incorporamento di artefatti di Power BI nelle applicazioni Web e nei portali: incorporamento per l'organizzazione e incorporamento 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 usando messaggi POST.

In uno scenario di incorporamento per l'organizzazione , gli utenti di Microsoft Entra accedono ai propri contenuti di Power BI tramite portali personalizzati dalle aziende e dai token di accesso. Tutti i criteri e le funzionalità di Power BI descritti in questo documento, ad esempio la sicurezza a livello di riga e la sicurezza a livello di oggetto (OLS) vengono applicati automaticamente a tutti gli utenti indipendentemente dal fatto che accedono 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 e elementi di Power BI (dashboard, report, modelli semantici e altri). È responsabilità di un servizio back-end ISV autenticare gli utenti finali e decidere quali artefatti e quale livello di accesso è appropriato 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 le API client di Power BI, aggiungono automaticamente il token di incorporamento crittografato alle richieste di Power BI come intestazione Authorization: EmbedToken . In base a questa intestazione, Power BI applichererà 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 dell'entità servizio delegati dall'utente che l'entità servizio Microsoft Entra.

L'analisi incorporata di Power BI e le relative API REST supportano tutte le funzionalità di isolamento della rete di Power BI descritte in questo articolo: Ad esempio, Tag del servizio e collegamento privato.

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 relativi alla 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 i 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 rendere operativo il modello di Machine Learning 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 alla 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

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

collegamento privato assicura che gli utenti di Power BI usino il backbone della rete privata Microsoft quando si passano alle risorse nel servizio Power BI.

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

• collegamento privato garantisce che il traffico venga propagato sul 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à di rete virtuale (anteprima - presto disponibile)

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) elimineranno il sovraccarico dell'installazione e del monitoraggio dei gateway dati locali per la connessione alle origini dati associate a una rete virtuale. Tuttavia, seguiranno 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 Power BI (o uno degli altri servizi cloud supportati) avvia una query e invia la query, i dettagli dell'origine dati e le credenziali al servizio di rete virtuale Power Platform .

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 ottiene la query e si connette alle origini dati con tali credenziali.

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 esegue il push sicuro dei dati dal contenitore al servizio cloud Power BI.

Questa funzionalità sarà presto disponibile in anteprima pubblica.

Entità servizio

Power BI supporta l'uso di entità servizio. Archiviare tutte le credenziali dell'entità servizio usate per crittografare o accedere a Power BI in un insieme di credenziali delle chiavi, assegnare criteri di accesso appropriati all'insieme di credenziali ed esaminare regolarmente le autorizzazioni di accesso.

Per altri dettagli, vedere Automatizzare le attività dell'area di lavoro Premium e del modello semantico con 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 file Excel, PowerPoint, PDF, Word o pbix , per garantire la protezione dei dati anche quando esce da Power BI.
• È facile classificare e proteggere i 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 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 durante l'incorporamento del 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 datamarts nel servizio Power BI verranno applicate al nuovo contenuto creato sopra a tali modelli semantici e ai datamarts.
• 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 nei 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 automatica della riservatezza downstream nella servizio Power BI garantisce che quando un'etichetta in un modello semantico o un datamart viene applicata o modificata, l'etichetta 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 Microsoft Purview (DLP) per Power BI (anteprima)

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 possono aiutarli a soddisfare i requisiti di conformità delle normative governative o del settore, ad esempio il GDPR (regolamento generale sulla protezione dei dati dell'Unione europea) o il CCPA (California Consumer Privacy Act) e assicurarsi che i dati in Power BI siano gestiti.

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 di prevenzione della perdita dei dati 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 è un proprietario di un modello semantico, è possibile eseguire l'override di un criterio e impedire che il modello semantico 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 Power BI.

app Microsoft Defender per il cloud per Power BI

Microsoft Defender per il cloud Apps è uno dei principali broker di sicurezza per l'accesso al cloud al mondo, denominato leader nel Magic Quadrant di Gartner per il mercato casB (Cloud Access Security Broker). Defender per il cloud Le app vengono usate 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 per il cloud App, 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 delle app Defender per il cloud e da azioni rischiose, ad esempio il download di dati contrassegnati con un'etichetta di riservatezza "Estremamente riservato", può essere bloccata immediatamente.
• Analizzare l'attività utente di Power BI con il log attività delle app Defender per il cloud. Il log attività di Defender per il cloud Apps include l'attività di Power BI acquisita 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 applicare, modificare e rimuovere l'etichetta. Amministrazione possono sfruttare i filtri avanzati delle app Defender per il cloud 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à delle app Defender per il cloud può essere sfruttata per definire regole personalizzate, per consentire di rilevare il comportamento dell'utente che devia dalla norma e anche di agire automaticamente, se sembra troppo pericoloso.
• Usare il rilevamento anomalie predefinito delle app Defender per il cloud. I criteri di rilevamento anomalie delle app di Defender per il cloud 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 delle app di Defender per il cloud. Defender per il cloud App fornisce 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 pertinenti di 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 delle app Microsoft Defender per il cloud 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 le funzionalità che potrebbero non essere state ancora rilasciate, le sequenze temporali di recapito potrebbero cambiare e le funzionalità previste potrebbero essere rilasciate dopo marzo 2021 o potrebbero non essere rilasciate affatto. Per altre informazioni sulle anteprime, vedere le Condizioni per i 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

Le domande seguenti sono domande di sicurezza e risposte comuni per Power BI. Questi sono organizzati in base al momento in cui sono stati aggiunti a questo white paper, per facilitare la possibilità di trovare rapidamente nuove domande e risposte quando questo documento viene aggiornato. Le domande più recenti vengono aggiunte alla fine di questo elenco.

In che modo gli utenti si connettono e ottengono l'accesso alle origini dati durante l'uso di Power BI?

• Power BI gestisce le credenziali per le origini dati per ogni utente per le credenziali cloud o per la connettività tramite un gateway personale. Le origini dati gestite da un gateway dati locale possono essere condivise tra le aziende e le autorizzazioni per queste origini dati possono essere gestite dal gateway Amministrazione. 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 dell'utente e accede ai dati con le credenziali. Dopo la pubblicazione del modello semantico in 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, l'origine dati viene connessa direttamente usando credenziali preconfigurate, la credenziale preconfigurata viene usata 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 dati quando l'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 usando 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), la servizio Power BI applicherà tale 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 l'utente non dispone 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 definire filtri all'interno del ruolo.

  La sicurezza a livello di oggetto 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 alla sicurezza 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?

• Tutti i dati richiesti e trasmessi da Power BI vengono crittografati in transito tramite HTTPS (tranne quando l'origine dati scelta dal cliente non supporta HTTPS) per connettersi dall'origine dati all'servizio Power BI. Viene stabilita una connessione sicura con il provider di dati e solo una volta stabilita tale connessione attraversa la rete.

In che modo Power BI memorizza nella cache report, dashboard o dati del modello ed è sicuro?

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

I client memorizzano nella cache i dati della pagina Web in locale?

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

Informazioni sulla sicurezza basata sui ruoli, sulla condivisione di report o dashboard e sulle connessioni dati? Come funziona in termini di accesso ai dati, visualizzazione del dashboard, accesso ai report o aggiornamento?

• Per le origini dati abilitate per la sicurezza a livello di ruolo, se un dashboard, un report o un modello di dati viene condiviso con altri utenti tramite Power BI, i dati sono quindi disponibili per gli utenti con cui è condiviso per visualizzare e interagire. Power BI non riautentica gli utenti rispetto all'origine originale dei dati. Dopo il caricamento dei dati in Power BI, l'utente che ha eseguito l'autenticazione sui dati di origine è responsabile della gestione di quali altri utenti e gruppi possono visualizzare i dati.

  Quando vengono effettuate connessioni dati a un'origine dati con supporto per la sicurezza a livello di riga, ad esempio un'origine dati di Analysis Services, solo i dati del dashboard vengono memorizzati nella cache in Power BI. Ogni volta che un report o un modello semantico viene visualizzato o accessibile in Power BI che usa dati provenienti dall'origine dati con supporto per la sicurezza a livello di riga, l'servizio Power BI accede all'origine dati per ottenere dati in base alle credenziali dell'utente e, se esistono autorizzazioni sufficienti, i dati vengono caricati nel report o nel modello di dati per tale utente. Se l'autenticazione non riesce, verrà visualizzato 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 Power BI Personal Gateway, una funzionalità che consente agli utenti di creare credenziali per più origini dati diverse, quindi di usare automaticamente tali credenziali quando successivamente accedono a ognuna di queste origini dati. Per altre informazioni, vedere Power BI Personal Gateway.

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

• La risposta dettagliata a questa domanda è disponibile nel collegamento seguente: Porte gateway

Quando si lavora con il gateway dati locale, come vengono usate le chiavi di ripristino e dove vengono archiviate? Che cos'è la gestione sicura delle credenziali?

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

  Tali chiavi generate (RSA e AES) vengono archiviate in un file che si trova nel computer locale. Tale file viene crittografato anche. Il contenuto del file può essere decrittografato solo da quel particolare computer Windows e solo da quel particolare account del servizio gateway.

  Quando un utente immette le credenziali dell'origine dati nell'interfaccia utente 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 che i dati vengano archiviati nella 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 sono 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, poiché presenta un sovraccarico di comunicazione inferiore.

  • HTTPS : WebSocket su HTTPS + TLS: questo protocollo usa solo la porta 443. WebSocket viene avviato da un singolo messaggio HTTP CONNECT. Una volta stabilito il canale, la comunicazione è essenzialmente TCP+TLS. È possibile forzare il gateway a usare questo protocollo modificando un'impostazione descritta nell'articolo sul gateway locale.

Qual è il ruolo di Rete CDN di Azure in Power BI?

• Come accennato in precedenza, Power BI usa l'rete per la distribuzione di contenuti di Azure (rete CDN) per distribuire in modo efficiente il contenuto statico e i file necessari agli utenti in base alle impostazioni locali geografiche. Per approfondire in dettaglio, il servizio Power BI usa più rete CDN per distribuire in modo efficiente i file e i contenuti statici necessari agli utenti tramite Internet pubblico. Questi file statici includono i download dei prodotti (ad esempio Power BI Desktop, il gateway dati locale o le app Power BI da diversi provider di servizi indipendenti), i file di configurazione del browser usati per avviare e stabilire eventuali connessioni successive con il servizio Power BI, nonché la pagina di accesso iniziale di Power BI sicura.

  In base alle informazioni fornite durante una connessione iniziale al servizio Power BI, il browser di un utente contatta il Rete CDN di Azure specificato (o per alcuni file, WFE) per scaricare la raccolta di file comuni specificati necessari per consentire l'interazione del browser con il 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 dal cluster Rete CDN di Azure e WFE, per la durata della sessione del browser servizio Power BI.

Per gli oggetti visivi di Power BI, Microsoft esegue una valutazione della sicurezza o della privacy del codice visivo personalizzato prima della pubblicazione di elementi nella raccolta?

• No. È responsabilità del cliente esaminare e determinare se è necessario affidarsi al codice visivo personalizzato. Tutto il codice visivo personalizzato viene gestito in un ambiente sandbox, in modo che qualsiasi codice errante in un oggetto visivo personalizzato non influisca negativamente sul resto del servizio Power BI.

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

• Sì. Gli oggetti visivi Bing Mappe ed ESRI trasmettono i dati dal servizio Power BI per gli oggetti visivi che usano tali servizi.

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 dei clienti?

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

Che ne dici della sovranità dei dati? È possibile effettuare il provisioning dei tenant nei data center situati in aree geografiche specifiche per garantire che i dati non lascino i confini del paese o dell'area geografica?

• Alcuni clienti in determinate aree geografiche hanno la possibilità di creare un tenant in un cloud nazionale/regionale, in cui l'archiviazione e l'elaborazione dei dati vengono mantenute separate da tutti gli altri data center. I cloud nazionali/regionali hanno un tipo di sicurezza leggermente diverso, poiché un trustee dei dati separato opera il cloud nazionale/regionale servizio Power BI 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. I prezzi per i cloud nazionali/regionali sono diversi dai servizio Power BI commerciali disponibili a livello generale. Per altre informazioni sulla disponibilità di servizio Power BI per i cloud nazionali/regionali, vedere Cloud nazionali/regionali di Power BI.

In che modo Microsoft gestisce le connessioni per i clienti che hanno sottoscrizioni Power BI Premium? Queste connessioni sono diverse da 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 business-to-business (B2B) di Microsoft Entra, usando Microsoft Entra ID per abilitare il controllo di accesso e l'autorizzazione. Power BI gestisce le connessioni dai sottoscrittori di Power BI Premium alle risorse di Power BI Premium esattamente come qualsiasi altro utente di Microsoft Entra.

Come funziona l'autenticazione lato server in WFE?

• L'autenticazione lato servizio della sequenza di autenticazione utente viene eseguita come descritto nei passaggi seguenti, illustrati nell'immagine che li segue.

1. Un utente avvia una connessione al servizio Power BI da un browser digitando l'indirizzo di Power BI nella barra degli indirizzi o selezionando Accedi dalla pagina marketing di Power BI (https://powerbi.microsoft.com). La connessione viene stabilita usando TLS 1.2 e HTTPS e tutte le comunicazioni successive tra il browser e il servizio Power BI usano HTTPS.

2. Il Gestione traffico di Azure controlla il record DNS dell'utente per determinare il data center più appropriato (in genere più vicino) in cui viene distribuito Power BI e risponde al DNS con l'indirizzo IP del cluster WFE a cui inviare l'utente.

3. WFE reindirizza quindi 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 servizio Power BI più vicino determinato in precedenza con un codice di autenticazione.

5. Il cluster WFE 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
• API REST di Power BI - Panoramica
• Informazioni di riferimento su API 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