Spécifications de sécurité pour exécuter des solutions Office (Office System 2003)

Mise à jour : novembre 2007

Les personnalisations au niveau du document et les compléments d'application incorporent les fonctionnalités de sécurité disponibles dans le .NET Framework. Votre solution peut ainsi profiter d'un ensemble de preuves sur lequel baser les décisions d'accorder un niveau de confiance.

Pour déployer et exécuter une solution Microsoft Office, vous devez accorder une confiance totale aux assemblys dans la stratégie de sécurité de chaque utilisateur final. Dans le cas des personnalisations, si le document se trouve à un emplacement réseau plutôt que sur l'ordinateur de l'utilisateur, vous devez également accorder la confiance totale au document. Pour plus d'informations sur la définition de la stratégie de sécurité sur les ordinateurs des utilisateurs finaux, consultez Déploiement de la stratégie de sécurité.

Les solutions Microsoft Office ajoutent une restriction de sécurité personnalisée consistant à ne pas accepter les preuves de type Tout le code ou Zone, ce qui signifie que les applications Microsoft Office n'exécuteront aucun assembly se trouvant sur l'ordinateur local, le réseau ou Internet tant que l'autorisation ne sera pas accordée à l'assembly (niveau de confiance accordé) dans votre stratégie de sécurité.

Microsoft Office Outlook inclut un module de protection du modèle objet qui permet d'empêcher du code non fiable d'accéder au modèle objet Outlook. Le module de protection du modèle objet peut également provoquer l'affichage d'avertissements par Outlook à l'attention de l'utilisateur final lors de l'exécution de votre code. Pour plus d'informations sur la façon d'éviter ces avertissements, consultez Considérations spécifiques sur la sécurité pour les solutions Office.

Niveaux de confiance

Voici les trois niveaux de confiance dans la sécurité .NET Framework :

• Confiance totale. Ce niveau accorde au code l'autorisation d'effectuer toute action que l'utilisateur actuel peut effectuer. Tout le code doit disposer d'une confiance totale pour s'exécuter dans des solutions Office.

• Confiance partielle. Ce niveau représente un jeu d'autorisations restreintes qui n'accorde que des autorisations spécifiées. Le code d'un niveau de confiance partiel ne s'exécute pas dans les solutions Office.

• Non fiable. Ce niveau n'accorde aucune autorisation ; le code ne s'exécute donc pas.

Le jeu d'autorisations requis est Confiance totale ; les solutions Office n'exécutent pas les extensions de code managé qui ont un niveau de confiance partiel ou qui ne sont pas fiables. Pour plus d'informations sur les jeux d'autorisations, consultez Jeux d'autorisations nommés.

Types de preuves

Les types de preuves dans la sécurité .NET Framework sont les suivants :

• Tout le code.

• Répertoire d'application.

• Global Assembly Cache (GAC).

• Hachage.

• Éditeur.

• Site.

• Nom fort.

• URL.

• Zone.

• Personnalisé. (msosec.dll pour les solutions Office. (Pour plus d'informations, consultez Comment : accorder des autorisations aux documents et classeurs dans des emplacements partagés (Office System 2003)).

Pour plus d'informations, consultez Preuve.

Visual Studio utilise la preuve d'URL pour accorder une confiance totale à vos projets lorsque vous les générez. Lorsque Visual Studio génère un projet Visual Studio Tools pour Office, cela modifie la stratégie de sécurité au niveau de l'utilisateur de façon à accorder une confiance totale aux emplacements de génération des projets Office. Lorsque la personnalisation ou le complément s'exécute, le chargeur présente l'URL de l'emplacement de l'assembly au système de stratégie, accordant ainsi une confiance totale aux emplacements spécifiques.

Ce niveau de sécurité est généralement suffisant lorsque vous travaillez sur votre propre ordinateur. Cependant, n'utilisez pas cette preuve lorsque vous déployez la solution, sous peine de créer un problème de sécurité. Avant de déployer l'assembly, il faut lui donner une forme de preuve plus forte. Il existe deux raisons d'utiliser une forme de preuve plus forte :

• Si vous accordez une confiance totale à un emplacement Web, les utilisateurs malveillants disposant d'un accès en écriture sur cet emplacement peuvent remplacer l'assembly par leur propre code et amener par la ruse les autres personnes à l'exécuter.

• La stratégie au niveau de l'ordinateur par défaut accorde une confiance partielle à tous les sites Web, mais étant donné qu'une confiance totale est nécessaire, la définition d'une stratégie au niveau de l'utilisateur pour accorder une confiance totale à une URL est insuffisante.

Si vous décidez d'utiliser une preuve d'URL, veillez à définir la stratégie dans la branche de zone Intranet du niveau de stratégie Ordinateur, et non Utilisateur. En outre, n'accordez une confiance totale qu'aux emplacements sur lesquels vous êtes certain que seules des personnes dignes de confiance peuvent écrire. Une meilleure stratégie consiste à utiliser une combinaison d'emplacement et de preuve forte du point de vue du chiffrement, telle qu'un nom fort. Les noms forts doivent toujours être utilisés avec les informations sur l'emplacement de façon à pouvoir corriger en toute sécurité une application portant un nom fort si celle-ci est compromise.

Pour les personnalisations au niveau du document, le document dispose également d'une preuve basée sur l'emplacement ; il est donc plus difficile aux utilisateurs malveillants de modifier le code de confiance en créant des documents l'utilisant à d'autres fins. Si un document comportant des extensions de code managé ne se trouve pas dans un emplacement totalement de confiance, il n'exécute pas l'assembly. Par défaut, la zone MyComputer dispose d'un niveau de confiance total. Le code peut donc être exécuté dans les documents sur l'ordinateur de l'utilisateur. Cependant, la zone Internet ne dispose pas d'un niveau de confiance total.

Les documents contenant des extensions de code managé n'utilisent pas la fonction Sécurité des macros d'Office, qui repose sur le magasin de certificats d'Office. La sécurité des macros n'est pas liée à la sécurité des assemblys.

Pour plus d'informations sur la sécurité dans le .NET Framework, consultez Notions fondamentales de la sécurité d'accès du code, et plus généralement, Sécurité dans le .NET Framework et Vue d'ensemble de l'administration de stratégie de sécurité.

Vue d'ensemble de la sécurité de l'assembly

Vue d'ensemble de la sécurité du document

Sécurité sur l'ordinateur de développement

Lorsque vous générez, en tant que développeur, un projet Office dans Visual Studio, le chemin d'accès complet de l'assembly (y compris le nom de l'assembly) est ajouté par défaut à votre stratégie de sécurité .NET Framework au niveau de l'utilisateur. Par conséquent, l'assembly reçoit la confiance totale. Les assemblys référencés présents dans le dossier de sortie de votre projet reçoivent également une confiance totale lorsque le projet est généré.

Si le paramètre par défaut n'est pas modifié, Visual Studio Tools pour Office vérifie la stratégie de sécurité dans le cache chaque fois que vous générez la solution. Si les assemblys ne bénificient pas de la confiance totale, Visual Studio Tools pour Office la leur accorde. Cela permet à votre projet de conserver l'approbation même si vous renommez l'assembly ou déplacez le projet à un nouvel emplacement.

Si vous modifiez le paramètre de confiance par défaut (affectez la valeur false à la propriété Emplacement des assemblys de confiance), Visual Studio n'accorde pas la confiance totale aux assemblys, et votre code ne s'exécute pas. Pour exécuter votre code de nouveau, remplacez la valeur de la propriété Emplacement des assemblys de confiance par true et régénérez votre solution. Vous pouvez également définir une règle générale qui permet à l'ensemble du code exécuté à partir du dossier Projets et de ses sous-dossiers de disposer d'une confiance totale.

Pour plus d'informations sur la définition d'options d'approbation pour votre projet et l'octroi d'une confiance totale aux dossiers, consultez Comment : accorder des autorisations à des dossiers et des assemblys (Office System 2003).

Mise en cache de la stratégie de sécurité

Le Common Language Runtime met en cache la stratégie de sécurité pour chaque processus. Lorsque vous générez vos projets, Visual Studio vérifie dans ce cache que les assemblys disposent d'une confiance totale. Si les assemblys disposent déjà d'une confiance totale lorsque Visual Studio est démarré, Visual Studio ne leur crée pas de stratégie pendant le processus de génération.

Si vous modifiez la stratégie de sécurité associée à votre projet pendant l'exécution de Visual Studio, Visual Studio ne détecte pas les modifications. Si les modifications que vous avez apportées empêchent l'exécution de votre projet, l'application lève une exception de sécurité, car Visual Studio ne recrée pas la stratégie pour accorder une confiance totale aux assemblys. Pour permettre à Visual Studio de détecter les modifications apportées à la stratégie de sécurité, vous devez fermer puis rouvrir Visual Studio.

Solutions créées en utilisant des versions antérieures

Chaque version du Microsoft .NET Framework installée sur votre ordinateur a une stratégie de sécurité qui lui est associée. Les solutions Visual Studio Tools pour Office vérifient la stratégie de sécurité de la version du .NET Framework pour laquelle elles ont été créées. Si une solution est créée à l'aide de Visual Studio Tools pour Office, version 2003, elle vérifie toujours la stratégie de sécurité dans la version 1.1 du .NET Framework. Si une solution est créée à l'aide de Visual Studio 2005 Tools pour Office, elle vérifie toujours la stratégie de sécurité dans .NET Framework version 2.0.

Les solutions Visual Studio Tools pour Office System 3.0 vérifient la stratégie de sécurité dans la version 3.5 du .NET Framework, mais les solutions pour Office 2003 peuvent être définies pour utiliser .NET Framework 2.0. Pour plus d'informations, consultez Comment : modifier la version cible de .NET Framework. 

Projets créés sur un réseau

Même si vous pouvez créer un projet à un emplacement réseau partagé, vous ne pouvez pas l'exécuter sur le réseau tant que vous ne lui avez pas accordé une confiance totale au niveau de l'ordinateur. Par défaut, Visual Studio Tools pour Office accorde la preuve d'URL au niveau de l'utilisateur. Vous devez accorder manuellement une confiance totale à l'assembly au niveau de l'ordinateur.

Si vous utilisez uniquement une preuve d'URL pour accorder une confiance totale à un emplacement réseau, les utilisateurs malveillants disposant d'un accès en écriture sur cet emplacement peuvent remplacer l'assembly par leur propre code et amener par la ruse les autres personnes à l'exécuter. Considérez les autres formes de preuve que vous pouvez utiliser à la place ou en plus d'une preuve d'URL. Pour plus d'informations, consultez Types de preuves dans cette rubrique.

Sécurité pour les utilisateurs finaux

Les utilisateurs finaux ouvrent les documents avec des extensions de code managé comme ils le feraient en général pour tout document. Si le document se trouve sur l'ordinateur de l'utilisateur final ou qu'une confiance lui a été accordée sur un partage réseau, Word ou Excel essaie de charger et d'exécuter l'assembly. Pour les compléments, le complément est chargé lorsque l'utilisateur lance l'application Microsoft Office.

L'application Microsoft Office vérifie la stratégie de sécurité et exécute l'une des actions suivantes :

• Si des autorisations ont été explicitement accordées à l'assembly et au document (le cas échéant), l'assembly est autorisé à s'exécuter. Pour plus d'informations sur la définition de la stratégie de sécurité sur les ordinateurs des utilisateurs finaux, consultez Déploiement de la stratégie de sécurité.

• Si l'unique preuve disponible pour déterminer les autorisations est de type Tout le code ou Zone, le code ne s'exécute pas, et l'utilisateur reçoit un message d'erreur indiquant que la stratégie de sécurité actuelle empêche l'exécution du code. L'utilisateur doit contacter un administrateur pour installer la stratégie qui permet au code de s'exécuter.

La stratégie de sécurité Visual Studio Tools pour Office par défaut n'autorise pas l'exécution de code dans les personnalisations. Par défaut, la stratégie de sécurité accorde un niveau de confiance à la zone Poste de travail, mais la stratégie de niveau domaine d'application pour les documents comportant des extensions de code managé ne permet pas à du code se trouvant dans la zone Poste de travail de s'exécuter tant qu'un niveau de confiance n'a pas été explicitement accordé à ce code. Cela diffère de l'expérience habituelle du développeur et de l'utilisateur final, mais l'utilisation des paramètres par défaut rend le bureau plus sécurisé. En outre, les utilisateurs finaux ne peuvent pas modifier les options de sécurité dans Office pour autoriser l'exécution de code non fiable. Seules les modifications explicites apportées à la stratégie de sécurité .NET permettent l'exécution des extensions de code managé.

Approbation des documents Office

Dans la plupart des situations, le document Office s'exécute dans la zone Poste de travail, et aucune action n'est requise pour permettre au document de s'ouvrir comme prévu. Toutefois, l'assembly doit être d'un niveau de confiance suffisant pour permettre à l'application de s'exécuter. Lorsque le document est arrivé comme pièce jointe d'un courrier électronique, il doit être enregistré ailleurs sur l'ordinateur (sur le bureau de l'utilisateur, par exemple) avant que la solution ne s'exécute, même si le document pointe vers un assembly de confiance. Cela est dû au fait que les pièces jointes se trouvent dans la zone Internet qui ne bénéficie pas d'une confiance totale.

Si le document se trouve sur le réseau, l'administrateur doit également accorder des autorisations au document. Pour les documents statiques tels que les modèles, l'administrateur peut accorder un niveau de confiance au document en fonction de son chemin d'accès complet (URL). Pour un stockage plus général où de nombreux utilisateurs peuvent télécharger des contenus arbitraires, tels qu'une liste SharePoint, l'administrateur peut choisir d'accorder un niveau de confiance uniquement aux documents Office situés dans cet emplacement partagé. Pour plus d'informations, consultez Comment : accorder des autorisations aux documents et classeurs dans des emplacements partagés (Office System 2003).

Suppression d'un niveau de confiance des assemblys

Si l'administrateur découvre qu'il existe un problème de sécurité dans l'organisation, il peut désactiver temporairement tout le code managé en appliquant une stratégie qui ne fournit aucune autorisation d'exécution pour l'ensemble du code. Si du code managé est requis, l'administrateur peut continuer à modifier la stratégie pour activer uniquement l'exécution du code requis en sélectionnant une propriété unique de ce code (telle que l'emplacement, le nom fort ou la signature) et en lui accordant les autorisations nécessaires. Il est facile de réactiver du code managé. Pour ce faire, restaurez simplement l'ancienne forme de la stratégie une fois le problème de sécurité résolu. Pour plus d'informations, consultez Comment : supprimer des autorisations de dossiers ou d'assemblys (Office System 2003).

Voir aussi

Concepts

Déploiement sécurisé (Office System 2003)

Meilleures pratiques pour la sécurité dans les solutions Office (Office System 2003)

Considérations spécifiques sur la sécurité pour les solutions Office

Sécurisation des applications

Autres ressources

Sécurité dans les solutions Office (Office System 2003)