Administrer BitLocker avec Sophos Central
Sophos Central Device Encryption active et administre Microsoft BitLocker. Le chiffrement technique et l’authentification Pre-Boot restent assurés par Windows. Les exigences Microsoft relatives au matériel et aux Group Policies s’appliquent donc au même titre que la Sophos Policy.
Préparer le système
Avant l’activation, les points suivants sont vérifiés :
- édition Windows prise en charge et niveau de correctifs actuel,
- TPM présent, activé et opérationnel,
- UEFI ou BIOS et Secure Boot dans l’état planifié,
- partitions système et Recovery suffisamment dimensionnées,
- absence de gestion concurrente du chiffrement,
- possibilité d’enregistrer le Recovery Key en sécurité dans Central.
Une erreur TPM ne se corrige pas en réactivant plusieurs fois la Sophos Policy. Les Windows Events, TPM Management et le BitLocker Status indiquent la cause.
Choisir le mode d’authentification
Selon la Policy et la plateforme, TPM only, TPM plus PIN, Passphrase ou USB Key peuvent être utilisés. Tous les modes ne conviennent pas de la même manière à chaque combinaison de Windows et de matériel.
TPM only est convivial, mais protège moins contre un attaquant qui dispose de l’appareil et d’un environnement connecté ou déverrouillable qu’un PIN supplémentaire. TPM + PIN renforce la protection Pre-Boot, mais augmente la charge de Support et de récupération.
Le choix repose sur le modèle de risque, les capacités du matériel et le processus utilisateur, pas sur un durcissement maximal généralisé.
Pour un PIN ou une Passphrase, il faut tenir compte du clavier Pre-Boot : Sophos ne documente que la disposition US English. Les caractères spéciaux peuvent donc se trouver sur d’autres touches au prochain démarrage. Si une clé USB est requise, elle doit être formatée en NTFS, FAT ou FAT32. Les deux variantes sont testées sur le matériel réellement utilisé avant le déploiement général de la Policy.
Contrôler les Group Policies
Les Windows GPO peuvent imposer les algorithmes BitLocker, l’authentification, la récupération et les exigences matérielles. Des paramètres contradictoires entre GPO et Central provoquent un chiffrement en attente ou des erreurs.
Sophos ne remplace pas les paramètres existants sous Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives. Les valeurs définies par Sophos ne sont pas nécessairement visibles dans Local Group Policy Editor, mais se trouvent sous HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE.
Avant le Rollout, les Policies locales et Domain sont exportées ou documentées. Les points particulièrement importants sont l’authentification Pre-Boot, la compatibilité TPM, la sauvegarde du Recovery Key et la méthode de chiffrement.
Central Device Encryption chiffre toujours les nouveaux volumes par logiciel et utilise AES-256 par défaut ; une Group Policy peut sélectionner AES-128. Un chiffrement BitLocker matériel existant n’est pas converti automatiquement et une GPO existante qui exige un chiffrement matériel n’est pas remplacée. Une obligation de Smart Card pour BitLocker n’est pas prise en charge par Central Device Encryption et génère un événement d’erreur.
Connaître les limites
Les Dynamic Disks ne sont pas pris en charge pour le System Volume ; les Data Volumes sur Dynamic Disks sont ignorés. Les Windows Partitions créées avec Boot Camp sur un Mac ne sont pas prises en charge non plus.
La première mise en application ne s’effectue pas dans une simple session Remote Desktop. Sophos n’y affiche pas les dialogues nécessaires, et l’utilisateur doit pouvoir tester localement l’authentification Pre-Boot.
Network Unlock ne peut pas être configuré depuis Sophos Central. Une infrastructure BitLocker Network Unlock déjà correctement configurée peut toutefois continuer à fonctionner en parallèle.
Valider l’activation
Si la partition système requise par BitLocker manque, Sophos exécute BdeHdCfg.exe, prépare le disque et exige un véritable redémarrage. Le chiffrement ne commence pas tant que l’utilisateur reporte le redémarrage ou le dialogue du mode d’authentification. Après un test matériel et Pre-Boot réussi, le volume système est chiffré en premier, puis les volumes de données fixes sélectionnés. Les journaux de diagnostic CDE.log et CDE_trace.xml se trouvent sous %ProgramData%\Sophos\Sophos Data Protection\Logs.
Après l’attribution de la Policy, l’utilisateur se connecte et suit, le cas échéant, l’invite Sophos. L’administrateur vérifie :
- Le BitLocker Status local avec les Windows Tools.
- Central indique que l’appareil est chiffré.
- Le Recovery Key est présent et récupérable.
- Le redémarrage et l’authentification Pre-Boot prévue fonctionnent.
- Une modification matérielle et une récupération ont été simulées sur un appareil de test.
Récupérer le Recovery Key
Un Recovery Key n’est communiqué qu’après la vérification d’identité définie. L’administrateur ouvre l’appareil ou l’utilisateur concerné et utilise le Recovery Workflow proposé par Central.
Après une récupération, il faut déterminer pourquoi BitLocker Recovery a été déclenché. Une mise à jour BIOS, une modification TPM, un changement de Secure Boot ou un soupçon de manipulation exigent des réactions différentes.
Si l’organisation prend en charge Self Service, le dernier utilisateur Central connecté peut récupérer la clé via Self Service Portal activé. Lors d’une communication par le Helpdesk, l’appareil, l’utilisateur et la Recovery Key ID affichée sont comparés.
Lire un ordinateur défectueux depuis un autre appareil
Si un ordinateur chiffré ne démarre plus à cause d’une panne matérielle, le lecteur BitLocker peut être connecté à un autre système Windows compatible avec BitLocker. Sur le lecteur verrouillé, il faut sélectionner Unlock Drive > More options > Enter recovery key et noter le Key ID affiché.
Dans Central, My Products > Encryption > Computers > Retrieve Recovery Key permet également de trouver la clé correspondante si l’ordinateur d’origine a déjà été supprimé ou si son hostname est inconnu. Il faut saisir le Key ID, sélectionner le volume trouvé et utiliser Show Key uniquement après le contrôle d’identité et d’autorisation prévu. La clé est saisie directement sur le système de récupération et n’est pas conservée durablement dans un ticket.
Renouveler le PIN ou la Passphrase
La Policy peut demander aux utilisateurs de changer le PIN ou le mot de passe à un intervalle défini. Le changement peut également être déclenché immédiatement pour un ordinateur particulier. Après cinq invites fermées, Sophos génère un Alert.
Un changement forcé est d’abord testé dans un groupe Pilot. Le Helpdesk et les utilisateurs doivent savoir que le nouveau secret s’applique dès le prochain Pre-Boot.
Migrer un BitLocker existant
Pour un appareil déjà chiffré, le statut de protection, les Protectors et la sauvegarde du Recovery Key sont vérifiés avant la reprise. Une migration depuis Sophos SafeGuard Enterprise ou une autre gestion suit le processus Sophos actuel.
L’ancienne instance de gestion n’est arrêtée qu’une fois que Central administre le Recovery Key de manière fiable.
Déchiffrement
Un déchiffrement planifié est déclenché par le Workflow pris en charge et surveillé jusqu’à son achèvement. Tous les utilisateurs de l’appareil sont d’abord retirés de la Device Encryption Policy. Un administrateur Windows local peut ensuite utiliser Manage BitLocker > Turn off BitLocker. Tant qu’une Encryption Policy reste active, Sophos Central annule toute tentative manuelle de déchiffrement et le disque demeure chiffré. L’alimentation de l’ordinateur portable, la durée et le risque pour les données sont pris en compte.
La simple suppression de la Central Policy ou de l’Agent ne prouve pas que BitLocker est désactivé ni que le support a été déchiffré.
Les codes d’erreur précis liés au TPM, à WMI, aux Slate GPOs, à un BitLocker suspendu et au CDE Service sont expliqués dans Résoudre systématiquement les erreurs Sophos Device Encryption.