Insider Risk Management: rileva e segnala, non blocca
Microsoft Purview Insider Risk Management serve a individuare i rischi che nascono dentro l’organizzazione: furto di proprietà intellettuale, fuga di dati, violazioni delle regole di sicurezza. Non impedisce nessuna azione: correla segnali, assegna un punteggio di rischio e produce alert che una persona deve leggere. Questa è la prima distinzione che l’esame ti chiede di riconoscere.
Ogni policy nasce da un policy template, cioè un insieme predefinito di condizioni che stabilisce quali indicatori usare e come pesarli; una policy senza template non esiste. Fra i template disponibili trovi Data theft by departing users, Data leaks, Data leaks by priority users, Data leaks by risky users, Security policy violations e, per chi amministra l’AI, Risky AI usage e Risky Agents. Risky AI usage valuta prompt e risposte che contengono informazioni sensibili in Microsoft 365 Copilot, in Microsoft Copilot e negli agenti, oltre alla navigazione verso siti di AI generativa; Risky Agents osserva gli agenti ospitati su Microsoft Copilot Studio e Microsoft Foundry.
Due termini da non confondere. Gli indicators sono i tipi di attività a cui la policy assegna un punteggio di rischio, per esempio scaricare file da un sito SharePoint o copiarli su uno storage personale. I triggering events sono invece le condizioni che portano un utente dentro il perimetro della policy: una data di dimissioni importata dal HR connector, la cancellazione dell’account in Microsoft Entra, oppure un alert DLP di gravità alta. Un utente incluso nella policy ma senza triggering event non viene valutato. Indicare come priority content un sito SharePoint, un sensitivity label o un sensitive information type alza il punteggio delle attività collegate e quindi anche il livello di gravità dell’alert.
Quando gli indicatori corrispondono, l’alert nasce con stato Needs review. Chi fa triage lo trova nell’Alerts dashboard e lo chiude in tre modi: aprendo un nuovo case, assegnandolo a un case esistente, o scartandolo. Dentro il case ci sono la timeline User activity e il Content explorer del case, che raccoglie file e messaggi legati all’alert: attenzione, non è il content explorer della data classification. Le azioni finali vanno da un avviso all’utente costruito su un notice template all’escalation verso eDiscovery (Premium).
Gli alert di DLP e le azioni di chi li gestisce
Microsoft Purview Data Loss Prevention (DLP) è l’altra metà della coppia, e qui lo strumento previene davvero l’azione. Sulla location Microsoft 365 Copilot and Copilot Chat, per esempio, l’azione Prevent Copilot from processing content con l’opzione Processing prompts fa sì che Copilot non risponda a un prompt che contiene i sensitive information type indicati.
Gli alert si configurano nelle regole della policy, nella sezione Incident reports, e possono essere single-event (uno per ogni corrispondenza, utile per eventi rari e gravi) o aggregate-event (uno quando si supera una soglia in una finestra di tempo). Sul dove guardarli la documentazione è esplicita: gli alert DLP si possono investigare e gestire sia nel dashboard di Microsoft Defender XDR sia nel Microsoft Purview portal, ma Defender XDR è la sede raccomandata per investigare e gestire, mentre il portale Purview è quello raccomandato per creare e modificare le policy. Nel dettaglio di un alert chi indaga legge DLP policy matched, rule matched, i sensitive information types (SIT) detected, le azioni compiute e se l’utente ha aggirato la policy tramite un policy tip, con la giustificazione che ha scritto.
Communication Compliance: violazioni nei messaggi
Microsoft Purview Communication Compliance rileva messaggi potenzialmente inappropriati: anche questo strumento segnala e non blocca a monte. Copre Exchange Online, Microsoft Teams, Microsoft 365 Copilot and Microsoft 365 Copilot Chat, Viva Engage e sorgenti di terze parti; i prompt e le risposte dell’AI sono quindi materiale da riesaminare come una email. I template pronti includono Detect inappropriate text, Detect inappropriate images, Detect sensitive info types, Detect financial regulatory compliance, Detect conflict of interest e Custom policy.
Il riesame avviene nella pagina Alerts e nelle schede Pending e Resolved della policy. Il revisore può fare Resolve, applicare un tag al messaggio (Compliant, Non-compliant, Questionable), Notify the user, Escalate to another reviewer, Report as misclassified, rimuovere il messaggio in Teams, o escalare a eDiscovery (Premium). I nomi utente sono pseudonimizzati per impostazione predefinita.
DSPM for AI: vedere che uso si fa dell’AI
Nel Microsoft Purview portal, sotto Solutions, trovi DSPM for AI (classic) e la versione attuale chiamata semplicemente DSPM (Data Security Posture Management). È il posto da cui si scopre quali interazioni con l’AI avvengono nel tenant. Le pagine tipiche sono Overview, Recommendations, Reports, Policies, Activity explorer e Data risk assessments; le app sono raggruppate in Copilot experiences and agents, Enterprise AI apps e Other AI apps. In Activity explorer compaiono eventi come AI interaction, Sensitive info types e AI website visit.
Il punto che l’esame verifica: DSPM for AI non blocca un prompt. Scopre, misura e raccomanda, e le sue policy con un clic appartengono ad altre soluzioni — la raccomandazione Detect risky interactions in AI apps crea una policy Risky AI usage in Insider Risk Management, mentre Protect items with sensitivity labels from Microsoft 365 Copilot and agent processing crea una policy DLP. Il blocco resta di DLP; il rilevamento del comportamento resta di Insider Risk Management e Communication Compliance.