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

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

• Amministratori di Power BI: amministratori responsabili della supervisione di Power BI nell'organizzazione. Gli amministratori di Power BI devono collaborare con la sicurezza delle informazioni e altri team pertinenti.
• Centro di eccellenza, 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 di 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 e messaggi di posta elettronica 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 cosa è coinvolto. È 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 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 a 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 un tag. È possibile assegnare a ogni elemento una sola etichetta, ad esempio un modello semantico di Power BI, noto in precedenza come set di dati, nella servizio Power BI) o a 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 lavorare in modo appropriato con 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:stato corrente della 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 se si sta portando la protezione delle informazioni all'organizzazione per la prima volta.
• Obiettivi e requisiti : obiettivi strategici per implementare la protezione delle informazioni nell'organizzazione. Comprendere gli obiettivi e i requisiti fungerà da guida per 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 per introdurre la protezione delle informazioni all'organizzazione.

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à (o tutte) nelle fasi di implementazione 1-4 (nella sezione successiva) sarà già completa.

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 è configurare se stessi per imparare, regolare ed eseguire l'iterazione 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 a 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 darvi un senso per quello che 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).

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 gli utenti di supporto. Le risorse includono i criteri di classificazione e protezione dei dati e la pagina della Guida personalizzata.

È importante che alcune delle documentazioni utente siano pubblicate in anticipo. È anche importante avere il team di supporto tecnico dell'utente preparato in anticipo.

Fase 3: Configurare le etichette e pubblicare

La terza fase è incentrata sulla definizione delle etichette di riservatezza. Quando tutte le decisioni sono state prese, la configurazione non è difficile o dispendiosa in termini di tempo. Le etichette di riservatezza vengono configurate nel Portale di conformità di Microsoft Purview nel 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 nella Portale di conformità di Microsoft Purview nel interfaccia di amministrazione di Microsoft 365.

Nota

Tutto fino a questo punto è un prerequisito per l'implementazione della protezione delle informazioni per Power BI.

Fase 5: Abilitare le impostazioni del tenant di Power BI

Nel portale di amministrazione di Power BI sono disponibili diverse impostazioni del tenant di Information Protection. Devono 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 dalla 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 di conseguenza la documentazione dell'utente.

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é visualizzino 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 di confusione, lacune nella struttura dell'etichetta o problemi tecnici. È anche possibile trovare motivi per migliorare la documentazione dell'utente.

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

Suggerimento

Assicurarsi di tenere conto del tempo sufficiente nel piano di progetto. Per le etichette e le impostazioni dei criteri di etichetta, la documentazione del prodotto consiglia di rendere effettive le modifiche di 24 ore . Questa volta è necessario 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 di 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 nelle app di Microsoft Defender per il cloud. Per altre informazioni, inclusa una descrizione delle funzionalità che potrebbero risultare utili, vedere Defender per il cloud App 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: creare un piano di progetto che includa tutte le attività chiave, la sequenza temporale stimata e chi sarà responsabile.

Struttura delle etichette 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 è coinvolto 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. Il suo obiettivo è invece considerazioni e attività che influiscono direttamente sulla classificazione del contenuto di 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 delle etichette. Viene anche definita tassonomia di classificazione dei dati perché l'obiettivo è classificare i dati. A volte viene definita 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 tra tre e 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. Includendoli 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 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 contiene 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 sulle 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.

Essere intenzionali con le etichette create perché è difficile rimuovere o eliminare un'etichetta dopo aver superato la fase di test iniziale. Poiché le etichette secondarie possono (facoltativamente) essere usate per un determinato set di utenti, possono cambiare più spesso rispetto alle etichette.

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

• Usare termini intuitivi, non ambigui: Clarity è importante per assicurarsi che gli utenti sappiano cosa scegliere quando classificano i dati. Ad esempio, avere un'etichetta Top Secret e un'etichetta Estremamente riservato è ambigua.
• Creare un ordine gerarchico logico: l'ordine delle etichette è fondamentale per rendere tutto corretto. Tenere presente che l'ultima etichetta nell'elenco è la più sensibile. L'ordine gerarchico, in combinazione con i termini ben selezionati, deve essere logico e intuitivo per consentire agli utenti di lavorare con . 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 Altamente riservato o Estremamente riservato .
• Usare termini facilmente localizzati in altre lingue: per le organizzazioni globali con operazioni in più paesi/aree geografiche, è importante scegliere termini di etichetta che non confondono o ambigui 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 degli utenti, riduzione dell'adozione e meno efficace della protezione delle informazioni. È consigliabile iniziare con un set iniziale di etichette (o usare quello che si ha già). Dopo aver acquisito più esperienza, espandere con cautela il set di etichette aggiungendo quelli più specifici 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 di etichette di riservatezza 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 confermano che le etichette localizzate trasmettono 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 e messaggi di posta elettronica)
• Gruppi e siti (ad esempio un canale di Teams o un sito di SharePoint)
• Asset di dati con schema (origini supportate registrate nella mappa dei dati purview)

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 essi. 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, sono previsti 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 può creare confusione per gli utenti quando vedono 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 viene configurata l'etichetta.

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: esaminare i prerequisiti e i passaggi di configurazione necessari che saranno 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 messaggi di posta elettronica. 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, fa riferimento alla crittografia. Potrebbe essere sufficiente crittografare solo 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 rimane con 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 un report nel servizio Power BI ha un'etichetta di riservatezza altamente limitata. 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.

• Nella servizio Power BI: l'impostazione di crittografia non ha un effetto diretto 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 nella 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 dalla servizio Power BI. Solo gli utenti autorizzati potranno aprire, decrittografare e visualizzare il file.
• File esportati: i file Microsoft Excel, Microsoft PowerPoint e PDF esportati dalla 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 i servizio Power BI e i file, che sono facilmente confusi. È 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 disporre delle 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: gli utenti o i gruppi devono essere specificati nei criteri di etichetta. In genere, l'assegnazione di utenti autorizzati è necessaria solo per i creatori di contenuti e i proprietari in modo che possano applicare etichette. Tuttavia, quando si usa la protezione della crittografia esiste un altro requisito. Ogni utente che deve aprire un file protetto deve essere specificato nei criteri di etichetta. Questo requisito significa che le licenze per la protezione delle informazioni potrebbero essere necessarie 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.
• Esaminare 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 il commit in una fase di test completa.
• Includere 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 che ottengano 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 condividono dati sensibili con utenti non autorizzati perché non sono stati etichettati.

Suggerimento

Esistono due tipi di ereditarietà per le etichette di riservatezza. L'ereditarietà downstream fa riferimento a elementi downstream (ad esempio i report) che ereditano automaticamente un'etichetta dal modello semantico di Power BI. Tuttavia, l'attenzione di questa sezione riguarda 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 altamente limitata include numeri di conto finanziario. Poiché i numeri di conto finanziario vengono archiviati in un database SQL di Azure, l'etichetta di riservatezza con restrizioni elevata è stata assegnata a tale origine. Quando i dati della database SQL di Azure sono importati in Power BI, la finalità è 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. L'individuazione e la classificazione dei dati sono supportate per database come database SQL di Azure, Istanza gestita di SQL di Azure e Azure Synapse Analytics. L'individuazione e la 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 in database SQL di Azure o SQL Server.
• Etichettatura automatica in Microsoft Purview: le etichette di riservatezza possono essere applicate alle origini dati supportate registrate come asset nella mappa dei dati di Microsoft Purview.

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 l'impostazione Applica etichette di riservatezza dalle origini dati ai dati nel tenant di Power BI. Per altre informazioni sulle impostazioni del tenant, vedere la sezione Impostazioni 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 dalle origini dati, le decisioni chiave e le azioni 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 dell'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, l'etichetta può essere aggiunta a uno o più criteri di etichetta. Un criterio di etichetta è il modo in cui si pubblica l'etichetta in modo che possa essere usata. 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 e quindi includere 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 nella servizio Power BI.

È consigliabile mantenere gli utenti e i gruppi autorizzati il più semplice possibile. 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 ogni volta che 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 presenta problemi durante l'apertura di un file crittografato, esaminare le autorizzazioni di crittografia per utenti e gruppi specifici (configurati 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 nella 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 applicano 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 è necessario creare nuovi gruppi di Microsoft Entra ID (in precedenza noti 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 Utilizzo interno generale può essere impostata come etichetta predefinita. Questa impostazione influirà sui nuovi elementi di Power BI creati in Power BI Desktop o sulla 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 delle 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 applica solo a Power BI.

Suggerimento

Anche se è possibile impostare etichette predefinite diverse (per Power BI e contenuto non Power BI), valutare se questa è 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 dei criteri di etichetta. 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 per assicurarsi 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 nelle indicazioni fornite per gli 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 di etichettatura obbligatorio 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 l'azione
• Un criterio di etichetta predefinito può comportare contenuti con etichetta errata perché un utente non ha esplicitamente fatto la 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 le etichette 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 l'impostazione predefinita dell'etichetta) 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 dell'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

Per usare le etichette di riservatezza, è necessario implementare licenze specifiche.

È necessaria una licenza di Microsoft Purview Information Protection per:

• Amministrazione istrator: Gli amministratori che configureranno, gestiranno e supervisioneranno le etichette.
• Utenti: autori di contenuti e proprietari 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, le funzionalità di conformità di Microsoft 365 E5 possono essere acquistate 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 che 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 impostate 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, si è ancora nel processo decisionale. Prima di impostare le impostazioni del tenant, è necessario determinare prima di tutto 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 tenant del contenuto.

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, 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 nella servizio Power BI (inclusa l'applicazione di un'etichetta). È possibile usare il log attività per tenere traccia 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 di un database SQL di Azure sono state definite con l'etichetta di riservatezza con restrizioni elevata, 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 l'impostazione Applica etichette di riservatezza dalle origini dati ai dati nel tenant di Power BI. È 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 altamente limitata, 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 tenant del contenutodownstream. È 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 modificare l'etichetta. 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 l'impostazione Consenti agli amministratori dell'area di lavoro di eseguire l'override dell'impostazione del tenant delle etichette di riservatezzaapplicate automaticamente. Questa impostazione si applica all'intera organizzazione (non a singoli gruppi). 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 Limita contenuto con etichette protette da condividere tramite collegamento a tutti gli utenti del tenant dell'organizzazione. Questa impostazione si applica all'intera organizzazione (non a singoli gruppi).

È 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 che hanno definito la 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 tutti gli utenti dell'organizzazione. Anche se ha un nome simile, lo scopo è diverso. Definisce i gruppi che possono creare un collegamento di condivisione per l'intera organizzazione, indipendentemente dall'etichetta di riservatezza. Nella maggior parte dei casi, è consigliabile limitare questa funzionalità nell'organizzazione. Per altre informazioni, vedere l'articolo Pianificazione della sicurezza degli utenti del 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) in modo da non limitare la produttività degli utenti.

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 esportata 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 informare i creatori di contenuti da esportare 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 .csv, .xml, mhtml o .png file (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 gli utenti che 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 chiave e le azioni 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 è appropriato per gli amministratori dell'area di lavoro modificare le etichette protette assegnate automaticamente.
• Determinare se il contenuto protetto può essere condiviso con l'intera organizzazione: discutere e decidere se è possibile creare collegamenti di condivisione per "persone nell'organizzazione" quando un'etichetta protetta (crittografata) è stata assegnata a un elemento nel servizio Power BI.
• Decidere quali formati di esportazione sono abilitati: identificare i requisiti normativi che influiscono 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

La configurazione della struttura delle etichette e la pubblicazione dei criteri di etichetta sono necessari per primi. 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 si trovano criteri di classificazione e protezione dei dati è utile. È possibile considerarlo come 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 è la 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 al nome dell'etichetta, fornire una descrizione completa dell'etichetta. La descrizione deve essere chiara ma breve. Ecco alcune descrizioni di esempio:
  • Utilizzo interno generale: per dati privati, interni e aziendali
  • 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. Ecco alcuni esempi:
  • Utilizzo 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 sulla posizione imprecisa
  • 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à intellettuale 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 possono visualizzare il contenuto assegnato a questa etichetta. Ecco alcuni esempi:
  • Tutti gli utenti, inclusi gli utenti interni, gli utenti 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, fornitori, terzisti o terze parti, 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 consentiti e/o accesso offline: descrive se l'accesso offline è consentito. Può anche definire se i download sono consentiti ai dispositivi aziendali o personali.
• Come richiedere un'eccezione: descrive se un utente può richiedere un'eccezione ai criteri 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: i criteri dati richiedono 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 renderlo un riferimento semplice per gli utenti. Dovrebbe essere il più breve e chiaro possibile. Se è troppo complesso, gli utenti non prenderà sempre il tempo necessario per comprenderlo.

Un modo per automatizzare l'implementazione di un criterio, ad esempio la classificazione dei dati e i criteri di protezione, è con 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 accettare di nuovo su base ricorrente, ad esempio ogni 12 mesi.

Elenco di controllo : quando si pianificano i criteri interni per gestire le aspettative per l'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.
• Valutare 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.
• Prendere in considerazione la posizione in cui individuare i criteri interni: è consigliabile prendere in considerazione la posizione in cui pubblicare i criteri di classificazione e protezione dei dati. Assicurarsi che tutti gli utenti possano accedervi facilmente. Pianificare di includerlo nella pagina della Guida personalizzata quando si pubblicano i criteri di etichetta.

Documentazione e formazione per gli utenti

Prima di implementare la funzionalità di protezione delle informazioni, è consigliabile creare e pubblicare documentazione per gli utenti. L'obiettivo della documentazione è quello di ottenere 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 può funzionare correttamente perché sarà facile da gestire. Un documento caricato in una raccolta condivisa o in un sito di Teams è anche 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 varie 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 creatori 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 i creatori di contenuti e i proprietari su:

• 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 l'ereditarietà delle etichette.
• 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, che protegge il file originale di Power BI Desktop durante il processo di sviluppo.
• Notifiche situazioni: consapevolezza delle 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 sugli utenti che devono 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 chiave e le azioni 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 è necessario un training specifico: creare o aggiornare il training degli utenti in modo da includere informazioni utili, soprattutto se è necessario un requisito normativo.

Supporto per gli utenti

È importante verificare chi sarà responsabile del supporto tecnico degli utenti. È 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 si prepara per la funzione di supporto utente, le decisioni chiave e le azioni includono:

• Identificare chi fornirà supporto per gli 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 i team: discutere il processo e le aspettative con il team di supporto, nonché 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 chiarezza 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: esaminare 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 dell'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 nella Portale di conformità di Microsoft Purview.
• Pubblicare un criterio di etichetta di riservatezza: creare e pubblicare un criterio di etichetta nel Portale di conformità di Microsoft Purview. Iniziare eseguendo il test con un piccolo gruppo di utenti.
• Impostare le impostazioni del tenant di Power BI: nel portale di amministrazione di Power BI impostare le impostazioni del tenant di 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 di 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 di tanto in tanto. 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 delle 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 esaminare regolarmente 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.