Compliance Microsoft Purview con PowerShell: 10 script per le PMI

C’è una differenza che nel portale di Microsoft Purview non si vede, e che salta fuori solo quando qualcuno chiede le prove: la differenza fra una misura configurata e una misura che sta effettivamente proteggendo qualcosa.

Nel portale una policy di conservazione appare come una riga verde. Un’etichetta di riservatezza appare nell’elenco delle etichette. Una regola DLP appare fra le regole. Sono tutte lì, sembrano tutte attive — e nessuna delle tre schermate dice se stanno funzionando davvero.

Questi 10 script PowerShell servono a rispondere a quella domanda, in lettura e in pochi minuti.

Configurato non significa attivo

Tre scenari che incontriamo con regolarità sui tenant che prendiamo in gestione. Nessuno dei tre produce un errore, un avviso o una riga rossa da nessuna parte.

Una policy di conservazione che non copre quello che credi. Il cmdlet che elenca le retention policy espone un campo Workload che riporta sempre l’elenco completo dei workload possibili — Exchange, SharePoint, OneDrive, Teams — indipendentemente dall’ambito su cui la policy è realmente distribuita. Chi lo legge come “coperto tutto” ha una fotografia sbagliata del proprio perimetro di conservazione. L’ambito vero si ottiene solo chiedendo il dettaglio di distribuzione, che è quello che fa il primo script.

Un’etichetta di riservatezza che non protegge nulla. Creare un’etichetta e pubblicarla sono due operazioni distinte. Un’etichetta esistente ma mai inclusa in una policy di pubblicazione non arriva a nessun utente: non compare in Word, non compare in Outlook, non applica crittografia. Nell’elenco delle etichette però c’è, con il suo nome e il suo colore.

Una regola DLP rimasta in simulazione. Le policy DLP si attivano in modalità di test — con o senza notifiche — per misurare l’impatto prima di bloccare davvero. È la pratica corretta. Il problema è che la promozione in produzione è un passaggio manuale che nessuno fa scattare, e una policy in test mode registra gli eventi senza impedire niente. Dà l’illusione della protezione: è probabilmente il singolo scarto più frequente fra compliance dichiarata e compliance reale.

I 10 script, in 5 aree

Conservazione (retention)

• 01-Get-RetentionPolicyScope.ps1 — le policy di conservazione con l’ambito realmente applicato, non quello dichiarato: quali posizioni sono davvero incluse ed escluse.
• 02-Get-RetentionLabelsAndRules.ps1 — le etichette di conservazione e le regole collegate: durata, decorrenza, azione alla fine del periodo, se sono etichette di record.

Classificazione

• 03-Get-SensitivityLabelsAndPolicies.ps1 — le etichette di riservatezza e le policy di pubblicazione: a chi arrivano, quali sono obbligatorie, quali applicano crittografia o marcatura.
• 08-Get-CustomSensitiveInfoTypes.ps1 — i tipi di informazione sensibile personalizzati creati dall’organizzazione, distinti dalle centinaia predefinite, con l’indicazione di quali sono effettivamente richiamati da una regola DLP.

Prevenzione perdita dati (DLP)

• 04-Get-DlpPolicies.ps1 — le policy DLP con stato, modalità e posizioni coperte.
• 05-Get-DlpRulesDetail.ps1 — le regole nel dettaglio: condizioni, tipi di informazione richiamati, azioni, severità.

Il divario, e le indagini

• 06-Get-DlpPoliciesInTestMode.ps1 — le policy mai promosse da simulazione a produzione. Se dovessi eseguirne uno solo, esegui questo.
• 09-Get-ComplianceSearchInventory.ps1 — l’inventario delle ricerche eDiscovery già presenti nel tenant, con stato e perimetro.

Tracciabilità e sintesi

• 07-Get-UnifiedAuditLogStatus.ps1 — se il log di controllo unificato è abilitato e con quale conservazione. Senza quello non esiste alcuna evidenza forense di cosa è successo nel tenant.
• 10-Get-PurviewComplianceSummary.ps1 — il cruscotto che mette in fila i buchi delle quattro aree precedenti.

Tutti e dieci sono di sola lettura: nessuno modifica la configurazione del tenant. Ognuno è autonomo, parametrico e commentato, ed esporta un CSV.

La trappola del contesto di connessione

Un avvertimento che vale più di molte righe di documentazione: i cmdlet di Purview non vivono nella stessa sessione di quelli di Exchange Online. Connect-IPPSSession e Connect-ExchangeOnline aprono due contesti diversi che espongono cmdlet diversi, e un cmdlet chiamato nel contesto sbagliato semplicemente non esiste.

Nel toolkit ogni script dichiara nelle proprie note il contesto che gli serve, e il file di istruzioni riporta la mappa completa. Lo script sul log di controllo è il caso interessante: la verifica dell’abilitazione passa da Exchange Online, non dal contesto compliance, ed è un dettaglio che fa perdere tempo a chiunque lo affronti la prima volta.

Il flusso consigliato

1. Parti da 10 per la fotografia d’insieme.
2. Esegui 06 per scoprire cosa è in simulazione: è il divario più rapido da chiudere e il più rischioso da ignorare.
3. Esegui 07: se il log di controllo non è attivo, quello viene prima di tutto il resto — senza log non ci sono prove di nulla.
4. Esegui 01 per verificare che l’ambito della conservazione corrisponda a quello che l’azienda crede di avere.
5. Usa 03 e 08 per capire se il lavoro di classificazione già fatto è arrivato agli utenti o è rimasto in configurazione.

Scarica il toolkit

I 10 script sono in un archivio ZIP con un file di istruzioni che riporta prerequisiti, ruoli di sola lettura necessari e la mappa dei contesti di connessione: Toolkit PowerShell Purview compliance.

Nessuna registrazione. Uso interno aziendale gratuito, fornito “as is”.

Le evidenze che chiede un auditor

L’output di questi script è materiale utilizzabile direttamente in una verifica. Chi conduce un audit non chiede se avete Purview: chiede per quanto tempo conservate una determinata categoria di documenti, chi può accedervi, cosa impedisce che escano dall’organizzazione e come dimostrate quello che è avvenuto. Un CSV con date, ambiti e modalità risponde meglio di uno screenshot del portale.

È lo stesso principio dei lavori che abbiamo pubblicato in questi giorni sul fronte AI: un registro dei sistemi di AI e delle informative di trasparenza valgono se sono documenti mantenuti, non se sono dichiarazioni. La conservazione e la classificazione dei dati sono lo strato sotto: senza quelle, la governance dell’AI descrive processi che non esistono.

Se ti interessa il pezzo complementare — non “cosa è protetto” ma “cosa riesco a recuperare” — è nel toolkit su backup e continuità di Microsoft 365, che parte dal fatto che Microsoft 365 non include un backup nativo. Gli altri venti toolkit stanno nell’hub PowerShell.

Se preferisci delegare

Eseguire gli script è la parte facile. Decidere quali policy promuovere in produzione, con quale ambito e senza bloccare il lavoro delle persone è la parte che richiede esperienza: una regola DLP troppo aggressiva viene disattivata dall’IT entro una settimana, e a quel punto il divario si riapre.

Con l’assistenza cybersecurity gestita copriamo esattamente questo: portare la configurazione di Purview da “presente” a “attiva e sostenibile”, con le evidenze pronte per gli audit. Parla con un nostro consulente.