Vue d’ensemble technique des stratégies de restriction logicielle
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Cette rubrique décrit les stratégies de restriction logicielle, quand et comment utiliser la fonctionnalité, les modifications qui ont été implémentées dans les versions précédentes, et fournit des liens vers des ressources supplémentaires pour vous aider à créer et déployer des stratégies de restriction logicielle à partir de Windows Server 2008 et Windows Vista.
Introduction
Les stratégies de restriction logicielle fournissent aux administrateurs un mécanisme piloté par stratégie de groupe pour identifier les logiciels et contrôler leur capacité à s’exécuter sur l’ordinateur local. Ces stratégies peuvent être utilisées pour protéger les ordinateurs exécutant des systèmes d’exploitation Microsoft Windows (à compter de Windows Server 2003 et Windows XP Professionnel) contre les conflits connus et protéger les ordinateurs contre les menaces de sécurité telles que les virus malveillants et les programmes de chevaux de Troie. Les stratégies de restriction logicielle peuvent aussi contribuer à créer une configuration fortement restreinte pour vos ordinateurs, dans laquelle seule l’exécution d’applications clairement identifiées est autorisée. Les stratégies de restriction logicielle sont intégrées à Microsoft Active Directory et à la stratégie de groupe. Vous avez également la possibilité de créer des stratégies de restriction logicielle sur des ordinateurs autonomes.
Les stratégies de restriction logicielle sont des stratégies d’approbation, c’est-à-dire des règles définies par un administrateur pour limiter des scripts et d’autres formes de code qui n’apparaissent pas entièrement fiables depuis l’exécution. L’extension Stratégies de restriction logicielle de l’éditeur de stratégie de groupe local fournit une interface utilisateur unique grâce à laquelle les paramètres permettant de restreindre l’utilisation des applications peuvent être gérés sur l’ordinateur local ou dans un domaine.
Procédures
Administrer les stratégies de restriction logicielle
Résoudre les problèmes liés aux stratégies de restriction logicielle
Scénarios d’utilisation de la stratégie de restriction logicielle
Les utilisateurs professionnels collaborent à l’aide de la messagerie électronique, de la messagerie instantanée et des applications d’égal à égal. À mesure que ces collaborations augmentent, en particulier avec l’utilisation d’Internet dans l’informatique d’entreprise, il en va de même pour les menaces du code malveillant, telles que les vers, les virus et les menaces malveillantes des utilisateurs ou des attaquants.
Les utilisateurs peuvent recevoir du code hostile sous de nombreuses formes, allant des fichiers exécutables Windows natifs (fichiers .exe), aux macros dans les documents (tels que les fichiers .doc) en passant par les scripts (tels que les fichiers .vbs). Les utilisateurs malveillants ou les attaquants utilisent souvent des méthodes d’ingénierie sociale pour amener les utilisateurs à exécuter du code contenant des virus et des vers. (L’ingénierie sociale est un terme permettant d’inciter les gens à révéler leur mot de passe ou une forme d’informations de sécurité.) Si ce code est activé, il peut générer des attaques par déni de service sur le réseau, envoyer des données sensibles ou privées à Internet, mettre en danger la sécurité de l’ordinateur ou endommager le contenu du disque dur.
Les organisations informatiques et les utilisateurs doivent être en mesure de déterminer les logiciels qui peuvent être exécutés en toute sécurité et ceux qui ne l’sont pas. Avec le grand nombre et les formes que le code hostile peut prendre, cela devient une tâche difficile.
Pour protéger leurs ordinateurs réseau contre le code hostile et les logiciels inconnus ou non pris en charge, les organisations peuvent implémenter des stratégies de restriction logicielle dans le cadre de leur stratégie de sécurité globale.
Les administrateurs peuvent faire appel aux stratégies de restriction logicielle pour la réalisation des tâches suivantes :
Définir ce qu’est un code de confiance
Concevoir une stratégie de groupe souple réglementant les scripts, les fichiers exécutables et les contrôles ActiveX
Les stratégies de restriction logicielle sont mises en place par le système d’exploitation et par des applications (notamment les applications d’exécution de scripts) conformes aux stratégies de restriction logicielle.
Les administrateurs peuvent en particulier faire appel aux stratégies de restriction logicielle pour la réalisation des tâches suivantes :
Spécifier quels logiciels (fichiers exécutables) peuvent être exécutés sur les ordinateurs clients
Empêcher les utilisateurs d’exécuter des programmes spécifiques sur des ordinateurs partagés
Préciser les personnes autorisées à ajouter des éditeurs approuvés sur les ordinateurs clients
Définir la portée des stratégies de restriction logicielle (préciser si elles affectent tous les utilisateurs ou un sous-ensemble d’utilisateurs sur les ordinateurs clients)
Empêcher l’exécution des fichiers exécutables sur l’ordinateur local, l’unité d’organisation, le site ou le domaine. Ceci peut s’avérer judicieux dans des cas où vous n’avez pas recours aux stratégies de restriction logicielle pour résoudre d’éventuels problèmes liés à des utilisateurs malveillants.
Différences et modifications dans les fonctionnalités
Il n’y a aucune modification des fonctionnalités dans SRP pour Windows Server 2012 et Windows 8.
Versions prises en charge
Les stratégies de restriction logicielle ne peuvent être configurées et appliquées qu’aux ordinateurs exécutant au moins Windows Server 2003, y compris Windows Server 2012 et au moins Windows XP, y compris Windows 8.
Notes
Certaines éditions du système d’exploitation client Windows commençant par Windows Vista n’ont pas de stratégies de restrictions logicielles. Les ordinateurs non administrés dans un domaine par stratégie de groupe peuvent ne pas recevoir de stratégies distribuées.
Comparaison des fonctions de contrôle d’application dans les stratégies de restriction logicielle et AppLocker
Le tableau suivant compare les fonctions et fonctionnalités de la fonctionnalité Stratégies de restriction logicielle (SRP) et d'AppLocker.
| Fonction de contrôle de l'application | SRP | AppLocker |
|---|---|---|
| Étendue | Les stratégies SRP peuvent être appliquées à tous les systèmes d'exploitation Windows à compter de Windows XP et de Windows Server 2003. | Les stratégies AppLocker s’appliquent uniquement à Windows Server 2008 R2, Windows Server 2012, Windows 7 et Windows 8. |
| Création d’une stratégie | Les stratégies SRP sont conservées via stratégie de groupe et seul l’administrateur de l’objet de stratégie de groupe peut mettre à jour la stratégie SRP. L’administrateur sur l’ordinateur local peut modifier les stratégies SRP définies dans l’objet de stratégie de groupe local. | Les stratégies AppLocker sont conservées via stratégie de groupe et seul l’administrateur de l’objet de stratégie de groupe peut mettre à jour la stratégie. L’administrateur sur l’ordinateur local peut modifier les stratégies AppLocker définies dans l’objet de stratégie de groupe local. AppLocker permet la personnalisation des messages d’erreur pour diriger les utilisateurs vers une page Web pour obtenir de l’aide. |
| Maintenance des stratégies | Les stratégies SRP doivent être mises à jour à l’aide du composant logiciel enfichable Stratégie de sécurité locale (si les stratégies sont créées localement) ou de la console de gestion stratégie de groupe (GPMC). | Les stratégies AppLocker peuvent être mises à jour à l’aide du composant logiciel enfichable Stratégie de sécurité locale (si les stratégies sont créées localement) ou de la console GPMC ou des applets de commande AppLocker Windows PowerShell. |
| Application de stratégie | Les stratégies SRP sont distribuées via stratégie de groupe. | Les stratégies AppLocker sont distribuées via stratégie de groupe. |
| Mode d’application | SRP fonctionne en « mode liste de refus », où les administrateurs peuvent créer des règles pour les fichiers qu’ils ne souhaitent pas autoriser dans cette entreprise, tandis que le reste du fichier est autorisé à s’exécuter par défaut. SRP peut également être configuré en « mode liste verte » de sorte que tous les fichiers sont bloqués par défaut et que les administrateurs doivent créer des règles d’autorisation pour les fichiers qu’ils souhaitent autoriser. |
AppLocker fonctionne par défaut en « mode liste verte » où seuls les fichiers sont autorisés à s’exécuter pour lesquels il existe une règle d’autorisation correspondante. |
| Types de fichiers pouvant être contrôlés | SRP peut contrôler les types de fichiers suivants : - Exécutables SRP ne peut pas contrôler chaque type de fichier séparément. Toutes les règles SRP se trouvent dans une seule collection de règles. |
AppLocker peut contrôler les types de fichiers suivants : - Exécutables AppLocker gère une collection de règles distincte pour chacun des cinq types de fichiers. |
| Types de fichiers désignés | SRP prend en charge une liste extensible de types de fichiers considérés comme exécutables. Les administrateurs peuvent ajouter des extensions pour les fichiers qui doivent être considérés comme exécutables. | AppLocker ne le prend pas en charge. AppLocker prend actuellement en charge les extensions de fichier suivantes : - Exécutables (.exe, .com) |
| Types de règles | SRP prend en charge quatre types de règles : - Hash |
AppLocker prend en charge trois types de règles : - Hash |
| Modification de la valeur de hachage | SRP permet aux administrateurs de fournir des valeurs de hachage personnalisées. | AppLocker calcule la valeur de hachage elle-même. En interne, il utilise le hachage SHA1 Authenticode pour les exécutables portables (Exe et Dll) et programmes d’installation Windows, ainsi qu’un hachage de fichier plat SHA1 pour le reste. |
| Prise en charge de différents niveaux de sécurité | Avec SRP, les administrateurs peuvent spécifier les autorisations avec lesquelles une application peut s’exécuter. Ainsi, un administrateur peut configurer une règle telle que le bloc-notes s’exécute toujours avec des autorisations restreintes et jamais avec des privilèges d’administration. SRP sur Windows Vista et les versions antérieures prenait en charge plusieurs niveaux de sécurité. Sur Windows 7, cette liste était limitée à deux niveaux seulement : Non autorisé et Non restreint (Utilisateur de base se traduit par Non autorisé). |
AppLocker ne prend pas en charge les niveaux de sécurité. |
| Gérer les applications empaquetées et les programmes d’installation d’applications empaquetées | Impossible | .appx est un type de fichier valide qu’AppLocker peut gérer. |
| Ciblage d’une règle vers un utilisateur ou un groupe d’utilisateurs | Les règles SRP s’appliquent à tous les utilisateurs sur un ordinateur particulier. | Les règles AppLocker peuvent être ciblées sur un utilisateur spécifique ou un groupe d’utilisateurs. |
| Prise en charge des exceptions de règle | SRP ne prend pas en charge les exceptions de règle | Les règles AppLocker peuvent comporter des exceptions qui permettent aux administrateurs de créer des règles telles que « Autoriser tout à partir de Windows à l’exception des Regedit.exe ». |
| Prise en charge du mode audit | SRP ne prend pas en charge le mode audit. La seule façon de tester les stratégies SRP consiste à configurer un environnement de test et à exécuter quelques expériences. | AppLocker prend en charge le mode audit qui permet aux administrateurs de tester l’effet de leur stratégie dans l’environnement de production réel sans affecter l’expérience utilisateur. Une fois que vous êtes satisfait des résultats, vous pouvez commencer à appliquer la stratégie. |
| Prise en charge de l’exportation et de l’importation de stratégies | SRP ne prend pas en charge l’importation/exportation de stratégie. | AppLocker prend en charge l’importation et l’exportation de stratégies. Cela vous permet de créer une stratégie AppLocker sur un exemple d’ordinateur, de la tester, puis d’exporter cette stratégie et de l’importer de nouveau dans l’objet de stratégie de groupe souhaité. |
| Application des règles | En interne, l’application des règles SRP se produit en mode utilisateur, qui est moins sécurisé. | En interne, les règles AppLocker pour les Exes et les Dll sont appliquées en mode noyau, ce qui est plus sécurisé que de les appliquer en mode utilisateur. |
Configuration système requise
Les stratégies de restriction logicielle ne peuvent être configurées et appliquées qu’aux ordinateurs exécutant au moins Windows Server 2003 et au moins Windows XP. Une stratégie de groupe est requise pour distribuer les objets de stratégie de groupe qui contiennent des stratégies de restriction logicielle.
Composants et architecture des stratégies de restriction logicielle
Les stratégies de restriction logicielle fournissent un mécanisme pour le système d’exploitation et les applications conformes aux stratégies de restriction logicielle afin de restreindre l’exécution du runtime des programmes logiciels.
À un niveau élevé, les stratégies de restriction logicielle se composent des composants suivants :
API stratégies de restriction logicielle. Les interfaces de programmation d’applications (API) sont utilisées pour créer et configurer les règles qui constituent la stratégie de restriction logicielle. Il existe également des API de stratégies de restriction logicielle pour interroger, traiter et appliquer des stratégies de restriction logicielle.
Outil de gestion des stratégies de restriction logicielle. Il s’agit de l’extension Stratégies de restriction logicielle du composant logiciel enfichable Éditeur d’objets local stratégie de groupe, que les administrateurs utilisent pour créer et modifier les stratégies de restriction logicielle.
Ensemble d’API de système d’exploitation et d’applications qui appellent les API de stratégies de restriction logicielle pour assurer l’application des stratégies de restriction logicielle au moment de l’exécution.
Active Directory et stratégie de groupe. Les stratégies de restriction logicielle dépendent de l’infrastructure stratégie de groupe pour propager les stratégies de restriction logicielle à partir d’Active Directory vers les clients appropriés, et pour l’étendue et le filtrage de l’application de ces stratégies sur les ordinateurs cibles appropriés.
API Authenticode et WinVerify Trust qui sont utilisées pour traiter les fichiers exécutables signés.
Observateur d’événements. Les fonctions utilisées par les stratégies de restriction logicielle consignent les événements dans les journaux observateur d'événements.
Ensemble de stratégies résultant (RSoP), qui peut faciliter le diagnostic de la stratégie effective qui sera appliquée à un client.
Pour plus d’informations sur l’architecture SRP et la façon dont SRP gère les règles, les processus et les interactions, consultez Fonctionnement des stratégies de restriction logicielle dans la bibliothèque technique Windows Server 2003.
Bonnes pratiques
Ne modifiez pas la stratégie de domaine par défaut.
- Si vous ne modifiez pas la stratégie de domaine par défaut, vous avez toujours la possibilité de réappliquer la stratégie de domaine par défaut en cas de problème avec votre stratégie de domaine personnalisée.
Créez un objet stratégie de groupe distinct pour les stratégies de restriction logicielle.
- Si vous créez un objet de stratégie de groupe distinct pour les stratégies de restriction logicielle, vous pouvez désactiver les stratégies de restriction logicielle en cas d’urgence sans désactiver le reste de votre stratégie de domaine.
Si vous rencontrez des problèmes avec les paramètres de stratégie appliqués, redémarrez Windows en mode sans échec.
- Les stratégies de restriction logicielle ne s’appliquent pas lorsque Windows est démarré en mode sans échec. Si vous verrouillez accidentellement une station de travail avec des stratégies de restriction logicielle, redémarrez l’ordinateur en mode sans échec, connectez-vous en tant qu’administrateur local, modifiez la stratégie, exécutez gpupdate, redémarrez l’ordinateur, puis connectez-vous normalement.
Soyez prudent lors de la définition d’un paramètre par défaut de Non autorisé.
Lorsque vous définissez un paramètre par défaut de Non autorisé, tous les logiciels sont interdits, à l’exception des logiciels qui ont été explicitement autorisés. Tout fichier que vous souhaitez ouvrir doit avoir une règle de stratégies de restriction logicielle qui lui permet de l’ouvrir.
Pour empêcher les administrateurs de se verrouiller hors du système, lorsque le niveau de sécurité par défaut est défini sur Non autorisé, quatre règles de chemin d’accès au Registre sont automatiquement créées. Vous pouvez supprimer ou modifier ces règles de chemin d’accès au Registre ; toutefois, cela n’est pas recommandé.
Pour une sécurité optimale, utilisez des listes de contrôle d’accès conjointement avec des stratégies de restriction logicielle.
- Les utilisateurs peuvent essayer de contourner les stratégies de restriction logicielle en renommant ou en déplaçant les fichiers non autorisés ou en remplaçant les fichiers sans restriction. Par conséquent, il est recommandé d’utiliser des listes de contrôle d’accès (ACL) pour refuser aux utilisateurs l’accès nécessaire à l’exécution de ces tâches.
Testez soigneusement les nouveaux paramètres de stratégie dans les environnements de test avant d’appliquer les paramètres de stratégie à votre domaine.
Les nouveaux paramètres de stratégie peuvent agir différemment de ce qui était prévu à l’origine. Les tests réduisent le risque de rencontrer un problème lorsque vous déployez des paramètres de stratégie sur votre réseau.
Vous pouvez configurer un domaine de test, distinct du domaine de votre organisation, dans lequel tester de nouveaux paramètres de stratégie. Vous pouvez également tester les paramètres de stratégie en créant un objet de stratégie de groupe de test et en le liant à une unité d’organisation de test. Une fois que vous avez testé minutieusement les paramètres de stratégie avec des utilisateurs de test, vous pouvez lier l’objet de stratégie de groupe de test à votre domaine.
Ne définissez pas les programmes ou fichiers sur Non autorisés sans tester pour voir quel effet peut être. Les restrictions sur certains fichiers peuvent sérieusement affecter le fonctionnement de votre ordinateur ou réseau.
Les informations entrées incorrectement ou les erreurs de saisie peuvent entraîner un paramètre de stratégie qui ne fonctionne pas comme prévu. Le test de nouveaux paramètres de stratégie avant de les appliquer peut empêcher un comportement inattendu.
Filtrez les paramètres de stratégie utilisateur en fonction de l’appartenance aux groupes de sécurité.
Vous pouvez spécifier des utilisateurs ou des groupes pour lesquels vous ne souhaitez pas qu’un paramètre de stratégie s’applique en désactivant les cases Appliquer stratégie de groupe et Lire, qui se trouvent sous l’onglet Sécurité de la boîte de dialogue propriétés de l’objet de stratégie de groupe.
Lorsque l’autorisation Lecture est refusée, le paramètre de stratégie n’est pas téléchargé par l’ordinateur. Par conséquent, moins de bande passante est consommée en téléchargeant des paramètres de stratégie inutiles, ce qui permet au réseau de fonctionner plus rapidement. Pour refuser l’autorisation Lecture, sélectionnez Refuser pour la case à cocher Lire, qui se trouve sous l’onglet Sécurité de la boîte de dialogue propriétés de l’objet de stratégie de groupe.
Ne créez pas de lien vers un objet de stratégie de groupe dans un autre domaine ou site.
- La liaison à un objet de stratégie de groupe dans un autre domaine ou site peut entraîner des performances médiocres.
Ressources supplémentaires
| Type de contenu | Références |
|---|---|
| Planification | Référence technique des stratégies de restriction logicielle |
| Opérations | Administrer les stratégies de restriction logicielle |
| Dépannage | Résolution des problèmes liés aux stratégies de restriction logicielle (2003) |
| Sécurité | Menaces et contre-mesures pour les stratégies de restriction logicielle (2008) Menaces et contre-mesures pour les stratégies de restriction logicielle (2008 R2) |
| Outils et paramètres | Outils et paramètres des stratégies de restriction logicielle (2003) |
| Ressources de la communauté | Verrouillage d’applications avec les stratégies de restriction logicielle |