Cette documentation est archivée et n’est pas conservée.

Spécifications de sécurité pour exécuter des solutions Office

Visual Studio 2005

Cette rubrique décrit les spécifications de sécurité à respecter pour pouvoir utiliser une solution Microsoft Office 2003. Les solutions Microsoft Visual Studio 2005 Tools pour Microsoft Office System incorporent les fonctionnalités de sécurité disponibles dans le .NET Framework 2.0. 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 Office qui utilise des extensions de code managé, vous devez accorder une confiance totale aux assemblys dans la stratégie de sécurité de chaque ordinateur ou utilisateur final. 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 Office qui utilisent des extensions de code managé 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 Microsoft Office Word 2003, Microsoft Office Excel 2003 et Microsoft Office Outlook 2003 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é.

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

Les niveaux de confiance dans la sécurité .NET Framework sont les suivants :

  • Confiance totale.

  • Confiance partielle.

  • Non fiable.

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. Pour plus d'informations, consultez Preuve.

Visual Studio utilise la preuve d'URL pour accorder une confiance totale à vos projets lorsque vous les créez. 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.

Votre solution profite également du fait que le document lui-même dispose d'une preuve basée sur l'emplacement ; de ce fait, il est 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. Vous pouvez continuer à utiliser des certificats pour vos macros. Pour plus d'informations, consultez « Managing Certificates with Certificate Stores » (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/managing_certificates_with_certificate_stores.asp).

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

Emplacement de l'assembly Paramètres par défaut Mode de configuration

Ordinateur de développement

Lorsque vous créez un projet Office, une confiance totale est accordée à l'assembly principal et à tous les assemblys référencés pour lesquels Copie locale a la valeur true sur votre ordinateur.

En principe, aucune action n'est requise.

Emplacement réseau partagé

Aucun niveau de confiance n'est accordé aux assemblys.

L'administrateur configure la stratégie de sécurité réseau qui accorde un niveau de confiance à l'emplacement, et l'assembly est sécurisé (par exemple, à l'aide d'une signature numérique). Pour plus d'informations, consultez Aspects de la sécurité des assemblys.

Ordinateur de l'utilisateur final

Aucun niveau de confiance n'est accordé aux assemblys.

L'administrateur accorde un niveau de confiance à l'assembly dans la stratégie de sécurité .NET. Pour plus d'informations, consultez Déploiement de la stratégie de sécurité.

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

Emplacement du document Paramètres par défaut Mode de configuration

Ordinateur de développement

Les documents disposent d'une confiance totale.

Aucune action n'est requise.

Emplacement réseau partagé

Aucun niveau de confiance n'est accordé aux documents.

L'administrateur configure la stratégie de sécurité réseau qui accorde un niveau de confiance à l'emplacement, le cas échéant avec une stratégie personnalisée pour accorder un niveau de confiance uniquement aux documents Office. Pour plus d'informations, consultez Comment : accorder des autorisations aux documents et classeurs dans des emplacements partagés.

Ordinateur de l'utilisateur final

Les documents disposent d'une confiance totale.

Aucune action n'est requise.

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

Lorsque vous créez, 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 afin que l'assembly reçoive une 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 contrôle la stratégie de sécurité dans le cache chaque fois que vous générez la solution, afin de vérifier que les assemblys disposent d'une confiance totale ; dans le cas contraire, Visual Studio Tools pour Office accorde la confiance totale. 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 n'est pas accessible à vos applications Office. Pour que votre code soit de nouveau accessible, 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 et des sous-dossiers Projets 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.

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 avec la version antérieure

Chaque version de Microsoft .NET Framework installée sur votre ordinateur dispose d'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. Autrement dit, 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 la version 2.0 du .NET Framework. Pour plus d'informations, consultez Considérations sur les installations d'infrastructures côte à côte.

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. Un emplacement réseau partagé étant moins sécurisé que votre ordinateur personnel, vous devez assigner une preuve plus sûre que la preuve d'URL, telle qu'une signature numérique ou un nom fort, aux assemblys dans les emplacements réseau.

Sécurité pour les utilisateurs finaux

Les utilisateurs finaux ouvrent des documents avec des extensions de code managé comme n'importe quel document ou ils utilisent Outlook comme d'habitude. Pour Word et Excel, 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 Outlook, le complément est chargé lorsque l'utilisateur démarre Outlook.

  • Si des autorisations ont été explicitement accordées au document et à l'assembly, 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.

Lorsque Microsoft .NET Framework Redistributable et Microsoft Office 2003 sont installés sur l'ordinateur des utilisateurs finaux, la stratégie de sécurité .NET Framework par défaut et la stratégie limitée de niveau domaine d'application des documents comportant des extensions de code managé ne permettent l'exécution d'aucun code. 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é.

Pour plus d'informations sur les composants .NET Framework redistribuables, consultez la page Web Téléchargements du .NET Framework (http://msdn.microsoft.com/netframework/downloads/updates/default.aspx?_r=1).

Approbation des documents Office

Dans la plupart des cas, le document Office s'exécute à partir de la zone MyComputer, et aucune action n'est requise pour permettre l'ouverture du document comme prévu ; toutefois, une confiance totale doit toujours être accordée à l'assembly pour que l'application s'exécute. 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.

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.

Voir aussi

Afficher: