Pianificazione dell'implementazione di Power BI: protezione delle informazioni per Power BI

Nota

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

Questo articolo descrive le attività di pianificazione correlate all'implementazione della protezione delle informazioni in Power BI. È destinato a:

• Amministratori Power BI: amministratori responsabili della supervisione di Power BI nell'organizzazione. Gli amministratori di Power BI devono collaborare con i team di sicurezza delle informazioni e altri team pertinenti.
• Center of Excellence, team IT e BI: altri responsabili della supervisione di Power BI nell'organizzazione. Potrebbe essere necessario collaborare con gli amministratori di Power BI, i team di sicurezza delle informazioni e altri team pertinenti.

Importante

La protezione delle informazioni e la prevenzione della perdita dei dati (DLP) è un'impresa significativa a livello di organizzazione. L'ambito e l'impatto sono molto più grandi rispetto a Power BI. Questo tipo di iniziativa richiede finanziamenti, definizione delle priorità e pianificazione. Si prevede di coinvolgere diversi team interfunzionali nelle attività di pianificazione, utilizzo e supervisione.

Le attività di etichettatura e classificazione si estendono oltre Power BI e persino gli asset di dati. Le decisioni illustrate in questo articolo si applicano agli asset per l'intera organizzazione, inclusi file ed e-mail, e non solo a Power BI. Questo articolo presenta gli argomenti che si applicano all'etichettatura e alla classificazione in generale, perché prendere decisioni organizzative appropriate è fondamentale per il successo della prevenzione della perdita dei dati in Power BI.

Questo articolo include anche indicazioni introduttive sulla definizione di una struttura di etichette di riservatezza. Tecnicamente, la struttura delle etichette di riservatezza è un prerequisito per l'implementazione delle etichette di riservatezza in Power BI. Lo scopo dell'inclusione di alcune informazioni di base in questo articolo è aiutare a comprendere i vari elementi interessati. È fondamentale collaborare con l'IT per pianificare e implementare la protezione delle informazioni nell'organizzazione.

Scopo delle etichette di riservatezza

L'uso delle etichette di riservatezza di Microsoft Purview Information Protection riguarda la classificazione del contenuto. Si pensi a un'etichetta di riservatezza come a un tag applicato a un elemento, un file, un sito o un asset di dati.

Esistono molti vantaggi per l'uso della protezione delle informazioni. La classificazione e l'etichettatura del contenuto aiutano le organizzazioni a:

• Comprendere dove risiedono i dati sensibili.
• Tenere traccia dei requisiti di conformità esterni e interni.
• Proteggere il contenuto da utenti non autorizzati.
• Informare gli utenti su come gestire in modo responsabile i dati.
• Implementare controlli in tempo reale per ridurre il rischio di perdita di dati.

Per altri casi d'uso per la protezione delle informazioni, vedere Protezione delle informazioni e DLP (casi d'uso comuni).

Suggerimento

Aiuta ricordare che Microsoft Purview Information Protection è il prodotto. Le etichette di riservatezza sono una funzionalità specifica del prodotto.

Un'etichetta di riservatezza è una breve descrizione in testo non crittografato. Concettualmente, è possibile pensare a un'etichetta di riservatezza come a un tag. È possibile assegnare a ogni elemento una sola etichetta, ad esempio un modello semantico di Power BI (precedentemente noto come set di dati) nel servizio Power BI o in ogni file (ad esempio un file di Power BI Desktop).

Un'etichetta ha i seguenti scopi.

• Classificazione: fornisce una classificazione per descrivere il livello di riservatezza.
• Formazione e consapevolezza degli utenti: consente agli utenti di comprendere come usare in modo appropriato il contenuto.
• Criteri: costituisce la base per l'applicazione e l'applicazione di criteri e DLP.

Prerequisiti per la protezione delle informazioni di Power BI

A questo scopo, è necessario aver completato i passaggi di pianificazione a livello di organizzazione descritti nell'articolo Pianificazione della protezione delle informazioni a livello di organizzazione. Prima di procedere, è necessario avere chiarezza su:

• Stato corrente: lo stato corrente di protezione delle informazioni nell'organizzazione. È necessario conoscere se le etichette di riservatezza sono già in uso per i file di Microsoft Office. In questo caso, l'ambito di lavoro per aggiungere Power BI è molto più piccolo rispetto a quando si usa la protezione delle informazioni nell'organizzazione per la prima volta.
• Obiettivi e requisiti : gli obiettivi strategici per implementare la protezione delle informazioni nell'organizzazione. Comprendere gli obiettivi e i requisiti permetterà di seguire le attività di implementazione.

Se la protezione delle informazioni non è usata dall'organizzazione, nella parte restante di questa sezione vengono fornite informazioni utili per collaborare con altri utenti al fine di introdurla.

Se la protezione delle informazioni è attivamente in uso all'interno dell'organizzazione, è consigliabile usare questo articolo per verificare che i prerequisiti siano soddisfatti. Se le etichette di riservatezza sono attivamente in uso, la maggior parte delle attività nelle fasi di implementazione 1-4 (nella sezione successiva) sarà già completa, se non addirittura tutte.

Fasi di implementazione

È consigliabile pianificare un piano di implementazione graduale per implementare e testare la protezione delle informazioni. L'obiettivo di un piano di implementazione graduale è prepararsi a imparare, regolare e iterare man mano che si procede. Il vantaggio è che meno utenti sono interessati durante le fasi iniziali (quando le modifiche sono più probabili), fino a quando la protezione delle informazioni non viene implementata per tutti gli utenti dell'organizzazione.

L'introduzione della protezione delle informazioni è un'impresa significativa. Come descritto nell'articolo Pianificazione della protezione delle informazioni a livello di organizzazione, se l'organizzazione ha già implementato la protezione delle informazioni per i documenti di Microsoft Office, molte di queste attività saranno già completate.

Questa sezione offre una panoramica delle fasi che è consigliabile includere nel piano di implementazione graduale. Dovrebbe dare un senso di cosa aspettarsi. Nella parte restante di questo articolo vengono descritti altri criteri decisionali per gli aspetti chiave che influiscono maggiormente su Power BI.

Fase 1: Pianificare, decidere, preparare

Nella prima fase, concentrarsi sulla pianificazione, sul processo decisionale e sulle attività preparatorie. La maggior parte del resto di questo articolo è incentrata su questa prima fase.

Il prima possibile, chiarire dove verrà eseguito il test iniziale. Questa scelta influirà sulla posizione iniziale di configurazione, pubblicazione e test. Per il test iniziale, è possibile usare un tenant non di produzione (se si ha accesso a uno di questi).

Suggerimento

La maggior parte delle organizzazioni ha accesso a un tenant, quindi può essere difficile esplorare nuove funzionalità in modo isolato. Per le organizzazioni che dispongono di un tenant di sviluppo o test separato, è consigliabile usarlo per la fase di test iniziale. Per altre informazioni sulla gestione dei tenant e su come creare un tenant di valutazione per testare le nuove funzionalità, vedere Configurazione del tenant.

Fase 2: Configurare le risorse utente di supporto

La seconda fase include i passaggi per configurare le risorse per supportare gli utenti. Le risorse includono i criteri di protezione e classificazione dei dati e la pagina di aiuto personalizzata.

È importante disporre di parte della documentazione utente pubblicata in anticipo. È anche importante avvisare in anticipo il team di supporto utenti in modo che sia disponibile.

Fase 3: Configurare le etichette e pubblicare

La terza fase è incentrata sulla definizione di etichette di riservatezza. Quando tutte le decisioni sono state prese, la configurazione non è difficile o dispendiosa in termini di tempo. Le etichette di riservatezza sono configurate nel portale di conformità di Microsoft Purview nell'interfaccia di amministrazione di Microsoft 365.

Fase 4: Pubblicare i criteri delle etichette

Prima di poter usare un'etichetta, è necessario pubblicarla come parte di un criterio di etichetta. I criteri di etichetta consentono a determinati utenti di usare un'etichetta. I criteri di etichetta vengono pubblicati nel portale di conformità di Microsoft Purview nell'interfaccia di amministrazione di Microsoft 365.

Nota

Tutto quanto detto finora è un prerequisito per l'implementazione della protezione delle informazioni per Power BI.

Fase 5: Abilitare le impostazioni del tenant di Power BI

Sono disponibili diverse impostazioni tenant di protezione delle informazioni nel portale di amministrazione di Power BI. Sono necessarie per abilitare la protezione delle informazioni nel servizio Power BI.

Importante

È necessario impostare le impostazioni del tenant dopo aver configurato e pubblicato le etichette nel portale di conformità di Microsoft Purview.

Fase 6: Test iniziali

Nella sesta fase si eseguono test iniziali per verificare che tutto si comporti come previsto. Ai fini dei test iniziali, è consigliabile pubblicare i criteri di etichetta solo per il team di implementazione.

Durante questa fase, assicurarsi di testare:

• File di Microsoft Office
• Elementi di Power BI nel servizio Power BI
• File di Power BI Desktop
• Esportazione di file dal servizio Power BI
• Altri ambiti inclusi nella configurazione, ad esempio siti di Teams o SharePoint

Assicurarsi di controllare la funzionalità e l'esperienza utente usando un Web browser e anche i dispositivi mobili comunemente usati. Aggiornare la documentazione dell'utente di conseguenza.

Importante

Anche se solo alcuni membri del team sono autorizzati a impostare un'etichetta di riservatezza, tutti gli utenti potranno visualizzare le etichette assegnate al contenuto. Se si usa il tenant di produzione, gli utenti potrebbero chiedersi perché vedono le etichette assegnate agli elementi in un'area di lavoro nel servizio Power BI. Essere pronti a supportare e rispondere alle domande dell'utente.

Fase 7: Raccogliere commenti e suggerimenti degli utenti

L'obiettivo di questa fase è ottenere feedback da un piccolo gruppo di utenti chiave. Il feedback deve identificare aree poco chiare, lacune nella struttura delle etichette o problemi tecnici. È anche possibile trovare motivi per migliorare la documentazione dell'utente.

A questo scopo, è necessario pubblicare (o ripubblicare) i criteri di etichetta a un piccolo subset di utenti che siano disposti a fornire commenti e suggerimenti.

Suggerimento

Assicurarsi di includere tempo sufficiente nel piano di progetto. Per le etichette e le impostazioni dei criteri di etichetta, la documentazione del prodotto consiglia di attendere 24 ore per l'applicazione delle modifiche. Questa volta serve per garantire che tutte le modifiche vengano propagate attraverso i servizi correlati.

Fase 8: Rilasciare in modo iterativo

La fase di implementazione è in genere un processo iterativo.

Spesso, l'obiettivo iniziale consiste nell'arrivare a uno stato in cui a tutti i contenuti di Power BI è assegnata un'etichetta di riservatezza. Per raggiungere questo obiettivo, è possibile introdurre criteri di etichetta obbligatori o criteri di etichetta predefiniti. È anche possibile usare le API amministratore di Information Protection per impostare o rimuovere etichette di riservatezza a livello di codice.

È possibile includere gradualmente più gruppi di utenti fino a quando non viene inclusa l'intera organizzazione. Questo processo comporta la ripubblicazione di ogni criterio di etichetta a gruppi di utenti sempre più grandi.

Durante questo processo, assicurarsi di definire le priorità fornendo indicazioni, comunicazioni e formazione agli utenti in modo che comprendano il processo e cosa ci si aspetta.

Fase 9: Monitorare, controllare, regolare, integrare

Ci sono altri passaggi da eseguire dopo l'implementazione iniziale. È necessario disporre di un team principale per monitorare le attività di protezione delle informazioni e ottimizzarle nel tempo. Quando vengono applicate le etichette, sarà possibile valutarne l'utilità e identificare le aree per le modifiche.

Esistono molti aspetti per controllare la protezione delle informazioni. Per altre informazioni, vedere Controllo della protezione delle informazioni e prevenzione della perdita dei dati per Power BI.

Gli investimenti effettuati nella configurazione della protezione delle informazioni possono essere usati nei criteri di prevenzione della perdita dei dati per Power BI, configurati nel portale di conformità di Microsoft Purview. Per altre informazioni, inclusa una descrizione delle funzionalità di prevenzione della perdita dei dati, vedere Prevenzione della perdita dei dati per Power BI.

La protezione delle informazioni può essere usata anche per creare criteri in Microsoft Defender for Cloud Apps. Per altre informazioni, inclusa una descrizione delle funzionalità che potrebbero risultare utili, vedere Defender for Cloud Apps per Power BI.

Elenco di controllo: quando si preparano le fasi di implementazione della protezione delle informazioni, le decisioni e le azioni principali includono:

• Creare un piano di implementazione graduale: definire le fasi per il piano di implementazione. Chiarire quali sono gli obiettivi specifici per ogni fase.
• Identificare dove eseguire il test: determinare dove eseguire il test iniziale. Per ridurre al minimo l'impatto sugli utenti, usare un tenant non di produzione, se possibile.
• Creare un piano di progetto: compilare un piano di progetto che includa tutte le attività chiave, la sequenza temporale stimata e i vari responsabili.

Struttura etichetta di riservatezza

La struttura delle etichette di riservatezza è un prerequisito per l'implementazione delle etichette di riservatezza in Power BI. Questa sezione include alcune informazioni di base che consentono di comprendere cosa aspettarsi se si è coinvolti nella creazione della struttura dell'etichetta.

Questa sezione non è un elenco completo di tutte le possibili considerazioni sulle etichette di riservatezza per tutte le applicazioni possibili. Si concentra invece su considerazioni e attività che influiscono direttamente sulla classificazione dei contenuti Power BI. Assicurarsi di collaborare con altri stakeholder e amministratori di sistema per prendere decisioni appropriate per tutte le applicazioni e i casi d'uso.

La base per l'implementazione della protezione delle informazioni inizia con un set di etichette di riservatezza. L'obiettivo finale è creare un set di etichette di riservatezza chiare e semplici da usare per gli utenti.

La struttura delle etichette di riservatezza usata in un'organizzazione rappresenta una tassonomia di etichetta. Viene anche comunemente definita tassonomia di classificazione dei dati perché l'obiettivo è classificare i dati. A volte viene chiamata definizione dello schema.

Non esiste un set di etichette standard o predefinito. Ogni organizzazione deve definire e personalizzare un set di etichette in base alle proprie esigenze. Il processo di arrivo al set corretto di etichette implica una vasta collaborazione. Richiede una pianificazione ponderata per garantire che le etichette soddisfino obiettivi e requisiti. Tenere presente che le etichette verranno applicate a più del semplice contenuto di Power BI.

Suggerimento

La maggior parte delle organizzazioni inizia assegnando etichette ai file di Microsoft Office. Si evolvono quindi per classificare altri contenuti, ad esempio elementi e file di Power BI.

Una struttura di etichette include:

• Etichette: le etichette formano una gerarchia. Ogni etichetta indica il livello di riservatezza per un elemento, un file o un asset di dati. È consigliabile creare da tre a sette etichette. Le etichette devono cambiare raramente.
• Etichette secondarie: le etichette secondarie indicano variazioni nella protezione o nell'ambito all'interno di un'etichetta specifica. Includendole in criteri di etichetta diversi, è possibile definire l'ambito delle etichette secondarie a un determinato set di utenti o agli utenti coinvolti in un progetto specifico.

Suggerimento

Anche se le etichette secondarie offrono flessibilità, devono essere usate con moderazione e solo per soddisfare i requisiti critici. La creazione di troppe etichette secondarie comporta una maggiore gestione. Possono anche sovraccaricare gli utenti con troppe opzioni.

Le etichette formano una gerarchia, a partire dalla classificazione meno sensibile alla classificazione più sensibile.

A volte il contenuto di Power BI include dati che si estendono su più etichette. Ad esempio, un modello semantico può contenere informazioni sull'inventario dei prodotti (utilizzo interno generale) e i dati delle vendite del trimestre corrente (Con restrizioni). Quando si sceglie l'etichetta da assegnare al modello semantico di Power BI, è consigliabile insegnare agli utenti di applicare l'etichetta più restrittiva.

Suggerimento

La sezione successiva descrive i criteri di classificazione e protezione dei dati che possono fornire agli utenti indicazioni su quando usare ogni etichetta.

Importante

L'assegnazione di un'etichetta o di un'etichetta secondaria non influisce direttamente sull'accesso al contenuto di Power BI nel servizio Power BI. L'etichetta fornisce invece una categoria utile che può guidare il comportamento dell'utente. I criteri di prevenzione della perdita dei dati possono anche essere basati sull'etichetta assegnata. Tuttavia, non viene modificato il modo in cui viene gestito l'accesso al contenuto di Power BI, tranne quando un file viene crittografato. Per altre informazioni, vedere Uso della protezione della crittografia.

Assicurarsi di essere chiari con le etichette create perché è difficile rimuoverle o eliminarle dopo aver superato la fase di test iniziale. Poiché le etichette secondarie possono essere (facoltativamente) usate per un set specifico di utenti, possono cambiare più spesso delle etichette stesse.

Ecco alcune procedure consigliate per la definizione di una struttura di etichette.

• Usare termini intuitivi, non ambigui: la chiarezza è importante per assicurarsi che gli utenti sappiano cosa scegliere quando classificano i dati. Ad esempio, avere un'etichetta Top secret e un'altra etichetta Altamente riservato può creare ambiguità.
• Creare un ordine gerarchico logico: l'ordine delle etichette è fondamentale per assicurarsi che tutto funzioni al meglio. Tenere presente che l'ultima etichetta nell'elenco è la più sensibile. L'ordine gerarchico, in combinazione con termini ben selezionati, deve essere logico e intuitivo per consentire agli utenti di usarlo. Una gerarchia chiara renderà anche i criteri più facili da creare e gestire.
• Creare solo alcune etichette che si applicano all'interno dell'organizzazione: la presenza di troppe etichette tra cui scegliere gli utenti creerà confusione. Comporterà anche una selezione dell'etichetta meno accurata. È consigliabile creare solo alcune etichette per il set iniziale.
• Usare nomi generici significativi: evitare di usare il gergo di settore o gli acronimi nei nomi delle etichette. Ad esempio, invece di creare un'etichetta denominata Informazioni personali, usare nomi come Con restrizioni elevate o Altamente riservato.
• Usare termini facilmente traducibili in altre lingue: per le organizzazioni globali con operazioni in più paesi/aree geografiche, è importante scegliere termini di etichetta che non confondano o presentino ambiguità quando vengono tradotti in altre lingue.

Suggerimento

Se ci si trova a pianificare molte etichette altamente specifiche, tornare indietro e rivalutare l'approccio. La complessità può causare confusione negli utenti, ridurre l'adozione e rendere meno efficace la protezione delle informazioni. È consigliabile iniziare con un set iniziale di etichette (o usare quello che si ha già). Dopo aver fatto ulteriore esperienza, espandere con cautela il set di etichette aggiungendone di più specifiche quando necessario.

Elenco di controllo: quando si pianifica la struttura delle etichette di riservatezza, le decisioni chiave e le azioni includono:

• Definire un set iniziale di etichette di riservatezza: creare un set iniziale compreso tra tre e sette etichette di riservatezza. Assicurarsi che abbiano un uso ampio per un'ampia gamma di contenuti. Pianificare l'iterazione nell'elenco iniziale durante la finalizzazione dei criteri di classificazione e protezione dei dati.
• Determinare se sono necessarie etichette secondarie: decidere se è necessario usare etichette secondarie per una delle etichette.
• Verificare la localizzazione dei termini dell'etichetta: se le etichette verranno tradotte in altre lingue, i parlanti nativi devono confermare che le etichette localizzate trasmettano il significato previsto.

Ambito etichetta di riservatezza

Un ambito di etichetta di riservatezza limita l'uso di un'etichetta. Anche se non è possibile specificare direttamente Power BI, è possibile applicare etichette a vari ambiti. Gli ambiti possibili includono:

• Elementi (ad esempio elementi pubblicati nel servizio Power BI e file ed e-mail)
• Gruppi e siti (ad esempio un canale di Teams o un sito di SharePoint)
• Asset di dati con schema (origini supportate registrate in Microsoft Purview Data Map)

Importante

Non è possibile definire un'etichetta di riservatezza solo con un ambito di Power BI. Anche se esistono alcune impostazioni che si applicano in modo specifico a Power BI, l'ambito non è uno di esse. L'ambito degli elementi viene usato per il servizio Power BI. Le etichette di riservatezza vengono gestite in modo diverso dai criteri DLP, descritti nell'articolo Prevenzione della perdita dei dati per la pianificazione di Power BI, in quanto alcuni tipi di criteri di prevenzione della perdita dei dati possono essere definiti in modo specifico per Power BI. Se si intende usare l'ereditarietà delle etichette di riservatezza dalle origini dati in Power BI, esistono dei requisiti specifici per l'ambito dell'etichetta.

Gli eventi correlati alle etichette di riservatezza vengono registrati in Esplora attività. I dettagli registrati di questi eventi saranno notevolmente più avanzati quando l'ambito è più ampio. Si sarà anche più preparati a proteggere i dati in un'ampia gamma di applicazioni e servizi.

Quando si definisce il set iniziale di etichette di riservatezza, è consigliabile rendere disponibile il set iniziale di etichette a tutti gli ambiti. Ciò è dovuto al fatto che ci può essere confusione per gli utenti nel vedere etichette diverse in applicazioni e servizi diversi. Nel corso del tempo, tuttavia, è possibile individuare casi d'uso per etichette secondarie più specifiche. Tuttavia, è più sicuro iniziare con un set coerente e semplice di etichette iniziali.

L'ambito dell'etichetta viene impostato nel portale di conformità di Microsoft Purview quando l'etichetta è configurata.

Elenco di controllo: quando si pianifica l'ambito dell'etichetta, le decisioni chiave e le azioni includono:

• Decidere l'ambito dell'etichetta: discutere e decidere se ognuna delle etichette iniziali verrà applicata a tutti gli ambiti.
• Esaminare tutti i prerequisiti: analizzare i prerequisiti e i passaggi di configurazione necessari per ogni ambito che si intende usare.

Uso della protezione della crittografia

Sono disponibili più opzioni per la protezione con un'etichetta di riservatezza.

• Crittografia: le impostazioni di crittografia riguardano file o e-mail. Ad esempio, è possibile crittografare un file di Power BI Desktop.
• Contrassegni: fa riferimento a intestazioni, piè di pagina e filigrane. I contrassegni sono utili per i file di Microsoft Office, ma non vengono visualizzati nel contenuto di Power BI.

Suggerimento

In genere, quando un utente fa riferimento a un'etichetta come protetta, sta parlando della crittografia. Potrebbe essere sufficiente crittografare solo le etichette di livello superiore, ad esempio Con restrizioni e Con restrizioni elevate.

La crittografia è un modo per codificare in modo crittografico le informazioni. La crittografia presenta diversi vantaggi chiave.

• Solo gli utenti autorizzati (ad esempio gli utenti interni all'interno dell'organizzazione) possono aprire, decrittografare e leggere un file protetto.
• La crittografia viene mantenuta per un file protetto, anche quando il file viene inviato all'esterno dell'organizzazione o viene rinominato.
• L'impostazione di crittografia viene ottenuta dal contenuto etichettato originale. Si consideri che un report nel servizio Power BI abbia un'etichetta di riservatezza Altamente riservato. Se viene esportata in un percorso di esportazione supportato, l'etichetta rimane intatta e la crittografia viene applicata al file esportato.

Il servizio Azure Rights Management (Azure RMS) viene usato per la protezione dei file con crittografia. Esistono alcuni prerequisiti importanti che devono essere soddisfatti per usare la crittografia di Azure RMS.

Importante

Esiste una limitazione da considerare: un utente offline (senza una connessione Internet) non può aprire un file di Power BI Desktop crittografato (o un altro tipo di file protetto da Azure RMS). Questo perché Azure RMS deve verificare in modo sincrono che un utente sia autorizzato ad aprire, decrittografare e visualizzare il contenuto del file.

Le etichette crittografate vengono gestite in modo diverso a seconda della posizione in cui l'utente lavora.

• Nel servizio Power BI: l'impostazione di crittografia non influisce direttamente sull'accesso degli utenti nel servizio Power BI. Le autorizzazioni standard di Power BI, ad esempio ruoli dell'area di lavoro, autorizzazioni per le app o autorizzazioni di condivisione, controllano l'accesso utente nel servizio Power BI. Le etichette di riservatezza non influiscono sull'accesso al contenuto all'interno del servizio Power BI.
• File di Power BI Desktop: è possibile assegnare un'etichetta crittografata a un file di Power BI Desktop. L'etichetta viene mantenuta anche quando viene esportata dal servizio Power BI. Solo gli utenti autorizzati potranno aprire, decrittografare e visualizzare il file.
• File esportati: i file di Microsoft Excel, Microsoft PowerPoint e PDF esportati dal servizio Power BI mantengono l'etichetta di riservatezza, inclusa la protezione della crittografia. Per i formati di file supportati, solo gli utenti autorizzati potranno aprire, decrittografare e visualizzare il file.

Importante

È fondamentale che gli utenti comprendano le distinzioni tra il servizio e i file Power BI, che possono facilmente confondere. È consigliabile fornire un documento di domande frequenti, insieme ad esempi, per aiutare gli utenti a comprendere le differenze.

Per aprire un file di Power BI Desktop protetto o un file esportato, un utente deve soddisfare i criteri seguenti.

• Connettività Internet: l'utente deve essere connesso a Internet. Per comunicare con Azure RMS è necessaria una connessione Internet attiva.
• Autorizzazioni RMS: l'utente deve avere autorizzazioni RMS definite all'interno dell'etichetta (anziché all'interno dei criteri di etichetta). Le autorizzazioni RMS consentono agli utenti autorizzati di decrittografare, aprire e visualizzare i formati di file supportati.
• Utente consentito: utenti o gruppi devono essere specificati nel criterio di etichetta. In genere, l'assegnazione di utenti autorizzati è necessaria solo per gli autori di contenuti e i proprietari in modo che possano applicare etichette. Tuttavia, quando si usa la protezione della crittografia è presente un altro requisito. Ogni utente che deve aprire un file protetto deve essere specificato nei criteri di etichetta. Questo requisito significa che potrebbero essere necessarie licenze di protezione delle informazioni per più utenti.

Suggerimento

L'impostazione del tenant Consenti agli amministratori dell'area di lavoro di eseguire l'override delle etichette di riservatezza applicate automaticamente consente agli amministratori dell'area di lavoro di modificare un'etichetta applicata automaticamente, anche se la protezione (crittografia) è abilitata per l'etichetta. Questa funzionalità è particolarmente utile quando un'etichetta è stata assegnata o ereditata automaticamente, ma l'amministratore dell'area di lavoro non è un utente autorizzato.

La protezione delle etichette viene impostata nel portale di conformità di Microsoft Purview quando si configura l'etichetta.

Elenco di controllo: quando si pianifica l'uso della crittografia delle etichette, le decisioni chiave e le azioni includono:

• Decidere quali etichette devono essere crittografate: per ogni etichetta di riservatezza decidere se deve essere crittografata (protetta). Considerare attentamente le limitazioni coinvolte.
• Identificare le autorizzazioni RMS per ogni etichetta: determinare le autorizzazioni utente per l'accesso e l'interazione con i file crittografati. Creare un mapping di utenti e gruppi per ogni etichetta di riservatezza per facilitare il processo di pianificazione.
• Verificare e risolvere i prerequisiti di crittografia RMS: assicurarsi che siano soddisfatti i prerequisiti tecnici per l'uso della crittografia di Azure RMS.
• Pianificare l'esecuzione di test approfonditi della crittografia: a causa delle differenze tra i file di Office e i file di Power BI, assicurarsi di eseguire una fase di test approfondita.
• Includere elementi nella documentazione e nella formazione degli utenti: assicurarsi di includere indicazioni nella documentazione e formazione su ciò che gli utenti devono aspettarsi per i file a cui viene assegnata un'etichetta di riservatezza crittografata.
• Eseguire il trasferimento delle conoscenze con il supporto: creare piani specifici per condurre sessioni di trasferimento delle conoscenze con il team di supporto. A causa della complessità della crittografia, è probabile ricevere domande dagli utenti.

Ereditarietà delle etichette dalle origini dati

Quando si importano dati da origini dati supportate (ad esempio Azure Synapse Analytics, database SQL di Azure o un file di Excel), un modello semantico di Power BI può, facoltativamente, ereditare l'etichetta di riservatezza applicata ai dati di origine. L'ereditarietà consente di:

• Promuovere la coerenza dell'etichettatura.
• Ridurre il lavoro dell'utente quando si assegnano etichette.
• Ridurre il rischio che gli utenti accedano e condividano dati sensibili con utenti non autorizzati perché questi non erano stati etichettati.

Suggerimento

Esistono due tipi di ereditarietà per le etichette di riservatezza. Ereditarietà downstream fa riferimento a elementi downstream (ad esempio report) che ereditano automaticamente un'etichetta dal modello semantico di Power BI. Tuttavia, l'obiettivo di questa sezione è l'ereditarietà upstream. L'ereditarietà upstream fa riferimento a un modello semantico di Power BI che eredita un'etichetta da un'origine dati upstream dal modello semantico.

Si consideri un esempio in cui la definizione di lavoro dell'organizzazione per l'etichetta di riservatezza Con restrizioni elevate include numeri di conti finanziari. Poiché i numeri di conto finanziario vengono archiviati in un database SQL di Azure, l'etichetta di riservatezza Con restrizioni elevate è stata assegnata a tale origine. Quando i dati del database SQL di Azure sono importati in Power BI, l'idea è che il modello semantico erediti l'etichetta.

È possibile assegnare etichette di riservatezza a un'origine dati supportata in modi diversi.

• Individuazione e classificazione dei dati: è possibile analizzare un database supportato per identificare le colonne che potrebbero contenere dati sensibili. In base ai risultati dell'analisi, è possibile applicare alcune o tutte le raccomandazioni sulle etichette. Individuazione e classificazione dei dati è supportato per database come il database SQL di Azure, Istanza gestita di SQL di Azure e Azure Synapse Analytics. Individuazione e classificazione dei dati SQL sono supportate per i database SQL Server locali.
• Assegnazioni manuali: è possibile assegnare un'etichetta di riservatezza a un file di Excel. È anche possibile assegnare manualmente le etichette alle colonne di database nel database SQL di Azure o in SQL Server.
• Etichettatura automatica in Microsoft Purview: le etichette di riservatezza possono essere applicate alle origini dati supportate registrate come asset in Microsoft Purview Data Map.

Avviso

I dettagli su come assegnare etichette di riservatezza a un'origine dati non rientrano nell'ambito di questo articolo. Le funzionalità tecniche sono in evoluzione rispetto a ciò che è supportato per l'ereditarietà in Power BI. È consigliabile condurre un modello di verifica tecnico per verificare gli obiettivi, la facilità d'uso e se le funzionalità soddisfano i requisiti.

L'ereditarietà verrà eseguita solo quando si abilita Applica etichette di riservatezza dalle origini dati ai dati in Power BI nelle impostazioni del tenant. Per altre informazioni sulle impostazioni del tenant, vedere la sezione Impostazioni del tenant di Power BI più avanti in questo articolo.

Suggerimento

Sarà necessario acquisire familiarità con il comportamento di ereditarietà. Assicurarsi di includere diverse circostanze nel piano di test.

Elenco di controllo: quando si pianifica l'ereditarietà delle etichette da origini dati, le decisioni e le azioni principali includono:

• Decidere se Power BI deve ereditare le etichette dalle origini dati: decidere se Power BI deve ereditare queste etichette. Pianificare l'abilitazione dell'impostazione del tenant per consentire questa funzionalità.
• Esaminare i prerequisiti tecnici: determinare se è necessario eseguire passaggi aggiuntivi per assegnare etichette di riservatezza alle origini dati.
• Funzionalità di ereditarietà delle etichette di test: completare un modello di verifica tecnico per testare il funzionamento dell'ereditarietà. Verificare che la funzionalità funzioni come previsto in varie circostanze.
• Includere nella documentazione utente: assicurarsi che le informazioni sull'ereditarietà delle etichette vengano aggiunte alle indicazioni fornite agli utenti. Includere esempi realistici nella documentazione dell'utente.

Criteri di etichetta pubblicati

Dopo aver definito un'etichetta di riservatezza, questa può essere aggiunta a uno o più criteri di etichetta. Un criterio di etichetta è il modo in cui si pubblica l'etichetta per poi usarla. Definisce quali etichette possono essere usate da quale set di utenti autorizzati. Esistono anche altre impostazioni, ad esempio l'etichetta predefinita e l'etichetta obbligatoria.

L'uso di più criteri di etichetta può essere utile quando è necessario specificare diversi set di utenti. È possibile definire un'etichetta di riservatezza una sola volta per poi includerla in uno o più criteri di etichetta.

Suggerimento

Un'etichetta di riservatezza non è disponibile per l'uso finché non viene pubblicato un criterio di etichetta contenente l'etichetta nel portale di conformità di Microsoft Purview.

Utenti e gruppi autorizzati

Quando si crea un criterio di etichetta, è necessario selezionare uno o più utenti o gruppi. I criteri di etichetta determinano quali utenti possono usare l'etichetta. Consente agli utenti di assegnare tale etichetta a contenuto specifico, ad esempio un file di Power BI Desktop, un file di Excel o un elemento pubblicato nel servizio Power BI.

È consigliabile usare un approccio il più semplice possibile per gli utenti e i gruppi autorizzati. Una buona regola generale è che le etichette primarie vengano pubblicate per tutti gli utenti. A volte è opportuno assegnare o definire l'ambito di un'etichetta secondaria a un subset di utenti.

È consigliabile assegnare gruppi invece di singoli utenti quando possibile. L'uso dei gruppi semplifica la gestione dei criteri e riduce la frequenza con cui deve essere ripubblicata.

Avviso

Gli utenti e i gruppi autorizzati per un'etichetta sono diversi dagli utenti assegnati ad Azure RMS per un'etichetta protetta (crittografata). Se un utente riscontra problemi durante l'apertura di un file crittografato, esaminare le autorizzazioni di crittografia per utenti e gruppi specifici (impostate all'interno della configurazione dell'etichetta, anziché all'interno dei criteri di etichetta). Nella maggior parte dei casi, è consigliabile assegnare gli stessi utenti a entrambi. Questa coerenza eviterà confusione e ridurrà i ticket di supporto.

Gli utenti e i gruppi autorizzati vengono impostati nel portale di conformità di Microsoft Purview quando vengono pubblicati i criteri di etichetta.

Elenco di controllo: quando si pianificano utenti e gruppi autorizzati nei criteri di etichetta, le decisioni chiave e le azioni includono:

• Determinare quali etichette si applichino a tutti gli utenti: discutere e decidere quali etichette di riservatezza devono essere disponibili per l'uso da parte di tutti gli utenti.
• Determinare quali etichette secondarie si applicano a un sottoinsieme di utenti: discutere e decidere se sono presenti etichette secondarie che saranno disponibili per l'uso solo da un set specifico di utenti o gruppi.
• Identificare se sono necessari nuovi gruppi: determinare se sono necessari nuovi gruppi Microsoft Entra ID (precedentemente noto come Azure Active Directory) per supportare gli utenti e i gruppi autorizzati.
• Creare un documento di pianificazione: se il mapping degli utenti autorizzati alle etichette di riservatezza è complicato, creare un mapping di utenti e gruppi per ogni criterio di etichetta.

Etichetta predefinita per il contenuto di Power BI

Quando si crea un criterio di etichetta, è possibile scegliere un'etichetta predefinita. Ad esempio, l'etichetta Uso interno generale può essere impostata come etichetta predefinita. Questa impostazione influirà sui nuovi elementi di Power BI creati in Power BI Desktop o nel servizio Power BI.

È possibile configurare l'etichetta predefinita nei criteri di etichetta specificamente per il contenuto di Power BI, che è separato da altri elementi. La maggior parte delle decisioni e impostazioni di protezione delle informazioni si applica in modo più ampio. Tuttavia, l'impostazione predefinita dell'etichetta (e l'impostazione dell'etichetta obbligatoria descritta di seguito) si applicano solo a Power BI.

Suggerimento

Anche se è possibile impostare etichette predefinite diverse (per contenuto di Power BI e non), valutare se questa sia l'opzione migliore per gli utenti.

È importante comprendere che un nuovo criterio di etichetta predefinito verrà applicato al contenuto creato o modificato, dopo la pubblicazione del criterio stesso. Non assegnerà retroattivamente l'etichetta predefinita al contenuto esistente. L'amministratore di Power BI può usare le API di protezione delle informazioni per impostare le etichette di riservatezza in blocco e assicurarsi così che il contenuto esistente sia assegnato a un'etichetta di riservatezza predefinita.

Le opzioni di etichetta predefinite vengono impostate nel portale di conformità di Microsoft Purview quando vengono pubblicati i criteri di etichetta.

Elenco di controllo: quando si pianifica se verrà applicata un'etichetta predefinita per il contenuto di Power BI, le decisioni chiave e le azioni includono:

• Decidere se specificare un'etichetta predefinita: discutere e decidere se un'etichetta predefinita è appropriata. In tal caso, determinare quale etichetta è più adatta per impostazione predefinita.
• Includere nella documentazione dell'utente: se necessario, assicurarsi che le informazioni sull'etichetta predefinita siano indicate agli utenti. L'obiettivo è consentire agli utenti di capire come determinare se l'etichetta predefinita è appropriata o se deve essere modificata.

Etichettatura obbligatoria del contenuto di Power BI

La classificazione dei dati è un requisito normativo comune. Per soddisfare questo requisito, è possibile scegliere di richiedere agli utenti di etichettare tutto il contenuto di Power BI. Questo requisito obbligatorio di etichettatura diventa effettivo quando gli utenti creano o modificano il contenuto di Power BI.

È possibile scegliere di implementare etichette obbligatorie, etichette predefinite (descritte nella sezione precedente) o entrambe. È consigliabile considerare i punti seguenti.

• Un criterio di etichetta obbligatorio garantisce che l'etichetta non sia vuota
• Un criterio di etichetta obbligatorio richiede agli utenti di scegliere quale deve essere l'etichetta
• Un criterio di etichetta obbligatorio impedisce agli utenti di rimuovere completamente un'etichetta
• Un criterio di etichetta predefinito è meno invadente per gli utenti perché non richiede azioni
• Un criterio di etichetta predefinito può comportare contenuti con etichetta errata perché un utente non ha esplicitamente fatto una determinata scelta
• L'abilitazione di un criterio di etichetta predefinito e di un criterio di etichetta obbligatorio può offrire vantaggi complementari

Suggerimento

Se si sceglie di implementare etichette obbligatorie, è consigliabile implementare anche quelle predefinite.

È possibile configurare i criteri di etichetta obbligatori specificamente per il contenuto di Power BI. La maggior parte delle impostazioni di protezione delle informazioni si applica in modo più ampio. Tuttavia, l'impostazione dell'etichetta obbligatoria (e di quella predefinita) si applica in modo specifico a Power BI.

Suggerimento

I criteri di etichetta obbligatori non sono applicabili alle entità servizio o alle API.

Le opzioni di etichettatura obbligatorie vengono impostate nel portale di conformità di Microsoft Purview quando vengono pubblicati i criteri di etichetta.

Elenco di controllo: quando si pianifica se sarà necessaria l'etichettatura obbligatoria del contenuto di Power BI, le decisioni chiave e le azioni includono:

• Decidere se le etichette saranno obbligatorie: discutere e decidere se le etichette obbligatorie sono necessarie per motivi di conformità.
• Includere nella documentazione utente: se necessario, assicurarsi che le informazioni sulle etichette obbligatorie vengano aggiunte alle indicazioni fornite per gli utenti. L'obiettivo è consentire agli utenti di comprendere cosa aspettarsi.

Requisiti di licenza

Devono essere applicate licenze specifiche per lavorare con le etichette di riservatezza.

È necessaria una licenza Microsoft Purview Information Protection per:

• Amministratori: gli amministratori che configureranno, gestiranno e supervisioneranno le etichette.
• Utenti: gli autori e i proprietari dei contenuti che saranno responsabili dell'applicazione delle etichette al contenuto. Gli utenti includono anche coloro che devono decrittografare, aprire e visualizzare i file protetti (crittografati).

Queste funzionalità potrebbero essere già disponibili perché sono incluse nelle suite di licenze, ad esempio Microsoft 365 E5. In alternativa, è possibile acquistare funzionalità di Microsoft 365 E5 Compliance come licenza autonoma.

È necessaria anche una licenza Power BI Pro o Premium per utente (PPU) per gli utenti che applicheranno e gestiranno le etichette di riservatezza nel servizio Power BI o in Power BI Desktop.

Suggerimento

Se sono necessari chiarimenti sui requisiti di licenza, rivolgersi al team dell'account Microsoft. Tenere presente che la licenza Microsoft 365 E5 Compliance include funzionalità aggiuntive che non rientrano nell'ambito di questo articolo.

Elenco di controllo: quando si valutano i requisiti di licenza per le etichette di riservatezza, le decisioni chiave e le azioni includono:

• Esaminare i requisiti di licenza dei prodotti: assicurarsi di esaminare tutti i requisiti di licenza.
• Esaminare i requisiti di licenza utente: verificare che tutti gli utenti a cui si prevede di assegnare etichette abbiano licenze Power BI Pro o PPU.
• Acquistare licenze aggiuntive: se applicabile, acquistare altre licenze per sbloccare le funzionalità che si intende usare.
• Assegnare licenze: assegnare una licenza a ogni utente che assegnerà, aggiornerà o gestirà le etichette di riservatezza. Assegnare una licenza a ogni utente che interagisce con i file crittografati.

Impostazioni del tenant di Power BI

Esistono diverse impostazioni del tenant di Power BI correlate alla protezione delle informazioni.

Importante

Le impostazioni del tenant di Power BI per la protezione delle informazioni non devono essere configurate fino a quando non vengono soddisfatti tutti i prerequisiti. Le etichette e i criteri di etichetta devono essere configurati e pubblicati nel portale di conformità di Microsoft Purview. Fino a questo momento, ci si trova ancora nel processo decisionale. Prima di impostare le impostazioni del tenant, è necessario determinare un processo per testare la funzionalità con un subset di utenti. È quindi possibile decidere come eseguire un'implementazione graduale.

Utenti che possono applicare etichette

È necessario decidere chi potrà applicare etichette di riservatezza al contenuto di Power BI. Questa decisione determinerà come impostare l'impostazione Consenti agli utenti di applicare etichette di riservatezza per l'impostazione del contenuto nel tenant.

In genere è l'autore o il proprietario del contenuto che assegna l'etichetta durante il normale flusso di lavoro. L'approccio più semplice consiste nell'abilitare questa impostazione del tenant, cosa che consente a tutti gli utenti di Power BI di applicare etichette. In questo caso, i ruoli dell'area di lavoro standard determineranno chi può modificare gli elementi nel servizio Power BI (inclusa l'applicazione di un'etichetta). È possibile usare il log attività per tenere traccia di quando un utente assegna o modifica un'etichetta.

Etichette da origini dati

È necessario decidere se si vuole che le etichette di riservatezza vengano ereditate da origini dati supportate upstream da Power BI. Ad esempio, se le colonne in un database SQL di Azure sono state definite con l'etichetta di riservatezza Con restrizioni elevate, un modello semantico di Power BI che importa i dati da tale origine erediterà tale etichetta.

Se si decide di abilitare l'ereditarietà da origini dati upstream, impostare Applica etichette di riservatezza dalle origini dati ai dati in Power BI nel tenant. È consigliabile pianificare l'ereditarietà delle etichette dell'origine dati per promuovere la coerenza e ridurre le attività.

Etichette per il contenuto downstream

È necessario decidere se le etichette di riservatezza devono essere ereditate dal contenuto downstream. Ad esempio, se un modello semantico di Power BI ha un'etichetta di riservatezza Con restrizioni elevate, tutti i report downstream erediteranno questa etichetta dal modello semantico.

Se si decide di abilitare l'ereditarietà per contenuto downstream, impostare l'impostazione Applica automaticamente le etichette di riservatezza al contenuto downstream nel tenant. È consigliabile pianificare l'ereditarietà in base al contenuto downstream per promuovere la coerenza e ridurre le attività.

Override dell'amministratore dell'area di lavoro

Questa impostazione si applica alle etichette applicate automaticamente, ad esempio quando vengono applicate etichette predefinite o quando le etichette vengono ereditate automaticamente. Quando un'etichetta ha impostazioni di protezione, Power BI consente solo agli utenti autorizzati di modificarla. Questa impostazione consente agli amministratori dell'area di lavoro di modificare un'etichetta applicata automaticamente, anche se sono presenti impostazioni di protezione sull'etichetta.

Se si decide di consentire gli aggiornamenti delle etichette, impostare Consenti agli amministratori dell'area di lavoro di eseguire l'override delle etichette di riservatezza applicate automaticamente nelle impostazioni del tenant. Questa impostazione si applica all'intera organizzazione e non a gruppi individuali. Consente agli amministratori dell'area di lavoro di modificare le etichette applicate automaticamente.

È consigliabile consentire agli amministratori dell'area di lavoro di Power BI di aggiornare le etichette. È possibile usare il log attività per tenere traccia dell'assegnazione o della modifica di un'etichetta.

Non consentire la condivisione di contenuto protetto

È necessario decidere se il contenuto protetto (crittografato) può essere condiviso con tutti gli utenti dell'organizzazione.

Se si decide di non consentire la condivisione di contenuto protetto, impostare l'impostazione Impedisci la condivisione tramite collegamento del contenuto con etichette protette con tutti nell'organizzazione nel tenant. Questa impostazione si applica all'intera organizzazione e non a gruppi individuali.

È consigliabile pianificare l'abilitazione di questa impostazione del tenant per impedire la condivisione di contenuto protetto. Se abilitata, non consente operazioni di condivisione con l'intera organizzazione per contenuti più sensibili (definiti dalle etichette con crittografia). Abilitando questa impostazione, si ridurrà la possibilità di perdita di dati.

Importante

Esiste un'impostazione del tenant simile denominata Consenti collegamenti condivisibili per concedere l'accesso a chiunque nell'organizzazione. Anche se ha un nome simile, lo scopo è diverso. Definisce quali gruppi possono creare un collegamento di condivisione per l'intera organizzazione, a prescindere dall'etichetta di riservatezza. Nella maggior parte dei casi, è consigliabile limitare questa funzionalità nell'organizzazione. Per altre informazioni, vedere l'articolo Pianificazione della sicurezza consumer report.

Tipi di file di esportazione supportati

Nel portale di amministrazione di Power BI sono disponibili molte impostazioni del tenant di esportazione e condivisione. Nella maggior parte dei casi, è consigliabile esportare i dati per tutti gli utenti (o la maggior parte di essi) in modo da non limitarne la produttività.

Tuttavia, i settori altamente regolamentati potrebbero avere un requisito per limitare le esportazioni quando non è possibile applicare la protezione delle informazioni per il formato di output. Un'etichetta di riservatezza applicata nel servizio Power BI segue il contenuto quando viene esportato in un percorso di file supportato. Include file di Excel, PowerPoint, PDF e Power BI Desktop. Poiché l'etichetta di riservatezza rimane con il file esportato, i vantaggi della protezione (crittografia che impedisce agli utenti non autorizzati di aprire il file) vengono conservati per questi formati di file supportati.

Avviso

Quando si esporta da Power BI Desktop in un file PDF, la protezione non viene mantenuta per il file esportato. È consigliabile indicare agli autori di contenuti di effettuare esportazioni dal servizio Power BI per ottenere la massima protezione delle informazioni.

Non tutti i formati di esportazione supportano la protezione delle informazioni. I formati non supportati, ad esempio i file .csv, .xml, mhtml o .png (disponibili quando si usa l'API ExportToFile) potrebbero essere disabilitati nelle impostazioni del tenant di Power BI.

Suggerimento

È consigliabile limitare le funzionalità di esportazione solo quando è necessario soddisfare requisiti normativi specifici. Negli scenari tipici è consigliabile usare il log attività di Power BI per identificare quali utenti eseguono esportazioni. È quindi possibile insegnare a questi utenti alternative più efficienti e sicure.

Elenco di controllo: quando si pianifica la configurazione delle impostazioni del tenant nel portale di amministrazione di Power BI, le decisioni e le azioni principali includono:

• Decidere quali utenti possono applicare etichette di riservatezza: discutere e decidere se le etichette di riservatezza possono essere assegnate al contenuto di Power BI da tutti gli utenti (in base alla sicurezza standard di Power BI) o solo da determinati gruppi di utenti.
• Determinare se le etichette devono essere ereditate da origini dati upstream: discutere e decidere se le etichette delle origini dati devono essere applicate automaticamente al contenuto di Power BI che usa l'origine dati.
• Determinare se le etichette devono essere ereditate dagli elementi downstream: discutere e decidere se le etichette assegnate ai modelli semantici di Power BI esistenti devono essere applicate automaticamente al contenuto correlato.
• Decidere se gli amministratori dell'area di lavoro di Power BI possono eseguire l'override delle etichette: discutere e decidere se gli amministratori dell'area di lavoro possono modificare le etichette protette assegnate automaticamente.
• Determinare se il contenuto protetto può essere condiviso con l'intera organizzazione: discutere e decidere se sia possibile creare collegamenti di condivisione per "persone nell'organizzazione" quando è stata assegnata un'etichetta protetta (crittografata) a un elemento nel servizio Power BI.
• Decidere quali formati di esportazione sono abilitati: identificare i requisiti normativi che influiranno sui formati di esportazione disponibili. Discutere e decidere se gli utenti potranno usare tutti i formati di esportazione nel servizio Power BI. Determinare se alcuni formati devono essere disabilitati nelle impostazioni del tenant quando il formato di esportazione non supporta la protezione delle informazioni.

Criteri di classificazione e protezione dei dati

È necessario innanzitutto configurare la struttura delle etichette e pubblicare i criteri delle etichette. Tuttavia, è necessario fare di più per aiutare l'organizzazione a riuscire a classificare e proteggere i dati. È fondamentale fornire indicazioni agli utenti su cosa può e non può essere fatto con il contenuto assegnato a una determinata etichetta. Questo è il punto in cui un criterio di classificazione e protezione dei dati risulta utile. È possibile considerarlo come le linee guida per le etichette.

Nota

I criteri di classificazione e protezione dei dati sono criteri di governance interni. È possibile scegliere di chiamarlo in modo diverso. Ciò che conta è che è sia una documentazione che si crea e si fornisce agli utenti in modo che sappiano come usare le etichette in modo efficace. Poiché i criteri di etichetta sono una pagina specifica nel portale di conformità di Microsoft Purview, provare a evitare di chiamare i criteri di governance interni con lo stesso nome.

È consigliabile creare in modo iterativo i criteri di classificazione e protezione dei dati durante il processo decisionale. Significa che tutto è chiaramente definito quando è il momento di configurare le etichette di riservatezza.

Ecco alcune delle informazioni chiave che è possibile includere nei criteri di classificazione e protezione dei dati.

• Descrizione dell'etichetta: oltre il nome dell'etichetta, fornire una descrizione completa. La descrizione deve essere chiara ma breve. Ecco alcune descrizioni di esempio:
  • Utilizzo interno generale: per i dati aziendali, privati e interni
  • Con restrizioni: per i dati aziendali sensibili che potrebbero causare danni se compromessi o sono soggetti a requisiti normativi o di conformità
• Esempi: fornire esempi per spiegare quando usare l'etichetta. Di seguito sono riportati alcuni esempi:
  • Uso interno generale: per la maggior parte delle comunicazioni interne, i dati di supporto non sensibili, le risposte ai sondaggi, le recensioni, le valutazioni e i dati approssimativi sulla posizione
  • Con restrizioni: per i dati personali (PII), ad esempio nome, indirizzo, telefono, posta elettronica, numero ID governo, razza o etnia. Include contratti fornitore e partner, dati finanziari non pubblici, dipendenti e risorse umane (HR). Include anche informazioni proprietarie, proprietà intellettuali e dati di posizione precisi.
• Etichetta obbligatoria: descrive se l'assegnazione di un'etichetta è obbligatoria per tutto il contenuto nuovo e modificato.
• Etichetta predefinita: descrive se questa etichetta è un'etichetta predefinita applicata automaticamente al nuovo contenuto.
• Restrizioni di accesso: informazioni aggiuntive che chiariscono se gli utenti interni e/o esterni sono autorizzati a visualizzare il contenuto assegnato a questa etichetta. Di seguito sono riportati alcuni esempi:
  • Tutti gli utenti, inclusi quelli interni, esterni e le terze parti con contratti di non divulgazione attivi (NDA), possono accedere a queste informazioni.
  • Gli utenti interni possono accedere solo a queste informazioni. Nessun partner, fornitore, terzista o terza parte, indipendentemente dallo stato dell'accordo di riservatezza o NDA.
  • L'accesso interno alle informazioni si basa sull'autorizzazione del ruolo del processo.
• Requisiti di crittografia: descrive se i dati devono essere crittografati inattivi e in transito. Queste informazioni sono correlate alla configurazione dell'etichetta di riservatezza e influiscono sui criteri di protezione che possono essere implementati per la crittografia dei file (RMS).
• Download e/o accesso offline consentiti: descrive se l'accesso offline è consentito. Può anche definire se i download sono consentiti per i dispositivi aziendali o personali.
• Come richiedere un'eccezione: descrive se un utente può richiedere un'eccezione al criterio standard e come eseguire questa operazione.
• Frequenza di controllo: specifica la frequenza delle verifiche di conformità. Le etichette sensibili più elevate devono comportare processi di controllo più frequenti e accurati.
• Altri metadati: un criterio dati richiede più metadati, ad esempio il proprietario dei criteri, il responsabile approvazione e la data di validità.

Suggerimento

Quando si creano criteri di classificazione e protezione dei dati, concentrarsi su come renderli un riferimento semplice per gli utenti. Dovrebbero essere quanto più brevi e chiari possibile. Se sono troppo complessi, non sempre gli utenti dedicheranno il tempo necessario a comprenderli.

Un modo per automatizzare l'implementazione di un criterio, ad esempio la classificazione dei dati e i criteri di protezione, consiste nel seguire le condizioni per l'utilizzo di Microsoft Entra. Quando viene configurato un criterio per le condizioni per l'utilizzo, gli utenti devono confermare i criteri prima di poter visitare il servizio Power BI per la prima volta. È anche possibile chiedere loro di accettarli di nuovo su base ricorrente, ad esempio ogni 12 mesi.

Elenco di controllo: quando si pianificano i criteri interni per gestire le aspettative di utilizzo delle etichette di riservatezza, le decisioni chiave e le azioni includono:

• Creare criteri di classificazione e protezione dei dati: per ogni etichetta di riservatezza nella struttura creare un documento dei criteri centralizzato. Questo documento deve definire ciò che può o non può essere fatto con il contenuto assegnato a ogni etichetta.
• Ottenere il consenso sui criteri di classificazione e protezione dei dati: assicurarsi che tutte le persone necessarie nel team assemblato abbiano accettato le disposizioni.
• Considerare come gestire le eccezioni ai criteri: le organizzazioni altamente decentralizzate devono considerare se possono verificarsi eccezioni. Anche se è preferibile avere criteri di classificazione e protezione dei dati standardizzati, decidere come risolvere le eccezioni quando vengono effettuate nuove richieste.
• Considerare dove individuare i criteri interni: dare un'idea della posizione in cui pubblicare i criteri di classificazione e protezione dei dati. Assicurarsi che tutti gli utenti possano accedervi facilmente. Pianificare di includerli nella pagina della Guida personalizzata quando si pubblicano i criteri di etichetta.

Documentazione e formazione degli utenti

Prima di implementare la funzionalità di protezione delle informazioni, è consigliabile creare e pubblicare documentazione per gli utenti. L'obiettivo della documentazione è quello di fornire un'esperienza utente senza problemi. La preparazione delle indicazioni per gli utenti consentirà anche di assicurarsi di aver preso in considerazione tutto.

È possibile pubblicare le indicazioni come parte della pagina della Guida personalizzata dell'etichetta di riservatezza. Una pagina di SharePoint o una pagina wiki nel portale centralizzato possono essere ideali in quanto sono facili da gestire. Anche un documento caricato in una raccolta condivisa o in un sito di Teams è un buon approccio. L'URL per la pagina della Guida personalizzata viene specificato nel portale di conformità di Microsoft Purview quando si pubblicano i criteri di etichetta.

Suggerimento

La pagina della Guida personalizzata è una risorsa importante. I collegamenti vengono resi disponibili in vari applicazioni e servizi.

La documentazione dell'utente deve includere i criteri di classificazione e protezione dei dati descritti in precedenza. Tale criterio interno è destinato a tutti gli utenti. Gli utenti interessati includono autori di contenuti e consumer che devono comprendere le implicazioni per le etichette assegnate da altri utenti.

Oltre ai criteri di classificazione e protezione dei dati, è consigliabile preparare le linee guida per gli autori e i proprietari di contenuti in merito a:

• Visualizzazione delle etichette: informazioni sul significato di ogni etichetta. Correlare ogni etichetta con i criteri di classificazione e protezione dei dati.
• Assegnazione di etichette: indicazioni su come assegnare e gestire le etichette. Includere informazioni che dovranno conoscere, ad esempio etichette obbligatorie, etichette predefinite e come funziona la loro ereditarietà.
• Flusso di lavoro: suggerimenti su come assegnare ed esaminare le etichette come parte del normale flusso di lavoro. Le etichette possono essere assegnate in Power BI Desktop non appena inizia lo sviluppo, approccio che protegge il file originale di Power BI Desktop durante il processo di sviluppo.
• Notifiche situazionali: consapevolezza sulle notifiche generate dal sistema che gli utenti potrebbero ricevere. Ad esempio, un sito di SharePoint viene assegnato a una determinata etichetta di riservatezza, ma un singolo file è stato assegnato a un'etichetta più sensibile (superiore). L'utente che ha assegnato l'etichetta superiore riceverà una notifica tramite posta elettronica che l'etichetta assegnata al file non è compatibile con il sito in cui è archiviata.

Includere informazioni su chi gli utenti dovranno contattare in caso di domande o problemi tecnici. Poiché la protezione delle informazioni è un progetto a livello di organizzazione, il supporto viene spesso fornito dall'IT.

Le domande frequenti e gli esempi sono particolarmente utili per la documentazione degli utenti.

Suggerimento

Alcuni requisiti normativi includono un componente di training specifico.

Elenco di controllo: quando si preparano la documentazione e il training degli utenti, le decisioni e le azioni principali includono:

• Identificare le informazioni da includere: determinare quali informazioni devono essere incluse in modo che tutti i destinatari pertinenti comprendano cosa ci si aspetta quando si tratta di proteggere i dati per conto dell'organizzazione.
• Pubblicare la pagina della Guida personalizzata: creare e pubblicare una pagina della Guida personalizzata. Includere indicazioni sull'etichettatura sotto forma di domande frequenti ed esempi. Includere un collegamento per accedere ai criteri di classificazione e protezione dei dati.
• Pubblicare i criteri di classificazione e protezione dei dati: pubblicare il documento dei criteri che definisce esattamente cosa può o non può essere fatto con il contenuto assegnato a ogni etichetta.
• Determinare se sia necessario un training specifico: creare o aggiornare il training utente per includere informazioni utili, soprattutto se è necessario un requisito normativo.

Supporto per gli utenti

È importante verificare chi sarà responsabile del supporto utente. È comune che le etichette di riservatezza siano supportate da un help desk IT centralizzato.

Potrebbe essere necessario creare linee guida per l'help desk (talvolta noto come runbook). Potrebbe anche essere necessario eseguire sessioni di trasferimento delle informazioni per assicurarsi che l'help desk sia pronto per rispondere alle richieste di supporto.

Elenco di controllo: quando ci si prepara per la funzione di supporto degli utenti, le decisioni e le azioni principali includono:

• Identificare chi fornirà supporto agli utenti: quando si definiscono ruoli e responsabilità, assicurarsi di includere il modo in cui gli utenti riceveranno assistenza per i problemi relativi alla protezione delle informazioni.
• Assicurarsi che il team di supporto utenti sia pronto: creare la documentazione e condurre sessioni di trasferimento delle informazioni per assicurarsi che l'help desk sia pronto per supportare la protezione delle informazioni. Evidenziare aspetti complessi che potrebbero confondere gli utenti, ad esempio la protezione della crittografia.
• Comunicare tra team: discutere il processo e le aspettative con il team di supporto, nonché con gli amministratori di Power BI e il Centro di eccellenza. Assicurarsi che tutti gli utenti coinvolti siano preparati per le potenziali domande degli utenti di Power BI.

Riepilogo dell'implementazione

Dopo aver preso le decisioni e aver soddisfatto i prerequisiti, è il momento di iniziare a implementare la protezione delle informazioni in base al piano di implementazione graduale.

L'elenco di controllo seguente include un elenco riepilogato dei passaggi di implementazione end-to-end. Molti dei passaggi includono altri dettagli illustrati nelle sezioni precedenti di questo articolo.

Elenco di controllo: quando si implementa la protezione delle informazioni, le decisioni chiave e le azioni includono:

• Verificare lo stato e gli obiettivi correnti: assicurarsi di avere informazioni sufficienti sullo stato corrente della protezione delle informazioni nell'organizzazione. Tutti gli obiettivi e i requisiti per l'implementazione della protezione delle informazioni devono essere chiari e attivamente usati per guidare il processo decisionale.
• Prendere decisioni: rivedere e discutere tutte le decisioni necessarie. Questa attività deve essere eseguita prima di configurare qualsiasi elemento nell'ambiente di produzione.
• Esaminare i requisiti di licenza: assicurarsi di comprendere i requisiti di licenza dei prodotti e delle licenze utente. Procurarsi e assegnare più licenze, se necessario.
• Pubblicare la documentazione utente: pubblicare i criteri di classificazione e protezione dei dati. Creare una pagina della Guida personalizzata contenente le informazioni pertinenti necessarie agli utenti.
• Preparare il team di supporto: eseguire sessioni di trasferimento delle conoscenze per assicurarsi che il team di supporto sia pronto per gestire le domande degli utenti.
• Creare le etichette di riservatezza: configurare ognuna delle etichette di riservatezza nel portale di conformità di Microsoft Purview.
• Pubblicare criteri di etichette di riservatezza: creare e pubblicare criteri di etichetta nel portale di conformità di Microsoft Purview. Iniziare eseguendo il test con un piccolo gruppo di utenti.
• Configurare le impostazioni del tenant di Power BI: nel portale di amministrazione di Power BI configurare le impostazioni del tenant Information Protection.
• Eseguire test iniziali: eseguire un set iniziale di test per verificare che tutto funzioni correttamente. Usare un tenant non di produzione per il test iniziale, se disponibile.
• Raccogliere commenti e suggerimenti degli utenti: pubblicare i criteri di etichetta in un piccolo subset di utenti che sono disposti a testare la funzionalità. Ottenere commenti e suggerimenti sul processo e sull'esperienza utente.
• Continuare le versioni iterative: pubblicare i criteri di etichetta in altri gruppi di utenti. Eseguire l'onboarding di più gruppi di utenti fino a quando non viene inclusa l'intera organizzazione.

Suggerimento

Questi elementi dell'elenco di controllo sono riepilogati a scopo di pianificazione. Per altri dettagli su questi elementi dell'elenco di controllo, vedere le sezioni precedenti di questo articolo.

Monitoraggio continuo

Dopo aver completato l'implementazione, è necessario indirizzare l'attenzione al monitoraggio e all'ottimizzazione delle etichette di riservatezza.

Gli amministratori e gli amministratori di sicurezza e conformità di Power BI dovranno collaborare occasionalmente. Per il contenuto di Power BI, sono disponibili due gruppi di destinatari interessati al monitoraggio.

• Amministratori di Power BI: viene registrata una voce nel log attività di Power BI ogni volta che viene assegnata o modificata un'etichetta di riservatezza. La voce del log attività registra i dettagli dell'evento, tra cui utente, data e ora, nome dell'elemento, area di lavoro e capacità. Altri eventi del log attività, ad esempio quando viene visualizzato un report, includeranno l'ID etichetta di riservatezza assegnato all'elemento.
• Amministratori di sicurezza e conformità: gli amministratori di sicurezza e conformità dell'organizzazione useranno in genere report, avvisi e log di controllo di Microsoft Purview.

Elenco di controllo: quando si monitora la protezione delle informazioni, le decisioni chiave e le azioni includono:

• Verificare ruoli e responsabilità: assicurarsi di essere chiari su chi è responsabile di quali azioni. Informare e comunicare con gli amministratori di Power BI o gli amministratori della sicurezza, se saranno direttamente responsabili di alcuni aspetti.
• Creare o convalidare il processo per l'attività di revisione: assicurarsi che gli amministratori di sicurezza e conformità siano chiari sulle aspettative per gli esami regolari di Esplora attività.

Suggerimento

Per altre informazioni sul controllo, vedere Controllo della protezione delle informazioni e prevenzione della perdita dei dati per Power BI.

Contenuto correlato

Nell'articolo successivo di questa serie vengono fornite informazioni sulla prevenzione della perdita dei dati per Power BI.