Objectif
Déployer BitLocker sur un parc Windows en garantissant avant chiffrement la sauvegarde centralisée des informations de récupération dans Active Directory ou Microsoft Entra ID, puis valider la récupération sur un groupe pilote.
Prérequis
- Postes Windows pris en charge, état TPM
- Choix du magasin de récupération : AD DS pour les appareils joints au domaine, Microsoft Entra ID pour les appareils Entra selon l’architecture.
- Groupe pilote et politique Intune/GPO de BitLocker préparée.
- Procédure Helpdesk documentée pour retrouver une clé via son Key ID et valider l’identité du demandeur.
Procédure pas à pas
Inventorier TPM et état BitLocker
Avant de pousser une politique, collectez l’état du TPM, le chiffrement actuel et les protecteurs. Repérez les machines déjà chiffrées avec une méthode différente ou un produit tiers.
Get-TpmGet-BitLockerVolumemanage-bde -status C:- Les machines pilotes ont un TPM exploitable ou un scénario de protection explicitement prévu.
Définir la récupération avant le chiffrement
Pour un domaine AD DS, configurez la GPO “Choose how BitLocker-protected operating system drives can be recovered” avec sauvegarde dans AD DS et, si souhaité, “Do not enable BitLocker until recovery information is stored to AD DS”. Dans Intune/Entra, configurez la politique BitLocker afin que les clés soient sauvegardées dans Entra ID.
- Le stockage de récupération est défini et accessible aux seuls rôles Helpdesk autorisés.
Créer une politique pilote
Avec Intune, privilégiez Endpoint security > Disk encryption > BitLocker pour le déploiement. Configurez méthode de chiffrement, TPM et récupération selon votre standard. Pour un déploiement silencieux, évitez les options exigeant une interaction de démarrage incompatible avec ce scénario.
- La politique ne cible qu’un groupe pilote de postes connus.
Vérifier ou sauvegarder une clé existante
Sur une machine déjà chiffrée, identifiez le protecteur RecoveryPassword. Si la politique n’a pas encore sauvegardé la clé, sauvegardez explicitement le protecteur dans le magasin correspondant.
$vol = Get-BitLockerVolume -MountPoint "C:"$recovery = $vol.KeyProtector | Where-Object KeyProtectorType -eq "RecoveryPassword"$recovery | Select-Object KeyProtectorId,KeyProtectorTypeBackup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $recovery[0].KeyProtectorId- La clé de récupération apparaît dans AD DS pour un poste joint au domaine.
Note : Pour Microsoft Entra ID, utilisez la cmdlet/commande de sauvegarde Entra adaptée ou la politique MDM ; manage-bde prend aussi en charge -aadbackup avec l’ID du protecteur.
Déployer le chiffrement sur le pilote
Laissez la politique activer BitLocker selon le scénario prévu, puis surveillez la progression. Évitez les redémarrages/firmware non planifiés pendant la phase initiale.
manage-bde -status C:Get-BitLockerVolume -MountPoint "C:" | Format-List VolumeStatus,ProtectionStatus,EncryptionPercentage,KeyProtector- Le volume atteint FullyEncrypted et ProtectionStatus = On.
Valider la présence de la clé côté annuaire
Depuis l’outil d’administration AD/Entra, recherchez le poste pilote et confirmez qu’au moins un mot de passe de récupération récent correspond au protecteur présent sur la machine. Ne vous contentez pas d’un état “encrypted”.
manage-bde -protectors -get C:- Le Key ID local possède une correspondance dans le stockage central.
Tester le processus de récupération sans perdre les données
Simulez une demande Helpdesk : à partir du Key ID, retrouvez la clé dans AD/Entra et documentez la procédure d’autorisation. Ne forcez pas un vrai recovery boot en production si le test peut être réalisé sur une machine de laboratoire.
- Le Helpdesk peut retrouver la bonne clé à partir du Key ID sans donner accès à toutes les clés du parc.
Étendre et surveiller
Déployez par vagues et surveillez échecs de chiffrement, TPM, sauvegarde de clé et appareils non conformes. Après utilisation d’une clé de récupération, prévoyez sa rotation afin qu’une valeur divulguée ne reste pas valable indéfiniment.
Get-BitLockerVolume- La couverture augmente sans appareil chiffré dépourvu de clé centralisée.
Validation
La procédure est validée lorsque :
- Chaque appareil pilote est chiffré avec ProtectionStatus On.
- Chaque protecteur RecoveryPassword possède une sauvegarde centralisée vérifiée avant généralisation.
- Le Helpdesk retrouve une clé avec le Key ID et les droits de lecture sont limités.
- Aucun produit de chiffrement tiers non traité n’est présent dans le périmètre.
Retour arrière
- Retirer l’assignation de la politique BitLocker pour stopper le déploiement sur de nouveaux appareils.
- Ne lancez pas automatiquement un déchiffrement massif : si un rollback du paramétrage suffit, laissez les volumes déjà chiffrés protégés selon la décision sécurité.
- Si un poste pilote doit être déchiffré, utilisez le mécanisme BitLocker standard après vérification de la clé et sauvegarde des données.
Dépannage / erreurs fréquentes
- Échec de chiffrement silencieux : vérifier TPM, conflit avec chiffrement tiers et paramètres nécessitant interaction utilisateur.
- Poste chiffré mais clé absente de l’annuaire : sauvegarder explicitement le RecoveryPassword puis corriger la politique avant d’étendre.
- Recovery screen après changement BIOS/UEFI : utiliser le Key ID pour retrouver la bonne clé, puis analyser la cause avant de suspendre/réactiver les protecteurs.
- Plusieurs clés visibles : identifier celle correspondant au Key ID affiché ; ne supprimer d’anciens protecteurs qu’après validation du nouveau.