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, appareils et 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 d’iOS, les clés de récupération, les politiques relatives aux appareils et les rapports.

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 lecteur amovible est perdu, volé, réparé, mis hors service ou consulté sans autorisation.

Le chiffrement natif est puissant, car 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.

La fonction 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, sauf si la bonne authentification, la clé de récupération ou la méthode de déverrouillage est disponible.

Le NIST décrit le chiffrement du stockage comme un moyen de restreindre l’accès aux informations stockées sur des appareils destinés aux 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 ↗, en particulier pour les appareils perdus, les lecteurs amovibles et la planification de la récupération.

En pratique, le chiffrement natif aide à réduire quatre risques :

• Un ordinateur portable perdu expose des fichiers professionnels.
• Un téléphone volé donne accès à des données professionnelles.
• Un lecteur mis hors service reste lisible après son élimination.
• Un utilisateur 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.

Cartographie des contrôles de gestion du chiffrement natif

La façon la plus simple d’envisager la gestion du chiffrement natif est 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 de l’appareil

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

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

Une politique pratique de chiffrement Windows devrait définir :

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

La planification de la récupération est importante. 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 de données. Les équipes doivent documenter l’option autorisée avant qu’un véritable verrouillage ne survienne.

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

Sur macOS, le chiffrement natif repose sur FileVault. Guide 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 plateformes Apple plus récentes, 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 consiste à supposer que « les appareils Apple sont chiffrés » signifie que l’organisation maîtrise la récupération et le reporting. Ce sont deux questions distinctes.

Android : gérer le chiffrement via une 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 est généralement assurée via Android Enterprise. Le guide de Google sur la gestion d’Android ↗ explique que les organisations peuvent imposer des politiques de sécurité telles que le verrouillage de l’écran et le chiffrement du stockage au moyen d’une solution de gestion.

La gestion du chiffrement Android doit définir :

• quels appareils sont autorisés pour un usage professionnel ;
• 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 appareils plus anciens répondent encore aux exigences de sécurité.

Le chiffrement Android est le plus efficace lorsqu’il est associé à l’inscription des appareils, à une politique d’écran verrouillé, à 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 de clés. Cela semble évident, mais de nombreux programmes de chiffrement échouent parce que la gestion des clés est faible.

Les directives de gestion des clés du NIST ↗ 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 : 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 doit répondre aux questions suivantes :

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 lecteurs amovibles susceptibles de stocker des données professionnelles.

Étape 2 : définir la couverture requise

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

Étape 3 : choisir les politiques de plateforme

Définissez 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 : tester avec un petit groupe

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

Étape 6 : appliquer progressivement

Passez du mode rapport uniquement à l’application des règles après résolution des problèmes du pilote.

Étape 7 : surveiller en continu

Examinez l’état du chiffrement, la protection suspendue, les échecs de dépôt, 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 communiquer à la direction

Les responsables de la sécurité n’ont pas besoin de connaître tous les paramètres techniques. 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 doit 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 a échoué ;
• les utilisateurs ou équipes à haut risque non couverts ;
• les événements de récupération au cours de la période de reporting ;
• les appareils en attente de mise hors service ou d’effacement ;
• les exceptions de politique et leurs responsables.

Si vous devez expliquer la couverture du chiffrement aux dirigeants ou aux clients, vous pouvez transformer votre politique de chiffrement natif en 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 le diaporama en déversement technique.

Lorsque le chiffrement natif ne suffit pas

Le chiffrement natif protège les données stockées, mais 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 l’hameçonnage ;
• 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 fiable le chiffrement intégré. 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.