Progettare l’information protection come sistema, non come feature

Da architect il punto di partenza non è “quale label creo”, ma quale dato protegge quale requisito. In SC-100 la data protection si progetta partendo dal ciclo di vita del dato (know → protect → prevent loss → govern) e mappandolo sui pilastri Security e Operational Excellence dell’Azure Well-Architected Framework. Microsoft Purview è il piano di controllo unificato: sensitivity labels per la classificazione e la protezione persistente, DLP per prevenire l’esfiltrazione, e immutable storage per i requisiti di conservazione WORM.

Sensitivity labels: classificazione + encryption che segue il dato

Le sensitivity labels di Purview sono l’unico controllo la cui protezione viaggia con il file (encryption + usage rights via Azure RIN Rights Management), indipendentemente da dove il documento finisce — mail, SharePoint, endpoint, o un tenant esterno. Questo è il motivo per cui, quando il requisito è “il dato deve restare protetto anche se esce dal perimetro”, la risposta è label con encryption, non una policy DLP (che blocca il transito ma non cifra il contenuto a riposo altrove).

Decisioni chiave di design:

  • Encryption con permessi assegnati (gruppi/ruoli predefiniti) per dati altamente regolamentati; encryption “let users assign” (Do Not Forward, permessi custom) quando serve flessibilità collaborativa.
  • Double Key Encryption (DKE) solo per il sottoinsieme più critico soggetto a sovranità/regolatorio estremo: aggiunge una chiave controllata dal cliente ma rompe co-authoring, ricerca server-side e DLP sul contenuto. È un trade-off pesante — non è il default.
  • Container labeling (SharePoint site, Teams, gruppi) per governare il contenitore, distinto dal file/email labeling che protegge il singolo item.

Auto-labeling vs user-driven: il trade-off accuratezza/adozione

Questo è il confronto architetturale centrale.

  • Labeling user-driven: massima adozione culturale e responsabilizzazione, ma accuratezza incoerente — dipende dall’utente. Va supportato da label di default, mandatory labeling e giustificazione al downgrade.
  • Auto-labeling client-side (Office app): suggerisce/applica in base a sensitive info types (SIT), EDM o trainable classifiers mentre l’utente scrive. Buon compromesso, ma applicabile solo dove l’app lo supporta.
  • Auto-labeling service-side (SharePoint, OneDrive, Exchange): applica label at rest e in transito senza intervento utente, ideale per il dato già esistente e per garantire copertura sui repository. Non richiede interazione ma non educa l’utente.

Raccomandazione di design: modello ibrido. Auto-labeling service-side per bonificare lo storage esistente e coprire i canali, user-driven con default + mandatory per il nuovo contenuto, e la classificazione automatica come “rete di sicurezza”. Prima di andare in enforcement, girare l’auto-labeling in simulation mode per misurare i falsi positivi.

DLP multi-canale: audit prima di enforce

Il DLP di Purview copre Exchange, SharePoint/OneDrive, Teams, endpoint (Endpoint DLP), browser e app cloud via Defender for Cloud Apps. La condizione più robusta non è il pattern testuale ma “content contains sensitivity label X”: si classifica una volta e il DLP eredita la decisione, evitando di duplicare la logica di rilevamento.

Il principio operativo (pilastro Operational Excellence) è fasare il rollout: partire in audit-only / policy tips, misurare volumi e falsi positivi, poi passare a block with override e infine a block duro solo sui canali e sui dati dove il segnale è pulito. Un DLP messo direttamente in blocco genera un’ondata di falsi positivi, ticket e — peggio — shadow workaround degli utenti, che erode la fiducia nel programma.

Immutable storage e requisiti WORM

Per conservazione legale/regolatoria (SEC 17a-4, GDPR retention, audit finanziari) il controllo è immutable storage: Azure Blob time-based retention o legal hold, e per la posta/documenti retention labels con record management (declare as record / regulatory record). Trade-off da conoscere: la regulatory record e il locked time-based policy rendono il dato realmente non-cancellabile e non-modificabile — impossibile da rimuovere anche per un admin, il che è esattamente il requisito ma va dimensionato con attenzione ai costi e all’irreversibilità.

Trappole tipiche d’esame

  • Requisito: “il documento deve restare cifrato anche se inviato a un partner esterno” → Sensitivity label con encryption, non una DLP policy (la DLP controlla il transito, non protegge il file a riposo altrove).
  • Requisito: “ridurre i falsi positivi e non bloccare la produttività al go-live del DLP” → avviare in audit mode / policy tips, poi block with override, enforcement duro solo dopo la fase di misurazione.
  • Trappola: schema di label troppo granulare (decine di sotto-label) → adozione crolla e classificazione diventa incoerente → progettare una tassonomia scalabile a 4-5 livelli (es. Public, General, Confidential, Highly Confidential) con eventuali sub-label mirate.
  • Requisito: “classificare automaticamente i milioni di file già presenti in SharePoint” → auto-labeling service-side, non client-side (che agisce solo sul nuovo contenuto in Office).
  • Requisito: “i record finanziari non devono essere alterabili né cancellabili per 7 anni, nemmeno da un admin” → immutable storage WORM (time-based retention lock / regulatory record), non una semplice retention label modificabile.
  • Trappola DKE: scelta come default “per massima sicurezza” → rompe co-authoring, DLP e ricerca server-side; riservarla al solo sottoinsieme ultra-critico.