Guide de sécurité de Windows XP

Chapitre 6 : Stratégie de restriction logicielle pour les clients Windows XP

Dernière mise à jour le 20 octobre 2005

Sur cette page

Présentation
Architecture de la stratégie de restriction logicielle
Options disponibles pour les stratégies de restriction logicielle
Conception et déploiement d'une stratégie de restriction logicielle
Résumé

Présentation

Les stratégies de restriction logicielle fournissent aux administrateurs un moyen d'identifier et de limiter les logiciels susceptibles d'être exécutés sur des ordinateurs locaux. Cet outil peut aider à protéger les ordinateurs dotés de Microsoft® Windows® XP Professionnel contre les conflits connus et à les préserver des logiciels malveillants, tels que les virus et les chevaux de Troie. La stratégie de restriction logicielle s'intègre parfaitement au service d'annuaire Active Directory® et à la stratégie de groupe. Vous pouvez également l'appliquer sur des ordinateurs autonomes.

La structure de ce chapitre est différente de celle des chapitres précédents de ce guide en raison du mode de fonctionnement de la stratégie de restriction logicielle. Les chapitres précédents ont fourni des recommandations sur la manière de configurer les options du paramètre Stratégie de groupe. La stratégie de restriction logicielle nécessite qu'un administrateur définisse les applications dont l'exécution est autorisée sur les ordinateurs clients de votre environnement, puis détermine les restrictions que la stratégie appliquera aux clients.

Lorsque vous implémentez la stratégie de restriction logicielle, vous devez commencer par déterminer quel sera le niveau de sécurité par défaut : Illimité ou Rejeté. Si le niveau de sécurité par défaut est Illimité, tous les logiciels pourront s'exécuter et vous devrez configurer des règles supplémentaires pour bloquer des applications spécifiques. L'approche plus sécurisée consistera à configurer le niveau de sécurité par défaut sur Rejeté, qui implique qu'aucun logiciel ne sera autorisé à s'exécuter, puis à configurer des règles supplémentaires pour permettre l'exécution d'applications spécifiques. Vous pouvez appliquer la stratégie de restriction logicielle à plusieurs ordinateurs par le biais de stratégies de groupe basées sur le domaine ou à des ordinateurs individuels par le biais d'une stratégie de groupe locale.

Important : Il est indispensable que vous testiez minutieusement l'ensemble des paramètres de stratégie présentés dans ce guide, et notamment ceux relatifs à la stratégie de restriction logicielle, avant de les déployer sur des systèmes de production. Des erreurs commises au niveau de la conception ou de la mise en œuvre de cette fonctionnalité risquent de créer beaucoup de frustration chez les utilisateurs.

Une stratégie de restriction logicielle offre différentes méthodes d'identification des logiciels, ainsi qu'une infrastructure reposant sur des stratégies pour appliquer les règles régissant les modalités d'exécution des logiciels identifiés. Les utilisateurs d'ordinateurs doivent se conformer aux instructions définies dans la stratégie de restriction logicielle par l'administrateur de leur environnement.

Vous pouvez recourir à une stratégie de restriction logicielle pour effectuer les opérations suivantes :

  • contrôler les logiciels susceptibles d'être exécutés sur les ordinateurs clients de votre environnement ;

  • limiter l'accès des utilisateurs à des fichiers spécifiques sur les postes de travail multiutilisateur ;

  • désigner les utilisateurs habilités à ajouter des éditeurs approuvés sur les ordinateurs clients ;

  • déterminer si les stratégies affectent tous les utilisateurs ou un sous-ensemble d'utilisateurs sur les ordinateurs clients ;

  • interdire l'exécution de fichiers exécutables sur vos ordinateurs locaux en fonction des stratégies définies au niveau d'un ordinateur, d'une UO, d'un site ou d'un domaine.

Haut de page

Architecture de la stratégie de restriction logicielle

La stratégie de restriction logicielle offre des fonctions extrêmement puissantes :

  • Une stratégie susceptible d'être appliquée au niveau du domaine ou des ordinateurs locaux. Les administrateurs créent la stratégie puis définissent les applications autorisées et non autorisées. La stratégie entre en vigueur au moment de l'exécution et les utilisateurs ne reçoivent pas d'invites leur permettant d'accepter ou de refuser l'exécution de fichiers exécutables.

  • Une stratégie dont l'application n'est pas limitée aux seuls fichiers exécutables binaires. La définition de ce que l'on entend par logiciel est quelque peu ambiguë. La stratégie de restriction logicielle permet d'exercer un contrôle sur Microsoft Visual Basic® Scripting Edition (VBScript), JScript® et d'autres langages de script. Elle s'intègre également à la fonction Windows Installer, de façon à contrôler les packages susceptibles d'être installés sur les ordinateurs clients. Cette fonction inclut une interface de programmation d'applications (API) qui vous permet de coordonner l'exécution de la stratégie avec celle d'autres programmes.

  • Une stratégie évolutive. Parce qu'elle est mise en œuvre par le biais de la stratégie de groupe, la stratégie de restriction logicielle peut être mise en œuvre et gérée de façon efficace sur des domaines composés de dizaines de milliers d'ordinateurs.

  • Une stratégie souple. Les administrateurs ont la possibilité d'interdire les scripts non autorisés, de réguler les contrôles Microsoft ActiveX® ou de verrouiller de façon sûre les ordinateurs clients.

  • Une stratégie qui utilise une cryptographie évoluée pour l'identification des logiciels. La stratégie de restriction logicielle peut identifier les logiciels en utilisant des hachages ou des signatures numériques.

L'implémentation de la stratégie de restriction logicielle s'effectue en trois phases :

  1. L'administrateur, ou une autorité déléguée, crée la stratégie à l'aide du composant logiciel enfichable Stratégie de groupe MMC pour l'unité d'organisation, le domaine ou le site du conteneur Active Directory. Microsoft préconise la création d'un objet de stratégie de groupe distinct pour la stratégie de restriction logicielle.

    Remarque : Vous ne pouvez créer une nouvelle stratégie de restriction logicielle pour un poste de travail autonome local que si vous êtes membre du groupe Administrateurs de l'ordinateur local. Pour définir ces paramètres de stratégie, cliquez sur Paramètres Windows, Paramètres de sécurité, puis sur Stratégie de restriction logicielle.

  2. La stratégie de niveau ordinateur est téléchargée et entre en vigueur une fois l'ordinateur démarré. Les stratégies utilisateur entrent en vigueur lorsque l'utilisateur se connecte au système ou au domaine. Pour mettre la stratégie à jour, exécutez la commande gpupdate.exe /force.

  3. Lorsqu'un utilisateur lance un fichier exécutable, tel qu'une application ou un script, la stratégie détermine si l'exécution est autorisée à partir de ses règles de priorité.

Paramètres Non restreint ou Rejeté

Une stratégie de restriction logicielle comprend deux éléments :

  • Une règle par défaut autorisant l'exécution de certains programmes.

  • Un ensemble d'exceptions à la règle par défaut.

Vous pouvez définir la règle par défaut utilisée pour identifier les logiciels sur Non restreint ou Rejeté, ce qui vous permet respectivement d'exécuter ou de ne pas exécuter tous les logiciels.

Avec la valeur Non restreint, l'administrateur peut définir des exceptions à la règle par défaut : autrement dit, un ensemble de programmes interdits d'exécution. Appliquez le paramètre par défaut Non restreint dans les environnements au sein desquels la gestion des ordinateurs clients est peu contraignante. Par exemple, vous pouvez limiter la capacité des utilisateurs à installer un programme susceptible d'entrer en conflit avec des programmes existants en créant une règle qui bloquera son exécution.

Par mesure de sécurité, il est toutefois plus prudent de sélectionner la valeur Rejeté pour la règle par défaut, et d'autoriser ensuite l'exécution de certains programmes spécifiques. Pour le paramètre par défaut Rejeté, l'administrateur doit définir toutes les règles relatives à chaque application et s'assurer que les paramètres de stratégie de sécurité corrects sont définis sur les ordinateurs des utilisateurs pour que ces derniers aient accès aux applications qu'ils sont autorisés à exécuter. Le paramètre par défaut Rejeté représente une approche plus sécurisée pour les organisations qui souhaitent protéger les ordinateurs clients dotés de Windows XP.

Quatre règles d'identification des logiciels

Les règles d'une stratégie de restriction logicielle identifient une ou plusieurs applications et indiquent si leur exécution est autorisée. Le moteur d'exécution de Windows XP interroge les règles de la stratégie avant d'autoriser l'exécution d'applications. Pour créer une règle, vous devez identifier des applications, puis les classer comme exceptions au paramètre par défaut Rejeté. Chaque règle peut inclure des commentaires qui précisent les actions accomplies.

Une stratégie de restriction logicielle utilise les quatre règles suivantes pour identifier une application :

  • Règle de hachage. Utilise une empreinte cryptographique du fichier exécutable.

  • Règle de certificat. Utilise un certificat numérique signé par un éditeur de logiciels pour le fichier .exe.

  • Règle de chemin d'accès. Utilise le chemin UNC (Universal Naming Convention) local ou le chemin d'accès au registre de l'emplacement du fichier .exe.

  • Règle de zone. Utilise la zone Internet d'origine du fichier exécutable (s'il a été téléchargé à l'aide de Microsoft Internet Explorer).

Règle de hachage

Un hachage est une empreinte numérique qui identifie un programme ou un fichier exécutable de façon unique, même si ce programme ou ce fichier est déplacé ou renommé. Les administrateurs peuvent faire appel à un hachage pour effectuer le suivi d'une version particulière d'un programme ou d'un fichier exécutable dont ils souhaitent interdire l'exécution aux utilisateurs.

Avec une règle de hachage, les logiciels restent identifiables de façon unique parce que la règle de hachage repose sur un calcul cryptographique faisant appel au contenu du fichier. Seuls les types de fichiers répertoriés dans la section Types de fichiers désignés du volet d'informations Stratégies de restriction logicielle sont concernés par les règles de hachage.

Les règles de hachage donnent les meilleurs résultats dans les environnements statiques. En cas de mise à niveau des logiciels de votre environnement, le hachage doit être recalculé pour chaque fichier exécutable mis à jour. Les règles de hachage conviennent plus particulièrement aux environnements dans lesquels les modifications et les mises à niveau de logiciels ne sont pas fréquentes.

Une règle de hachage comprend les trois éléments de données suivants, séparés par deux points :

  • la valeur de hachage MD5 ou SHA-1 ;

  • la longueur de fichier ;

  • le numéro d'identification de l'algorithme de hachage.

Les fichiers numériquement signés utilisent la valeur de hachage contenue dans la signature, à savoir MD5 ou SHA -1. Les fichiers exécutables qui ne sont pas numériquement signés utilisent une valeur de hachage MD5.

Les règles de hachage se présentent sous le format suivant :

[Valeur de hachage MD5 ou SHA1]:[longueur de fichier]:[identification de l’algorithme de hachage]

L’exemple de règle de hachage qui suit s’applique à un fichier de 126 octets dont le contenu correspond à la valeur de hachage MD5 (7bc04acc0d6480af862d22d724c3b049) et à l’algorithme de hachage (ce qui est indiqué par l’identificateur d’algorithme de hachage 32771) :

7bc04acc0d6480af862d22d724c3b049:126:32771

Chaque fichier que l’administrateur souhaite interdire ou autoriser doit contenir une règle de hachage. Après la mise à jour d'un logiciel, l'administrateur doit créer une nouvelle règle de hachage pour chaque application car les valeurs de hachage des fichiers exécutables d'origine ne correspondent pas à celles des nouveaux fichiers.

Suivez la procédure indiquée ci-dessous afin de créer une règle de hachage pour un fichier exécutable.

Pour créer une règle de hachage pour un fichier exécutable existant

  1. Dans la barre d'outils de l'Éditeur d'objets de stratégie de groupe, cliquez sur Paramètres Windows, Paramètres de sécurité, Stratégie de restriction logicielle, puis cliquez sur Règles supplémentaires avec le bouton droit.

  2. Cliquez sur Nouvelle règle de hachage dans le menu contextuel.

    Figure 6.1 Boîte de dialogue Nouvelle règle de hachage

  3. Cliquez sur Parcourir afin de sélectionner le fichier pour lequel créer une règle de hachage. Dans cet exemple, le fichier exécutable se nomme Excel.exe. La nouvelle valeur de hachage du fichier s'affiche dans le champ Fichier à hacher : et la version de l'application dans le champ Informations de fichier :.

  4. Sélectionnez le paramètre de niveau de sécurité par défaut à appliquer à cette règle. Les options sont les suivantes :

    • Rejeté

    • Non restreint

Règle de certificat

Une règle de certificat requiert l'existence d'un certificat d'éditeur de logiciel (utilisé pour la signature du code) pour qu'un programme soit autorisé à s'exécuter. Un administrateur peut exiger des certificats signés pour l'ensemble des scripts et des contrôles ActiveX, par exemple. Les sources habilitées pour une règle de certificat sont les suivantes :

  • Autorité de certification (CA) approuvée, telle que VeriSign.

  • Infrastructure de clés publiques (PKI, Public Key Infrastructure) Microsoft Windows 2000/Windows Server™ 2003.

  • Certificat auto-signé.

La règle de certificat constitue une excellente méthode d'identification des logiciels, car elle utilise les hachages signés de la signature du fichier signé pour comparer les fichiers, indépendamment de leur nom ou de leur emplacement. Malheureusement, peu de fournisseurs de logiciels utilisent la technologie de signature de code, et même ceux qui s'en servent ne signent généralement qu'un faible pourcentage des fichiers exécutables qu'ils distribuent. Pour cela, les règles de certificat sont généralement utilisées pour quelques types d'applications spécifiques tels que les contrôles ActiveX ou les applications développées en interne. Par exemple, ce guide recommande aux entreprises de signer numériquement les scripts utilisés pour la gestion des ordinateurs et des utilisateurs, afin que tous les scripts non signés soient bloqués. Une règle de hachage peut alors être utilisée pour identifier les exceptions à une règle de certificat.

Activation des règles de certificat

Les règles de certificat ne sont pas activées par défaut. Pour activer les règles de certificat, suivez les étapes de la procédure ci-dessous.

Pour activer les règles de certificat

  1. Ouvrez le GPO dans l'Éditeur d'objets de stratégie de groupe.

  2. Dans l'arborescence de la console, cliquez sur Options de sécurité.

  3. Dans le volet de détails, cliquez deux fois sur Paramètres systèmes : Appliquez les règles de certificat des exécutables Windows pour les stratégies de restriction logicielle.

  4. Cliquez sur Activé pour activer les règles de certificat.

Pour des instructions détaillées sur la façon de signer numériquement des fichiers, consultez la section « Step-by-Step Guide to Digitally Signing Files with Test Certificates » de l'article « Using Software Restriction Policies to Protect Against Unauthorized Software » à l'adresse www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx.

Bon nombre de sites Web commerciaux disposent de leurs propres certificats numériquement signés par une autorité de certification approuvée. Ces certificats sont généralement valables entre une et plusieurs années. Lorsque vous appliquez des règles de certificat, faites attention aux dates d'expiration des certificats. N'hésitez pas à vous adresser à l'éditeur du logiciel pour plus d'informations sur la date d'expiration d'un certificat publié. Lorsque vous recevez un certificat de la part d'une autorité de certification approuvée, vous pouvez l'exporter dans un fichier pour créer une règle de certificat. Pour exporter un certificat, suivez les étapes de la procédure ci-dessous.

Pour exporter un certificat

  1. Sélectionnez l'éditeur approuvé qui émettra le certificat. Dans cet exemple, il s'agit de Microsoft MSN®.

    Figure 6.2 Affichage de l’éditeur approuvé dans la boîte de dialogue Avertissement de sécurité

  2. Cliquez sur l'onglet Détails puis sur Copier dans un fichier... afin de copier ce certificat dans un fichier et de l'utiliser pour créer une règle de certificat.

    Figure 6.3 Onglet Détails de la boîte de dialogue Certificat

  3. La page d'accueil de l’Assistant Exportation de certificat s'affiche. Cliquez sur Suivant pour continuer.

    Figure 6.4 Page d'accueil de l’Assistant Exportation de certificat

  4. Dans la page Format de fichier d’exportation, sélectionnez Binaire codé DER X.509 (.cer) et cliquez sur Suivant pour créer le fichier de certificat portant une extension (.cer).

    Figure 6.5 Affichage de la méthode d’encodage sélectionnée dans la page Format de fichier d’exportation de l’Assistant Exportation de certificat

  5. Dans la page Fichier à exporter, désignez un nom de fichier de règle de certificat descriptif. Le certificat sera enregistré dans l'emplacement sélectionné et sous le nom que vous choisirez.

    Figure 6.6 Affichage d’un exemple de nom de fichier dans la page Fichier à exporter de l’Assistant Exportation de certificat

  6. La page Fin de l'Assistant Exportation de certificat affichera les paramètres spécifiés du fichier de certificat. Vérifiez les paramètres et cliquez sur Terminer pour exporter le fichier.

    Figure 6.7 Affichage des paramètres spécifiés dans la page Fin de l’Assistant Exportation de certificats

Règle de chemin d'accès

Une règle de chemin d'accès spécifie un dossier ou un chemin d'accès complet à un programme. Lorsqu'une règle spécifie un dossier, elle examine tous les programmes contenus dans ce dossier et dans les sous-dossiers de ce dossier. Les règles de chemin d'accès gèrent les chemins d'accès locaux et UNC.

L'administrateur doit définir, dans la règle de chemin d'accès, tous les répertoires à partir desquels une application spécifique sera lancée. Si un raccourci de bureau est utilisé pour lancer une application, par exemple, la règle de chemin d'accès doit indiquer à la fois le fichier exécutable et les chemins d'accès aux raccourcis pour exécuter cette application. Si un utilisateur tente d'exécuter une application avec seulement une règle de chemin d'accès partielle, l'avertissement Logiciel restreint s'affichera.

La plupart des applications utilisent la variable %ProgramFiles% pour installer des fichiers sur le disque dur des ordinateurs Windows XP. Malheureusement, certaines applications sont préprogrammées pour copier des fichiers dans le sous-répertoire C:\Program Files, même si cette variable est configurée sur un autre répertoire dans un autre lecteur. Tenez compte de cette limitation lorsque vous créez et testez des règles de chemin d'accès.

Utilisation de variables d'environnement dans les règles de chemin d'accès

Vous pouvez faire en sorte qu'une règle de chemin d'accès utilise des variables d'environnement. Les règles de chemin d'accès étant évaluées dans l'environnement client, les variables d'environnement permettent à un administrateur d'adapter une règle à l'environnement d'un utilisateur particulier.

Les deux exemples qui suivent illustrent le mode d'application de variables d'environnement à une règle de chemin d'accès.

  • « %UserProfile% » correspond à **C:\Documents and Settings\*<User>*****et à tous les sous-dossiers rattachés à ce répertoire.

  • « %ProgramFiles%\<Application> »**correspond à C:\Program Files\<Application> et à tous les sous-dossiers rattachés à ce répertoire.

    Remarque : Les variables d'environnement ne sont pas protégées par des listes de contrôle d'accès (ACL, Access Control List). Il existe deux types de variables d'environnement : Utilisateur et Système. Les utilisateurs capables de démarrer une invite de commandes peuvent redéfinir le chemin d'accès de la variable d'environnement Utilisateurs. Seuls les utilisateurs membres du groupe Administrateurs peuvent modifier la variable d'environnement Système.

Bien que les deux exemples précédents soient très utiles, vous pourriez souhaiter étudier les autres variables d'environnement disponibles. Pour une liste complète, reportez-vous à « Command shell overview » sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/windows/xp/all/proddocs/ en-us/ntcmds_shelloverview.mspx.

Utilisation de caractères génériques dans les règles de chemin d'accès

Les caractères génériques « ? » et « * » peuvent s'utiliser dans les règles de chemin d'accès. Dans les exemples qui suivent, des caractères génériques sont appliqués à différentes règles de chemin d'accès :

  • \\DC – ??\login$ correspond à \\DC – 01\login$, \\DC – 02\login$, etc.

  • *\Windows correspond à C:\Windows, D:\Windows, E:\Windows et à tous les sous-dossiers rattachés à chaque répertoire.

  • C:\win* correspond à C:\winnt, C:\windows, C:\windir et à tous les sous-dossiers rattachés à chaque répertoire.

  • *.vbs correspond à toute application possédant cette extension dans Windows XP Professionnel.

  • C:\Application Files\*.* correspond à tous les fichiers d'application placés dans le sous-répertoire désigné.

Règles de chemin d'accès au Registre

La plupart des applications stockent les chemins d'accès à leurs dossiers d'installation ou à leurs répertoires d'applications dans le Registre Microsoft Windows. Certaines applications peuvent être installées à n'importe quel emplacement du système de fichiers. Pour les localiser, vous pouvez créer une règle de chemin d'accès qui recherche les clés de Registre correspondantes.

L'identification de ces emplacements à l'aide de chemins d'accès à des dossiers spécifiques, tels que C:\Program Files\Microsoft Platform SDK, ou de variables d'environnement telles que %ProgramFiles%\Microsoft Platform SDK est parfois un peu difficile. Toutefois, si le programme stocke ses répertoires d'application dans le Registre, vous pouvez créer une règle de chemin d'accès qui utilisera la valeur présente dans le Registre, telle que :

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\ Install Dir%

Ce type de règle de chemin d'accès, appelé règle de chemin d'accès au Registre, se présente sous la forme :

%<Ruche du Registre>\<Nom de clé de Registre>\<Nom de la valeur>%

Remarque : Un caractère \ ne doit jamais être immédiatement placé à la suite du dernier signe % dans un suffixe de règle de chemin d'accès au Registre. Le nom de la ruche de Registre doit être écrit entièrement ; les abréviations restent sans effet.

Lorsque la règle par défaut prend la valeur Rejeté, quatre règles de chemin d'accès au Registre sont configurées pour que le système d'exploitation ait accès aux fichiers système. Ces règles de chemin d'accès sont créées à titre préventif, pour éviter que vous ou d'autres utilisateurs ne soyez interdits d'accès au système, et sont configurées sur Non restreint. Ces règles ne devraient être modifiées ou supprimées que par des utilisateurs avancés. Les paramètres d'une règle de chemin d'accès au Registre sont les suivants :

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
    CurrentVersion\SystemRoot%

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
    CurrentVersion\SystemRoot%\*.exe

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
    CurrentVersion\SystemRoot%\System32\*.exe

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
    CurrentVersion\ProgramFilesDir%

Priorité des règles de chemin d'accès

En présence de plusieurs règles de chemin d'accès valables, la règle la plus spécifique est prioritaire par rapport aux autres. Les chemins d'accès ci-dessous sont classés par ordre de priorité décroissante (de la correspondance la plus précise à la correspondance la plus générale) :

  • Lecteur:\Dossier1\Dossier2\NomFichier.Extension

  • Lecteur:\Dossier1\Dossier2\*.Extension

  • *.Extension

  • Lecteur:\Dossier1\Dossier2\

  • Lecteur:\Dossier1\

Règle de zone

Vous pouvez faire appel à une règle de zone pour identifier les logiciels qui sont téléchargés à partir de l'une des zones suivantes définies dans Internet Explorer :

  • Internet

  • Intranet

  • Sites sensibles

  • Sites de confiance

  • Poste de travail

La version actuelle de la règle de zone Internet s'applique exclusivement aux packages Windows Installer (*.msi). Cette règle ne s'applique donc pas aux logiciels qui sont téléchargés par le biais d'Internet Explorer. Tous les autres types de fichiers concernés par des règles de zone sont répertoriés dans le tableau Types de fichiers désignés, qui apparaît un peu plus loin dans ce chapitre. Une liste de types de fichiers désignés est partagée par l'ensemble des règles de zone.

Recommandations relatives aux règles

Reportez-vous aux informations du tableau ci-après pour déterminer le type de règle le mieux adapté aux utilisateurs et à l'environnement d'une application.

Tableau 6.1 Détermination de la règle la mieux adaptée à une application donnée

Tâche Règle recommandée
Autoriser ou interdire une version de programme spécifique. Règle de hachage
Sélectionnez le fichier pour lequel créer une règle de hachage.
Identifier un programme toujours installé au même emplacement. Règles de chemin d’accès avec variables d’environnement
%ProgramFiles%\Internet Explorer\iexplore.exe
Identifier un programme susceptible d’être installé à n'importe quel endroit sur les ordinateurs clients. Règle de chemin d’accès au Registre
%HKEY_LOCAL_MACHINE\SOFTWARE\ ComputerAssociates\InoculateIT\6.0\Path\HOME%
Identifier un ensemble de scripts sur un serveur central. Règle de chemin d’accès
\\SERVER_NAME\Share
Identifier un ensemble de scripts sur un groupe de serveurs (DC01, DC02 et DC03, par exemple). Règle de chemin d’accès avec caractère générique
\\DC??\Share
Interdire tous les fichiers .vbs, à l'exception de ceux qui se trouvent dans un répertoire de script de connexion. Règle de chemin d’accès avec caractère générique *.VBS doit prendre la valeur Rejeté \\LOGIN_SRV\Share\*.VBS doit prendre la valeur Non restreint
Interdire un fichier installé par un virus systématiquement appelé Flcss.exe. Règle de chemin d'accès Flcss.exe doit prendre la valeur Rejeté
Identifier un ensemble de scripts susceptibles d'être exécutés n'importe où. Règle de certificat Utilisez un certificat pour signer numériquement les scripts.
Autoriser l'installation de logiciels à partir de sites Internet de confiance. Règle de zone Le paramètre Sites de confiance doit prendre la valeur Non restreint.
Priorité des règles dans une stratégie de restriction logicielle

Les règles sont évaluées dans un ordre spécifique. Les règles qui correspondent le plus précisément à un programme sont prioritaires par rapport à celles qui se rapprochent de ce programme de façon plus générale. Si deux règles identiques présentant des niveaux de sécurité différents sont établies pour le même logiciel, la règle dont le niveau de sécurité est le plus élevé est prioritaire. Si deux règles de hachage (une avec le niveau de sécurité Rejeté et l'autre avec le niveau de sécurité Non restreint) sont appliquées au même logiciel, par exemple, la règle présentant le niveau de sécurité Rejeté est prioritaire et le programme n'est pas exécuté. L'ordre de priorité des règles (de la plus spécifique à la plus générale) s'établit comme suit :

  1. Règle de hachage

  2. Règle de certificat

  3. Règle de chemin d'accès

  4. Règle de zone

  5. Règle par défaut

Haut de page

Options disponibles pour les stratégies de restriction logicielle

Cette section présente les différentes options de contrôle qui influencent le mode de fonctionnement d'une stratégie de restriction logicielle. Ces options modifient la façon dont les paramètres d'approbation Microsoft Authenticode® sont appliqués pour les fichiers signés numériquement. Il existe deux options de contrôle : Contrôle des bibliothèques de liens dynamiques (DLL) et Ignorer les administrateurs.

Contrôle DLL

La plupart des programmes sont constitués par un fichier exécutable et plusieurs DLL de prise en charge. Les règles de stratégie de restriction logicielle ne sont par défaut pas appliquées aux DLL. Ce paramètre par défaut est recommandé à la plupart des clients pour trois raisons principales :

  • Si le fichier exécutable principal est rejeté, le programme ne pourra pas être exécuté : l'interdiction des DLL associées est donc inutile.

  • Le contrôle des DLL dégrade les performances du système car toutes les bibliothèques liées à l'application doivent être vérifiées. Si un utilisateur exécute 10 programmes au cours d'une session, par exemple, la stratégie de restriction logicielle évalue chaque programme. Lorsque le contrôle DLL est activé, la stratégie évalue chacune des DLL chargées avec chaque programme. Si chaque programme utilise 20 DLL, cette configuration provoquerait le contrôle de 10 programmes exécutables et de 200 DLL ; la stratégie de restriction logicielle devrait donc procéder à 210 évaluations.

    Un programme tel qu'Internet Explorer comprend un fichier exécutable (iexplore.exe) et plusieurs DLL liées.

  • Si le paramètre de sécurité par défaut est configuré sur Rejeté, le système devra identifier non seulement le fichier exécutable principal avant d'autoriser son exécution, mais également toutes les DLL associées au fichier .exe, ce qui accroît la charge de travail du système.

Étant donné que les virus s'attaquent principalement aux fichiers exécutables, certains visent plus précisément les DLL. Le contrôle DLL est donc l'option recommandée si vous souhaitez obtenir les meilleures garanties possibles pour les programmes exécutés dans votre environnement.

Pour vous assurer qu'un programme ne contient pas de virus, vous pouvez faire appel à un ensemble de règles de hachage qui identifient le fichier exécutable et l'ensemble des DLL qui lui sont associées.

Pour désactiver l'option de contrôle DLL :

  • Lorsque vous modifiez une stratégie de restriction logicielle, sélectionnez, dans la boîte de dialogue Propriétés de contrôle, Tous les fichiers logiciels à l'exception des bibliothèques (tels que les fichiers DLL), comme l'illustre la figure suivante :

    Figure 6.8 Affichage des options de contrôle des fichiers et des utilisateurs dans la boîte de dialogue Propriétés de contrôle

Ignorer les administrateurs

Vous pouvez interdire l'exécution de certains programmes à la plupart des utilisateurs, tout en autorisant les administrateurs à les exécuter. Prenons l'exemple d'un ordinateur partagé auquel plusieurs utilisateurs se connectent par le biais de Terminal Server et supposons que l'administrateur souhaite limiter les utilisateurs à l'exécution de certaines applications spécifiques sur l'ordinateur, tout en permettant aux membres du groupe Administrateurs local d'accéder à l'ensemble des programmes. Utilisez l'option de contrôle Ignorer les administrateurs pour y parvenir.

Si la stratégie de restriction logicielle est créée dans un objet de stratégie de groupe lié à un objet Active Directory, Microsoft recommande de refuser l'autorisation Appliquer la stratégie de groupe sur l'objet de stratégie de groupe au groupe Administrateurs et de ne pas recourir à l'option Ignorer les administrateurs. Cette méthode est moins exigeante en bande passante réseau car les paramètres de l'objet de stratégie de groupe qui ne s'appliquent pas aux administrateurs ne sont pas téléchargés.

Remarque : Les stratégies de restriction logicielle définies dans des objets de stratégie de sécurité locaux ne permettent pas le filtrage des groupes d'utilisateurs et nécessitent donc l'utilisation de l'option Ignorer les administrateurs.

Pour activer l'option Ignorer les administrateurs :

  • Dans la boîte de dialogue Propriétés de contrôle (présentée dans la figure 6.8), sélectionnez Tous les utilisateurs exceptés les administrateurs locaux.
Définition de fichiers exécutables

La boîte de dialogue Propriétés de Types de fichiers désignés, représentée sur la figure suivante, dresse la liste des types de fichiers régis par la stratégie de restriction logicielle. Ces types de fichiers sont considérés comme des fichiers exécutables. Un fichier d'écran de veille (.scr), par exemple, est considéré comme un fichier exécutable parce qu'il se charge comme un programme lorsque vous double-cliquez dessus dans l'Explorateur Windows.

Les règles de stratégie de restriction logicielle s'appliquent uniquement aux types de fichiers répertoriés dans la boîte de dialogue Propriétés de Types de fichiers désignés. Si votre environnement utilise un type de fichier auquel vous souhaitez appliquer les règles, ajoutez-le à la liste. Pour les fichiers de script Perl, par exemple, vous pouvez choisir d'ajouter les fichiers .pl et autres types de fichiers associés au moteur Perl à la liste Types de fichiers désignés : dans l'onglet Général de la boîte de dialogue Propriétés de Types de fichiers désignés.

Figure 6.9 Boîte de dialogue Propriétés des types de fichiers désignés

Pour la conception d'objets de stratégie de groupe définie dans ce guide, les types de fichiers .mdb et .Ink sont supprimés et .ocx est ajouté. Le tableau suivant dresse la liste des types de fichiers désignés.

Tableau 6.2 Types de fichiers désignés

Extension de fichier Description Extension de fichier Description
.ade Extension de projet Microsoft Access .msc Document de console commune Microsoft
.adp Projet Microsoft Access .msi Package Windows Installer
.bas Module de classe Visual Basic .msp Correctif Windows Installer
.bat Fichier de commandes .mst Fichier source Visual Test
.chm Fichier d’aide HTML compilé .ocx Contrôle ActiveX
.cmd Script de commande Windows NT .pcd Image Photo CD
.com Application MS-DOS .pif Raccourci vers un programme MS-DOS
.cpl Extension du Panneau de configuration .reg Entrée de registre
.crt Certificat de sécurité .scr Ecran de veille
.exe Application .sct Composant Windows Script
.hlp Fichier d’aide Windows .shs Objet Bribes
.hta Application HTML .url Raccourci Internet (Uniform Resource Locator, URL)
.inf Fichier d’informations d’installation .vb Fichier Visual Basic
.ins Paramètres Communication Internet .vbe Fichier script crypté VBScript
.isp Paramètres Communication Internet .vbs Fichier script VBScript
.js Fichier JScript .wsc Composant Windows Script
.jse Fichier script crypté JScript .wsf Fichier Windows Script
.mde Base de données MDE Microsoft Access .wsh Fichier de paramètres d’hôte de script Windows
##### Éditeurs approuvés La boîte de dialogue **Propriétés des Éditeurs approuvés** permet de configurer les utilisateurs autorisés à sélectionner des éditeurs approuvés. Vous pouvez également déterminer les éventuels contrôles de révocation de certificats à effectuer avant d'approuver un éditeur. Lorsque les règles de certificat sont activées, la stratégie de restriction logicielle s'assure, en examinant une liste de révocation de certificats (CRL), que le certificat et la signature du logiciel sont valables. Ce processus peut néanmoins avoir une incidence négative sur les performances, au démarrage des programmes signés. Les options disponibles dans l'onglet **Général** de la boîte de dialogue **Propriétés des Éditeurs approuvés**, représentée sur la figure suivante, vous permettent de définir les paramètres relatifs aux contrôles ActiveX et autres contenus signés. [![](images/Cc163080.XPSG0610(fr-fr,TechNet.10).jpg)](https://technet.microsoft.com/fr-fr/cc163080.xpsg0610_big(fr-fr,technet.10).jpg) **Figure 6.10 Boîte de dialogue Propriétés des Éditeurs approuvés** Le tableau ci-après récapitule les paramètres d'éditeurs approuvés liés aux contrôles ActiveX et autres contenus signés. **Tableau 6.3 Tâches et paramètres relatifs aux éditeurs approuvés**

Nom du paramètre Tâche
Administrateurs de l’entreprise Sélectionnez cette option pour que seuls les administrateurs de l'entreprise soient autorisés à prendre des décisions relatives aux contenus actifs signés.
Administrateurs de l’ordinateur local Sélectionnez cette option pour autoriser les administrateurs de l'ordinateur local à prendre toutes les décisions relatives aux contenus actifs signés.
Utilisateurs finaux Sélectionnez cette option pour autoriser les utilisateurs à prendre des décisions relatives aux contenus actifs signés.
Éditeur Sélectionnez cette option pour vous assurer que le certificat utilisé par l'éditeur du logiciel n'a pas été révoqué.
Horodateur Sélectionnez cette option pour vous assurer que le certificat que l'entreprise utilise pour l'horodatage des contenus actifs n'a pas été révoqué.
[](#mainsection)[Haut de page](#mainsection) ### Conception et déploiement d'une stratégie de restriction logicielle Cette section décrit le processus d'administration d'une stratégie de restriction logicielle à l'aide des composants logiciels enfichables Stratégie de groupe, les éléments à prendre en considération lors de la première modification d'une stratégie et les modalités d'application d'une stratégie de restriction logicielle à un groupe d'utilisateurs. Elle traite également des différentes questions liées au déploiement d'une stratégie de restriction logicielle. #### Intégration aux stratégies de groupe Vous pouvez administrer une stratégie de restriction logicielle à l'aide des composants logiciels enfichables Stratégie de groupe appliqués à un ensemble d'ordinateurs clients, ainsi qu'à tous les utilisateurs qui se connectent aux ordinateurs. La stratégie est appliquée à l'UO de bureau et à l'UO de portable définies dans ce guide. ##### Domaine L'administrateur doit créer un objet de stratégie de groupe distinct pour la stratégie de restriction logicielle. Cette méthode permet de désactiver la stratégie de groupe sans aucune incidence sur les autres stratégies appliquées à l'objet en cas de problème imprévu. ##### Stratégie locale Une stratégie locale devrait être configurée pour les ordinateurs clients autonomes de votre environnement comme cela est décrit dans le chapitre 5, « Sécurisation des clients autonomes Windows XP », de ce guide. #### Conception d'une stratégie Cette section décrit les différentes étapes de la conception et du déploiement d'une stratégie de restriction logicielle. La conception de la stratégie suppose la prise d'un certain nombre de décisions, celles-ci étant détaillées dans le tableau ci-après. **Tableau 6.4. Considérations importantes relatives à la conception d'une stratégie**

Décision Facteurs à prendre en considération
Ordinateurs portables ou postes de travail Identifiez les exigences des utilisateurs mobiles de votre environnement pour déterminer si les ordinateurs portables nécessitent une stratégie différente de celle des ordinateurs de bureau. Les ordinateurs portables exigent généralement une plus grande souplesse.
Partages de serveur, scripts de connexion et lecteurs de base. Vous devrez définir une règle de chemin d'accès pour toutes les applications démarrées à partir d'un partage de serveur ou d'un répertoire de base. Vous pouvez ajouter des fichiers de script de connexion à la règle de chemin d'accès. Si un script appelle un autre script, ajoutez également les emplacements des fichiers exécutables à la règle de chemin d'accès.
Objet de stratégie de groupe ou stratégie de sécurité locale Dans ce guide, nous avons utilisé un objet de stratégie de groupe dans le cadre de la conception. Néanmoins, tenez compte des conséquences de la stratégie locale dans votre cas de figure.
Stratégie utilisateur ou ordinateur Ce modèle de conception applique tous les paramètres au niveau de l'ordinateur.
Niveau de sécurité par défaut Nous vous recommandons de sélectionner le paramètre par défaut Rejeté, puis de définir les autres options de la stratégie en conséquence. Le paramètre par défaut Non restreint est également disponible.
Règles supplémentaires Vous devez au besoin appliquer des règles de chemin d'accès au système d'exploitation supplémentaires lorsque vous employez la stratégie par défaut Rejeté. Dans la configuration Rejeté, les quatre règles sont automatiquement créées.
Options de stratégie Si vous utilisez une stratégie de sécurité locale et ne souhaitez pas qu'elle s'applique aux administrateurs sur les ordinateurs clients de votre environnement, sélectionnez l'option de contrôle de stratégie Ignorer les administrateurs. Si vous souhaitez vérifier les DLL ainsi que les scripts et les fichiers exécutables, sélectionnez l'option de contrôle de stratégie Contrôle DLL. Si vous souhaitez établir des règles pour des types de fichiers qui ne se trouvent pas dans la liste de types de fichiers désignés par défaut, optez pour leur ajout manuel dans la boîte de dialogue Propriétés des Types de fichiers désignés. Pour sélectionner les utilisateurs autorisés à prendre les décisions relatives au téléchargement de contrôles ActiveX et autres contenus signés, cochez la case Éditeur dans l'onglet Général de la boîte de dialogue Propriétés des Éditeurs approuvés.
Application de la stratégie à un site, domaine ou UO La stratégie réside au-dessous de l'UO d'appartenance des ordinateurs de bureau et des ordinateurs portables.
**Remarque** : Bien que ce guide recommande l'application de la stratégie de restriction logicielle au niveau de l'ordinateur, il existe un grand nombre de cas pour lesquels une application au niveau de l'utilisateur serait logique. Par exemple, une entreprise dotée d'ordinateurs partagés, tels que des serveurs d'applications Terminal Server ou des postes de travail de centres d'appels, pourrait souhaiter autoriser certains utilisateurs à exécuter une suite d'applications, mais bloquer l'accès à tous les autres. ##### Méthodes recommandées Microsoft vous recommande de créer un objet de stratégie de groupe distinct pour la stratégie de restriction logicielle, de façon à minimiser l'impact sur le reste de votre domaine ou sur les stratégies locales si vous deviez désactiver la stratégie en urgence. De même, si vous verrouillez accidentellement une station de travail avec une stratégie de restriction logicielle lors de la phase de conception de votre UO, redémarrez l'ordinateur en **Mode sans échec**, connectez-vous en tant qu'administrateur local, puis modifiez la stratégie. La stratégie de restriction logicielle n'est pas appliquée lorsque vous démarrez Windows en **Mode sans échec**. Après avoir démarré l'ordinateur en **Mode sans échec**, exécutez Gpupdate.exe, puis redémarrez l'ordinateur. Pour optimiser la sécurité, utilisez des listes de contrôle d'accès conjointement à la stratégie de restriction logicielle et n'accordez pas de privilèges d'administrateur aux utilisateurs. Certains utilisateurs peuvent tenter de renommer ou de déplacer les fichiers non autorisés ou d'écraser les fichiers non restreints afin de contourner une stratégie de restriction logicielle. Faites appel à des listes de contrôle d'accès pour interdire l'accès aux utilisateurs et les empêcher d'effectuer ces opérations. Les utilisateurs appartenant au groupe **Administrateurs** local pourront contourner la mise en œuvre de votre stratégie de restriction logicielle. Microsoft vous recommande donc, lorsque c'est possible, de ne pas donner de privilèges d'administration aux utilisateurs. Les scripts de connexion sont généralement placés au-dessous du dossier SUSVOL, sur le contrôleur de domaine ou sur un serveur centralisé. Il arrive souvent que le contrôleur de domaine change avec chaque connexion. Si votre règle par défaut prend la valeur **Rejeté**, veillez à créer des règles qui identifient les emplacements de vos scripts de connexion. Si les serveurs d'accès possèdent des noms similaires, recourez à des caractères génériques pour les localiser, ou utilisez le nom du script de connexion avec des paramètres non restreints. **Remarque** : Testez minutieusement les nouveaux paramètres de stratégie de restriction logicielle dans des environnements de test avant de les appliquer à votre domaine. Ces nouveaux paramètres peuvent parfois en effet avoir un comportement inattendu. Des tests approfondis vous permettront de réduire les risques de problèmes lors du déploiement des paramètres de stratégie de restriction logicielle sur votre réseau. #### Étapes de la procédure Utilisez les informations ci-dessous pour concevoir votre stratégie de restriction logicielle et l'appliquer, sous forme d'objet de stratégie de groupe, aux ordinateurs portables et ordinateurs de bureau de votre environnement. ##### Étape 1. Créez un objet de stratégie de groupe pour l'unité d'organisation Localisez l'UO créée pour les ordinateurs de bureau ou ordinateurs portables de votre environnement. Si vous travaillez sur un ordinateur client autonome, les paramètres de stratégie se trouvent dans la stratégie de l'ordinateur local. Dans cette stratégie, cliquez sur **Propriétés**, puis créez un nouvel objet de stratégie de groupe. Attribuez un nom à la stratégie, en respectant les conventions de noms de votre organisation. N'oubliez pas que cette stratégie sera exclusivement utilisée pour appliquer des restrictions logicielles. ##### Étape 2. Définissez la stratégie de restriction logicielle Sélectionnez l'objet de stratégie de groupe et cliquez sur **Modifier**. Sélectionnez **Windows Settings\\Security Settings\\Software Restriction Policy** dans l'arborescence. Lorsque vous modifiez la stratégie pour la première fois, le message : Aucune stratégie de restriction logicielle n'a été définie s'affiche. Ce message vous signale que vous allez définir des valeurs par défaut lors la création d'une stratégie. Ces valeurs par défaut risquent de remplacer les paramètres de stratégie définis dans d'autres stratégies de restriction logicielle. Comme vous n'avez encore défini aucun paramètre de stratégie de restriction logicielle, acceptez les valeurs par défaut pour commencer. Cliquez sur le menu **Actions** avec le bouton droit et sélectionnez **Nouvelles stratégies de restriction logicielle**. ##### Étape 3. Configurez les règles de chemin d'accès Après avoir déterminé les applications et les scripts utilisés par chaque station de travail, vous pouvez définir les règles de chemin d'accès. Certains programmes lancent d'autres programmes pour exécuter des tâches. Les applications installées dans votre environnement peuvent dépendre d'un ou de plusieurs programmes prenant en charge d'autres programmes. Un récapitulatif des logiciels installés, accompagné des informations d'installation correspondantes, peut s'avérer extrêmement utile pour le suivi des règles de chemin d'accès. Voici un exemple de structure pour un poste de travail : - Applications = \*\\Program Files - Applications de groupe partagées = g:\\Group Applications - Script de connexion = Logon.bat - Raccourcis du Bureau = \*.lnk - Scripts VBS approuvés =\*.vbs ##### Étape 4. Définissez les options de stratégie Les options suivantes présentent les paramètres de stratégie recommandés pour la conception définie dans ce guide. Ces options modifient le champ d'application des paramètres d'approbation Authenticode pour les fichiers numériquement signés. - **Contrôle obligatoire**. Si l'ordinateur est membre du domaine, assurez-vous que le groupe **Admins du domaine** est automatiquement ajouté au groupe **Administrateurs**. - **Appliquer aux utilisateurs**. Inclut tous les utilisateurs à l'exception des administrateurs locaux. L'utilisation de cette option retarde le lancement de chaque application. Pour compenser ce retard, le programme est conçu pour configurer la stratégie de façon à ce qu'elle ne vérifie pas les DLL. - **Appliquer aux fichiers**. Inclut tous les fichiers d'application exception faite des bibliothèques (DLL, par exemple). L'utilisation de cette option retarde le lancement de chaque application. Pour compenser ce retard, le programme est conçu pour configurer la stratégie de façon à ce qu'elle ne vérifie pas les DLL. - **Types de fichiers désignés**. Pour la conception d'objets de stratégie de groupe définie dans ce guide, les fichiers .ocx ont été ajoutés à la liste et les types de fichiers .mdb et .Ink ont été supprimés. Vous pouvez ajouter des extensions de types de fichiers d'applications personnalisées pour les assujettir aux mêmes règles. - **Éditeurs approuvés**. Pour la conception d'objets de stratégie de groupe définie dans ce guide, le groupe **Administrateurs** a été activé et l'option **Propriétés des Éditeurs approuvés : Administrateurs de l'ordinateur local** sélectionnée. Avant d'approuver un éditeur, sélectionnez l'option **Vérifier : Éditeur** lors de la conception de l'objet de stratégie de groupe pour veiller à ce que la stratégie procède à la validation des certificats. ##### Étape 5. Appliquez les paramètres par défaut Il est recommandé d'appliquer le paramètre par défaut **Non restreint** à la stratégie. Vous avez ainsi la garantie que la stratégie est correctement initialisée avant l'application des restrictions logicielles. Après avoir vérifié les paramètres de la stratégie, rétablissez la valeur par défaut **Rejeté**. ##### Étape 6. Testez la stratégie Si l'ordinateur fait partie d'un domaine, déplacez-le vers le conteneur d'UO auquel la stratégie est appliquée. Redémarrez l'ordinateur de test et ouvrez une session. Les plans de test indiquent généralement le comportement attendu pour chaque programme lors de l'application de la stratégie. Exécutez les applications pour vous assurer qu'elles fonctionnent parfaitement et que vous avez accès à l'ensemble de leurs fonctionnalités. Après avoir vérifié le bon fonctionnement des applications, simulez une attaque pour vous assurer que la stratégie ne présente aucune faille de sécurité. Si l'ordinateur est un client autonome, connectez-vous à l'ordinateur de test et suivez votre plan de test. Après avoir vérifié les applications, simulez une nouvelle attaque pour vous assurer que la stratégie ne présente aucune faille de sécurité. #### Déploiement d'une stratégie de restriction logicielle Après avoir minutieusement testé la stratégie, appliquez-la à l'UO d'ordinateurs de bureau ou d'ordinateurs portables de votre environnement. S'il s'agit d'un ordinateur client autonome, appliquez-la aux paramètres de l'ordinateur local sur le client. Ouvrez le composant logiciel enfichable Ordinateurs et utilisateurs de la console MMC et parcourez l'arborescence jusqu'au conteneur de l'UO qui renferme les ordinateurs de bureau ou les ordinateurs portables. Créez ensuite le nouvel objet de stratégie de groupe à l'aide de l'Éditeur d'objets de stratégie de groupe. Modifiez les propriétés et appliquez les paramètres de stratégie voulus à la **stratégie de restriction logicielle**, dans le dossier **Windows Settings\\Security Settings**, en vous appuyant sur les informations des tableaux ci-après. **Tableau 6.5 Niveaux de sécurité**

Règle par défaut dans l'interface utilisateur Description Paramètre
Rejeté Le logiciel n'est pas exécuté, indépendamment des droits d'accès de l'utilisateur. Utilisez cette règle par défaut
**Tableau 6.6 Règles supplémentaires**

Règle de chemin d'accès Paramètre
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\SystemRoot% Non restreint
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\SystemRoot%\*.exe Non restreint
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\SystemRoot%\System32\*.exe Non restreint
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\ProgramFilesDir% Non restreint
*.vbs Rejeté
G:\Group Applications Non restreint
Logon.bat ou script de connexion Non restreint
*\Program Files Non restreint
**Tableau 6.7 Contrôle sur les fichiers et les utilisateurs**

Options de contrôle Recommandation
Appliquer les stratégies de restriction logicielle aux fichiers suivants : Tous les fichiers logiciels à l'exception des DLL.
Appliquer les stratégies de restriction logicielle aux utilisateurs suivants : Tous les utilisateurs à l'exception des administrateurs locaux.
**Tableau 6.8 Types de fichiers désignés**

Types de fichiers Recommandation
Propriétés des types de fichiers désignés Supprimez les types de fichiers .mdb et .Ink et ajoutez les fichiers .ocx.
**Tableau 6.9 Éditeurs approuvés**

Éditeurs approuvés Recommandation
Autorisez les groupes d'utilisateurs suivants à sélectionner des éditeurs approuvés : Administrateurs de l’ordinateur local
Déterminez si le certificat est révoqué. Sélectionnez l'option Éditeur.
[](#mainsection)[Haut de page](#mainsection) ### Résumé Les stratégies de restriction logicielle fournissent aux administrateurs un moyen efficace pour identifier et limiter les logiciels susceptibles d'être exécutés sur les postes de travail Windows XP Professionnel d'un domaine. Vous pouvez créer des stratégies pour bloquer les scripts malveillants, verrouiller de diverses façons les ordinateurs de votre environnement ou interdire l'exécution de certaines applications. Dans une entreprise, il est d'usage de gérer les stratégies de restriction logicielle par le biais d'objets de stratégie de groupe, puis de personnaliser chaque stratégie en fonction des exigences des différents groupes d'utilisateurs et ordinateurs. Microsoft vous déconseille de gérer des groupes d'utilisateurs dans un environnement autonome. Lorsqu'elle est correctement appliquée, une stratégie de restriction logicielle améliore l'intégrité et la souplesse de gestion des ordinateurs de votre organisation et se traduit au final par une réduction des coûts de possession et de maintenance des systèmes d'exploitation présents sur ces ordinateurs. #### Informations complémentaires Les liens suivants permettent d'obtenir des informations complémentaires concernant les questions de sécurité liées à Windows XP Professionnel. - Pour plus d'informations sur la stratégie de restriction logicielle, consultez l'article « [Using Software Restriction Policies to Protect Against Unauthorized Software](http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx) » à l'adresse www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx. - Pour plus d'informations sur la stratégie de groupe, lisez l'article « [Windows 2000 Group Policy](http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp) » à l'adresse www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp. ##### Téléchargez ![](images/Cc163080.icon_exe(fr-fr,TechNet.10).gif)[Télécharger le Guide de sécurité de Windows XP](http://go.microsoft.com/fwlink/?linkid=14840) [](#mainsection)[Haut de page](#mainsection)
  • Last updated on