Come impedire a Windows Update di sospendere la crittografia BitLocker?

6

Oggi sono rimasto piuttosto scioccato nel vedere che una macchina Windows 10 Pro che ho recentemente installato con BitLocker (PIN di avvio + TPM con crittografia completa del disco) improvvisamente non ha più abilitato BitLocker:

EaquantopareWindowshaincasinatolemieimpostazionidiBitlocker:

Eccounoscreenshotchehopresodellemieimpostazioniunasettimanafa(chenonhomodificatomanualmentedaallora):

QuindiWindowsdeveaverlimodificatisoemhow.

Nonhoincasinatoilregistrooglistrumentiinstallatichelofarebbero.NonhonemmenoinstallatoalcunsoftwareAVditerzepartipoichévisitosolositiwebcheconsideriaffidabili(comegoogle.com,youtube.com,amazon.com,ecc.)Einstallosolosoftwarecheconsideriaffidabili(comeFirefox,Skypeecc.)...SospettocheWindowsUpdatesialafontedelproblema.Ecomerisulta altre persone hanno segnalato problemi simili con Windows Update sospendendo il loro BitLocker .

Questo è assolutamente inaccettabile secondo me! Poiché utilizzo un PIN di avvio + TPM, non sembra essere un modo ovvio per evitare che ciò accada di nuovo.

C'è un modo per impedirlo? Non voglio davvero disabilitare Windows Update poiché non otterrò più aggiornamenti di sicurezza. Inoltre, non mi piace l'idea di installare manualmente gli aggiornamenti una volta alla settimana e successivamente verificare se BitLocker è stato abilitato di nuovo.

    
posta Forivin 12.12.2018 - 16:01
fonte

2 risposte

2

AGGIORNAMENTO: come da commenti, questa risposta non spiega completamente il comportamento.

Non sono un esperto, ma di recente ho riscontrato qualcosa di simile.

Innanzitutto, nota che c'è una differenza tra "Sospendi" BitLocker e "Disabilita" BitLocker:

BitLocker finestra di dialogo che mostra la differenza tra

Dai tuoi screenshot, il tuo BitLocker è sospeso, non spento.

In base a Microsoft :

The Suspend-BitLocker cmdlet suspends Bitlocker encryption, allowing users to access encrypted data on a volume that uses BitLocker Drive Encryption. This cmdlet makes the encryption key available in the clear.

...

While suspended, BitLocker does not validate system integrity at start up. You might suspend BitLocker protection for firmware upgrades or system updates.

Windows Update ha un meccanismo in cui installa alcuni degli aggiornamenti ora e il resto al prossimo riavvio. Presumo che ciò avvenga avviando in un sistema operativo leggero che esiste solo per installare i nuovi file, quindi chiama il bootloader di Windows una volta terminato. Sembra che Microsoft abbia deciso di non voler raggruppare tutti i driver TPM in questo leggero programma di installazione, quindi disabilitano temporaneamente BitLocker.

Un BitLocker sospeso dovrebbe tornare alla protezione completa al prossimo riavvio, quindi la risposta sembra essere quando Windows Updates ti chiede di riavviare, dovresti farlo subito . So che è fastidioso, ma sfortunatamente è così che funziona Windows.

    
risposta data 12.12.2018 - 16:49
fonte
0

Per quello che vale, il modo "standard" per evitare la sovrascrittura delle regole dei criteri di gruppo in Windows è quello di passare alla chiave di registro associata, modificarne le autorizzazioni e rimuovere / negare l'accesso in scrittura per l'utente SYSTEM (o tutti gli utenti) . Ciò è efficace contro il motore di criteri di gruppo utilizzato per inviare modifiche di configurazione a macchine unite al dominio. Non ho mai sentito parlare di Windows Update modificando una regola dei criteri di gruppo prima, quindi non sono sicuro che funzionerà lì, ma il blocco delle scritture da parte di SYSTEM (o di tutti gli utenti) probabilmente lo farebbe comunque se lo fosse (sull'altro mano, non c'è alcuna garanzia che il motore di Windows Update rispetti gli ACL, i processi a livello di amministrazione sono liberi di ignorarli se lo desiderano).

Le chiavi di registro pertinenti appaiono per essere

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE (and subkeys)

e forse anche

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Bitlocker (subkeys specifically)

I valori nella seconda posizione fanno riferimento al primo, quindi il primo potrebbe essere il luogo autorevole, ma per quanto posso dire non è documentato. In ogni caso, negare l'accesso in scrittura per SYSTEM su entrambe le chiavi e le loro sottochiavi è lo scatto migliore che posso immaginare per evitare che ciò accada di nuovo (ma non ci sono garanzie). Puoi provare a negare la scrittura per tutti gli utenti, se vuoi essere più sicuro (alcuni elementi di aggiornamento vengono eseguiti come l'account TrustedInstaller speciale, ad esempio).

    
risposta data 12.12.2018 - 20:15
fonte

Leggi altre domande sui tag