Considérations relatives à la sécurité pour AppLocker
Cette rubrique destinée aux professionnels de l’informatique décrit les considérations relatives à la sécurité à prendre en compte lors de l’implémentation de AppLocker.
L’objectif de AppLocker est de limiter l’accès aux logiciels et, par conséquent, les données accessibles par les logiciels, à un groupe spécifique d’utilisateurs ou à un groupe professionnel défini. Les considérations relatives à la sécurité pour AppLocker sont les suivantes :
AppLocker est déployé au sein d’une entreprise et administré de manière centralisée par les membres de l’équipe informatique disposant d’informations d’identification approuvées. Ainsi, la création et le déploiement de sa stratégie son conformes à des processus de déploiement de stratégie et des restrictions de sécurité similaires.
Les stratégies AppLocker sont distribuées via des processus connus et par des moyens connus au sein du domaine via la stratégie de groupe. Toutefois, les stratégies AppLocker peuvent également être définies sur les ordinateurs individuels d’utilisateurs ayant des privilèges d’administrateur, et elles peuvent être contraires à la stratégie de sécurité écrite de l’organisation. Les paramètres d’application des stratégies locales sont remplacés par les mêmes stratégies AppLocker dans un objet de stratégie de groupe (GPO). Toutefois, les règles AppLocker étant cumulatives, une stratégie locale qui n’est pas présente dans un GPO sera toujours évaluée pour cet ordinateur.
Microsoft ne fournit pas de moyen de développer des extensions pour AppLocker. Les interfaces ne sont pas publiques. Un utilisateur disposant d’informations d’identification d’administrateur peut automatiser certains processus AppLocker à l’aide des applets de commande Windows PowerShell. Pour obtenir des informations sur les applets de commande Windows PowerShell pour AppLocker, voir Applets de commande AppLocker dans Windows PowerShell.
AppLocker s’exécute dans le contexte Administrateur ou LocalSystem, qui est l’ensemble de privilèges le plus élevé. Ce contexte de sécurité présente un risque d’utilisation incorrecte. Si un utilisateur avec des droits d’administration apporte des modifications à une stratégie AppLocker sur un périphérique local joint à un domaine, ces modifications peuvent être remplacées ou non autorisées par le GPO qui contient la règle AppLocker pour le même fichier (ou chemin d’accès) modifié sur le périphérique local. Toutefois, les règles AppLocker étant cumulatives, une stratégie locale qui n’est pas présente dans un GPO sera toujours évaluée pour cet ordinateur. Si l’ordinateur local n’est pas joint à un domaine et n’est pas administré par une stratégie de groupe, une personne ayant des droits d’administration peut modifier la stratégie AppLocker.
Lors de la sécurisation des fichiers dans un répertoire avec une règle ayant un type de condition chemin d’accès, il est nécessaire et préférable de restreindre l’accès à ces fichiers en définissant les listes de contrôle d’accès (ACL) conformément à votre stratégie de sécurité, que vous utilisiez l’action Autoriser ou Refuser sur la règle.
AppLocker ne protège pas contre l’exécution de binaires DOS 16 bits dans la machine virtuelle DOS (NTVDM). Cette technologie permet l’exécution de programmes Windows DOS et 16 bits existants sur des ordinateurs utilisant Intel 80386 ou ultérieur lorsqu’un autre système d’exploitation est déjà exécuté et contrôle le matériel. Par conséquent, les binaires 16 bits peuvent toujours s’exécuter sur Windows Server 2008 R2 et Windows 7 lorsque AppLocker est configuré pour bloquer les binaires et les bibliothèques. Si vous devez obligatoirement empêcher l’exécution des applications 16 bits, vous devez configurer la règle Refuser dans le regroupement de règles d’exécutable pour NTVDM.exe.
Vous ne pouvez pas utiliser AppLocker (ou les stratégies de restriction logicielle) pour empêcher l’exécution du code en dehors du sous-système Win32. Cela s’applique en particulier au sous-système (POSIX) dans Windows NT. Si vous devez obligatoirement empêcher l’exécution des applications dans le sous-système POSIX, vous devez désactiver le sous-système.
AppLocker peut uniquement contrôler VBScript, JScript, les fichiers .bat, les fichiers .cmd et les scripts Windows PowerShell. Il ne contrôle pas tout le code interprété qui s’exécute au sein d’un processus hôte, par exemple, les macros et les scripts Perl. Le code interprété est une forme de code exécutable qui s’exécute au sein d’un processus hôte. Par exemple, les fichiers de commandes Windows (* bat) s’exécutent dans le contexte de l’hôte de commande Windows (cmd.exe). Pour contrôler le code interprété à l’aide de AppLocker, le processus hôte doit appeler AppLocker avant qu’il exécute le code interprété, puis appliquer la décision renvoyée par AppLocker. Tous les processus hôtes n’appellent pas AppLocker. Par conséquent, AppLocker ne peut pas contrôler chaque type de code interprété, par exemple les macros Microsoft Office.
Important
Vous devez configurer les paramètres de sécurité appropriés de ces processus hôtes pour pouvoir autoriser leur exécution. Configurez par exemple les paramètres de sécurité dans Microsoft Office pour vous assurer que seules les macros signées et approuvées sont chargées.
Les règles AppLocker autorisent ou empêchent le lancement d’une application. AppLocker ne contrôle pas le comportement des applications après leur lancement. Les applications peuvent contenir des indicateurs transmis aux fonctions qui signalent à AppLocker de contourner les règles et permettent le chargement d’un autre .exe ou .dll. Dans la pratique, une application qui est autorisée par AppLocker peut utiliser ces indicateurs pour contourner les règles AppLocker et lancer les processus enfants. Vous devez soigneusement examiner les applications une par une avant de les autoriser à s’exécuter à l’aide de règles AppLocker.
Remarque
Les deux indicateurs qui illustrent cette condition sont SANDBOX_INERT, qui peut être transmis à CreateRestrictedToken, et LOAD_IGNORE_CODE_AUTHZ_LEVEL, qui peut être transmis à LoadLibraryEx. Ces deux indicateurs signalent à AppLocker de contourner les règles et permettent le chargement d’un .exe ou d’une .dll enfant.