Reprendre ou migrer Sophos Device Encryption
Un chiffrement existant n’est pas repris sur le seul critère du système d’exploitation. Quatre questions sont déterminantes : Quelle technologie chiffre le volume, quel système la gère actuellement, quel parcours de récupération fonctionne et quel état cible a été convenu ? Ce n’est qu’une fois ces points établis qu’un seul parcours de migration est choisi.
Décision rapide : Un chiffrement BitLocker ou FileVault natif déjà actif est généralement repris sans déchiffrement préalable. Un appareil non chiffré suit le parcours de déploiement habituel. SafeGuard BitLocker, SafeGuard Full Disk Encryption (FDE) et FileVault géré par SafeGuard constituent des états initiaux distincts. Si la version de SafeGuard est inconnue, si les modules sont mixtes ou si aucune confirmation actuelle du support Sophos n’est disponible, le processus est interrompu : les anciennes instructions ne doivent pas être utilisées.
Avant de prendre une décision : sécuriser les preuves et la récupération
L’inventaire est tenu par appareil ou groupe d’appareils homogène. Un statut tel que Unmanaged dans Sophos Central ou Sophos Fusion indique uniquement que Sophos Device Encryption ne gère pas l’appareil. Cela ne prouve ni que le volume n’est pas chiffré ni qui possède une clé de récupération existante.
Avant toute affectation de Policy, désinstallation ou opération de déchiffrement, consignez au minimum les éléments suivants :
- identité de l’appareil, système d’exploitation, prise en charge de la plateforme au regard de son cycle de vie et tenant cible,
- chaque volume interne avec la technologie de chiffrement, la progression du chiffrement et l’état de protection local,
- système de gestion responsable : système d’exploitation ou MDM, Sophos Fusion, SafeGuard Enterprise ou inconnu,
- modules de chiffrement installés incluant la version exacte du produit ; avec SafeGuard, vous pouvez également enregistrer séparément les composants FDE, de gestion BitLocker et de chiffrement de fichiers,
- Policies effectivement appliquées, protecteurs BitLocker ou utilisateurs FileVault autorisés au pré-démarrage,
- ID de clé de récupération et stockage responsable sans copier la clé dans l’inventaire, le ticket ou la capture d’écran,
- accès testé et autorisé à la clé de récupération actuellement appropriée,
- les opérations de chiffrement, de déchiffrement ou de dépôt de clé encore en cours.
Les configurations système requises pour Sophos Endpoint et les limites du cycle de vie sont examinées avant la planification technique. Si l’état du chiffrement local est inconnu, si un processus est toujours actif ou si le chemin de récupération ne peut pas être testé, l’appareil reste inchangé. Le traitement s’arrête ; une désinstallation d’essai ne constitue pas un diagnostic valide.
Détecter l’état initial et choisir le chemin
| État initial | Chemin sélectionné | Exécution |
|---|---|---|
| Déjà géré par Sophos Fusion | Aucune migration ; prouver l’affectation et l’état de l’appareil | Valider l’état de BitLocker ou Vérifier l’état et la récupération de FileVault |
| BitLocker natif et non géré par Sophos | Reprise sans déchiffrement de routine | Appliquer BitLocker existant |
| Appareil non chiffré confirmé localement | Nouveau déploiement | Préparer BitLocker ou Préparer FileVault |
| Appareil uniquement signalé comme Unmanaged, Not available ou inconnu dans l’inventaire | Déterminer d’abord la signification de l’inventaire, la technologie de chiffrement locale et le système de gestion responsable | Distinguer trois inventaires aux intitulés similaires |
| SafeGuard BitLocker | Déterminer la version et les modules ; ne poursuivre qu’après confirmation actuelle de la prise en charge de cet état précis | Distinguer les parcours SafeGuard BitLocker selon l’état initial |
| SafeGuard FDE | Ne traitez pas comme BitLocker ; ne démarrez pas sans confirmation actuelle pour l’étape de migration limitée dans le temps | Migrer SafeGuard Enterprise Full Disk Encryption |
| FileVault natif et non géré par Sophos | Reprise sans déchiffrement de routine | Appliquer FileVault déjà actif |
| FileVault géré par SafeGuard | Clarifiez d’abord l’état de FileVault, les modules et l’étape de migration prise en charge | Appliquer FileVault géré par SafeGuard |
Le tableau détermine uniquement les instructions de plateforme appropriées. Les séquences de clics, les commandes, les changements de protecteur et le déchiffrement y sont uniquement décrits afin que le même processus de sécurité ne soit pas exécuté différemment à plusieurs endroits.
Pour l’exécution, ouvrez toujours les instructions de plateforme liées dans le tableau et utilisez uniquement la section correspondant à l’état initial constaté. Si cette section est absente ou ne couvre pas la version détectée et les modules installés, ne poursuivez pas avec une procédure BitLocker ou FileVault générique. L’état reste inchangé et l’inventaire est transmis au support Sophos. La sélection d’un chemin de migration ne permet jamais à un module SafeGuard d’être conservé ou de continuer à fonctionner en parallèle.
Déjà géré par Sophos
Si l’objet correspondant au bon appareil dans le bon tenant Fusion signale qu’une Policy Device Encryption s’applique, aucune migration n’est nécessaire. Comparez néanmoins l’état local, l’état dans Fusion et l’association de la clé de récupération. L’état vert ou chiffré d’un ancien appareil portant un nom similaire ne prouve rien pour l’appareil actuel.
Pour Windows, procédez à la validation dans Gérer BitLocker avec Sophos Fusion – Valider l’état et les rapports. Sur Mac, suivez Gérer FileVault avec Sophos Fusion – Valider l’état et la préparation à la récupération.
Reprendre BitLocker ou FileVault natif
Avec BitLocker natif, le volume reste chiffré. La procédure et les conséquences du remplacement des protecteurs et de la clé de récupération sont décrites dans Migrer BitLocker existant. Dès que Sophos a remplacé les protecteurs BitLocker, les anciennes clés de récupération ne permettent plus de revenir à l’état précédent. Le parcours de récupération existant reste donc disponible jusqu’à la reprise confirmée. Après la reprise, il ne peut plus servir de solution de retour arrière.
Avec FileVault natif, aucun déchiffrement préalable de routine n’est nécessaire. La section Appliquer un FileVault déjà actif décrit la confirmation de l’utilisateur local, la génération d’une nouvelle clé de récupération personnelle et la vérification du dépôt de la clé. La méthode de récupération précédente n’est ignorée que lorsque la nouvelle clé correspondant au Mac est réellement accessible dans Fusion.
Seul un appareil non chiffré confirmé localement ne suit pas la migration. Windows démarre par Vérifier les prérequis et la compatibilité, macOS démarre par Exigences avant la première affectation. Un état Unmanaged ou un inventaire inconnu ne suffit pas à lui seul pour cette classification. Si la vérification locale affiche déjà BitLocker, FileVault ou SafeGuard, l’appareil suit à la place les instructions de reprise, de migration ou d’assistance appropriées ; il n’est pas traité comme un appareil non chiffré.
SafeGuard BitLocker : distinguer les versions 6/7 et 8 ou ultérieures
Bien que SafeGuard BitLocker utilise BitLocker comme technologie de chiffrement, les états de gestion et de protection dépendent de la version. Par conséquent, les appareils dotés de SafeGuard 6 ou 7 ne sont pas modifiés avec les appareils de SafeGuard 8.
- SafeGuard 6 ou 7 : Ne déduisez pas des indications historiques qu’une mise à niveau, une version intermédiaire ou une désinstallation spécifique est toujours prise en charge aujourd’hui. Sans confirmation écrite à jour de la version trouvée, le processus s’arrêtera. S’il est disponible, vous travaillerez exclusivement avec SafeGuard Enterprise BitLocker 6.x ou 7.x.
- SafeGuard 8 ou version ultérieure : BitLocker est adopté sans déchiffrement de routine. Ici aussi, une confirmation écrite à jour doit couvrir l’état exact de SafeGuard et les modules concernés. L’ordre spécifique est répertorié sous SafeGuard Enterprise BitLocker 8.0 ou version ultérieure, et non dans cette aide à la décision.
Traitez séparément les parcs hétérogènes. Si des versions inconnues, des composants FDE et BitLocker simultanés ou des modules supplémentaires de chiffrement de fichiers sont détectés, interrompez la procédure. Ces modules ne sont ni conservés ni réinstallés par mesure de précaution.
SafeGuard Full Disk Encryption : déchiffrer et rechiffrer
SafeGuard FDE n’est pas simplement un autre système de gestion de BitLocker. Cet état initial exige un déchiffrement complet suivi d’un nouveau chiffrement : le chiffrement source est intégralement retiré selon un parcours SafeGuard actuellement confirmé par écrit, son achèvement est établi localement, puis seulement BitLocker est déployé sous Sophos Fusion.
Sans confirmation écrite à jour portant sur l’étape précise et limitée dans le temps de la migration FDE, ne commencez pas cette procédure. Ne tentez surtout pas de la contourner en maintenant les anciens composants SafeGuard en service ou en les réinstallant. Dans ce cas, les preuves de version, de module, de volume et de récupération sont transmises au support Sophos. Si la confirmation est disponible, effectuez le travail exclusivement selon SafeGuard Enterprise Full Disk Encryption. Le processus qui y est décrit doit couvrir le déchiffrement FDE par étapes, sa preuve locale, une période limitée pendant laquelle les données sont en clair et le déploiement ultérieur de BitLocker. Si l’une de ces étapes manque, le dossier reste bloqué ; la procédure générale de déchiffrement BitLocker ne peut pas s’y substituer.
FileVault géré par SafeGuard
Sur un Mac, il est d’abord prouvé qu’Apple FileVault chiffre réellement et quels modules SafeGuard se chargent uniquement de l’administration. L’ordre de déchiffrement ou de mise hors service sous Windows n’est pas répercuté sur FileVault.
Si le support Sophos confirme par écrit l’étape de migration limitée dans le temps, effectuez l’opération conformément à FileVault – État initial de SafeGuard. En présence de modules inconnus ou mixtes, arrêtez la procédure. Cette confirmation ne permet pas non plus de conserver, de réinstaller ou de continuer à fonctionner en parallèle un module SafeGuard pour le chiffrement de fichiers. Un tel projet doit rester suspendu jusqu’à l’obtention d’une confirmation écrite distincte du support Sophos.
Valider l’état cible
Le système de gestion existant ne sera mis hors service que lorsque tous les points suivants auront été respectés pour l’appareil concerné :
- L’identité de l’appareil et le locataire cible sont corrects.
- L’état du volume local indique l’état de chiffrement convenu ; aucun processus de chiffrement ou de déchiffrement n’est ouvert de manière inattendue.
- Fusion affiche la stratégie prévue et le statut géré approprié.
- Un administrateur autorisé peut récupérer la nouvelle clé de récupération correspondant à l’appareil et à l’ID affiché sans la divulguer dans le rapport de validation.
- L’accès au pré-démarrage et le redémarrage contrôlé fonctionnent avec les utilisateurs ou protecteurs prévus.
- Le parcours précédent de récupération et de gestion reste disponible jusqu’à ce que toutes ces preuves soient réunies.
Si ne serait-ce qu’un seul de ces éléments de preuve manque, l’introduction ne se poursuivra pas. Avec BitLocker, l’ancienne clé n’est pas prévue comme chemin de retour après un changement de protecteur. Avec FileVault, la désinstallation de l’agent ne constitue jamais une preuve de transfert de responsabilité sur la clé.
Itinéraire de retour, déclassement et escalade
Avant le changement effectif, préparez le retour arrière comme suit : arrêtez l’affectation de la Policy, limitez le pilote et conservez le parcours de récupération précédent. Une fois le changement de protecteur ou le déchiffrement commencé, aucun retour général à l’état antérieur n’est possible. Consignez l’état, validez-le de nouveau selon l’article de la plateforme concernée et ne poursuivez que par un parcours actuellement pris en charge. En cas de doute, ne réinstallez pas SafeGuard et ne le laissez pas fonctionner dans l’espoir de restaurer l’état précédent.
Si l’agent de point final Sophos local doit également être supprimé après un transfert de chiffrement réussi, seules les instructions suivantes spécifiques à la plateforme s’appliquent :
- Désinstaller Sophos Endpoint sous Windows une fois l’état cible de BitLocker et la responsabilité de récupération établis,
- Désinstaller Sophos Endpoint sur macOS une fois l’état cible de FileVault, la responsabilité de récupération testée et les preuves locales transmises.
La suppression ou la restauration ultérieure de l’enregistrement de l’appareil Fusion est un autre travail distinct. Il fait partie de Remplacer ou retirer l’appareil Sophos Fusion. Ni la suppression de l’enregistrement ni la désinstallation de l’agent ne déchiffrent automatiquement un volume ou ne transfèrent une clé FileVault.
Transmettez le dossier au support Sophos si la version ou les modules SafeGuard sont inconnus, si les informations actuelles sur le cycle de vie du produit manquent, si la récupération ne peut pas être testée avant la transition, si le système de gestion responsable et l’état local du chiffrement se contredisent, ou si un changement de clé ou de protecteur a commencé sans nouvelles informations de récupération appropriées. Les identités des appareils et des volumes, les versions, l’inventaire des modules, les heures d’état et les messages d’erreur sont transférés, mais aucune clé de récupération.