Perché la governance del portale Purview è un tema d’esame
In MS-102 le domande su Microsoft Purview raramente chiedono “come si crea una policy DLP”. Chiedono invece chi può crearla, chi può vederne i risultati e come si dimostra che funziona. Sono tre problemi distinti, con tre superfici amministrative distinte.
I role group di Microsoft Purview
Purview ha un proprio sistema RBAC, separato dai ruoli di directory di Microsoft Entra ID. I role group vivono nel portale Purview (Settings > Roles and scopes > Role groups) e assegnano permessi sulle sole funzionalità di compliance.
| Role group | Cosa consente | Quando assegnarlo |
|---|---|---|
| Compliance Administrator | Configurazione completa di DLP, retention, sensitivity label, Insider Risk; accesso ai case eDiscovery | Owner della funzione compliance |
| Compliance Data Administrator | Come sopra ma con enfasi su gestione dei dati e device; non include tutti i permessi di case management | Chi opera su classificazione e device onboarding |
| eDiscovery Manager | Crea e gestisce i propri case, esegue search, export | Legal/investigatori operativi |
| eDiscovery Administrator | Sottoinsieme di eDiscovery Manager con accesso a tutti i case dell’organizzazione | Escalation, sblocco case orfani |
| Records Management | Retention label con azione di record declaration, file plan, disposition review | Records manager / archivista |
| Content Explorer Content Viewer | Lettura del contenuto degli item classificati | Solo su necessità documentata |
| Content Explorer List Viewer | Lettura dell’elenco degli item, senza aprire il contenuto | Analisi di copertura senza esposizione |
| Data Classification Content Viewer | Visualizzazione contenuto in activity/content explorer | Verifica falsi positivi |
Il pattern chiave: i due ruoli di content explorer sono separati proprio per consentire l’analisi quantitativa senza accesso al dato.
Separazione dei compiti rispetto a Entra ID
Il Global Administrator di Entra ID può entrare nel portale Purview e assegnare role group, ma non eredita i permessi di lettura del contenuto. Deve aggiungersi esplicitamente ai role group di viewer — azione che lascia traccia nell’audit log e che quindi è verificabile.
Questo è il cuore del least privilege in Purview:
- Entra ID governa l’identità, Purview governa il dato.
- Un Compliance Administrator non può creare utenti o assegnare licenze.
- Un Global Administrator non dovrebbe essere l’operatore quotidiano: si usa PIM per l’elevazione just-in-time e si delegano i role group specifici.
- I role group Purview sono assegnabili a gruppi, ma non supportano scoping per unità amministrativa allo stesso modo di Entra ID: verificare sempre il perimetro dichiarato dal ruolo.
Verificare che la configurazione funzioni davvero
Creare una policy non significa che stia proteggendo qualcosa. Gli strumenti di validazione sono quattro, con scopi diversi.
Content explorer
Fotografia statica: mostra dove risiedono oggi gli item che corrispondono a un sensitive info type, a un trainable classifier o a una sensitivity label. Serve a rispondere a “quanti file con IBAN ho su SharePoint Online?”. Richiede i ruoli di viewer, non è coperto dai permessi amministrativi.
Activity explorer
Fotografia dinamica: mostra le azioni sugli item etichettati — label applicata, declassata, file copiato su USB, condiviso esternamente. È lo strumento per capire se gli utenti stanno aggirando la policy. Retention dei dati tipicamente 30 giorni.
Report DLP e alert policy
- DLP policy matches conta ogni match, anche quando la policy è in modalità simulazione: è la metrica per il tuning.
- DLP incidents conta gli eventi aggregati per item, utile per il volume reale.
- False positives and overrides è il report da leggere per capire se la regola è troppo aggressiva; presuppone che sia stata abilitata la user override con giustificazione.
- Le alert policy (Purview > Policies > Alert policies) generano notifiche con soglia e aggregazione; una policy DLP genera alert solo se l’opzione di incident report è attiva sulla regola.
Come si legge un falso positivo
Un match che l’utente ha giustificato come non pertinente indica quasi sempre confidence level troppo basso o instance count minimo troppo permissivo sul sensitive info type. La correzione operativa è alzare il confidence level (es. da 65 a 85) o aumentare il numero minimo di istanze, poi rimettere la policy in simulation mode e ri-misurare prima di riattivare l’enforcement.
Trappole tipiche d’esame
- Scenario: un Global Administrator apre content explorer e vede i conteggi ma non riesce ad aprire i file. → Risposta: assegnare esplicitamente il role group Content Explorer Content Viewer; il ruolo Entra ID non conferisce accesso al contenuto.
- Scenario: si modifica una policy DLP e cinque minuti dopo il report non mostra cambiamenti. → Risposta: attendere la propagazione (fino a 24 ore per DLP e sensitivity label, i report hanno un ulteriore ritardo di aggregazione). Non ricreare la policy.
- Scenario: un legale deve gestire solo i propri case senza vedere quelli altrui. → Risposta: eDiscovery Manager, non eDiscovery Administrator.
- Scenario: serve analizzare quanti documenti sensibili esistono senza che l’analista possa leggerli. → Risposta: Content Explorer List Viewer (elenco sì, contenuto no).
- Scenario: alto numero di override giustificati dagli utenti su una regola DLP. → Risposta: alzare confidence level o instance count del sensitive info type e ritestare in simulation mode, non disattivare la policy.