Questo è ciò che Microsoft ha da dire al riguardo:

Disable sleep

BitLocker unlock methods for operating system drives—such as TPM integrity checks or requests for a PIN or startup key before allowing access to the drive—are only used when a computer is turned on, is restarted, or comes out of hibernation. If a computer enters sleep mode after a period of inactivity instead of entering hibernation, the drive stays unlocked. Therefore, for added security, it is recommended that sleep mode be disabled by using Group Policy.

Bolds mine. È implicito il fatto che riprendere dal letargo sia sicuro quanto l'avvio a freddo.

Probabilmente hai a che fare con un reparto IT troppo zelante, hanno frainteso il problema o hanno altri motivi non correlati alla crittografia del disco per la modifica.

Per quanto riguarda la spiegazione generale del motivo per cui l'ibernazione potrebbe essere disabilitata, dovresti chiedere al tuo reparto IT. A questo punto non è nemmeno chiaro se sia stato fatto per ragioni legate alla sicurezza. Forse hanno riscontrato problemi con questo hardware e l'hanno disabilitato per tutta l'azienda.

Un altro motivo potrebbe essere che mirano a disabilitare avvio rapido per motivi.

Le workstation di sicurezza, forse non tutte, usano FDE o avvio sicuro, e in tal caso la sospensione potrebbe essere un problema.

Potremmo speculare per l'eternità, ma a meno che il tuo reparto IT non vada in giro per SecSE, non otterrai una risposta effettiva.

Da un punto di vista agnostico del software, FDE (full disk encryption) è generalmente implementato come controllo per contrastare il rischio di recupero dei dati da dispositivi smarriti o rubati. Se è per altri motivi, potrebbe non essere applicabile ...

Da un punto di vista della gestione dei rischi aziendali, la decisione di autorizzare gli stati di sospensione o ibernazione dovrebbe basarsi su una valutazione tecnica di come il software FDE funziona in tali stati e se sarà ancora efficace contro gli scenari di minaccia che sono applicabile.

Per le soluzioni di autenticazione pre-boot ci si basava sul fatto che un dispositivo da arrestare per FDE fosse efficace, questo era a causa del potenziale per un utente malintenzionato di accedere alla memoria (e quindi in teoria dei tasti crittografici) usando DMA attacchi basati.

Un paio di altri fattori che sono rilevanti per la decisione nei dispositivi attuali (quando si considerano gli attacchi pratici):

• Se il dispositivo ha interfacce compatibili con DMA esterne
• Modalità di implementazione dello spazio di archiviazione (unità rimovibile e memoria cablata)

Ci saranno anche altre cose da considerare, ad esempio se una password di pre-boot separata e una password di accesso sono implementate con requisiti di complessità differenti, c'è la possibilità di un attacco più facile per indovinare la password se lo stato del dispositivo non richiede il pre -boot password.

Quando si mette il sistema in ibernazione, l'intera memoria viene archiviata su disco (hiberfil.sys). Ciò rappresenta sempre una minaccia alla sicurezza perché la memoria può contenere dati privati, password, chiavi e così via. Avvicinandoti allo storage con un altro sistema ottieni l'accesso all'intero dump della memoria. La crittografia del disco aiuta ma non tutta la memoria può essere crittografata su disco, ad esempio alcuni segmenti di memoria devono essere disponibili per poter eseguire il kernel.

D'altro canto, la modalità sleep continua a mantenere il potere fluttuante attraverso la memoria, e quindi richiede una memoria persistente (ignora il caching per il momento). Il disco rigido è sempre crittografato quando BitLocker è configurato, anche quando Windows è attivo e in esecuzione.

Dal punto di vista degli attaccanti, non penso che la sospensione e BitLocker creino un ambiente non sicuro. Direi anche che la modalità di sospensione è più vulnerabile poiché lascia una grande finestra di opportunità per un utente malintenzionato di tentare di accedere a contenuti di memoria semplici.