Perché la disk encryption è un pilastro dell’endpoint security

Cifrare il disco protegge i dati “at rest”: se un portatile viene rubato, senza la chiave i settori del volume restano illeggibili. Su Windows lo strumento nativo è BitLocker, su macOS è FileVault. In MD-102 il tema non è “come si accende BitLocker manualmente”, ma come si progetta e distribuisce una policy centralizzata da Microsoft Intune, garantendo che la recovery key sia sempre recuperabile dall’amministratore.

La disk encryption policy per BitLocker in Intune

La configurazione si trova in Endpoint security → Disk encryption (profilo dedicato) oppure dentro un Settings catalog / Endpoint protection configuration profile. Le scelte architetturali chiave che l’esame verifica sono:

  • Enable full disk encryption / silent enablement: la policy avvia la cifratura senza prompt all’utente. Perché funzioni in modalità “silent” servono un TPM attivo e il dispositivo deve essere Microsoft Entra joined (o Entra hybrid joined), così Intome può fare escrow automatico della chiave.
  • Encryption method (algoritmo e forza): tipicamente XTS-AES 128 o XTS-AES 256 per i dischi di sistema e dati fissi; per i dispositivi rimovibili si usa AES-CBC per compatibilità con macchine più vecchie. Su volumi già cifrati un cambio di algoritmo non è retroattivo: serve decifrare e ricifrare.
  • Encryption type: used space only (rapido, ideale su dischi nuovi/appena provisionati) vs full disk (cifra anche lo spazio libero, più sicuro su dischi già usati).
  • OS drive settings: scelta dell’unlock (TPM, TPM+PIN, TPM+startup key). Il TPM da solo dà sblocco trasparente; il PIN aggiunge un fattore ma rompe la silent enablement senza interazione.

Escrow della recovery key in Entra ID

La parte cruciale: la policy deve impostare “Store recovery information in Microsoft Entra ID before enabling BitLocker” (e opzionalmente bloccare la cifratura finché il backup non è riuscito). Così la recovery key da 48 cifre viene salvata sull’oggetto dispositivo in Microsoft Entra ID. Senza questo escrow, la chiave esiste solo sull’endpoint e, in caso di lockout, è irrecuperabile.

Recupero delle chiavi

Quando BitLocker entra in recovery mode (dopo cambi hardware, aggiornamenti firmware/UEFI, disabilitazione del TPM o modifiche al boot), l’utente vede una schermata che chiede la recovery key identificata da un Key ID. L’amministratore la recupera da:

  • Microsoft Intome admin center → Devices → dispositivo → Recovery keys, oppure
  • Entra admin center → Devices → BitLocker keys.

L’utente finale può auto-recuperarla dal portale myaccount / Devices se ha i permessi. Regola d’oro: si recupera solo ciò che è stato messo in escrow prima dell’evento — non esiste recupero retroattivo di una chiave mai salvata.

Prerequisiti hardware e integrazione con la compliance

  • TPM 2.0 (raccomandato), UEFI/Secure Boot e edizioni Windows Pro/Enterprise/Education.
  • Su hardware senza TPM la silent enablement fallisce: serve una startup key o un PIN, quindi interazione utente.
  • La cifratura si può rendere requisito di compliance: in una compliance policy si imposta “Require BitLocker” (e Secure Boot). Un dispositivo non cifrato risulta non-compliant; con Conditional Access questo può bloccare l’accesso alle risorse finché la cifratura non è attiva. Reporting dedicato in Endpoint security → Disk encryption → monitoraggio.

L’equivalente su macOS: FileVault

Per i Mac gestiti Intune offre una policy FileVault analoga:

  • Abilita la cifratura full-disk XTS-AES 128.
  • Gestisce l’escrow della personal recovery key in Intune (recuperabile dall’admin center), con opzione di rotazione periodica della chiave.
  • Può forzare l’attivazione al login e rendere FileVault un requisito di compliance come BitLocker.

Trappole tipiche d’esame

  • Scenario: vuoi cifrare i portatili senza alcun prompt all’utente. → Risposta: silent enablement funziona solo con TPM presente e dispositivo Entra joined; senza questi requisiti la cifratura richiede interazione (PIN/startup key).
  • Scenario: un utente è in BitLocker recovery ma non trovi la chiave nel portale. → Risposta: la chiave era recuperabile solo se la policy imponeva l’escrow in Entra prima di abilitare BitLocker; una chiave mai salvata non si recupera retroattivamente.
  • Scenario: devi passare da XTS-AES 128 a 256 su macchine già cifrate. → Risposta: il cambio non è retroattivo; l’algoritmo si applica alle nuove cifrature, i volumi esistenti vanno decifrati e ricifrati.
  • Scenario: vuoi impedire l’accesso alle app aziendali dai device non cifrati. → Risposta: usa una compliance policy “Require BitLocker” combinata con Conditional Access, non solo il configuration profile.
  • Scenario: devi cifrare dei Mac gestiti e conservarne la chiave. → Risposta: usa una policy FileVault in Intune con escrow della personal recovery key, non BitLocker.