Administration de Windows

Le service d’installation ActiveX dans Windows Vista

Rob Campbell and Joel Yoker

Vue d'ensemble:

• Problèmes courants avec les contrôles ActiveX
• Installation des contrôles ActiveX
• Autorisations dangereuses
• Un processus plus sûr dans Windows Vista

C’est toujours la même histoire. Pour améliorer sensiblement votre sécurité, vous devez renoncer à une certaine liberté ou une certaine flexibilité. Si votre environnement est comme la plupart des organisations, vous souhaitez vivement renforcer le système d’exploitation du bureau dans le but de fournir un environnement informatique plus sécurisé

à vos utilisateurs finaux. Les administrateurs informatiques abordent généralement la tâche de protection de bureau en utilisant une combinaison de paramètres de stratégie de sécurité, les autorisations utilisateur, les listes de contrôle d’accès aux fichiers et aux registres (les ACL) et les restrictions de services système.

Une difficulté courante dans le développement d’un environnement de poste de travail sécurisé est comment adoucir les menaces entourant les contrôles ActiveX® malveillants tout en fournissant toujours un niveau approprié de compatibilité des applications dans votre environnement. Cela a été un problème avec les systèmes d’exploitation de bureau pendant de nombreuses années. Heureusement, le nouveau service d’installation ActiveX (AxIS) dans Windows Vista™ répond aux problèmes spécifiques de la gestion des contrôles ActiveX dans les environnements d’entreprise. AxIS fournit une façon simple et maniable pour les utilisateurs standard, qui ne seraient pas normalement autorisés à installer des contrôles ActiveX, de les installer à partir de sites Web approuvés. Le contrôle de la Stratégie de groupe sur AxIS permet aux administrateurs informatiques de déterminer quels contrôles les utilisateurs peuvent installer, quelles que soient les autorisations qu’ils possèdent.

Dans cet article, nous examinons les défis administratifs entourant les contrôles ActiveX, comment ces problèmes ont été résolus dans les versions précédentes de Windows® et comment AxIS dans Windows Vista fournit une façon unique et efficace de gérer l’installation des contrôles ActiveX.

Qu’est-ce qu’un contrôle ActiveX ?

Un contrôle ActiveX est un morceau de code exécutable (généralement un fichier OCX emballé dans un fichier .cab) installé et invoqué par l’utilisateur via Internet Explorer®. Les développeurs Web créent des contrôles ActiveX pour ajouter des fonctionnalités à leurs applications Web qu’ils ne peuvent pas réaliser facilement avec le HTML standard ou un script simple.

Une fonctionnalité clé des contrôles ActiveX est la simplicité de leur modèle de déploiement « télécharger et exécuter ». Les contrôles ActiveX sont installés et invoqués à l’aide de la balise d’objet HTML, qui possède un attribut appelé CODEBASE qui indique à Internet Explorer (via une adresse URL) où obtenir le contrôle s’il n’est pas déjà installé sur la machine de l’utilisateur. Dans ce cas, Internet Explorer télécharge le package d’installation associé, réalise la vérification de confiance sur l’objet et demande à l’utilisateur l’autorisation d’installation à l’aide de la barre d’information d’Internet Explorer (illustrée à la figure 1). Pendant l’installation, le contrôle est enregistré et invoqué par le rendu de la page. Une fois installé, le contrôle peut être invoqué par tout utilisateur standard. Ce mécanisme simple de distribution et d’exécution est destiné à offrir aux développeurs une manière simple de distribuer leurs composants aux utilisateurs de leur application Web. Le problème avec cette méthode de distribution est que les utilisateurs standard ne peuvent pas installer directement les contrôles ActiveX parce que les privilèges d’administrateur sont nécessaires pour terminer l’installation.

Figure 1** Barre d’information d’installation de contrôle ActiveX **

Lorsque les contrôles ActiveX ont été introduits pour la première fois dans Internet Explorer 4.0, Internet est apparu comme un endroit beaucoup plus convivial. Aujourd’hui, le code exécutable distribué sur le Web peut représenter une menace significative, donc Windows autorise seulement les utilisateurs possédant des droits d’administrateur locaux à installer des contrôles ActiveX, et seulement si l’installation est approuvée selon les paramètres de stratégie. Une fois qu’un contrôle ActiveX est installé par un administrateur, tout utilisateur du système peut l’invoquer. Ce comportement est facilité par une série d’ACL de fichiers et de registres dans Windows. Si cela empêche les utilisateurs standard d’installer des contrôles ActiveX, cela ne réduit pas les risques pour les administrateurs locaux et les utilisateurs standard (les autorisations par défaut étant modifiées) qui les installent.

Si la protection par défaut dans Windows (autorisant seulement ceux qui possèdent des privilèges d’administrateur à exécuter l’installation) s’adresse aux contrôles ActiveX au niveau individuel, elle n’explique pas comment gérer ceux-ci à travers une grande organisation. Un problème courant dans les environnements d’entreprise est comment permettre l’utilisation de contrôles ActiveX approuvés par l’organisation informatique en réduisant les menaces potentielles dirigées via des contrôles externes, non approuvés. Au bout du compte, la décision d’installer un contrôle ActiveX particulier, bon ou mauvais, est souvent laissée aux utilisateurs individuels, en fonction de leurs droits. Pour neutraliser les menaces, certaines organisations bloquent tous les contrôles ActiveX, alors que d’autres autorisent l’installation des utilisateurs finaux mais tentent de gérer tout logiciel malveillant installé.

Une autre façon d’empêcher l’installation de mauvais contrôles est d’appliquer les droits restreints de l’utilisateur standard et de demander à l’administrateur informatique de pré-installer tous les contrôles requis sur la plate-forme de bureau. Ceci est efficace si les contrôles ActiveX utilisés sont relativement statiques par nature, s’ils sont modifiés en utilisant un processus de version planifié conjointement avec les mises à jour de bureau, ou si l’organisation utilise un mécanisme de distribution de logiciel tel que Systems Management Server. Cependant, la gestion continue, les besoins toujours changeants des développeurs d’applications internes et les dépendances vis-à-vis des contrôles externes continueront à être un problème avec ces approches.

Lorsque les utilisateurs possèdent des privilèges d’administrateur, le problème est différent : il implique d’empêcher ces utilisateurs d’installer des contrôles non approuvés. Dans ce cas, le droit de l’utilisateur final d'installer des contrôles ActiveX est supposé, puisque l’utilisateur possède des privilèges d’administrateur. (Notez que lorsque les utilisateurs finaux s’exécutent en tant qu’administrateurs locaux, c’est une attitude qui représente un risque élevé pour l’organisation et qui n’est pas recommandée pour la plupart des environnements d’entreprise.)

Une solution consiste à posséder un serveur de téléchargement de composant Internet interne qui héberge les contrôles approuvés. Cette solution nécessite la modification de la chaîne CodeBaseSearchPath dans le registre du client. Normalement, lorsqu’une balise d’objet contenant l’attribut CODEBASE est recherchée dans la page HTML demandée, les clients Windows sont dirigés vers les emplacements spécifiés dans les données CodeBaseSearchPath. Par défaut, cette chaîne de registre contient le mot clé CODEBASE et les URL Internet pour la galerie de contrôles ActiveX. Pour implémenter un Serveur de Téléchargement de Composant Internet, vous devez remplacer les données par défaut dans CodeBaseSearchPath avec l’URL du serveur interne où vous hébergerez des contrôles approuvés par votre organisation. Comme dans l’approche précédente, cette solution nécessite une gestion continue et supporte le coût et la complexité d’héberger un serveur interne pour les contrôles ActiveX.

Il existe d’autres solutions, telles que la modification des URLActions de la zone Internet Explorer, la spécification des contrôles approuvés par l’administrateur via la Stratégie de groupe et le blocage de l’installation de tous les contrôles au périmètre via les règles de pare-feu. Mais, comme vous pouvez le constater, toutes ces approches présentent des problèmes et beaucoup sont finalement abandonnées en raison du manque de flexibilité. Pire, certaines de ces solutions nécessitent encore que l’utilisateur possède des droits administratifs. Finalement, ces modifications tentent de résoudre des parties du problème, par exemple contrôler (ou bloquer) d’où viennent les contrôles ActiveX, d’où ils peuvent être invoqués, etc. Cependant, ces solutions ne résolvent pas le problème fondamental : les utilisateurs sans droits d’administrateur ne peuvent pas installer les contrôles ActiveX.

Comment AxIS peut vous aider ?

AxIS dans Windows Vista permet à l’administrateur d’entreprise de gérer des contrôles ActiveX tout en maintenant une méthode de sécurité renforcée en ayant des utilisateurs qui s’exécutent comme des utilisateurs standard avec des paramètres de système de fichiers par défaut. AxIS fournit les options de Stratégie de groupe pour configurer des sources fiables de contrôles ActiveX et un processus broker pour installer des contrôles à partir de ces sources approuvées au nom des utilisateurs standard. L’avantage principal est que vous pouvez maintenir une méthode de sécurité non administrative sur les postes de travail d’utilisateur avec un contrôle administratif centralisé. AxIS s’appuie sur l’administrateur informatique pour identifier des sources fiables (généralement des URLS Internet ou intranet) de contrôles ActiveX. Lorsqu’une balise d’objet indique à Internet Explorer d’invoquer un contrôle, AxIS procède de la façon suivante :

1. Il vérifie que le contrôle est installé. Sinon, il doit être installé avant l’utilisation.
2. Il inspecte le paramètre de stratégie AxIS pour vérifier si le contrôle provient d’une source fiable. La vérification spécifique correspond au nom d’hôte de l’URL spécifiée dans l’attribut CODEBASE de la balise d’objet par rapport à la liste d’emplacements fiables spécifiés dans la stratégie.
3. Il télécharge et installe le contrôle au nom de l’utilisateur.

Si le nom d’hôte de l’URL de source n’est pas répertorié dans le paramètre de stratégie AxIS, l’invite du contrôle du compte utilisateur normal (UAC) sera invoquée, nécessitant des droits administratifs pour terminer l’installation. De plus, AxIS enregistrera un événement portant l’ID 4097 dans le journal des événements d’applications à partir de la source AxInstallService décrivant la tentative d’installation de contrôle ActiveX, ainsi que le chemin de téléchargement spécifique vers le contrôle. Un exemple de l’événement 4097 est illustré à la figure 2. Les données de cette entrée de journal des événements peuvent être utilisées par l’administrateur d’entreprise pour modifier la stratégie de groupe, permettant d’installer le contrôle par le biais d’AxIS lors des visites suivantes du site Web.

Figure 2** Événement 4097 AxInstallService **

AxIS est un composant facultatif qui est fourni avec les versions Business, Enterprise et Édition Intégrale de Windows Vista, et qui peut être activé via une option sans assistance ou la boîte de dialogue du panneau de configuration (Programmes | Programmes et fonctionnalités | Activez ou désactivez les fonctionnalités Windows), comme illustré à la figure 3. Une fois activé, AxIS parcourt les étapes présentées ci-dessus chaque fois qu’un contrôle est demandé par Internet Explorer.

Figure 3** Activation d’AxIS dans le panneau de configuration **

La possibilité de joindre des tâches aux événements dans Windows Vista est un moyen simple pour un administrateur de recevoir une notification du service AxIS, par exemple lorsque l’installation d’un contrôle ActiveX est bloquée. Il est important de noter que le contrôle ActiveX n’est pas toujours censé être installé à partir du même nom d’hôte d’URL auquel l’utilisateur final accède à partir de son site Web. Pour cette raison, les informations fournies par l’événement 4097 AxInstallService (tentative d’installation) peuvent se révéler extrêmement utiles pour identifier l’hôte à partir duquel la tentative d’installation du contrôle est effectuée.

Avec les informations que vous obtenez à partir de l’événement, vous pouvez configurer l’emplacement approuvé dans la stratégie de groupe. Les paramètres AxIS dans la stratégie locale ou la stratégie de groupe se trouvent dans les paramètres de configuration de l’ordinateur (comme illustré à la figure 4). Les sites d’installation approuvés pour le paramètre de stratégie de contrôles ActiveX vous permet de spécifier des URL d’hôte des emplacements approuvés (voir la figure 5). Le paramètre du site approuvé nécessite deux informations, l’emplacement où le contrôle ActiveX peut être installé et le comportement de l’installation.

Figure 4** Paramètres de l’éditeur d’objets de stratégie de groupe **

Figure 5** Sites d’installation AxIS-approved **

D’abord, comme indiqué auparavant, une URL d’hôte est nécessaire pour indiquer l’emplacement approuvé du contrôle. Contrairement aux solutions précédentes, qui nécessitaient le CLSID du contrôle (qui change souvent lorsque les contrôles sont révisés par leurs développeurs), AxIS permet d’installer des contrôles à partir de l’emplacement approuvé, tout en réduisant le fardeau administratif général. La deuxième information est une chaîne de quatre valeurs délimitées par des virgules, chacune dictant le comportement de l’expérience de téléchargement de contrôles ActiveX. Les valeurs spécifient quatre propriétés : TPSSignedControl, SignedControl, UnsignedControl et ServerCertificatePolicy. Les deux premières propriétés (TPSSignedControl et SignedControl) peuvent avoir une valeur parmi trois : 0, 1 ou 2. Ces valeurs sont similaires aux valeurs trouvées dans les paramètres URLAction. La valeur 0 empêche le contrôle de s’installer, avec la valeur 1 l’utilisateur est invité à fournir l’autorisation d’installation et la valeur 2 entraîne l’installation silencieuse de la part de l’utilisateur. Les contrôles non signés ne peuvent pas être installés silencieusement et donc la valeur de UnsignedControl ne peut être que 0 ou 1. Notez que si aucune stratégie n’est spécifiée, les valeurs par défaut 2, 1 et 0 sont utilisées.

La propriété finale spécifie le comportement de l’installation basé sur les paramètres de certificat du contrôle des paramètres signés. Comme la plupart des sites SSL, le certificat doit réussir une série de tests de sécurité pour s’assurer qu’il est valide. Les propriétés de certificat non valides sont parfois la concrétisation de l’implémentation de contrôle ActiveX signé réel. Via sa configuration, AxIS permet aux administrateurs de limiter les informations non valides qui sont parfois présentées par les certificats URL par URL. La propriété finale est représentée comme une combinaison à masque de bits des valeurs illustrées à la figure 6.

Figure 6 ServerCertificatePolicy

Le paramètre par défaut est 0, ce qui signifie que toutes les vérifications de sécurité doivent réussir avant qu'AxIS termine l’installation. La combinaison du paramètre d’hôte et de ces quatre valeurs est spécifiée dans le paramètre de stratégie, comme illustré à la figure 7.

Figure 7** URL d’hôte AxIS approuvées **

Conclusion

AxIS vous permet de configurer la stratégie de groupe pour contrôler quels contrôles ActiveX les utilisateurs peuvent installer sans nécessiter de privilèges d’administrateur ou de configurations complexes. Le contrôle à ce niveau pouvait représenter un véritable défi dans les versions précédentes de Windows et des solutions disponibles précédemment ont souvent été fournies avec des restrictions sérieuses ou des frais de gestion augmentés. AxIS offre aux organisations un autre outil pour une approche de moindre privilège des droits d’utilisateur final sur les systèmes de bureau, autorisant la mise en œuvre d’un modèle d’utilisateur standard où les utilisateurs finaux ne nécessitent pas de privilège d’administrateur. Windows Vista replace l’administrateur informatique aux commandes, car il choisit des contrôles ActiveX approuvés dans l’environnement d’entreprise déterminé par l’organisation, pas par l’utilisateur final.

Rob Campbell est spécialiste technique senior dans l’équipe Microsoft Federal. Rob s’emploie à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.

Joel Yoker est consultant senior dans l’équipe Microsoft Federal. Joel s’emploie à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.