gestion du chiffrement natif

La gestion du chiffrement natif consiste à contrôler les fonctionnalités de chiffrement déjà intégrées aux systèmes d’exploitation, aux appareils et aux plateformes. Pour la plupart des organisations, cela inclut Windows BitLocker, macOS FileVault, le chiffrement basé sur les fichiers d’Android, la protection des données iOS, les clés de récupération, les politiques relatives aux appareils et le reporting.

L’objectif est simple : veiller à ce que les données sensibles restent protégées si un ordinateur portable, un téléphone, une tablette ou un support amovible est perdu, volé, réparé, mis hors service ou consulté sans autorisation.

Le chiffrement natif est puissant parce qu’il fait déjà partie de la plateforme. Mais il doit tout de même être géré. Sans politiques claires, stockage des clés de récupération, contrôles de conformité et accompagnement des utilisateurs, le chiffrement intégré peut devenir incohérent ou difficile à récupérer en cas de problème.

Le rôle de sécurité que le chiffrement natif est censé assurer

Le chiffrement natif protège les données au repos. Cela signifie que les données stockées sur un appareil restent illisibles à moins que la bonne authentification, la clé de récupération ou la méthode de déverrouillage soit disponible.

Le NIST décrit le chiffrement du stockage comme un moyen de restreindre l’accès aux informations stockées sur les appareils des utilisateurs finaux, tels que les ordinateurs portables, les appareils mobiles et les supports amovibles. Ses recommandations sur le chiffrement du stockage ↗ constituent un excellent point de départ pour comprendre le chiffrement de disque complet, le chiffrement de volume et le chiffrement au niveau des fichiers.

La CISA fournit des conseils pratiques similaires sur sa page consacrée à la protection des données stockées sur les appareils ↗, notamment pour les appareils perdus, les supports amovibles et la planification de la récupération.

En pratique, le chiffrement natif aide à gérer quatre risques :

• Un ordinateur portable perdu qui expose des fichiers professionnels.
• Un téléphone volé donnant accès à des données professionnelles.
• Un disque mis hors service qui reste lisible après son élimination.
• Un utilisateur qui oublie ses identifiants et a besoin d’une récupération sécurisée.

Le chiffrement lui-même n’est qu’un élément. La couche de gestion détermine si la protection est cohérente.

Carte des contrôles de gestion du chiffrement natif

La manière la plus simple d’envisager la gestion du chiffrement natif est de la voir comme un ensemble de contrôles, et non comme un simple interrupteur.

Ce tableau fait la différence entre « le chiffrement est disponible » et « le chiffrement est réellement géré ».

Windows : gérer BitLocker et le chiffrement des appareils

Sous Windows, le chiffrement natif désigne généralement BitLocker ou le chiffrement automatique de l’appareil.

La présentation de BitLocker par Microsoft ↗ explique que BitLocker protège les volumes contre les accès hors ligne, en particulier lorsque les appareils sont perdus, volés ou retirés du service. Dans les environnements gérés, l’important n’est pas seulement d’activer BitLocker. Il faut aussi s’assurer que la bonne politique, la bonne méthode de récupération et le bon processus de reporting sont en place.

Une politique pratique de chiffrement Windows devrait définir :

• quels disques doivent être chiffrés ;
• si la protection par TPM seul est suffisante ;
• si des codes PIN sont requis pour les utilisateurs à risque plus élevé ;
• où les clés de récupération sont sauvegardées ;
• qui peut récupérer les clés de récupération ;
• comment le chiffrement en échec ou suspendu est signalé.

La planification de la récupération est importante. La présentation de la récupération BitLocker par Microsoft ↗ explique les différentes options de récupération, notamment les mots de passe de récupération, les clés de récupération, les packages de clés et les agents de récupération des données. Les équipes doivent documenter l’option autorisée avant qu’un véritable verrouillage ne se produise.

macOS et appareils Apple : gérer FileVault et la protection des données

Sur macOS, le chiffrement natif s’articule autour de FileVault. Le guide d’Apple sur la gestion de FileVault avec la gestion des appareils ↗ explique comment les organisations peuvent imposer FileVault, contrôler les reports par les utilisateurs, gérer l’affichage des clés de récupération aux utilisateurs et déposer les clés de récupération personnelles via la gestion des appareils.

Pour l’iPhone, l’iPad et les nouvelles plateformes Apple, le chiffrement est étroitement lié à la protection des données. La présentation du chiffrement et de la protection des données d’Apple ↗ explique comment les appareils Apple protègent les données des utilisateurs et de l’entreprise si un appareil est perdu, volé ou compromis.

Pour les environnements Apple, la gestion doit se concentrer sur :

• l’application de FileVault lors de la configuration lorsque cela est approprié ;
• le dépôt des clés de récupération dans le système de gestion approuvé ;
• la rotation des clés de récupération après utilisation ;
• la confirmation des utilisateurs pouvant déverrouiller les volumes chiffrés ;
• la documentation de ce qui se passe lors de la migration ou de la réattribution d’un appareil.

Le principal risque est de supposer que « les appareils Apple sont chiffrés » signifie que l’organisation maîtrise la récupération et le reporting. Ce sont des questions distinctes.

Android : gérer le chiffrement via la politique d’appareil

Les appareils Android intègrent également un chiffrement natif. Le chiffrement basé sur les fichiers d’Android permet de chiffrer différents fichiers avec différentes clés, et l’Android Open Source Project explique ce modèle dans sa documentation sur le chiffrement basé sur les fichiers ↗.

Pour les appareils professionnels, la gestion du chiffrement s’effectue généralement via Android Enterprise. Le guide Google sur la gestion Android ↗ explique que les organisations peuvent appliquer des politiques de sécurité, telles que le verrouillage de l’écran et le chiffrement du stockage, par l’intermédiaire d’une solution de gestion.

La gestion du chiffrement Android doit définir :

• quels appareils sont autorisés à des fins professionnelles ;
• si l’appareil est entièrement géré ou s’il s’agit d’un BYOD avec profil professionnel ;
• quelle robustesse de verrouillage d’écran est requise ;
• comment les appareils perdus sont verrouillés ou effacés ;
• comment l’état de conformité est surveillé ;
• si les anciens appareils répondent toujours aux exigences de sécurité.

Le chiffrement Android est le plus efficace lorsqu’il est associé à l’enrôlement des appareils, à une politique d’écran de verrouillage, à des exigences de mise à jour et à l’effacement à distance.

La gestion des clés est le véritable problème de gestion

Le chiffrement dépend des clés. Cela semble évident, mais de nombreux programmes de chiffrement échouent parce que la gestion des clés est insuffisante.

Les recommandations du NIST sur la gestion des clés ↗ couvrent la planification, la protection, le cycle de vie et la gouvernance du matériel de clés cryptographiques. Pour le chiffrement natif, la question pratique est généralement la suivante : où les clés de récupération sont-elles stockées et qui peut les utiliser ?

Un bon processus de gestion des clés de récupération devrait répondre à ces questions :

1. Où la clé est-elle déposée ? 2. La clé est-elle stockée automatiquement ou manuellement ? 3. Qui peut la récupérer ? 4. La récupération est-elle journalisée ? 5. La clé est-elle renouvelée après utilisation ? 6. Que se passe-t-il lorsque l’appareil est mis hors service ? 7. Que se passe-t-il si le système de gestion change ?

Ne laissez pas les clés de récupération dans des captures d’écran, des feuilles de calcul, des lecteurs partagés ou des notes personnelles. L’accès à la récupération doit être contrôlé, journalisé et limité.

Une séquence de déploiement pratique

La gestion du chiffrement natif est plus facile lorsqu’elle est déployée par étapes.

Étape 1 : inventorier les appareils

Répertoriez les ordinateurs portables, ordinateurs de bureau, téléphones, tablettes et supports amovibles susceptibles de stocker des données professionnelles.

Étape 2 : définir la couverture requise

Déterminez quels types d’appareils doivent utiliser le chiffrement natif et quelles exceptions sont autorisées.

Étape 3 : choisir les politiques de plateforme

Configurez les règles BitLocker, FileVault, Android et des autres plateformes avant un déploiement à grande échelle.

Étape 4 : configurer le dépôt des clés de récupération

Assurez-vous que les clés de récupération sont stockées dans le système approuvé avant que les utilisateurs n’en dépendent.

Étape 5 : réaliser un pilote avec un petit groupe

Testez la récupération, les conflits de politiques, la migration des appareils et la communication auprès des utilisateurs.

Étape 6 : appliquer progressivement

Passez du mode de reporting uniquement à l’application après la résolution des problèmes rencontrés lors du pilote.

Étape 7 : surveiller en continu

Examinez l’état du chiffrement, la protection suspendue, les dépôts ayant échoué, les appareils non gérés et les événements de récupération.

Cette séquence évite l’erreur la plus fréquente : activer largement le chiffrement avant d’avoir testé la récupération.

Ce qu’il faut présenter à la direction

Les responsables de la sécurité n’ont pas besoin de chaque paramètre technique. Ils ont besoin d’une vision claire de la couverture, des risques et de l’état de préparation.

Un rapport utile sur le chiffrement natif devrait présenter :

• le pourcentage d’appareils gérés chiffrés ;
• le nombre d’appareils sans clés de récupération ;
• les appareils dont le chiffrement est suspendu ou en échec ;
• les utilisateurs ou équipes à haut risque non couverts ;
• les événements de récupération durant la période de reporting ;
• les appareils en attente de mise hors service ou d’effacement ;
• les exceptions aux politiques et leurs responsables.

Si vous devez expliquer la couverture de chiffrement aux dirigeants ou aux clients, vous pouvez transformer votre politique de chiffrement natif en une présentation prête pour les parties prenantes avec Pi ↗. Utilisez-la pour présenter la couverture, les risques, l’état de préparation à la récupération et les prochaines étapes sans transformer la présentation en déversement d’informations techniques.

Lorsque le chiffrement natif ne suffit pas

Le chiffrement natif protège les données stockées, mais il ne résout pas tous les problèmes de sécurité.

Il ne remplace pas :

• la gestion des identités et des accès ;
• la détection et la réponse sur les terminaux ;
• la sauvegarde et la reprise après sinistre ;
• la gestion des correctifs ;
• la prévention des pertes de données ;
• la protection contre le phishing ;
• les contrôles d’accès au cloud ;
• la mise au rebut sécurisée des appareils.

Il ne protège pas non plus les données après qu’un utilisateur autorisé a déverrouillé l’appareil et accédé normalement aux fichiers. Une fois le système en fonctionnement et l’utilisateur authentifié, d’autres contrôles restent nécessaires.

Le chiffrement natif doit être considéré comme un contrôle de base, et non comme l’ensemble de la stratégie de sécurité.

Le verdict

La gestion du chiffrement natif consiste à rendre le chiffrement intégré fiable. Activer BitLocker, FileVault, le chiffrement Android ou la protection des données Apple n’est qu’un début.

Un programme mature définit la couverture, applique les politiques, dépose les clés de récupération, limite l’accès à la récupération, surveille la conformité et teste ce qui se passe lorsqu’un appareil est perdu, verrouillé, migré ou mis hors service.

Le meilleur programme de chiffrement n’est pas celui qui possède la case à cocher la plus robuste. C’est celui où la protection, la récupération et le reporting fonctionnent tous lorsque l’organisation en a réellement besoin.