 TechNet Magazine June 2007

TechNet Magazine June 2007

Sécurité : Au cœur du contrôle de compte d’utilisateur de Windows Vista

Le contrôle du compte utilisateur, ou UAC, est l’une des nouvelles fonctionnalités les plus mal comprises de Windows Vista. Pourtant, son objectif (permettre l’exécution aux utilisateurs avec des droits d’utilisateur standard) peut résoudre beaucoup de problèmes de sécurité. Découvrez dans le détail les problèmes que l’UAC est conçu pour résoudre, ainsi que la façon dont il fonctionne.

Mark Russinovich Sécurité: Clés de protection des données avec le chiffrement de lecteur BitLocker

BitLocker a deux objectifs très importants : Il offre un chiffrement de données de volume complet et une manière de valider l’intégrité des composants initiaux de démarrage avant le démarrage de Windows Vista. Obtenez un aperçu sur la manière dont BitLocker fonctionne et voyez comment il vous aide à protéger votre organisation.

Byron Hynes Sécurité: Découverte du pare-feu Windows

La mobilité a modifié les menaces informatiques et les techniques pour s’en protéger. Lorsque les portables sortent du périmètre et reviennent sur le réseau, il vous faut de meilleures façons de protéger vos systèmes. Découvrez comment vous pouvez utiliser le pare-feu Windows pour protéger vos ordinateurs (sur Internet et sur votre propre réseau interne).

Steve Riley Sécurité: Les nouvelles ACL améliorent la sécurité dans Windows Vista

Bien que les ACL n’aient pas subi de révision majeure, il existe plusieurs modifications importantes que vous devez connaître pour la gestion des ACL dans un environnement Windows Vista. Découvrez comment 30 ACL ont été modifiées pour améliorer la sécurité, l’impact qu’elles auront sur votre organisation et apprenez à gérer ces modifications dans votre infrastructure.

Jesper Johansson Sécurité: Gestions des restrictions de matériel à l’aide de la Stratégie de groupe

Les clés/disques USB au format de poche et autres périphériques amovibles peuvent faciliter votre vie personnelle mais compliquer votre vie professionnelle. Pour une sécurité améliorée, vous devez disposer d’une méthode pour le contrôle des périphériques matériels que les utilisateurs installent sur leurs systèmes de travail. Vous pouvez maintenant utiliser la Stratégie de groupe pour définir les périphériques qu’ils peuvent ou non utiliser.

Jeremy Moskowitz Sécurité: Quatre technologies de sécurité dont chaque organisation informatique devrait disposer

La plupart des entreprises partagent des problèmes de sécurité semblables. Dans le monde connecté actuel, il existe quatre types généraux d’outils de sécurité dont chaque organisation devrait disposer. Découvrez ces outils et explorez la manière dont les technologies impliquées peuvent fonctionner ensemble à l’avenir pour créer la solution de sécurité idéale.

Matt Clapham and Todd Thompson Sécurité: Un nouvel outil puissant pour la gestion des certificats

Les certificats sont un élément clé de votre infrastructure : si l’un d’eux expire, la productivité peut s’arrêter. Si vous êtes dans un environnement Microsoft PKI, la nouvelle solution Identity Lifecycle Manager Certificate Management (ILM-CM) peut aider à ce que tout continue à bien se passer. Découvrez comment cet outil peut vous aider à améliorer les processus d’authentification et à réduire les coûts de gestion des certificats.

Kevin Dallmann De la part de l’éditeur: Problèmes de sécurité

Joshua Trupin Boîte à outils: Nouveaux produits pour les professionnels de l’informatique

Greg Steen Forum aux questions sur SQL: Installations 64 bits, allocation de mémoire de cluster et plus encore

Edited by Nancy Michell Coup de projecteur sur les utilitaires: PowerToys d’élévation de script pour Windows Vista

Tandis que le contrôle de compte utilisateur offre une amélioration importante dans le domaine de la sécurité, la possibilité d’élever les autorisations est essentielle pour accomplir certaines tâches administratives et fonctions. Voici certains des PowerToys d’élévation qui rendent l’élévation plus flexible et plus puissante.

Michael Murgolo Le petit câbleur: Le protocole SSTL (Secure Socket Tunneling Protocol)

Les protocoles VPN dans Windows XP et Windows Server 2003 ne fonctionnent pas pour certaines configurations. Comprenez les divers problèmes et découvrez comment Windows Server « Longhorn » et Windows Vista avec Service Pack 1 utiliseront le protocole SSTP (Secure Socket Tunneling Protocol) pour les résoudre.

Joseph Davies Windows PowerShell: Utilisation d’Active Directory

Windows PowerShell ne fournit pas de cmdlet Get-ADSIObject, mais cela ne l’empêche pas de proposer une base solide pour la prise en charge d’ADSI. Découvrez les adaptateurs de type et apprenez à utiliser Windows PowerShell pour travailler avec les objets d’annuaire.

Don Jones Hé, vous le scripteur !: Scripts concernant le soulignement ondulé rouge

Vous recherchez une manière plus facile d’ajouter des termes au dictionnaire de Microsoft Word que de le faire manuellement, un mot à la fois ? Qui ne serait pas tenté ? Ce mois, les scripteurs vous indiquent comment créer des dictionnaires personnalisés dans Microsoft Word, et comment configurer Word par programmation afin qu’il utilise ces dictionnaires.

The Microsoft Scripting Guys Histoires de Bureau: Comment ne pas perdre vos données

C’est incroyable le nombre de fois où des données importantes sont perdues. Mais la réalité est que les informations ne sont perdues que parce qu’elles ne sont pas protégées. Découvrez les mesures importantes que vous pouvez et devez prendre pour sécuriser les données de votre organisation.

Wes Miller Sur le terrain: Parlez à vos développeurs

Il est plus simple que vous le pensez de faire en sorte que les développeurs génèrent des applications plus faciles à gérer. Tout commence par la communication. Les développeurs ne voient pas les logiciels de la même façon que les administrateurs. Mais en discutant avec les développeurs, les administrateurs peuvent expliquer ce qui est important à leurs yeux et les développeurs peuvent ainsi concevoir des codes en connaissance de cause.

David Aiken La vie secrète de Windows: Ce que les nouveaux utilisateurs voient dans le menu Démarrer

Imaginez acheter un nouvel ordinateur, activer Windows, cliquer sur le bouton Démarrer et voir un menu vierge. La raison pour laquelle le menu Démarrer contient des applications dans l’emplacement le plus fréquemment utilisé avant d’avoir utilisé quoi que ce soit est la suivante : offrir une bonne expérience prête à l’emploi. Découvrez comment ces applications sont choisies.

Raymond Chen Lettres: Réponses à vos questions


 S&#233;curit&#233; : Au cœur du contr&#244;le de compte d’utilisateur de Windows&#160;Vista
Sécurité Mark Russinovich

Au cœur du contrôle de compte d’utilisateur de Windows Vista
Vue d'ensemble:
  • Exécution en tant qu’utilisateur standard
  • Virtualisation de fichiers et registres
  • Élévation de l’état de compte

Le contrôle du compte utilisateur (UAC) est une fonctionnalité souvent mal comprise de Windows Vista. Dans ma série de trois articles dans TechNet Magazine sur les modifications de noyau de Windows Vista, disponible en ligne à l’adresse technetmagazine.com, je n’ai pas couvert l’UAC parce que j’estime qu’il mérite son propre article.
Dans cet article, je vais aborder les problèmes que l’UAC résout et je vais décrire l’architecture et l’implémentation de la technologie de ses composants. Ces technologies incluent la refactorisation d’opérations qui nécessitaient auparavant des droits administratifs, la virtualisation légère pour aider l’exécution correcte de programmes sans droits administratifs, la capacité pour les programmes de demander explicitement des droits administratifs et l’isolation de processus administratifs des processus non administratifs s’exécutant sur le même bureau des utilisateurs.

L’objectif de l’UAC
L’UAC est conçu pour permettre l’exécution aux utilisateurs avec des droits d’utilisateur standard, par opposition aux droits administratifs. Les droits administratifs permettent aux utilisateurs de pouvoir lire et modifier n’importe quelle partie du système d’exploitation, y compris le code et les données d’autres utilisateurs, et même Windows® lui-même. Sans les droits administratifs, les utilisateurs ne peuvent pas modifier de paramètres système (que ce soit accidentellement ou intentionnellement), les logiciels malveillants ne peuvent pas changer les paramètres de sécurité du système ou désactiver l’antivirus et les utilisateurs ne peuvent pas compromettre les informations sensibles d’autres utilisateurs sur les ordinateurs partagés. L’exécution avec les droits d’utilisateur standard peut donc réduire les appels urgents passés au support technique dans les environnements d’entreprise, réduire l’impact des logiciels malveillants, permettre aux ordinateurs domestiques de fonctionner de façon plus fluide et protéger les données sensibles sur les ordinateurs partagés.
L’UAC devait s’attaquer à plusieurs problèmes pour faciliter l’exécution avec un compte d’utilisateur standard. Tout d’abord, avant Windows Vista™, le modèle d’utilisation de Windows était basé sur des droits administratifs supposés. Les développeurs de logiciels supposaient que leurs programmes pourraient accéder et modifier n’importe quel fichier, clé de registre ou paramètre du système d’exploitation. Même lorsque Windows NT® a introduit de la sécurité et des accès différenciés entre les comptes d’utilisateur standard et administratif, les utilisateurs étaient guidés dans un processus d’installation qui les encourageaient à utiliser un compte administrateur intégré ou l’un des comptes qui étaient membre du groupe Administrateurs.
Le deuxième problème que l’UAC devait résoudre était que les utilisateurs ont parfois besoin des droits administratifs pour exécuter des opérations comme l’installation d’un logiciel, la modification de l’heure du système et l’ouverture de ports dans le pare-feu.
La solution d’UAC à ces problèmes s’appuie sur trois axes : exécuter la plupart des applications avec des droits d’utilisateur standard, éviter le besoin systématique des droits d’administrateur et encourager les développeurs de logiciels à créer des applications qui s’exécutent avec les droits d’utilisateur standard. Pour ce faire, l’UAC permet une réduction de la fréquence de demande des droits administratifs et l’exécution d’applications d’héritage avec les droits d’utilisateur standard. Il facilite également l’accès aux droits administratifs par les utilisateurs standard lorsqu’ils en ont besoin, et permet même l’exécution d’utilisateurs avec privilèges d’administrateur comme s’ils étaient des utilisateurs standard.

Exécution en tant qu’utilisateur standard
Un audit complet de toutes les opérations administratives pendant le développement de Windows Vista a permis d’identifier beaucoup d’opérations qui pouvaient être activées pour les utilisateurs standard sans compromettre la sécurité du système. Par exemple, même les sociétés commerciales qui ont adopté des comptes utilisateurs standard pour leurs systèmes de bureau Windows XP étaient incapables de supprimer leurs utilisateurs itinérants du groupe Administrateurs parce que Windows XP ne différencie pas la modification du fuseau horaire de la modification de l’heure du système. L’utilisateur d’un ordinateur portable qui veut configurer le fuseau horaire pour que ses rendez-vous s’affichent correctement dans son calendrier lorsqu’il voyage à l’étranger doit avoir le privilège « Modifier l’heure du système » (appelé SeSystemTimePrivilege en interne), qui, par défaut, est seulement accordé aux administrateurs.
L’heure est habituellement utilisée dans les protocoles de sécurité comme Kerberos, mais le fuseau horaire affecte seulement la façon dont l’heure est affichée, donc Windows Vista ajoute un nouveau privilège, « Changer le fuseau horaire » (SeTimeZonePrivilege), et l’attribue au groupe Utilisateurs, comme indiqué à la figure 1. Cela permet aux sociétés commerciales de consentir l’exécution de leurs utilisateurs d’ordinateurs portables sous les comptes d’utilisateurs standard.
Figure 1 Le privilège « Changer le fuseau horaire »
Figure 1 Le privilège « Changer le fuseau horaire »
Windows Vista permet également aux utilisateurs standard de configurer les paramètres de WEP lorsqu’ils se connectent à des réseaux sans fil, de créer des connexions VPN, de modifier les paramètres de gestion de l’alimentation et d’installer des mises à jour Windows critiques. De plus, il introduit des paramètres de Stratégie de groupe qui autorisent les utilisateurs standard à installer une imprimante et d’autres pilotes de périphérique approuvés par les administrateurs informatiques, et à installer des contrôles ActiveX® à partir de sites approuvés par l’administrateur.
Qu’en est-il des applications consommateur et métier qui ne s’exécutent pas correctement dans les comptes d’utilisateur standard ? Si le besoin de droits administratifs est légitime pour certains logiciels, un grand nombre de programmes enregistrent inutilement des données utilisateur dans les emplacements système globaux. Microsoft recommande que les programmes d’installation d’application globaux qui comptent s’exécuter avec les droits administratifs créent un répertoire sous le répertoire %ProgramFiles% pour stocker les fichiers de l’application exécutables et les données auxiliaires et créer une clé sous HKEY_LOCAL_MACHINE\Software pour leurs paramètres d’application. Lorsqu’une application s’exécute, elle peut le faire dans différents comptes utilisateur et devrait donc enregistrer les données spécifiques à l’utilisateur dans un répertoire %AppData% propre à chaque utilisateur et enregistrer des paramètres propres à chaque utilisateur dans le profil d’annuaire de l’utilisateur sous HKEY_CURRENT_USER\ Software. Les comptes utilisateur standard n’ont pas de droits d’écriture dans le répertoire %ProgramFiles% ou dans HKEY_LOCAL_MACHINE\Software, mais puisque la plupart des systèmes de Windows sont à utilisateur unique et que la majorité des utilisateurs étaient administrateurs jusqu’à Windows Vista, les applications qui enregistrent de façon inexacte des données utilisateur et des paramètres à ces emplacements fonctionnement quand même.
Windows Vista permet à ces applications d’héritage de s’exécuter dans les comptes d’utilisateur standard à l’aide de la virtualisation du système de fichiers et de l’espace de noms du registre. Lorsqu’une application modifie un emplacement de système global dans le système de fichiers ou dans le registre, et que cette opération échoue parce que l’accès lui est refusé, Windows redirige l’opération vers une zone propre à l’utilisateur. Lorsque l’application lit à partir d’un emplacement système global, Windows cherche d’abord des données dans la zone propre à l’utilisateur et, si aucune donnée n’est présente, permet la tentative de lecture à partir de l’emplacement global.
Pour cette virtualisation, Windows Vista traite un processus comme un héritage s’il fait 32 bits (et non 64 bits), s’il ne s’exécute pas avec les droits administratifs, et s’il n’a pas un fichier de manifeste indiquant qu’il a été écrit pour Windows Vista. Toutes les opérations qui ne proviennent pas d’un processus classifié comme héritage selon cette définition, y compris les accès de partage de fichier de réseau, ne sont pas virtualisées. Un état de virtualisation du processus est enregistré comme un indicateur dans son jeton, qui est la structure de données du noyau qui traque le contexte de sécurité d’un processus, y compris son compte utilisateur, ses appartenances au groupe et ses privilèges.
Vous pouvez voir l’état de virtualisation d’un processus en ajoutant la colonne Virtualisation à la page Processus du Gestionnaire des tâches. La figure 2 indique que pour la plupart des composants de Windows Vista, y compris le Gestionnaire de fenêtres du Bureau (Dwm.exe), le Sous-système d’exécution client-serveur (Csrss.exe) et l’Explorateur, soit la virtualisation est désactivée parce qu’ils ont un manifeste Windows Vista, soit ils s’exécutent avec les droits administratifs et n’autorisent donc pas la virtualisation. La virtualisation est activée sur Internet Explorer® (iexplore.exe) parce qu’il peut héberger de multiples contrôles et scripts ActiveX, et doit supposer qu’ils n’ont pas été écrits pour fonctionner correctement avec les droits d’utilisateur standard.
Figure 2 Le Gestionnaire des tâches affiche l’état de la virtualisation
Figure 2 Le Gestionnaire des tâches affiche l’état de la virtualisation
Les emplacements de système de fichiers qui sont virtualisés pour les processus d’héritage sont %ProgramFiles%, %ProgramData% et %SystemRoot%, à l’exclusion de certains sous-répertoires spécifiques. Cependant, tous les fichiers possédant une extension exécutable, y compris .exe, .bat, .scr, .vbs et autres, sont exclus de la virtualisation. Cela signifie que les programmes qui se mettent à jour à partir d’un compte utilisateur standard échouent au lieu de créer des versions privées de leurs exécutables qui ne sont pas visibles par un administrateur exécutant un programme de mise à niveau global. Pour ajouter des extensions supplémentaires à la liste d’exceptions, entrez-les dans la clé de registre suivante et redémarrez :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Utilisez un type de multi-chaîne pour délimiter des extensions multiples, sans faire commencer le nom de l’extension par un point.
Les modifications apportées aux annuaires virtualisés par les processus d’héritage redirigent vers le répertoire racine de l’utilisateur virtuel, %LocalAppData%\VirtualStore. Par exemple, si un processus virtualisé qui s’exécute sur mon système crée C:\Windows\Application.ini, le fichier qu’il crée est en fait C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. Le composant Local du chemin souligne le fait que les fichiers virtualisés n’errent pas avec le reste du profil lorsque le compte possède un profil errant.
Si vous naviguez dans l’Explorateur dans un répertoire contenant des fichiers virtualisés, l’Explorateur affiche un bouton nommé Fichiers de compatibilité dans sa barre d’outils, comme illustré à la figure 3. Cliquez sur le bouton pour naviguer vers le sous-répertoire de VirtualStore correspondant pour afficher les fichiers virtualisés.
Figure 3 Le bouton de Fichiers de compatibilité indique des fichiers virtualisés qui se trouvent à proximité
Figure 3 Le bouton de Fichiers de compatibilité indique des fichiers virtualisés qui se trouvent à proximité
La figure 4 illustre comment le Pilote de filtre de virtualisation de fichier de l’UAC (%SystemRoot%\System32\Drivers\Luafv.sys) implémente la virtualisation du système de fichiers. Puisque c’est un pilote de filtre de système de fichiers, il voit toutes les opérations de système de fichiers, mais il implémente seulement la fonctionnalité pour les opérations des processus d’héritage. Vous pouvez voir qu’il modifie le chemin d’accès du fichier cible pour un processus d’héritage qui crée un fichier dans un emplacement système global, mais il ne le fait pas pour un processus exécutant une application Windows Vista avec les droits d’utilisateur standard. Le processus d’héritage croit que l’opération réussit lorsqu’il a réellement créé le fichier dans un emplacement entièrement accessible par l’utilisateur, mais les autorisations par défaut dans le répertoire \Windows refusent l’accès à l’application écrite pour Windows Vista.
Figure 4 Virtualisation de système de fichiers
Figure 4 Virtualisation de système de fichiers
La virtualisation de registre est implémentée de façon légèrement différente de la virtualisation de système de fichiers. Les clés de registre virtualisées incluent la plupart de la branche HKEY_LOCAL_MACHINE\Software, mais il existe de nombreuses exceptions, comme ce qui suit :
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Seules les clés qui sont habituellement modifiées par les applications d’héritage, mais sans provoquer de problèmes de compatibilité ou d’interopérabilité, sont virtualisées. Windows redirige les modifications de clés virtualisées par une application d’héritage vers un registre de racine virtuelle de l’utilisateur sur HKEY_CURRENT_USER\Software\Classes\VirtualStore. La clé est située dans la ruche des Classes de l’utilisateur, %LocalAppData%\Microsoft\Windows\UsrClass.dat, qui, comme toutes les autres données de fichier virtualisées, n’erre pas avec un profil utilisateur errant.
Au lieu de maintenir une liste fixe d’emplacements virtualisés comme Windows le fait pour le système de fichiers, l’état de virtualisation d’une clé est enregistré comme un indicateur, REG_KEY_DONT_VIRTUALIZE, dans la clé elle-même. L’utilitaire Reg.exe peut afficher l’indicateur, ainsi que deux autres indicateurs liés à la virtualisation, REG_KEY_DONT_SILENT_FAIL et REG_KEY_RECURSE_FLAG, comme illustré à la figure 5. Lorsque REG_KEY_DONT_SILENT_FAIL est défini et que la clé n’est pas virtualisée (REG_KEY_DONT_ VIRTUALIZE est défini), une application d’héritage à qui serait refusé l’accès pour exécuter une opération sur la clé se voit à la place attribuer l’accès à la clé que possède l’utilisateur, au lieu de l’accès que demande l’application. REG_KEY_RECURSE_FLAG indique si de nouvelles sous-clés héritent des indicateurs de virtualisation du parent, au lieu des seuls indicateurs par défaut.
Figure 5 L’utilitaire Reg affiche les indicateurs de virtualisation
Figure 5 L’utilitaire Reg affiche les indicateurs de virtualisation
La figure 6 illustre comment la virtualisation de registre est implémentée par le Gestionnaire de configuration, qui gère le registre dans le noyau du système d’exploitation, Ntoskrnl.exe. Comme avec la virtualisation de système de fichiers, un processus d’héritage créant une sous-clé d’une clé virtualisée est redirigé vers le registre racine virtuel de l’utilisateur, mais un processus Windows Vista se voit refuser l’accès par les autorisations par défaut.
En plus de la virtualisation du système de fichiers et de registre, certaines applications nécessitent une aide supplémentaire pour s’exécuter correctement avec les droits d’utilisateur standard. Par exemple, une application qui teste le compte dans lequel elle s’exécute pour l’appartenance dans le groupe Administrateurs peut fonctionner autrement, mais elle ne s’exécutera pas si elle n’est pas dans ce groupe. Windows Vista définit donc plusieurs shims de compatibilité des applications pour que de telles applications fonctionnent de toute façon. Les shims le plus habituellement appliqués aux applications d’héritages pour l’opération avec les droits standard sont illustrés à la figure 7. Les professionnels de l’informatique peuvent utiliser des outils comme l’ACT (Application Compatibility Toolkit, disponible à l’adresse technet.microsoft.com/windowsvista/aa905066.aspx) et son utilitaire SUA (Standard User Analyzer) ou le LUA Buglight d’Aaron Margosis pour identifier les exigences de shim pour leurs applications métier. Ils attribuent des shims à une application utilisant l’outil Compatibility Administrator (qui fait également partie de l’ACT), puis déploient la base de données de compatibilité résultante (fichier .sdb) vers leurs ordinateurs portables à l’aide de la Stratégie de groupe. Notez que, au besoin, la virtualisation peut être complètement désactivée pour un système utilisant un paramètre de stratégie de sécurité locale.
Figure 7 Shim courants d’utilisateur (Close Figure 7)

Shim | Objectif
ElevateCreateProcess | Modifie CreateProcess pour contrôler les erreurs ERROR_ELEVATION_REQUIRED en appelant le Service Informations d’application pour lancer une invite de commande pour l’élévation.
ForceAdminAccess | Usurpe des requêtes d’appartenance au groupe d’administrateur.
VirtualizeDeleteFile | Usurpe la suppression réussie de fichiers et d’annuaires globaux.
LocalMappedObject | Force les objets de section globale dans l’espace de noms de l’utilisateur.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Redirige l’inscription globale d’objets COM à un emplacement propre à chaque utilisateur.
Les effets de la virtualisation
Vous pouvez modifier l’état de la virtualisation d’un processus en sélectionnant Virtualisation dans le menu contextuel qui apparaît lorsque vous cliquez dessus avec le bouton droit dans le Gestionnaire des tâches. La figure A illustre le comportement d’une invite de commande lorsque son état de virtualisation est modifié. Elle démarre avec la virtualisation désactivée parce qu’elle possède un manifeste Windows Vista. Puisqu’elle s’exécute avec les droits d’utilisateur standard, elle est incapable de créer un fichier dans le répertoire \Windows, mais elle est ensuite virtualisée avec le Gestionnaire des tâches, puis semble créer le fichier avec succès. Lorsque sa virtualisation retourne à son état désactivé, elle ne peut pas trouver le fichier, qui est en fait dans le magasin virtuel de l’utilisateur.
Figure A Une modification d’état de la virtualisation
Figure A Une modification d’état de la virtualisation

Le Mode Approbation administrateur
Même si les utilisateurs exécutent seulement des programmes qui sont compatibles avec les droits d’utilisateur standard, certaines opérations nécessitent toujours des droits administratifs. La grande majorité des installations de logiciel nécessite des droits administratifs pour créer des annuaires et des clés de registre dans les emplacements système globaux, ou pour installer des services ou des pilotes de périphérique. La modification du système global de Windows et des paramètres d’application nécessite également des droits administratifs, à l’image de la fonction de contrôle parental de Windows Vista. Il serait possible d’exécuter la plupart de ces opérations en basculant vers un compte administratif dédié, mais cette opération contraignante pourrait inviter les utilisateurs à préférer rester dans le compte administrateur pour exécuter leurs tâches quotidiennes.
Windows Vista inclut donc une fonctionnalité « Exécuter en tant que » améliorée pour que les utilisateurs standard puissent lancer facilement des processus avec des droits administratifs. Cette fonctionnalité a nécessité de fournir aux applications une façon, que je vais décrire, d’identifier les opérations pour lesquelles elles peuvent obtenir des droits administratifs de la part de l’application au besoin.
De plus, pour permettre aux utilisateurs qui agissent comme des administrateurs systèmes de s’exécuter avec les droits d’utilisateur standard, mais sans avoir à saisir les noms d’utilisateur et les mots de passe à chaque fois qu’ils veulent accéder à des droits administratifs, Windows Vista a créé le mode Approbation administrateur (AAM). Cette fonctionnalité crée deux identités pour l’utilisateur lors de l’ouverture de la session : l’une avec les droits d’utilisateur standard et l’autre avec des droits administratifs. Puisque chaque utilisateur sur un système Windows Vista est soit un utilisateur standard, soit un utilisateur agissant la plupart du temps comme un utilisateur standard dans AAM, les développeurs doivent supposer que tous les utilisateurs de Windows sont des utilisateurs standard, ce qui provoquera l’augmentation du nombre de programmes fonctionnant avec les droits d’utilisateur standard, sans virtualisation ni shim.
L’octroi de droits administratifs à un processus s’appelle une élévation. Lorsqu’elle est exécutée par un compte utilisateur standard, on parle d’élévation Par-dessus l’épaule (OTS), parce que cela nécessite la saisie d’informations d’authentification pour un compte qui est membre du groupe de l’administrateur, ce qui est généralement fait par quelqu’un tapant sur le clavier de l’utilisateur qui en a besoin, en se tenant par-dessus son épaule. Une élévation exécutée par un utilisateur AAM est appelée une élévation de Consentement parce que l’utilisateur doit simplement approuver l’attribution de ses droits administratifs.
Windows Vista considère qu’un utilisateur est un administrateur si l’utilisateur est membre de l’un des groupes de type administrateur listé à la figure 8. Beaucoup des groupes listés sont seulement utilisés sur des systèmes joints à un domaine et ne donnent pas directement de droits administratifs locaux aux utilisateurs, mais les autorise à modifier des paramètres au niveau du domaine. Si un utilisateur est membre de n’importe quel de ces groupes, mais pas du véritable groupe d’administrateurs, alors il accède à ses droits administratifs à l’aide des élévations OTS, au lieu des élévations de Consentement.
Figure 8 Groupes administratifs (Close Figure 8)

Administrateurs intégrés
Administrateurs de certificat
Administrateurs de domaine
Administrateurs de l’entreprise
Administrateurs de stratégie
Administrateurs de schéma
Contrôleurs de domaine
Contrôleurs de domaine de Lecture seule de l’entreprise
Contrôleurs de domaine de Lecture seule
Opérateurs de compte
Opérateurs de sauvegarde
Opérateurs cryptographiques
Opérateurs de Configuration réseau
Opérateurs d’impression
Opérateurs de système
Serveurs RAS
Utilisateurs avec pouvoir
Accès Compatible antérieur à Windows 2000
Lorsqu’un utilisateur appartenant à l’un des groupes listés ouvre une session, Windows Vista crée un jeton représentant la version d’utilisateur standard de l’identité administrative de l’utilisateur. Le nouveau jeton est dépouillé de tous les privilèges attribués à l’utilisateur, sauf ceux listés à la figure 9, qui sont les privilèges utilisateur standard par défaut. De plus, tous les groupes de type administrateur sont marqués par l’indicateur USE_FOR_DENY_ONLY dans le nouveau jeton. La figure 10 illustre l’outil Sysinternals Process Explorer (un outil de gestion intraprocessus que vous pouvez télécharger à l’adresse microsoft.com/technet/sysinternals) qui affiche les appartenances au groupe et les privilèges d’un processus s’exécutant avec les droits administratifs sur la gauche, et sans les droits d’administrateur sur la droite. (Pour empêcher son utilisation involontaire, le modèle de sécurité de Windows nécessite qu’un privilège avec l’indicateur désactivé soit activé avant qu’il ne puisse être utilisé).
Figure 9 Privilèges utilisateur standard (Close Figure 9)

Nom convivial | Nom interne
Ne pas faire de vérification transversale | SeChangeNotifyPrivilege
Arrêter le système | SeShutdownPrivilege
Retirer un ordinateur de sa station d’accueil | SeUndockPrivilege
Augmenter un jeu de travail de processus | SeIncreaseWorkingSetPrivilege
Modifier le fuseau horaire | SeTimeZonePrivilege
Figure 10 L’administrateur AAM et les jetons de l’utilisateur standard
Figure 10 L’administrateur AAM et les jetons de l’utilisateur standard
Un groupe avec l’indicateur DENY_ONLY peut uniquement être utilisé pour refuser à un utilisateur l’accès à une ressource, ne jamais l’autoriser, boucher un trou de sécurité qui pourrait être créé si le groupe était supprimé entièrement au lieu de cela. Par exemple, si un fichier avait une liste de contrôle d’accès (ACL) qui a refusé tout accès au groupe Administrateurs, mais qui a accordé un certain accès à un autre groupe auquel l’utilisateur appartient, l’accès sera autorisé à l’utilisateur si le groupe Administrateurs est absent du jeton, ce qui donne plus d’accès à la version standard de l’identité de l’utilisateur qu’à son identité d’administrateur.
Les systèmes autonomes, qui sont généralement des ordinateurs domestiques et des systèmes joints à un domaine, traitent l’accès AAM par les utilisateurs à distance différemment parce que les ordinateurs connectés à un domaine peuvent utiliser des groupes administratifs de domaine dans leurs autorisations de ressource. Lorsqu’un utilisateur accède à un partage de fichier de l’ordinateur autonome, Windows demande l’identité de l’utilisateur standard de l’utilisateur à distance, mais dans les domaines joints à un domaine, Windows honore toutes les appartenances de groupe de domaines de l’utilisateur en demandant l’identité administrative de l’utilisateur.

Accès commode aux droits administratifs
Il existe plusieurs façons pour le système et les applications d’identifier un besoin de droits administratifs. L’une d’elles réside dans l’interface utilisateur de l’Explorateur : il s’agit de l’entrée de menu contextuel et option de raccourci « Exécuter en tant qu’administrateur ». Ces éléments incluent une icône de bouclier colorée qui devrait être placée sur n’importe quel bouton ou élément de menu qui subiront une élévation de droits lorsqu’ils sont sélectionnés. Choisir l’entrée « Exécuter en tant qu’administrateur » peut forcer l’Explorateur à appeler l’API ShellExecute avec le verbe « runas ».
La grande majorité des programmes d’installation nécessitent des droits administratifs, donc le chargeur d’image, qui établit le lancement d’un exécutable, inclut le code de détection de programme d’installation pour identifier les programmes d’installation d’héritage probables. Une partie de la méthode heuristique qu’il utilise est simple, comme la détection si le nom de fichier de l’image ou ses informations de version interne contiennent les mots installation, installer ou mise à jour. Une autre méthode, plus sophistiquée, consiste en une analyse pour les séquences d’octets dans l’exécutable, qui sont communs aux utilitaires de wrapper d’installation de tiers.
Le chargeur d’image appelle également la bibliothèque de compatibilité des applications (appcompat) pour voir si l’exécutable cible nécessite des droits d’administrateur. La bibliothèque regarde dans la base de données de compatibilité des applications pour voir si l’exécutable est associé aux indicateurs de comptabilité RequireAdministrator ou RunAsInvoker.
La façon la plus courante pour un exécutable de demander des droits administratifs est d’inclure une balise requestedElevationLevel dans son fichier de manifeste d’application. Les manifestes sont des fichiers XML qui contiennent des informations supplémentaires sur une image. Ils ont été introduits dans Windows XP comme une façon d’identifier des dépendances sur les assemblys côte à côte de DLL et Microsoft .NET Framework. La présence de l’élément trustInfo dans un manifeste (que vous pouvez voir dans l’extrait de la décharge de chaîne Firewallsettings.exe ci-dessous), indique un exécutable qui a été écrit pour Windows Vista et l’élément requestedElevationLevel imbriqué à l’intérieur. L’attribut de niveau de l’élément peut avoir une valeur parmi trois : asInvoker, highestAvailable et requireAdministrator.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Les exécutables qui n’ont aucun besoin de droits administratifs, comme Notepad.exe, indiquent la valeur asInvoker. Certains exécutables prévoient que les administrateurs voudront toujours l’accès maximal, donc ils utilisent la valeur highestAvailable. Un utilisateur qui exécute un exécutable devra subir une élévation si l’exécution a lieu en AAM, ou s’il est considéré comme un administrateur, selon les règles définies plus tôt et qu’il doit subir une élévation pour accéder à ses droits administratifs. Regedit.exe, Mmc.exe et Eventvwr.exe sont des exemples d’applications qui utilisent highestAvailable. Enfin, requireAdministrator provoque toujours une requête d’élévation, et il est utilisé par tous les exécutables qui ne fonctionnent pas sans les droits administratifs.
Les applications d’accessibilité spécifient « true » pour l’attribut uiAccess, afin de conduire les entrées de fenêtre des processus élevés, et ils doivent être également signés et situés dans l’un des emplacements sécurisés, comme %Systemroot% et % ProgramFiles % pour obtenir ce pouvoir.
Pour déterminer les valeurs spécifiées par un exécutable, il existe une méthode simple : afficher son manifeste avec l’utilitaire Sigcheck de Sysinternals comme ceci :
sigcheck –m <executable>
Le fait d’exécuter une image qui demande des droits administratifs peut forcer le Service Informations d’application (également appelé AIS, contenu dans %SystemRoot%\System32\Appinfo.dll), qui s’exécute dans un processus Hôte de Service (%SystemRoot%\System32\Svchost.exe), à lancer Consent.exe (%SystemRoot%\System32\Consent.exe). Consent capture un bitmap de l’écran, lui applique un effet de fondu, bascule vers un bureau qui est uniquement accessible au compte Système local, peint le bitmap comme arrière-plan, puis affiche une boîte de dialogue d’élévation qui contient les informations sur l’exécutable. L’affichage sur un bureau séparé empêche tout logiciel malveillant potentiel présent dans le compte de l’utilisateur de modifier l’apparence de la boîte de dialogue.
Figure 11 Boîtes de dialogues d’élévation OTS
Figure 11 Boîtes de dialogues d’élévation OTS
Si une image est un composant Windows numériquement signé par Microsoft et qu’elle est dans le répertoire système de Windows, alors la boîte de dialogue affiche une rayure bleue à travers son sommet, comme indiqué en haut de la figure 11. La rayure grise (fenêtre du milieu) est pour les images qui sont numériquement signées par quelqu’un d’autre que Microsoft, et la rayure orange (fenêtre du bas) est pour les images non signées. La boîte de dialogue d’élévation affiche l’icône de l’image, sa description et son éditeur pour les images numériquement signées, mais seulement une icône générique, le nom de fichier et « Éditeur non identifié » pour les images non signées. Cela complique la tâche des logiciels malveillants qui tenteraient d’imiter l’apparence d’un logiciel légitime. Le bouton Détails en bas de la boîte de dialogue se développe pour afficher la ligne de commande qui sera passée à l’exécutable s’il est lancé. La boîte de dialogue Consentement de AAM, illustrée à la figure 12, est similaire, mais au lieu d’ouvrir une invite de commandes pour les informations d’authentification d’administrateur, la boîte de dialogue possède les boutons Continuer et Annuler.
Figure 12 La boîte de dialogue d’élévation AAM
Figure 12 La boîte de dialogue d’élévation AAM
Si un utilisateur décline une élévation, Windows renvoie une erreur d’accès refusé au processus qui a initié le lancement. Lorsqu’un utilisateur accepte une élévation, soit en saisissant les informations d’authentification d’administrateur soit en cliquant sur Continuer, AIS appelle CreateProcessAsUser pour lancer le processus avec l’identité administrative appropriée. Bien que AIS soit techniquement le parent du processus élevé, AIS utilise la nouvelle prise en charge dans l’API CreateProcessAsUser qui définit l’ID de processus parent du processus comme celui du processus qui l’a lancé au départ (voir la figure 13). C’est pourquoi les processus élevés n’apparaissent pas comme les enfants du processus d’hébergement de service d’AIS dans les outils (comme Process Explorer) qui affichent les arborescences de processus.
Figure 13 Flux d’élévation
Figure 13 Flux d’élévation
Bien que les boîtes de dialogue d’élévation apparaissent sur un bureau sécurisé séparé, les utilisateurs n’ont pas de façon par défaut de vérifier qu’ils affichent une fenêtre légitime, et non une fenêtre présentée par un logiciel malveillant. Ce n’est pas un problème pour AAM, parce qu’un logiciel malveillant ne peut pas gagner de droits administratifs avec une boîte de dialogue Consentement truquée, mais le logiciel malveillant pourrait attendre une élévation OTS de l’utilisateur standard, l’intercepter, et utiliser un cheval de Troie sous la forme d’une boîte dialogue pour capturer les informations d’authentification d’administrateur. Avec ces informations d’authentification, ils peuvent gagner l’accès au compte de l’administrateur et l’infecter.
Pour cette raison, ces élévations OTS sont fortement découragées dans les environnements d’entreprise. Pour désactiver les élévations OTS (et réduire les appels passés au support technique), exécutez l’Éditeur de Stratégie de sécurité locale (Secpol.msc) et configurez le « Contrôle des comptes utilisateur : comportement de l’invite d’élévation pour les utilisateurs standard » sur « Refuser automatiques les demandes d’élévation de privilèges ».
Les particuliers qui sont soucieux de la sécurité doivent configurer les élévations OTS pour nécessiter une séquence de touches de sécurité (SAS, Secure Attention Sequence) que les logiciels malveillants ne peuvent pas intercepter ou imiter. Configurez le SAS en lançant l’Éditeur de Stratégie de groupe (Gpedit.msc), en naviguant vers la Configuration de l’ordinateur | Modèles d’administration | Composants Windows | Interface utilisateur d’Informations d’authentification, et en activant « Exiger un chemin d’accès approuvé pour une entrée d’informations d’identification ». Après cela, vous devrez taper sur Ctrl+Alt+Suppr pour accéder à la boîte de dialogue d’élévation.

Isolation des processus élevés
Windows Vista dresse une barrière autour des processus élevés pour les protéger contre l’exécution de logiciels malveillants situés sur le même bureau avec les droits d’utilisateur standard. Sans cette barrière, un logiciel malveillant pourrait conduire une application administrative en lui envoyant des entrées de souris synthétisée et de fenêtre à l’aide de messages de fenêtre. Le modèle de sécurité standard de Windows empêche l’exécution de logiciel malveillant dans un processus avec les droits d’utilisateur standard d’altérer un processus élevé s’exécutant comme un utilisateur différent. En revanche, il n’empêche pas l’exécution d’un logiciel malveillant comme la version de droits standard d’un utilisateur avec privilèges d’administrateur d’ouvrir des processus élevés de l’utilisateur, de leur injecter du code et d’y démarrer des threads pour exécuter le code injecté.
La protection de Windows Vista pour les messages de fenêtre est appelée Isolation des privilèges au niveau de l’interface graphique (UIPI). Elle est basée sur le nouveau Mécanisme d’Intégrité de Windows que Windows Vista utilise également comme une barrière autour des processus élevés. Dans ce nouveau modèle de sécurité, tous les processus et les objets possèdent un niveau d’intégrité, et une stratégie d’intégrité d’un objet peut limiter les accès qui seraient autrement accordés à un processus par le modèle de sécurité Contrôle d’accès discrétionnaire (DAC) de Windows.
Les niveaux d’intégrité (IL) sont représentés par les Identificateurs de Sécurité (SID), qui représentent également des utilisateurs et des groupes, où le niveau est codé dans l’Identificateur relatif des SID (RID). La figure 14 illustre le nom d’affichage, les SID et la version hexadécimale du RID des SID pour les quatre IL primaires. Les numéros hexadécimaux révèlent des écarts de 0x1000 entre chaque niveau qui permettent l’utilisation de niveaux intermédiaires par les applications d’accessibilité de l’interface utilisateur, de même que la croissance future.
Figure 14 Niveaux d’intégrité primaire (Close Figure 14)

Nom | SID | RID
Niveau Bas obligatoire | S-1-16-4096 | 0x1000
Niveau Moyen Obligatoire | S-1-16-8192 | 0x2000
Niveau Élevé obligatoire | S-1-16-12288 | 0x3000
Niveau Système obligatoire | S-1-16-16384 | 0x4000
La figure 15 présente la liste des stratégies IL d’objet et des types d’accès qu’ils limitent, qui correspond aux accès génériques définis pour un objet. Par exemple, No-Write-Up empêche un processus à IL faible de gagner l’un des accès représentés par les accès GENERIC_WRITE. La stratégie par défaut pour la plupart des objets, y compris les fichiers et les clés de registre, est No-Write-Up, qui empêche un processus d’obtenir l’accès en écriture aux objets qui possèdent un IL plus élevé que lui, même si la liste de contrôle d’accès de l’objet discrétionnaire (DACL) accorde cet accès à l’utilisateur. Les seuls objets avec une stratégie différente sont les objets de processus et de thread. Leur stratégie, No-Write-Up plus No-Read-Up, empêche un processus s’exécutant sur un IL plus bas d’injecter du code dans un processus qui possède un IL plus élevé, et d’y lire des données (comme les mots de passe).
Figure 15 Stratégies de niveau d’intégrité (Close Figure 15)

Stratégie | Effet
No-Write-Up | Un processus à l’IL inférieur ne peut pas modifier un objet possédant un IL plus élevé
No-Read-Up | Un processus à l’IL inférieur ne peut pas lire un objet possédant un IL plus élevé
No-Execute-Up | Un processus à l’IL inférieur ne peut pas exécuter un objet possédant un IL plus élevé
Windows attribue un IL à chaque processus qu’il place dans le jeton du processus à côté des SID des groupes auxquels appartient l’utilisateur qui exécute le processus. La figure 16 propose des exemples de processus attribués à différents IL. Les processus héritent habituellement de l’IL de leur parent, mais un processus peut également lancer un processus à un IL différent, comme AIS le fait lorsqu’il lance un processus élevé. Vous pouvez afficher les niveaux d’intégrité du processus avec l’utilitaire Whoami incorporé en spécifiant l’option /all, ou avec Sysinternals Process Explorer ou AccessChk. L’Explorateur de processus peut afficher les IL des processus en ajoutant une colonne Niveau d’intégrité.
Figure 16 Essayer l’attribution de niveau intégrité du processus (Close Figure 16)

Niveau d’intégrité | Processus d’exemple
Niveau Bas obligatoire | Internet Explorer en mode protégé et les processus lancés par Internet Explorer en mode protégé
Niveau Moyen Obligatoire | Utilisateur standard et les processus AAM non élevés
Niveau Élevé obligatoire | Processus s’exécutant avec les droits administratifs
Niveau Système obligatoire | Système local, Service Local et processus de Service réseau
Chaque objet sécurisable possède un IL, qu’il soit explicite ou implicite. Les objets de processus, de thread et de jetons possèdent toujours un IL explicitement attribué qui est d’habitude identique à celui enregistré dans le jeton de processus correspondant. La plupart des objets n’a pas d’IL explicite : par défaut, le niveau d’intégrité est Moyen. Les seuls objets créés avec un IL autre que Moyen sont les objets créés par un processus exécutant un IL Bas, qui héritent donc d’un IL Bas. Vous pouvez utiliser l’outil iCacls intégré (%SystemRoot%\System32\iCacls.exe) pour afficher l’IL des fichiers, et l’utilitaire AccessChk de Sysinternals pour afficher l’IL des fichiers, des clés de registre, des services et des processus. La figure 17 révèle que l’IL d’un répertoire qui a besoin d’être accessible par Internet Explorer en mode protégé est Bas.
Figure 17 AccessChk affichant l’IL d’un répertoire Favoris de l’utilisateur
Figure 17 AccessChk affichant l’IL d’un répertoire Favoris de l’utilisateur
Si un objet possède un IL explicite, il est enregistré dans une entrée de contrôle d’accès (ACE) d’un type nouveau pour Windows Vista, le Label ACE, dans la Liste de contrôle d’accès de Système (SACL) du descripteur de sécurité de l’objet (voir la figure 18). La SID dans l’ACE correspond à l’IL de l’objet, et les indicateurs de l’ACE codent la stratégie d’intégrité de l’objet. Avant Windows Vista, les SACL enregistraient seulement les ACE d’audit, qui exigent le privilège « Gérer le journal d’audit et de sécurité » (SeSecurityPrivilege), alors que la lecture d’un Label ACE nécessite seulement l’accès d’autorisations en lecture (READ_CONTROL). Pour qu’un processus modifie l’IL d’un objet, il doit posséder l’accès Propriétaire des modifications (WRITE_OWNER) sur l’objet, ainsi qu’un IL égal ou supérieur à celui de l’objet, et le processus peut uniquement définir un IL égal ou inférieur au sien. Le nouveau privilège « Modifier un nom d’objet » (SeRelabelPrivilege) permet à un processus de modifier l’IL de n’importe quel objet auquel le processus a accès, et même d’élever son IL à un niveau supérieur au sien. Mais par défaut, ce privilège n’est attribué à aucun compte
Figure 18 Le Label ACE d’un objet
Figure 18 Le Label ACE d’un objet
Lorsqu’un processus essaie d’ouvrir un objet, la vérification d’intégrité intervient avant la vérification DACL standard de Windows dans la fonction SeAccessCheck du noyau. Étant données les stratégies d’intégrité par défaut, un processus peut seulement ouvrir un objet avec les droits en écriture si son IL est égal ou supérieur à celui de l’objet, et que le DACL accorde également au processus les accès qu’il désire. Par exemple, un processus d’IL Bas ne peut pas ouvrir un processus d’IL Moyen pour l’accès en écriture, même si le DACL lui accorde l’accès en écriture.
Avec la stratégie d’intégrité par défaut, les processus peuvent ouvrir n’importe quel objet (à l’exception des objets de processus et de thread) pour l’accès en lecture, tant que le DACL de l’objet accorde l’accès en lecture. Cela signifie qu’un processus qui s’exécute à un IL Bas peut ouvrir n’importe quel fichier accessible au compte utilisateur dans lequel il s’exécute. Internet Explorer en mode protégé utilise des IL pour contribuer à empêcher un logiciel malveillant qui pourrait l’infecter de modifier les paramètres du compte utilisateur, mais il ne l’empêche pas de lire les documents de l’utilisateur.
Les objets de processus et de thread sont des exceptions, parce que leur stratégie d’intégrité inclut également No-Read-Up. Cela signifie que l’IL d’un processus doit être égal ou supérieur à celui du processus ou du thread qu’il veut ouvrir et que le DACL doit lui accorder les accès qu’il veut pour que l’ouverture réussisse. En supposant que les DACL autorisent l’accès désiré, la figure 19 illustre les accès dont bénéficient les processus qui s’exécutent aux niveaux Moyen et Bas aux autres processus et objets.
Figure 19 Accès aux objets et processus
Figure 19 Accès aux objets et processus
Le sous-système de Windows Messaging honore également les niveaux d’intégrité pour implémenter UIPI en empêchant un processus d’envoyer quoi que ce soit, mis à part quelques messages de fenêtres informationnels aux fenêtres possédées par un processus ayant un IL plus élevé. Cela empêche les processus d’utilisateur standard d’injecter des données dans les fenêtres de processus élevés ou de briser un processus élevé en lui envoyant des messages mal formés qui déclenchent des saturations de la mémoire tampon interne. Les processus peuvent choisir d’autoriser des messages supplémentaires à passer en appelant l’API ChangeWindowMessageFilter. UIPI bloque également les crochets de fenêtre en les empêchant d’affecter les fenêtres des processus d’IL plus élevés, pour qu’un processus d’utilisateur standard ne puisse pas enregistrer les frappes d’un utilisateur dans l’application administrative, par exemple.

Limites d’élévations et de sécurité
Il est important d’être conscient que ces élévations d’UAC sont des outils de commodité, pas des limites de sécurité. Une limite de sécurité nécessite que cette stratégie de sécurité dicte ce qui peut franchir la limite. Les comptes utilisateur constituent un exemple d’une limite de sécurité dans Windows, parce qu’un utilisateur ne peut pas accéder aux données appartenant à un autre utilisateur sans l’autorisation de ce dernier.
Puisque les élévations ne sont pas des limites de sécurité, il n’y a pas de garantie qu’un logiciel malveillant s’exécutant sur un système avec les droits d’utilisateur standard ne puisse pas compromettre un processus élevé pour gagner des droits administratifs. Par exemple, les boîtes de dialogues d’élévation identifient seulement l’exécutable qui va être élevé : elles ne disent rien sur ce qu’il fera lorsqu’il s’exécute. L’exécutable traitera les arguments de ligne de commande, chargera des DLL, ouvrira des fichiers de données et communiquera avec d’autres processus. Chacune de ces opérations pourrait, dans l’absolu, permettre à un logiciel malveillant de compromettre le processus élevé et de gagner ainsi des droits administratifs.
Jouer dans un bac à sable à IL Bas
Internet Explorer en mode protégé s’exécute à un IL Bas pour créer une clôture autour du logiciel malveillant qui pourrait infecter son processus. Cela empêche le logiciel malveillant de modifier les paramètres du compte de l’utilisateur et de s’installer dans un emplacement à démarrage automatique. Vous pouvez utiliser l’utilitaire PsExec de Sysinternals, avec le commutateur -l, pour lancer des processus arbitraires à IL Bas afin d’explorer le bac à sable. La figure B illustre comment une invite de commande s’exécutant à IL Bas ne peut pas créer de fichier dans le répertoire temporaire de l’utilisateur, qui possède un IL Moyen, mais elle peut le faire dans le répertoire temporaire d’Internet Explorer, qui possède un IL Bas.
Figure BL’invite de commande peut uniquement créer des fichiers dans un IL similaire

Les processus AAM élevés sont particulièrement susceptibles d’être compromis, parce qu’ils s’exécutent dans le même compte utilisateur que les processus de droits standard de l’utilisateur AAM et partagent le profil de l’utilisateur. Beaucoup d’applications lisent des paramètres et chargent des extensions enregistrées dans un profil utilisateur, offrant des opportunités d’élévation aux logiciels malveillants. Par exemple, les boîtes de dialogue des contrôles courants chargent les extensions de Noyau configurées dans une clé de registre de l’utilisateur (sous HKEY_CURRENT_USER), donc le logiciel malveillant pourrait s’y ajouter comme une extension à charger dans le processus élevé qui utilise ces boîtes de dialogue.
Même les processus élevés à partir des comptes utilisateur standard pourraient être compromis à cause de l’état partagé. Tous les processus s’exécutant dans une ouverture de session partagent l’espace de noms interne où Windows enregistre des objets tels que les événements, les mutex, les sémaphores et la mémoire partagée. Si un logiciel malveillant sait qu’un processus élevé essaiera d’ouvrir et de lire un objet spécifique de la mémoire partagée lorsque le processus démarre, il pourrait créer un objet avec un contenu qui déclencherait une saturation de la mémoire tampon pour injecter du code dans le processus élevé. Ce type d’attaque est relativement sophistiqué, mais son éventualité empêche les élévations OTS de constituer une limite de sécurité.
Au final, les élévations ont été créées pour être un outil commode, visant à encourager les utilisateurs qui souhaitent accéder aux droits administratifs pour s’exécuter avec les droits d’utilisateur standard par défaut. Les utilisateurs qui veulent les garanties d’une limite de sécurité peuvent échanger la commodité contre la sécurité, en utilisant un compte utilisateur standard pour les tâches quotidiennes et le Changement rapide d’utilisateur vers un compte administrateur dédié pour exécuter des opérations administratives. D’un autre côté, les utilisateurs qui veulent sacrifier la sécurité à la commodité peuvent désactiver l’UAC sur un système dans la boîte de dialogue Comptes utilisateur dans le Panneau de configuration, mais ils doivent être conscients que cela désactive également le Mode protégé pour Internet Explorer.

Conclusion
L’exécution en tant qu’utilisateur standard présente de nombreux avantages, y compris une aide à la protection des systèmes contre les dommages accidentels ou intentionnels, ainsi que la protection des données et de l’intégrité des utilisateurs partageant un système contre les accès non autorisés. Les diverses modifications de l’UAC et des technologies auront pour résultat un changement majeur dans le modèle d’utilisation de Windows. Avec Windows Vista, les utilisateurs de Windows peuvent pour la première fois exécuter la plupart des tâches quotidiennes et exécuter la plupart des logiciels en utilisant des droits d’utilisateur standard, et beaucoup de sociétés commerciales peuvent maintenant déployer des comptes utilisateur standard.

Mark Russinovich est technicien dans le service responsable des plates-formes et services chez Microsoft. Co-auteur de l’ouvrage intitulé Microsoft Windows Internals (Microsoft Press, 2004), il participe fréquemment à des conférences pour informaticiens et développeurs. Il a récemment rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé la société Sysinternals qui a publié les utilitaires Process Explorer, Filemon et Regmon.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 S&#233;curit&#233;: Cl&#233;s de protection des donn&#233;es avec le chiffrement de lecteur BitLocker
Sécurité Byron Hynes

Clés de protection des données avec le chiffrement de lecteur BitLocker
Vue d'ensemble:
  • Chiffrement de volume complet
  • Clés BitLocker
  • Configuration de BitLocker

Le chiffrement de lecteur BitLocker Windows est certainement l’une des fonctionnalités dont ont parle le plus à propos de Windows Vista. Cependant, la plupart des gens n’ont pas encore eu la possibilité de tester BitLocker pour découvrir par eux-mêmes
ses fonctions et son fonctionnement, et surtout sur un ordinateur ne disposant pas d’un module de plate-forme sécurisée (TPM). Dans cet article, je présente les principes fondamentaux de BitLocker™, pour que vous puissiez évaluer son potentiel et l’inclure dans votre planification de mise à niveau. Je vais commencer par des informations conceptuelles et d’arrière-plan, puis je jetterai un coup d’œil sur la gestion et l’activation de la récupération de données BitLocker et la manière dont BitLocker peut être utile à la fin de la vie d’un ordinateur. Pour mieux comprend la terminologie employée ici, jetez un coup d’œil à la barre latérale « Disques et volumes ».
Disques et volumes
La terminologie autour des disques et des volumes peut souvent être confuse. Voici un glossaire abrégé pour votre référence.
Partition - Une partition est une section d’un disque dur physique. Il s’agit d’une structure logique définie dans une table de partition enregistrée sur le disque.
Volume - Un volume est une structure logique dans Windows formée d’une ou plusieurs partitions et définie par un composant Windows appelé le gestionnaire de volume. À l’exception du gestionnaire de volume et des composants de démarrage, le reste du système d’exploitation et des applications fonctionne avec des volumes, et non des partitions. Dans le cas de systèmes d’exploitation des clients Windows, y compris Windows Vista, les partitions et les volumes ont en général une relation d’un à un. Dans les serveurs, un volume est souvent constitué de plusieurs partitions, telles qu’une configuration RAID typique.
Partition active - Une seule partition à la fois peut être marquée comme la partition active. Il s’agit de la partition qui contient le secteur d’amorçage utilisé pour démarrer le système d’exploitation. La partition active est parfois appelée partition système ou volume système, mais ne confondez pas ces termes avec le volume de système d’exploitation de Windows.
Volume de système d’exploitation Windows - Ce volume contient l’installation Windows, y compris les dossiers System et System32. Avant la sortie de Windows Vista, les termes « partition d’amorçage » étaient utilisés (et le sont encore souvent). Les termes « volume de système d’exploitation Windows » sont plus clairs et évitent toute confusion entre la partition d’amorçage et la partition système. Précédemment, les formateurs disaient parfois aux étudiants de garder à l’esprit que le démarrage a lieu à partir de la partition système et la recherche des fichiers système a lieu sur la partition d’amorçage.
Avant Windows Vista, le volume de système d’exploitation de Windows (également connu comme partition d’amorçage) et la partition active (également connue comme partition système) étaient semblables, parce que les disques durs de la plupart des ordinateurs clients étaient configurés comme une seule grande partition. À la figure A, vous pouvez voir les fonctions attribuées à chaque partition ou volume dans la console Gestion des disques dans Windows Vista.
Figure A Fonctions de partition
Figure A Fonctions de partition

BitLocker accomplit deux tâches complémentaires mais distinctes. Tout d’abord, BitLocker fournit le chiffrement de volume complet pour le volume de système d’exploitation de Windows®. Ensuite, sur les ordinateurs avec un module de plate-forme sécurisée compatible, BitLocker fournit une manière de valider l’intégrité des composants initiaux de démarrage avant d’autoriser Windows Vista™ à démarrer.
Pour utiliser toutes les fonctionnalités de BitLocker, votre ordinateur doit disposer d’une micropuce TPM et d’un BIOS compatibles. Par compatible, on entend une version 1.2 TPM et BIOS qui prend en charge le module de plate-forme sécurisée et la racine statique de mesure d’approbation (SRTM ou Static Root of Trust Measurement) comme défini par Trusted Computing Group (TCG). Cependant, les ordinateurs sans version TPM ni BIOS compatible peuvent toujours utiliser le chiffrement BitLocker.

Chiffrement de volume complet
BitLocker fournit le chiffrement de volume complet pour s’assurer que toutes les données écrites dans le volume de système d’exploitation de Windows sont chiffrées. Il est indispensable de protéger les informations confidentielles enregistrées sur les ordinateurs de votre organisation, et surtout sur les portables et les ordinateurs mobiles.
Tous les jours, des ordinateurs mobiles sont perdus ou volés. Avec la possibilité informatique accrue des portables et un personnel de plus en plus mobile, un seul travailleur peut transporter des centaines de gigaoctets de secrets professionnels concernant votre organisation, des documents confidentiels ou des informations d’identification personnelles des clients. Toute recherche d’informations vous indiquera qu’un nombre trop élevé de ces données se perdent. (L’association Privacy Rights Clearinghouse indique que plus de 104 millions d’enregistrements contenant des informations personnelles ont été perdues ou publiées depuis 2005.)
De nombreuses organisations sont déjà sous le coup d’autorisations légales et commerciales pour protéger une grande quantité d’informations privées ; et même si vous n’y êtes légalement pas obligé, vous devrez probablement créer des intérêts commerciaux pour agir ainsi.

Pourquoi chiffrer le volume complet ?
Si vous êtes un administrateur Windows expérimenté, vous êtes probablement familiarisé avec les options de chiffrement Windows, telles que le système de fichiers EFS (Encrypting File System) et peut-être le chiffrement et la protection fournis par les services de gestion des droits (RMS, Rights Management Services). La grande différence avec BitLocker, c’est qu’une fois activé, il est automatique, transparent et inclut l’intégralité du volume.
Par exemple, avec EFS, vous devez indiquer les fichiers et les dossiers à protéger. Dans Windows Vista, il existe certaines nouvelles options qui rendent EFS plus flexible. EFS et RMS traitent chacun des scénarios que BitLocker ne traite pas. Mais EFS et RMS nécessitent tous deux une configuration d’administrateur significative et ne sont pas conçus pour protéger tout ce qui est enregistré sur le volume.
De même, BitLocker chiffre tout ce qui est écrit dans un volume BitLocker protégé, y compris le système d’exploitation lui-même, le registre, les fichiers de mise en veille prolongée et les fichiers d’échange, les applications et les données utilisées par les applications.
Les trois éléments suivants ne sont pas chiffrés : le secteur d’amorçage, tout mauvais secteur déjà marqué comme illisible et les métadonnées de volume. Les métadonnées de volume consistent en trois copies redondantes des données utilisées pour gérer BitLocker, y compris les informations statistiques sur le volume et les copies protégées de certaines clés de décryptage. Ces articles ne nécessitent pas de chiffrement parce qu’ils ne sont pas uniques, valables ou personnellement identifiables.
Le chiffrement de volume complet protège des attaques hors ligne (le genre d’attaques tentant de contourner le système d’exploitation). Par exemple, une attaque hors ligne courante consiste à voler un ordinateur, supprimer le disque dur et l’installer en tant que deuxième lecteur sur un autre ordinateur (exécutant une copie différente de Windows ou un système d’exploitation différent) pour éviter les autorisations NTFS et les mots de passe utilisateur. Il est impossible de lire un volume BitLocker protégé en utilisant ce genre d’attaque.

Comment BitLocker code les données
BitLocker utilise l’algorithme AES avec les clés 128 bits. Pour une meilleure protection, les clés peuvent être augmentées à 256 bits à l’aide de la Stratégie de groupe ou du fournisseur WMI (Windows Management Instrumentation) de BitLocker.
Chaque secteur dans le volume est individuellement chiffré, avec une partie de la clé de chiffrement étant dérivée du numéro de secteur lui-même. Ceci signifie que deux secteurs contenant des données identiques non chiffrées entraîneront une écriture d’octets chiffrés différents sur le disque, rendant l’accès à la découverte des clés beaucoup plus difficile, en créant et chiffrant des parties connues d’informations.
Avant le chiffrement des données avec AES, BitLocker utilise également un algorithme appelé diffuseur. Sans entrer dans la cryptographie et pour le dire simplement, le diffuseur consiste à s’assurer que les moindres modifications, même les plus insignifiantes, en clair, entraînent une modification de la totalité du secteur crypté chiffré. Il est également beaucoup plus difficile pour un attaquant de découvrir des clés ou des données.
Si vous êtes intéressé par les détails de l’algorithme de chiffrement de BitLocker, lisez l’article de Neil Ferguson intitulé AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista ».

Clés BitLocker
À chaque fois que vous avez affaire au chiffrement, vous devez avoir des connaissances relatives aux clés, et BitLocker n’est pas une exception. BitLocker utilise une architecture de clés élégante, mais un peu complexe.
Les secteurs eux-mêmes sont chiffrés à l’aide d’une clé appelée la clé de chiffrement de volume complet (Full Volume Encryption Key, FVEK). Cependant, la FVEK n’est pas utilisée par les utilisateurs et ils n’y ont pas accès. La FVEK est elle-même chiffrée avec une clé appelée la clé principale de volume (Volume Master Key, VMK). Ce niveau d’abstraction offre certains avantages uniques, mais peut rendre le processus un peu plus difficile à comprendre. La FVEK est gardée secrète parce que, si elle venait à être compromise, il faudrait à nouveau chiffrer tous les secteurs. Étant donné que cette opération prendrait beaucoup de temps, elle est à éviter. À la place, le système travaille avec la VMK.
La FVEK (chiffrée avec la VMK) est enregistrée sur le disque lui-même, comme faisant partie des métadonnées de volume. Bien que la FVEK soit enregistrée localement, elle n’est jamais écrite sur un disque non chiffré.
La VMK est également chiffrée, ou « protégée », mais par un ou plusieurs protecteurs de clés possibles. Le protecteur de clé par défaut est le module de plate-forme sécurisée. L’utilisation d’un module de plate-forme sécurisée est abordée dans la section suivante sur la vérification d’intégrité. Un mot de passe de récupération est également créé comme un protecteur de clé, en cas d’urgence. La récupération sera également abordée ultérieurement.
Vous pouvez associer le module de plate-forme sécurisée à un code confidentiel numérique ou une clé partielle enregistrée sur un lecteur USB pour une sécurité accrue. Chacun d’entre eux se trouve sous la forme d’authentification à deux facteurs. Si votre ordinateur ne dispose pas d’un processeur TPM et BIOS compatibles, BitLocker peut être configuré pour enregistrer la totalité d’un protecteur de clé sur un lecteur USB. Ceci s’appelle une clé de démarrage.
BitLocker peut être désactivé sans décrypter les données. Dans ce cas, la VMK est uniquement protégée par un nouveau protecteur de clé enregistré non chiffré. Notez que cette clé en clair autorise le système à accéder au lecteur comme s’il n’était pas protégé.
Au démarrage, le système recherche un protecteur de clé approprié en interrogeant le module de plate-forme sécurisée, vérifiant les ports USB ou, si nécessaire, en invitant l’utilisateur (ce qui s’appelle la récupération). Le fait de rechercher un protecteur de clé permet à Windows de déchiffrer la VMK, qui déchiffre la FVEK, qui déchiffre les données enregistrées sur le disque. Ce processus est illustré à la figure 1.
Figure 1 Processus de démarrage BitLocker par défaut
Figure 1 Processus de démarrage BitLocker par défaut

Vérification d’intégrité
Étant donné que les composants de la partie initiale du processus de démarrage doivent être disponibles non chiffrés pour que l’ordinateur puisse démarrer, un attaquant pourrait modifier le code dans ces composants initiaux de démarrage (pensez au rootkit) et accéder ensuite à l’ordinateur, même si les données sur le disque ont été chiffrées.
En utilisant ce genre d’attaque, un intrus pourrait accéder aux informations confidentielles, telles que les clés BitLocker ou les mots de passe utilisateur, et tirer parti de ces informations pour contourner les autres protections de sécurité.
La prévention de ce genre d’attaque était l’un des objectifs d’origine du programme et de l’équipe ayant créé BitLocker. D’une certaine façon, le chiffrement est un moyen pour arriver à une fin. Le chiffrement de volume complet autorise BitLocker à protéger l’intégrité du système et empêche Windows de démarrer si les composants initiaux de démarrage ont été modifiés.
Sur les ordinateurs équipés d’un TPM compatible, à chaque démarrage de l’ordinateur, chacun des composants initiaux de démarrage (tels que le BIOS, la partition MBR [Master Boot Record], le secteur d’amorçage et le code de gestionnaire de démarrage) analyse le code à exécuter, calcule une valeur de hachage et enregistre la valeur dans les registres spécifiques du module de plate-forme sécurisée, appelés les registres de configuration de plateforme (PCR, Platform Configuration Registers). Une fois qu’une valeur est enregistrée dans un PCR, elle ne peut pas être remplacée ou effacée sauf si le système redémarre. BitLocker utilise le module de plate-forme sécurisée et les valeurs enregistrées dans les PCR pour protéger la VMK.
Un module de plate-forme sécurisée peut créer une clé associée aux valeurs PCR spécifiques. Lorsque ce type de clé est créé, le module de plate-forme sécurisée chiffre la clé et seul le module de plate-forme sécurisée spécifique peut la déchiffrer. De plus, le module de plate-forme sécurisée déchiffre la clé uniquement si les valeurs PCR actuelles correspondent aux valeurs spécifiées lors de la création de la clé. Ce processus s’appelle le « scellement » de la clé dans module de plate-forme sécurisée.
Par défaut, BitLocker scelle les clés aux mesures de CRTM (Core Root of Trust of Measurement), BIOS et extensions de plateforme, code d’option ROM, code MBR, secteur d’amorçage NTFS et gestionnaire de démarrage. Si l’un de ces éléments est modifié de manière inopinée, BitLocker verrouillera le lecteur et en empêchera l’accès ou le déchiffrement.
Par défaut, BitLocker est configuré pour rechercher et utiliser un module de plate-forme sécurisée. Vous pouvez utiliser la stratégie de groupe ou un paramètre de stratégie local pour autoriser BitLocker à travailler sans module de plate-forme sécurisée et stocker les clés sur un lecteur flash USB externe. Cependant, sans module de plate-forme sécurisée, BitLocker ne peut pas vérifier l’intégrité du système.

Première activation de BitLocker
BitLocker est disponible dans Windows Vista Enterprise et Windows Vista Édition Intégrale. (BitLocker sera également un composant facultatif compris dans la prochaine version de Windows Server®, nom de code « Longhorn ».)
La discussion suivante suppose que vous disposiez d’un ordinateur avec module de plate-forme sécurisée compatible disponible pour effectuer des tests. Si vous souhaitez activer BitLocker sur un ordinateur sans un module de plate-forme sécurisée, suivez les étapes répertoriées dans la barre latérale « Utilisation de BitLocker sans module de plate-forme sécurisée ».
Utilisation de BitLocker sans module de plate-forme sécurisée
BitLocker est configuré par défaut pour utiliser un module de plate-forme sécurisée, et si vous n’en avez pas, Windows prêt à l’emploi ne vous autorisera pas à activer BitLocker. Cependant, la procédure suivante, prise dans le guide pas-à-pas du chiffrement de lecteur BitLocker dans Windows, vous autorisera à utiliser BitLocker sans module de plate-forme sécurisée.
Pour exécuter ces étapes, vous devez être connecté en tant qu’administrateur. Même sans module de plate-forme sécurisée, votre ordinateur doit prendre en charge la lecture d’un lecteur flash USB lors du processus de mise en route. De plus, vous devez disposer d’un lecteur flash USB disponible lorsque vous activez BitLocker et à chaque redémarrage de l’ordinateur.
Pour activer le chiffrement de lecteur BitLocker sur un ordinateur sans module de plate-forme sécurisée compatible :
  1. Cliquez sur Démarrer, saisissez gpedit.msc dans la zone Rechercher puis appuyez sur ENTRÉE.
  2. Si la boîte de dialogue Contrôle de compte d’utilisateur apparaît, vérifiez que l’action proposée correspond à ce que vous avez demandé, puis cliquez sur Continuer.
  3. Dans l’arborescence de la console Éditeur d’objets de stratégie de groupe, cliquez sur Modèles d’administration, puis sur Composants Windows, puis double-cliquez sur Chiffrement de lecteur BitLocker.
  4. Double-cliquez sur le paramètre Configuration du Panneau de configuration : Activez les options de démarrage avancées. La boîte de dialogue Configuration du Panneau de configuration : Activer les options de démarrage avancées apparaît.
  5. Sélectionnez l’option Activé, sélectionnez la case à cocher Autoriser BitLocker sans un module de plate-forme sécurisée compatible, et cliquez sur OK. Vous avez modifié le paramètre de stratégie pour pouvoir utiliser une clé de démarrage à la place d’un module de plate-forme sécurisée.
  6. Fermez l'éditeur d'objets de stratégie de groupe.
  7. Pour appliquer immédiatement la stratégie de groupe, vous pouvez cliquer sur Démarrer, saisir gpupdate.exe /force dans la zone Rechercher, puis appuyer sur la touche ENTRÉE. Attendez la fin du processus.

Une partie importante de l’activation de BitLocker consiste à s’assurer que la configuration de vos volumes est correcte. BitLocker nécessite que la partition active ne soit pas chiffrée pour que le secteur d’amorçage, le gestionnaire de démarrage et le programme de chargement de Windows puissent être lus (ces composants sont protégés par les étapes d’intégrité du système décrites précédemment). Étant donné que les autres composants Windows peuvent nécessiter l’utilisation temporaire de la partition active, Microsoft recommande que la partition active soit au moins 1,5 Go. C’est également une bonne idée de configurer les autorisations NTFS pour que les utilisateurs ne puissent pas écrire accidentellement des données dans ce volume.
Windows lui-même sera installé sur un deuxième volume plus grand, pouvant être chiffré. Si vous installez Windows sur un nouveau système, vous pouvez configurer manuellement les volumes à l’aide des instructions disponibles dans le Guide pas-à-pas de BitLocker Drive Encryption dans Windows Vista.
Vous pouvez utiliser l’outil de préparation de lecteur BitLocker pour faciliter la configuration de votre système pour BitLocker. Cet outil facilite le travail de configuration des lecteurs. Il est disponible en tant que complément de Windows Vista Édition Intégrale ou pour les clients qui déploient Windows Vista Enterprise. Pour des instructions détaillées sur l’outil de préparation du lecteur BitLocker, visitez le site support.microsoft.com/kb/930063.
L’outil de préparation du lecteur BitLocker rétrécit automatiquement le volume (si vous n’en avez qu’un seul), crée la deuxième partition, la rend active, effectue toutes les modifications de configuration nécessaires et déplace les fichiers de démarrage à l’emplacement approprié.
Une fois vos volumes configurés, l’activation de BitLocker est très simple. Dans la section Sécurité du Panneau de configuration, cliquez sur l’icône Chiffrement de lecteur BitLocker. Après vous être familiarisé avec l’invite de consentement du contrôle de compte d’utilisateur, un écran semblable à la figure 2 apparaît.
Figure 2 Activation de BitLocker
Figure 2 Activation de BitLocker
La séquence exacte de la suite des opérations variera selon l’état du processeur du module de plate-forme sécurisée dans votre ordinateur. Si le processeur du module de plate-forme sécurisée n’est pas initialisé, l’Assistant d’initialisation du module de plate-forme sécurisée s’exécutera. Suivez les invites pour initialiser le module de plate-forme sécurisée, qui comprendra le redémarrage de l’ordinateur.
Après l’initialisation du module de plate-forme sécurisée, la page Enregistrer le mot de passe de récupération apparaît, comme l’illustre la figure 3. Pour pouvoir récupérer vos données en cas de défaillance du module de plate-forme sécurisée ou d’un autre problème, vous devez disposer d’un mot de passe de récupération. Cette page vous autorise à enregistrer un mot de passe de récupération sur un lecteur flash USB ou disque local ou réseau, ou à l’imprimer pour le garder en lieu sûr. Vous devez choisir au moins l’une des options suivantes et vous pouvez choisir d’enregistrer plusieurs copies. Une fois le mot de passe de récupération enregistré, le bouton Suivant est activé. Cliquez sur ce bouton.
Figure 3 Enregistrement de votre mot de passe de récupération
Figure 3 Enregistrement de votre mot de passe de récupération
La page de chiffrement du volume de disque sélectionné apparaît et vous pouvez choisir d’exécuter ou non une vérification du système avant le démarrage du chiffrement. La vérification du système nécessite un redémarrage, mais assurez-vous avant que vos ports TPM, BIOS et USB fonctionnent correctement avec BitLocker. Après le redémarrage, si un problème est détecté, vous verrez alors un message d’erreur. Sinon, la barre d’état Chiffrement en cours s’affiche.
C'est tout. Le chiffrement s’effectue en arrière-plan et vous pouvez continuer à utiliser votre ordinateur. Une fois le chiffrement initial terminé, un message apparaît pour vous en informer. Vous pouvez surveiller l’état de terminaison continu du chiffrement du volume de disque en faisant glisser le curseur sur l’icône Chiffrement de lecteur BitLocker dans la barre d’outils en bas de l’écran. Pour plus de détails, vous pouvez vous référer au guide pas à pas mentionné précédemment.
Certains utilisateurs ont été étonnés de voir que BitLocker n’invite pas l’utilisateur ou ne fait aucune autre interruption évidente au démarrage de l’ordinateur. C’est parce, dans sa configuration par défaut, BitLocker compte sur le module de plate-forme sécurisée pour confirmer l’intégrité de système avant de déverrouiller le volume. Cette opération est automatique et transparente pour l’utilisateur.
Vous pouvez configurer BitLocker pour demander la saisie d’un code confidentiel ou la présence d’une clé enregistrée sur un lecteur flash USB au démarrage. Ceci augmente la sécurité et est recommandé dans les situations où la sécurité accrue compense l’inconvénient que représente la saisie de code confidentiel. À mon avis, c’est toujours le cas. (En d’autres termes, mon ordinateur de bureau nécessite un code confidentiel et mon ordinateur portable une clé USB.)

Récupération BitLocker
Lorsque vous traitez le chiffrement (surtout dans un environnement d’entreprise ou commercial), il est essentiel que vous disposiez d’une manière pour qu’un utilisateur autorisé puisse récupérer ses données, même si les méthodes ou les clés d’accès normales ne sont pas disponibles. BitLocker appelle ceci la récupération.
S’il existe un quelconque changement inattendu dans les composants initiaux de démarrage ou si vous perdez une clé de démarrage USB ou qu’un utilisateur oublie son code confidentiel, BitLocker ne pourra pas terminer le processus de démarrage normal. BitLocker laissera le volume verrouillé et Windows ne pourra pas démarrer. À la place, le code BitLocker dans le gestionnaire de démarrage présentera un écran de texte. Si un mot de passe de récupération a été enregistré sur un lecteur flash USB (parfois appelé une clé de récupération), un écran semblable à la figure 4 apparaît.
Figure 4 Recherche d’une clé de récupération
Figure 4 Recherche d’une clé de récupération
Pour que BitLocker puisse lire un lecteur flash USB, il doit être connecté au démarrage. Par conséquent, si vous disposez d’un lecteur flash USB avec un mot de passe de récupération, insérez-le et appuyez sur la touche Échappement. Si vous ne disposez pas d’un lecteur flash USB, appuyez sur la touche Entrée pour voir l’écran illustré à la figure 5. Cet écran apparaîtra également si une clé de récupération n’a jamais été enregistrée sur un lecteur USB.
Figure 5 Saisie d’un mot de passe BitLocker
Figure 5 Saisie d’un mot de passe BitLocker
BitLocker recherche désormais un mot de passe numérique à 48 chiffres qui peut déverrouiller le lecteur. Ce numéro apparaît sur la page si vous avez choisi d’imprimer le mot de passe de récupération. Il est également stocké dans un fichier si vous avez enregistré le mot de passe de récupération dans un dossier.
La façon la plus facile de gérer les mots de passe de récupération d’une entreprise consiste à les avoir automatiquement enregistrés dans Active Directory®. Vous pouvez obtenir tous les détails sur la manière d’effectuer cette opération à l’adresse suivante go.microsoft.com/fwlink/?LinkId=87067.
Dans un prochain article, je développerai la gérabilité de BitLocker, mais dans cet aperçu général, vous devez savoir que BitLocker est livré avec un fournisseur WMI complet qui autorise BitLocker (et le TPM) a être gérés par tout système WBEM (Web-Based Enterprise Management) compatible WMI. Ceci signifie que BitLocker peut écrire le script en utilisant tout langage de script pouvant accéder aux objets WMI, tels que VBScript ou Windows PowerShell™.
BitLocker est également livré avec un outil de ligne de commande appelé manage-bde.wsf qui utilise le fournisseur WMI pour vous permettre de gérer BitLocker, sur des ordinateurs locaux ou distants. Pour plus d’informations, lancez une invite de commande élevée et saisissez manage-bde.wsf /?.

Désactivation sécurisée
À un moment donné, tout ordinateur doit être désactivé. Les entreprises dépensent souvent des sommes et des efforts significatifs pour s’assurer que les lecteurs de disques sont complètement nettoyés avant leur désactivation. La plupart des processus supprimant les données confidentielles des lecteurs de disques prennent du temps, sont onéreux et ont pour résultat la destruction permanente du matériel. BitLocker fournit d’autres options nettement plus rentables.
Au lieu de vous inquiéter de supprimer les données, BitLocker vous permet de ne pas enregistrer les données confidentielles sur le disque de manière risquée. Étant donné que tout ce qui est écrit sur le disque est chiffré, les données peuvent être rendues complètement inaccessibles de façon permanente en détruisant toutes les copies des clés de chiffrement. Le disque dur lui-même est complètement indemne et peut être réutilisé.
Vous pouvez choisir entre plusieurs approches de désactivation des volumes qui ont été protégés par BitLocker. Vous pouvez choisir de supprimer toutes les copies de clés des métadonnées de volume, tout en les conservant dans un site central sécurisé. Ceci peut permettre aux systèmes d’être transportés de manière sécurisée ou d’être désactivés temporairement s’ils restent sans assistance pendant longtemps. Ceci garantit que les utilisateurs autorisés puissent accéder aux données, tandis que ceux qui ne le sont pas, tels que les nouveaux propriétaires de l’équipement, ne le puissent pas.
Vous pouvez également choisir de supprimer toutes les copies de clés des métadonnées de volume et de toutes les archives, telles qu’Active Directory (peut-être en créant des clés qui ne sont pas enregistrées). Étant donné qu’il n’existe aucune clé de décryptage, personne ne peut récupérer les données.
Dans tous les cas, la désinstallation et la destruction des clés contenues dans les métadonnées de volume sont presque instantanées et peuvent être exécutées sur plusieurs systèmes par un administrateur. Un investissement minimal en temps et en effort est requis mais a pour résultat un niveau supérieur de protection permanente. L’utilitaire de format dans Windows Vista a été mis à jour pour qu’une commande de format supprime les métadonnées de volume et remplace ces secteurs pour supprimer de manière sécurisée toutes les clés BitLocker.

Quelques points pour terminer
BitLocker est un outil puissant conçu pour vous protéger des menaces spécifiques. Il est excellent dans sa catégorie. Cependant, ce serait une erreur de penser que BitLocker puisse vous protéger de toutes les menaces. Il est absolument primordial que vous continuiez à utiliser des défenses et des contrôles appropriés, tels que des mots de passe stricts.
Comprenez que BitLocker est adapté aux attaques hors ligne. Ceci signifie que si Windows s’exécute, BitLocker a déverrouillé le volume. En d’autres termes, BitLocker n’offre pas de protection à un système en cours d’exécution. Les technologies, telles qu’EFS et RMS complètent BitLocker en protégeant les informations lorsque le système d’exploitation s’exécute.
Pour plus d’informations sur BitLocker, visitez le site Web de Microsoft, à l’adresse suivante technet.microsoft.com/windowsvista/aa905065.aspx. Pour plus d’informations sur les spécifications TPM et TCG, visitez la section Spécifications TPM du site Web TCG à l’adresse suivante go.microsoft.com/fwlink/?LinkId=72757.

Byron Hynes travaille dans le groupe d’assistance utilisateur de Windows Server chez Microsoft. Il a précédemment travaillé en tant que consultant et formateur. Vous pouvez le contacter à l’adresse suivante : bhynes@microsoft.com.


 S&#233;curit&#233;: D&#233;couverte du pare-feu Windows
Sécurité Steve Riley

Découverte du pare-feu Windows
Vue d'ensemble:
  • Protection entrante/sortante
  • La plateforme de filtrage Windows
  • L’interface de sécurité avancée
  • Profils de réseau

À l’époque paléo-informatique, personne ne songeait à installer des pare-feu sur des ordinateurs individuels. Quel en aurait été l’intérêt ? Internet était quasiment inconnu, TCP/IP n’existait pas encore et le routage par les protocoles LAN se restreignait à votre bâtiment ou campus. Les données importantes résidaient sur
le macroordinateur ou les serveurs de fichiers : les informations conservées sur les ordinateurs de bureau étaient rarement essentielles et le propre poids de l’ordinateur offrait une certaine part de sécurité physique décente. S’il existait une connexion Internet, des traducteurs de protocoles étaient sans doute prévus, ainsi qu’un routeur de filtrage de paquets (je veux dire « pare-feu »), probablement configuré avec trop de règles et d’exceptions.
Les environnements informatiques modernes ont beaucoup changé depuis cette lointaine époque. Tout est connecté à Internet (et passe maintenant par le protocole TCP/IP) et les périphériques portables sont dorénavant la norme. Votre employeur vous a probablement équipé d’un ordinateur portable, pas parce qu’il vous apprécie, mais parce qu’il souhaite obtenir davantage de vous : il s’attend à ce que vous soyez disponible à tout moment, dès que vous avez cinq minutes et que vous disposiez d’une connexion Wi-Fi. Il est vrai que les portables coûtent plus cher que les ordinateurs de bureau, mais il ne fait aucun doute que cet investissement est remboursé par la productivité. Vous voyez, c’est la portabilité qui les rend si séduisants, pour vous et pour vos adversaires.
Réfléchissez à ceci : sur le temps total de mise sous tension et de connexion de votre portable à un réseau, quel est le pourcentage du temps de connexion à votre réseau d’entreprise ? Si vous êtes comme moi, peut-être 20 pourcent maximum. Ceci signifie que mon portable est en sécurité dans les limites du réseau d’entreprise Microsoft, protégé par les défenses de périmètre du réseau face aux attaques de l’extérieur, 20 pourcent du temps seulement. Mais qu’en est-il des 80 pourcent du temps où mon portable est, dans des buts pratiques, connecté directement à Internet ? (Et je suis souvent connecté au réseau le plus dangereux du monde : le réseau local d’un hôtel, à une conférence sur la sécurité informatique !) Et les fois où je suis connecté au réseau de l’entreprise, qu’en est-il des menaces représentées par d’autres ordinateurs dans cet environnement ?
Les contrôles de sécurité évoluent pour suivre, parfois avec trop de retard, les menaces. Les virus étaient un problème touchant les clients parce que les gens s’échangeaient des disquettes, donc les programmes antivirus apparurent d’abord chez les clients. Ensuite, à mesure que le courrier électronique a pris son essor et que les logiciels malveillants se sont transformés en vers s’appuyant sur la distribution des messages électroniques, les programmes anti-malware ont évolué et sont apparus sur les passerelles de courrier électronique. Avec le développement du Web, les logiciels malveillants se sont transformés en chevaux de Troie et les logiciels anti-programme malveillant se sont penchés sur les serveurs proxy d’accès à Internet. Il s’agit là d’un parcours d’évolution bien compris que personne ne discute.
Appliquons à présent cette logique aux pare-feu. Si un pare-feu représentait une protection suffisante contre les menaces d’hier dans les limites de votre réseau, ce n’est plus le cas car les menaces sont maintenant différentes, elles sont plus sophistiquées et plus répandues. N’oublions pas non plus que les périphériques et les styles de travail ont également beaucoup évolué. Un grand nombre d’ordinateurs contiennent des informations sensibles enregistrées localement et ils passent beaucoup de temps loin du réseau de l’entreprise (c’est-à-dire, en dehors de ses limites). Par conséquent, le pare-feu doit se transformer en mécanisme de protection client individuel. Ne vous méprenez pas : les pare-feu de clients ne sont plus facultatifs. Pour protéger vos ordinateurs de votre propre réseau d’entreprise et d’Internet, des pare-feu de clients sont nécessaires.

Pare-feu de clients et comédie sécuritaire
Beaucoup de gens ne se sont pas rendu compte que la version initiale de Windows® XP incluait un pare-feu de client. Ceci n’est pas vraiment surprenant puisque le pare-feu était désactivé par défaut et qu’il fallait plusieurs clics de souris pour le débusquer. De sa façon plutôt furtive, le pare-feu apparaissait sans véritable indication de son but ou informations sur son utilisation. Mais il marchait. Si vous aviez activé ce pare-feu, vous auriez été à l’abri de Nimda, Slammer, Blaster, Sasser, Zotob et de tous les autres virus essayant de lancer un trafic non sollicité sur votre port réseau. Conscient de l’importance de la protection des clients, Windows XP Service Pack 2 (SP2) a activé le pare-feu par défaut, créé deux profils (Internet et réseau d’entreprise) et permis l’activation de la stratégie de groupe.
Malheureusement, deux obstacles ont ralenti l’adoption du pare-feu Windows XP SP2 : des problèmes d’applications et la comédie sécuritaire. Beaucoup de gens craignaient que le pare-feu n’empêche leurs applications de fonctionner correctement. Toutefois, ceci était rarement le cas en raison de la conception du pare-feu. Le pare-feu permettait à l’ensemble du trafic sortant de quitter votre ordinateur, mais il bloquait tout le trafic entrant ne répondant pas à une requête sortante précédente. La seule occasion à laquelle cette conception entravait le bon fonctionnement d’une application sur un client était si l’application créait un socket d’écoute et comptait recevoir des requêtes entrantes. Le pare-feu Windows XP permettait des configurations simples d’exceptions pour les programmes ou les ports (mais, malheureusement, pas par la stratégie de groupe).
La plus grande force de dissuasion était la comédie sécuritaire jouée par les fabricants d’autres pare-feu de clients. Certains croyaient que la conception du pare-feu Windows XP (en l’occurrence le fait de permettre à tout le trafic sortant de partir sans contraintes) était une fonctionnalité insuffisante pour un pare-feu de client. L’argument était qu’un pare-feu de client suffisant devait bloquer tout le trafic, entrant et sortant, à moins que l’utilisateur n’ait accordé une autorisation particulière.
Réfléchissons-y un moment. Deux scénarios émergent.
  • Si vous intervenez en tant qu’administrateur local et que vous êtes infecté par un logiciel malveillant, le logiciel malveillant désactivera simplement le pare-feu. Vous êtes « 0wn3d ».
  • Si vous n’intervenez pas en tant qu’administrateur local et que vous vous faites infecter par un logiciel malveillant, un pare-feu tiers fera apparaître une boîte de dialogue dans une langue étrangère mentionnant des ports et des adresses IP et une question très sérieuse : « Souhaitez-vous autoriser cette opération ? » Bien entendu, la seule réponse est affirmative. Et une fois que cette boîte de dialogue disparaît, votre sécurité part avec elle. Plus habituellement, le logiciel malveillant détourne simplement une session existante d’un programme que vous avez déjà autorisé et vous ne voyez même pas la boîte de dialogue. Vous êtes toujours « 0wn3d ».
Il existe un axiome de sécurité important que vous devez comprendre : la protection porte sur la ressource que vous souhaitez protéger, pas sur la chose face à laquelle vous essayez de la protéger. L’approche correcte consiste à exécuter le pare-feu Windows, simple quoiqu’efficace, sur chacun des ordinateurs de votre organisation, à protéger chaque ordinateur face à tous les autres ordinateurs du monde. Si vous essayez de bloquer des connexions sortantes depuis un ordinateur qui est déjà compromis, comment pouvez-vous être sûr que l’ordinateur fait vraiment ce que vous lui demandez ? Réponse : vous ne pouvez pas en être sûr. La protection sortante est de la comédie sécuritaire : c’est un truc qui donne seulement l’impression d’améliorer votre sécurité sans faire quoi que ce soit pour améliorer votre sécurité en fait. C’est pourquoi la protection sortante n’existait pas dans le pare-feu Windows XP et n’existe pas dans le pare-feu Windows Vista™. (Je reviendrai sur le contrôle sortant dans Windows Vista dans quelques instants.)

Quelles sont les nouveautés dans Windows Vista ?
La plateforme de filtrage Windows, qui fait partie de la nouvelle pile de réseau, est la base du pare-feu Windows Vista. À l’instar de Windows XP, Windows Vista bloque le trafic entrant par défaut. En fonction du profil utilisé par votre ordinateur, il peut y avoir des exceptions par défaut pour les services réseau (j’aborderai les profils plus tard). Vous pouvez, si vous le souhaitez, écrire des règles pour autoriser des connexions entrantes. Également comme Windows XP, Windows Vista autorise par défaut tout trafic sortant à partir de processus interactifs, mais il limite le trafic sortant depuis les services qui participent à la restriction de services. Et, là aussi, vous pouvez écrire des règles pour bloquer des connexions sortantes supplémentaires.
La grande différence entre Windows XP et Windows Vista est la nouvelle interface de sécurité avancée et la prise en charge de stratégie de groupe intégrale pour la configuration et les règles (voir la figure 1). L’ancienne interface utilisateur du panneau de configuration y est toujours et est quasiment inchangée sauf pour les paramètres de la journalisation et du protocole ICMP (Internet Control Message Protocol), qui se trouvent maintenant dans la nouvelle interface utilisateur. Cette nouvelle interface utilisateur, le composant logiciel enfichable MMC de sécurité avancée, offre toutes les nouvelles fonctionnalités et une grande flexibilité. Il existe également un nouveau contexte dans la commande Netsh, netsh advfirewall, qui vous permet d’écrire des ajouts et des suppressions de règles, de définir et d’afficher des stratégies globales et par profil et d’afficher l’état actif du pare-feu. Et pour vous les développeurs, FirewallAPI.dll et Netfw.H fournissent un contrôle de programmation sur tous les paramètres du pare-feu.
Figure 1 Pare-feu Windows avec sécurité avancée
Figure 1 Pare-feu Windows avec sécurité avancée
La console MMC de sécurité avancée est gérée par des Assistants. Lorsque vous créez une règle, vous pouvez choisir un type parmi quatre : programme, port, prédéfini ou personnalisé. Ces types sont expliqués à la figure 2.
Figure 2 Quatre types de règles (Close Figure 2)

Type | Objectif
Programme | Utilisée pour autoriser ou bloquer le trafic pour un programme particulier.
Port | Utilisée pour autoriser ou bloquer le trafic sur des ports TCP ou UDP particuliers.
Prédéfini | Utilise un groupe préexistant de règles pour activer des fonctionnalités Windows sur le réseau (telles que le partage de fichiers et d’imprimantes ou l’assistance à distance).
Personnalisé | Expose tous les boutons, cadrans et commutateurs, de sorte que vous pouvez configurer des règles très spécifiques.
Nombreux sont les éléments que vous pouvez référencer lors de l’écriture de règles ; tous sont disponibles pour les règles locales et les règles appliqués par la stratégie de groupe. À savoir : Comptes et groupes d’utilisateurs et d’ordinateurs Active Directory®, adresses IP source et destination, ports TCP et UDP source et destination, numéros de protocole IP, programmes et services, types d’interfaces (câblé, sans fil ou à accès distant) et les types et codes ICMP.
Une fois configuré, le pare-feu traite les règles dans l’ordre suivant :
Restrictions de services Certains des services de Windows Vista se restreindront pour limiter la probabilité d’une autre attaque de style Blaster. Une des restrictions est une liste des ports requis par le service. Le pare-feu met ceci en application et empêche le service d’utiliser (ou d’être prié d’utiliser) un autre port.
Règles de sécurité de connexion La console MMC de sécurité avancée incorpore IPSec, ainsi que le pare-feu. Toutes les règles incluant des stratégies IPSec sont ensuite traitées.
Contournement authentifié Ces règles autorisent des ordinateurs authentifiés spécifiques à contourner d’autres règles.
Règles de blocage Ces règles bloquent explicitement le trafic entrant ou sortant spécifié.
Règles d’autorisation Ces règles autorisent explicitement le trafic entrant ou sortant spécifié.
Les règles de pare-feu sont stockées dans le registre, mais je ne vais pas vous dire où exactement. Bon, d’accord, vous les trouverez aux endroits suivants :
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
Surtout ne modifiez pas les règles directement dans le registre. Si vous le faites, nous vous retrouverons et nous vendrons votre animal de compagnie sur eBay ! Bon, peut-être pas, mais la seule manière prise en charge de modifier des règles consiste à utiliser la console MMC de sécurité avancée.

Profils de réseau
Windows Vista définit trois profils de réseau : domaine, privé et public. Lorsque l’ordinateur est joint à un domaine et qu’il s’est connecté au domaine, l’ordinateur applique automatiquement le profil du domaine (vous n’avez jamais la possibilité de faire ce choix vous-même). Lorsque l’ordinateur est connecté à un réseau interne qui n’a pas de domaine (par exemple, un réseau domestique ou un réseau de petite entreprise), vous (ou un administrateur) devez appliquer le profil privé. Enfin, lorsque l’ordinateur est connecté directement à Internet, vous devez appliquer le profil public.
Comment Windows Vista détermine-t-il l’endroit où placer votre ordinateur ? Quand il existe une modification de réseau (par exemple, s’il reçoit une nouvelle adresse IP ou s’il voit une nouvelle passerelle par défaut ou s’il obtient une nouvelle interface), un service appelé Network Location Awareness (NLA) détecte la modification. Il génère un profil de réseau (qui inclut des informations sur les interfaces existantes, précise si l’ordinateur s’est authentifié auprès d’un contrôleur de domaine, donne l’adresse MAC de la passerelle, et ainsi de suite) et lui attribue un GUID. NLA notifie ensuite le pare-feu et le pare-feu applique la stratégie correspondante (il existe une stratégie définie pour chacun des trois profils).
S’il s’agit d’une nouvelle interface que l’ordinateur n’a jamais rencontrée auparavant et que NLA n’a pas choisi le profil de domaine, vous verrez apparaître une boîte de dialogue qui vous demande d’indiquer le genre de réseau auquel vous vous connectez. Mystérieusement, il y a trois choix : Domestique, Entreprise et Public. Vous pourriez penser qu’Entreprise signifie le profil du domaine, mais en fait ce n’est pas le cas. Souvenez-vous, vous ne voyez jamais le profil du domaine parce que NLA le sélectionne automatiquement lorsque l’ordinateur se connecte à un domaine. En réalité, Domestique et Entreprise correspondent au profil privé. Ils ont les mêmes fonctionnalités ; seules les icônes diffèrent. Remarque : vous devez être administrateur local, ou être capable de vous élever à un administrateur local, pour sélectionner le profil privé. Vous ne saurez pas surpris de savoir que Public correspond au profil public.
Dans Windows Vista, un profil de réseau s’applique à toutes les interfaces de l’ordinateur. Voici un récapitulatif de l’arborescence de décision NLA :
  1. Examinez tous les réseaux connectés.
  2. Une interface est-elle connectée à un réseau classé comme public ? Si c’est le cas, définissez le profil de l’ordinateur sur public et quittez.
  3. Une interface est-elle connectée à un réseau classé comme privé ? Si c’est le cas, définissez le profil de l’ordinateur sur privé et quittez.
  4. Toutes les interfaces voient-elles un contrôleur de domaine et l’ordinateur a-t-il réussi à se connecter ? Si c’est le cas, définissez le profil de l’ordinateur sur domaine et quittez.
  5. Sinon, définissez le profil de l’ordinateur sur public.
L’objectif est de sélectionner le profil le plus restrictif possible. Il existe cependant deux effets secondaires évidents. D’abord, si le port Ethernet de votre ordinateur est connecté à votre réseau d’entreprise et que sa carte de réseau sans fil est connectée au Starbucks d’en bas, l’ordinateur sélectionnera le profil public, pas le profil de domaine. Ensuite, si votre ordinateur est connecté directement à Internet (dans le profil public) ou s’il est connecté à votre réseau local domestique (dans le profil privé) et que vous effectuez une connexion VPN avec votre réseau d’entreprise, votre ordinateur restera dans le profil public ou privé.
Qu’est-ce que cela peut bien vouloir dire ? La stratégie du pare-feu pour le profil de domaine inclut des règles pour l’assistance à distance, l’administration à distance, le partage de fichiers et d’imprimantes, etc. Si vous vous appuyez sur ces règles afin d’accéder à un client à distance, vous n’y parviendrez pas si le client a choisi un autre profil. Mais ne désespérez pas : vous pouvez écrire des règles de pare-feu pour autoriser les connexions entrantes dont vous avez besoin, puis les appliquer uniquement à des connexions VPN. À présent, vous pouvez continuer à gérer vos clients sur le réseau VPN, même lorsqu’ils ne sont pas dans le profil de domaine.

Contrôle des connexions sortantes
J’ai dit plus haut que le formulaire typique de protection sortant dans les pare-feux de client était juste de la comédie sécuritaire. Cependant, une forme de contrôle sortant est très utile : le contrôle administratif de certains types de trafic que vous savez ne pas vouloir autoriser. Le pare-feu Windows Vista fait déjà ceci pour les restrictions de services. Le pare-feu permet à un service de communiquer uniquement sur les ports dont il dit avoir besoin et il bloque toutes les autres tentatives du service. Vous pouvez développer en écrivant des règles supplémentaires qui autorisent ou bloquent un trafic spécifique conformément à la stratégie de sécurité de votre organisation (voir la figure 3).
Figure 3 Assistant Nouvelle règle de trafic entrant
Figure 3 Assistant Nouvelle règle de trafic entrant
Disons, par exemple, que vous souhaitez empêcher des utilisateurs d’exécuter un client de messagerie instantané particulier. Vous pouvez créer une règle (dans la stratégie de groupe, bien entendu) pour bloquer les connexions aux serveurs d’ouverture de session pour ce client.
Toutefois, cette approche a des limites pratiques. Par exemple, Windows Live™ Messenger (que vous connaissez peut-être sous le nom de MSN® Messenger) dispose d’une variété de serveurs qu’il peut utiliser pour se connecter et la liste ne cesse de changer. De plus, il se tournera vers le port 80/tcp si le port par défaut 1863/tcp est bloqué. Il serait trop compliqué de créer une règle pour empêcher Windows Live Messenger de se connecter à ses serveurs d’ouverture de session. Je mentionne ceci pour montrer que le contrôle administratif du trafic sortant peut être utile, mais qu’il ne peut pas remplacer les stratégies de restriction logicielle si vous devez maintenir un contrôle serré sur les logiciels que les utilisateurs sont autorisés à installer et exécuter.

Protéger votre ordinateur
Il n’y a plus de périmètre. Chaque ordinateur est dorénavant responsable de sa propre protection. Tout comme les logiciels anti-programme malveillant sont passés du client au périmètre, les pare-feu doivent passer du périmètre au client. Vous pouvez prendre des mesures immédiates en activant le pare-feu qui est déjà installé.
Que vos systèmes exécutent Windows XP ou que vous soyez déjà passé à Windows Vista, le pare-feu Windows est disponible pour tous vos clients et fournira la protection dont vous avez besoin pour améliorer la sécurité au sein de votre organisation (même lorsque vos employés mobiles sont à des milliers de kilomètres du bureau).

Où en apprendre plus
  • Windows Vista TechCenter : Mise en route du pare-feu Windows avec sécurité avancée
  • Windows Vista TechCenter : Diagnostic et dépannage du pare-feu Windows avec sécurité avancée
  • Steve Riley’s TechEd Europe Presentation: Améliorations IPSec et pare-feu Windows Vista
  • Le petit câbleur : Le nouveau pare-feu de Windows Vista et Windows Server « Longhorn »
  • Laboratoire virtuel Pare-feu Windows Vista

Steve Riley, stratège en sécurité dans le Trustworthy Computing Group de Microsoft et auteur pour TechNet Magazine, voyage dans le monde entier pour participer à des conférences et aider les clients à sécuriser leurs données. Son dernier ouvrage, consacré à la protection des réseaux Windows, est intitulé « Protect Your Windows Network » (Addison-Wesley, 2005). Vous pouvez le contacter à l’adresse steve.riley@microsoft.com.


 S&#233;curit&#233;: Les nouvelles ACL am&#233;liorent la s&#233;curit&#233; dans Windows&#160;Vista
Sécurité Jesper Johansson

Les nouvelles ACL améliorent la sécurité dans Windows Vista
Vue d'ensemble:
  • Nouveautés des ACL
  • Contrôles plus étroits de l’administrateur
  • Autorisations d’installateur de confiance
  • Utilisateurs et groupes modifiés

La structure fondamentale des listes de contrôle d’accès (ACL) n’a pas beaucoup changé pour Windows Vista, mais il existe plusieurs petites modifications néanmoins importantes, dont vous devez être conscient. Certaines modifications
étaient nécessaires parce que les ACL intervenaient dans plusieurs problèmes dans Windows® XP. Pour commencer, la plupart des utilisateurs de Windows XP s’exécutent comme administrateurs. C’est-à-dire qu’ils utilisent un compte qui est membre du groupe Administrateurs intégré. Pour les utilisateurs à domicile, il s’agit quasiment d’une certitude, car tous les comptes ajoutés pendant l’installation deviennent administrateurs. Par conséquent, tout programme que ces utilisateurs exécutent s’exécutera également avec les privilèges d’administrateur, en leur donnant l’accès sans limites au système d’exploitation. C’est bien sûr particulièrement problématique si ces programmes sont de source douteuse.
Le deuxième problème qui devait être pris en compte était que les ACL par défaut des versions précédentes de Windows rendaient beaucoup de gens nerveux car elles comprenaient des entrées d’ACL (les ACE) pour Tout le monde, Utilisateurs avec pouvoir et autres. Par exemple, l’ACL par défaut sur la racine du volume de démarrage (normalement C:\) de Windows XP donnait accès en lecture à Tout le monde et accordait l’autorisation de création de dossiers à tous les membres du groupe Utilisateurs. Enfin, dans Windows XP, les opérations pouvant être effectuées comportaient des restrictions. Il n’existait par exemple aucune méthode pour l’attribution d’autorisations au propriétaire actuel d’un objet. Vous pouviez donner des autorisations au propriétaire mais, si le propriétaire était modifié, ces autorisations n’étaient pas transférées. De même, les propriétaires possédaient des droits implicites sur un objet, quelles que soient les autorisations affectées à cet objet.
Avec Windows Vista™, Microsoft a entrepris de résoudre nombre de ces problèmes et de permettre la prise en charge d’autres fonctionnalités, telles que le Contrôle de compte d’utilisateur (User Account Control, UAC). Cet article porte principalement sur les modifications majeures liées au contrôle d’accès dans Windows Vista. Le mois prochain, je continuerai par les outils que vous pouvez utiliser pour gérer le contrôle d’accès.

Utilisateurs et groupes modifiés et nouveaux
Certains utilisateurs et groupes de Windows Vista sont nouveaux et certaines vieilles connaissances de Windows XP ont été supprimées. De plus, la manière dont certains fonctionnent a été modifiée. Chacune des modifications a un certain impact sur la manière dont le contrôle d’accès peut être géré.
Administrateur : désactivé par défaut Le compte Administrateur intégré, avec l’identificateur relatif (RID) 500, est maintenant désactivé par défaut dans la plupart des cas. L’administrateur était prévu pour être un compte d’urgence, utilisé pour sauver l’ordinateur lorsque tout le reste avait échoué. Il a fini par malheureusement être utilisé beaucoup plus souvent comme compte d’administration standard et enfreindre ainsi plusieurs principes de sécurité. Le plus notable de ceux-ci, la responsabilité, signifie que vous perdez la capacité de traquer qui effectue des modifications sur votre système. Le compte a donc partiellement été désapprouvé. Microsoft pourra en fin de compte totalement désapprouver le compte, mais il est pour l’instant désactivé par défaut. Si vous ne disposez pas d’autres comptes locaux dans le groupe Administrateurs, le RID 500 est toujours utilisable dans la console de récupération et en mode sans échec, mais ne peut et ne doit autrement pas être utilisé.
Notez qu’il existe une différence entre le compte Administrateur intégré et les autres comptes du groupe Administrateurs. Nous écrivons généralement avec une majuscule « Administrateur » pour faire référence au compte avec le RID 500 et le distinguer d’un « administrateur », qui est tout autre compte membre du groupe Administrateurs intégré. Les noms de groupes sont également écrits avec une majuscule.
Dans Windows XP, le compte Administrateur intégré possédait plusieurs droits et privilèges spéciaux dont ne disposait aucun autre administrateur. Nombre de ceux-ci ont été supprimés dans Windows Vista, mais il existe deux exceptions notables : Premièrement, un compte administrateur désactivé peut être utilisé dans la console de récupération s’il n’existe pas d’autres administrateurs locaux. Deuxièmement, l’Administrateur n’est pas soumis à l’UAC et disposera toujours d’un jeton administratif complet. Ceci s’applique également à l’Administrateur de domaine (RID 500 sur un domaine).
Autorisations d’Utilisateur avec pouvoir supprimées L’ancien groupe Utilisateurs avec pouvoir a, pour des raisons pratiques, été aboli. Le groupe existe toujours, mais la plupart des autorisations qui lui étaient accordées ont été supprimées. Il n’était pas difficile de savoir qu’un utilisateur membre du groupe Utilisateurs avec pouvoir était en fait un administrateur qui ne s’était pas encore promu administrateur. J’ai pris une fois le contrôle d’un ordinateur auquel tous les correctifs logiciels nécessaires avaient été appliqués et sur lequel était exécuté Windows XP Service Pack 2 (SP2), en moins de 45 minutes, en m’accordant les privilèges d’administrateur. La reconnaissance, à l’aide d’un petit programme écrit en C++ et la fermeture puis l’ouverture de session pour terminer la prise de contrôle étaient incluses, et tout ceci était possible car j’étais membre des Utilisateurs avec pouvoir.
De nombreuses organisations ont accordé des autorisations sophistiquées au groupe Utilisateurs avec pouvoir et dépendent d’utilisateurs qui en sont membres ; il n’était donc pas possible de supprimer ce groupe dans Windows Vista. Cependant, Microsoft supprimera probablement complètement le groupe Utilisateurs avec pouvoir dans une version future de Windows. Vous seriez bien avisé de commencer à prévoir votre migration sans groupe Utilisateurs avec pouvoir.
Installateur de confiance L’Installateur de confiance est en fait un service et non un utilisateur, bien que des autorisations lui soient accordées dans l’ensemble du système de fichiers. Le renforcement de la sécurité de service permet à chaque service d’être traité comme une entité de sécurité à part entière à laquelle des autorisations peuvent être affectées, comme à tout autre utilisateur. Pour un aperçu général de cette fonctionnalité, voir le numéro de janvier 2007 de TechNet Magazine. Le livre Windows Vista Security (Grimes et Johansson, Wiley Press, 2007), explore en détail le renforcement de la sécurité de service, y compris la manière dont d’autres fonctionnalités en tirent parti, telles que le pare-feu et IPSec.
Les SID de service ne sont pas émis par les autorités observées précédemment telles que NT AUTHORITY ou un domaine. Le nom complet du compte virtuel de l’installateur de confiance est NT SERVICE\TrustedInstaller et son SID est :
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Vous pouvez voir le SID de tout service, même ceux qui n’existent pas, en exécutant la commande sc showsid, comme indiqué à la figure 1.
Figure 1 sc showsid affiche le SID de tout service, y compris ceux qui n’existent pas encore
Figure 1 sc showsid affiche le SID de tout service, y compris ceux qui n’existent pas encore
Ce SID commence par S-1-5-80. Notez que la première sous-autorité est ici 80, ce qui correspond à SECURITY_SERVICE_ID_BASE_RID et signifie que ce SID est émis par la sous-autorité NT SERVICE d’un service. Ceci se vérifie pour tout service. Les sous-autorités restantes et les RID sont basés sur le nom du service. Ceci permet à un développeur d’accorder des autorisations à son service sans avoir à générer et à installer le service au préalable, car son nom est déterministe et ne variera pas d’un ordinateur à l’autre.
Si vous n’arrivez pas à trouver le service TrustedInstaller dans le gestionnaire de services, son nom complet est « Programme d’installation de modules Windows ».
Comptes d’aide et de prise en charge supprimés Les comptes Support_xxxxxx et HelpAssistant ont tous deux été supprimés sur les nouvelles installations propres de Windows Vista, bien qu’ils soient conservés en cas de mise à niveau à partir d’une version précédente de Windows. Le compte Support_xxxxxx était utilisé pour exécuter des scripts à partir du centre de support. Certains OEM qui fournissaient leur propre contenu d’aide pouvaient également avoir fourni leurs propres comptes de support. Le sort des comptes OEM est incertain, mais il est plus que probable que les OEM arrêteront simplement de les créer. Ils ne sont pour ainsi dire plus nécessaires. En fait, du point de vue de la sécurité, il n’était de toute façon pas très judicieux d’autoriser des utilisateurs à exécuter des scripts à partir du centre d’aide en tant qu’autre utilisateur. Il est donc préférable que ces comptes disparaissent. Windows Vista possède un nouveau mécanisme pour l’accomplissement de cette tâche.
Le compte HelpAssistant était utilisé pour l’assistance à distance. Comme avec le centre d’aide, la fonctionnalité d’assistance à distance a été remaniée afin d’éviter de devoir recourir à l’utilisation du compte HelpAssistant, et il a par conséquent été supprimé.
Nouveaux SID d’emplacement réseau Les systèmes d’exploitation basés sur Windows NT® ont toujours eu certains SID basés sur l’emplacement réseau, tels que NETWORK et INTERACTIVE, qui indiquent des utilisateurs ouvrant une session depuis le réseau et de manière interactive. Il existe également un SID REMOTE INTERACTIVE LOGON, attribué aux utilisateurs ouvrant une session à l’aide des services Terminal Server. (Notez que les utilisateurs des services Terminal Server dispose de REMOTE INTERACTIVE LOGON et de INTERACTIVE LOGON dans leurs jetons.) Dans Windows Vista, deux SID supplémentaires ont été ajoutés : DIALUP et INTERNET. Le raisonnement exact derrière l’ajout d’un compte indiquant une ouverture de session par ligne commutée est quelque peu incertain, particulièrement lorsqu’un nombre toujours plus grand d’utilisateurs ne se connecte pas en ligne si le seul réseau disponible est une ligne téléphonique, mais ce SID est maintenant disponible. INTERNET correspond évidemment à un utilisateur ayant ouvert une session au-delà du réseau local. NETWORK, cependant, indique toujours tout utilisateur ouvrant une session depuis le réseau, y compris Internet.
DROITS DU PROPRIÉTAIRE et droits du propriétaire Il existe maintenant un SID pour les DROITS DU PROPRIÉTAIRE, qui s’applique à quiconque étant propriétaire d’un fichier au moment où un accès à celui-ci a lieu. Il est principalement utilisé pour limiter ce que le propriétaire peut faire avec le fichier. Il existe deux modifications notables du fonctionnement des droits du propriétaire par rapport à Windows XP. Tout d’abord, si vous êtes propriétaire de l’objet, mais qu’il existe un ACE sur l’objet qui s’applique à vous, les droits de l’ACE supplanteront le fait que vous êtes le propriétaire. Il s’agit d’une modification majeure qui aura un impact significatif sur certains aspects d’administration de système car nous sommes habitués à ce que le propriétaire dispose de droits implicites. Deuxièmement, le SID DROITS DU PROPRIÉTAIRE peut être utilisé pour limiter davantage ce que le propriétaire peut faire avec un objet.
Supposons que nous disposions d’un dossier, dont l’utilisateur Jesper est propriétaire, avec un ACL, comme à la figure 2. L’utilisateur, Jesper, possède uniquement l’autorisation Lecture sur le dossier, bien qu’il en soit le propriétaire. S’il essaie de copier un fichier dans celui-ci, la copie échouera car Jesper n’a pas l’autorisation d’écriture dans le dossier. Cependant, ceci n’est pas entièrement intuitif en ce qui concerne les messages d’erreur. Si vous tentez de copier un fichier avec l’Explorateur Windows® dans un dossier que vous possédez mais pour lequel vous ne disposez pas des autorisations d’écriture, voici ce qui se passe : Premièrement, l’Explorateur Windows indique que vous devez élever les autorisations pour copier le fichier et vous demande de le faire, mais la copie de fichier échoue parce que vous n’avez pas les droits de copie de quoi que ce soit dans ce dossier. Vous obtenez un message d’erreur indiquant « Vous devez disposer d’une autorisation pour effectuer cette action » et un bouton pour « Réessayer » (comme si cela pouvait vous aider) et « Annuler ». Ceci, en dépit du fait que vous êtes le propriétaire.
Figure 2 Seul le Système local et un autre utilisateur ont accès à ce dossier
Figure 2 Seul le Système local et un autre utilisateur ont accès à ce dossier
Si Jesper essaie de modifier l’ACL sur le fichier, il sera invité à élever son jeton pour le faire. Puisqu’il est propriétaire du fichier, il peut le faire. Le propriétaire conserve des droits implicites de lecture et de modification de l’ACL (READ_CONTROL et WRITE_DAC) à moins qu’un ACE pour DROITS DU PROPRIÉTAIRE spécifie autre chose.
Pour comprendre l’effet du SID DROITS DU PROPRIÉTAIRE, ajoutons-le à l’ACL ci-dessus. Nous avons maintenant les autorisations illustrées à la figure 3.
Figure 3 L’ajout des autorisations DROITS DU PROPRIÉTAIRE au dossier modifie les autorisations de Jesper
Figure 3 L’ajout des autorisations DROITS DU PROPRIÉTAIRE au dossier modifie les autorisations de Jesper
Avec ces autorisations, si le compte de Jesper tente de copier quelque chose dans le dossier, cette action réussit immédiatement parce que Jesper est propriétaire et possède les droits appropriés. Cependant, si Jesper essaie de modifier l’ACL sur l’objet, cette action échoue ! L’ACE DROITS DU PROPRIÉTAIRE spécifie que le propriétaire aura uniquement le privilège Modifier, pas la capacité de modifier la liste de contrôle d’accès discrétionnaire (DACL). Par conséquent, DROITS DU PROPRIÉTAIRE est principalement utilisé pour supprimer WRITE_DAC, la capacité de modifier le descripteur de sécurité du propriétaire.
Si un administrateur modifie le propriétaire de l’objet, les autorisations DROITS DU PROPRIÉTAIRE ne sont pas automatiquement transférées au nouveau propriétaire. Dans ce cas, l’ACE DROITS DU PROPRIÉTAIRE est désactivé en le marquant comme pouvant être uniquement hérité, sans l’appliquer aux conteneurs ou aux objets (en d’autres termes en ne l’appliquant pas du tout). Ceci est effectué pour s’assurer que les administrateurs ne sont pas entièrement bloqués pour accéder à l’objet. Pour faire en sorte que l’ACE DROITS DU PROPRIÉTAIRE prenne de nouveau effet, l’Administrateur doit réactiver manuellement cet ACE. Ainsi, il peut être marqué comme s’appliquant à ce dossier, ses sous-dossiers et ses fichiers, selon les besoins.
Il existe plusieurs scénarios intéressants dans lesquels le SID DROITS DU PROPRIÉTAIRE peut être utile, comme lorsque l’administrateur souhaite que les utilisateurs puissent créer des fichiers et des dossiers sur un serveur de fichiers, mais qu’il ne veut pas qu’ils puissent modifier des ACL sur ces dossiers. Une autre situation probable survient lorsque les utilisateurs étaient membres d’un groupe à certain point et ont créé certains objets mais, peut-être pour des raisons professionnelles, ont été plus tard supprimés de ce groupe. À ce stade, ils ne devraient pas pouvoir modifier les paramètres sur ces objets.
DROITS DU PROPRIÉTAIRE est considérablement utilisé pour renforcer la sécurité de service. Lorsqu’un service crée un objet transitoire au moment de l’exécution, le créateur de l’objet est le SID principal du processus de service, généralement LocalSystem, NetworkService ou LocalService, et non le SID du service lui-même. Ceci signifie que tout autre service s’exécutant dans le même contexte de processus peut modifier l’objet, ce qui est sans aucun doute peu souhaitable. En définissant un SID DROITS DU PROPRIÉTAIRE sur de tels objets, le système d’exploitation peut empêcher d’autres services d’accéder à ceux-ci.

ACL par défaut
Les ACL par défaut dans Windows XP étaient en fait essentiellement bons. En dehors de certains problèmes mineurs, tels que l’autorisation de placer des fichiers dans la racine du volume de démarrage accordée aux utilisateurs, ils étaient généralement sensés. Cependant, certains OEM ont apparemment décidé qu’ils savaient mieux ce qui constituait une sécurité raisonnable. L’écran de la figure 4 correspond à l’image de l’ACL sur le répertoire Windows d’un ordinateur exécutant Windows XP Édition Media Center pour un OEM important. L’OEM a essentiellement désactivé la sécurité du système de fichiers.
Figure 4 Un ACL configuré par l’OEM
Figure 4 Un ACL configuré par l’OEM
Microsoft a effectué quelques réglages des ACL dans Windows Vista. Premièrement, si vous êtes habitué à Windows XP, vous savez que tous les fichiers de système d’exploitation sont la propriété du groupe Administrateurs et que les administrateurs disposent du contrôle total sur ces fichiers. En tant que membre de ce groupe, vous disposez par conséquent d’un accès sans limites à ces fichiers. Cela n’est pas le cas dans Windows Vista.
Installateur de confiance Dans Windows Vista, la plupart des fichiers du système d’exploitation sont la propriété du SID TrustedInstaller, et seul ce SID dispose du contrôle total sur ceux-ci. Ceci est le résultat de la tâche d’intégrité de système qui a été mise en œuvre dans Windows Vista et a spécifiquement pour but d’empêcher un processus qui s’exécute comme administrateur ou Système local de remplacer automatiquement les fichiers. Pour pouvoir supprimer un fichier de système d’exploitation, vous devez par conséquent prendre possession du fichier puis lui ajouter un ACE qui vous autorise à le supprimer. Ceci offre une mince couche de protection contre un processus qui s’exécute comme Système local et possède un libellé d’intégrité Système. Un processus possédant une intégrité plus réduite n’est pas supposé pouvoir s’élever lui-même pour modifier la propriété. Certains services peuvent par exemple s’exécuter avec une intégrité moyenne, bien qu’ils s’exécutent comme Système local. De tels services ne peuvent pas remplacer les fichiers système pour qu’un exploit qui en prend possession puisse remplacer certains fichiers du système d’exploitation, ce qui rend plus difficile l’installation d’un rootkit ou autre logiciel malveillant sur le système. Il devient également plus difficile pour les administrateurs système qui s’offusquent de la simple présence de certains fichiers binaires système de supprimer ces fichiers.
ACE de refus d’accès Vous constaterez que beaucoup d’objets du système de fichiers possèdent des ACE de refus d’accès pour Tout le monde, ce qui a provoqué une grande consternation parmi de nombreux administrateurs. Si vous activez l’option Afficher les fichiers et dossiers cachés, vous verrez le dossier familier Documents and Settings. Cependant, si vous cliquez dessus, vous obtiendrez une erreur de refus d’accès. Pour comprendre ce qui se passe avec Documents and Settings, examinez le listing de répertoire de la figure 5.
Figure 5 Documents and Settings est en fait un point de jonction et non un répertoire
Figure 5 Documents and Settings est en fait un point de jonction et non un répertoire
Documents and Settings n’est en fait pas du tout un répertoire, mais un point de jonction. Rappelez-vous que les points de jonction sont similaires aux liens symboliques qui redirigent simplement l’accès à un autre emplacement. Dans ce cas, la jonction va directement vers un répertoire nommé C:\Users. Microsoft a en fait modifié l’espace de noms du système de fichiers de manière significative dans Windows Vista et les données utilisateur sont maintenant transférées dans C:\Users. Les autres éléments situés au-dessous de l’ancien espace de noms « C:\Documents and Settings\<Nom d’utilisateur> » ont également été déplacés. Par exemple, « C:\Documents and Settings\<Nom d’utilisateur>\Application Data » a été transféré vers C:\Users\<nom d’utilisateur>\appdata\roaming. Vous pouvez voir les modifications très clairement à l’aide d’une ligne de commande utilisant la commande dir /a, comme je l’ai fait à la figure 5. La raison pour laquelle l’espace de noms a été modifié si radicalement est pour qu’il soit plus intuitif pour les utilisateurs et pour obtenir une séparation claire entre les documents et les données. Au lieu d’enregistrer tous les fichiers de données sous le dossier Mes Documents, les développeurs peuvent maintenant créer leurs propres dossiers sous le profil de l’utilisateur et l’utilisateur les verra à cet emplacement. Les données d’application pour tous les utilisateurs sont maintenant dans un dossier masqué appelé %systemroot%\ProgramData plutôt que sous Documents and Settings\All Users\Application Data.
Microsoft n’a pas supprimé l’espace de noms « C:\Documents and Settings » car l’utilisation de ce nom peut être codée en dur dans les anciennes applications au lieu d’utiliser des variables d’environnement telles que %USERPROFILE%. Ces applications ne fonctionneraient pas si « C:\Documents and Settings » disparaissait. Ceux-ci sont plutôt représentés comme des points de jonction ou des liens symboliques, pour la compatibilité ascendante. Les applications dans lesquelles ces chemins sont codés en dur peuvent toujours tomber en panne, en fonction de la méthode dont elles effectuent l’accès aux données, mais elles ne fonctionnent déjà pas dans les versions de Windows différentes de l’anglais. C’est vraiment le point essentiel. Lorsqu’une mise à jour de Windows, telle que Windows XP SP2 ou Windows Vista, provoque une panne de programmes tiers, c’est presque toujours parce que les développeurs de ces programmes ont fait des suppositions non valides ou utilisé Windows d’une manière dont ils n’étaient pas supposés le faire.
Si vous essayez d’ouvrir un fichier, par exemple, en tapant « C:\Documents and Settings\<Nom d’utilisateur>\Mes Documents\foo.txt », cela devrait fonctionner, en supposant que vous disposez à cet emplacement d’un fichier appelé foo.txt. Cependant, si vous essayez de naviguer vers « C:\Documents and Settings\<Nom d’utilisateur>\Mes documents », un message d’erreur « Accès refusé » s’affichera. Pour comprendre ce qui se passe, examinez l’ACL de la figure 6.
Figure 6 ACE de refus d’accès sur Documents and Settings
Figure 6 ACE de refus d’accès sur Documents and Settings
Examinez l’ACE de la liste. Il s’agit d’un ACE de refus d’accès pour Tout le monde de la liste du contenu du dossier. Les programmes peuvent traverser les points de jonction et ouvrir des documents avec des chemins absolus car le groupe Tout le monde possède le privilège Contourner la vérification de parcours (également connu sous le nom SeChangeNotifyPrivilege). Les tentatives d’énumération par un utilisateur ou un processus des répertoires qu’ils représentent échoueront en raison de l’ACE de refus d’accès. C’est pourquoi il n’est en fait pas possible d’afficher le contenu de C:\Documents and Settings et qu’il n’est pas non plus possible de supprimer ce « répertoire ». Le but principal de la mise en place de l’ACE de refus d’accès est la prévention de la suppression de la jonction par les utilisateurs, ce qui provoquerait des pannes dans les anciennes applications. Elle permet également de rappeler aux développeurs de ne pas écrire d’applications utilisant l’ancien espace de noms et de commencer plutôt à utiliser les variables d’environnement ou les chaînes de Registre pour mettre l’application à l’abri des modifications futures et des différences dues à la langue.
Notez que tous ces points de jonction sont masqués par défaut et que la vaste majorité des utilisateurs ne les verra jamais. Pour empêcher ceux qui les voient de les supprimer, Microsoft a mis en place un ACE de refus d’accès pour « Lister le dossier ».
Contourner la vérification de parcours La raison pour laquelle les utilisateurs peuvent accéder à des fichiers pour lesquels ils possèdent des droits à l’intérieur de dossiers (ou points de jonction) pour lesquels ils ne possèdent pas de droits d’accès, est que tout le monde dispose du privilège Contourner la vérification de parcours. Contourner la vérification de parcours, ou SeChangeNotifyPrivilege, est en fait le privilège le plus fondamental de Windows. Il est accordé à un processus dont tous les autres privilèges ont été supprimés, sauf si ce processus demande spécifiquement que ce privilège soit aussi supprimé. C’est ce qui se passe lorsque vous lancez un processus utilisant la ligne runas /trustlevel:0x10000 < dans Windows Vista. Le programme spécifié dans <commande> s’exécutera avec un jeton limité et tous les privilèges, sauf SeChangeNotifyPrivilege, sont dépouillés du jeton du processus.
Il est intéressant de noter que trustlevel 0x20000 procure un jeton avec l’ensemble normal de SID, mais des privilèges dépouillés. 0x40000 procure un jeton complètement normal.

Autorisations par défaut
Les autorisations par défaut sur le système de fichiers dans Windows Vista ont été quelque peu modifiées dans Windows XP. Si vous examinez l’ACL sur %systemdrive% (habituellement le lecteur C:, le volume de démarrage) sur Windows XP ou Windows Server® 2003, vous verrez ceci (ou quelque chose de très similaire sur les premières versions de Windows XP) :
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Voici le même ACL sur le même répertoire dans Windows Vista :
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Plusieurs différences sont à noter. Premièrement, il existe maintenant deux ACE pour BA (BUILTIN\Administrators) au lieu d’un seul. Cependant, l’effet direct est identique. Dans Windows Vista, un ACE n’est pas hérité et accorde l’accès complet à la racine ; et l’un des ACE est un ACE E/S (à héritage uniquement), hérité par les conteneurs et les objets, et celui-ci accorde les permissions GA (ensemble générique, ou contrôle total). Ceci est également vrai pour le remplacement d’un ACE SY (LocalSystem) par deux dans Windows Vista. Dans Windows XP, cet ACE unique accordait l’accès total et était hérité par les objets et les conteneurs. Ici encore, il n’y a aucune modification directe. La raison principale pour laquelle l’ACL a été modifié était de clarifier et de séparer les privilèges pour que l’ACL soit plus facile à gérer et même, potentiellement, à restaurer.
De manière plus intéressante, vous noterez que l’ACE pour CO (Creator/Owner, Créateur/Propriétaire) a été supprimé. Ceci signifie que si un utilisateur crée un objet dans la racine du système de fichiers, aucune autorisation spéciale n’est maintenant accordée au créateur.
Vous noterez également que l’ACE pour WD (Tout le monde) a été supprimé. De nombreuses personnes intéressées par la sécurité, bien que ne comprenant pas complètement les implications de leurs actions, étaient indûment préoccupées par cet ACE. Microsoft a essayé en vain pendant des années d’expliquer que le groupe Tout le monde était fonctionnellement identique au groupe intégré Utilisateurs, mais il semble qu’ils y aient finalement renoncé et aient simplement supprimé cet ACE. Puisqu’il existe un ACE identique pour BU (BUILTIN\Users) également hérité par les conteneurs et les objets, l’effet direct est que rien n’a été modifié.
En outre, deux des ACE pour BU (utilisateurs intégrés) ont été remplacés par des ACE pour AU (utilisateurs authentifiés). Ceci s’explique par le fait que le compte Invité est membre des utilisateurs intégrés (en vertu du fait que INTERACTIVE est membre du groupe intégré des utilisateurs), mais Invité n’est pas membre du groupe des utilisateurs authentifiés. Pour permettre au compte invité de lire et d’exécuter des fichiers, l’ACE 0x1200a9 (dans la pratique, Lire et Exécuter) demeure accordé à BU. Cependant, les ACE qui accordent des autorisations de création de fichiers et de dossiers sont plutôt accordés aux utilisateurs authentifiés. Il s’agit d’une modification par rapport à Windows XP. Dans Windows XP, un Invité pouvait créer des fichiers dans la racine. Dans Windows Vista, un Invité ne peut pas créer de tels fichiers. Gardez cependant à l’esprit que ceci ne sert à rien, sauf si le compte Invité est activé et que les invités peuvent d’une manière ou d’une autre atteindre la racine du volume de démarrage. Par défaut, le compte Invité est désactivé.
J’ai réservé le meilleur pour la fin. Il existe quelques ACE très intéressants et en apparence difficiles dans les deux listes ci-dessus. Dans Windows XP, un ACE est hérité par les conteneurs et spécifie 0x100004 pour les utilisateurs intégrés. Cet ACE accorde aux utilisateurs le droit de créer des sous-dossiers, des sous-dossiers de sous-dossiers etc., puisqu’il est hérité par les conteneurs. Il existe également un ACE d’héritage uniquement, hérité par les sous-dossiers pour 0x100002. Cet ACE accorde aux utilisateurs le droit de créer des fichiers et des sous-dossiers dans les dossiers qu’ils créent sous la racine. En d’autres termes, ces deux ACE autorisent les utilisateurs, y compris les invités, à créer des fichiers et des dossiers sous la racine, comme je l’ai mentionné précédemment.
Dans Windows Vista, les ACE y correspondant sont un ACE d’héritage uniquement, hérité par les conteneurs et les fichiers, accordant GR (lecture générique), GX (exécution générique) et GW (écriture générique) ainsi que SD (Descripteur de sécurité de lecture) et un ACE qui s’applique uniquement à la racine et qui accorde le privilège LC. LC est en fait une abréviation qui s’applique aux ACE d’Active Directory®. Dans Active Directory, il signifie qu’un utilisateur peut lister des objets enfants. Cependant, la valeur hexadécimale de LC est 0x4. Pour un répertoire, 0x4 signifie FILE_ ADD_SUBDIRECTORY, ce qui devient fonctionnellement équivalent à 0x100004, puisque nous avons déjà 0x100000 (la capacité d’utiliser l’objet pour la synchronisation) de l’ACE 0x1200a9. En d’autres termes, il fournit exactement le même effet que dans Windows XP : les utilisateurs peuvent créer des sous-répertoires sous la racine.
D’où proviennent ces valeurs hexadécimales ? Pour commencer, que sont les valeurs hexadécimales ? Comme vous devez l’avoir maintenant remarqué, le contrôle d’accès regorge de nombres hexadécimaux (en base 16), tels que 0x1200a9. Ce sont en fait des représentations par masques de bits d’un masque d’accès qui sont définies sur « activées », pour indiquer qu’elles sont utilisées dans un ACE particulier. Lorsque vous utilisez un outil, tel que icacls, sc ou secedit, pour lister un ACL, les masques de bits sont représentés par des chaînes de texte plus conviviales, s’il existe une correspondance 1 à 1.
Par conséquent, pour déterminer ce que signifie LC vous devez simplement accéder au site Web MSDN®, rechercher la chaîne LC et examiner la colonne des valeurs de droits d’accès (Access right value) pour y trouver ADS_RIGHT_ACTRL_DS_LIST. Si vous ouvrez ensuite le fichier d’en-tête Iads.h et recherchez cette chaîne, vous trouverez qu’elle correspond à 0x4. Pour les chaînes qui ne proviennent pas d’Active Directory (qui ne sont pas précédées de « ADS_RIGHT »), vous trouverez généralement la valeur hexadécimale dans AccCtrl.h. Une fois que vous disposez de la valeur hexadécimale, il est facile de la rechercher dans le masque d’accès dans WinNt.H ou AccCtrl.h pour voir ce qu’elle signifie vraiment.
Si vous avez besoin d’aide pour ceci, vous pouvez vous procurer une copie du livre Protect Your Windows Network (de Jesper Johansson et Steve Riley, Addison-Wesley, 2005). Le chapitre 17 détaille en profondeur comment analyser les chaînes et les ACE du langage SDDL (Security Description Definition Language).
Les autorisations accordées à ces sous-répertoires (A;OICIIO;SDGXGWGR;;;AU) sont uniquement gouvernées par l’ACE dans Windows Vista, ce qui constitue la plus grande différence entre Windows Vista et Windows XP. Plutôt que d’accorder un contrôle total au créateur de sous-répertoires, comme dans Windows XP, Windows Vista accorde des privilèges de modification aux utilisateurs authentifiés.
Le résultat direct de ce nouvel ACL est que le créateur d’un objet ne dispose plus de droits spéciaux et que les choses sont un peu plus claires. La plus importante modification est peut-être que les utilisateurs authentifiés disposent de privilèges Modifier même dans les sous-dossiers créés par les administrateurs, ce qui est très différent de Windows XP. Dans Windows XP, les utilisateurs et les utilisateurs authentifiés ne disposent pas de droits sur les objets créés par les administrateurs sous la racine. Dans l’ensemble, cependant, bien que ces ACE semblent difficiles, l’effet direct n’est pas très différent de celui de Windows XP.
Pour résumer, dans Windows Vista, tout le monde, y compris l’utilisateur Invité, peut lire et peut exécuter des fichiers dans la racine. Seuls les utilisateurs authentifiés peuvent créer de nouveaux fichiers et dossiers et, lorsque les utilisateurs le font, ils obtiennent des autorisations de modification sur ces fichiers et dossiers. En d’autres termes, les autorisations sont légèrement plus efficaces dans Windows Vista que dans Windows XP, bien qu’il soit important de noter que le compte invité est par défaut désactivé.

Modifications apportées aux jetons
Lorsqu’un utilisateur membre du groupe Administrateurs de Windows XP ouvre une session, son jeton contient le SID du groupe Administrateurs et il peut faire tout ce que le groupe Administrateurs peut faire. Dans Windows Vista, par contre, ceci n’est plus le cas en raison du Contrôle de compte d’utilisateur. Le SID des administrateurs est toujours présent dans le jeton, mais il est défini sur Refuser uniquement, comme illustré dans la capture d’écran de Process Explorer à la figure 7.
Figure 7 Avec le Contrôle de compte d’utilisateur, le SID Administrators est uniquement utilisé pour refuser l’accès, sauf en cas d’élévation des privilèges
Figure 7 Avec le Contrôle de compte d’utilisateur, le SID Administrators est uniquement utilisé pour refuser l’accès, sauf en cas d’élévation des privilèges
En exécutant le contrôle d’accès, une telle entrée dans le jeton est uniquement utilisée pour refuser l’accès, en d’autres termes pour correspondre à un ACE de refus d’accès (DENY). Tous les ACE d’autorisation pour ce SID sont ignorés. Ceci signifie que vous n’êtes pas véritablement administrateur à tout moment, même si vous ouvrez une session sur le système en tant que tel.

Niveau d’intégrité
Windows prend maintenant en charge le libellé des processus et des objets avec des niveaux d’intégrité. Ces niveaux d’intégrité sont en fait également représentés comme des ACE, mais pas dans le DACL. Ils font au lieu de cela partie de la liste de contrôle d’accès du système (SACL), avec quelques indicateurs spéciaux. Par exemple, l’indicateur NW est utilisé pour indiquer le blocage d’un processus à un niveau d’intégrité plus bas pour l’écriture vers un objet de niveau d’intégrité plus élevé (SDDL_NO_WRITE_UP). Mark Russinovich explique ceci en détail dans son article « Au cœur du Contrôle de compte d’utilisateur de Windows Vista » de ce numéro de TechNet Magazine.

Conclusion
Bien qu’il n’existe aucune modification dramatique et unique du contrôle d’accès dans Windows Vista, comme c’était le cas dans Windows 2000, de nombreuses petites modifications ont été mises en place. Individuellement, elles peuvent ne pas être particulièrement remarquables mais, prises dans leur ensemble, elles signifient en fait que vous devez reconsidérer une grande quantité des opérations d’administration de votre système. De plus, ces modifications prennent en charge plusieurs autres initiatives, notamment le Contrôle de compte d’utilisateur et le renforcement de la sécurité de service. Certains administrateurs pourront être particulièrement embêtés lorsqu’ils commenceront à utiliser Windows Vista. J’ai déjà vu des commentaires tels que « systèmes d’exploitation tyranniques » qui limitent la capacité de supprimer des parties du système d’exploitation qui, pour une raison ou une autre, semblent gênantes. Cependant, toutes ces modifications s’appuient sur des raisons solides et, si vous passez quelques temps à analyser ce qui a été fait, vous comprendrez très probablement pourquoi.

Jesper Johansson est architecte sécurité pour une grande entreprise de commerce électronique, responsable de la stratégie de sécurité des applications de toute la gamme de propriétés et de services. Il a travaillé dans la sécurité pendant 20 ans et a écrit de nombreux articles et de deux livres sur la sécurité. Lorsqu’il ne travaille pas sur la sécurité des informations, il enseigne la plongée sous-marine.


 S&#233;curit&#233;: Gestions des restrictions de mat&#233;riel &#224; l’aide de la Strat&#233;gie de groupe
Sécurité Jeremy Moskowitz

Gestions des restrictions de matériel à l’aide de la Stratégie de groupe
Vue d'ensemble:
  • Restriction des installations de matériel
  • Restriction de périphériques spécifiques
  • Restriction de classes de périphériques

Cela ne fait aucun doute : ces clés/disques USB au format de poche et autres gadgets multimédia amovibles peuvent faciliter votre vie personnelle mais rendre votre vie professionnelle plus difficile. Vous voulez disposer d’un moyen permettant de contrôler
les périphériques matériels pouvant être installés ou non. Heureusement, avec la Stratégie de groupe de Windows Vista™ et la prochaine version de Windows Server®, nom de code « Longhorn », vous avez la possibilité d’autoriser les souris USB et de rejeter les disques USB sur clé, autoriser les lecteurs de CD-ROM, mais pas les graveurs de DVD, ou encore d’autoriser Bluetooth mais pas PCMCIA.
Deux sections de la stratégie de groupe peuvent vous aider à rendre votre matériel plus sûr : Configuration de l’ordinateur | Modèles d’administration | Système | Accès au stockage amovible (voir la figure 1) et Configuration de l’ordinateur | Modèles d’administration | Système | Installation de périphérique | Restrictions d’installation de périphérique (voir la figure 2).
Figure 1 Restrictions matérielles prédéfinies de la Stratégie de groupe
Figure 1 Restrictions matérielles prédéfinies de la Stratégie de groupe
Figure 2 Personnaliser les types de matériels dont vous voulez restreindre l’utilisation
Figure 2 Personnaliser les types de matériels dont vous voulez restreindre l’utilisation
Le premier ensemble (Accès au stockage amovible) est assez explicite : Si vous activez un paramètre de stratégie pour ce type de stockage amovible (CD/DVD, disquette, etc.), vous pouvez, si vous le souhaitez, interdire ensuite la lecture et/ou l’écriture sur l’ensemble de ce type de périphérique. Mais il ne dispose pas tout à fait des super-pouvoirs dont dispose Restrictions d’installation de périphérique.
Il existe dans Accès au stockage amovible des groupes de paramètres de stratégie nommés Classes personnalisées : Refuser les Classes personnalisées et l’accès de lecture : Refuser l’accès en écriture. Ceci semble parfait, mais la stratégie Accès au stockage amovible n’empêche en fait pas l’installation des pilotes (le pilote de la classe est déjà installé lorsque le matériel est détecté). La stratégie empêche en fait la lecture ou l’écriture sur le périphérique. Dans la section suivante, lorsque je détaillerai les paramètres de la stratégie Restrictions d’installation de périphérique, je verrouillerai l’utilisation de l’intégralité du pilote.

Obtenir un descripteur des classes et des numéros d’identification
Commençons par le commencement : Vous devez savoir ce que vous voulez restreindre. Vous pouvez avoir les idées larges ou commencer petit. C’est-à-dire que vous pouvez limiter une « classe » spécifique de périphériques ou être extrêmement spécifique et restreindre un seul type de matériel. Vous pouvez également faire le contraire et autoriser uniquement des classes de périphériques spécifiques, comme les souris USB. Voici l’astuce, toutefois : pour être vraiment efficace, vous devrez traquer le matériel à restreindre.
Par conséquent, si vous voulez qu’aucun des pilotes de joystick ne puisse être installé et que seules les souris USB puissent être installées, vous devrez vous procurer un joystick et une souris USB. Une autre solution consiste à utiliser Internet pour rechercher le numéro d’identification de matériel, le numéro d’identification compatible ou la classe de périphérique. Cependant, il vous sera beaucoup plus facile de disposer physiquement de l’un des périphériques. Ainsi, vous pourrez le présenter à votre ordinateur et constater par vous-même le numéro d’identification de matériel, le numéro d’identification compatible ou la classe de périphérique. Une fois que vous posséderez ces informations, vous saurez précisément comment l’interdire (ou le laisser disponible).
Dans l’exemple suivant, j’interdis une famille spécifique de cartes audio : la famille Creative AutoPCI ES1371/ES1373. Si vous voulez interdire quelque chose d’autre (comme des périphériques USB spécifiques, des ports USB, etc.), inspirez-vous de cet exemple et remplacez la carte par le périphérique de votre choix.
Démarrez le gestionnaire de périphériques sur un ordinateur sur lequel les périphériques matériels sont déjà installés. Lorsque vous aurez trouvé le périphérique, cliquez dessus avec le bouton droit et sélectionnez Propriétés, puis l’onglet Détails. Vous verrez par défaut une « Description du périphérique ». Bien qu’elle soit intéressante, celle-ci n’est pas utile. Sélectionnez la liste déroulante Propriétés et choisissez « Numéros d’identification du matériel » comme à la figure 3.
Figure 3 Onglet Détails du périphérique
Figure 3 Onglet Détails du périphérique
La page Numéros d’identification du matériel vous indique, de haut en bas, le numéro d’identification le plus spécifique au moins spécifique. Si vous observez de près l’élément le plus haut dans la liste Numéros d’identification du matériel, vous verrez que cette carte audio est plus particulièrement une carte audio ES1371 Rev 2. Ces informations sont plutôt détaillées. En descendant dans la liste, la description devient moins spécifique, pour englober toute la famille.
Qui plus est, vous pouvez modifier Propriété pour utiliser Numéros d’identification compatible. Ces derniers décrivent également le matériel et sont considérés comme moins spécifiques que ce que vous trouverez dans Numéros d’identification du matériel. Vous pourriez choisir d’utiliser les informations de Numéros d’identification compatible pour essayer de capturer davantage de périphériques similaires dans votre liste d’interdiction (car elles sont moins spécifiques et peuvent en fait offrir un plus grand nombre de résultats). En contrepartie, il est possible que vous restreigniez quelque chose que vous ne souhaitez pas restreindre.
Pour terminer, vous trouverez la catégorie la moins spécifique en sélectionnant Classe de périphérique dans la liste déroulante Propriété. Dans mon cas, la carte audio est indiquée comme étant simplement Multimédia. Toutefois, de nombreux éléments peuvent être considérés comme Multimédia et, ici encore, moins vous serez spécifique et plus vous devrez être prudent.
Une fois que vous aurez décidé de la valeur à utiliser, cliquez dessus avec le bouton droit, sélectionnez Copier et collez-le dans le Bloc-notes pour le sauvegarder. Il est important de le copier tel qu’il est affiché, car la valeur devra être entrée avec précision dans les étapes suivantes. Les caractères majuscules et minuscules de la valeur doivent être transférés avec exactitude.
Pour ceux qui préfèrent le style commando de ligne de commande au lieu de l’utilisation du Gestionnaire de périphériques pour la capture des numéros d’identification du matériel ou des classes de périphérique, l’utilitaire de ligne de commande Devcon est disponible à l’adresse support.microsoft.com/kb/311272. Notez par ailleurs que Microsoft possède de nombreux numéros d’identification de classes courantes pouvant être utiles si vous ne disposez pas de l’accès physique au périphérique. Vous trouverez des informations sur ceux-ci à l’adresse go.microsoft.com/fwlink/?LinkId=52665.

Contrôle de l’accès au matériel à l’aide de la Stratégie de groupe
Bien que nous nous apprêtions à explorer tous les paramètres de stratégie de Configuration de l’ordinateur | Modèles d’administration | Système | Installation de périphérique | Restrictions d’installation de périphérique (voir la figure 2), un seul sera véritablement nécessaire pour terminer cet exemple initial.
Pour commencer, créez un Objet de Stratégie de groupe (GPO) et liez-le à l’unité d’organisation (UO) (ou un domaine, etc.) contenant les ordinateurs exécutant Windows Vista et que vous voulez contrôler. Modifiez maintenant le GPO et accédez à Configuration de l’ordinateur | Modèles d’administration | Système | Installation de périphérique | Restrictions d’installation de périphérique | Empêcher l’installation de périphériques correspondant à l’un de ces numéros d’identification de périphériques. Sélectionnez Activé dans le paramètre de stratégie, cliquez sur Afficher (également dans le paramètre de stratégie) et sélectionnez Ajouter dans la boîte de dialogue « Afficher le contenu ». Ensuite, dans la boîte de dialogue « Ajout d’élément », collez les informations que vous avez enregistrées auparavant sur le périphérique, comme indiqué à la figure 4.
Figure 4 Collez le numéro d’identification de périphérique pour capturer avec précision la description
Figure 4 Collez le numéro d’identification de périphérique pour capturer avec précision la description
Il existe toutefois un inconvénient. Si le périphérique est déjà installé sur un ordinateur, ce dernier ne le désinstallera pas et n’y restreindra pas l’accès comme par magie. Par conséquent, si vous devez restreindre l’accès à un matériel, il est souhaitable de l’effectuer tôt au cours du déploiement de Windows Vista. Notez cependant que Windows Vista effectue une vérification chaque fois qu’un périphérique est supprimé puis réinstallé. Les éléments tels que les lecteurs USB de poche (qui sont enlevés puis réinsérés) sont ainsi d’excellents exemples pour ce processus. Puisque Windows Vista effectue uniquement la revérification lorsque le périphérique est réintroduit, le périphérique est restreint à ce moment-là (même si le pilote de périphérique a été initialement chargé sur l’ordinateur). Un problème plus difficile a trait aux périphériques livrés avec un ordinateur et n’étant pas enlevés puis réintroduits. Pour ces périphériques, il n’existe aucune solution évidente à première vue.
Lorsque vous allumez un ordinateur sur lequel un périphérique matériel n’a auparavant jamais été connecté, Windows essaie d’installer le pilote et fournit des informations sur son état pendant sa progression. Si vous avez configuré une stratégie restreignant de tels périphériques, vous obtiendrez un résultat tel que celui de la figure 5.
Figure 5 Une installation de périphérique est empêchée
Figure 5 Une installation de périphérique est empêchée

Autres restrictions de matériel
Dans l’exemple ci-dessus, nous avons interdit un seul périphérique. Si vous l’aviez souhaité, vous auriez pu prendre le chemin inverse et restreindre par défaut tous les matériels puis en autoriser quelques-uns. Encore une fois, vous pouvez voir une liste de ces paramètres de stratégie à la figure 2, qui illustre la branche Configuration de l’ordinateur | Modèles d’administration | Installation de périphérique | Restrictions d’installation de périphérique de Stratégie de groupe. Vous pouvez choisir parmi plusieurs paramètres.
Vous trouverez tout d’abord « Autoriser les administrateurs à passer outre les stratégies de restriction d’installation de périphériques ». Par défaut, les administrateurs locaux de Windows Vista doivent observer les restrictions qui sont mises en place. Si vous activez ce paramètre, les administrateurs locaux peuvent outrepasser les restrictions et installer tous les matériels de leur choix.
L’option « Permettre l’installation de périphériques à l’aide de pilotes correspondant à ces classes d’installation de périphériques » est la suivante. En entrant des descriptions de périphériques dans ce paramètre de stratégie, vous autorisez expressément ces périphériques matériels à être installés sur le système. Notez que ce paramètre de stratégie s’applique seulement aux classes d’installation, pas aux numéros d’identification de périphériques (tels que ceux utilisés dans l’exemple).
Pour obtenir l’effet inverse, vous pouvez définir « Empêcher l’installation de périphériques à l’aide de pilotes correspondant à ces classes d’installation de périphériques ».
Les deux paramètres « Afficher un message personnalisé lorsque l’installation est empêchée par une stratégie (texte de bulle) et (titre de bulle) » vous aident à personnaliser le message, comme à la figure 5.
Comme mentionné plus haut, la méthode la moins spécifique pour la description du matériel est basée sur la classe de matériel. Notez par ailleurs que le paramètre de stratégie « Autoriser l’installation de périphériques correspondant à l’un de ces numéros d’identification de périphériques » ne tient pas compte des descriptions de numéros d’identification de classe. Pour utiliser les descriptions de numéros d’identification de classe, utilisez « Permettre l’installation de périphériques à l’aide de pilotes correspondant à ces classes d’installation de périphériques » ou « Empêcher l’installation de périphériques à l’aide de pilotes correspondant à ces classes d’installation de périphériques ». Cette dernière stratégie s’utilisera de préférence avec le paramètre « Empêcher l’installation de périphériques non décrits par d’autres paramètres de stratégie ». En empêchant tout (par défaut) et en utilisant ensuite ce paramètre, vous pouvez spécifier précisément les périphériques que vous voulez autoriser.
Dans l’exemple, j’ai utilisé la stratégie « Empêcher l’installation de périphériques correspondant à l’un de ces numéros d’identification de périphériques » pour interdire un type spécifique de matériel en fonction du numéro d’identification de périphérique. Si vous vouliez implémenter des restrictions en utilisant les classes de périphérique, vous devriez tirer parti d’autres paramètres de stratégie spécifiques tels que « Permettre l’installation de périphériques à l’aide de pilotes correspondant à ces classes d’installation de périphériques » ou « Empêcher l’installation de périphériques à l’aide de pilotes correspondant à ces classes d’installation de périphériques ».
« Empêcher l’installation de périphériques amovibles » est une méthode rapide, générique pour interdire tout périphérique se décrivant comme amovible, y compris les périphériques USB. Ce paramètre est plutôt général. Il est donc préférable de ne pas l’utiliser trop souvent. Utilisez plutôt les techniques décrites plus haut pour obtenir des numéros d’identification de périphériques modérément restrictifs et les verrouiller de manière spécifique.
Enfin, « Empêcher l’installation de périphériques non décrits par d’autres paramètres de stratégie » est le paramètre de stratégie fourre-tout qui interdit fondamentalement tout matériel, à moins que vous n’ayez décidé en particulier que tel ou tel élément puisse être installé. Cette stratégie, conjointement aux diverses stratégies « Autoriser » (telles qu’« Autoriser l’installation de périphériques correspondant à l’un de ces numéros d’identification de périphériques ») forme un outil vraiment puissant pour autoriser uniquement le matériel que vous voulez dans votre environnement.

Conclusion
La Stratégie de groupe de Windows Vista possède plusieurs nouveaux super-pouvoirs, qui sont extrêmement utiles pour autoriser uniquement le matériel que vous voulez dans votre environnement. Implémentez simplement vos paramètres de stratégie tôt au cours de votre déploiement, pour que le matériel que vous ne voulez pas sur votre réseau ne réussisse jamais à se connecter.
Interview de Michael Dennis, responsable de programme de la Stratégie de groupe chez Microsoft
J’ai récemment eu l’opportunité d’interviewer Michael Dennis, qui est à la barre chez Microsoft du vaisseau Stratégie de groupe, depuis ses débuts. Michael va quitter l’équipe Stratégie de groupe pour poursuivre d’autres opportunités chez Microsoft. Je me suis entretenu avec Michael pour réfléchir aux neuf dernières années de la Stratégie de groupe, ce qu’il en a été et ce qu’il en adviendra.

Jeremy Moskowitz Michael, je pense que beaucoup de gens aimeraient savoir ce que vous avez accompli de meilleur durant votre temps passé à la tête de l’équipe Stratégie de groupe de Microsoft.

Michael Dennis Mes plus grands accomplissements ne sont pas récents, ils datent de l’époque à laquelle nous nous concentrions sur ce qui allait porter le nom de Stratégie de groupe. Nous avions déjà la Stratégie système dans Windows NT® 4.0 ; nous l’avons donc examinée et nous nous sommes penchés sur ses problèmes. Puisque cela se passait pendant la période de développement d’Active Directory®, nous avons cherché comment améliorer la gérabilité des clients et des serveurs.
Le fait que cette Stratégie de groupe allait être intégrée dans une hiérarchie et que cela n’avait jamais été fait auparavant était pour nous particulièrement important. Nous nous sommes donc concentrés sur l’infrastructure fondamentale, les processus clients et l’intégration à Active Directory.
Le produit dérivé de notre meilleur accomplissement a également été notre pire accomplissement. Ceci parce que l’interface utilisateur graphique que nous avons livrée avec Windows 2000 était problématique. Il fallait littéralement avoir un doctorat en Stratégie de groupe pour l’utiliser efficacement, car les administrateurs devaient connaître l’intégralité de son fonctionnement. Il aurait été mieux, à cette époque, de créé la Console de gestion des stratégies de groupe (GPMC) et le Jeu de stratégie résultant (RSoP) et de les livrer (c’était ce qui était prévu).

JM Quels éléments auriez vous souhaité inclure dans l’environnement de Stratégie de groupe ?

MD La bonne nouvelle est que les éléments que je voulais depuis la sortie de la version Windows 2000 sont maintenant dans Windows Vista (comme RSoP, la GPMC, les paramètres augmentés, etc.). J’aurais préféré avoir mis ces choses en place beaucoup plus tôt.
En outre, je souhaiterais que l’infrastructure de Stratégie de groupe puisse facilement être étendue par les partenaires. Notre modèle d’extension côté serveur/côté client nécessite une bonne quantité de travail de la part des développeurs. Cependant, on peut également considérer que notre structure de modèle d’ADM/ADMX fournit une infrastructure facilement extensible. Toutefois, il serait encore mieux que cette partie du système permette aux gens d’étendre plus de types de paramètres.
J’aurais également souhaité que les rapports de GPMC soient plus extensibles pour les partenaires et les développeurs d’outils tiers. Il s’agit d’un sujet sur lequel les fournisseurs d’outils tiers se sont beaucoup exprimés.

JM Pouvez-vous nous donner des informations que les gens ne savent pas sur l’équipe Stratégie de groupe ?

MD La position de l’équipe Stratégie de groupe dans l’environnement global n’est pas toujours claire dans l’esprit des gens. On pense généralement que nous créons l’infrastructure, le transport et les éléments côté serveur et client. En fait, dans Windows Vista seul, nous avons fait équipe avec environ 120 équipes différentes de Microsoft pour mettre en place les nouveaux paramètres pour cette version.
Les lecteurs doivent prendre note du fait que cette Stratégie de groupe n’est pas responsable des problèmes de ralentissement de système au démarrage ou à l’ouverture de session. C’est la charge utile de la Stratégie de groupe qui est la cause d’un possible ralentissement. Si vous ordonnez à la Stratégie de groupe d’effectuer une tâche extrêmement lourde, elle le fera. Par exemple, si vous lui ordonnez d’installer Microsoft Office sur les ordinateurs au cas par cas, pas de problème. Mais sachez qu’elle fera exactement ce que vous lui avez demandé, c’est-à-dire installer l’intégralité d’Office avant que vous obteniez une invite d’ouverture de session. Est-ce qu’il s’agit d’un ralentissement ? Sans aucun doute, mais du point de vue de l’administrateur qui l’a déployé, c’est précisément ce qui est attendu du système.

JM Quelle est la chose dont vous êtes le plus fier en ce qui concerne l’utilisation de la Stratégie de groupe ?

MD Ces jours-ci, j’aime particulièrement montrer certains nouveaux paramètres qui ont été intégrés à Windows Vista. Les paramètres des périphériques amovibles (pour restreindre des éléments tels que les clés USB, etc.) sont des paramètres qui ont été vivement demandés. Il existe à peu près 2 400 paramètres disponibles dans Windows Vista, ce qui permet un niveau significatif de contrôle pour les administrateurs. J’aime demander aux clients ce qu’ils veulent contrôler et leur montrer ensuite comment le faire.

JM Pourquoi êtes-vous passés des fichiers ADM aux fichiers ADMX ?

MD Techniquement, nous n’avions pas besoin de le faire pour profiter de la nouvelle fonctionnalité de magasin central de Windows Vista. La raison principale de la conversion vers ADMX était de nous permettre de prendre en charge plusieurs langues de manière appropriée.
Auparavant, dans les environnements multilingues, le contenu des fichiers ADM d’un GPO était souvent remplacé par inadvertance par celui d’un autre langage. Du point de vue historique, nous avons emprunté le format ADM à Windows NT 4.0, qui l’avait emprunté à Windows 98, qui l’avait à son tour emprunté à Windows 95. Si XML avait alors existé, il aurait été pratique pour notre format de fichier.
Cependant, maintenant que nous avons XML, il est devenu plus facile de prendre en charge de multiples langages, et celui-ci présente des opportunités futures pour apporter des améliorations au Registre et aux paramètres avec notre schéma de langage.

JM Quel a été le plus grand défi interne que vous avez eu à surmonter pendant votre travail avec l’équipe GP ?

MD Le plus grand problème continu de l’équipe est de faire en sorte que d’autres composants de Windows aient des fonctionnalités utilisables avec la stratégie.
L’équipe X pourrait répondre &« Nous avons tout juste créé cette nouvelle fonctionnalité géniale. Pourquoi est-ce que quelqu’un voudrait la désactiver ? »&, ce que nous comprenons. Mais nous avons travaillé sur beaucoup de ces problèmes.
Il existe également des défis techniques en ce qui concerne l’activation de certaines choses par la stratégie, comme par exemple le nouveau Pare-feu Windows avec fonctions avancées de sécurité (WFAS). WFAS a été particulièrement difficile. Il n’est pas facile ou évident de lui permettre d’utiliser correctement la stratégie. L’interface que l’équipe WFAS a créée pour Windows Vista est superbe, mais il a été difficile de la créer correctement.
Dans les versions de Windows antérieures à Windows Vista, les équipes produit n’ont pas toujours réfléchi à l’utilisation de la stratégie avec leurs composants. Toutefois, durant le développement de Windows Vista, de nombreuses équipes nous ont demandé comment y parvenir. Incroyable !
JM Que vous réserve l’avenir ?

MD Je vais faire partie de l’équipe &Mobile Information Worker&, qui est responsable des Smartphones, des Pocket PC, etc. Mon rôle sera d’étendre certaines technologies d’administration de Windows Server System aux périphériques Windows Mobile®.
Je tâcherai de mettre en œuvre la même vision et la même passion envers la gérabilité et de les appliquer à ce nouvel environnement. En attendant, je laisse l’équipe Stratégie de groupe dans une situation remarquable pour que les choses continuent à avancer sans moi.

JM Voulez-vous ajouter quelque chose d’autre à l’attention des lecteurs ?

MD Tout au long du développement de la Stratégie de groupe, rencontrer les clients et comprendre véritablement ce qu’ils souhaitaient faire a constitué une étape importante. Si les clients ont une opinion bien structurée des scénarios qu’ils aimeraient que la Stratégie de groupe adopte et possèdent une raison commerciale pour leur utilisation, ils doivent nous en faire part.
Nous avons un bon mécanisme de commentaires disponible pour tous à l’adresse WindowsServerFeedback.com. Cherchez le bouton de la Stratégie de groupe (Group Policy).
Si vos collègues peuvent vous indiquer&« Voici mon problème, voici mon argumentation commerciale, voici ce que je veux que le système fasse et pourquoi je le veux... »&, ce genre d’information nous est très, très utile. Les preneurs de décisions quant au futur de la Stratégie de groupe consultent tous les commentaires qui proviennent de cette source.
Encore une fois, si vous souhaitez que la Stratégie de groupe progresse, faites-nous connaître vos besoins. Mais, s’il vous plaît, ne nous dites pas simplement &« Nous avons besoin d’un paramètre de stratégie qui effectue ceci... »& sans nous dire pourquoi. La partie &« Comment faire ? »& est notre travail. Ce que l’équipe de la Stratégie de groupe doit vraiment connaître est le &« Pourquoi »&.
JM Merci d’avoir pris le temps de discuter avec nous de votre expérience dans l’équipe de la Stratégie de groupe de Microsoft. Bonne continuation !
MD Merci Jeremy.

Jeremy Moskowitz, MCSE et MVP de Group Policy, administre GPanswers.com, un forum communautaire sur la Stratégie de groupe. Il est responsable d’un ensemble d’ateliers de formation intensive sur la Stratégie de groupe. Son dernier ouvrage est Group Policy : Management, Troubleshooting and Security (Sybex, 2007). Vous pouvez contacter Jeremy à l’adresse www.GPanswers.com.


 S&#233;curit&#233;: Quatre technologies de s&#233;curit&#233; dont chaque organisation informatique devrait disposer
Sécurité Matt Clapham and Todd Thompson

Quatre technologies de sécurité dont chaque organisation informatique devrait disposer
Vue d'ensemble:
  • Tableau de bord de gestion des risques
  • Logiciels anti-programme malveillant
  • Détection d’anomalie réseau

Lorsqu’il s’agit de sécurité informatique, la plupart des entreprises ont à peu près les mêmes problèmes à résoudre. Microsoft n’est pas une exception. Nous avons passé deux ans avec l’équipe de conformité et de gestion des risques dans
MMS (Microsoft® Managed Solutions). (Voir « Microsoft recharge le service informatique d'Energizer » pour plus d’informations sur MMS.)
L’équipe de conformité et de gestion des risques doit définir, surveiller et corriger les risques au sein de tous les environnements MMS (aussi bien pour les services client que pour la coordination d’infrastructure). Précédemment, notre responsable, Arjuna Shunn, a reconnu que nous avions besoin d’une solution technologique offrant les contrôles et la surveillance souhaités d’une manière cohésive et centralisée. Les technologies abordées ici sont le résultat direct de nos toutes premières idées, associées à deux ans d’expérience utilisant divers produits Microsoft et produits de parties tierces au sein de nos opérations.
Tout d’abord, nous avions besoin de technologies de sécurité pouvant couvrir les trois types de contrôle primaires (prévention, détection et correction) tout en fournissant audits et rapports. Nous avons vu que cette série d’outils se divise en quatre catégories : tableau de bord de gestion des risques, logiciels anti-programme malveillant, détection d’anomalie réseau et gestion de configuration souhaitée. Nous avons tenté d’inclure au moins un représentant de chacune de ces catégories dans nos opérations de gestion des risques. Et nous avons remarqué qu’en tirant profit des technologies de l’une de ces quatre catégories, l’équipe de sécurité informatique pouvait atteindre un équilibre raisonnable entre le coût et l’efficacité.
Nos deux principales opérations de gestion des risques (réponse relative à un incident lié à la sécurité et gestion de conformité) ont grandement profité de cette approche. Mais nous devons poursuivre nos recherches pour atteindre la coordination souhaitée entre ces outils. Une série cohésive de technologies peut offrir encore plus au niveau de l’efficacité opérationnelle, mais malheureusement l’industrie ne dispose pas encore de ce système intégré.
Heureusement, tout n’est pas perdu pour les équipes de sécurité informatique ; tout n’est qu’une question de temps avant que les quatre systèmes fonctionnent ensemble et interagissent pour le plus grand effet. Lorsque ces systèmes fonctionneront ensemble, non seulement, ils permettront la surveillance active de la sécurité du système, mais ils seront également très utiles lors d’audits ou autres opérations informatiques de routine. Dans cet article, nous décrivons la fonction idéale de chaque système, en l’illustrant de quelques exemples tirés de notre utilisation de service d’exécution.

Tableau de bord de gestion des risques
À notre avis, un tableau de bord de gestion des risques (RMD, Risk Management Dashboard) est essentiel. Il s’agit de la technologie la plus importante pour le fonctionnement de l’équipe de sécurité informatique. Les risques liés à la confidentialité, l’intégrité, la disponibilité et la responsabilité au sein d’une entreprise sont souvent contrôlés par des systèmes et processus disparates sans interface unique permettant de regrouper les données, les mettre en corrélation et remédier aux risques. En outre, les exigences liées aux réglementations spécifient des niveaux de transparence de données d’entreprise difficiles. Il n’existe pas encore de système rationalisé pour suivre facilement la stratégie, de la création à l’exécution d’entreprise. En témoignent les difficultés d’entreprise courantes lors d’acquisition, de corrélation, d’évaluation, de correction et de conformité de données. (Bien que la solution RMD présentée ici ne soit pas complète, System Center Operations Manager 2007, comme illustré à la figure 1, fournit une interface unique pour surveiller plusieurs ressources et rassembler les alertes associées.)
Figure 1 System Center Operations Manager 2007 offre une interface unique permettant d’afficher des alertes et de gérer des ressources depuis le réseau
Figure 1 System Center Operations Manager 2007 offre une interface unique permettant d’afficher des alertes et de gérer des ressources depuis le réseau
La saisie des données est entravée par une incapacité à regrouper et normaliser les données de sources disparates. Le regroupement de données est un véritable défi, étant donné qu’il nécessite de casser l’approche trop courante de collecte et de rapports de données. Même là où le regroupement de données est terminé, la normalisation continue de poser un défi encore plus grand parce qu’il est extrêmement difficile de mettre en place l’infrastructure courante nécessaire pour prendre en charge la normalisation de données. Sans cette normalisation, il est impossible de comparer des événements associés à la santé et la sécurité venant de différents systèmes de manière significative.
Pour exécuter l’automatisation nécessaire, le tableau de bord de gestion des risques doit avoir accès aux sources de données autres que les technologies de sécurité décrites ici. Beaucoup de données non relatives à la sécurité peuvent être utilisées pour déterminer les risques généraux. Les informations, telles que les journaux de routeur, le suivi des actifs, l’état de correctif, les utilisateurs actuellement connectés, les rapports de performances et les données de gestion des modifications peuvent tous fournir des informations pertinentes pour enquêter sur l’incident. Par conséquent, le système général doit pouvoir accéder à toutes ces données. Nous sommes conscients que même les infrastructures d’entreprise centrées Microsoft comprennent des technologies non Microsoft. Par conséquent, RMD doit accepter les sources des technologies non Microsoft via une interface courante.
Si les données peuvent être acquises et normalisées, l’étape suivante consiste à les mettre en corrélation. L’objectif consiste à mettre en corrélation une séquence d’événements (telle qu’un événement d’anomalie réseau, un événement de rapport antivirus et un événement de variance de configuration souhaité) à une pièce décisionnelle de données liées aux risques. Ceci nécessite un travail manuel intensif pour générer la logique de corrélation qui aura pour résultat d’alerter des risques de manière significative. Basée sur les technologies actuellement disponibles, cette logique de corrélation est difficile à atteindre.
L’évaluation de données requiert également un travail manuel intensif. Dans le cas où la corrélation survient, un analyste doit toujours observer les données mises en corrélation pour déterminer son efficacité. L’efficacité des données mises en corrélation ne peut pas être plus stricte que les règles sur lesquelles elle est basée. Ceci entraîne une analyse humaine supplémentaire des données mises en corrélation pour évaluer les risques de l’environnement informatique. Une infrastructure de gestion des risques claire et codée pourrait aider à réduire la quantité d’intervention manuelle requise pour atteindre un niveau de triage. Sans cette infrastructure, le développement d’une série de règles de corrélation pratique dans une mise en œuvre donnée est difficile.
Supposons qu’un système a atteint le point d’évaluation des risques, l’étape suivante est alors la correction automatisée. À l’heure actuelle, ceci n’est disponible qu’au sein de l’entreprise et n’est effectué que pour une série limitée de technologies, telle que la gestion de correctifs ou d’antivirus. La correction automatisée menée par le système RMD fournira à l’administration informatique une incroyable capacité de maintenir un niveau de risques informatiques acceptable. Lorsque plusieurs risques sont identifiés simultanément, la logique de corrélation devrait permettre de hiérarchiser la réponse à l’incident en fonction des données de classification des actifs.
Enfin, offrir la preuve de conformité à diverses exigences liées aux réglementations est un défi gigantesque pour les services informatiques et, comme nous l’avons mentionné, ce système devrait prendre en charge une telle fonctionnalité. Un système de gestion des risques centralisé associé à la stratégie pourrait être un grand avantage pour produire des rapports et la preuve de la conformité. Mais la stratégie doit spécifier plus que le pourquoi et le comment. Pour faciliter la correction automatisée, la stratégie doit être traduite en une série de normes que le tableau de bord peut contrôler, appliquer et en fournir des commentaires.
Pour résumer, on peut dire que le tableau de bord de gestion des risques est idéal pour fournir une interface unifiée permettant d’évaluer la santé de l’entreprise, la conformité liée à la stratégie et aux réglementations et les processus de gestion des risques. Cet objectif est atteint en associant les informations des produits et des sources relatives à la santé et la sécurité disparates en un affichage relatif aux risques cohésifs. Une bonne solution RMD doit pouvoir faire ce qui suit :
  • Regrouper, normaliser et mettre en corrélation les données à partir de sources disparates
  • Fournir le rassemblement automatisé des informations et l’évaluation des risques
  • Mapper les exigences de réglementations aux stratégies et prendre en charge les audits et les rapports
  • Fournir une infrastructure unifiée qui peut être modifiée pour correspondre aux besoins de l’entreprise
Le tableau de bord devrait autoriser les données à être organisées et affichées en fonction de leur signification, affichant, par exemple, les premiers incidents par type ou système source, les incidents en attente, les incidents résolus, et ainsi de suite. Il doit également vous permettre de plonger dans chaque élément de ligne de rapport pour plus de détails. Lorsque l’utilisateur observe un événement, il doit disposer d’un accès facile à toutes les données associées pour améliorer les décisions et permettre un temps de réaction plus rapide.
Nous devrions noter que RMD est également utile aux administrateurs ne faisant pas partie de l’équipe de sécurité. Étant donné que le tableau de bord englobe un affichage holistique de l’environnement, RMD peut servir de point central pour tout le personnel, pour afficher l’état actuel. Le tableau de bord peut, par exemple, alerter l’équipe de messagerie d’une attaque de refus de service au niveau de la passerelle SMTP. Alors qu’il s’agit d’un incident de sécurité pour l’équipe de gestion des risques, l’équipe de messagerie le verra comme un incident de disponibilité. Bien que l’équipe de messagerie ne soit peut-être pas responsable de la résolution d’un tel incident, elle souhaitera peut-être être au courant de tels incidents qui affectent les actifs gérés par l’équipe.

Technologies anti-programme malveillant
Un système de logiciels anti-programme malveillant est important pour protéger votre infrastructure des menaces imprévues masquées dans le code et les actions des utilisateurs. À l’heure actuelle, il existe en général deux types d’outils séparés pour se protéger contre les programmes malveillants : les antivirus et les logiciels anti-espions. (Windows® Defenser, par exemple, illustré à la figure 2, appartient à cette catégorie.) Tous deux préviennent, détectent et corrigent différents types d’infection. Cependant, tout n’est qu’une question de temps avant que ces deux types de protection soient unifiés dans une solution unique et qu’il n’y ait qu’un seul logiciel anti-programme malveillant sur un système.
Figure 2 Windows Defender aide à protéger le client des logiciels espions
Figure 2 Windows Defender aide à protéger le client des logiciels espions
Une solution de logiciels anti-programme malveillant minutieuse doit effectuer une surveillance en temps réel et une analyse de manière périodique. Elle doit signaler de façon centralisée dans un rapport les logiciels malveillants connus (y compris les virus, les logiciels espion et les rootkits) et les programmes malveillants inconnus basés sur les comportements risqués typiques. La technologie de logiciels anti-programme malveillant robuste observe les points d’entrée classiques (y compris le système de fichiers, le registre, le noyau, le navigateur, les messages électroniques et les applications connectées) via l’intégration avec le système d’exploitation et les applications.
De plus, une solution de logiciels anti-programme malveillant doit couvrir davantage que la sécurité d’hôte. Elle doit surveiller les services de collaboration et de messagerie courants où les fichiers infectés sont souvent transmis, tels que la messagerie instantanée et Sharepoint®. Elle doit également fournir une prévention automatisée en arrêtant les opérations (connues et suspectes) ainsi qu’analyser soigneusement les données utilisateur pour supprimer, par exemple, les macrovirus cachés dans les documents d’utilisateur et n’ayant pas encore infecté le système.
Il va sans dire que les logiciels anti-programme malveillant sont inutiles s’ils ne sont pas mis à jour. Le système doit garder ses signatures et ses systèmes de suppression à jour afin d’être toujours à la pointe des menaces les plus récentes. Si une menace émergente apparaît, le fournisseur devrait mettre en place des protections supplémentaires avant la prochaine apparition d’une menace. Une solution de logiciels anti-programme malveillant facile à gérer est également configurable et peut être mise à jour de manière centralisée.
Bien sûr, cette protection ne doit pas entraver les performances. Si les performances sont affectées, la productivité le sera aussi. Les utilisateurs essaieront peut-être même de désactiver la solution de logiciels anti-programme malveillant, n’ayant plus aucune protection.
Enfin, ne négligez pas l’importance des technologies auxiliaires pour aider le système anti-programme malveillant. Les pare-feux (limitant les privilèges utilisateur) et les autres stratégies améliorent également la protection contre les actions des utilisateurs et le code malveillant.

Détection d’anomalie réseau
Pendant qu’un anti-programme malveillant observe les systèmes, la détection d’anomalie réseau contrôle les chemins courants, observant les indicateurs de comportement suspect connu et rapportant ces informations au RMD pour correction. (Un pare-feu, par exemple, comme l’illustre la figure 3, serait inclus dans cette catégorie.) Les comportements suspects pourraient être des trafics d’attaques connus (un ver ou un refus de service) ou des données correspondant à un certain modèle (numéros de sécurité sociale américains) étant envoyés par message électronique.
Figure 3 Un pare-feu est une partie importante d’une solution de détection d’anomalie réseau
Figure 3 Un pare-feu est une partie importante d’une solution de détection d’anomalie réseau
Malgré les efforts du service de gestion informatique, tout réseau d’entreprise important devra, inévitablement, faire face à un incident dû à un logiciel malveillant. La détection d’anomalie réseau peut fournir un système d’avertissement en amont pouvant aider à accélérer la correction. De plus, les capacités de contrôle des données par la détection d’anomalie réseau et la possibilité d’identifier et d’empêcher les fuites d’informations sensibles sont des outils pratiques qui permettent de protéger les informations dans un environnement centré sur les fuites de données et la conformité aux réglementations.
Comme avec les technologies anti-programme malveillant, la détection d’anomalie réseau doit être constamment adaptée à la dernière série de menaces et aux types de données sensibles. Si tel n’est pas le cas, sa valeur est fortement diminuée. De plus, un bon système de détection d’anomalie réseau doit comprendre les véritables anomalies pour réduire le nombre d’affirmations incorrectes signalées. Si tel n’est pas le cas, les administrateurs pourraient commencer à négliger les rapports venant de la détection d’anomalie réseau, pensant que chacun est simplement une nouvelle fausse alerte.
Après quelques réglages ou une formation, le système de détection d’anomalie réseau devrait être capable de reconnaître les modèles d’utilisation du trafic typique et de les surveiller. Cette étape est importante étant donné que les nouveaux types de logiciels malveillants et autres attaques pourraient réapparaître légèrement modifiés dans les modèles d’utilisation. L’équipement de mise en réseau a un rôle significatif dans le système de détection d’anomalie réseau général, étant donné que la solution doit traiter les données des routeurs, des commutateurs et des pare-feux. Les alertes de système de détection d’anomalie réseau peuvent ensuite être traitées par le moteur de corrélation dans le RMD.
Il est possible pour les détecteurs d’anomalie réseau d’être intégrés aux logiciels anti-programme malveillant hôte ou au pare-feu, offrant un ensemble de protection dans lequel tous les ordinateurs inclus aident à la surveillance et éventuellement à la prévention des attaques avant leur propagation.

Gestion de configuration souhaitée
Un des défis les plus importants auquel les services informatiques des grandes entreprises doivent faire face consiste à conserver les systèmes correctement configurés. Le système doit être correctement configuré pour plusieurs raisons : gestion facile, évolutivité simplifiée, conformité assurée, verrouillage contre les diverses formes d’intrusion et productivité améliorée, pour n’en citer que quelques-unes. De nombreuses raisons s’intègrent à la sécurité.
La gestion de configuration souhaitée est une zone largement inexploitée dans la plupart des entreprises en raison de sa complexité et de ses coûts de démarrage. Mais les études montrent qu’à long terme, le maintien des systèmes permet des économies de coût et une fiabilité améliorée. Une solution de surveillance de configuration souhaitée (DCM) peut aider.
Un bon système DCM doit pouvoir analyser automatiquement le réseau pour s’assurer que les nouveaux systèmes sont déployés comme souhaité et doit également vérifier que les systèmes déjà en place sont toujours conformes. Que ce soit pour s’assurer du déploiement du dernier correctif ou pour réduire le nombre d’utilisateurs avec des privilèges de domaine, une solution DCM complète doit configurer les systèmes, les analyser et effectuer un rapport pour savoir si chaque configuration est proche de la configuration idéale. Les corrections peuvent être simples (telles que la réparation des nouveaux systèmes sur le réseau à mesure de leur déploiement) ou énergiques (telles que l’application des paramètres de messagerie électronique clientes pour les utilisateurs). La clé ici consiste à les associer aux stratégies de l’organisation et à la position des réglementations. (DCM peut également aider à identifier et supprimer l’infection de logiciels malveillants, étant donné que les types simples seront facilement détectés dans les résultats d’analyse.)
DCM est l’un des systèmes de données principaux au moteur de corrélation de RMD, et DCM fournit des détails importants sur la manière dont l’hôte en question passe de variant à normal. L’opportunité de ses données peut faire la différence entre un incident de sécurité à une alarme ou à cinq alarmes, ainsi un actif est analysé en fonction de sa valeur. Par exemple, un actif de faible sensibilité pourrait n’être analysé qu’une fois par mois, tandis qu’un actif de sensibilité modérée est analysé une fois par semaine et un actif de sensibilité élevée au moins une fois par jour.
Une installation de DCM constitue également une partie fondamentale du mécanisme d’une bonne protection de l’accès réseau. Ainsi, le système peut vérifier que tous les systèmes connectés sont correctement configurés et bloquer les systèmes nouveaux ou inconnus jusqu’à ce qu’ils soient validés. De plus, DCM doit rechercher les vulnérabilités de configuration (telles que les listes de contrôle d’accès faibles sur un partage) pour que les administrateurs puissent agir en conséquence.
Ne pensez pas que DCM s’applique uniquement aux hôtes, tels que les clients ou les serveurs. Les périphériques de mise en réseau et l’annuaire fondamental sont des candidats pour l’inclusion DCM. Si votre conception réseau est correcte et disponible, elle devrait être très simple pour que le système DCM idéal puisse appliquer les normes des périphériques associés. Imaginez les possibilités ! Au lieu d’ajuster des configurations de routeur manuellement, DCM peut contrôler la mise en œuvre. Ou disons qu’une série de paramètres Stratégie de groupe standard est associée à une série particulière de serveurs ou de clients. Le DCM devrait les contrôler et envoyer une alerte si les paramètres de domaine changent.
Les données recueillies par DCM devraient être assez solides pour être utilisées dans un audit informatique. Un bon DCM doit pouvoir gérer des modifications et des contrôles de conformité des réglementations pour que les audits puissent être résolus presque en continu. Par exemple, une de nos vérifications de contrôle de routine consiste à vérifier que l’appartenance de l’administrateur local sur les serveurs MMS n’a pas été modifiée. L’objectif de DCM consiste à faire appliquer cette règle.
Même si votre service informatique n’est pas prêt pour un système DCM qui se corrige automatiquement, une variation connue en tant que surveillance de configuration souhaitée peut toujours être déployée et offrir de bons résultats. Ceci offre également des rapports et des alertes relatifs aux problèmes de configuration, mais les mêmes économies d’échelle ne sont pas nécessairement atteintes étant donné que la correction est en grande partie manuelle. Cependant, la notification et les données dont RMD a besoin seront disponibles pour une mise en corrélation.
Gardez ce qui suit à l’esprit. DCM, aux formats que je viens de décrire, a dû être étendu aux éléments de configuration importants minimaux associés aux données de collecte d’actifs standard. Autrement, il peut empiéter sur la flexibilité dont l’équipe informatique a besoin. Si les repères de configuration DCM se démodent, DCM sera rapidement considéré comme une taxe de fonctionnement au lieu d’un outil utile. Il est primordial que vous restiez informé des dernières nouveautés pour savoir comment configurer les actifs de manière optimale. De plus, nous pensons que le système DCM comprend des mises à jour régulières de ses livres de configuration selon les meilleures pratiques pour l’actif ou l’application en question.

Conclusion
Que vous le génériez en interne ou l’achetiez chez un fournisseur réputé, le tableau de bord est essentiel, fonctionnant en tant qu’outil principal de votre équipe pour la réponse aux incidents. L’anti-programme malveillant est également essentiel, pour vous protéger des menaces qui se multiplient au quotidien. La détection d’anomalie réseau est sur le point de changer pour passer de la détection d’intrusion hôte ou des signatures de logiciels malveillants à l’inclusion de la découverte de fuite de données. Cette dernière fonction peut permettre d’éviter la prochaine fuite réseau. La gestion de configuration souhaitée, bien qu’elle soit une nouveauté, sera bientôt une fonctionnalité de surveillance et de maintien des configurations. Sans tenir compte des fournisseurs de ces outils, vous devez disposer d’au moins une de ces quatre catégories !
En fonction de ce que nous avons vu jusqu’à maintenant, pas un seul fournisseur (même Microsoft) n’offre de solution holistique unique qui résout chacun de ces quatre espaces. C’est à vous de rechercher la sélection de produits qui conviendra le mieux à vos besoins spécifiques. Avec cet article, nous souhaitons simplement offrir un aperçu de ce que vous devez prendre en considération, ce que vous devriez envisager d’atteindre et quelle sera la solution idéale.

Matt Clapham est ingénieur en sécurité dans le groupe Infrastructure et sécurité du service informatique de Microsoft. Il a précédemment travaillé pendant deux ans dans l’équipe de conformité et de gestion des risques dans MMS (Microsoft Managed Solutions).
Todd Thompson est ingénieur en sécurité dans le groupe Infrastructure et sécurité du service informatique de Microsoft. Il a précédemment travaillé pendant deux ans dans l’équipe de conformité et de gestion des risques dans MMS (Microsoft Managed Solutions).


 S&#233;curit&#233;: Un nouvel outil puissant pour la gestion des certificats
Sécurité Kevin Dallmann

Un nouvel outil puissant pour la gestion des certificats
Vue d'ensemble:
  • Architecture ILM-CM
  • Administration et modèles
  • Création d’un flux de travail

Vous travaillez tranquillement lorsque soudain vous recevez un appel de votre équipe de support technique : un certificat a expiré sur l’un de vos systèmes de production. Le système s’est arrêté, et votre entreprise perd de la productivité (et de l’argent) jusqu’à ce que vous renouveliez le certificat.
Si vous êtes chargé de gérer un environnement à infrastructure de clé publique (PKI), je suis certain que vous avez été surpris par l’expiration soudaine d’un certificat. Oubliez votre journée tranquille.
Lorsque Microsoft a ajouté les services PKI dans Windows® 2000 et Windows Server® 2003, les sociétés ont pu mettre en œuvre, à moindres coûts, leur propre environnement PKI interne. Malheureusement, les services PKI Microsoft® ne pouvaient pas gérer le cycle de vie des certificats générés. Cependant, Microsoft a récemment acquis un produit de gestion des certificats puis édité Identity Lifecycle Manager (ILM), qui associait la gestion des certificats aux fonctionnalités de fourniture et de contrôle d’identité de Microsoft® Identity Integration Server (MIIS). Cet article explique comment ILM peut aider à gérer les certificats et les cartes à puce pour votre organisation.

Architecture ILM-CM
Le noyau de l’architecture ILM Certificate Management (ILM-CM) est le serveur ILM-CM et ses composants associés (voir la figure 1). Le serveur ILM-CM peut être installé sur un serveur unique configuré pour créer une interface avec une ou plusieurs autorités de certification (CA). ILM-CM a besoin de SQL Server™, qui stocke les informations des certificats, les stratégies et autres données associées utilisées pour gérer votre environnement de certificats. Pour gérer les utilisateurs et les autorisations de sécurité, le serveur ILM-CM a également besoin d’Active Directory®. Voir la figure 2 pour les versions et les composants requis.
Figure 2 Prise en charge de l’infrastructure ILM-CM (Close Figure 2)

Composants | Versions
Active Directory | Windows Server 2003
Serveur de base de données | SQL Server 2000 SP3 ou supérieur ou SQL Server 2005
Autorité de certification | Windows Server 2003 Enterprise Edition ou Data Center Edition
SMTP | Serveur SMTP
Figure 1 Architecture ILM-CM
Figure 1 Architecture ILM-CM
Une fois l’environnement ILM-CM entièrement installé, toutes les requêtes de certificat communiquent avec le serveur ILM-CM. Le serveur ILM-CM est chargé de stocker toutes les informations associées aux certificats dans la base de données de SQL Server, qui peuvent être utilisées pour la signalisation de certificats, les alertes et la gestion d’un environnement de flux de travail.
L’architecture logicielle ILM-CM comprend trois parties de haut niveau : le serveur ILM-CM, les plug-in CA et les composants côté client. Le logiciel serveur peut être installé et exécuté sur une CA ou sur un serveur principalement utilisé pour ILM-CM. Le serveur ILM-CM communique ensuite avec les CA, la base de données de SQL Server et Active Directory. Le serveur dispose également d’un portail Web utilisé par les gestionnaires de certificats pour configurer les stratégies de certificat et les flux de travail, et par les abonnés aux certificats pour demander et renouveler les certificats logiciels.
Pour que la CA communique avec le serveur ILM-CM, des modules de sortie et de stratégie ILM-CM doivent être installés et configurés sur chaque CA que vous voulez gérer. Ces deux modules servent à enregistrer les informations de certificat dans la base de données. Lorsqu’un certificat est émis par une CA, le module de sortie est chargé d’envoyer cette information au serveur ILM-CM, qui à son tour enregistre les informations de certificat dans la base de données.
Si vous avez l’intention de gérer des cartes à puce dans votre environnement, vous devez installer le logiciel client de carte à puce ILM-CM. Ce logiciel est nécessaire sur tout ordinateur client qui doit interagir avec le serveur ILM-CM.

Installation d’ILM-CM
L’installation du serveur ILM-CM est en fait assez simple : un assistant vous guide dans la procédure. Mais avant d’exécuter l’assistant, vous devez vous occuper de plusieurs fonctions de pré-installation.
La première chose dont ILM-CM a besoin est Active Directory et une extension de schéma ILM-CM. L’extension de schéma ajoute des attributs de sécurité Microsoft .NET Framework supplémentaires dont ILM-CM a besoin pour mettre en œuvre les modèles de profil.
Vous devez également installer .NET Framework 2.0, et les composants susmentionnés (SQL Server, CA et serveur SMTP) doivent également être en place. Si ILM-CM est installé sur un serveur séparé de la CA, vous devez installer les modules ILM-CM sur les CA en exécutant l’Assistant d’installation ILM-CM sur les CA. Une fois l’installation terminée, vous devriez pouvoir connecter le portail ILM-CM en indiquant http://hostname/CLM dans votre navigateur.
Pour permettre la notification d’expiration/de renouvellement de certificat, vous devez configurer le service ILM-CM sur le serveur ILM-CM. Commencez par créer un compte approprié dans Active Directory. Entrez dans les services ILM-CM et ajoutez ce compte comme compte d’ouverture de session. Ajoutez ensuite cet utilisateur aux administrateurs locaux et le groupe IIS_WPG dans le serveur ILM-CM, de même que le « Agir en tant que partie du système d'exploitation, Générer des audits de sécurité et Remplacer un jeton de niveau processus » en utilisant les stratégies de groupe. Une fois le service ILM-CM configuré, le serveur ILM-CM peut analyser la base de données de SQL Server à la recherche des certificats expirés et informe par courrier électronique les propriétaires ou gestionnaires de certificats.

Administration d’ILM-CM
ILM-CM est géré via une interface Web, divisée en zones fonctionnelles associées aux tâches de gestion des utilisateurs, des certificats et des cartes à puce. Une fois connecté au portail ILM-CM avec les privilèges d’administrateur appropriés, plusieurs tâches administratives vous permettant de gérer l’environnement ILM-CM (voir la figure 3) sont affichées. La section Tâches courantes comprend les options d’administration, y compris inscription d’utilisateurs à un nouveau jeu de certificats ou carte à puce. Vous pouvez également gérer et approuver des requêtes.
Figure 3 Tâches du portail de gestion ILM-CM
Figure 3 Tâches du portail de gestion ILM-CM
Pour localiser des utilisateurs ou des certificats, utilisez la zone des tâches Manage Users and Certificates. Ces tâches vous permettent de chercher, récupérer, révoquer ou renouveler des certificats. Vous pouvez également chercher une liste de révocation.
Si votre organisation utilise des cartes à puce, la partie Manage User Smart Cards est pratique. Si, par exemple, un utilisateur a verrouillé sa carte, le gestionnaire de certificats peut la déverrouiller ici. Vous pouvez également chercher et afficher des cartes à puce dans le lecteur de cartes local.
La zone Requests de l’interface permet aux gestionnaires de certificats d’examiner et d’approuver les requêtes de certificat utilisateur. Par exemple, vous pouvez afficher tous les certificats contenus dans une requête en attente. La zone Administration permet de créer et de gérer les modèles de profil. Enfin, la zone Repors est utilisée pour développer et créer des rapports associés aux utilisateurs et certificats.
Lors de l’authentification au portail ILM-CM, si votre compte n’a pas de privilèges d’administrateur, une page d’abonné s’affiche et propose les fonctions de gestion libre-service à la disposition des utilisateurs de certificat (voir la figure 4). À partir de ce portail, les utilisateurs peuvent afficher et gérer leurs certificats et les cartes à puce en fonction de leur configuration de stratégie donnée. Les exemples de tâches courantes incluent demande de certificat ou de carte à puce, examen des certificats existants et modification des PIN de carte à puce.
Figure 4 Page de portail abonné pour la gestion libre de l’utilisateur
Figure 4 Page de portail abonné pour la gestion libre de l’utilisateur
Fournir un processus de flux de travail délégué de haute qualité pour émettre, renouveler, remplacer, révoquer et remplacer les certificats ou les cartes à puce peut être un défi pour toute organisation. Avec ILM-CM, vous pouvez désormais déléguer ces tâches pour mieux garantir la sécurité. Disons que vous avez un utilisateur qui a oublié son PIN de carte à puce. En utilisant le modèle de flux de travail délégué, l’utilisateur peut appeler le support technique qui lui posera quelques questions de vérification. En cas de réponse correcte à ces questions, le support technique peut débloquer la carte à puce pour l’utilisateur. Ou encore, le flux de travail délégué permet de récupérer un certificat Encrypted File System (EFS) en cas de suppression accidentelle ou de perte d’un portable.

Modèles de profil
Un modèle de profil est le composant fondamental qui rend possible un processus de gestion de flux de travail complet pour ILM-CM. Un modèle de profil est considéré être un objet administratif unique contenant un ou plusieurs modèles de certificat. Les modèles de profil sont créés et configurés pour gérer la façon dont le processus de flux de travail doit fonctionner dans votre environnement de certificat. L’élément clé d’un modèle de profil est qu’il peut contenir des modèles de certificat multiples pouvant être gérés comme un seul article, ce qui signifie que les utilisateurs peuvent être gérés par un modèle pouvant suivre le processus de certificat pendant tout son cycle de vie.
Les modèles de profil peuvent être configurés pour enregistrer les certificats sur un ordinateur (basé sur logiciel) ou sur une carte à puce (basé sur matériel). Vous pouvez créer ces modèles en dupliquant un échantillon à partir du portail d’administrateur ILM-CM. Dans le modèle de profil, vous pouvez définir plusieurs composants de stratégie de gestion (voir la figure 5).
Figure 5 Un modèle de profil
Figure 5 Un modèle de profil
De nombreux composants de stratégie sont applicables aux profils de logiciel et de carte à puce (voir la figure 6). Certains méritent un commentaire supplémentaire. Pendant le processus d’inscription du certificat, vous pouvez utiliser le composant de stratégie d’inscription pour définir certains critères concernant la façon dont vous souhaitez que le processus d’inscription se déroule. Par exemple, vous pouvez configurer une collecte de données, autrement dit l’utilisateur doit entrer des informations telles que codes de département, adresse de messagerie et gestionnaire. Vous pouvez également créer des définitions qui impriment automatiquement un document officiel lorsque l’utilisateur a inscrit un certificat.
Figure 6 Stratégies de profil logicielles (Close Figure 6)

Composant | Description
Détails du profil | Indique les détails généraux du modèle de profil. Permet d’ajouter un ou plusieurs modèles de certificat au modèle de profil.
Stratégie de duplication | Définit les entités de flux de travail d’un certificat existant.
Stratégie d’inscription | Définit le flux de travail du processus d’inscription.
Stratégie de mise à jour en ligne | Similaire à la stratégie de renouvellement, excepté qu’elle peut mettre à jour des certificats expirants, le contenu de certificat, les modèles et les applets de carte à puce.
Stratégie de « Récupération au nom de » | Récupère des certificats ou une clé privée de l’utilisateur.
Stratégie de renouvellement | Définit le flux de travail de renouvellement lorsqu’un certificat expire.
Stratégie de réactivation | Définit le processus pour réactiver un certificat.
Stratégie de récupération | Définit le flux de travail pour récupérer un certificat utilisateur stocké sur un ordinateur qui a été supprimé, reconstruit ou volé.
Stratégie de révocation | Définit le flux de travail pour révoquer tous les certificats dans un profil.
La stratégie de mise à jour en ligne peut être très utile à votre organisation. Elle est similaire à la stratégie de renouvellement, excepté qu’elle peut mettre à jour le contenu du certificat, les modèles de certificat, les applets sur cartes à puce ainsi que le certificat lui-même lorsqu’il est sur le point d’expirer. Pour utiliser au mieux cette stratégie, vous devez activer le service ILM-CM et le fichier web.config pour autoriser l’accès à un attribut à plusieurs valeurs dans Active Directory. Vous devez également installer le service de mise à jour en ligne sur l’ordinateur client.
La stratégie de « Récupération au nom de » peut être pratique si votre société utilise le cryptage EFS. Supposons que quelqu’un supprime accidentellement son certificat de cryptage. Vous pouvez utiliser ce composant de stratégie pour configurer un flux de travail dans lequel l’équipe de sécurité de support technique demande la clé privée de l’utilisateur. L’utilisateur peut ensuite récupérer sa clé privée en recevant un message électronique avec un mot de passe secret généré par le serveur ILM-CM. Enfin, il se rend sur un lien Web secret sur le serveur ILM-CM pour récupérer le certificat avec ses clés privées associées. La stratégie de « Récupération au nom de » est également particulièrement utile lorsqu’un employé quitte l’organisation, et que ses données doivent être récupérées à des fins d’archivage, réglementaires ou autres.
Pour fournir un processus de renouvellement plus sécurisé, la stratégie de renouvellement vous permet de configurer et d’envoyer par message électronique la clé secrète à mot de passe à utilisation unique dont les utilisateurs ont besoin pour renouveler leurs certificats. Si vous révoquez un certificat puis voulez le réactiver et le supprimer de la Liste de révocation des certificats (CRL), la stratégie de réactivation peut définir ce processus de flux de travail.
Les deux composants de stratégie uniques (associés seulement aux stratégies de certificat de logiciel et pas avec les cartes à puce) sont la stratégie de récupération et la stratégie de révocation. Si un certificat utilisateur enregistré sur un ordinateur est supprimé ou si l’ordinateur lui-même est reconstruit ou volé, la stratégie de récupération peut définir le processus pour restaurer le certificat ou les clés en cas d’archivage sur la CA. La stratégie de révocation permet à l’administrateur de fixer une raison de révocation statique ou autorise la personne exécutant la requête de révocation à désigner la raison au moment de la révocation.
Il existe cinq stratégies supplémentaires de gestion qui sont spécifiques aux modèles de profil de carte à puce, comme illustré à la figure 7.
Figure 7 Stratégies de profil de carte à puce (Close Figure 7)

Composant | Description
Stratégie de remplacement | Définit le profil en cas de perte ou de vol d’une carte à puce de l’utilisateur.
Stratégie de désactivation | Définit le processus de désactivation de certificats sur une carte à puce avant leur expiration.
Stratégie de retrait | Définit le processus pour révoquer tous les certificats sur une carte à puce.
Stratégie de déblocage | Définit qui peut débloquer un PIN utilisateur de carte à puce.
Stratégie de cartes temporaires | Définit une carte à puce de remplacement à court terme. L’utilisateur reçoit de nouveaux certificats de signature mais peut déchiffrer leurs données en obtenant les certificats de chiffrement de profil existants.
Vous pouvez définir plusieurs opérations différentes pour la stratégie de retrait, comme effacer les données utilisateur sur la carte à puce, bloquer les PIN utilisateur et administratif et réinitialiser le PIN administratif. La stratégie de déblocage est généralement utilisée si un utilisateur a oublié son PIN ou qu’une nouvelle carte a été expédiée avec un PIN attribué par ILM-CM. L’utilisateur demande ensuite que la carte à puce soit débloquée.
Comme avec tout produit administratif, les rapports sont une fonctionnalité très utile. La capacité à capturer un instantané de votre environnement de certificat ou carte à puce est très importante pour toute organisation. ILM-CM dispose de plusieurs rapports intégrés incluant inventaires de carte à puce, résumés de requête, usage et expiration de certificat, entre autres. Comme avec les autres systèmes de génération de rapports, si vous avez besoin de rapports supplémentaires, vous pouvez écrire une requête personnalisée puisque toutes les données sont enregistrées dans une base de données de SQL Server.

Développement d’un flux de travail
Voyons maintenant comment ILM-CM peut aider à définir un processus de flux de travail productif. Disons que vous avez plusieurs administrateurs systèmes qui sont responsables de gérer et maintenir les certificats SSL pour leurs systèmes. La première question à poser est : Quels sont les principaux aspects du processus ?
En fonction du type de système, le processus peut nécessiter des méthodes différentes pour créer le fichier de requête de certificat. Ainsi, la première tâche consiste à développer une page Intranet ayant des instructions détaillées sur la manière de créer la requête de certificat pour tous les systèmes.
Après que l’administrateur a créé le fichier de requête, il peut le soumettre au portail d’utilisateur ILM-CM pour l’approbation du certificat. En utilisant le processus de flux de travail ILM-CM, l’administrateur peut définir plusieurs approbateurs qui doivent vérifier et approuver une requête de certificat. Après qu’un certificat a été approuvé, l’utilisateur peut récupérer le certificat d’ILM-CM. Comme ILM-CM met les informations de certificat dans une base de données de SQL Server, les administrateurs peuvent récupérer les informations historiques.
Un an plus tard, lorsque le certificat approche de sa date d’expiration, ILM-CM envoie une notification par courrier électronique au demandeur, l’informant que le certificat est sur le point d’expirer et qu’il doit le renouveler. Mettre ce processus de flux de travail en place aide à éviter que les certificats expirent subitement et vous fassent passer une mauvaise journée.

Résumé
Si votre entreprise utilise un environnement Microsoft PKI, ILM-CM peut aider à le gérer. ILM-CM permet aux organisations d’améliorer les processus d’authentification de sécurité et de réduire les coûts et la complexité de la gestion des certificats numériques et des cartes à puce. ILM-CM est également la base pour développer les processus de flux de travail de certificat et de carte à puce qui font encore défaut à tellement d’entreprises.
Microsoft a également mis en œuvre une prise en charge API externe pour ILM-CM. Si votre organisation utilise des applications personnalisées, vous pouvez interfacer ces applications pour profiter de la prise en charge API ILM-CM.
Pour plus d’informations sur ILM-CM, voir microsoft.com/technet/clm. Un guide de démarrage rapide est également disponible (go.microsoft.com/fwlink/?LinkId=87336).

Kevin Dallmann est consultant-ingénieur système senior pour Accenture et il est principalement responsable de la prise en charge des environnements Active Directory et PKI pour les grandes entreprises. Kevin gère les certifications MCSE et MCT et dispense également des cours Microsoft.


 De la part de l’&#233;diteur: Probl&#232;mes de s&#233;curit&#233;
De la part de l’éditeur
Problèmes de sécurité
Joshua Trupin

Avez-vous remarqué que les problèmes de sécurité sont devenus un peu plus faciles à gérer dernièrement ? Bien entendu, nous aimerions en être entièrement responsables, ici à TechNet Magazine, mais d’autres facteurs y ont contribué. Les deux plus importants sont la détection et la robustesse.
La détection consiste à être conscient des menaces potentielles et des astuces d’ingénierie sociale, tout en maîtrisant les mises à jour et correctifs réguliers qui protègent les logiciels installés. La robustesse est le revers de la médaille, l’idée que les logiciels peuvent être générés pour être plus sûrs et pour réduire leur surface d’attaque en désactivant les fonctionnalités exposées par défaut.
Oh et il existe un autre facteur : la lecture régulière de TechNet Magazine. Impossible de l’oublier celui-là ! Vous avez entre les mains notre numéro presque déjà célèbre consacré à la sécurité, qui contient non moins de sept articles qui vous aideront à devenir un analyste/praticien spécialisé dans la sécurité plus redoutable pour votre entreprise. Mark Russinovich ouvre le jeu avec une analyse du fonctionnement interne de l’UAC, tandis que Steve Riley se consacre au pare-feu Windows et Jesper Johansson explore les modifications d’ACL dans Windows Vista. Nous avons également Jeremy Moskowitz qui parle de la stratégie de groupe et des verrouillages de matériel, Michael Murgolo qui aborde le sujet des PowerToys d’élévation de script et bien plus encore. Le numéro que vous avez entre les mains risque d’être le meilleur magazine de tous les temps.
Tout en maintenant votre état de vigilance, vous devriez découvrir les nouveautés en matière de sécurité de Microsoft. Microsoft Forefront représente le facteur de « robustesse » ; il s’agit d’une gamme de produits de sécurité d’entreprise qui fournit une protection dans trois domaines : systèmes d’exploitation client, serveurs d’applications et frontière du réseau. Il inclut des outils de sécurité pour Exchange Server et Sharepoint et intègre ISA Server et Intelligent Application Gateway pour le trafic réseau. Microsoft System Center incorpore la part de « détection » car il vous permet de rassembler les informations concernant vos systèmes, d’optimiser les opérations et la gestion, de produire des rapports et d’améliorer la livraison de services. Il comprend la prochaine génération de technologies de gestion de la configuration et de surveillance des opérations, entre autres outils.
Pour en savoir plus sur Forefront et System Center, visitez le site Infrastructure Microsoft à l’adresse Microsoft.com/infrastructure. Et pour obtenir les meilleures solutions à vos problèmes de sécurité, tenez-vous au courant et garantissez la robustesse grâce à TechNet Magazine.
—Joshua Trupin

Remerciements aux experts techniques Microsoft suivants : Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher et Buck Woody.


 Bo&#238;te &#224; outils: Nouveaux produits pour les professionnels de l’informatique
Boîte à outils Nouveaux produits pour les professionnels de l’informatique and Greg Steen
myLittleAdmin dispose d’une interface modifiable
L’UI Web prend en charge la plupart des opérations de base de données, y compris la création de nouvelles bases de données, la gestion des bases de données existantes et de leurs contenus et le travail avec des instantanés et des schémas. Il est simple de modifier les propriétés des objets de base de données existants et myLittleAdmin a une grille de données modifiable qui permet de modifier les lignes individuelles de vos tableaux. L’affichage par arborescence de l’interface est très similaire à l’affichage par arborescence existant dans SQL Server Management Studio, l’application ne nécessitant ainsi qu’un apprentissage limité. La seule gêne est que certains clics habituels avec le bouton droit n’activent pas le menu contextuel attendu.
Vous pouvez également utiliser myLittleAdmin pour modifier les connexions, rôles de serveur et informations d’authentification de votre instance SQL. Elle vous permet même de créer et modifier les périphériques de sauvegarde et les serveurs liés (tâches utiles qu’il est agréable d’exécuter à distance).
MyLittleAdmin vous permet également d’exécuter des tâches comme : interroger ad-hoc, attacher et détacher les bases de données, sauvegarder et restaurer, importer les données CSV et rétrécir les bases de données. Vous pouvez même parcourir le journal des erreurs et le contrôleur d’activité pour exécuter un dépannage.
Prix : À partir de 590$ pour une licence pour un seul serveur. Dans le cadre de vos outils Web pour clients, à partir de 990$ pour une licence pour un seul serveur.


 Forum aux questions sur SQL: Installations 64&#160;bits, allocation de m&#233;moire de cluster et plus encore
Forum aux questions sur SQL Installations 64 bits, allocation de mémoire de cluster et plus encore and Par Nancy Michell
Figure 1Recherche SQL Server Books Online dans Windows Live
Disons toutefois que SQL Server dispose de toute la RAM d’un serveur et qu’une nouvelle instance de SQL Server démarre. Qu’arrive-t-il à la mémoire de l’instance SQL Server d’origine ? Il semble que je devrais prévoir le cas de figure le plus défavorable, lorsqu’un seul nœud reste opérationnel et que toutes les instances de SQL Server finissent par s’exécuter sur ce nœud.
R : Il est généralement considéré préférable de définir une valeur de mémoire de serveur maximale inférieure à la mémoire totale disponible dans un ordinateur. Cependant, il est peu probable qu’une valeur égale à un tiers de la mémoire totale soit la meilleure configuration dans votre situation.
Vous craignez que trois des quatre serveurs de votre cluster puissent tomber en panne au même moment et que les trois instances de SQL Server finissent par cohabiter sur le quatrième nœud. Ce scénario est toutefois peu probable.
Dans la majorité des cas, il est préférable de configurer chaque instance pour qu’elle utilise la plupart de la mémoire disponible sur chaque nœud. Supposons que chaque nœud dispose de 32 Go de RAM. La définition de la mémoire de serveur maximale sur 28 Go pour chaque instance constitue un choix raisonnable.
En cas de défaillance d’un nœud, l’instance s’exécutant sur ce nœud basculerait sur le nœud passif et pourra potentiellement gagner l’accès à 28 Go de mémoire. Les deux autres instances ne seront toujours pas affectées ; elles continueront à s’exécuter sur les deux autres nœuds du cluster.
Vous avez indiqué un quatrième nœud de basculement de cluster avec cinq instances de SQL Server et une instance d’Analysis Services. Si vous exécutez SQL Server 2000 avec les extensions Address Windowing Extensions (AWE), vous devrez définir avec précaution certaines limites de mémoire soigneusement sélectionnées pour vos instances de moteur relationnel car elles n’abandonneront pas la mémoire qu’elles ont acquise. La situation est différente avec les instances de SQL Server 2005 et 64 bits, plus souples, et qui ont accès à un grand espace d’adressage avec ou sans AWE. Même si vous utilisez AWE dans ce cas de figure, cet espace d’adressage est dynamique et peut libérer la mémoire sur demande. Par conséquent, pour répondre à la question concernant l’effet sur l’instance de SQL Server originale et la mémoire qu’elle a acquise dans une situation de basculement au cours de laquelle une nouvelle instance démarre, le résultat dépend de la version de SQL Server utilisée (SQL Server 2000 ou SQL Server 2005) et de l’utilisation ou non de AWE.
La planification pour le scénario le plus défavorable est en principe une bonne idée mais, dans la pratique, à moins que vous n’ayez vraiment surdimensionné le système, il est peu probable qu’il survive à trois des quatre nœuds tombant en panne dans un cluster exécutant cinq instances de moteur relationnel SQL Server et une instance d’Analysis Services. Le nœud restant ne disposera pas de ressources de processeur suffisantes pour se charger des instances d’origine à un niveau de performances équivalent. Par conséquent, il sera généralement préférable de concevoir la solution de manière à conserver des performances optimales avec la perte d’un nœud, mais vous devrez intervenir manuellement, dans une moindre mesure, en cas de perte de plusieurs. Vous obtiendrez ainsi une bonne combinaison de prise en charge de haute disponibilité tout en pouvant obtenir un degré d’utilisation décent des ressources coûteuses.
Enfin, avec SQL Server 2005, l’utilisateur final peut faire évoluer le cluster jusqu’à huit nœuds. Dans SQL Server 2000, un cluster de quatre nœuds correspondait au maximum possible.

Limites de la mise en miroir
Q : En me documentant sur la mise en miroir de bases de données SQL Server 2005, j’ai trouvé la restriction suivante : la mise en miroir de base de données peut uniquement prendre en charge 10 bases de données maximum par instance de serveur. Ma configuration requise se compose de deux instances de SQL Server séparées avec stockage séparé, basculement automatique entre les deux et redondance de données.
J’avais prévu d’utiliser la réplication de transactions SQL Server 2005 égal à égal (P2P) combinée à Microsoft® Cluster Server (MSCS), sur lequel j’aurais disposé d’une adresse IP de cluster associée à l’un des deux nœuds, afin que tout le trafic d’insertion, de mise à jour, de suppression et de lecture soit destiné à un seul nœud du cluster. J’aurais traité le nœud secondaire comme passif, mais les transactions y auraient été répliquées. En cas de défaillance, MSCS aurait basculé cette adresse IP vers l’autre nœud et, puisqu’il aurait été configuré pour être P2P et bidirectionnel, aucune procédure manuelle n’aurait lieu pour le démarrage de la publication des transactions sur l’autre nœud (une fois de nouveau actif). J’aurais utilisé la configuration Jeu de nœuds majoritaire dans MSCS pour réduire la nécessité d’accès à une ressource disque partagée pour le quorum.
L’option de mise en miroir n’est toujours pas décidée. Nous avons réduit le nombre de bases de données par cluster SQL Server de 1 000 à 100. Toutefois, est-il recommandé de placer une telle charge de ressources sur les systèmes ?
A : Pour des informations ou de l’aide sur la mise en miroir de SQL Server, consultez BOL ou SQL Server Tech Center aux adresses microsoft.com/technet/prodtechnol/sql et msdn2.microsoft.com/sql.
Votre question a donné lieu à une longue discussion. Après avoir épluché les réactions, voici les meilleures réponses en ce qui concerne votre scénario :
La première réponse est qu’il n’y a aucune limite imposée quant au nombre de bases de données pouvant être mises en miroir dans une instance donnée. Je suppose que vous faites référence à un article mentionnant qu’il est recommandé de mettre en miroir 10 bases de données par instance, mais il s’agit simplement d’une approximation et aucune limite n’est appliquée en particulier à quelque endroit que ce soit. Tout dépend des ressources disponibles sur le système donné.
La mise en miroir pourrait constituer une option, mais 1 000 bases de données constituent sans aucun doute une valeur extrême ; sauf si vous disposez d’un serveur de vraiment grande puissance. Si vous ne voulez pas utiliser le stockage partagé et souhaitez utiliser les technologies SQL Server intégrées, vous pouvez essayer d’utiliser la mise en miroir, l’envoi de journaux ou la réplication. Les avantages et les inconvénients de chacune de ces solutions varient.
La réponse numéro deux est que, si vous disposez de plusieurs bases de données sans utiliser le stockage partagé et que vous voulez utiliser une solution de récupération après incident fournie par Microsoft, vous devrez envisager l’envoi de journaux à l’aide d’un ensemble de petits programmes d’assistance personnalisés pour réduire la surcharge d’administration. Un programme peut sauvegarder et restaurer chaque base de données dans l’ordre et vous éviter ainsi d’avoir à exécuter plusieurs agents d’envoi de journaux. Notez que ceci comporte un certain risque de perte de données. Il n’y a pas de solution intégrée qui ne nécessite pas le stockage partagé ou un SGBD pour éviter toute perte de données.
Bien sûr, il existe toujours un problème quant à la manière dont MSCS pourra effectuer la détection et le basculement. Les configurations MNS dans un cluster ne suppriment généralement pas complètement la nécessité de stockage partagé. Elles suppriment simplement la nécessité de disposer d’un LUN partagé dédié pour le quorum. Le seul moyen de faire en sorte que cette conception fonctionne est de configurer le cluster pour gérer uniquement les adresses IP et les noms de réseaux. SQL Server ne peut pas être configuré en clusters sans stockage partagé et, puisque vous ne pouvez pas utiliser de cluster pour le service SQL; ceci signifie que le cluster ne pourra pas détecter et contrôler les services SQL Server dans une configuration typique.
Vous pourriez utiliser un cluster pour le service SQL Server en l’ajoutant comme service générique à surveiller, mais un problème se présente lors du basculement : puisqu’un cluster est utilisé pour le service, MSCS essaiera de mettre le service en ligne sur le nœud passif lors du basculement, mais certains services SQL seront déjà exécutés sur celui-ci. Bien sûr, vous pourriez l’utiliser pour mettre simplement les adresses IP et les noms réseau en cluster, puis basculer manuellement lorsque nécessaire. Vous pourriez effectuer la même chose en utilisant l’équilibrage de la charge réseau (Network Load Balancing, NLB), qui est effectué ailleurs. Jetez un coup d’œil au document microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx pour plus d’informations.
Étant donné le nombre de bases de données que vous essayez de prendre en charge, une solution d’envoi de journaux pourrait être plus appropriée. Bien sûr, vous devrez automatiser le processus en utilisant un package DTS/SSIS (Data Transformation Services/SQL Server Integration Services), car sinon la sauvegarde manuelle, le déplacement et l’application des journaux actifs prendraient trop de temps en cas de panne.

Merci aux informaticiens Microsoft ci-dessous pour l’apport de leur expertise technique : Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci; Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren et particulièrement Buck Woody.


 Coup de projecteur sur les utilitaires: PowerToys d’&#233;l&#233;vation de script pour Windows&#160;Vista
Coup de projecteur sur les utilitaires PowerToys d’élévation de script pour Windows Vista and Michael Murgolo
Télécharger le code de cet article: Utility2007_06.exe (159KB)
Tandis que le contrôle de compte utilisateur offre une amélioration importante dans le domaine de la sécurité, la possibilité d’élever les autorisations est essentielle pour accomplir certaines tâches administratives et fonctions. Voici certains des PowerToys d’élévation qui rendent l’élévation plus flexible et plus puissante.
Parmi les nombreuses fonctionnalités que Windows Vista a introduites pour répondre aux problèmes de sécurité, le contrôle de compte utilisateur (UAC) est l’une des plus importantes. Avec le contrôle de compte utilisateur, même les utilisateurs qui sont des administrateurs exécutent la plupart des applications avec des privilèges standard, mais ils ont un « potentiel d’élévation » pour des tâches administratives et des
fonctions d’applications spécifiques. Au bout de plusieurs mois d’utilisation de Windows Vista™, l’élévation nécessaire d’une tâche ou d’une application devient une seconde nature. Cependant, j’ai été frustré par un certain nombre de lacunes rencontrées en essayant d’élever certains types de tâches dans Windows Vista.
Donc, j’ai créé, dans le même esprit que les anciens PowerToys Windows®, quelques PowerToys d’élévation de script pour surmonter ces restrictions. Vous pouvez trouver tous les PowerToys que je vais vous présenter dans le téléchargement de code à l’adresse technetmagazine .com/code07.aspx. Et vous pouvez découvrir comment le contrôle de compte utilisateur fonctionne dans l’article de novembre 2006, écrit par Alex Heaton, qui explique comment parvenir au rêve non administratif grâce au contrôle de compte utilisateur (voir l’encadré « Ressources supplémentaires »).

PowerToy de commande d’élévation
Le premier inconvénient était le fait qu’il n’y avait pas de méthode pour élever une application depuis la ligne de commande ou depuis la boîte de dialogue Exécuter. Donc, après avoir enquêté chez Microsoft, je suis tombé sur un modèle de script de John Stephens (ingénieur de conception logicielle chez Microsoft) qui m’a fourni les informations dont j’avais besoin. Il s’avère que si vous transférez le verbe « runas » à l’API ShellExecute ou à son équivalent COM, la méthode ShellExecute de Shell.Application, l’application lancée invitera à l’élévation (voir l’encadré pour plus de détails). Ceci m’a permis de créer le premier PowerToy d’élévation : le PowerToy Commande d’élévation.
Cet outil (qui se compose des fichiers ElevateCommand.inf, elevate.cmd et elevate.vbs) ajoute une commande d’élévation à votre système. Ceci vous permet de lancer des applications qui invitent à l’élévation depuis la ligne de commande, un script ou la boîte de dialogue Exécuter. Par exemple, la commande suivante ouvre Win.ini avec le Bloc-notes (après avoir invité à l’élévation) :
elevate notepad c:\Windows\Win.ini
Lorsque vous utilisez la commande d’élévation avec Windows Script Host (WSH), Windows PowerShell™ ou d’autres scripts, vous devez spécifier l’exécutable de l’hôte de script (par exemple wscript, cscript ou powershell) en tant qu’application. Pour exécuter un fichier vbs, par exemple, vous utiliseriez ceci :
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
Figure 2Invites avec privilèges élevés

Installation et implémentation
Pour installer ces PowerToys, cliquez avec le bouton droit sur un fichier INF, sélectionnez Installer et approuvez l’élévation. Pour désinstaller, utilisez la sélection de Programmes et fonctionnalités dans le Panneau de configuration.
Si l’envie vous prenez d’examiner les fichiers INF et que vous vous demandez pourquoi trois PowerToys installent elevate.cmd et elevate.vbs dans des emplacements différents, je vais vous l’expliquer. La plupart des PowerToys sont implémentés en ajoutant une sous-clé runas à la clé HKEY_CLASSES_ROOT\objecttype\Shell pour le type d’objet dans le Registre.
Cependant, pour certains PowerToys il y avait des types d’objets pour lesquels je souhaitais avoir deux entrées de menu contextuel provoquant l’élévation (« CMD Prompt Here as Administrator » et « PowerShell Prompt Here as Administrator » pour les types d’objets Lecteur et Répertoire ; « Run as Administrator » et « Run as Administrator with Command Prompt » pour tous les types d’objets WSH). Puisqu’il ne peut y avoir qu’une clé runas pour chaque type d’objet, il me fallait implémenter la deuxième action en appelant la commande d’élévation. Mais comme je souhaitais que chaque INF puisse être installé et désinstallé d’une manière indépendante, j’ai dû mettre les copies associées elevate.cmd et elevate.vbs dans des endroits différents. (Vous ne pouvez pas incrémenter des compteurs d’utilisation des fichiers à partir d’un fichier INF brut. Oui, les programmes d’installation MSI conviendraient mieux, mais je souhaitais des programmes d’installation qui puissent être créés et modifiés avec un éditeur de texte.) L’une des conséquence est le fait que seules les entrées de menu contextuel implémentées à l’aide de la clé runas afficheront une icône de protection dans le menu.

Résumé
J’espère que vous trouverez ces outils utiles et qu’ils amélioreront votre expérience avec le contrôle de compte utilisateur. Peut-être vous inspireront-ils à créer vos propres PowerToys. (Pour ceux qui utilisent d’autres langages de script tels que Perl ou Python sur Windows Vista, il devrait être facile de créer un PowerToy « Script d’élévation » pour ces langages également.) Comme pour tous les PowerToys, ceux-ci sont des outils à « utiliser à vos propres risques », non pris en charge. En tout cas, amusez-vous bien à créer des élévations !
Ressources supplémentaires
  • Réalisez le rêve de tout non administrateur avec le contrôle des comptes utilisateur
  • Vue d’ensemble du contrôle de compte utilisateur
  • Élévation par ShellExecute
  • Méthode ShellExecute
  • Verbes et associations de fichiers
  • Renaissance d’un ancien PowerToy


 Le petit c&#226;bleur: Le protocole SSTL (Secure Socket Tunneling Protocol)
Le petit câbleur Le protocole SSTL (Secure Socket Tunneling Protocol) and Joseph Davies
Cet article est basé sur une version préliminaire de Windows Server, nom de code « Longhorn ». Toutes les informations contenues dans le présent document sont susceptibles d’être modifiées.
Les protocoles VPN dans Windows XP et Windows Server 2003 ne fonctionnent pas pour certaines configurations. Comprenez les divers problèmes et découvrez comment Windows Server « Longhorn » et Windows Vista avec Service Pack 1 utiliseront le protocole SSTP (Secure Socket Tunneling Protocol) pour les résoudre.
La prise en charge d’un réseau privé virtuel (VPN) dans Windows XP et Windows Server 2003 vous permet de vous connecter à votre Intranet privé sur Internet, comme si votre ordinateur était connecté à un port Ethernet local. Cependant, les protocoles VPN dans Windows XP et Windows Server 2003 ne fonctionnent pas pour certaines configurations de pare-feu
et pour certaines configurations indirectes (par exemple lorsque votre ordinateur se trouve derrière un traducteur d’adresses réseau [NAT] ou un serveur proxy Web) dans lesquelles le trafic pour les connexions VPN est bloqué. Pour résoudre ces difficultés, la prochaine version de Windows Server®, nom de code « Longhorn », et Windows Vista™ avec Service Pack 1 (tous les deux en phase de test bêta) incluent la prise en charge du nouveau protocole SSTP (Secure Socket Tunneling Protocol).

Problèmes d’accès au VPN
Dans Windows® XP et Windows Server 2003, les protocoles VPN qui permettent les connexions à distance à un Intranet sur Internet sont le protocole PPTP (Point-to-Point Tunneling Protocol) et le protocole L2TP/IPsec (Layer Two Tunneling Protocol avec Internet Protocol security). Ils permettent l’encapsulation des paquets envoyés entre un client à accès distant et l’Intranet auquel il est connecté.
Le trafic VPN basé sur PPTP consiste en une connexion TCP au port TCP 1723 sur le serveur VPN pour la gestion du tunnel et des paquets encapsulés par encapsulation générique de routage (GRE) pour les données VPN. Mais le trafic PPTP peut avoir des problèmes avec les pare-feux, NAT et proxys Web. Pour éviter ces problèmes, les pare-feux doivent être configurés pour autoriser la connexion TCP et les données encapsulées GRE. Bien que la GRE soit une méthode standard d’encapsulation de paquets IP, de nombreux fournisseurs d’accès à Internet (ISP) abandonnent ces paquets, ce qui entraîne une perte de données. De plus, les connexions existant dans les hôtels et les cafés-restaurants sont généralement configurées pour un trafic normal sur Web et messagerie électronique et peuvent ne pas autoriser le trafic PPTP. De plus, si votre ordinateur est derrière un NAT, le NAT doit pouvoir traduire le trafic GRE. Dans le cas contraire, vous pourrez établir la connexion TCP mais vous ne pourrez pas envoyer ni recevoir des données encapsulées GRE. Enfin, le trafic PPTP ne peut pas passer par un proxy Web.
L’autre protocole VPN fonctionnant dans Windows XP et Windows Server 2003, L2TP/IPsec, utilise Internet Key Exchange (IKE) pour négocier la protection Encapsulating Security Payload (ESP) IPsec du trafic VPN, et peut également avoir des problèmes avec les pare-feux, NAT et proxys Web.
Dans cette configuration, les pare-feux doivent être configurés pour autoriser le trafic IKE et les données encapsulées ESP. Si votre ordinateur client VPN se trouve derrière un NAT, le client VPN et le serveur VPN doivent prendre en charge IPsec NAT-Traversal (NAT-T). Notez, toutefois, que le serveur VPN ne peut se trouver derrière un NAT et que le trafic L2TP/IPsec ne peut passer dans un proxy Web.

La nouvelle solution VPN
Comme vous pouvez le voir, il existe plusieurs problèmes liés au fonctionnement du protocole VPN dans Windows XP et Windows Server 2003. La bonne nouvelle est que SSTP dans Windows Vista avec Service Pack 1 et Windows Server « Longhorn » résout ces problèmes de connectivité VPN en utilisant HTTP sur SSL (Secure Sockets Layer). SSL est également appelé Transport Layer Security (TLS). HTTP sur SSL sur le port TCP 443 est le protocole utilisé sur le Web depuis un certain temps pour collecter les numéros de carte de crédit et autres renseignements privés. Quand vous vous connectez à une adresse Web qui commence par https:, vous utilisez HTTP sur SSL.
Utiliser HTTP sur SSL résout de nombreux problèmes de connectivité de protocole VPN (les pare-feux, NAT et proxys de Web autorisent généralement ce type de trafic parce qu’il est tellement répandu).
SSTP utilise une session HTTP sur SSL entre les clients VPN et les serveurs pour échanger les paquets encapsulés IPv4 ou IPv6. Notez qu’une connexion VPN à accès distant HTTP sur SSL est différente de la connexion faite par une application qui utilise HTTP sur SSL. Par exemple, Outlook® Web Access (OWA) vous permet d’accéder à votre messagerie électronique Microsoft Exchange dans votre entreprise sur Internet. OWA utilise une session chiffrée HTTP sur SSL, mais ce n’est pas la même chose qu’une connexion d’accès distant. Bien que vous puissiez afficher vos messages électroniques avec OWA, vous ne pouvez pas atteindre l’emplacement d’une URL Intranet intégrée dans un message électronique d’Exchange.
(SSTP ne prend pas en charge les configurations de proxy Web authentifiées, dans lesquelles le proxy a besoin d’une certaine forme d’authentification pendant la requête de connexion HTTP.)
Une mise en œuvre HTTP sur SSL dans Windows peut sensiblement abaisser le coût de la gestion de votre solution d’accès distant. Par exemple, HTTP sur SSL génère moins de questions au support technique et élimine les problèmes liés aux serveurs VPN placés derrière des NAT. Et, comme SSTP fonctionne à peu près partout, les utilisateurs sont plus heureux et plus productifs.
Parce que SSTP est intégré dans Windows, vous n’avez pas à vous préoccuper de l’installation et de la gestion d’un logiciel client VPN tiers sur les ordinateurs clients, ou de l’installation d’un logiciel supplémentaire sur le serveur VPN. De plus, SSTP peut assurer un meilleur équilibre des charges pour les connexions VPN via les équilibreurs de charge SSL disponibles.
Nouvelles fonctionnalités SSTP
  • SSTP a intégré la prise en charge de la protection d’accès réseau (NAP), qui peut être utilisée pour mieux protéger les biens du réseau en garantissant la conformité avec les exigences d’intégrité du système. Pour plus d’informations sur la NAP, voir microsoft.com/nap.
  • De plus, SSTP prend en charge le trafic IPv6 natif envoyé dans le tunnel SSTP et les connexions SSTP IPv6 sur Internet IPv6.
  • SSTP établit également une seule session HTTP sur SSL du client SSTP au serveur SSTP. Les autres solutions VPN basées sur SSL de fournisseurs tiers utilisent deux sessions HTTP sur SSL. L’utilisation d’une seule session HTTP sur SSL assure une utilisation moindre du réseau et un meilleur équilibrage des charges.
  • Enfin, SSTP est entièrement intégré dans les composants client VPN de Windows Vista avec Service Pack 1 et Windows Server « Longhorn » et Routage et accès distant dans Windows Server « Longhorn ». SSTP est un autre protocole VPN et peut utiliser les mêmes protocoles d’authentification et méthodes de configuration (telles que le dossier Connexions réseau et Gestionnaire de connexions) que ceux utilisés pour les connexions basées sur PPTP ou L2TP/IPsec.
Contrairement aux protocoles PPTP et L2TP/IPsec dans Windows XP et Windows Server 2003, SSTP ne prend pas en charge les connexions VPN site à site.

SSTP dans Windows
Un ordinateur exécutant Windows Server « Longhorn » et Routage et accès distant est un serveur VPN basé sur SSTP. Il est inutile d’installer IIS parce que Routage et accès distant écoute les connexions entrantes sur l’URI (Uniform Resource Identifier) spécifique /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/.Toutefois, Routage et accès distant et IIS peuvent coexister sur le même serveur.
Un ordinateur exécutant Windows Vista (avec les améliorations prévues dans le prochain Service Pack 1, dont la sortie est prévue au courant de l’année) ou Windows Server « Longhorn » est un client VPN basé sur SSTP, capable d’initier des connexions SSTP vers un serveur VPN basé sur SSTP. Le serveur SSTP doit avoir un certificat d’ordinateur avec la propriété installée Authentification de serveur ou utilisation avancée de la clé (EKU) polyvalente. Ce certificat d’ordinateur est utilisé par le client SSTP pour authentifier le serveur SSTP lorsque la session SSL est établie. Le client SSTP valide le certificat d’ordinateur du serveur SSTP. Pour faire confiance au certificat d’ordinateur, l’autorité de certification racine (CA) de l’autorité de certification émettrice du certificat d’ordinateur du serveur SSTP doit être installée sur le client SSTP.
La figure 1 compare les attributs des différents protocoles VPN dans Windows Server « Longhorn » et Windows Vista avec Service Pack 1. L’encadré « Nouvelles fonctionnalités SSTP » décrit les fonctionnalités SSTP.
Figure 1 Comparaison des différents protocoles VPN (Close Figure 1)

Attributs | PPTP | L2TP/IPsec | SSTP
Encapsulation | GRE | L2TP sur UDP | SSTP sur TCP
Chiffrement | Chiffrement Microsoft Point-to-Point (MPPE) avec RC4 | IPsec ESP avec Triple Data Encryption Standard (3DES) ou Advanced Encryption Standard (AES) | SSL avec RC4 ou AES
Protocole de gestion de tunnel | PPTP | L2TP | SSTP
Lorsque l’authentification de l’utilisateur a lieu | Avant que le chiffrement ne commence | Une fois la session IPSec établie | Une fois la session SSL établie
Certificats requis pour établir le tunnel VPN | Aucun | Certificats d’ordinateur sur client VPN et serveur VPN | Certificat d’ordinateur sur serveur VPN et certificat d’autorité de certification racine sur le client VPN

Fonctionnement de SSTP
Lorsqu’un utilisateur sur un ordinateur exécutant Windows Server « Longhorn » ou Windows Vista avec Service Pack 1 initie une connexion VPN basée sur SSTP, le processus suivant a lieu :
  1. Le client SSTP établit une connexion TCP avec le serveur SSTP entre un port TCP dynamiquement attribué sur le client et le port TCP 443 sur le serveur.
  2. Le client SSTP envoie un message Hello client SSL, indiquant que le client veut créer une session SSL avec le serveur SSTP.
  3. Le serveur SSTP envoie son certificat d’ordinateur au client SSTP.
  4. Le client SSTP valide le certificat d’ordinateur, détermine la méthode de chiffrement pour la session SSL, génère une clé de session SSL puis la chiffre avec la clé publique du certificat du serveur SSTP.
  5. Le client SSTP envoie la forme chiffrée de la clé de session SSL au serveur SSTP.
  6. Le serveur SSTP déchiffre la clé de session de SSL chiffrée avec la clé privée de son certificat d’ordinateur. Toute communication future entre le client SSTP et le serveur SSTP est chiffrée avec la méthode de chiffrement négociée et la clé de session SSL.
  7. Le client SSTP envoie un message de requête HTTP sur SSL au serveur SSTP.
  8. Le client SSTP négocie un tunnel SSTP avec le serveur SSTP.
  9. Le client SSTP négocie une connexion PPP avec le serveur SSTP. Cette négociation inclut l’authentification des informations d’authentification de l’utilisateur avec une méthode d’authentification PPP et la configuration des paramètres pour le trafic IPv4 ou IPv6.
  10. Le client SSTP commence à envoyer le trafic IPv4 ou IPv6 sur la liaison PPP.
La figure 2 montre la structure des paquets IPv4 ou IPv6 envoyés sur une connexion VPN basée sur SSTP.
Figure 2Structure des paquets SSTP
Un paquet IPv4 ou IPv6 est tout d’abord encapsulé avec un en-tête PPP et un en-tête SSTP. La combinaison du paquet IPv4 ou IPv6, de l’en-tête de PPP et de l’en-tête de SSTP est chiffrée par la session SSL. Un en-tête TCP et un en-tête IPv4 (pour les connexions SSTP sur Internet IPv4) ou un en-tête IPv6 (pour les connexions SSTP sur Internet IPv6) sont ajoutés pour terminer le paquet.
Pour plus d’informations sur SSTP, voir le blog Routage et accès distant à l’adresse blogs.technet.com/rrasblog.


 Windows PowerShell: Utilisation d’Active Directory
Windows PowerShell Utilisation d’Active Directory and Don Jones Windows PowerShell ne fournit pas de cmdlet Get-ADSIObject, mais cela ne l’empêche pas de proposer une base solide pour la prise en charge d’ADSI. Découvrez les adaptateurs de type et apprenez à utiliser Windows PowerShell pour travailler avec les objets d’annuaire.
Si vous vous êtes amusé avec Windows PowerShell, il y a de fortes chances pour que vous ayez essayé le cmdlet Get-WMIObject, également connu sous son alias pratique de gwmi. Comme je l’ai décrit dans l’article du mois dernier, ce cmdlet est un exemple de l’amélioration majeure que représente Windows PowerShell par rapport aux précédents langages de script et shells de ligne de commande
(voir technetmagazine.com/issues/2007/05/PowerShell). Gwmi permet d’accéder rapidement et facilement à Windows® Management Instrumentation (WMI), vous laissant faire un nombre incroyable de choses sans devoir écrire des scripts complexes.
Get-WMIObject est un tellement bon exemple de ce que Windows PowerShell™ peut faire que lorsque je le montre à une classe, les étudiants extrapolent invariablement sa fonctionnalité vers d’autres domaines de l’administration Windows. Généralement, l’une des premières questions que l’on me pose est du genre « Existe-t-il un cmdlet Get-ADSIObject » ?

Prise en charge d’ADSI dans Windows PowerShell
ADSI signifie Active Directory® Services Interface. Malgré son nom, ADSI n’est pas spécifique à Active Directory. Une façon plus précise de lire ce nom serait « Active (pause) Directory Services Interface », parce que ADSI peut se connecter à de nombreux services d’annuaire, y compris les annuaires de style Windows NT® (pas uniquement les domaines Windows NT, voyez-vous, mais également le gestionnaire de comptes de sécurité [SAM] local sur des ordinateurs indépendants et membres). Avec une telle flexibilité, un cmdlet Get-ADSIObject serait certainement formidablement utile. Malheureusement, l’équipe de Windows PowerShell n’a pas été en mesure de l’insérer dans sa première version.
Cependant, ne me faites pas dire que la prise en charge d’ADSI par Windows PowerShell est insuffisante. En fait, la prise en charge d’ADSI dans Windows PowerShell est si bonne que le cmdlet Get-ADSIObject ne vous manquera même pas !
Tout commence avec l’adaptateur de type [ADSI]. Les adaptateurs de type méritent une petite explication. N’oubliez pas que Windows PowerShell est basé sur Microsoft® .NET Framework (2.0 ou supérieur, pour être précis). En conséquence, presque tout dans Windows PowerShell, des objets WMI aux fichiers et dossiers, est représenté comme objet depuis Framework. Cependant, l’équipe de Windows PowerShell n’avait pas trop envie d’exposer des objets Framework bruts aux administrateurs Windows. Par exemple, de nombreux objets Framework fonctionnent d’une façon un peut inconstante, et la constance était un objectif de conception majeur pour Windows PowerShell. Une autre raison est que certains objets Framework sont excessifs lorsqu’il s’agit de l’administration Windows, alors que la simplicité était également un objectif clé de la conception de Windows PowerShell. C’est ainsi que sont nés les adaptateurs de type.
Comme son nom l’indique, un adaptateur de type « adapte » un type d’objet .NET Framework en un format plus cohérent et, parfois, plus simple. Par exemple, supposons que vous créez une nouvelle variable de chaîne comme celle-ci :
[string]$var = “Hello”
Vous avez utilisé une instance du type System.String qui est gérée par l’adaptateur .NET. L’adaptateur de type [ADSI] est connecté aux classes .NET Framework DirectoryServices, y compris le type DirectoryEntry.

Récupération d’objets de l’annuaire
Il est assez simple de se connecter aux objets d’annuaire. Par exemple, pour se connecter à un utilisateur appelé Don, dans l’unité organisationnelle (OU) IT du domaine Contoso.com, vous utiliseriez quelque chose du genre :
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
Si vous avez travaillé avec ADSI dans VBScript ou un autre langage, cela devrait vous être familier. Il s’agit d’une chaîne de requête Lightweight Directory Access Protocol (LDAP) standard, qui est le moyen natif d’accès à Active Directory. Il n’est pas nécessaire de spécifier un nom de contrôleur de domaine (DC) ou autres détails ; il y a assez d’informations dans ce nom de domaine pleinement qualifié (FQDN) pour localiser un DC et récupérer l’objet (en supposant que vous avez l’autorisation de le faire, bien entendu).
Si vous travaillez avec des comptes de sécurité locaux, le processus est presque identique, excepté en ce qui concerne l’utilisation du fournisseur WinNT au lieu du fournisseur LDAP :
$user = [ADSI]”WinNT://don-pc/don”
Veuillez noter que les noms LDAP et WinNT sont sensibles à la casse. Alors que Windows PowerShell lui-même ne dépend généralement pas de la casse, ces ressources ADSI ne le sont pas, aussi, faites attention à la façon dont vous les tapez.
La figure 1 montre ce qui se passe si je prends la variable $user résultante et la transmets à Get-Member : J’obtiens une liste des propriétés de l’objet. Malheureusement, il ne s’agit pas d’une liste complète de toutes les propriétés de l’utilisateur, et elle n’inclut aucune des méthodes de l’objet utilisateur. La classe sous-jacente System.DirectoryServices.DirectoryEntry Framework fonctionne de façon un peu étrange à cet égard, et Windows PowerShell ne peut me montrer que ce que la classe Framework fournit.
Figure 1Récupération de la liste des propriétés d’un objet
Pour récupérer des objets, il s’agit principalement de savoir construire une chaîne de requête. L’utilisation du fournisseur WinNT est plutôt facile. Il suffit de spécifier un nom d’ordinateur ou de domaine, suivi d’une barre oblique puis d’un nom d’objet. Cette technique fonctionne parfaitement avec les domaines Active Directory (qui bénéficient, après tout, d’une comptabilité descendante avec les domaines Windows NT). Et, en fait, l’utilisation du fournisseur WinNT pour récupérer des objets Active Directory peut s’avérer être le chemin le plus facile puisque le fournisseur WinNT vous donne un affichage plat du domaine. Autrement dit, vous n’avez pas besoin de savoir dans quelle OU se trouve un objet parce que le fournisseur WinNT ne voit pas les OU.
La récupération d’objets LDAP nécessite un peu plus de précision. Vous commencez avec les informations les plus spécifiques possibles, telles qu’un nom canonique (cn) de l’objet ou le nom d’une OU. Ensuite, vous indiquez le chemin complet jusqu’à l’objet, en commençant par son conteneur parent et en finissant avec le domaine lui-même. Par exemple, l’utilisateur Don, situé dans l’UO Sales, qui est l’OU West du domaine Contoso.Com, ressemblerait à ceci :
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
Ce format nécessite un petit peu de pratique et implique que vous sachiez où se trouve l’objet. La figure 2 résume les divers composants d’un FQDN.
Figure 2 Composants du FQDN (Close Figure 2)

Composant | Objectif | Exemple
cn | Nom canonique d’un objet. Également utilisé pour les conteneurs non-OU, tels que Users et Computers. | cn=Don
ou | Unité organisationnelle. | ou=Sales
dc | Composant de nom de domaine. Chaque composant d’un nom de domaine DNS obtient son propre composant « dc= ». | dc=domaine, dc=com

L’aide d’un ami
La création et la suppression d’objets impliquent généralement que vous vous connectiez tout d’abord au conteneur de l’objet, tel qu’une OU, puis demandiez au conteneur de créer ou supprimer l’objet. J’oublie toujours la bonne syntaxe, mais heureusement les gars de Microsoft Scripting peuvent donner un coup de main sous la forme d’ADSI Scriptomatic.
Bien que créé au départ pour VBScript, ADSI Scriptomatic est toujours un guide utile pour Windows PowerShell puisque la syntaxe ADSI est la même. Par exemple, après avoir téléchargé l’outil, je sélectionne l’option de création d’un nouvel utilisateur. J’ignore tous les codes de script générés par l’outil jusqu’au code « End connect to a container », qui ressemble à ceci :
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
La conversion à Windows PowerShell est facile. Tout d’abord, je me connecte au conteneur dans lequel je veux créer l’utilisateur. Pour rester cohérent avec le code Scriptomatic, j’utilise la variable $objContainer pour représenter l’OU. Je crée également une variable, $strName, pour contenir le nouveau nom d’utilisateur :
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
Ensuite, je copie le code Scriptomatic, supprime toute trace de toute déclaration VBScript, et ajoute $ aux noms de variable :
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
Et c’est tout : un nouvel utilisateur a été créé dans l’OU Test du domaine Contoso.com.

Modification des objets d’annuaire
Une fois connecté à un objet, tel qu’un utilisateur ou un groupe, vous pouvez le modifier. Avec le fournisseur WinNT, vous pouvez modifier directement de nombreuses propriétés, comme celles de la figure 1. Par exemple, pour afficher puis modifier la propriété Description d’un utilisateur, procédez comme suit :
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
Le plus important est de se souvenir que les modifications de propriété sont apportées à votre cache de propriété locale, qui est une zone de stockage temporaire qu’ADSI conserve sur votre ordinateur. Appeler la méthode SetInfo réécrit la mémoire cache sur le domaine ou ordinateur duquel vous avez récupéré l’objet, enregistrant essentiellement vos modifications à l’annuaire.
Les objets Active Directory ne fournissent pas de propriétés directes pour la majorité des attributs d’objet. Au lieu de cela, utilisez les méthodes Obtenir et Indiquer :
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Les objets WinNT ont tendance à être assez simplistes, puisque les services d’annuaire de Windows NT n’ont pas enregistré beaucoup d’informations sur les objets comme les utilisateurs et les groupes. D’autre part, Active Directory enregistre de nombreuses informations et il peut être difficile de trouver les noms d’attribut corrects. Par exemple, pour modifier un nom d’utilisateur, vous devez modifier la propriété Sn. Pourquoi Sn ? Cela signifie « surname » en anglais, soit nom de famille.
Heureusement, Microsoft propose des références utiles, disponibles en ligne à l’adresse msdn2.microsoft.com/ms677286.aspx. Cette référence indique les noms d’attribut pour chaque zone majeure de la console Utilisateurs & Ordinateurs Active Directory, ainsi si vous savez ce que vous voulez changer dans la console, vous pouvez trouver le nom d’attribut sous-jacent. Veuillez noter qu’une référence plus complète console/attribut est disponible dans le livre ADSI Scripting: TFM par Cade Fassett (SAPIEN Press, 2007).

Ce que vous ne pouvez pas faire
Malheureusement, la prise en charge d’ADSI dans Windows PowerShell n’a pas une base aussi solide que la prise en charge d’autres technologies, telles que WMI. Par exemple, il est un peu difficile d’énumérer les membres d’un groupe d’ordinateur locaux. Plusieurs situations difficiles apparaissent également lorsqu’il s’agit d’utiliser Active Directory. D’après mon expérience, la récupération, création, et suppression de base d’objets fonctionne bien. La modification des propriétés d’objet marche assez bien, bien que certaines propriétés soient inaccessibles. Je rencontre la majorité des difficultés en travaillant avec des groupes et objets locaux via le fournisseur WinNT.
Cela ne veut pas dire que l’on ne peut rien faire. Certaines choses sont juste plus difficiles ou moins intuitives. Examinons l’exemple suivant :
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
Il s’agit d’ajouter l’utilisateur nommé User1 au groupe Techs. Le début est assez simple. Je récupère le groupe en utilisant le FQDN. Ensuite, j’utilise la collection de Membres du groupe (en particulier, la méthode Ajouter de la collection) pour ajouter le FQDN de l’utilisateur voulu. La dernière étape n’est, cependant, plus du tout intuitive. J’appelle la méthode CommitChanges de la classe PSBase masquée pour enregistrer les modifications.
PSBase est une classe spéciale qui représente directement l’objet .NET Framework de base. Dans ce cas, CommitChanges n’est pas directement exposé dans Windows PowerShell (en fait, aucune méthode n’est exposée par l’adaptateur ADSI), en conséquence vous devez aller jusqu’à la classe sous-jacente. Ce n’est pas impossible, mais ce n’est certainement pas intuitif. Cela montre également que les capacités des services d’annuaire n’ont pas encore été entièrement adaptées dans Windows PowerShell.
Et ceci, pour plusieurs raisons. Tout d’abord, l’équipe de Windows PowerShell a ajouté la prise en charge d’ADSI actuelle au shell un peu tardivement dans le cycle de développement. Comme Jeffrey Snover, architecte du shell, le dit souvent, « livrer c’est choisir ». L’équipe disposait d’un certain temps alloué au développement et à la livraison du shell, et elle a dû prendre des décisions quant à ce qu’elle devait garder pour la prochaine version. Autrement, elle aurait pu passer des années à ajouter des fonctionnalités sans jamais sortir un produit pris en charge.
Une autre raison est le .NET Framework sous-jacent. Sa classe DirectoryServices est assez complexe et adapter cette complexité dans Windows PowerShell prendra de nombreuses heures et nécessitera une planification soignée. Les classes Framework évoquent également, à mon avis, un peu Active Directory et ne fournissent pas la prise en charge stellaire pour le fournisseur WinNT (Windows PowerShell hériterait bien entendu de ces restrictions de Framework).
Je m’attends à ce que Windows PowerShell ait finalement une prise en charge largement étendue des services d’annuaire, prise en charge qui peut ne pas s’effectuer via la couche d’ADSI, mais plutôt via les améliorations de base dans le .NET Framework. Entre-temps, la prise en charge d’ADSI disponible dans Windows PowerShell vous permet d’exécuter la majorité des tâches administratives, telles que création d’utilisateurs, modification des propriétés d’utilisateur courantes et ainsi de suite.
N’oubliez pas que de nombreuses tâches de services d’annuaire peuvent être réalisées via WMI. Vérifiez les scripts disponibles à l’adresse microsoft.com/technet/scriptcenter/scripts pour voir d’excellents exemples utilisant WMI, pour fournir des informations plus complètes sur un groupe local que ne le ferait ADSI.


 H&#233;, vous le scripteur&#160;!: Scripts concernant le soulignement ondul&#233; rouge
Hé, vous le scripteur ! Scripts concernant le soulignement ondulé rouge and Les scripteurs Microsoft
Télécharger le code de cet article: HeyScriptingGuy2007_06.exe (151KB)
Vous recherchez une manière plus facile d’ajouter des termes au dictionnaire de Microsoft Word que de le faire manuellement, un mot à la fois ? Qui ne serait pas tenté ? Ce mois, les scripteurs vous indiquent comment créer des dictionnaires personnalisés dans Microsoft Word, et comment configurer Word par programmation afin qu’il utilise ces dictionnaires.
Figure 1Document Word affichant les fautes d’orthographe
Vous ne remarquez rien de particulier ? Bingo. Word a dessiné des lignes ondulées sous les termes de script tels que Msgbox. Pourquoi ? Parce que Word ne reconnaît pas ces termes. Ne reconnaît pas ces termes ? Mais enfin Word ! Pourtant, au cours des dernières d’années, les scripteurs ont tapé le terme Msgbox plusieurs millions de fois. Ils ont exécuté la vérification orthographique plusieurs millions de fois et t’ont toujours dit que Msgbox était correctement écrit. Et tu continues de signaler Msgbox, StrReverse et LTrim comme fautifs ? C’est quoi le problème ?
Avant que vous ne vous dépêchiez de prendre la défense de Word, oui, nous savons que nous pouvons ajouter manuellement ces termes au dictionnaire de Microsoft Word. Mais, voyons, nous sommes les scripteurs, et nous le disons haut et fort : nous ne connaissons rien au travail manuel ? En outre, ajouter manuellement les fonctions VBScript, les noms de classe Windows® Management Instrumentation (WMI) et les attributs d’objet Active Directory® Security Interfaces (ADSI) peut être, pour le moins, assez fastidieux. Et que se passe-t-il si nous voulons le faire sur tous nos ordinateurs ? Et si nous voulons partager ces orthographes correctes avec nos lecteurs dévoués ? Que se passe-t-il si... et bien, vous voyez ce que nous voulons dire.
Le fait est le suivant : il doit sûrement y avoir une façon plus facile d’ajouter des termes de script (ou n’importe quel terme) au dictionnaire sans devoir le faire manuellement, mot par mot.
En fait, non, c’est impossible. Au mois prochain !
Mais non, nous plaisantons. Bien sûr qu’il existe une façon plus facile d’ajouter des termes au dictionnaire. Et dans un instant, nous vous indiquerons comment procéder. Mais nous allons commencer par prendre une minute pour parler des dictionnaires.
À propos, voici un fait intéressant concernant les dictionnaires. Pourquoi les Américains écrivent-ils le mot couleur « color » et non pas « colour » comme les Britanniques ? Pourquoi les Américains écrivent-ils le mot centre « center » et non pas « centre » comme les Britanniques ? Nous connaissons la réponse : parce que Noé Webster, qui a créé le premier dictionnaire américain (le Webster est toujours LE dictionnaire de référence pour l’anglais-américain), n’aimait pas les règles d’orthographe de l’anglais et a ainsi arbitrairement modifié l’orthographe de nombreux mots.
Très bien. Ce n’est pas passionnant. Mais essayez de trouver un fait intéressant à propos des dictionnaires !
En plus du dictionnaire standard intégré dans l’application, Microsoft Word vous permet de créer un nombre illimité de dictionnaires personnalisés. Par défaut, Word dispose d’un dictionnaire personnalisé appelé Custom.dic, qui se trouve généralement dans le dossier Application Data\Microsoft\Proof dans votre dossier de profil utilisateur (\Documents and Settings\nom d’utilisateur par défaut dans Windows XP). Si vous cliquez avec le bouton droit de la souris sur un mot mal écrit et sélectionnez Ajouter au dictionnaire, ce mot sera ajouté à Custom.dic.
En fait, Custom.dic n’est qu’un vieux fichier texte simple. Ouvrez-le dans le Bloc-notes, et vous verrez une liste de mots similaires à ceci :
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
Et c’est ainsi que nous pouvons ajouter par programmation des termes de script au dictionnaire de Microsoft Word. Il suffit de créer un fichier texte contenant ces termes, puis de configurer Word pour utiliser ce fichier comme dictionnaire personnalisé. Est-ce difficile ? Etant donné que les scripteurs sont prêts à utiliser eux-mêmes cette fonction, ce n’est vraiment pas très difficile.
Mais attendez : nous devons encore faire une pause. Dans le modèle objet de Microsoft Word, les informations sur les dictionnaires personnalisés sont enregistrées dans la collection CustomDictionaries. À son tour, cette collection peut être accédée par programmation en référençant l’objet Word.Application et la propriété CustomDictionaries. Par exemple, la figure 2 montre un script qui renvoie des informations sur tous les dictionnaires personnalisés associés à votre copie de Microsoft Word.
Figure 2 Script qui récupère les informations de dictionnaire personnalisé (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
Exécutez le script de la figure 2, et vous obtiendrez des informations similaires à :
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
Plutôt cool, non ?
Bien entendu, obtenir des informations sur les dictionnaires existants n’est pas exactement la même chose que créer un nouveau dictionnaire personnalisé ; c’est un peu comme lire un article sur un millionnaire et être soi-même millionnaire. En conséquence, voyons si nous pouvons trouver une façon de créer un nouveau dictionnaire personnalisé dans Word.
Nous allons commencer par ajouter toutes les fonctions VBScript à un nouveau dictionnaire appelé Scripting.dic. Nous commençons avec les fonctions VBScript parce que nous devons y travailler un peu. Ensuite, nous vous montrerons comment ajouter des classes WMI, des attributs ADSI et des cmdlets Windows PowerShell™ à votre dictionnaire sans aucun effort. (Cela va sans dire, lorsqu’il s’agit de ne pas se fatiguer, les scripteurs savent de quoi ils parlent.)
Pour commencer, la création d’un dictionnaire personnalisé dans Microsoft Word est aussi simple que ceci :
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
Comme vous pouvez le voir, nous commençons par créer une instance de l’objet Word.Application. Vous aurez peut-être remarqué que nous ne réglons jamais la propriété Visible sur True, et ainsi Word n’est jamais visible à l’écran. Pourquoi ? Tout simplement, parce que l’exécution de ce script dure à peine une seconde. En conséquence, nous ne voyons pas vraiment l’intérêt d’assister à une apparition fugitive de Word à l’écran. Mais si vous aimez les brèves apparitions de Word (notamment, pour savoir que le script est exécuté), il suffit d’ajouter cette deuxième ligne de code à votre script :
objWord.Visible = True
Après avoir créé l’objet Word.Application, nous utilisons cette ligne de code pour créer une référence d’objet à la collection CustomDictionaries :
Set colDictionaries = _
  objWord.CustomDictionaries
Nous appelons ensuite la méthode Add pour ajouter le dictionnaire personnalisé. Il convient de noter que ce fichier n’a pas besoin d’exister ; si Word ne peut pas trouver de fichier appelé Scripting.dic, il crée tout simplement un nouveau fichier vierge portant ce nom. Voici le code pour ajouter le dictionnaire personnalisé :
colDictionaries.Add “Scripting.dic”
Vous aurez peut-être également remarqué que nous n’avons pas spécifié de chemin pour ajouter le nouveau dictionnaire. Au lieu de cela, nous avons simplement transmis le nom de fichier (Scripting.dic) à la méthode Add (ajouter). Pas de problème. Dans ce cas, Scripting.dic est créé dans le dossier par défaut pour les dictionnaires et autres outils de vérification (par exemple, C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof).
Et si nous voulons placer notre dictionnaire ailleurs ? Aucun problème. Cette commande crée Scripting.dic dans le dossier C:\Scripts :
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
Et que se passe-t-il si nous décidons un jour que nous voulons effacer ce dictionnaire personnalisé ? Toujours pas de problème. Dans ce cas, nous pouvons sélectionner le dictionnaire en question et utiliser la méthode Delete pour l’effacer :
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Figure 3Document Word après l’ajout d’un dictionnaire personnalisé
C’est assez pratique, et nous le disons nous-mêmes, en particulier lorsque l’on considère le fait que vous pouvez partager Scripting.dic et votre script de création de dictionnaire personnalisé avec qui vous voulez. Faites-le et en moins de temps qu’il n’en faut pour le dire, leurs versions de Word afficheront également Msgbox comme un mot correctement écrit. La vérité c’est que, si nous, les scripteurs, étions paresseux, nous pourrions terminer cet article du mois ici et vous auriez quand même un outil utile. Mais, vous n’avez encore rien vu !
Remarque : en fait, nous sommes paresseux. Mais comme nous devons utiliser la place dont nous disposons pour cet article, nous avons décidé de proposer un script ou deux en bonus.
Comme vous le savez probablement, VBScript et Windows Script Host sont plutôt timides ; ils n’aiment pas trop parler d’eux. Ce n’est pas le cas de WMI, ADSI ou Windows PowerShell. Il suffit de poser une question et ces technologies vous diront tout de leurs classes, leurs propriétés, leurs méthodes (soit tout ce que vous voudrez savoir).
Prenons ADSI, par exemple. La figure 4 montre un script qui lie au schéma d’Active Directory et récupère tous les attributs de l’objet de compte utilisateur. À son tour, il enregistre ces attributs dans le fichier C:\Scripts\Scripting.dic.
Figure 4 Ajouter les noms d’attribut ADSI à un dictionnaire personnalisé (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
N’est-ce pas beau ? Avec quelques lignes de code, nous avons créé un dictionnaire contenant tous les attributs de l’objet utilisateur Active Directory. Partagez ce code avec vos collègues scripteurs, et vous n’aurez plus jamais à vous soucier de noms d’attribut tels que streetAddress ou givenName affichés comme des mots mal écrits. Et, bien entendu, c’est extensible à l’infini. Vous voulez ajouter les propriétés pour la classe d’ordinateur ? Remplacez dans cette ligne de code :
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
Ou pour les classes WMI ? La figure 5 montre un script qui récupère une liste de toutes les classes WMI se trouvant dans l’espace de noms root\cimV2 et enregistre ces informations sur C:\Scripts\Scripting.dic.
Figure 5 Ajouter les noms de classe WMI à un dictionnaire personnalisé (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Vous pensez que nous avons oublié nos utilisateurs de Windows PowerShell ? Les scripteurs ne feraient jamais cela. En fait, nous les avons bien oubliés. Mais nous nous sommes souvenus de parler de ce script d’une ligne qui renvoie tous les noms de cmdlet et les enregistre sur C:\Scripts\Scripting.dic:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
Le point positif de l’article de ce mois, c’est que nous avons tous appris quelque chose. Vous avez appris à créer des dictionnaires personnalisés dans Microsoft Word et à configurer par programmation Word pour utiliser ces dictionnaires personnalisés. Et les scripteurs ont appris que si vous voulez que quelque chose soit fait, et bien, le mieux c’est encore de faire en sorte que quelqu’un le fasse pour vous. Mais si tout le reste échoue, vous pouvez toujours le faire vous-même !


 Histoires de Bureau: Comment ne pas perdre vos donn&#233;es
Histoires de Bureau Comment ne pas perdre vos données and Wes Miller C’est incroyable le nombre de fois où des données importantes sont perdues. Mais la réalité est que les informations ne sont perdues que parce qu’elles ne sont pas protégées. Découvrez les mesures importantes que vous pouvez et devez prendre pour sécuriser les données de votre organisation.
L’information n’aspire qu’à être libre. Quelle que soit la personne à qui vous les confiez ou les efforts que vous déployez pour essayer d’emprisonner ces 0 et ces 1, ils trouveront toujours un moyen de s’échapper. Tous les jours, des pertes de données, mineures ou importantes, font la une. Il est ridicule de perdre des données importantes
Figure 2Mauvais choix de mot de passe, même si vous aimez votre mère
L’intégrité du mot de passe et l’authentification locale sont critiques mais, bien entendu, les données sur le système local ne devraient pas être des données que vous ne pouvez pas vous permettre de compromettre à moins qu’elles ne soient physiquement sécurisées ou chiffrées. Les mots de passe à eux seuls ne sont pas la solution. Un mot de passe utilisateur n’est qu’un outil permettant d’empêcher les attaquants qui veulent compromettre l’accès interactif direct au système et ne disposent pas d’outils, de le faire.

Sécurité physique
Les données critiques ne doivent pas résider sur un système qui peut être physiquement compromis ou sorti du bureau. Si vous craignez que vos systèmes soient compromis lorsque quelqu’un démarre dans Windows PE et récupère des données, vous avez d’autres problèmes ; Windows PE n’est pas le coupable. Au lieu de cela, vous vous trouvez dans le ou les cas suivants. Vos systèmes ne sont pas correctement sécurisés au niveau physique. Ils sont sécurisés, mais vous ne faites pas confiance aux utilisateurs qui y accèdent, vos données sont sur un système que n’est pas (ou ne peut pas être) physiquement sécurisé, ou les systèmes ne peuvent pas être physiquement sécurisés et vous n’avez pas utilisé d’outils de chiffrement de volume, tels que la fonctionnalité BitLocker™ dans Windows Vista, pour réduire le risque de compromission physique. (Pour plus d’informations sur BitLocker, consultez l’article de Byron Hynes dans ce numéro de Technet Magazine).
D’après vous, quels sont vos systèmes qui peuvent présenter un risque. Pouvez-vous les sécuriser physiquement ? Pourquoi ne pas les placer dans un centre de données ou dans une autre zone à accès limité ? Si ce n’est pas possible, ou s’il s’agit d’un système mobile, utilisez-vous un logiciel de chiffrement de volume ? Si vous ne pouvez prendre aucune de ces mesures, transférez les données sur un système sécurisé ou chiffrez-les. Dans le cas du portable volé dont je vous ai parlé, si le volume avait été chiffré avec un outil de chiffrement de volume sécurisé, les données auraient été presque entièrement à l’abri de toute compromission.
Ce n’est pas parce qu’un système se trouve dans un centre de données qu’il est sécurisé ; si vous avez plusieurs T1 connectés à Internet, vous courez toujours un risque. L’accès Internet rapproche les personnes indélicates de l’accès physique, en conséquence, prenez soigneusement en compte les menaces dont font l’objet vos systèmes. Envisagez de les déplacer sur un segment séparé de votre réseau où vous avez au moins un autre niveau de protection de réseau entre Internet et les systèmes analysés.

Atténuation des risques pour les données
Une autre mesure de sécurité à votre disposition consiste à permettre aux utilisateurs d’accéder via des applications ou outils client léger qui isolent les données vers un serveur physiquement sécurisé. Cela peut signifier fournir l’accès via un VPN afin que les utilisateurs qui sont souvent en déplacement puissent se connecter. Ne laissez jamais les contraintes physiques d’un utilisateur imposer la façon dont les données doivent être traitées. Ce n’est pas parce qu’un utilisateur a besoin d’un accès, et qu’il se trouve dans un lieu sans haut débit ou autre accès ultra-rapide, que vous devez transférer les données sur la machine de l’utilisateur. Si vous ne pouvez absolument pas déplacer le système et devez le garder dans un emplacement non sécurisé, je le répète, sécurisez les données utilisant le chiffrement de volume.

Sécurité intégrée au système
Préparez-vous à l’éventualité que, malgré tous vos efforts, quelqu’un s’introduise dans votre système en retirant le disque dur et en le plaçant dans un autre système Windows où les ACL NTFS peuvent être réinitialisés.
Pour cela, utilisez le chiffrement de volume inclus dans Windows Vista. Pour la plupart des autres versions de Windows, de nombreux outils de fournisseurs tiers sont disponibles. Leur complexité d’usage varie, de même que leur capacité à exécuter un chiffrement de volume complet et/ou un chiffrement de fichiers ou répertoires individuels comme le permet Encrypting File System (EFS). Si le volume est chiffré, les données sont protégées contre la majorité des vols.

Sécurité des archives
Les données sauvegardées doivent également être sécurisées. La plupart des personnes donnent deux raisons pour ne pas sauvegarder leurs systèmes de façon sécurisée : le chiffrement au moment de la sauvegarde prend trop de temps et/ou leur logiciel de sauvegarde ne le prend pas en charge.
Mais si vous sauvegardez des systèmes, et surtout si vous suivez la meilleure pratique consistant à sortir les sauvegardes du site, vous devez sécuriser les données intégrées aux sauvegardes. Chiffrez les données en utilisant EFS, si disponible, ou autre logiciel de chiffrement de volume (tel que la fonctionnalité BitLocker dans Windows Vista ou autre logiciel de tiers), ou achetez un logiciel de sauvegarde incluant des capacités de chiffrement et fonctionnant à un niveau acceptable. La sécurité n’est pas garantie par le simple fait que les données sont un peu brouillées sur une bande de sauvegarde ou découpées dans une solution de sauvegarde basée sur disque. Vous devez supposer que le mécanisme de transport lui-même sera compromis.

Sécurité de la transmission
Vous devez sécuriser toutes les données transmises en ligne. N’utilisez que des protocoles sécurisés pour accéder au système distant. Utilisez des versions chiffrées de protocoles et supposez toujours qu’une attaque de type man-in-the-middle (l’homme au milieu) est probable. N’utilisez pas de protocoles non chiffrés ou mal chiffrés, et si vous utilisez un chiffrement, n’utilisez pas une longueur ou un algorithme de chiffrement faible. Vous, ou quelqu’un dans votre organisation, doit comprendre tous les protocoles de communication et les algorithmes de chiffrement utilisés entre les systèmes de votre infrastructure.

Suppression sécurisée
Nous avons tous entendu des histoires concernant des disques durs ou autres périphériques de stockage achetés sur eBay ou au marché aux puces local qui ont été exposés à un logiciel d’expertise légale ou même à des utilitaires de restauration ordinaires, et ont ainsi révélé leurs sombres secrets, à savoir les données qui auraient dû être complètement supprimées avant de vendre les lecteurs.
Si vous avez des UFD dans votre organisation, envisagez les utilitaires de chiffrement forcé. Les disques contenant des données à haut risque doivent être chiffrés. Malgré la conviction populaire, je ne pense pas que le simple chiffrement des volumes avant leur mise au rebut soit sûre. Vous vous souvenez de cette métaphore sur les déchets médicaux que j’ai mentionnée plus tôt ? Considérons les données sur ces systèmes comme des déchets dangereux, et les utilitaires de suppression de données comme le traitement. Utilisez un outil de suppression des données conforme à la norme DoD 5220.22-M, par exemple SDelete de Mark Russinovich, avant de revendre vos disques et systèmes, ou même avant de les déplacer au sein de votre organisation. Autrement, le prochain utilisateur entre dans le secret de toutes les données de l’utilisateur précédent.

Audit
Et enfin, mais non des moindres, un autre élément clé de la sécurité des données consiste à auditer le cycle de vie des données de votre organisation, voire à modéliser les menaces auxquelles elles sont exposées. Détectez les points faibles par lesquels vos données peuvent passer et surveillez-les soigneusement. Windows dispose de plusieurs outils d’audit intégrés. Toutefois, avec l’audit, vous pouvez facilement connaître un débordement de données. Assurez-vous que vous regardez les bonnes zones et que vous n’êtes pas surchargé de données. Détectez les points faibles et comblez-les correctement avec une bonne atténuation, n’endommagez pas le barrage retenant vos données. Assurez-vous également que vos utilisateurs sont correctement formés sur la gestion convenable des données. Ils sont le maillon critique à de nombreux niveaux de votre organisation. Pour plus d’informations, consultez l’encadré « Ressources supplémentaires ». N’oubliez pas de suivre toutes les suggestions présentées ici ; elles vous permettront de mieux dormir la nuit.
Ressources supplémentaires
« Guide des ressources pour l'application des optimisations d’infrastructure principale, niveau de base à normalisé » vous expliquera comment faire passer votre infrastructure informatique d’un niveau de base très manuel et réactif à un niveau normalisé comprenant une automatisation accrue, appliquant des normes de configuration et intégrant des opérations améliorées. Téléchargez le guide à l’adresse suivante : go.microsoft.com/?linkid=5795711. « Guides des ressources pour l'application des optimisations d’infrastructure complémentaire » se trouve sur microsoft.com/io. Consultez également l’article « Les 10 lois immuables de sécurité » pour d’autres conseils sur la sécurité.


 Sur le terrain: Parlez &#224; vos d&#233;veloppeurs
Sur le terrain Parlez à vos développeurs and David Aiken Il est plus simple que vous le pensez de faire en sorte que les développeurs génèrent des applications plus faciles à gérer. Tout commence par la communication. Les développeurs ne voient pas les logiciels de la même façon que les administrateurs. Mais en discutant avec les développeurs, les administrateurs peuvent expliquer ce qui est important à leurs yeux et les développeurs peuvent ainsi concevoir des codes en connaissance de cause.
C’est étrange, mais les développeurs ne voient pas les logiciels de la même façon que les administrateurs. Les développeurs travaillent avec des codes, des traces, des fichiers de configuration XML, des GUID et des assemblys. Les administrateurs travaillent avec des scripts et des composants logiciels MMC (Microsoft® Management Console) (ou plutôt, c’est ce qu’ils souhaiteraient).
Prenons un peu de recul. J’ai parfois l’impression que l’ensemble du processus de développement des logiciels est défaillant. Nous consacrons tout un tas de ressources à essayer de comprendre ce que veut l’utilisateur final. Nous créons des prototypes, réalisons des études d’utilisabilité, organisons des entretiens et ainsi de suite ; pourtant nous avons du mal à fournir une expérience de gestion simple et cohérente. Nous avons beaucoup de mal.
Je pensais autrefois que Xcopy, Regedit et le Bloc-notes étaient les meilleures façons d’installer un logiciel. Maintenant je sais que le meilleur moyen consiste à utiliser un Microsoft Installer (MSI) qui peut être personnalisé, installé et désinstallé. Je sais qu’il n’est probablement pas judicieux de s’attendre à ce qu’un administrateur configure un service Web à l’aide du Bloc-notes pour éditer du XML, et qu’un composant logiciel enfichable MMC (ou un script Windows PowerShell™) représente un bien meilleur choix. Je sais qu’une trace de pile ne représente aucun intérêt pour apporter la cause initiale et les solutions possibles à un problème pour un utilisateur ou un administrateur, et qu’un événement bien écrit dans les journaux d’applications est plus utile. Je sais qu’afin de générer un logiciel qui peut être géré et exploité par des administrateurs, je dois les traiter comme des utilisateurs.
En traitant l’administrateur comme un utilisateur, je peux définir des cas d’utilisation, générer des prototypes, mener des études de convivialité et ainsi de suite. Ceci me permettra de fournir la meilleure expérience possible aux administrateurs. En d’autres termes, ceci les aidera à installer, configurer, surveiller, dépanner et réparer mon logiciel sans qu’ils aient besoin de faire appel à moi. Si j’utilise les fonctionnalités de gestion intégrées dans le système d’exploitation qu’ils connaissent, je peux réduire considérablement le coût d’exécution de mon application (moins de prises en charge des problèmes à un niveau supérieur), améliorer la satisfaction des clients (l’application est en panne moins souvent et ils peuvent réparer les problèmes rapidement) et augmenter les chances qu’ils achètent mon logiciel plutôt que le vôtre (résultat : une croisière aux Antilles).
D’accord, la croisière, c’est un rêve. Mais faire en sorte que les développeurs créent des applications plus faciles à gérer n’est pas un simple rêve, c’est un objectif réalisable. Et vous pouvez aussi y participer. La prochaine fois qu’il y a un problème, ne vous contentez pas de transférer le message électronique en maudissant son auteur. Suggérez-lui plutôt d’inscrire un événement dans le journal des applications ou de fournir un compteur de performances ou une autre indication du problème. Mieux encore, suggérez une cause et une résolution possibles. Demandez-lui de vous générer un script Windows PowerShell ou une console MMC pour configurer l’application. En fait, les développeurs ignorent souvent votre existence, sans parler de vos besoins. Parlez-leur.


 La vie secr&#232;te de Windows: Ce que les nouveaux utilisateurs voient dans le menu D&#233;marrer
La vie secrète de Windows Ce que les nouveaux utilisateurs voient dans le menu Démarrer and Raymond Chen Imaginez acheter un nouvel ordinateur, activer Windows, cliquer sur le bouton Démarrer et voir un menu vierge. La raison pour laquelle le menu Démarrer contient des applications dans l’emplacement le plus fréquemment utilisé avant d’avoir utilisé quoi que ce soit est la suivante : offrir une bonne expérience prête à l’emploi. Découvrez comment ces applications sont choisies.
Nous avons tout d’abord pensé remplir ce menu Démarrer vierge avec du texte. Avec quelque chose du style « Hé, bien sûr, cet espace est pour l’instant vierge, mais à mesure que vous exécutez des programmes, ils apparaîtront ici, faites-moi confiance. ». L’espace n’avait plus l’air idiot. À l’heure actuelle, cet espace a l’air stupide et laid.
Nous avons effectué quelques tests supplémentaires, et nous avons finalement choisi ce qui s’affiche dans Windows XP. Le mois dernier, vous avez vu que la liste de programmes fréquemment utilisés est basée sur un système de points : les programmes avec le nombre de points le plus important apparaissent dans cette liste dynamique. Pour les nouveaux utilisateurs, nous avons donné des points artificiels aux divers programmes. Par conséquent, le menu Démarrer initial présente un échantillon de programmes amusants pour donner aux utilisateurs une idée de ce qu’ils peuvent faire.
Le nombre de points artificiels est choisi avec soin pour avoir un nombre de points suffisants pour que les programmes souhaités apparaissent sur la liste des programmes fréquemment utilisés. Cependant, le nombre de points n’est pas très élevé pour éviter qu’ils engloutissent les véritables points gagnés par les programmes à mesure que les utilisateurs lancent les applications.
Cependant, ces points artificiels n’ont pas été attribués aux utilisateurs qui ont mis leur système à niveau depuis Windows 2000. Dans ce cas, les points utilisés par le menu Démarrer de Windows 2000 pour Intellimenus ont été utilisés dans le système de points de Windows XP. Ainsi, le menu Démarrer pour une installation mise à niveau de Windows XP reflétait les programmes exécutés le plus souvent par l’utilisateur sous Windows 2000.
Dans la version initiale de Windows XP, les points artificiels ont été attribués pour que les trois premiers des six emplacements sur la liste des programmes les plus fréquemment utilisés aient été choisis par Windows et les trois derniers par le fabricant informatique. Si vous avez acheté une copie au détail, au lieu d’une copie préinstallée de Windows XP, alors Windows a renseigné deux de ces trois emplacements et a laissé le dernier espace vide. Ainsi, le tout premier programme exécuté apparaîtra immédiatement sur le menu Démarrer.
Ces six emplacements ont subi des modifications dans Windows XP Service Pack 1. Deux des emplacements ont été choisis par Windows, l’un par le Ministère de la Justice des États-Unis et le dernier par le fabricant informatique. Comme précédemment, si vous avez acheté votre copie de Windows XP chez un détaillant, alors deux des emplacements du fabricant informatique ont été attribués par Windows et le dernier a été laissé vide.
Le menu Démarrer est l’une des parties les plus visibles de l’interface utilisateur de Windows, et comme vous le voyez, nous avons beaucoup travaillé pour que tout semble naturel et intuitif.


 Lettres: R&#233;ponses &#224; vos questions
Lettres Réponses à vos questions
Prise en main de Windows PE
Après avoir lu l’article de Wes Miller « Prise en main de Windows PE » dans le numéro de septembre 2006 de TechNet Magazine, j’ai créé un menu avec l’Assistant basé sur HTML pour applications (HTA). J’ai plusieurs questions concernant le fonctionnement du menu avec Windows® PE 2.0.
-Andy

Voici vos questions et les réponses de Wes à chacune d’elles :

Comment puis-je savoir si les composants logiciels optionnels, HTA et Windows Script Host (WSH), sont exécutés depuis mon fichier ISO ?
Si vous avez installé les composants optionnels dans votre fichier ISO conformément aux instructions de la documentation, ils doivent fonctionner. J’ai entendu parler de deux scénarios courants où ce n’est pas le cas : Si vous n’avez pas exécuté peimg /prep pour préparer l’image, ou si vous n’avez pas utilisé le paramètre /commit avec ImageX pour valider les changements dans l’image Windows PE lors du démontage.

Windows Management Instrumentation (WMI) doit-il être installé ? Les fichiers de l’Assistant mentionnés dans l’article entraînent une erreur Internet Explorer®.
Les fichiers de l’Assistant doivent fonctionner dans la mesure où les HTA sont installés ; ils sont très rudimentaires. WMI n’est pas nécessaire pour ces fichiers, je les ai en fait écrits avant que vous puissiez ajouter WMI à Windows PE.

Comment puis-je inclure OC.bat dans mon fichier startnet.cmd ?
Il est inutile d’utiliser OC.bat si vous utilisez Windows PE 2.0. Il n’est requis que pour 1.x. Windows PE 2.0 vous permet d’ajouter des composants sans ajouter la correction apportée par OC.bat.

Puis-je utiliser certains codes de Wes dans mon menu une fois que tout fonctionne ?
Vous êtes libre d’utiliser tout exemple de code et de le réutiliser comme vous le souhaitez. Il est toutefois interdit de le revendre ou de le distribuer dans le cadre d’un package d’exemples de code. Consultez le contrat de licence sur le site Web de TechNet Magazine pour plus d’informations.

Où se trouve Windows PE ?
Où puis-je trouver les outils de génération Windows PE ? Puis-je les télécharger ou dois-je les acheter ?
-Franklin
Les outils de génération Windows PE pour Windows Vista™ font partie du Windows Automated Installation Kit (WAIK). Vous pouvez le télécharger à l’adresse go.microsoft.com/fwlink/?LinkId=85377.
Le WAIK est réservé aux systèmes d’exploitation de la famille Windows Vista. Pour le déploiement de Windows XP, de nombreux outils similaires sont disponibles dans le Business Desktop Deployment Solution Accelerator. Toutefois, la licence pour Windows PE a été modifiée avec Windows Vista. Auparavant, (pour Windows XP), Windows PE n’était disponible que via la licence Software Assurance (voir microsoft.com/licensing/sa/benefits/winpe.mspx pour plus de détails).

File Server Resource Manager
Le package File Server Resource Manager sera-t-il disponible au téléchargement pour une utilisation sur la version originale de Windows Server® 2003 ? Ou ce package n’est-il compatible qu’avec la version R2 ?
-Dan
File Server Resource Manager est une fonctionnalité de Windows Server 2003 R2. En raison des dépendances dans cette version, il n’est pas prévu pour l’instant de la mettre à disposition des précédentes versions.

Dans le noyau
Après avoir lu l’article de Mark Russinovich « Dans le noyau de Windows Vista : 3è partie », j’ai deux questions. Tout d’abord, je remarque que Process Explorer indique où les fichiers exe ou DLL sont aléatoirement situés à chaque session de démarrage. Est-il possible pour un logiciel malveillant d’utiliser le même mécanisme pour déterminer l’emplacement du code qu’il veut exploiter ? Deuxièmement, s’il existe 256 positions où la randomisation peut démarrer (si j’ai bien compris l’article), peut-on empêcher un sondage par « force brute » d’un logiciel malveillant si le code cible reste statique pendant la session.
-Joe

Mark a les réponses à vos questions :

Process Explorer pose le problème de l’œuf et de la poule : le logiciel malveillant ne peut pas trouver les DLL parce qu’il ne peut pas trouver l’API qui renvoie cette information. Un sondage par « force brute » d’un logiciel malveillant n’est pas une méthode d’injection fiable, parce que si le logiciel malveillant se trompe, il est probable qu’il bloque l’application qu’il essaie d’infecter. Au minimum, la randomisation ralentira la propagation d’un virus. Dans le meilleur des cas, elle empêchera le logiciel malveillant d’infecter un système.

Nous contacter
Vous avez quelque chose à dire ? Ne soyez pas timide ! Nous aimons avoir des nouvelles de nos lecteurs. Envoyez-nous un message électronique à tnmag@microsoft.com.