Durcir BitLocker : XTS-AES 256, TPM+PIN, dépôt des clés

BitLocker transforme un appareil perdu ou volé : de fuite de données, il devient simple dépense matérielle. La plupart des organisations l'activent ; bien moins le configurent contre autre chose qu'un vol opportuniste. La différence tient à quatre décisions : la méthode de chiffrement, la façon dont la clé est libérée au démarrage, l'endroit où résident les clés de récupération, et la protection ou non de la chaîne de démarrage qui entoure BitLocker.

Le modèle de menace en un tableau

TPM seul est un choix par défaut raisonnable pour la plupart des portables de bureau. Les dirigeants, administrateurs, voyageurs et appareils contenant des données sensibles justifient TPM+PIN.

Étape 1 : choisir les paramètres de chiffrement

Chemin GPO : Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption.

Les volumes existants conservent leur chiffrement d'origine. Modifier la stratégie n'affecte que les volumes chiffrés ensuite ; pour faire passer un ancien volume AES-128 en XTS-AES 256, il faut le déchiffrer puis le rechiffrer.

Étape 2 : configurer l'authentification au démarrage

Sous Operating System Drives > Require additional authentication at startup :

• Enabled.
• Allow BitLocker without a compatible TPM : décoché.
• Configure TPM startup : Allow TPM.
• Configure TPM startup PIN : Allow startup PIN with TPM (ou Require pour les groupes à risque élevé via une GPO distincte).
• Laissez les options de clé de démarrage sur Do not allow, sauf raison valable d'utiliser des clés USB.

Paramètres associés :

Pour ajouter un PIN à un appareil déjà chiffré :

$pin = Read-Host -AsSecureString "Startup PIN"
Add-BitLockerKeyProtector -MountPoint C: -TpmAndPinProtector -Pin $pin

Étape 3 : déposer les clés de récupération en premier

Un appareil chiffré sans clé de récupération déposée est un futur incident de perte de données. Sous Operating System Drives > Choose how BitLocker-protected operating system drives can be recovered :

• Allow data recovery agent : facultatif.
• Save BitLocker recovery information to AD DS : Enabled, stocker les mots de passe de récupération et les packages de clés.
• Do not enable BitLocker until recovery information is stored to AD DS : Enabled.
• Omit recovery options from the setup wizard : Enabled (les utilisateurs ne peuvent pas choisir d'imprimer la clé ou de l'enregistrer dans un fichier).

Pour les appareils joints à Entra, le profil BitLocker d'Intune fait l'équivalent et stocke les clés dans Entra ID. Pour les appareils existants, sauvegardez explicitement la clé :

$kp = (Get-BitLockerVolume -MountPoint C:).KeyProtector |
      Where-Object KeyProtectorType -eq 'RecoveryPassword'
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId    # AD DS
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId  # Entra ID

Restreignez qui peut lire les clés de récupération. Dans AD, les clés sont stockées dans des objets enfants msFVE-RecoveryInformation de l'ordinateur ; vérifiez quels groupes peuvent les lire, comme pour les mots de passe LAPS. Configurez la rotation des clés après usage (Intune sait faire tourner le mot de passe de récupération lorsqu'il a été montré à un utilisateur).

Étape 4 : protéger la chaîne de démarrage

BitLocker fait confiance au TPM, et le TPM fait confiance à ce qu'il a mesuré au démarrage. Assurez-vous que cette chaîne est intacte :

• UEFI avec Secure Boot sur chaque appareil. Vérifiez avec Confirm-SecureBootUEFI (renvoie True).
• TPM 2.0, micrologiciel à jour (Get-Tpm).
• Liaison au PCR 7 : manage-bde -protectors -get C: affiche le profil de validation PCR ; msinfo32 affiche PCR7 Configuration: Bound sur les appareils modernes. BitLocker s'appuie alors sur l'état de Secure Boot plutôt que sur les empreintes de chaque composant de démarrage, et les mises à jour du micrologiciel provoquent moins de demandes de récupération.
• Kernel DMA Protection (visible dans msinfo32) sur les appareils dotés de Thunderbolt ou USB4. Sur le matériel plus ancien qui en est dépourvu, TPM+PIN ou la désactivation des ports DMA externes dans le micrologiciel compense.
• Mot de passe du micrologiciel défini là où c'est pris en charge, pour que l'ordre de démarrage et Secure Boot ne puissent pas être modifiés à la légère.
• Veille prolongée plutôt que veille pour les appareils à risque élevé : réglez Allow standby states (S1-S3) when sleeping (on battery) et (plugged in) sur Disabled sous System > Power Management > Sleep Settings, pour que les clés ne soient pas en RAM quand l'écran est rabattu.

Étape 5 : vérifier sur tout le parc

Sur un appareil :

Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionMethod,
  EncryptionPercentage, ProtectionStatus, KeyProtector
manage-bde -status C:

Vous attendez ProtectionStatus: On, EncryptionMethod: XtsAes256 et les protecteurs Tpm ou TpmPin plus RecoveryPassword.

ProtectionStatus: Off sur un volume entièrement chiffré signifie que BitLocker est suspendu (par exemple un reliquat d'un script de mise à jour du micrologiciel utilisant Suspend-BitLocker), et que la clé est stockée en clair sur le disque. Reprenez-le avec Resume-BitLocker -MountPoint C: et traquez les scripts qui suspendent sans nombre de redémarrages.

À l'échelle du parc, produisez vos rapports à partir du rapport de chiffrement d'Intune, de la gestion BitLocker de Configuration Manager ou d'un script de conformité collectant les valeurs ci-dessus. Alertez sur les appareils sans clé déposée et sur les volumes restés suspendus.

Journaux utiles : Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management enregistre les modifications de protecteurs, le début et l'arrêt du chiffrement et les sauvegardes de clés.

Chiffrement automatique de l'appareil

Sur du matériel moderne, Windows 11 active automatiquement le chiffrement de l'appareil (device encryption) pendant l'installation lorsque l'utilisateur se connecte avec un compte Microsoft ou professionnel, et les versions récentes l'appliquent à davantage d'appareils. Il utilise XTS-AES 128 et une protection TPM seul, et la clé part vers le compte connecté. Pour les appareils gérés, appliquez votre stratégie BitLocker pendant la préparation afin que la configuration gérée (chiffrement, cible de dépôt, PIN) remplace la configuration automatique ; sinon, vous risquez d'hériter de volumes AES-128 dont les clés se trouvent dans un compte personnel.

Liste de contrôle

• XTS-AES 256 pour les lecteurs du système et les lecteurs fixes ; chiffrement complet pour le matériel réutilisé
• TPM seul pour les appareils standard, TPM+PIN (PIN amélioré) pour les utilisateurs à risque élevé
• Chiffrement bloqué tant que la clé de récupération n'est pas déposée
• Accès aux clés de récupération restreint et audité
• Secure Boot actif, TPM 2.0, liaison au PCR 7, Kernel DMA Protection vérifiés
• Veille désactivée au profit de la veille prolongée pour les portables à risque élevé
• Rapport de parc sur l'état de protection, le chiffrement et le dépôt des clés ; alerte sur les volumes suspendus

La robustesse de BitLocker dépend de la chaîne de démarrage sur laquelle il repose. La même sécurité basée sur la virtualisation qui protège la chaîne de démarrage alimente aussi Credential Guard : les deux relèvent du même projet de mise à niveau matérielle.