Vigilance sécuritéDéploiement d’EFS : 2ème partie

John Morello

Le déploiement du système de fichiers EFS (Encrypting File System) peut essentiellement être considéré comme composé de deux parties : la portion conceptuelle dorsale, qui porte principalement sur la gestion des certificats et les agents de récupération, et la portion de déploiement d’EFS visible par l’utilisateur. J’ai décrit le mois dernier la portion dorsale et abordé les options de récupération de données et de clés,

ainsi que les options de création de certificats pour les clients. Je me concentrerai principalement ici sur les aspects du déploiement que vos utilisateurs finaux verront, comme les améliorations de l’Explorateur Windows®, le choix des emplacements du système de fichiers à chiffrer et la gestion des options de chiffrement avec la stratégie de groupe.

Déterminer si EFS est déjà utilisé

Une fois que vous avez décidé de déployer EFS, la première étape consiste à déterminer l’état actuel d’utilisation d’EFS dans votre organisation. Souvenez-vous qu’EFS peut être utilisé en mode autonome, dans lequel l’utilisateur final est entièrement responsable de la création et de la sauvegarde de ses clés de chiffrement. Des utilisateurs de votre organisation utilisent peut-être déjà EFS de cette manière et il est donc important de déterminer qui sont ces utilisateurs afin d’assurer une transition facile vers un déploiement plus géré.

La première fois qu’EFS est employé par un utilisateur donné sur son ordinateur, Windows crée l’entrée de registre suivante dans HKEY_CURRENT_USER :

HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash 

Microsoft® Systems Management Server (SMS), les scripts d’ouverture de session d’Active Directory et d’autres outils peuvent être utilisés pour vérifier la présence de cette entrée sur les ordinateurs dans toute l’entreprise. Si cette valeur de registre est présente pour un utilisateur, c’est qu’il a utilisé EFS à un certain moment. Cependant, cette valeur n’indique pas nécessairement que quelqu’un utilise actuellement EFS ou que certaines de ses données sont chiffrées. Ainsi, lorsqu’un ordinateur disposant de cette clé de registre est trouvé, il doit être examiné de plus près pour déterminer si des fichiers sont actuellement chiffrés.

Utilisez cipher.exe avec les commutateurs /U et /N pour lui ordonner d’indiquer l’état de chiffrage des fichiers et des répertoires d’un ordinateur. Par exemple, si vous souhaitez déterminer si certaines données d’un système ont été chiffrées, vous pourriez exécuter la commande suivante :

cipher /U /N

La vérification du Registre et le rapport de cipher peuvent être combinés dans un script commun pour vérifier la présence de la valeur du Registre et, si celle-ci est présente, générer un compte-rendu des fichiers actuellement chiffrés sur l’ordinateur. Une fois ces rapports générés, vous saurez quels sont les utilisateurs qui ont des fichiers chiffrés et quels sont ces fichiers, et serez prêt à les migrer vers une conception à gestion centralisée.

Pour contrôler l’application de la stratégie de groupe pendant le déploiement, il est utile de créer deux groupes de sécurité dans votre domaine pour séparer les ordinateurs sur lesquels EFS est utilisé de ceux pour lesquels ce n’est pas le cas. Par exemple, « SG-ComputersUsingEFS » peut contenir les comptes d’ordinateur des ordinateurs sur lesquels EFS est déjà utilisé, tandis que « SG-ComputersNotUsingEFS » contiendra tous les autres ordinateurs sur lesquels EFS n’est pas actuellement utilisé.

Contrôle de l’utilisation d’EFS avec la stratégie de groupe

Une fois que vous savez qui utilise ou n’utilise pas EFS, l’étape suivante de votre déploiement de client est la désactivation de l’utilisation autonome d’EFS pour tous ceux qui ne l’utilisent pas actuellement. C’est une étape importante du processus de déploiement car il est plus facile d’activer et de configurer convenablement EFS dès la première fois, que de migrer des utilisateurs qui utilisent des certificats auto-signés. Effectuez uniquement cette étape après avoir déterminé les utilisateurs qui utilisent déjà EFS car, en désactivant EFS au travers de la stratégie de groupe, les utilisateurs ne pourront pas accéder aux fichiers actuellement chiffrés. Vous trouverez cette stratégie dans l’Éditeur d’objet de stratégie de groupe sous Compu-ter Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System.

Comme mentionné précédemment, cette valeur devrait uniquement être activée sur les ordinateurs sur lesquels EFS n’est pas actuellement utilisé, pour ne pas interrompre le travail de tout utilisateur utilisant déjà EFS. Ainsi, dans mon exemple, la liste de contrôle d’accès (ACL) sur l’Objet de stratégie de groupe (Group Policy Object, GPO) qui désactive EFS autorise uniquement le groupe « SG-ComputersNotUsingEFS » à appliquer la stratégie de groupe.

Chiffrer ou ne pas chiffrer

Une fois que vous avez déterminé les systèmes utilisant actuellement EFS et désactivé EFS sur tous les autres jusqu’à votre déploiement géré, l’étape suivante consiste à déterminer ce qui sera chiffré dans ce déploiement géré. En fonction de la manière dont vos systèmes clients sont gérés, la difficulté de ce processus peut s’échelonner de simple à très compliquée.

Pour choisir les fichiers à chiffrer, il est tout d’abord important de savoir si vos utilisateurs possèdent les autorisations d’administrateurs sur leurs systèmes. Si vos utilisateurs sont administrateurs locaux, vous êtes seulement capable de les informer et de les encourager à chiffrer les données sensibles, mais vous n’êtes pas vraiment en mesure de prendre le contrôle de façon gérée. C’est pour une raison simple : un administrateur local peut créer des fichiers et des répertoires à tout emplacement du système de fichiers. Ainsi, bien que vous puissiez chiffrer les emplacements standard, tels que Mes Documents, si l’utilisateur crée un nouveau répertoire à un autre emplacement et y enregistre des informations sensibles, il est difficile de s’assurer que ces données sont également protégées. Outre tous les autres avantages de sécurité procurés par le fait que les utilisateurs finaux ne sont pas administrateurs locaux, ceci permet également à EFS d’être beaucoup plus gérable et sécurisé.

L’information essentielle suivante à garder à l’esprit est le fait qu’EFS assure un chiffrage dépendant de l’utilisateur. En d’autres termes, tout ce qui est chiffré par un utilisateur donné peut uniquement être déchiffré par ce même utilisateur et aucun autre, y compris le compte SYSTEM (à l’exception, bien sûr, de l’Agent de récupération de données ou DRA). Ceci signifie que si un exécutable ou une DLL sont chiffrés avec une clé de l’utilisateur et qu’un autre utilisateur principal du système essaie d’y accéder, un message de refus d’accès lui est affiché. Ainsi, ne chiffrez en général pas les fichiers ou répertoires qui incluent du code exécutable auquel plusieurs utilisateurs principaux d’un système peuvent avoir besoin d’accéder. Windows empêchera le chiffrement des fichiers de %SystemRoot% et des fichiers portant l’attribut SYSTEM, mais il n’est pas rare que les fournisseurs de logiciels installent des fichiers binaires dans %ProgramFiles% pour les services qui peuvent être exécutés par le compte SYSTEM. C’est une approche courante pour les fournisseurs de portables, qui l’utilisent pour installer les logiciels de gestion de périphériques et de l’énergie qui s’exécutent en tant que services.

Ces deux faits à l’esprit, quels sont les recommandations pour les cibles de chiffrement EFS ? La réponse se résume à la manière dont les systèmes de vos utilisateurs sont habituellement configurés. Dans un environnement bien géré avec une image de système d’exploitation standardisée, vous pouvez probablement automatiser le processus de chiffrement pour les utilisateurs en fonction des emplacements de stockage de données de l’image déterminés au préalable. Par exemple, si les utilisateurs peuvent uniquement enregistrer des données dans %userprofile%\Mes Documents, vous pouvez avoir uniquement besoin de chiffrer ce répertoire. Remarque : soyez prudent en cas de chiffrement de Mes Documents, si vous utilisez la redirection de dossiers. Si Mes Documents est redirigé vers un serveur, le serveur devra être approuvé pour la délégation et avoir accès au profil de l’utilisateur. Dans ce cas, il est généralement plus facile de chiffrer uniquement la mémoire cache des fichiers hors connexion, ce que nous aborderons plus tard dans cette rubrique.

Dans un environnement moins géré (où les utilisateurs peuvent écrire dans plusieurs emplacements du système de fichiers), il peut être souhaitable d’automatiser le chiffrement de quelques emplacements de stockage courants et d’apprendre ensuite aux utilisateurs à chiffrer par eux-mêmes d’autres emplacements. Quel que soit votre environnement, effectuez toujours le chiffrement au niveau du dossier et non du fichier. En procédant ainsi, vous êtes sûr que tous les fichiers créés dans cet annuaire, y compris les fichiers temporaires, sont toujours chiffrés.

Emplacements de chiffrement recommandés

En règle générale, les emplacements que vous devez chiffrer sont normalement : %userprofile%\Mes documents, %userprofile%\Application Data\Microsoft\Outlook (en supposant que vous utilisez Microsoft Office Outlook® comme client de messagerie) et %userprofile%\Desktop. Le chiffrage de Mes documents protège l’emplacement par défaut des fichiers enregistrés dans Windows XP. La protection du répertoire Outlook permet de s’assurer que les messages électroniques sensibles mis en cache localement sont également chiffrés. C’est particulièrement important pour les utilisateurs d’Outlook 2003 utilisant le mode de mise en cache par défaut. Enfin, le Bureau est souvent utilisé comme répertoire temporaire dans lequel les utilisateurs peuvent placer des documents sur lesquels ils sont en train de travailler ou des présentations qu’ils utilisent fréquemment. Vous pouvez bien sûr avoir modifié l’emplacement par défaut de certains de ces répertoires dans votre organisation, ainsi vos choix de chiffrement EFS doivent refléter les emplacements normalement utilisés dans votre organisation.

Outre ces recommandations générales, vous devez également déterminer si vous disposez d’applications qui enregistrent des informations sensibles à d’autres emplacements. Par exemple, certaines applications enregistrent des données utilisateur dans %ProgramFiles%\AppName au lieu du profil de l’utilisateur. Il est important de déterminer si vous disposez de telles applications sur vos systèmes clients afin que vous puissiez protéger convenablement toutes les données qu’elles utilisent. Dans le cas de figure idéal, l’application peut être configurée pour enregistrer les modifications dans un autre chemin spécifique au profil de l’utilisateur (tel que Mes documents), dans lequel aucune modification additionnelle d’EFS n’est nécessaire. Dans le cas de figure le moins désirable, si l’application nécessite que des données soient enregistrées dans son répertoire Program Files, EFS peut être utilisé pour chiffrer uniquement un sous-répertoire spécifique de Program Files.

Enfin, soyez prudent si vous avez l’intention de chiffrer le répertoire temporaire (%TMP% et %TEMP%). De nombreux programmes d’installation d’applications utilisent ce répertoire pour l’expansion du contenu des packs d’installation et exécutent ensuite des opérations de déplacement des fichiers développés pour les placer dans le chemin correct de %ProgramFiles%. Puisqu’un fichier déplacé sur un même volume conserve ses attributs originaux, le fichier continuera à être chiffré après avoir été placé dans %ProgramFiles%. Si un utilisateur différent de celui qui exécute le programme d’installation tente ensuite d’utiliser ce fichier, l’accès à ce dernier lui sera refusé. Souvent, de tels problèmes ne se manifestent pas sous forme de messages d’erreur d’application indiquant la cause initiale. Pour cette raison, je recommande généralement de chiffrer %TMP% uniquement dans les environnements bien gérés dans lesquels les utilisateurs finaux n’installent pas d’applications par eux-mêmes.

Protection des fichiers hors connexion

Les fichiers hors connexion sont une fonctionnalité de Windows 2000 et des versions ultérieures qui permet aux utilisateurs de faire une copie locale de données enregistrées sur un serveur de fichiers. Les fichiers hors connexion permettent alors à l’utilisateur de travailler sur ces données en étant déconnecté du serveur et de synchroniser par la suite les modifications sur le serveur lorsqu’ils sont connectés. Les fichiers hors connexion ne se composent cependant pas d’un répertoire simple contenant des copies de fichiers du serveur. Il s’agit plutôt d’une base de données partagée par l’ensemble du système et exécutée dans le contexte du compte SYSTEM. Dans Windows XP, cette base de données peut être protégée avec EFS. Réfléchissez à ce que ceci signifie, en tenant compte du fait qu’il a été dit précédemment qu’EFS est fonction de l’utilisateur. Comment EFS, qui est fonction de chaque utilisateur, peut-il chiffrer une base de données utilisée par plusieurs entités de sécurité ?

Lorsqu’un utilisateur exécutant Windows XP choisit l’option de chiffrer les fichiers hors connexion dans l’Explorateur Windows, la routine de chiffrement utilisée est différente de celle utilisée pour les autres opérations de chiffrement pouvant être établies par cet utilisateur. Au lieu d’utiliser la paire de clés personnelles EFS de l’utilisateur pour le processus (ce qui empêcherait SYSTEM d’accéder aux fichiers), le compte SYSTEM génère lui-même une paire de clés à utiliser par EFS et utilise cette paire de clés pour le chiffrement de la mémoire cache côté client. Ceci a une implication critique au niveau de la sécurité, car si quelqu’un peut par la suite faire en sorte que du code s’exécute avec le compte SYSTEM, il peut déchiffrer les données de la mémoire cache. Si un ordinateur portable est volé, il est incroyablement facile pour un attaquant de réinitialiser le mot de passe d’administrateur et d’ouvrir ensuite une session en tant qu’administrateur. Une fois administrateur, il est tout aussi simple de forcer le code à s’exécuter en tant que SYSTEM et d’accéder ensuite à la mémoire cache. Notez que ce comportement a été modifié dans Windows Vista™. Windows Vista utilise maintenant la clé individuelle de l’utilisateur pour chiffrer les fichiers hors connexion spécifiques à l’utilisateur.

Pour être protégé contre ce type d’attaque, l’ordinateur portable peut être configuré pour enregistrer la clé de chiffrement dans la base de données du Gestionnaire de comptes de sécurité (SAM) hors connexion, sous la forme d’une entrée de mot de passe au démarrage (mode 2) ou d’une disquette insérée pendant le processus de démarrage (mode 3). Les deux approches peuvent être peu pratiques puisqu’elles nécessitent une interaction non automatisable avec l’ordinateur pendant le processus de démarrage créant des problèmes potentiels avec la gestion automatisée des systèmes. Cependant, si EFS doit être utilisé sur un ordinateur avec fichiers hors connexion, il est essentiel que l’une de ces options soit utilisée pour la sécurité des données de la mémoire cache. Je recommande généralement d’utiliser le mot de passe au moment du démarrage (voir la figure 1). En effet, un utilisateur dont l’ordinateur portable et sa mallette ont été volés est plus susceptible d’avoir déjà sa disquette dans l’ordinateur portable ou, si ce n’est pas le cas, très certainement dans la mallette de son portable.

Figure 1** Automatisation des opérations EFS **

Activation d’EFS

Une fois que vous avez déterminé ce qui doit être chiffré sur le client, l’étape suivante consiste à exécuter l’opération de chiffrement. Ce processus peut être mené à bien à l’aide d’un script d’ouverture de session ou un autre processus qui exécutera un script sur le client pour appeler cipher.exe afin d’exécuter l’opération de chiffrement. Si votre environnement comporte déjà des utilisateurs autonomes d’EFS, comme indiqué dans l’exemple précédent, je recommande d’effectuer au préalable leur migration.

Pour la migration de ces utilisateurs autonomes, la première étape consiste à fournir aux systèmes clients des certificats gérés, comme indiqué dans la version de février 2007 de cette rubrique (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). Une fois que tous les systèmes ont été inscrits pour obtenir ces certificats gérés, le chiffrement doit être exécuté avec le commutateur /U pour mettre à jour tout fichier existant avec le nouveau chiffrement et les clés de l’agent de récupération. À ce stade, tous les systèmes du groupe SG-ComputersUsingEFS utiliseraient EFS en mode géré, y compris avec des clés émises de façon centralisée (et potentiellement archivées) et des agents de récupération gérés de façon centralisée.

Pour déployer EFS pour les utilisateurs n’utilisant pas actuellement EFS, vous devez tout d’abord supprimer la stratégie de groupe empêchant l’utilisation d’EFS. Une fois ceci effectué et les utilisateurs inscrits pour obtenir des certificats gérés, un script d’ouverture de session peut être exécuté pour chiffrer les chemins de clés décrits précédemment. Voici un exemple simple de script :

cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"

Après avoir activé EFS sur les répertoires désirés, vous devrez peut-être définir deux options supplémentaires pour augmenter la sécurité de votre déploiement d’EFS, toutes deux liées aux données échangées depuis la mémoire vers le disque. Notez que pour chacun de ces scénarios, la quantité de données qui pourrait potentiellement être récupérée par une partie malveillante est limitée à ce qui a été chargé en mémoire ou placé sur disque pendant l’utilisation légitime. En d’autres termes, si un utilisateur dispose sur un ordinateur de données sensibles protégées par EFS et qui n’ont pas été affichées (et par conséquent pas chargées dans la mémoire), ces données ne sont pas mises en danger par ces sources d’attaques.

Le fichier d’échange est utilisé par Windows comme mémoire virtuelle (souvent appelée espace d’échange dans les autres systèmes d’exploitation) et contient des morceaux bruts de données en mémoire écrites en texte clair sur le disque dur. Ceci peut mettre des données sensibles en danger sur un système protégé par EFS car, si un attaquant peut récupérer le fichier d’échange, il peut potentiellement utiliser des outils d’investigation pour extraire des données utilisables de ce fichier. Puisque le fichier d’échange ne peut quant à lui pas être chiffré dans Windows XP (notez toutefois qu’il peut l’être dans Windows Vista), la meilleure option consiste à forcer Windows à le vider lors de l’arrêt du système. Ceci peut être accompli à l’aide de la stratégie de groupe, comme illustré dans la figure 2.

Figure 2** Définition de la stratégie de groupe **(Cliquer sur l'image pour l'agrandir)

L’inconvénient de ce paramètre est l’augmentation significative du temps nécessaire à l’arrêt d’un ordinateur, en particulier ceux disposant d’une grande quantité de mémoire. Par défaut, la taille du fichier d’échange est directement liée à la quantité de mémoire physique de l’ordinateur. En effet, pour vider le fichier d’échange, Windows doit écrire physiquement dans chaque page du disque avant l’arrêt.

Le fichier de mise en veille prolongée de Windows contient une vidange de la mémoire physique de l’ordinateur lorsque le mode de gestion de l’alimentation est défini pour permettre la mise en veille. Lorsque la mise en veille survient, Windows écrit le contenu complet de la mémoire physique sur le disque dans le fichier de mise en veille, permettant ainsi à l’ordinateur d’être restauré dans un état identique lorsque l’utilisateur est prêt à continuer à travailler. Comme le fichier d’échange, le fichier de mise en veille prolongée ne peut pas être chiffré dans Windows XP. Cependant, contrairement au fichier d’échange, le fichier de mise en veille prolongée ne peut pas être directement désactivé avec un objet de stratégie de groupe. Utilisez au lieu de cela un script pour appeler powercfg.exe avec le commutateur /HIBERNATE pour désactiver (ou réactiver) la mise en veille prolongée.

Après avoir terminé les tâches de chiffrement et de configuration initiales, vous devriez envisager de nettoyer l’espace libre des disques pendant le déploiement. Ce processus peut être très long et perturbateur, mais a des avantages nets en terme de sécurité pour les environnements haute sécurité. L’espace libre est la zone d’un disque qui ne contient pas de données actuellement actives sur le système mais qui, en raison du fonctionnement des disques durs, peut contenir des morceaux d’informations sensibles des fichiers précédemment utilisés. En d’autres termes, puisque l’opération de suppression d’un fichier n’écrase en fait pas tous les secteurs qu’un fichier occupe sur un disque (elle supprime seulement le pointeur de la table des fichiers), les données qui ont été supprimées peuvent continuer à exister sur le disque. Dans ce cas, les données peuvent être récupérables par des outils d’investigation qui peuvent lire cet espace libre et reconstruire des fichiers à partir de celui-ci. Pour effacer en toute sécurité ces données résiduelles, exécutez cipher avec le commutateur /W. Ceci force cipher à écraser systématiquement tous les secteurs marqués comme disponibles sur le disque. Tant que toutes les opérations de fichiers futures sur les données sensibles surviennent dans des répertoires protégés par EFS, il ne sera pas nécessaire d’exécuter régulièrement cette commande.

Amélioration de l’Explorateur Windows pour EFS

Par défaut, les options de chiffrement et de déchiffrage des fichiers et des annuaires sont situées au plus profond des menus de propriétés avancées de l’Explorateur Windows. Vous pouvez choisir d’améliorer les activités de l’utilisateur final avec EFS en plaçant « Chiffrer » et « Déchiffrer » sur le menu contextuel de l’Explorateur Windows (que vous activez d’un clic avec le bouton droit). En outre, l’Explorateur Windows peut être configuré pour afficher les fichiers et les répertoires protégés avec EFS à l’aide d’une couleur différente (vert) de celle des autres fichiers. Ceci peut aider les utilisateurs à savoir si un fichier ou un répertoire est chiffré sans avoir à accéder au menu des propriétés avancées. Enfin, vous pouvez vouloir ajouter une option pour définir les utilisateurs ayant accès à un fichier ou à un répertoire. Pour activer ces options, faites les

following changes in the registry via a script calling reg.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]  
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS dans Windows Vista

Le système de fichiers EFS a bénéficié de plusieurs améliorations importantes dans Windows Vista qui le rendent plus facile à déployer et à gérer et améliorent également sa sécurité. L’amélioration principale est la prise en charge complète du stockage des clés EFS sur les cartes à puce. C’est une fonctionnalité particulièrement utile pour les organisations qui utilisent déjà l’ouverture de session par carte à puce, car cette même carte peut être utilisée pour stocker les clés EFS des utilisateurs. Cette prise en charge des cartes à puce s’étend également aux certificats d’agent de récupération, de sorte que les certificats DRA sensibles peuvent également être enregistrés sur les cartes.

Windows Vista prend également en charge le chiffrement d’éléments auparavant impossible ou difficilement mis en œuvre dans Windows XP. Windows Vista peut chiffrer le fichier d’échange, éliminant le besoin de définir l’option d’effacement du fichier d’échange de mémoire virtuelle. La conception complète des fichiers hors connexion a été retravaillée dans Windows Vista. Outre une stabilité et des performances bien meilleures (ainsi qu’une interface généralement plus conviviale), la mise en cache côté client est maintenant fonction de l’utilisateur, ce qui signifie qu’il est possible de chiffrer en toute sécurité la mémoire cache sans recourir à SYSKEY mode 2 ou 3. Ces deux améliorations éliminent les obstacles de déploiement majeurs des environnements actuels basés sur Windows XP.

Enfin, Windows Vista permet aux administrateurs de configurer le chiffrement du dossier Documents directement au travers de la stratégie de groupe, sans avoir à utiliser un script séparé. La figure 3 illustre les nouvelles propriétés EFS disponibles au travers des objets de la stratégie de groupe dans Windows Vista.

Figure 3** Propriétés EFS dans Windows Vista **(Cliquer sur l'image pour l'agrandir)

Conclusion

EFS fournit aux administrateurs Windows une option hautement sécurisée pour la protection des données mobiles. EFS est évolutif, gérable et fournit des mécanismes de récupération de données souples. Dans Windows Vista, EFS dispose d’améliorations supplémentaires pour une gestion et un déploiement plus faciles, ainsi que la prise en charge du stockage des clés à base de carte à puce. Pour les organisations qui souhaitent protéger leurs données, même lorsqu’un ordinateur a été physiquement perdu, EFS fournit une solution puissante qui est déjà intégrée à la plate-forme Windows existante.

Où trouver davantage

Pour plus d’informations sur les sujets abordés dans cette rubrique, voir les ressources suivantes :

• La rubrique de février 2007 de Vigilance sécurité
• Encrypting File System in Windows XP and Windows Server 2003 (en anglais)
• How to Use the SysKey Utility to Secure the Windows Security Accounts Manager Database (en anglais)

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.