Le sensitivity label di Microsoft Purview sono metadati persistenti che viaggiano dentro il file o il messaggio: sopravvivono al download, al rename, al forward e all’uscita dal tenant. Sono lo strumento con cui MS-102 misura la capacità di tradurre un requisito di business (“i contratti non devono essere stampabili dai fornitori”) in una configurazione concreta.
Costruire la gerarchia
Le label si creano dal Microsoft Purview portal → Information Protection → Labels. Il modello tipico è una scala a 4-5 livelli (Public, General, Confidential, Highly Confidential) con sublabel che specializzano il livello padre per destinatario o scenario (Confidential\Anyone, Confidential\All Employees, Confidential\Specific People).
Regole strutturali da ricordare:
- Una label padre con sublabel non è applicabile direttamente: l’utente deve scegliere una sublabel.
- La gerarchia ammette un solo livello di annidamento.
- L’ordine nella lista determina la priorità: la label più in basso è considerata la più restrittiva. È questo ordinamento che governa upgrade e downgrade, non il nome.
Definire le protezioni
Ogni label è un contenitore di impostazioni; le principali:
| Protezione | Effetto | Uso tipico |
|---|---|---|
| Encryption — permessi assegnati ora | L’admin definisce utenti/gruppi e diritti d’uso (Viewer, Reviewer, Co-Author, Co-Owner o custom) dentro la label | Documenti a circolazione nota, protezione uniforme |
| Encryption — permessi definiti dall’utente | L’utente sceglie i destinatari al momento dell’applicazione (Do Not Forward, Encrypt-Only, o prompt in Word) | Collaborazione ad hoc con esterni |
| Content marking | Header, footer e watermark, anche dinamici con variabili tipo ${User.Name} e ${Item.Date} |
Deterrenza visiva, requisiti di compliance documentale |
| Scadenza / accesso offline | Il contenuto smette di essere accessibile dopo N giorni o senza connessione | Progetti a termine, dispositivi non gestiti |
L’encryption può includere il doppio scope: chi ha diritti d’uso ridotti non può stampare, copiare o estrarre contenuto anche con una copia locale del file.
Estendere lo scope
Nella creazione si sceglie a cosa la label si applica:
- Files & emails — Office desktop/web/mobile, PDF, e messaggi in Exchange Online.
- Groups & sites — Microsoft 365 Groups, Teams e siti SharePoint Online: qui la label non cripta, ma imposta privacy del gruppo, accesso guest, accesso da dispositivi non gestiti e condivisione esterna del sito. Richiede che le sensitivity label siano abilitate per i container (attivazione via PowerShell con
Execute-AzureAdLabelSynce le impostazioni Microsoft Entra ID sui gruppi unificati). - Schematized data assets — asset mappati nella Data Map (SQL, Azure Storage, Microsoft Fabric/OneLake): classificazione, non crittografia dei file.
- Meetings e Power BI/Fabric items come scope aggiuntivi.
Una label può avere sia lo scope file/email sia quello container: sono impostazioni indipendenti dentro la stessa label.
Pubblicazione e comportamento client
Le label diventano visibili solo tramite una label policy. Nella policy si definisce:
- Ambito: utenti e gruppi specifici (pubblicazione mirata). Chi non è nella policy semplicemente non vede la label.
- Label predefinita per documenti, email e nuovi container.
- Obbligo di etichettatura (mandatory labeling): nessun salvataggio o invio senza label.
- Giustificazione per il downgrade o la rimozione della label: l’evento viene registrato e finisce in audit.
- Link a una pagina di help personalizzata.
La propagazione richiede tipicamente fino a 24 ore sui client.
Auto-labeling: client-side vs service-side
- Client-side (auto-labeling policy in label policy): gira in Office con licenza appropriata, agisce mentre l’utente scrive, può raccomandare la label (l’utente accetta) o applicarla automaticamente. Condizioni basate su sensitive info type, trainable classifier o keyword.
- Service-side (auto-labeling policy): gira lato servizio su SharePoint Online, OneDrive ed Exchange Online, anche su file già esistenti (at-rest), senza che l’utente apra nulla. Non richiede il client Office, si esegue prima in simulation mode e non può applicare label con encryption user-defined permissions.
Trappole tipiche d’esame
- Scenario: “Ho creato una label ma gli utenti non la vedono in Word” → Risposta: la label esiste ma non è stata pubblicata in una label policy che includa quegli utenti (o non sono passate fino a 24 ore).
- Scenario: “Serve etichettare automaticamente milioni di file già presenti in SharePoint Online, senza toccare i client” → Risposta: auto-labeling policy service-side, non la simple auto-labeling client-side.
- Scenario: “Un contratto criptato viene inviato a un partner esterno che lo salva sul proprio PC: cosa succede?” → Risposta: la protezione persiste fuori dal tenant; l’accesso dipende dai diritti d’uso concessi nella label, non dalla posizione del file.
- Scenario: “Il co-authoring e AutoSave non funzionano sui documenti etichettati con encryption” → Risposta: abilitare l’impostazione co-authoring per file criptati a livello di tenant (una volta attivata non è reversibile).
- Scenario: “Devo bloccare l’accesso guest e la condivisione esterna su un sito Teams riservato” → Risposta: label con scope Groups & sites, non encryption: la crittografia non si applica al container.
- Scenario: “L’utente ha applicato Confidential ma il file risulta Highly Confidential” → Risposta: conta l’ordine delle label; scendere di livello è un downgrade e richiede giustificazione se la policy lo impone.