Surveillance de la sécuritéDéploiement d'EFS : Partie 1

John Morello

À présent, tout le monde a entendu parler de pertes de données confidentielles ou sensibles dues au vol ou à la perte de portables. Des portables disparaissent régulièrement. Avec l'augmentation des vols d'identités et le fait que la conformité aux règlementations n'a jamais été aussi indispensable, la protection approfondie des données se trouvant sur les systèmes informatiques mobiles est essentielle.

Une des solutions consiste à utiliser le système de fichiers EFS (Encrypting File System), inclus dans Windows® depuis Windows 2000. Ce système fournit un cryptage sur disque hautes performances intégré. EFS s'intègre parfaitement avec Windows Explorer, si bien que, souvent, les utilisateurs finaux ne sauront même pas lorsque l'un des fichiers qu'ils utilisent est crypté. De plus, EFS fonctionne également bien avec l'authentification Windows native et les technologies de contrôle d'accès, de sorte que les utilisateurs n'ont pas besoin de se rappeler différents mots de passe pour accéder à leurs données. Enfin, EFS fournit des options faciles à gérer pour la récupération des données au cas où un utilisateur perd l'accès à ses clés de cryptage (par exemple, si son profil utilisateur est supprimé ou endommagé ou en cas de perte de sa carte à puce).

EFS utilise la technologie de cryptographie intégrée dans Windows pour créer, enregistrer et déployer des clés de cryptage solides pour la protection des données. Dans Windows XP Service Pack 1 (SP1) et les versions ultérieures, EFS utilise l'algorithme AES (Advanced Encryption Standard) avec une clé 256 bits pour crypter les données sur le disque. Ces clés symétriques sont ensuite protégées avec une paire de clés asymétriques (RSA). Le système EFS crypte chaque fichier avec sa clé AES, puis il crypte cette clé avec la clé RSA de l'utilisateur et il enregistre le résultat dans le fichier. Pour plus d'informations sur la cryptographie EFS, consultez l'encadré « Ressources EFS ». Pour le moment, je vais laisser de côté les bases techniques du système de fichiers EFS pour vous expliquer comment déployer le système et le rendre viable dans votre environnement. C'est la raison pour laquelle cet article suppose une connaissance préalable des concepts de cryptographie EFS.

Remarque sur la sécurité EFS

Certaines applications prétendent pouvoir décrypter le cryptage EFS. En fait, aucune de ces applications ne décrypte le chiffrement AES (ou DES - Data Encryption Standard - ou DESX - Expanded Data Encryption Standard), mais elles parviennent à accéder à la clé confidentielle EFS de l'utilisateur en s'acharnant à découvrir son mot de passe. Une chose importante qu'il ne faut pas oublier en ce qui concerne le cryptage EFS : les clés confidentielles utilisées pour créer et protéger les données cryptées utilisent les normes DPAPI (Data Protection API). DPAPI utilise des dérivés des informations d'identification de l'utilisateur pour protéger les données de sorte que cette protection des données avec EFS n'est pas plus efficace que le mot de passe de l'utilisateur. Avec Windows Vista™, vous pouvez maintenant stocker des certificats de cryptage EFS sur des cartes à puce, ce qui modifie ce paradigme et augmente considérablement la sécurité relative des données protégées par EFS.

Quelle doit être la longueur d'un mot de passe pour qu'il soit résistant à ces attaques ? Étant donné les possibilités matérielles d'aujourd'hui et les algorithmes d'attaque de mots de passe modernes, il est recommandé d'utiliser un mot de passe de 11 caractères ou plus (ou, plus exactement, une phrase clé). Une phrase clé de 11 caractères ou plus est extrêmement résistante aux méthodes les plus avancées d'aujourd'hui, y compris les attaques par hachage précalculé (telles que les Rainbow Tables, consultez le message sur le blog « Why you shouldn't be using passwords of any kind on your Windows networks » (en anglais) répertorié dans l'encadré « Ressources », pour plus d'informations).

PKI ou ne pas PKI ?

On pense souvent à tort qu'une infrastructure PKI est nécessaire pour permettre le fonctionnement du système de fichiers EFS. Il est vrai qu'EFS peut facilement s'intégrer avec à cette infrastructure et tirer parti d'une architecture PKI si votre organisation en a déjà une, mais cela n'est pas indispensable. Ceci dit, la décision d'utiliser ou non une architecture PKI dans votre déploiement EFS influera sur de nombreuses décisions de déploiement futures, il faut donc bien étudier le problème.

L'avantage principal de l'utilisation d'une architecture PKI avec EFS est la possibilité de réaliser un archivage et une récupération des clés. Tandis qu'EFS tout seul permettra aux administrateurs d'exécuter la récupération des données, la récupération automatique des clés est disponible uniquement avec une PKI, et même dans ce cas, seulement en exécutant Windows Server® 2003 Enterprise Edition en tant qu'autorité de certification. La récupération des données est le processus par lequel un utilisateur qui perd l'accès à sa clé de cryptage peut fournir ses données cryptées à un administrateur désigné et connu comme l'agent de récupération de données. Ce dernier peut ensuite décrypter ces données et les renvoyer à l'utilisateur ou les recrypter pour qu'elles soient utilisées avec une nouvelle clé confidentielle. L'agent de récupération travaille en quelque sorte dans l'ombre du processus de cryptage de l'utilisateur car tout ce que l'utilisateur crypte avec sa clé est également crypté avec une copie de la clé de l'agent. Ainsi, lorsque la clé de l'utilisateur est perdue, l'agent peut intervenir, déchiffrer les données, leur appliquer sa clé pour le décryptage (ou le recryptage), puis renvoyer les données à l'utilisateur. L'approche par agent fonctionne bien, mais elle peut être difficile à gérer si l'utilisateur a crypté de grandes quantités de données ou s'il ne dispose pas d'un personnel informatique local pouvant servir d'agents de récupération des données.

La récupération des clés, en revanche, requiert que l'autorité de certification fasse une copie de la clé de cryptage de l'utilisateur pendant le processus de création de la clé et stocke cette copie en toute sécurité dans la base de données de l'autorité de certification. Ensuite, lorsqu'un utilisateur perd l'accès à des fichiers cryptés, l'administrateur de l'autorité de certification n'a plus qu'à accéder à cette base de données pour récupérer la clé de l'utilisateur. À ce stade, l'utilisateur retrouvera un accès immédiat à ses données sans avoir à passer par l'intermédiaire d'un agent de récupération de données. De cette façon, la récupération des clés est souvent plus rapide et plus efficace. Notez, cependant, qu'il est préférable de toujours disposer d'agents de récupération de données, même si vous utilisez la récupération des clés, pour avoir une solution de secours en cas de perte de clés. Ceci permet également aux grandes organisations d'avoir un système de récupération distribué dans lequel les administrateurs informatiques locaux peuvent récupérer des données d'utilisateurs sans avoir à faire appel au groupe d'administrateurs PKI.

Autre avantage de l'utilisation d'une PKI avec EFS : elle peut également faciliter le partage de fichiers cryptés. Rappelez-vous qu'EFS n'est pas uniquement limité aux systèmes portables. Il peut être tout aussi utile dans toute situation où la sécurité physique d'un ordinateur ne peut pas être garantie. Dans ces situations, il peut être nécessaire que plusieurs utilisateurs accèdent aux mêmes données cryptées. Bien que la prise en charge de Windows pour le partage de fichiers cryptés soit quelque peu limitée parce qu'elle permet uniquement le partage de fichiers individuels, et non de répertoires, elle peut s'avérer un outil utile. Pour faciliter le partage de fichiers EFS, l'utilisateur qui partage le fichier doit avoir accès aux clés publiques des utilisateurs avec lesquels il partage (ce qui est plus facile si ces utilisateurs ont un certificat EFS valide publié pour leur compte dans Active Directory®). Bien qu'il soit possible d'exécuter cette publication manuellement, l'utilisation d'une autorité de certification Windows installée dans le mode Enterprise (intégré à Active Directory) automatise entièrement le processus.

Gestion des clés EFS

Si vous avez une PKI basée sur Windows Server 2003 que vous pouvez utiliser, la création de certificats EFS d'utilisateurs est un processus simple. Une autorité de certification Windows Server 2003 est fournie avec un ensemble de modèles de certificats par défaut, notamment un modèle qui s'appelle EFS basique. Toutefois, ce modèle est une modèle de version 1 qui ne prend pas en charge l'archivage des clés. Si, avant de le rendre disponible sur votre autorité de certification, vous souhaitez dupliquer le modèle pour créer un nouveau modèle de version 2 (vous pourriez par exemple l'appeler EFS avec archive des clés, comme illustré à la figure 1). Sur ce nouveau modèle, accédez à l'onglet Traitement de la demande et sélectionnez l'option d'archivage de la clé de cryptage de l'utilisateur. Notez qu'il faudra que l'archivage des clés soit configuré correctement sur l'autorité de certification pour que vous puissiez activer cette option. La section des ressources inclut une excellente description étape par étape du processus. Définissez également ce modèle pour qu'il remplace le modèle EFS basique pour faire en sorte que les clients utilisent cette nouvelle version (voir la figure 2).

Figure 1** EFS avec Archive des clés **(Cliquer sur l'image pour l'agrandir)

Figure 2** Remplacement du modèle EFS basique **(Cliquer sur l'image pour l'agrandir)

Vous devrez ensuite déterminer les autorisations correctes sur le modèle pour accorder un accès aux bons utilisateurs. Étant donné que le composant EFS de Windows demandera automatiquement un certificat lors de la première utilisation d'EFS, vous n'avez généralement pas besoin de permettre aux utilisateurs de s'auto-inscrire au modèle EFS. En fait, je vous déconseille de permettre l'auto-inscription pour les certificats EFS à moins que vous ne soyez sûr que tous les utilisateurs auto-inscrits utiliseront EFS. La figure 3 illustre les paramètres d'auto-inscription EFS. En émettant des certificats à des utilisateurs qui n'utiliseront peut-être jamais EFS, vous augmentez la taille de votre base de données d'autorité de certification inutilement. Bien que la taille de la base de données d'autorité de certification ne soit pas en elle-même limitée, elle risque de devenir plus difficile à gérer (en particulier via Microsoft Management Console ou MMC) car vous augmentez le nombre de certificats émis.

Figure 3** Configuration des autorisations d'utilisateurs EFS **(Cliquer sur l'image pour l'agrandir)

Pour finir, si vous avez besoin de prendre en charge le partage de fichiers cryptés, vous souhaiterez peut-être que l'autorité de certification publie automatiquement le certificat de l'utilisateur dans Active Directory.

Une fois le modèle configuré correctement sur votre autorité de certification, la première fois qu'un utilisateur essaie de crypter un fichier avec EFS, il obtiendra son certificat de votre autorité de certification et votre autorité de certification archivera automatiquement sa clé confidentielle.

Gestion des clés DRA

Le point suivant à envisager si vous disposez d'une PKI est l'utilisation ou non des certificats DRA générés par l'autorité de certification. Pourquoi ne pas utiliser les certificats DRA de votre PKI ? Imaginez un scénario dans lequel vous avez une autorité de certification émettrice avec une période de validité de certificat relativement courte (deux années ou moins). Cette autorité de certification ne pourra pas émettre de certificats avec des durées de validité supérieures à la sienne, ce qui signifie que vos certificats DRA auront une durée de validité de deux ans (au plus). Ceci peut résulter dans un scénario de récupération des données beaucoup plus complexe. Cette hypothèse est illustrée dans le scénario suivant.

1. Un utilisateur crypte un fichier en janvier 2006. Les certificats DRA qui sont attribués à son ordinateur par la stratégie de groupe ont une durée de validité de deux ans (ils expirent en janvier 2008).
2. L'utilisateur continue à crypter de nouveaux fichiers, en utilisant EFS.
3. En janvier 2008, les certificats DRA expirent et l'administrateur fait parvenir de nouveaux certificats par le biais de la stratégie de groupe.
4. Toutes les opérations de cryptage effectuées à partir de ce moment utilisent les nouveaux certificats DRA (y compris les fichiers que cet utilisateur ouvre qui ont été cryptés avec les anciens certificats DRA ; ils utiliseront les nouveaux certificats lorsqu'ils seront enregistrés). Les fichiers auxquels l'utilisateur ne touche pas seront uniquement protégés par les anciens certificats DRA.
5. L'utilisateur endommage accidentellement son profil et a besoin de récupérer des données.
6. L'administrateur informatique doit maintenant avoir deux groupes de certificats DRA : les nouveaux pour les fichiers utilisés depuis l'étape 3 et les anciens pour les fichiers auxquels l'utilisateur n'a pas accédé depuis cette étape.

L'administrateur informatique a la possibilité d'exécuter un script après l'étape 3 pour mettre à jour tous les fichiers avec le nouveau certificat RA (à l'aide de cipher.exe/u), mais cela prendra du temps. De plus, il faut souligner que les paires de clés DRA ne deviennent pas inutiles après leur expiration, même si le composant EFS ne permet plus de nouvelles opérations de cryptage si un certificat DRA expiré est inclus dans sa stratégie de récupération. Les vieux fichiers cryptés avec des paires de clés DRA expirées peuvent, bien sûr, toujours être récupérés. Par conséquent, les paires de clés DRA ne doivent pas être ignorées, même après l'expiration de leur durée de validité. Vous ne savez simplement pas quand vous aurez besoin de les utiliser.

C'est pour ces raisons que je recommande que les environnements ayant des autorités de certification avec des certificats à courte validité emploient des certificats DRA auto-signés avec des durées de validité plus longues. L'utilitaire de chiffrement comprend un commutateur (cipher.exe /r) qui crée automatiquement des paires de clés d'agents de récupération EFS avec une durée de vie de 100 ans (voir la figure 4). Le certificat de cette paire de clés peut ensuite être associé aux objets de stratégie de groupe et utilisé comme un certificat DRA dans l'ensemble de votre organisation. Étant donné que le composant EFS ne vérifie pas la chaîne de confiance des certificats DRA, ces certificats auto-signés fonctionneront sans que vous ayez besoin d'apporter des modifications à la liste des autorités de certification racine reconnues sur vos systèmes. Quelle que soit la durée de vie de l'autorité de certification d'une organisation, je recommande toujours de créer au moins un certificat DRA de longue durée et de l'associer à un GPO au niveau du domaine. Il s'agit de l'option de secours de récupération des données à utiliser en cas d'échec de toutes les autres options. Ceci est tout particulièrement essentiel si vous utilisez des clés DRA créées par l'autorité de certification en l'absence d'une archive des clés de l'autorité de certification. Si un certificat DRA se trouvait compromis, vous pouvez mettre à jour le GPO avec un nouveau certificat et utiliser cipher.exe /u comme expliqué plus haut pour mettre à jour vos fichiers.

Figure 4** Exécution de Ciquer /R **(Cliquer sur l'image pour l'agrandir)

Ressources EFS

Vous pouvez obtenir beaucoup plus d'informations sur les détails d'EFS et les meilleures pratiques en visitant les sites suivants.

• Why you shouldn’t be using passwords of any kind on your Windows networks (en anglais)
• Implementing Key Archival Walkthrough (en anglais)
• Encrypting File System in Windows XP and Windows Server 2003 (en anglais)

Déploiement KRA et DRA

L'archivage des clés permet aux administrateurs de l'autorité de certification de récupérer des clés de cryptage mises en dépôt par l'utilisateur. Il s'agit évidement d'une capacité très sensible et puissante puisqu'elle peut permettre à un administrateur de l'autorité de certification de décrypter toutes les données dans l'organisation qui utilise une clé signée par l'autorité de certification. Par conséquent, l'archivage et la récupération des clés doivent faire l'objet de précautions particulières et seul un petit nombre d'employés de sécurité de confiance devraient y être autorisés. Étant donné la nature sensible de la récupération des clés, si vous souhaitez en faire votre principal mécanisme pour réobtenir l'accès à des données cryptées par EFS, il est important que vous disposiez d'un processus de remontée défini clairement pour que les demandes de récupération soient adressées à votre équipe d'administration de l'autorité de certification. Chaque demande devra alors être approuvée pour que le processus de récupération puisse commencer. Ensuite, une fois la clé récupérée, elle doit être fournie à l'utilisateur à l'aide d'une méthode sécurisée (en d'autres termes, pas par message électronique) puisque la clé récupérée fournit l'accès à tous les données protégées par EFS de l'utilisateur.

Les clés de l'agent de récupération de clé (ou KRA) sont créées et conservées par les administrateurs de l'autorité de certification et ne sont pas publiées par l'intermédiaire de la stratégie de groupe. En fait, le système EFS ne peut pas déterminer si les clés qu'il utilise ont été archivées. Il exécute simplement ses opérations de cryptage normalement. De plus, les clés KRA créées sur l'autorité de certification ne sont pas spécifiques à EFS. Une autorité de certification utilisant l'archivage des clés sera associée à n clés KRA au niveau de l'autorité de certification qui sera utilisée pour protéger toute clé archivée par l'autorité de certification. Ces clés peuvent inclure celles utilisées avec EFS, un courrier électronique sécurisé ou tout autre certificat comportant un cryptage. Les clés KRA doivent être stockées en sécurité par les agents de récupération des clés individuels. Deux agents de récupération de clé individuels au moins doivent être utilisés comme recours en cas de perte d'une clé.

La première fois qu'un administrateur se connecte au contrôleur de domaine dans un domaine créé récemment, une stratégie de récupération par défaut est créée au niveau du domaine à l'aide d'un certificat auto-signé. Une paire de clés est également stockée dans le profil de l'administrateur sur le contrôleur de domaine. Ce certificat DRA aura une durée de vie de trois ans. L'approche recommandée consiste à supprimer ce certificat par défaut pour le remplacer par des certificats auto-signés de plus longue durée ou des certificats émis par votre PKI. Si vous ne supprimez pas ce certificat par défaut auto-signé, EFS cessera de crypter de nouveaux fichiers sur l'ensemble de votre domaine trois ans après sa création. Ceci parce que le certificat aura expiré. EFS empêche le cryptage de nouvelles données lorsqu'un certificat DRA expiré est inclus dans sa stratégie de récupération. Bien qu'il soit possible d'exploiter Windows XP et les systèmes ultérieurs sans aucune stratégie d'agent de récupération en place, ceci est fortement déconseillé. Dans ce cas, si un utilisateur perd l'accès à sa clé de cryptage pour quelque raison que ce soit et que la récupération des clés n'est pas possible, toutes ses données seront irrévocablement perdues.

Comme je l'ai déjà dit, les clés DRA peuvent être auto-signées ou émises par une autorité de certification. Dans la plupart des cas, une approche hybride est recommandée, avec au moins deux clés d'agent de récupération de répertoire auto-signées, de longue durée, utilisées à l'échelle de l'entreprise en tant qu'agent de récupération de dernier recours. Comme les certificats DRA sont déployés à l'aide des objets de stratégie de groupe, ils possèdent les mêmes capacités d'héritage que les autres objets de stratégie de groupe. En d'autres termes, l'algorithme d'accumulation et d'application de GPO local, de site, de domaine, d'unité d'organisation qui contrôle l'application d'autres paramètres GPO s'applique également aux DRA. Ainsi, une organisation peut facilement implémenter une approche à plusieurs niveaux pour les certificats DRA, dans laquelle le groupe informatique central a un accès DRA à chaque partie de l'entreprise, mais où les groupes informatiques locaux gèrent cette capacité pour leurs domaines de responsabilité spécifiques. Ceci est particulièrement précieux dans les grandes organisations géographiquement dispersées puisqu'il n'est plus nécessaire de transférer de grandes quantités de données cryptées via des liaisons WAN pour faciliter la récupération de données. La figure 5 illustre un déploiement DRA typique à plusieurs niveaux.

Figure 5** Déploiement DRA à plusieurs niveaux **

Dans ce cas, un utilisateur de l'unité d'organisation de Baton Rouge aurait six agents de récupération de répertoire pour chaque fichier crypté : deux de ses administrateurs locaux, deux du groupe informatique d'Amérique du Nord et deux du niveau du domaine. Ainsi, si l'utilisateur perdait l'accès à ses données cryptées, il pourrait demander à un agent de récupération de répertoire local, à Baton Rouge, ou au groupe informatique d'Amérique du Nord, de se charger de leur récupération. En dernier recours, si ces quatre agents étaient indisponibles ou perdus, les agents du niveau du domaine pourraient prendre le relais et récupérer tout aussi bien les données. Quel que soit l'agent qui effectue la récupération, le processus sera toujours essentiellement le même. L'utilisateur commencera par mettre les données à la disposition de l'agent. Il est important que l'agent prenne les mesures nécessaires pour s'assurer que la demande est légitime et qu'elle provient bien du véritable propriétaire des données. Cela fait, l'agent charge le certificat DRA, décrypte (et recrypte, de préférence) les données, puis il les renvoie à l'utilisateur final. Certaines organisations choisissent également d'exécuter une récupération locale : l'agent rend visite à l'utilisateur, il charge sa paire de clés DRA dans le profil, puis il décrypte les données et supprime la paire de clés. L'utilisateur a ensuite accès aux données sous forme de texte brut et il peut les recrypter avec une nouvelle clé. Il convient de noter que cette approche est beaucoup moins sûre parce que la paire de clés DRA est copiée (bien que de façon temporaire) sur l'ordinateur local, mais elle peut faire gagner du temps, en particulier si un grand nombre de données doivent être récupérées.

Notez que si la récupération doit être fournie à l'utilisateur par le biais de l'archivage et la récupération des clés, la demande de récupération sera exécutée complètement indépendamment de ce processus. Au lieu d'utiliser un DRA, la demande de récupération de clé de l'utilisateur parviendra aux administrateurs de l'autorité de certification, qui doivent l'approuver, avant d'accéder à l'archive pour récupérer la clé confidentielle de l'utilisateur. Ils mettront ensuite cette clé confidentielle à la disposition de l'utilisateur de façon sécurisée, en la plaçant par exemple sur un site Web sécurisé pour permettre son téléchargement. (Si l'utilisateur se servait d'une carte à puce pour stocker sa clé EFS, disponible avec Windows Vista, cette clé doit également être réémise). L'utilisateur chargera cette clé dans son profil et aura ensuite un accès immédiat à toutes ses données cryptées.

Étant donné que les paires de clés DRA et KRA peuvent être utilisées pour décrypter des données sensibles, il importe qu'elles soient protégés correctement. Les paires de clés DRA et KRA ne doivent pas être stockées dans les profils de bureau normaux des administrateurs (les profils dans lesquels ils effectuent leurs tâches quotidiennes normales). Elles doivent être stockées de manière sécurisée hors ligne sur une disquette, un support optique ou flash conservé dans un endroit physiquement sécurisé. Ensuite, si besoin est, l'agent de récupération peut charger la paire de clés sur un poste de travail de récupération à partir de ce support, exécuter l'opération de récupération, puis supprimer la paire de clés. Dans certaines organisations où la sécurité des informations est particulièrement indispensable, des postes de travail dédiés sont désignés pour la récupération afin d'accroître la sécurité de ces paires de clés, mais ce n'est pas le cas pour toutes les organisations.

La prochaine fois

Maintenant que j'ai examiné les aspects de la gestion des clés, de la récupération des données et d'Active Directory dans la planification EFS, je me concentrerai le mois prochain sur les questions de déploiement côté client dans la 2ème partie de ce sujet. J'aborderai des sujets tels que le contrôle de l'utilisation d'EFS par la stratégie de groupe, le choix des données à crypter, le cryptage automatique des données par les scripts de connexion et les améliorations côté client pour Windows Explorer afin de faciliter encore plus l'utilisation de données protégées par EFS.

John Morello a obtenu une mention très bien à la Louisiana State University et a occupé plusieurs postes chez Microsoft, qu'il a rejoint il y a six ans. En tant que consultant senior, il a conçu des solutions de sécurité pour des entreprises classées dans Fortune 100 ainsi que des clients civils et militaires du Gouvernement. Il est actuellement responsable de programme dans le groupe Windows Server qui se consacre aux technologies de sécurité et d'accès distant.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.