Quattro leve, quattro verbi diversi
Il dominio Govern and secure mette in fila quattro strumenti di Microsoft Purview che sembrano intercambiabili e non lo sono. Prima ancora dei menu, fissa i verbi: una sensitivity label classifica e protegge il contenuto, una policy di Data Loss Prevention (DLP) impedisce un’azione, la retention decide per quanto tempo un elemento si conserva, e DSPM for AI osserva e raccomanda ma non blocca nulla di suo. L’esame AB-650, che al momento è in beta e si supera con 700, tende a formulare gli obiettivi come “identify requirements”: ti descrive un’esigenza a parole e ti chiede quale leva la soddisfa. “Gli utenti non devono poter incollare numeri di carta in un prompt” è DLP; “i documenti riservati devono restare cifrati anche fuori dal tenant” è una sensitivity label; “le conversazioni con Copilot vanno conservate tre anni” è il data lifecycle management. Sbagliare leva è l’errore che costa di più.
Information protection: il tipo di informazione e l’etichetta
Il mattone di base è il sensitive information type (SIT), un classificatore basato su pattern che riconosce dati come numeri di carta di credito o codici fiscali. I SIT si dividono in built-in, named entity (in versione un-bundled più stretta e bundled più ampia), custom e exact data match (EDM). Ogni SIT ha Name, Description e Pattern, e il pattern combina primary element, supporting element, confidence level e proximity: l’elemento di supporto deve trovarsi entro un certo numero di caratteri da quello primario perché il match valga. I tre confidence level sono low, medium e high, con valori rispettivamente 65, 75 e 85; high produce meno falsi positivi ma più falsi negativi. Gli stessi SIT vengono riusati da DLP, dalle sensitivity label, dalle retention label e dall’auto-labeling: impararli una volta serve ovunque.
Il SIT dice che cosa c’è dentro; la sensitivity label decide come proteggerlo. Un’etichetta può applicare encryption, aggiungere content markings (watermark, header, footer), proteggere container come SharePoint sites, Teams e Microsoft 365 Groups, impostare il default sharing link, ed essere applicata automaticamente o solo raccomandata. Quando crei l’etichetta ne scegli lo scope fra Files & other data assets, Emails, Meetings e Groups & sites. L’etichetta viene scritta in chiaro nei metadati del file o del messaggio, quindi resta attaccata al contenuto anche quando si sposta, e ogni elemento può averne una sola. Conta anche l’ordine: nella pagina Labels l’etichetta più restrittiva va in fondo alla lista.
Qui casca la prima confusione tipica: l’etichetta non è la sensitivity label policy. L’etichetta definisce le protezioni; la policy la pubblica a utenti e gruppi e porta impostazioni proprie, come lo specificare una default label, il Require a justification for changing a label e il Require users to apply a label, cioè il mandatory labeling. Se un utente ricade in più policy le riceve tutte, e in caso di conflitto vince quella con il numero d’ordine più alto.
DLP: le sedi da coprire, Copilot compreso
Una policy DLP si costruisce scegliendo che cosa monitorare, un eventuale administrative unit come ambito, dove monitorare, le condizioni e le azioni. Le location includono Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, i device Windows 10, Windows 11 e macOS, le istanze di Microsoft Defender for Cloud Apps, i repository on-premises, Fabric e Power BI, e Microsoft 365 Copilot. Ogni sede ha prerequisiti propri: Exchange basta configurarla, mentre Endpoint DLP richiede che i dispositivi siano onboardati, e la policy si applica solo se sia l’utente sia il device rientrano nell’ambito. Prima di attivare i blocchi si usa la simulation mode, perché, come dice la documentazione, “Actions defined in a policy aren’t applied while the policy is in simulation mode”.
La sede da studiare con più attenzione è Microsoft 365 Copilot and Copilot Chat, disponibile solo nel template Custom e che, quando la selezioni, disabilita tutte le altre location della stessa policy; non supporta gli admin units. Le condizioni supportate sono Content contains con Sensitivity labels oppure con Sensitive information types, e Email is received from con External users; l’azione è Prevent Copilot from processing content, declinabile in Processing prompts e in Performing Web Searches. Attenzione a due dettagli d’esame: non puoi usare la condizione sui SIT e quella sulle sensitivity label nella stessa rule (due rule nella stessa policy sì), e DLP non ispeziona il contenuto dei file caricati dentro un prompt, ma solo il testo digitato.
Quando una rule scatta e la policy è configurata per generarli, arrivano gli alert. Il ciclo di vita è Trigger, Notify, Triage, Investigate, Remediate, Tune. Gli alert compaiono nel DLP alerts dashboard del portale Purview, dove restano 30 giorni e dove puoi impostare lo stato Investigating, e come incident nel Microsoft Defender portal, dove la storia è conservata sei mesi e dove filtri la coda con Service Source: Data Loss Prevention. Il triage separa veri e falsi positivi; la fase Tune ti riporta a correggere ambito, condizioni, azioni e notifiche.
Retention e DSPM for AI: conservare e osservare
Il data lifecycle management lavora con due sole azioni, retain e delete, combinabili in retain-only, delete-only, retain and then delete. Una retention policy assegna le impostazioni a livello di sede (mailbox, sito, account) e le sue location comprendono anche Microsoft Copilot experiences, Enterprise AI apps e Other AI apps; una retention label le assegna a livello di singolo elemento e, a differenza della policy, viaggia con il contenuto dentro il tenant. Le etichette diventano disponibili tramite una retention label policy, mentre una auto-apply retention label policy le applica da sola quando le condizioni sono soddisfatte. Se più impostazioni entrano in conflitto valgono i principi di retention: “retention always takes precedence over permanent deletion, and the longest retention period wins”. La retention non è né una sensitivity label né un backup: non cifra e non è Microsoft 365 Backup, che è un prodotto distinto.
Resta DSPM for AI, che nel portale Purview è il punto centrale da cui vedere l’uso dell’AI: report sulle interazioni, Recommendations, Activity explorer con eventi come AI interaction e AI website visit, una pagina Apps and agents e le Data risk assessments, con una valutazione predefinita che gira settimanalmente sui primi 100 siti SharePoint per utilizzo. Nella versione corrente di DSPM questa area si è ampliata con l’AI observability, che inventaria le app e gli agenti AI attivi. Il punto da non sbagliare è che DSPM for AI mostra il rischio e propone policy con un clic, ma l’enforcement resta altrove: è la sensitivity label che protegge il file, è la policy DLP che nega l’azione, è la retention che decide quanto si conserva.