• Cloud, Microsoft 365, Sicurezza
• 9 Luglio 2020

Le Sensitivity Labels sono una componente fondamentale all’interno del Microsoft Information Protection framework e in questo articolo esploreremo come questa componente è ben radicata all’interno dell’ecosistema Microsoft 365.

Questo articolo è inteso come la prosecuzione dell’articolo introduttivo alle Sensitivity Labels: Come classificare e proteggere le informazioni con le Sensitivity Labels di Office 365 Security & Compliance, è consigliata la lettura per chi non ha ancora esperienza con la nuova piattaforma di Unified Labeling.

Sensitivity Labels negli Office 365 Groups

Applicando una Sensitivity Label ad un Microsoft 365 group (il nuovo nome degli Office 365 groups) è possibile gestire alcune caratteristiche del gruppo:

• Privacy del gruppo (se è un gruppo pubblico o privato)
• Accesso esterno al gruppo: se i Guest sono consentiti o meno
• Accesso a SharePoint Online da dispositivi non gestiti

È importante tenere a mente che non viene applicata la protezione di Azure Information Protection ad ogni singolo file, come quello che accade se si abilita su SharePoint una policy IRM che sempre usa AIP, ma solo al Microsoft 365 group inteso come contenitore.

Per configurare questa funzionalità è necessario effettuare alcune configurazioni in Azure Active Directory: collegarsi tramite PowerShell ad Azure AD e abilitare le Unified Labels per i Microsoft 365 Groups tramite i seguenti comandi:

Una volta eseguita questa configurazione è necessario sincronizzare le Labels dallo Unified Label Store verso Azure Active Directory, per fare ciò eseguire i seguenti comandi

A questo punto sul Security & Compliance Center di Office 365 https://protection.office.com/ sarà possibile configurare le opzioni delle Sensitivity Labels inerenti i Microsoft 365 Groups.

Portarsi su Classification -> Sensitivity labels, selezionare una label e quindi premere Edit

Figura 1 – Modifica di una Sensitivity Label

Sarà ora disponibile un elemento in più nella configurazione della Sensitivity Label, inerente agli Unified Group, in cui configurare quanto appena descritto

Figura 2 – Impostazione Unified Group su Sensitivity Labels

Dopo aver atteso 24 ore è possibile provare a creare un Microsoft 365 group applicandogli una Sensitivity Label: in Figura 3 viene illustrato come si presenta il flusso di creazione partendo da Outlook

Figura 3 – Creazione Gruppo da Outlook

Siccome per questa Label è stata disabilitata la possibilità di creare gruppi pubblici, la Privacy del gruppo viene automaticamente impostata a Private.

Per quanto riguarda la possibilità di invitare utenti esterni non si è inventato nulla di nuovo: si è scelto di utilizzare una funzionalità già esistente di Azure AD (configurabile e visibile solo tramite PowerShell) per creare un AzureAD Object Setting per l’oggetto Unified Group.

Figura 4 – Azure AD Object Setting

Nel momento in cui si tenta di aggiungere un utente, il People Picker non ne propone l’aggiunta

Figura 5 – People Picker senza Guests

Per quanto riguarda le restrizioni di accesso a SharePoint Online da device non gestito, è necessario configurare Conditional Access in maniera appropriata. Questo scenario è già stato trattato nell’articolo Come utilizzare le App-Enforced Restrictions policy di Azure AD Conditional Access e le Sensitivity Labels per i Microsoft 365 Groups utilizzano esattamente le stesse configurazioni, anche qui non si è inventato nulla di nuovo, si è deciso di sfruttare tecnologia esistente.

Figura 6 – App-Enforced Restrictions in SharePoint Online

Sensitivity Labels in PowerBI

Per abilitare l’uso delle Sensitivity Labels in PowerBI collegarsi al pannello di amministrazione tramite il link https://app.powerbi.com/admin-portal/ e portarsi su Tenant Settings -> Information Protection -> Spostare il toggle su Enabled e premere Apply

Figura 7 – Sensitivity Labels in PowerBI

Una volta abilitate le Sensitivity Lables in PowerBI gli utenti potranno applicarle alle loro dashboard, report, dataset e dataflows come nell’esempio in Figura 7

Figura 8 – Applicazione Sensitivity Label a dashboard

È importante ricordarsi che PowerBI non applica protezione tramite encryption e non aggiunge marcature utilizzando il content marking, ciò nonostante, è comunque utile applicare una Sensitivity Label in quanto permette di avere una miglior governance sui dati trattati in PowerBI.

Sensitivity Lables in Microsoft Defender Advanced Threat Protection (MDATP)

Abilitando l’integrazione tra Microsoft Defender ATP e Azure Information Protection si aumentano le potenzialità di entrambi i prodotti:

• Defender ATP riesce, nella creazione degli incidenti, a esporre la sensibilità dei dati sul dispositivo compromesso e questo permette di prioritizzare al meglio la gestione degli incidenti
• Azure Information Protection riceve dal client di Defender ATP metadati e altre informazioni utili circa il contenuto dei files che scansiona, aiutando nella ricerca di informazioni sensibili all’interno dei computers

Per abilitare l’integrazione tra Azure Information Protection e Microsoft Defender ATP portarsi sul portale di amministrazione di ATP tramite il link https://securitycenter.windows.com/, andare su Advanced features, abilitare Azure Information Protection e premere su Save Preferences

Figura 9 – Abilitazione integrazione MDATP / AIP

Dopo qualche ora all’interno della vista Data Discovery di Azure Information Protection saranno disponibili i livelli di rischio degli endpoint

Figura 10 – AIP Data discovery arricchita da MDATP

Verranno anche mostrati i files classificati e quelli non ancora protetti, come in questo esempio: il file in oggetto è un export RVtools contenente, tra gli altri, molti indirizzi IP che il client di MDATP ha correttamente identificato e conseguentemente ha inviato questo segnale ad AIP.

Figura 11 – Information types

La console di Microsoft Defender ATP invece si arricchirà di altri dettagli: verrà visualizzata la classificazione delle informazioni residenti sulla macchina negli ultimi 30 giorni

Figura 12 – MDATP console con dati AIP

Sensitivity Labels in Microsoft Cloud App Security (MCAS)

Microsoft Cloud App Security ha delle funzionalità utili nella manipolazione dei files, sia che siano ospitati su applicazioni del Microsoft Cloud che su Cloud di altri providers.
MCAS è, ad esempio, in grado di applicare delle classificazioni automatiche utilizzando delle policy oppure di interrompere la condivisione di un file ospitato su SharePoint o su Box.

Per abilitare l’integrazione tra Microsoft Cloud App Security ed Azure Information Protection è sufficiente andare sul portale di amministrazione di MCAS tramite il collegamento https://portal.cloudappsecurity.com, premere sul cogwheel -> Settings

Figura 13 – Settings MCAS

A questo punto portarsi in Information Protection -> Azure Information Protection e abilitare l’integrazione.
Nell’articolo Come classificare e proteggere le informazioni con le Sensitivity Labels di Office 365 Security & Compliance abbiamo evidenziato che Azure Information Protection funziona apponendo dei metadati in chiaro ai files indipendentemente dal fatto che essi siano protetti o meno. MCAS utilizza questi metadati nelle sue decisioni sulle azioni da intraprendere. Raccomando inoltre di impostare l’opzione di scansionare solo files provenienti dal proprio tenant, in quanto MCAS potrebbe trovare dei files protetti da policy non esistenti in questo tenant, provenienti da altre Organizzazioni che utilizzano AIP.

Se si desidera che MCAS sia in grado di scansionare anche files protetti da un template AIP (raccomandato) allora concedere i diritti richiesti: in tal caso MCAS sarà in grado di ottenere lo usage right per il documento che si appresta a scansionare.

Figura 14- Integrazione MCAS / AIP

Di seguito è possibile vedere l’integrazione al lavoro: eseguendo in MCAS una ricerca dei files utilizzando le label definite nello Unified Label Store (che MCAS sincronizza ogni ora) vengono restituiti i risultati nei datastore per i quali è abilitata.

Figura 15 – Ricerca Files MCAS

Così come è possibile, direttamente dalla console di MCAS, applicare una classificazione ad un documento non classificato

Figura 16 – Ricerca File

Figura 17 – Classificazione manuale di un file

Le policy di MCAS, assieme allo scanner di AIP e la classificazione automatica dei documenti del client di AIP permettono una copertura massima ed una estrema flessibilità all’interno di una strategia di Information Protection.

Reportistica

Azure Information Protection offre potenti strumenti di reportistica tramite la funzionalità di Central Reporting, che aggrega i dati provenienti dalle seguenti sorgenti in un workspace Azure Log Analytics:

• I client di Azure Information Protection
  • Il client integrato in Microsoft Office non invia i dati al Central Reporting in Azure ma solamente al Security & Compliance Center, pertanto Microsoft raccomanda di installare sempre il client di Azure Information Protection e non utilizzare quello integrato in Office se non per scenari molto basici.
  • Il client di AIP configurato come scanner invia i dati al Central Reporting
    
• Microsoft Cloud App Security
• Computer Windows 10 inseriti nel servizio Microsoft Defender Advanced Threat Protection
• I log interni della piattaforma Azure Information Protection (protection usage logs, che prima andavano scaricati tramite PowerShell e correlati manualmente)

Data la dipendenza da Azure Log Analytics la funzionalità non è abilitata per impostazione predefinita: dal portale Microsoft Azure portarsi sulla blade di Azure Information Protection e selezionare Configure analytics.

Selezionare quindi un workspace Log Analytics preesistente o crearne uno ad-hoc, la spunta “Enable deeper analytics…” serve per configurare i clienti ad inviare il dato completo che è stato identificato come sensitive data ed ha effetto solo sui client classici (che saranno deprecati il 31 marzo 2021 e non sono più disponibili sul portale di download) mentre per i client sulla Unified Label Platform va configurata all’interno di una Label Policy tramite PowerShell. Per esempio, se viene trovato un numero di carta di credito, non viene solo segnalato l’evento dal client ma il dato viene anche inviato e memorizzato nel log: questo aspetto va tenuto in debita considerazione.

Figura 18 – Abilitazione Central Reporting

Dopo quale giorno di utilizzo sarà possibile esplorare le dashboard fornite:

Usage Report: permette di visualizzare quali label vengono applicate, per quale tipologia di contenuto (documenti, e-mail), su quali devices e con quali applicazioni

Figura 19 – Usage Report

Activity Logs: raccoglie i dati inerenti all’attività di classificazione, protezione ed eventuale rimozione delle stesse da parte degli utenti. Registra gli accessi ai documenti protetti da AIP e l’attività di discovery da parte di Windows Defender ATP.

In Figura 19 è possibile osservare un evento di discovery:

Figura 20 – Discovery AIP

Mentre in Figura 21 è mostrato un evento di accesso ad una mail con una Sensitivity Label applicata

Figura 21 – Accesso ad un documento classificato

Data discovery: visualizza in maniera aggregata i risultati ricevuti dai files scansionati dagli scanner, i computer Windows 10 con Defender ATP, i client AIP e quali tipi di informazioni sensibili sono presenti all’interno dei files e dei loro repositories.

Figura 22 – Data Discovery

I report sono interattivi: è possibile quindi esplorare in profondità, ad esempio, su un singolo endpoint

Figura 23 – Data discovery – drill down su endpoint

Recommendations: la piattaforma è in grado di esprimere suggerimenti per la creazione di nuove label, sulla base dei dati sensibili scoperti nel nostro dataset oppure l’aggiunta di percorsi che non stiamo monitorando

Conclusioni

Le Sensitivity Labels e l’integrazione di Azure Information Protection nella Unified Label Platform sono un grande passo in avanti nella trasformazione di Office 365 / Microsoft 365 in una piattaforma che è più della somma delle sue parti: non si limitano ad essere solo un insieme di prodotti nati on-premises e portati in Cloud.

Microsoft sono anni che fa un ampio uso di Azure nella realizzazione di nuove soluzioni e nell’aggiornamento delle esistenti e lo vediamo anche qui: il Central Reporting poggia su Log Analytics il quale richiede una subscription Azure e avrà dei costi ricorrenti di cui è bene essere a conoscenza, Microsoft stima circa 20GB al mese ogni 10.000 utenti.

L’aggiunta delle Sensitivity Labels ai Microsoft 365 groups sono un’ottima notizia per quelle organizzazioni che gestivano manualmente gli scenari di “accesso guest” e “accesso da device non gestito a SharePoint Online“: finalmente si elimina la discrepanza in cui gli utenti sono in grado di creare dei gruppi autonomamente e poi il reparto IT deve tentare di indovinare la sensibilità di un gruppo per applicare le policy corrette. Ora, tutto il processo è in mano agli utenti.