Sophos Device Encryption : résoudre les erreurs BitLocker et FileVault

Sophos Fusion (anciennement Sophos Central) pilote Device Encryption, mais n’effectue pas lui-même le chiffrement : BitLocker intervient sous Windows et FileVault sous macOS. Une erreur peut donc se situer à quatre niveaux différents : la Policy et l’affectation des utilisateurs, l’agent Sophos et la synchronisation, le système d’exploitation ou la gestion des Recovery Keys.

Parcours rapide et sûr : Consignez l’état Central et le libellé exact de l’alerte, contrôlez en lecture seule l’état local de BitLocker ou FileVault, puis confirmez qu’un parcours de récupération valide existe. Ce n’est qu’ensuite que la branche concernée est traitée. Désactiver et réactiver plusieurs fois la Policy ne constitue pas un diagnostic et peut modifier l’état, la gestion des clés ou une opération de chiffrement ou de déchiffrement en cours.

Transmettre le cas de récupération normal

Ce runbook diagnostique les anomalies mais ne récupère ni ne divulgue de clé de récupération. Une demande de récupération normale est adressée à Sophos Device Encryption : Récupérer en toute sécurité la clé de récupération.

Après la remise autorisée de la clé attribuée de manière unique, le déverrouillage a lieu sur la plateforme respective : sous Windows dans l’article Gérer BitLocker avec Sophos Fusion, sous macOS dans le Flux de gestion FileVault. Les étapes de récupération, de divulgation et de déverrouillage ne sont pas dupliquées ici.

Ne confondez pas statut central et alerte

L’état de chiffrement décrit le dernier état de l’appareil signalé à Central. Un Alert, en revanche, signale un écart spécifique. Un état ancien alors que l’affichage local est à jour indique donc d’abord un problème de communication ou de synchronisation, et non nécessairement un défaut de chiffrement.

Les sept valeurs de statut

Pending ne signifie pas « la Policy est en attente d’application » et Suspended ne signifie pas « le volume est déchiffré ». Le seul état Encrypted ne suffit pas pour valider le déploiement : la clé doit être disponible par le parcours de récupération prévu.

Les trois alertes de chiffrement des appareils

Device is not encrypted signifie qu’un volume n’est pas chiffré même s’il doit l’être conformément à la stratégie. L’utilisateur peut notamment avoir reporté le chiffrement après l’attribution de la Policy. Vérifiez alors le volume concerné, la présence d’une invite utilisateur et la progression locale du chiffrement.

Recovery key is missing signifie que Central ne trouve pas de clé de récupération pour un volume chiffré dans sa base de données. Il s’agit d’un risque de récupération et non d’une preuve d’un lecteur non chiffré. Vérifiez la communication, la dernière synchronisation et l’inventaire des clés de récupération concerné sans consigner la clé dans les notes du dossier.

Device Encryption is suspended signale une protection BitLocker suspendue. Si cela n’a pas été fait intentionnellement, Sophos donne trois raisons typiques :

• La clé de récupération n’a pas encore été enregistrée dans Central. L’endpoint doit disposer d’une connexion Internet fonctionnelle.
• BitLocker pré-provisionné n’est pas encore activé. L’utilisateur doit définir un code PIN, un mot de passe ou une clé USB selon le mode souhaité.
• Les mises à jour Windows sont installées. BitLocker supprimera automatiquement la suspension après le prochain redémarrage.

Ce n’est que lorsque ces trois cas auront été exclus qu’une intervention administrative imprévue ou une erreur Windows plus grave sera recherchée.

Un processus pour chaque modèle d’erreur

1. Geler l’état et sécuriser la récupération

Avant le premier changement, notez :

• nom de l’appareil et ID de l’appareil dans Central ;
• système d’exploitation, build et heure du problème ;
• la politique attribuée et l’utilisateur concerné ;
• statut exact, texte d’alerte, code d’erreur et horodatage ;
• le volume concerné et s’il est actuellement chiffré ou déchiffré ;
• si le responsable de la récupération a confirmé qu’une clé actuelle et appropriée est disponible.

Le journal de travail indique uniquement Clé disponible, Clé absente ou Non déterminé. La clé elle-même et les identifiants de clé complets n’y sont pas consignés.

2. Comparez le statut central et local

La comparaison aboutit à quatre cas distincts :

1. Les deux côtés signalent le même état : Traitez l’anomalie locale.
2. État local correct, Central obsolète : Vérifiez la communication de l’agent, l’horodatage de la Policy et la dernière synchronisation.
3. Central correct, état local contradictoire : vérifiez le volume concerné et l’affichage natif du système d’exploitation ; ne tirez pas de conclusions sur tous les volumes à partir d’un état global.
4. Les deux côtés sont inconnus ou contradictoires : N’effectuez aucune réparation modifiant l’état. Créez un package de diagnostic et transmettez le cas au niveau supérieur.

3. Vérifier l’application de la politique

Un composant installé ne prouve pas qu’une Policy est appliquée. Vérifiez les points suivants :

• la Policy est activée et attribuée à l’utilisateur prévu ou à son groupe ;
• l’utilisateur connecté à l’appareil est affecté au bon appareil dans Central ;
• aucune priorité plus élevée ni défaut global n’explique le paramètre visible ;
• l’heure de la dernière application de la Policy est postérieure à sa dernière modification ;
• aucune stratégie GPO, MDM ou gestion de chiffrement précédente n’impose un état différent.

Corrigez une affectation dans le système qui en est à l’origine. Définir indistinctement les stratégies locales sur Not configured ou activer et désactiver plusieurs fois une Policy dans Central ne fait que masquer le système d’administration dont les paramètres prévalent réellement.

Windows : BitLocker ne démarre pas ou reste en attente

Vérifiez d’abord localement et en lecture seule

Dans une invite de commande administrative, Windows affiche l’état de tous les volumes BitLocker :

manage-bde -status

Pour chaque volume, relevez Conversion Status, Percentage Encrypted, Protection Status, Lock Status et les Key Protectors existants. Le résultat peut être expurgé avant transmission au support ; supprimez les mots de passe de récupération et tout autre secret.

Le protocole Sophos le plus important se trouve ici :

C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log

Examinez également la période pertinente dans l’Observateur d’événements Windows, l’état du TPM et les stratégies de groupe BitLocker réellement appliquées. Ce n’est pas le nombre d’avertissements, mais la première erreur reproductible après l’application de la Policy ou le redémarrage qui mène à l’étape suivante.

L’utilisateur ne voit pas de boîte de dialogue d’activation

Si la boîte de dialogue attendue est manquante, le type de session, l’utilisateur connecté, le texte exact du journal, l’heure et les redémarrages en attente sont uniquement documentés. Ni une cause de session spécifique ni un défaut de service ne sont dérivés d’une seule entrée de journal. Un changement de type de session ou un redémarrage n’a lieu que conformément aux instructions Sophos en vigueur applicables à la version installée ; puis manage-bde -status, le nouvel horodatage CDE.log et Central sont à nouveau comparés.

La politique et le GPO se contredisent

Les zones de conflit typiques comprennent l’authentification au démarrage, les protecteurs autorisés, les exigences TPM et FIPS, la méthode de chiffrement et la sauvegarde de la clé de récupération. Documentez les GPO appliquées et comparez-les à la Policy centrale. Corrigez ensuite le système de gestion responsable ; ne contournez pas le modèle de sécurité par une solution locale improvisée pendant le diagnostic.

La configuration normale, la sélection du protecteur et le paramétrage des GPO sont expliqués dans Gérer BitLocker avec Sophos Fusion.

BitLocker est Suspended

Suspended ne signifie pas que le volume est déchiffré, mais que la protection est suspendue sur au moins un volume. Vérifiez d’abord si une mise à jour Windows ou du micrologiciel est en cours, si des redémarrages sont en attente, si BitLocker est pré-provisionné et si la clé de récupération est enregistrée dans Central.

• Si un processus de mise à jour documenté n’est pas encore terminé, achevez la séquence de redémarrage prévue, puis effectuez une nouvelle vérification.
• Si un administrateur a sciemment suspendu BitLocker, la personne responsable du changement décide de la reprise ou de la réactivation de la protection BitLocker.
• En l’absence d’explication, la suspension est considérée comme un écart de sécurité. Ne forcez pas la reprise sans discernement ; consignez plutôt l’heure, l’événement et l’état du protecteur en vue de l’escalade.

Erreur d’activation avec le contexte TPM, firmware ou DMA

En cas d’erreur d’activation liée au matériel, le code d’erreur exact, l’état actuel du TPM/UEFI, le mode d’authentification prévu et les versions du micrologiciel et du pilote sont documentés. Une cause ou une réparation ne sera pas déterminée sans instructions spécifiques au modèle actuel, à la version Windows et à Sophos. Les signatures plus anciennes ne sont donc classées que dans la section historique contrôlée par le support.

Lorsqu’il signale un périphérique compatible DMA non protégé, le fabricant de l’appareil doit confirmer si le bus et le périphérique sont internes et sécurisés. Une entrée de registre sous AllowedBuses, des modifications apportées aux ACL ou une publication générale de bus inconnus ne constituent pas une réparation générale. Le comportement diffère également entre les versions de Windows. Sans instruction OEM ou Sophos actuelle, spécifique au modèle et à la version, n’intervenez pas dans le Registre.

macOS : FileVault attend l’utilisateur ou la clé de récupération

Limiter l’autorisation des utilisateurs

FileVault nécessite un utilisateur autorisé localement. Sur un Mac à puce Apple, cela comprend le statut Volume Owner ; le statut Secure Token approprié est également nécessaire à l’administration. Sont donc vérifiés :

• L’utilisateur actuellement connecté localement est-il couvert par la politique de chiffrement de l’appareil ?
• Cet utilisateur peut-il réellement déverrouiller FileVault au démarrage ?
• L’utilisateur attendu est-il visible dans l’application Sophos Device Encryption ?
• Des jetons sécurisés ou une autorisation du propriétaire du volume sont-ils disponibles ?
• Une boîte de dialogue Sophos attend-elle le mot de passe de connexion macOS ou Encrypt, Create key ou Proceed ?

Ne créez pas de nouveau compte local ou mobile par précaution et ne modifiez pas les autorisations de l’utilisateur tant que la condition manquante n’est pas clairement établie. La procédure prise en charge pour autoriser des utilisateurs supplémentaires est décrite dans Gérer FileVault avec Sophos Fusion.

FileVault est actif, mais Central n’a pas de clé

« FileVault actif » et « Clé de récupération gérée dans Central » sont deux déclarations différentes. Pour chaque volume requis par la politique, l’état du chiffrement local, l’indication de récupération dans l’application Sophos Device Encryption et le dernier horodatage central sont comparés.

Les commandes Sophos documentées ci-dessous sont en lecture seule :

/usr/local/bin/seadmin status
/usr/local/bin/seadmin --device-encryption

status permet de comparer la dernière synchronisation. --device-encryption affiche la Policy ainsi que l’état de chiffrement et de récupération des volumes internes. Un volume chiffré dont la clé n’est pas confirmée dans Central ne peut pas être considéré comme correctement déployé.

Si Sophos affiche une clé de récupération personnelle après un échec de dépôt, le responsable FileVault doit assurer sa conservation provisoire sécurisée. Ne copiez pas la clé dans le package de diagnostic. L’article FileVault lié décrit la gestion prise en charge de cette clé unique et sa confirmation ultérieure dans Fusion ; ce runbook ne remplace pas le processus de récupération.

Le chiffrement ou le déchiffrement s’arrête

Une valeur de pourcentage inchangée n’est pas encore une raison pour redémarrer la gestion du chiffrement. Tout d’abord, les éléments suivants sont comparés sur une période de temps suffisamment longue :

• la progression locale du volume concerné ;
• alimentation, espace de stockage disponible et redémarrage en attente ;
• l’horodatage de la dernière politique et de l’agent ;
• les événements du système d’exploitation survenus au même moment ;
• la présence d’un autre système de gestion du chiffrement ;
• état cible attendu : chiffrer, adopter ou déchiffrer.

Avec un déchiffrement planifié, la personne responsable du changement confirme l’état cible, la responsabilité de la clé de récupération et la procédure propre à la plateforme. Pour Windows, suivez l’article BitLocker ; pour macOS, suivez l’article FileVault. En cas de déchiffrement inattendu, ne tentez pas de l’annuler par des modifications précipitées de la Policy ; examinez l’appareil, les modifications de Policy et les événements comme un écart de sécurité.

Unmanaged, chiffrement et migration existants

Unmanaged signifie simplement que le composant Device Encryption est installé, mais qu’aucune Policy Device Encryption ne s’applique. Le support peut être chiffré ou non. Il ne s’agit pas d’une demande d’attribution immédiate d’une politique.

Avant adoption ou migration, l’état source est inventorié :

1. Plateforme, volumes et état du chiffrement local.
2. Protecteurs actifs ou utilisateurs FileVault autorisés.
3. Système de gestion précédent et paramètres GPO/MDM réellement appliqués.
4. Chemin de récupération vérifié sous la gestion précédente.
5. État cible prévu et exactement un système cible responsable.

Choisissez ensuite une seule branche selon la plateforme et poursuivez exclusivement avec la procédure BitLocker ou FileVault correspondante. Tant que la nouvelle clé de récupération n’est pas confirmée dans le système cible, le chemin de récupération précédent n’est pas supprimé et l’ancienne administration n’est pas mise hors service.

Les listes dans Central ont également des significations différentes : Computers without Device Encryption installed affiche les appareils gérés sans composant de chiffrement. Unmanaged computers, en revanche, peut contenir des ordinateurs synchronisés depuis l’annuaire sans protection Sophos. Avant qu’une installation ou une action politique ne soit effectuée, il est donc d’abord précisé dans quelle liste et pour quelle raison l’appareil apparaît.

Signatures historiques : les reconnaître sans les réparer soi-même

Les signatures suivantes proviennent de l’expérience opérationnelle d’Avanet. Elles aident à qualifier un dossier d’assistance, mais ne constituent pas une procédure de réparation actuelle :

• ManagementStatus.InvalidNamespace, 0x8004100E ou 0x80041002 liés à Win32_EncryptableVolume ;
• 0x803100B6 sur les appareils détectés comme ardoise ;
• System.BadImageFormatException à Sophos.Encryption.BitLockerService.exe ;
• Erreur BitLocker après la conversion de MBR en GPT ou du BIOS hérité en UEFI ;
• Erreur d’activation lorsque l’ISO ou le disque bootable est monté ;
• No UI user session available ;
• 0x80310048 ou FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED ;
• anciennes images d’erreur DMA/AllowedBuses ;
• Nécessité d’une journalisation avancée DEBUG ou TRACE.

La classe Microsoft Win32_EncryptableVolume explique le contexte WMI mais n’autorise pas le réenregistrement MOF ni la réparation WMI. De même, aucune DLL n’est copiée à partir des caches, aucune autorisation du Registre n’est reprise, aucune partition BCD ou de récupération n’est modifiée et aucune clé de journalisation non documentée n’est définie. Le support Sophos doit fournir des instructions à jour pour la version installée, le build exact et la signature complète.

Package de diagnostic et point d’escalade

Windows

• Export ou capture d’écran de l’Alerte Centrale sans Secret ;
• correspondance entre appareils, Policies et utilisateurs, avec horodatages ;
• sortie nettoyée de manage-bde -status ;
• extrait pertinent de CDE.log ;
• événements Windows correspondants et GPO BitLocker réellement appliquées ;
• état du TPM, de l’UEFI et du firmware ainsi que dernier redémarrage effectif ;
• Endpoint Self Help ou Sophos Diagnostic Utility (SDU), si disponible dans l’agent utilisé ;
• une courte liste des contrôles déjà effectués sans modifier l’état.

macOS

• correspondance entre appareils, Policies et utilisateurs, avec horodatages ;
• Version des composants macOS et Sophos ;
• sorties expurgées de seadmin status et seadmin --device-encryption ;
• Statut des volumes concernés dans l’application Sophos Device Encryption ;
• Informations indiquant si l’utilisateur dispose d’un jeton sécurisé/propriétaire de volume et d’une autorisation de pré-démarrage ;
• Heure de la dernière communication centrale réussie ;
• Package SDU et processus reproductible sans clé de récupération.

Avant le partage, les données utilisateur sont réduites à ce qui est nécessaire et les clés de récupération, mots de passe, identifiants de clé complets et autres secrets sont supprimés.

Le cas est transmis au support Sophos si la responsabilité ou la disponibilité de la Recovery Key reste incertaine, si Central et le système d’exploitation signalent des états contradictoires après une synchronisation réussie, si le service de l’agent échoue à plusieurs reprises, si une signature historique est présente ou si l’étape suivante modifierait WMI, le registre, les fichiers programme, le BCD ou les partitions. Le dossier indique le premier écart observé, et pas seulement la dernière erreur consécutive.

Questions fréquentes