Déployer Sophos Central Device Encryption en sécurité
Sophos Central Device Encryption administre le chiffrement de disque intégré à Windows et macOS : BitLocker sous Windows et FileVault sous macOS. Sophos ne fournit pas de moteur de chiffrement séparé, mais applique des Policies, collecte le statut et gère les Recovery Keys.
La gestion couvre les volumes de démarrage et les volumes de données fixes, mais pas les supports amovibles. BitLocker To Go peut chiffrer ces supports, mais Sophos Central n’en gère ni le statut ni les Recovery Keys.
Prérequis et licence
Avant le Rollout, il faut vérifier la licence, le système d’exploitation pris en charge, le matériel et le chiffrement existant. Un appareil peut déjà être administré par BitLocker, FileVault, des Group Policies, MDM ou un produit antérieur.
Une installation Endpoint réussie ne prouve pas que Device Encryption est licencié, sélectionné ou techniquement prêt. Sous My Environment > Installers, les installateurs complets Windows et macOS incluent tous les produits Endpoint couverts par la licence. On peut aussi utiliser Choose Components… pour sélectionner précisément Device Encryption. Après l’installation, il faut contrôler la Policy effective et le statut de chiffrement signalé, et non se fier uniquement à la réussite de l’installateur.
Conséquences de l’expiration de la licence
Après l’expiration de la licence Encryption, la page Device Encryption disparaît du Self Service Portal. Les utilisateurs ne peuvent alors plus récupérer eux-mêmes leurs Recovery Keys. Sophos supprime en outre la plupart des composants Encryption de l’appareil, tout en conservant les éléments nécessaires à une reconnexion ultérieure.
BitLocker et FileVault ne sont pas désactivés et les disques ne sont pas déchiffrés. C’est précisément ce qui rend une expiration non planifiée critique : la protection reste active alors que l’administration centrale et la Recovery sont limitées. Si un BitLocker Recovery Key change pendant cette phase non gérée, Central connaît encore l’ancien Key après la réactivation de la licence. Le renouvellement de licence et une procédure indépendante de Recovery d’urgence doivent donc faire partie de la planification opérationnelle.
Définir d’abord le propriétaire et la procédure de récupération
Avant d’activer la première Policy, les décisions suivantes doivent être prises :
- Qui peut récupérer des Recovery Keys ?
- Comment l’identité de l’utilisateur demandeur est-elle vérifiée ?
- Self Service est-il utilisé ?
- Où les opérations de récupération sont-elles consignées ?
- Que se passe-t-il en cas de départ, de perte de l’appareil ou de remplacement de la carte mère ?
- Comment un appareil est-il déchiffré ou effacé cryptographiquement avant son élimination ?
Un Recovery Key est traité comme un secret hautement sensible. Il n’est jamais conservé en clair dans un e-mail, un chat ou un ticket.
Attribution des Policies
Les Device Encryption Policies sont attribuées aux utilisateurs ou aux groupes. L’identité de l’utilisateur et l’association de l’appareil doivent donc être correctes. Le comportement est testé dans le Pilot pour les appareils partagés et les comptes locaux.
Un appareil Windows reste chiffré si un utilisateur sans Policy correspondante se connecte ultérieurement. Avec FileVault, en revanche, chaque utilisateur du Mac doit être couvert par la Policy de chiffrement afin que la gestion prévue des utilisateurs et de la récupération soit complète.
Avec Encrypt boot volume only, les volumes de données fixes restent hors de la Sophos Policy. Cette décision est comparée au stockage réel des données. L’option Windows Encrypt used space only accélère le chiffrement initial, mais peut laisser non chiffrées des zones contenant des données déjà supprimées ; elle est donc réservée aux nouveaux ordinateurs.
La Base Policy n’est pas activée sans contrôle sur tout le tenant. Un groupe Pilot couvre au minimum plusieurs générations de matériel, modèles d’ordinateurs portables, versions de système et états de chiffrement existants.
Planifier Windows et macOS séparément
Windows exige une conception appropriée pour TPM et BitLocker. Les modes d’authentification, les Group Policies et la Recovery Partition influencent l’activation.
macOS exige FileVault, une association fiable des utilisateurs et, selon la plateforme, un MDM Bootstrap Token ainsi que les autorisations Apple appropriées. Le Personal Recovery Key et les utilisateurs FileVault autorisés sont contrôlés.
Les détails propres aux plateformes figurent dans les articles Administrer BitLocker avec Sophos Central et Administrer FileVault avec Sophos Central.
Les erreurs précises de statut, de service, de TPM, de WMI et de Recovery Key sont traitées dans Résoudre systématiquement les erreurs Sophos Device Encryption.
Surveiller le statut
Sophos Central affiche le statut de chiffrement, les erreurs et les informations de récupération. Après l’activation, les points suivants sont vérifiés :
- La Policy s’applique au bon utilisateur et au bon appareil.
- Le chiffrement démarre et atteint 100 %.
- Le Recovery Key est enregistré dans Central.
- Le redémarrage et la connexion fonctionnent.
- La procédure de récupération a été testée de manière contrôlée.
- Les Alert E-mails et les responsabilités fonctionnent.
Une invite utilisateur ou un redémarrage en attente ne constitue pas un Rollout terminé.
Les Medium Alerts Device is not encrypted, Recovery key is missing et Device Encryption is suspended ne sont pas simplement fermés. L’absence d’un Key exige de vérifier immédiatement la communication avec Central. Un BitLocker suspendu peut indiquer un Recovery Key pas encore chargé, un Pre-Provisioning incomplet ou un Windows Update en attente de redémarrage. En présence de nombreux Encryption Events, Sophos recommande d’abord un redémarrage suivi d’une synchronisation, puis le type précis d’Event doit néanmoins être examiné.
Central distingue plusieurs valeurs de statut :
| Statut | Signification |
|---|---|
Encrypted | chiffrement terminé |
Pending | Policy attribuée, chiffrement en cours ou en attente |
Suspended | BitLocker est temporairement suspendu sur au moins un Volume |
Plain | au moins un Volume n’est pas chiffré ou n’a pas démarré |
Unmanaged | Agent présent, mais aucune Device Encryption Policy effective |
Not supported | plateforme ou mode de fonctionnement non pris en charge |
Not available | Central ne connaît pas le statut, par exemple si le composant manque |
Sous My Products > Encryption > Computers, le filtre Computers without Device Encryption installed affiche les ordinateurs gérés sans composant. Après AD Sync, l’onglet Unmanaged computers contient en plus les appareils connus dans AD mais sans protection Sophos. Ces deux listes ne doivent pas être confondues.
Self Service Recovery
Les utilisateurs autorisés peuvent récupérer eux-mêmes leur Recovery Key via Sophos Central Self Service Portal. Ils reçoivent au préalable une invitation de configuration. Le portail affiche uniquement les ordinateurs sur lesquels la personne s’est connectée en dernier. Si quelqu’un d’autre s’est connecté entre-temps, l’appareil n’est plus disponible pour cet utilisateur dans Self Service Recovery.
Pour configurer l’accès, il faut ouvrir My Environment > Users & Groups > Users, sélectionner les utilisateurs et cliquer sur Email Setup Link. Dans la boîte de dialogue, on choisit Sophos Central Self Service Welcome/Setup Email. Les utilisateurs ne peuvent employer le portail pour la récupération qu’après avoir suivi le lien d’activation. Cet accès doit être revu lors de l’Offboarding.
Self Service réduit la charge du Helpdesk, mais ne remplace ni la vérification d’identité lors d’une récupération administrative ni l’analyse de l’événement déclencheur.
Les administrateurs peuvent aussi rechercher une clé avec au moins cinq caractères de la Recovery Key ID ou Volume ID. BitLocker possède une clé par Volume protégé. Dès qu’un administrateur affiche un Windows Recovery Key, Sophos le marque comme utilisé et le remplace à la synchronisation suivante. Il ne doit donc pas être consulté uniquement à titre de test sur les appareils de production.
Lors de l’installation de Sophos Central Device Encryption, les clés de récupération BitLocker existantes sont automatiquement remplacées et ne peuvent plus être utilisées. Avant une migration de l’administration, il faut donc vérifier que la nouvelle clé est disponible dans Central.
Fichiers protégés par mot de passe sous Windows
Device Encryption 2.0 ou version ultérieure peut empaqueter sous Windows des fichiers jusqu’à 50 MB dans un fichier HTML protégé par AES-256. Cette opération s’effectue via le menu contextuel d’Explorer ou un Add-in pour Outlook classique sous Windows ; le nouvel Outlook n’est pas pris en charge.
Cette fonction sert au transfert sécurisé de fichiers, pas au chiffrement du disque, et ne remplace pas DLP. Le mot de passe est transmis par un canal distinct. La compatibilité des navigateurs et le processus du destinataire sont testés avant l’utilisation en production.
Reprendre un chiffrement existant
Un appareil déjà chiffré n’est pas automatiquement déchiffré puis rechiffré. Sophos peut reprendre les états BitLocker ou FileVault pris en charge, mais nécessite un Recovery Key valide et un état de gestion correct.
Lors des migrations, les Recovery Keys existants sont sauvegardés, puis renouvelés de manière contrôlée si le Workflow officiel le prévoit. Deux systèmes d’administration ne doivent pas imposer simultanément des Policies de chiffrement contradictoires.
Désactivation et Offboarding
La suppression du composant Sophos ne déchiffre pas automatiquement un disque dans tous les scénarios. Inversement, la suppression d’une Policy ne doit pas déclencher incidemment un déchiffrement.
Avant l’Offboarding, l’état cible, la conservation du Recovery Key, le changement de propriétaire et la désinstallation locale sont définis. Après la dernière action, le statut est contrôlé directement dans le système d’exploitation.