Comment empêcher Windows Update de suspendre le chiffrement BitLocker?
J'ai été assez choqué aujourd'hui de voir qu'une machine Windows 10 Pro que j'ai récemment installée avec BitLocker (démarrage PIN + TPM avec cryptage complet du disque)) n'a soudainement plus activé BitLocker:
Et apparemment, Windows a foiré mes paramètres Bitlocker:
Voici une capture d'écran que j'ai prise de mes paramètres il y a une semaine (que je n'ai pas modifié manuellement depuis): 
Windows a donc dû les changer de façon.
Je n'ai pas gâché le registre ou installé les outils qui le feraient. Je n'ai même pas installé de logiciel AV tiers, car je ne visite que des sites Web que vous considérez fiables (comme google.com, youtube.com, Amazon.com, etc.) et n'installe que des logiciels que vous considérez fiables (comme Firefox, Skype, etc.) ... Je soupçonne que Windows Update est à l'origine du problème. Et comme il s'avère d'autres personnes ont signalé des problèmes similaires avec Windows Update suspendant leur BitLocker .
C'est absolument inacceptable à mon avis! Comme j'utilise un démarrage PIN + TPM, il ne semble pas y avoir de moyen évident d'empêcher que cela ne se reproduise.
Existe-t-il un moyen d'empêcher cela? Je ne veux vraiment pas désactiver Windows Update car je ne recevrai plus de mises à jour de sécurité. Et je n'aime pas non plus l'idée d'installer manuellement les mises à jour une fois par semaine, puis de vérifier ensuite si BitLocker est à nouveau activé.
MISE À JOUR: selon les commentaires, cette réponse n'explique pas complètement le comportement.
Je ne suis pas un expert, mais j'ai récemment rencontré quelque chose de similaire.
Tout d'abord, notez qu'il y a une différence entre "suspendre" BitLocker et "désactiver" BitLocker:
À partir de vos captures d'écran, votre BitLocker est suspendu, pas éteint.
Selon Microsoft :
L'applet de commande Suspend-BitLocker suspend le chiffrement Bitlocker, permettant aux utilisateurs d'accéder aux données chiffrées sur un volume qui utilise le chiffrement de lecteur BitLocker. Cette applet de commande rend la clé de chiffrement disponible en clair.
...
En cas de suspension, BitLocker ne valide pas l'intégrité du système au démarrage. Vous pouvez suspendre la protection BitLocker pour les mises à niveau du micrologiciel ou les mises à jour du système.
Windows Update dispose d'un mécanisme dans lequel il installe certaines des mises à jour maintenant et le reste au prochain redémarrage. Je suppose que cela est accompli en démarrant dans un système d'exploitation léger qui n'existe que pour installer les nouveaux fichiers, puis appelle le chargeur de démarrage Windows une fois terminé. Il semble que Microsoft ait décidé de ne pas regrouper tous les pilotes TPM dans ce programme d'installation léger, ils désactivent donc BitLocker temporairement.
Un BitLocker suspendu devrait revenir à une protection complète au prochain redémarrage, donc la réponse semble être lorsque les mises à jour Windows vous demandent de redémarrer, vous devez le faire rapidement . Je sais que c'est ennuyeux, mais malheureusement, c'est ainsi que Windows fonctionne.
Pour ce que cela vaut, la façon "standard" d'empêcher l'écrasement des règles de stratégie de groupe dans Windows consiste à accéder à la clé de registre associée, à modifier ses autorisations et à supprimer/refuser l'accès en écriture pour l'utilisateur SYSTEM (ou tous les utilisateurs). Cela est efficace contre le moteur de stratégie de groupe utilisé pour transmettre les modifications de configuration aux machines jointes au domaine. Je n'ai jamais entendu parler de la mise à jour de Windows mettant à jour une règle de stratégie de groupe, donc je ne sais pas si cela fonctionnera là-bas, mais le blocage des écritures par SYSTEM (ou par tous les utilisateurs) le ferait probablement si quelque chose le ferait (d'autre part part, il n'y a aucune garantie que le moteur Windows Update respectera les ACL; les processus au niveau administrateur sont libres de les ignorer s'ils le souhaitent).
Les clés de registre pertinentes apparaissent à être
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE (and subkeys)
et peut-être aussi
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Bitlocker (subkeys specifically)
Les valeurs du deuxième emplacement font référence au premier, donc le premier peut être l'emplacement faisant autorité, mais pour autant que je sache, ce n'est pas vraiment documenté. Quoi qu'il en soit, refuser l'accès en écriture pour SYSTEM sur les deux clés et leurs sous-clés est la meilleure solution à laquelle je peux penser pour empêcher que cela ne se reproduise (mais pas de garantie). Vous pouvez essayer de refuser l'écriture pour tous les utilisateurs, si vous voulez être très sûr (certains éléments de mise à jour s'exécutent en tant que compte TrustedInstaller spécial, par exemple).