Clés de récupération BitLocker : dépôt, rotation, audit

BitLocker ne protège les données que tant que la clé de récupération est à la fois disponible pour les bonnes personnes et indisponible pour tous les autres. Les organisations réussissent souvent une moitié seulement : des clés déposées mais lisibles par des centaines d'administrateurs, ou un accès bien verrouillé mais un quart du parc sans aucune clé déposée, si bien que la première mise à jour de micrologiciel ratée tourne à la perte de données.

Le guide pilier sur le durcissement de BitLocker couvre la stratégie de chiffrement elle-même, y compris le paramètre GPO qui bloque le chiffrement tant que la clé n'est pas sauvegardée. Ce guide couvre la vie de la clé après cela : où elle réside, comment prouver que chaque appareil en a une, qui peut la lire, comment les lectures sont auditées et comment les clés sont renouvelées. La thématique BitLocker & sécurité du démarrage liste le reste de la série.

Où résident les clés

Microsoft BitLocker Administration and Monitoring (MBAM), composant de MDOP, a atteint la fin du support étendu ; si vous l'exploitez encore, migrez vers la gestion BitLocker de Configuration Manager ou vers Intune plutôt que de le prolonger.

Chaque volume peut accumuler plusieurs protecteurs de mot de passe de récupération au fil du temps. L'ID du protecteur de clé affiché sur l'écran de récupération (« Recovery key ID » ; les 8 premiers caractères suffisent pour la recherche) identifie celui dont l'utilisateur a besoin.

Étape 1 : prouver que chaque appareil a une clé déposée

Le paramètre du guide pilier « Do not enable BitLocker until recovery information is stored » protège les nouveaux chiffrements. Il ne couvre ni les appareils chiffrés auparavant, ni ceux qui se sont chiffrés automatiquement avant l'application de la stratégie, ni les clés perdues lors de la recréation d'un objet ordinateur. Mesurez la couverture.

Sur l'appareil, comparez les protecteurs locaux avec ce que contient l'annuaire :

(Get-BitLockerVolume -MountPoint C:).KeyProtector |
  Where-Object KeyProtectorType -eq 'RecoveryPassword' |
  Select-Object KeyProtectorId

Dans Active Directory, listez les ordinateurs qui possèdent au moins un objet de récupération :

$withKeys = Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  ForEach-Object { ($_.DistinguishedName -split ',',2)[1] } | Sort-Object -Unique
Get-ADComputer -Filter * -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  Where-Object { $_.DistinguishedName -notin $withKeys } |
  Select-Object Name

Exécutez ceci avec un compte capable de lire les objets de récupération, sinon tous les ordinateurs paraissent non protégés. Pour Entra ID, listez les métadonnées des clés (pas les clés elles-mêmes) avec Microsoft Graph PowerShell et comparez les valeurs DeviceId avec votre inventaire d'appareils Intune :

Connect-MgGraph -Scopes 'BitLockerKey.ReadBasic.All'
Get-MgInformationProtectionBitlockerRecoveryKey -All |
  Select-Object Id, DeviceId, CreatedDateTime, VolumeType

Le rapport de chiffrement d'Intune affiche aussi l'état de chiffrement par appareil. Pour combler les manques, sauvegardez le protecteur existant avec Backup-BitLockerKeyProtector (AD) ou BackupToAAD-BitLockerKeyProtector (Entra ID), comme indiqué dans le guide pilier, au moyen d'un script de correction. Le journal d'événements Microsoft > Windows > BitLocker-API > Management de l'appareil enregistre chaque tentative de sauvegarde et son résultat ; alertez sur les échecs de sauvegarde.

Étape 2 : restreindre la lecture des clés dans Active Directory

msFVE-RecoveryPassword est un attribut confidentiel : sa lecture exige le droit Control Access sur l'attribut en plus de l'autorisation de lecture normale. Par défaut, cela désigne les Domain Admins et quiconque dispose du contrôle total sur les objets ordinateurs, ce qui, dans beaucoup de domaines, inclut des comptes de service et des groupes de support sur-délégués.

1. Créez un groupe comme BitLocker-Recovery-Readers pour les personnes qui effectuent réellement les récupérations.
2. Déléguez à ce groupe l'accès en lecture aux objets de récupération dans les UO des postes de travail :

dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:RP;;msFVE-RecoveryInformation"
dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:CA;msFVE-RecoveryPassword;msFVE-RecoveryInformation"

3. Vérifiez qui d'autre détient le contrôle total ou All extended rights sur ces UO et objets ordinateurs, et retirez-le là où ce n'est pas nécessaire. La revue faite pour les lecteurs de mots de passe Windows LAPS s'applique ici, et les deux groupes rassemblent souvent les mêmes personnes.

Testez d'abord la délégation en laboratoire. Installez la fonctionnalité RSAT BitLocker Recovery Password Viewer sur les postes d'administration du support ; elle ajoute un onglet BitLocker Recovery aux objets ordinateurs et une recherche par ID de clé.

Étape 3 : restreindre la lecture des clés dans Entra ID

Dans Entra ID, lire la clé elle-même exige l'autorisation microsoft.directory/bitlockerKeys/key/read. Plusieurs rôles intégrés l'incluent, parmi lesquels Cloud Device Administrator, Helpdesk Administrator, Intune Administrator et Security Administrator ; consultez la référence des rôles à jour avant toute attribution. Recommandations :

• Attribuez l'un de ces rôles, ou un rôle personnalisé ne comportant que l'autorisation de clé BitLocker, à l'équipe de récupération, et rendez-le éligible via Privileged Identity Management plutôt que permanent.
• Limitez l'accès du support avec des unités administratives si vos licences le permettent.
• Tranchez la question du libre-service. Par défaut, le propriétaire enregistré d'un appareil peut voir sa clé de récupération dans son portail de compte. Pour les appareils de l'entreprise, vous pouvez le désactiver dans Entra admin center > Devices > Device settings avec le paramètre qui empêche les utilisateurs non administrateurs de récupérer les clés BitLocker de leurs propres appareils.
• Pour l'automatisation, utilisez BitLockerKey.ReadBasic.All (métadonnées uniquement) partout où c'est possible ; n'accordez BitLockerKey.Read.All qu'à l'outil qui doit réellement lire les clés.

Étape 4 : auditer chaque lecture de clé

Active Directory. Sur les contrôleurs de domaine, activez Audit Directory Service Access (Success) sous Advanced Audit Policy Configuration > Audit Policies > DS Access, puis ajoutez une SACL sur les UO des postes de travail : principal Everyone, succès, Read msFVE-RecoveryPassword, appliquée aux objets msFVE-RecoveryInformation descendants. Chaque lecture produit alors un événement 4662 sur le DC qui l'a servie, avec le compte à l'origine et le GUID de schéma de l'attribut dans le champ Properties. Récupérez le GUID sur lequel filtrer :

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
  -LDAPFilter '(lDAPDisplayName=msFVE-RecoveryPassword)' -Properties schemaIDGUID |
  ForEach-Object { [guid]$_.schemaIDGUID }

Entra ID. Chaque lecture de clé est enregistrée dans le journal d'audit Entra, catégorie KeyManagement, sous Read BitLocker key, avec l'acteur et l'appareil. Diffusez les journaux d'audit vers votre SIEM et alertez sur les lectures hors équipe de récupération, les lectures en masse et les lectures par des applications.

Corrélez les lectures avec les tickets. Une lecture de clé sans ticket de récupération correspondant mérite une question.

Étape 5 : faire tourner les clés après usage

Intune (appareils joints à Entra et hybrides). Dans votre stratégie BitLocker (Endpoint security > Disk encryption, ou le catalogue de paramètres), réglez Configure Recovery Password Rotation pour activer le renouvellement sur les appareils joints à Entra, ou à la fois sur les appareils joints à Entra et hybrides (CSP BitLocker ConfigureRecoveryPasswordRotation, valeurs 1 et 2). Lorsqu'un mot de passe de récupération est utilisé pour déverrouiller le lecteur du système, l'appareil en génère un nouveau et le dépose. Pour une clé divulguée sans avoir été utilisée, par exemple lue au téléphone à la mauvaise personne, lancez l'action d'appareil BitLocker key rotation depuis la page de l'appareil dans Intune.

Active Directory. Il n'existe pas de rotation intégrée pilotée par le client. Exécutez un script (via votre outil de gestion ou une correction planifiée) qui ajoute un nouveau mot de passe de récupération, le dépose et seulement ensuite supprime l'ancien protecteur :

$old = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
$new = Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector -WarningAction SilentlyContinue
$newId = ($new.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $old.KeyProtectorId }).KeyProtectorId
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $newId
foreach ($p in $old) { Remove-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $p.KeyProtectorId }

Vérifiez que la sauvegarde a réussi (la cmdlet lève une exception en cas d'échec) avant de supprimer quoi que ce soit. Les anciens objets de récupération restent dans AD ; c'est sans danger, puisque le protecteur correspondant n'existe plus sur le disque.

Ce qui casse

• Une délégation trop serrée laisse le support incapable de récupérer un appareil à 7 h du matin. Gardez une procédure de secours documentée via les administrateurs Tier 0.
• Les scripts de nettoyage d'appareils qui suppriment les objets ordinateurs ou appareils Entra obsolètes suppriment aussi les clés de disques qui dorment peut-être encore dans un tiroir. Vérifiez d'abord la date de la dernière clé de récupération et l'état de chiffrement, et gardez la corbeille AD activée.
• Les appareils réinstallés réutilisent le nom mais créent de nouvelles clés ; les utilisateurs qui lisent le mauvais ID de clé perdent du temps. Formez le support à toujours faire correspondre l'ID de clé.
• Désactiver le libre-service dans Entra ID augmente les appels au support ; prévoyez les effectifs.

Vérifier

• Rapport de couverture : zéro appareil chiffré sans clé déposée, dans AD comme dans Entra ID.
• dsacls ou la vue Advanced Security des UO des postes de travail ne montre que les groupes prévus avec Control Access sur msFVE-RecoveryPassword.
• Une lecture de test par un compte du support produit un événement 4662 ou une entrée d'audit Entra Read BitLocker key dans le SIEM en quelques minutes.
• Après une récupération de test sur un appareil Intune, l'ID de clé dans Entra ID change et l'ancien mot de passe ne déverrouille plus le disque.

Liste de contrôle

• Chaque appareil chiffré a une clé déposée dans AD DS ou Entra ID ; manques corrigés
• Lecture AD de msFVE-RecoveryPassword déléguée uniquement à un groupe dédié
• Rôles de lecture des clés Entra attribués via PIM ; libre-service tranché sciemment
• Lectures de clés AD auditées avec 4662 ; lectures de clés Entra diffusées depuis le journal d'audit
• Lectures corrélées avec les tickets de récupération
• Rotation des mots de passe de récupération activée dans Intune ; rotation scriptée pour les appareils AD uniquement
• Processus de nettoyage des appareils protégeant les clés déposées

Les clés de récupération sont le plus souvent nécessaires après des modifications de la chaîne de démarrage. Le guide Secure Boot et UEFI explique quelles mises à jour peuvent déclencher une récupération et comment s'y préparer, et l'entrée du glossaire TPM explique pourquoi le TPM ne libère la clé que lorsque les mesures correspondent.