Validation BitLocker AD : politiques, volumes et récupération

Qu’est-ce que la validation BitLocker AD pour la récupération ?

La validation BitLocker AD pour la récupération rapproche trois preuves indépendantes : la politique applicable à un ordinateur, la protection réellement présente sur chaque volume et les informations de récupération stockées dans les services de domaine Active Directory (AD DS) pour son protecteur de récupération actuel. Un constat portant sur la politique ouvre cette investigation ; il ne peut pas répondre à ces trois questions.

L’unité de revue utile est un ordinateur identifié et un volume identifié, à une heure consignée. Un paramètre à l’échelle du domaine, un disque chiffré localement et un ancien objet de récupération dans l’annuaire peuvent tous exister alors que le chemin de récupération prévu reste non vérifié. Consignez ces observations séparément avant de décider ce qui doit être corrigé.

Notre article sur l’hygiène des objets ordinateur, notamment BitLocker et le dépôt des informations de récupération situe ce travail dans la revue plus large du cycle de vie des ordinateurs. Ici, la tâche est plus ciblée : établir si l’enregistrement de récupération correspond au protecteur actuellement présent sur le volume. Ne déduisez pas l’état de chiffrement de la présence ou de l’absence d’un objet dans l’annuaire.

Fonctionnement : politique, état des volumes et dépôt des informations de récupération

Établir le mode de gestion et le périmètre des volumes

Consignez les volumes du système d’exploitation, de données fixes et amovibles inclus dans le périmètre, les ordinateurs auxquels ils appartiennent et l’origine de leur configuration : GPO ou CSP. Indiquez explicitement les volumes exclus ; le contrôle du seul lecteur du système d’exploitation ne suffit pas à satisfaire une exigence couvrant les lecteurs de données.

La référence de configuration BitLocker de Microsoft identifie ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption comme une politique CSP et indique Not available pour son équivalent GPO. Cela ne signifie pas que BitLocker ne dispose d’aucun paramètre GPO. Les paramètres de récupération des lecteurs du système d’exploitation et de données fixes proposent une sauvegarde dans AD DS et une option empêchant l’activation tant que cette sauvegarde n’a pas réussi. Windows Server utilise GPO plutôt que CSP pour la configuration BitLocker.

Pour une cible gérée par GPO, recueillez les preuves du jeu de stratégies résultant au niveau ordinateur à l’aide de la syntaxe gpresult documentée par Microsoft :

gpresult /scope computer /z

Examinez les paramètres de récupération pertinents et les stratégies qui prévalent. Pour les clients gérés par CSP, obtenez les affectations correspondantes et les résultats de politique de l’appareil depuis le système de gestion. Un rapport GPO ne démontre pas l’application d’un CSP. Résolvez les désaccords liés à une gestion mixte avant de présenter la politique prévue comme effective. La même distinction entre une valeur collectée et la protection de la cible apparaît dans nos quatre contrôles de sécurité GPO et leur vérification sur la cible.

Prendre en compte l’historique du volume

La FAQ BitLocker de Microsoft explique que les informations de récupération d’un lecteur chiffré avant l’application de la politique de sauvegarde ne sont pas automatiquement envoyées à AD DS lorsque l’ordinateur rejoint le domaine ou reçoit ensuite cette politique. AD DS conserve également les anciennes entrées de mot de passe de récupération. Un événement ancien indiquant une sauvegarde réussie peut subsister au-delà de l’enregistrement d’annuaire ou du protecteur qui le rendait utile.

Demandez quand le chiffrement a commencé, quand l’appartenance au domaine et la politique de récupération ont pris effet, et si les protecteurs ont changé. Ces réponses déterminent où chercher une lacune. Ni un déploiement récent de politique ni l’horodatage le plus récent de l’annuaire ne remplacent le rapprochement avec le protecteur actuel. Lorsque l’historique est indisponible, consignez-le comme inconnu et effectuez les contrôles directs ci-dessous.

Détection : recueillir trois preuves indépendantes

Étape 1 : mesurer le chiffrement et la protection de chaque volume

Exécutez localement la commande manage-bde de consultation de l’état documentée pour le lecteur sélectionné :

manage-bde -status C:

Consignez l’état de conversion, le pourcentage de chiffrement, la méthode de chiffrement, l’état de protection et l’état de verrouillage. La progression du chiffrement et la protection active sont des champs distincts ; un volume chiffré dont la protection est désactivée exige un suivi différent de celui d’un volume entièrement déchiffré. Une commande qui échoue ne fournit aucune de ces observations.

PowerShell propose la cmdlet documentée Get-BitLockerVolume. Cet exemple limite les propriétés affichées avec Select-Object :

Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop |
    Select-Object MountPoint,VolumeType,VolumeStatus,EncryptionPercentage,EncryptionMethod,ProtectionStatus,LockStatus

Répétez l’opération pour chaque volume sélectionné. Enregistrez avec le résultat l’identité de l’ordinateur, le point de montage, l’horodatage et l’issue de la collecte, afin qu’un autre relecteur puisse reproduire le périmètre. Ne transformez pas un poste injoignable en poste non chiffré dans le rapport.

Étape 2 : identifier les protecteurs de récupération actuels sans afficher de secrets

La référence Backup-BitLockerKeyProtector documente le tableau KeyProtector, KeyProtectorId et KeyProtectorType. Utilisez ces propriétés pour identifier les protecteurs de type mot de passe de récupération, sans supposer une position fixe dans le tableau :

(Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop).KeyProtector |
    Select-Object KeyProtectorType,KeyProtectorId

Cette projection affiche les identifiants et les types, pas le mot de passe de récupération. Consignez tous les protecteurs actuels de type mot de passe de récupération du volume sélectionné ; il peut y en avoir plusieurs. Un protecteur TPM n’est pas l’identifiant de mot de passe de récupération à rapprocher d’AD DS. Si le protecteur de type mot de passe de récupération attendu est absent, qualifiez explicitement cette observation au lieu de choisir un autre type de protecteur pour donner l’apparence d’un tableau complet.

Étape 3 : lire les métadonnées de récupération AD DS du bon ordinateur

Microsoft documente la classe msFVE-RecoveryInformation comme des informations de récupération associées à un ordinateur, et msFVE-RecoveryGuid comme le GUID associé à un mot de passe de récupération. Le ObjectGUID de l’objet d’annuaire lui-même est un identifiant différent.

Utilisez le module ActiveDirectory depuis un poste d’administration autorisé. La requête ciblée suivante utilise les paramètres Get-ADObject de Microsoft. Remplacez le DN de l’ordinateur et le DC par les valeurs vérifiées. Elle demande les métadonnées de récupération sans demander msFVE-RecoveryPassword ni toutes les propriétés :

Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'CN=PC01,OU=Workstations,DC=contoso,DC=com' -SearchScope OneLevel -Server 'dc01.contoso.com' -Properties whenCreated,msFVE-RecoveryGuid,msFVE-VolumeGuid -ErrorAction Stop |
    Select-Object DistinguishedName,whenCreated,'msFVE-RecoveryGuid','msFVE-VolumeGuid'

Les attributs GUID renvoyés peuvent être des tableaux d’octets. Pour un objet de récupération renvoyé, le constructeur .NET Guid à partir d’un tableau d’octets documenté fournit une valeur lisible pour la comparaison. Affectez un objet renvoyé à $recoveryObject avant d’évaluer cette expression :

[guid]::new([byte[]]$recoveryObject.'msFVE-RecoveryGuid')

Comparez ce GUID complet à l’identifiant du protecteur actuel de type mot de passe de récupération, en ignorant les accolades de présentation et la casse. Utilisez l’association à l’ordinateur et au volume comme contexte supplémentaire ; ne faites pas le rapprochement sur la seule date de création. Traitez les attributs manquants ou mal formés comme des preuves incomplètes. Le schéma rend msFVE-VolumeGuid facultatif ; l’absence de cet attribut à elle seule ne démontre donc pas l’échec de la sauvegarde du mot de passe de récupération.

L’accès à l’annuaire fait partie de la mesure. Une requête réussie mais vide, exécutée avec un compte qui ne peut pas voir les objets pertinents, ne constitue pas un résultat d’absence fiable. Vérifiez le DN, les permissions et le DC choisi, et examinez les incertitudes de réplication ou de visibilité avant de conclure qu’aucune entrée correspondante n’existe. La correspondance des métadonnées ne démontre toujours pas que l’opérateur de récupération autorisé peut obtenir et utiliser le secret.

Étape 4 : préserver les inconnues dans la matrice de preuves

Utilisez ce qui suit comme modèle de rapport, pas comme des résultats mesurés :

Distinguez la non-observation, l’échec de collecte et un test non réalisé. Une ligne peut être observée tandis qu’une autre reste non résolue. Rapportez chaque écart avec les preuves nécessaires à sa clôture, au lieu de fusionner les lignes dans un indicateur unique de conformité.

Remédiation : aligner politique, protecteurs actuels et récupération (Remediation)

Étape 1 : corriger la politique prévue pour les nouvelles activations

Confirmez d’abord le mode de gestion et chaque classe de lecteur. Pour les politiques de récupération AD DS applicables, sélectionnez la sauvegarde des informations de récupération requises et l’option bloquant l’activation tant que le stockage dans AD DS n’a pas réussi. Examinez séparément les paramètres du système d’exploitation et des données fixes. Ces options sont documentées dans la référence de configuration ci-dessus ; elles ne constituent pas une version GPO de remplacement de RequireDeviceEncryption.

Testez la configuration sur un périmètre pilote, contrôlez les résultats de politique sur la cible et conservez les traces de tout échec de déploiement. Microsoft précise que de nombreuses politiques BitLocker sont appliquées lors de l’activation initiale et que les changements de politique ne redémarrent pas le chiffrement. Les volumes déjà chiffrés nécessitent donc le rapprochement direct ci-dessous.

Étape 2 : sauvegarder un protecteur de récupération actuel existant

Sur un volume déjà chiffré, identifiez d’abord le protecteur de type mot de passe de récupération par son type et son identifiant. Résolvez les problèmes de connectivité au domaine et de permissions de sauvegarde, puis utilisez l’opération manage-bde de sauvegarde des protecteurs dans AD DS documentée :

manage-bde -protectors -adbackup C: -id "{CURRENT-RECOVERY-PROTECTOR-GUID}"

Les accolades contiennent une valeur à remplacer par le GUID complet réel du protecteur, pas un mot de passe. Le paramètre -id est obligatoire. Cette opération sauvegarde les informations de récupération sélectionnées ; elle ne chiffre pas un lecteur non chiffré et ne crée pas un protecteur manquant. Si aucun protecteur adapté n’existe, utilisez la procédure de provisionnement approuvée par l’organisation avant de tenter la sauvegarde.

Après la sauvegarde, répétez la requête AD DS ciblée et rapprochez à nouveau l’identifiant. Conservez les anciennes entrées conformément à la politique de l’organisation sur les données de récupération ; ne les supprimez pas simplement parce qu’elles sont plus anciennes. Une réponse de commande réussie doit être suivie d’une correspondance observée indépendamment dans l’annuaire. Si elle reste absente, laissez le point relatif au dépôt des informations de récupération non résolu et recherchez la défaillance précise.

Étape 3 : exercer la récupération dans des conditions contrôlées

Utilisez le processus de récupération BitLocker de Microsoft pour définir l’accès de l’opérateur et l’obtention des informations. Sa procédure AD DS utilise RSAT BitLocker Recovery Password Viewer dans Active Directory Users and Computers ; l’accès à la récupération revient par défaut aux Domain Administrators et peut être délégué. Le visualiseur peut effectuer une recherche à partir de l’identifiant de mot de passe affiché.

Prévoyez un appareil de test représentatif ou une fenêtre de maintenance approuvée, un opérateur responsable, une voie de récupération et un plan de retour arrière. Confirmez l’ordinateur, le volume et l’identifiant de récupération affiché avant d’obtenir le secret correspondant. Transmettez-le uniquement par le canal de récupération approuvé. Ne provoquez pas la récupération sur les systèmes de production simplement pour remplir un champ d’audit.

Consignez si l’opérateur prévu a obtenu les informations correspondantes et si elles ont déverrouillé le volume prévu. Ne consignez pas le mot de passe dans les preuves. Après utilisation, suivez la procédure de rotation du mot de passe de récupération de l’organisation, vérifiez tout protecteur de remplacement et sa nouvelle correspondance dans le dépôt, puis contrôlez à nouveau l’état de protection. Un exercice limité à l’obtention des informations doit être qualifié d’obtention vérifiée ; ce n’est pas un test de déverrouillage.

Comment EtcSec détecte cette situation

L’implémentation d’etc-collector examinée expose BITLOCKER_NOT_REQUIRED comme un constat de sévérité Low. Son Detect() lit BitLockerRequired via FindRegistrySettingInt : une valeur absente ou toute valeur différente de 1 donne Count 1 ; une valeur de 1 donne Count 0. Ce décompte est le résultat d’un contrôle, pas le nombre d’ordinateurs non chiffrés.

La fonction auxiliaire renvoie la première valeur disponible dans la Default Domain Controllers Policy, puis dans la Default Domain Policy, puis dans une autre politique collectée. Elle ne calcule pas la politique effective par ordinateur, notamment la précédence des liens, le filtrage et l’héritage. Une valeur acceptée depuis une politique ne permet pas d’établir la couverture du parc.

Le fournisseur SMB lit GptTmpl.inf et Machine/Registry.pol. L’analyseur Registry.pol associe BitLockerRequired uniquement lorsque la clé contient fve et que la valeur est un DWORD nommé requiredeviceencryption. La distinction CSP/GPO de Microsoft ci-dessus signifie que cette association ne permet pas d’établir une exigence générale de chiffrement par GPO. Des fichiers manquants ou non lus ne prouvent pas non plus l’absence d’une politique appliquée.

Ce Detect() ne collecte aucun état de chiffrement de volume, protecteur de récupération actuel, enregistrement de récupération AD DS correspondant ni résultat de test de récupération. Qualifiez les résultats positifs comme ceux dont le décompte est nul à l’aide de la matrice de preuves distincte. Ne clôturez la tâche de vérification que lorsque les volumes identifiés, les protecteurs actuels et la voie de récupération prévue sont pris en compte, avec un responsable explicitement désigné pour les inconnues restantes.