Il problema di design: rilevare senza sorvegliare

Un architetto SC-100 non progetta l’insider risk come un sistema di sorveglianza, ma come un controllo di rischio bilanciato: massimizzare il segnale utile per identificare esfiltrazione, sabotaggio o fuga accidentale di dati, minimizzando l’impatto sulla privacy dei dipendenti e l’esposizione legale dell’organizzazione. La domanda ricorrente è: dato questo requisito di protezione del dato, quale combinazione di controlli raccomandi e con quale postura di privacy?

Il dominio si articola su tre capacità di Microsoft Purview che vanno progettate insieme, non a silo: Insider Risk Management (IRM), Data Loss Prevention (DLP) e Information Protection (sensitivity label). L’errore architetturale più comune è trattarle come prodotti separati anziché come un unico pipeline di classificazione → policy → rilevamento → risposta.

Insider Risk Management: segnali vs. privacy

IRM correla segnali eterogenei — attività su endpoint (download, copia su USB, upload cloud), eventi DLP, movimenti HR (dimissioni imminenti, performance review), e segnali di Microsoft Defender — per assegnare un risk score all’utente. Più ricco è il set di segnali, più accurato il rilevamento; ma più invasiva la raccolta.

Il pattern privacy-by-design raccomandato:

  • Pseudonimizzazione: attivare l’opzione che sostituisce nome, email e path con identificativi anonimi nell’interfaccia degli analisti. Il de-anonimizzato è possibile solo tramite ruolo dedicato e con audit. Questo è quasi sempre la risposta corretta quando lo scenario cita “GDPR”, “works council”, “rappresentanze sindacali” o operazioni in EU/Germania.
  • RBAC granulare sui casi: separare i ruoli Insider Risk Management Analyst (indaga alert senza vedere identità) e Investigator (accede al contenuto e all’identità reale). Segregazione dei doveri: chi definisce le policy non deve poter chiudere i propri casi.
  • Scoping e HR connector: usare gli indicatori HR come trigger event (es. dimissioni) invece di monitorare tutti indistintamente riduce i falsi positivi e la superficie di sorveglianza.

Il trade-off è netto: una policy che monitora l’intera popolazione con tutti i segnali attivi genera alert fatigue, rischio legale e nessun valore investigativo. La scelta d’esame è quasi sempre template mirati (Data theft by departing users, Data leaks) su scope definiti, non monitoraggio universale.

DLP: dove applicare il controllo

Il DLP di Purview è unificato su più location: Exchange, SharePoint/OneDrive, Teams, endpoint (Endpoint DLP) e app cloud via Defender for Cloud Apps. La decisione architetturale è dove intercettare il dato:

  • Endpoint DLP copre azioni locali (copia su USB, stampa, upload su browser, incolla in app non gestite) — indispensabile per esfiltrazione fisica.
  • DLP via Defender for Cloud Apps governa app SaaS di terze parti e shadow IT, dove le sensitivity label da sole non arrivano.
  • La classificazione deve basarsi su sensitivity label e trainable classifier / SIT, non solo su regex: la label rende la protezione persistente (crittografia, watermark) che segue il file fuori dal tenant.

La sinergia chiave è DLP → IRM: le violazioni DLP alimentano il risk score. Un design che tiene DLP e IRM scollegati perde il segnale più prezioso.

Integrazione con Conditional Access

Il punto architetturale più sofisticato: Adaptive Protection. IRM classifica gli utenti in livelli di rischio (elevated/moderate/minor) e questi livelli diventano condizione in Entra ID Conditional Access e in DLP. Un utente che scala a rischio elevato può essere forzato a re-autenticazione, bloccato dal download o limitato nell’accesso ai siti sensibili — in automatico e in modo reversibile quando il rischio decade. Questo trasforma il rilevamento passivo in risposta dinamica, allineandosi al pilastro Security del Well-Architected Framework (difesa in profondità, least privilege dinamico) senza penalizzare l’intera popolazione (Operational Excellence, Cost Optimization: meno controlli statici e costosi).

Trappole tipiche d’esame

  • Requisito: rilevare furto dati da dipendenti in uscita rispettando GDPR/works council → IRM con template Data theft by departing users + pseudonimizzazione attivata + RBAC che separa Analyst e Investigator. Non un monitoraggio esteso in chiaro.
  • Requisito: bloccare copia di file classificati su USB e app cloud personali → Endpoint DLP per l’azione locale + Defender for Cloud Apps per lo shadow IT, con policy basate su sensitivity label, non solo SIT/regex.
  • Requisito: rendere adattivo l’accesso in base al comportamento a rischio → Adaptive Protection: livelli di rischio IRM come segnale in Conditional Access e DLP. Non ACL statiche né gruppi manuali.
  • Requisito: la policy IRM genera troppi alert e lamentele → restringere lo scope, usare trigger event (HR connector) e template mirati; ridurre i segnali, non aumentarli. Policy troppo aggressiva = anti-pattern.
  • Requisito: la protezione deve seguire il file fuori dal tenant → sensitivity label con crittografia, non DLP da solo: il DLP agisce ai confini, la label protegge il contenuto ovunque.