Gérez BitLocker facilement

Obtenez d'abord un agent sur chaque machine

La console ne peut gérer que ce qu'elle peut voir. Chaque PC doit d'abord installer l'agent Endpoint Central et créer des rapports. Sans agent, une machine est invisible pour la stratégie, pour le coffre de clés et pour chaque rapport de ce guide.

Comparez la liste des machines de la console avec celles que possède réellement le bureau : enregistrements d'achats, liste des ordinateurs Active Directory, analyse du réseau. Tout PC manquant n'est pas « probablement crypté » ; il est inconnu, et le risque est inconnu. Les projets de chiffrement de flotte échouent généralement à cette étape de visibilité, et non à l’étape de chiffrement : comblez d’abord l’écart.

Écrivez une politique avant de toucher un PC

Créez la stratégie BitLocker de manière centralisée au lieu de configurer les PC un par un. Une politique est une définition de « chiffré correctement », et la procédure pas à pas de la vidéo définit les décisions qui comptent :

Protecteur : le TPM déverrouille automatiquement le lecteur uniquement au démarrage : un ordinateur portable volé atteint toujours l'écran de connexion Windows. TPM + PIN demande un code PIN avant même le démarrage de Windows, ce qui est le paramètre qui arrête véritablement un voleur ; pour les ordinateurs portables qui voyagent, cela vaut la petite friction quotidienne. Les machines sans TPM peuvent utiliser un protecteur de phrase secrète – un choix délibéré, jamais un accident.

Algorithme et portée : XTS-AES 128 ou 256 (256 est ce que la plupart des auditeurs aiment voir écrit ; ni l'un ni l'autre n'est forcé en pratique), et le chiffrement de l'espace utilisé uniquement pour les machines flambant neuves par rapport au disque plein pour toute machine déjà en service, car l'espace "vide" contient toujours les fichiers supprimés.

Configurez le dépôt de clé et vérifiez-le avant d'appliquer quoi que ce soit

Chaque lecteur BitLocker possède une clé de récupération à 48 chiffres, et le jour où un PC affiche l'écran de récupération bleu, cette clé est la seule chose entre l'utilisateur et un lecteur effacé. Escrow signifie que la clé est collectée automatiquement et stockée là où l'organisation la contrôle : sur le serveur Endpoint Central, avec la possibilité de sauvegarder également les clés dans Active Directory ou Azure AD.

La règle d'Endpoint Central est stricte, et la rigueur est la fonctionnalité : le chiffrement ne démarre pas tant que la clé de récupération n'a pas été stockée en toute sécurité sur le serveur. Un lecteur ne peut jamais être chiffré avec sa seule clé bloquée sur la machine elle-même.

Transférer d’abord la politique à un groupe pilote

Déployez la politique terminée sur un petit groupe pilote devant l'ensemble du bureau – quelques machines vers lesquelles vous pouvez vous rendre. Regardez-les se déplacer à travers les états de la console, confirmez que la clé de récupération de chacun a atterri dans le coffre-fort, puis étendez ensuite le déploiement à des groupes de machines (ManageEngine documente des poussées allant jusqu'à 250 appareils à la fois). Les nouvelles machines peuvent bénéficier de la police automatiquement au fur et à mesure de leur adhésion, de sorte que la flotte reste couverte après la fin du projet.

Lire le tableau d'état – crypté, en attente, non conforme

À partir de là, le travail consiste à lire, pas à voyager. La vue Ordinateurs gérés BitLocker de la console présente chaque machine gérée dans l'un des trois états : Chiffré, Chiffrement en attente ou Non conforme. Ce tableau - et non une promenade dans le bureau - est la façon dont vous répondez « lesquels de nos PC ne sont toujours pas cryptés ? »

Travailler la liste des lacunes dans l'ordre des risques

« En attente » et « Non conforme » sont des symptômes et non des diagnostics. Les causes habituelles : la machine ne s'est pas enregistrée (éteinte, en congé, l'agent a cessé de signaler) ; une condition préalable a échoué : les vérifications préalables au déploiement de la console signalent des classiques tels que l'incompatibilité du mode BIOS et les erreurs de propriété du TPM ; la machine n'a pas de TPM et aucune phrase secrète de secours n'a été prévue ; ou l'édition Windows ne peut pas du tout faire BitLocker - une machine Windows Home restera pour toujours dans l'espace jusqu'à ce qu'elle soit mise à niveau ou remplacée.

Effacez la liste par ordre de risque : les ordinateurs portables qui quittent le bâtiment en premier, puis les machines contenant des données sensibles (comptes, RH, dossiers clients), puis les ordinateurs de bureau dans les espaces partagés, puis les ordinateurs de bureau fixes dans les salles contrôlées. Et vérifiez correctement la finition sur chaque machine : l'état indique Crypté et vous pouvez récupérer sa clé de récupération dans le coffre-fort. Les deux – pas un.

Prouvez-le – Rapports, exercice de récupération et vérification locale

Lorsque le tableau est propre, extrayez le rapport de chiffrement : quelles machines sont chiffrées, avec quelle politique et si la clé de chaque lecteur est stockée. Ce rapport est la preuve d’audit – la différence entre « nous pensons que nous sommes cryptés » et un document que vous pouvez remettre.

Répétez ensuite une fois le pire jour : choisissez une machine, ouvrez la recherche de clé de récupération de la console et récupérez sa clé comme vous le feriez lors d'un véritable verrouillage. L'engagement que vous n'avez jamais testé est un espoir, pas un système. Faites la même chose lorsque les gens changent : lorsqu'un employé quitte l'entreprise, faites la rotation des clés et accédez-y correctement au lieu de laisser leurs anciens accès et clés en vigueur.

Assis vous-même devant un PC, vous pouvez vérifier l'état de cette machine à partir d'une invite de commande d'administrateur :

manage-bde -status C:

Cela vous indique l'état de ce disque – il ne dit rien sur l'endroit où se trouve sa clé de récupération. Le coffre-fort est la réponse à cette deuxième question, et c’est tout l’intérêt de gérer BitLocker à partir d’une seule console.