Quattro domande, quattro strumenti

Questo pezzo del dominio non chiede di configurare Microsoft Purview: chiede di riconoscere quale strumento risponde a quale domanda. Sono quattro domande distinte.

  • Quanto siamo conformi e che cosa conviene fare adesso? → Microsoft Purview Compliance Manager
  • Dove si trova il contenuto sensibile e con quale etichetta? → data explorer
  • Che cosa hanno fatto le persone su quel contenuto? → activity explorer
  • Dov’è quel file o quel messaggio che ci è stato richiesto? → Content search in eDiscovery

Vivono tutti nel Microsoft Purview portal, ma sono solution distinte, con permessi distinti. La difficoltà dell’esame non è la procedura: è lo scambio fra strumenti dal nome simile.

Compliance Manager: un punteggio e una lista di azioni

Compliance Manager valuta e gestisce la conformità nell’ambiente multicloud. Assegna punti quando completi una improvement action e li somma in un compliance score basato sul rischio; il punteggio di partenza deriva dal Microsoft 365 data protection baseline. Gli elementi da riconoscere sono quattro: i controls (il singolo requisito di una norma), gli assessments (un gruppo di controls per una specifica norma), le regulations (la libreria di template normativi pronti) e le improvement action, che portano la guida operativa e possono essere assegnate a un owner, con Implementation status, Test status e una scheda Evidence per documenti e link. Alcune azioni si testano a mano, altre in automatico grazie ai segnali che Compliance Manager riceve da altre solution Purview, da Microsoft Secure Score e da Microsoft Defender for Cloud.

Qui vive il distrattore più costoso del dominio. Microsoft Secure Score non misura la conformità: è una misura della postura di sicurezza dell’organizzazione, sta nel Microsoft Defender portal e propone recommended actions. L’Identity Secure Score è espresso in percentuale, sta nel Microsoft Entra admin center e rappresenta la parte identità del Microsoft Secure Score. Attenzione: anche l’Identity Secure Score chiama le sue voci improvement action, quindi il termine da solo non distingue nulla. Il discriminante è l’oggetto misurato — conformità normativa, sicurezza complessiva, sicurezza delle identità — e il portale in cui lo strumento vive.

Data explorer e activity explorer: lo stato contro le azioni

Data explorer mostra uno scatto attuale degli elementi che hanno una sensitivity label, una retention label oppure sono stati classificati come sensitive information type o da un trainable classifier. Risponde alla domanda “dove si trova questo contenuto”: si naviga per Data source fino al singolo elemento, si filtra per nome di etichetta o di SIT, si esporta l’elenco. Lo trovi sotto Information Protection > Explorers. L’accesso è deliberatamente ristretto perché consente di leggere il contenuto analizzato: Data Explorer List viewer fa vedere elemento e posizione, Data Explorer Content viewer ne fa aprire il contenuto, e i due ruoli non sono cumulativi.

Non confonderlo con il content explorer, che la documentazione chiama Content Explorer (classic) e colloca sotto Data Lifecycle Management > Explorers, con i role group paralleli Content Explorer List viewer e Content Explorer Content viewer. Mostra lo stesso tipo di inventario: se una domanda ti mette davanti entrambi, guarda il nome esatto e la solution che lo ospita.

L’activity explorer risponde a un’altra domanda: non dove sta il contenuto, ma che cosa è stato fatto. La doc lo descrive come “a historical view of activities on your labeled content”, alimentata dai Microsoft 365 unified audit logs, e riporta fino a 30 giorni di dati. Si lavora per filtri (Date range, Activity type, Location, Sensitivity label, User) e per filter sets predefiniti come Endpoint DLP activities o Egress activities; fra le attività compaiono Label applied, Label changed, File read e i match delle policy DLP. Non è una vista in tempo reale: dipende dai tempi dell’audit log, quindi una vista vuota subito dopo l’attivazione di una policy di solito significa che i dati non sono ancora arrivati, non che la policy non funzioni.

Content search in eDiscovery: trovare l’elemento preciso

Quando arriva una richiesta legale o interna che nomina persone, date e parole chiave, lo strumento è la ricerca in Microsoft Purview eDiscovery. Una sola ricerca copre Exchange Online, SharePoint, OneDrive, Microsoft Teams, Microsoft 365 Groups e Viva Engage, e i risultati si possono esportare o mettere sotto hold. La query si costruisce col condition builder guidato oppure in Keyword Query Language; prima di esportare, Statistics e Sample dicono quanti elementi e quali location sono stati colpiti.

Il nome Content search resta, ma il posto è cambiato: la vecchia solution separata è confluita nell’esperienza di ricerca di eDiscovery e tutte le content search stanno in un unico case chiamato Content Search. Per Copilot conta un fatto: prompt e risposte delle applicazioni AI sono conservati nella mailbox dell’utente, quindi si trovano con una ricerca eDiscovery, usando la condizione Item class con l’opzione Copilot activity.

All’esame la domanda tipica è uno scenario di una riga. “Quanti documenti etichettati Confidential ci sono in questo sito?” è data explorer. “Chi ha declassato quell’etichetta la settimana scorsa?” è activity explorer. “Serve ogni messaggio di questa persona che contenga questa parola” è Content search in eDiscovery. “Quali azioni ci avvicinano a una norma e quanto valgono?” è Compliance Manager. Nessuna delle quattro risposte richiede di ricordare un percorso di menù: richiede di aver capito che la prima descrive uno stato, la seconda un’azione già avvenuta, la terza una consegna di prove e la quarta un programma di conformità.