Déploiement sécurisé (Office System 2003)
Mise à jour : novembre 2007
S'applique à |
|---|
Les informations dans cette rubrique s'appliquent uniquement aux projets Visual Studio Tools pour Office et versions de Microsoft Office spécifiés. Type de projet
Version de Microsoft Office
Pour plus d'informations, consultez Fonctionnalités disponibles par type d'application et de projet. |
Lorsque vous créez une solution Visual Studio Tools pour Office, votre stratégie de sécurité locale est automatiquement mise à jour pour permettre au code de votre projet de s'exécuter. Cependant, lorsque vous déployez votre solution, vous devez mettre à jour explicitement la stratégie de sécurité sur chaque ordinateur où est utilisée la solution, afin d'autoriser le code assembleur à s'exécuter et à accéder au modèle objet Office.
Pour les personnalisations au niveau du document, si vous déployez le document sur un emplacement réseau, vous devez également mettre à jour la stratégie de sécurité pour le 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é. Pour plus d'informations sur les personnalisations au niveau du document, consultez Architecture des personnalisations au niveau du document.
Noms forts et certificats
La méthode recommandée pour déployer des solutions de manière sécurisée consiste à créer des assemblys avec nom fort ou signer ces derniers avec un certificat Authenticode (x.509), voire effectuer ces deux opérations pour renforcer la sécurité et accroître la souplesse de gestion. Les noms forts et les signatures Authenticode offrent un haut niveau de sécurité ; en effet, il est très difficile pour une personne de modifier votre code sans invalider le nom fort ou la signature. Les signatures Authenticode présentent d'autres avantages :
Il est possible de leur affecter des informations de date.
Les certificats peuvent être révoqués.
Le certificat fournit l'identité de l'éditeur.
Pour plus d'informations sur les assemblys avec nom fort, consultez Assemblys avec nom fort et Création et utilisation d'assemblys avec nom fort.
Pour plus d'informations sur les signatures Authenticode, consultez Déploiement et signature Authenticode.
Choix du niveau de sécurité
Vous devez comparer les avantages que présentent les règles strictes en matière de sécurité aux avantages que présentent des règles moins strictes en matière d'administration et choisir un niveau approprié d'approbation. Par exemple, si vos solutions sont systématiquement déployées sur un serveur nommé \\appserver\ et si elles sont systématiquement signées à l'aide du certificat de votre entreprise, choisissez une règle qui ne fasse confiance qu'à ce certificat sur \\appserver\. Cela vous permet de vous protéger contre des utilisateurs malveillants qui pourraient voler le certificat et publier le code sur Internet (le code n'est pas approuvé à moins qu'il provienne de \\appserver\). Cela signifie également que si vous souhaitez stocker ultérieurement les assemblys sur un autre serveur, vous devrez remettre à jour la stratégie de sécurité.
Si vous ne connaissez pas précisément l'emplacement où seront déployées vos solutions, vous pouvez établir un compromis acceptable en rendant digne de confiance le certificat ou nom fort émanant de l'ordinateur local et de l'intranet local. Si vous envisagez de distribuer votre code sur le Web, vous pouvez également utiliser la zone Sites de confiance dans les options de sécurité d'Internet Explorer. Vous ne devez pas approuver votre certificat de la zone Internet, la zone Sites sensibles, ou au niveau supérieur (ensemble du code) sans avoir une raison impérieuse de le faire. Le cas échéant, prenez les précautions appropriées pour garantir la sécurité du code, même s'il est entre les mains d'utilisateurs malveillants. Pour plus d'informations, consultez Sécurité d'accès du code.
Pour plus d'informations sur les menaces potentielles, consultez Considérations spécifiques sur la sécurité pour les solutions Office.
Autorisation d'accès à l'assembly
Une possibilité de déploiement pour les personnalisations au niveau du document consiste à déployer le document localement auprès de chaque utilisateur, et l'assembly sur un emplacement réseau. De la même manière, dans le cas de compléments au niveau de l'application, vous pouvez déployer l'assembly complémentaire sur un emplacement réseau. L'assembly ne s'exécute pas dans une solution Office tant qu'il n'est pas digne de confiance. Signez numériquement l'assembly et accordez l'accès en écriture à l'emplacement aux seuls administrateurs système (et à tout utilisateur qui doit modifier l'assembly). Pour plus d'informations sur la sécurisation de l'assembly avant le déploiement, consultez Aspects de la sécurité des assemblys.
L'outil Configuration de Microsoft .NET Framework 2.0 ou l'outil Stratégie de sécurité d'accès du code (Caspol.exe) permet de définir une stratégie de niveau entreprise qui rend l'assembly digne de confiance.
Pour plus d'informations sur l'outil Configuration du .NET Framework, consultez Outil .NET Framework Configuration (Mscorcfg.msc). Pour plus d'informations sur Caspol.exe, consultez Outil Code Access Security Policy Tool (Caspol.exe) et Configuration de la stratégie de sécurité à l'aide de l'outil Code Access Security Policy Tool (Caspol.exe).
Avant de déployer un assembly vers son emplacement final (ou de mettre à jour un assembly déployé), examinez votre stratégie de sécurité et déterminez le type de preuve à utiliser pour réduire les risques. Pour plus d'informations, consultez Spécifications de sécurité pour exécuter des solutions Office (Office System 2003).
Sécurisation des documents sur le réseau
Dans le cas de personnalisations au niveau du document, si le document se trouve sur un serveur ou sur un partage réseau, l'URL du document doit bénéficier d'une confiance totale. Cela s'applique surtout aux modèles ou aux documents individuels qui ne peuvent être modifiés que par des personnes de confiance. Vous devez vous assurer que les utilisateurs non fiables n'ont pas les autorisations requises pour modifier ou remplacer le document sur le partage.
Si un administrateur souhaite permettre à des utilisateurs d'accéder aux documents situés sur un partage public tel qu'un portail SharePoint, il doit modifier la stratégie de sécurité afin d'inclure un nouveau groupe de codes pour les documents. Le groupe de codes est basé sur la condition d'appartenance, qui recherche l'existence de documents Office comme preuves et permet aux administrateurs de prendre des décisions de confiance en conséquence (de même, les administrateurs doivent ajouter un groupe de codes pour rendre l'assembly explicitement digne de confiance). Pour plus d'informations, consultez Comment : accorder des autorisations aux documents et classeurs dans des emplacements partagés (Office System 2003).
Distribution par courrier électronique
Par défaut, dans le cas de personnalisations au niveau du document, l'assembly ne s'exécute pas si le document est ouvert directement à partir d'un courrier électronique. Cependant, il est possible d'enregistrer le document sur le disque dur local pour l'ouvrir de manière classique. Si le document contient un chemin d'accès complet à un assembly totalement approuvé dans son manifeste d'application, la solution s'exécute.
Il est possible, bien que cela ne soit pas recommandé, d'activer les documents à partir du dossier temporaire de Microsoft Outlook pour héberger du code. Cela présente un risque de sécurité de niveau faible à intermédiaire. En effet, si une faille existe dans un assembly déployé qui bénéficie d'une confiance totale, un utilisateur malveillant peut exploiter cette faille en attachant un document qui pointe vers l'assembly dans un courrier électronique, puis en invitant le destinataire à l'ouvrir. En cas de réussite, l'agresseur peut accéder par exemple à un site intranet sécurisé via les informations d'identification de l'utilisateur cible. Remarquez que l'assembly doit néanmoins bénéficier explicitement d'une confiance totale ; un agresseur ne peut pas créer de document ni d'assembly de son choix pour piéger l'utilisateur.
Modification de la stratégie de sécurité
Si l'administrateur ajuste les autorisations d'un document ou d'un assembly, les utilisateurs doivent quitter puis redémarrer toutes les applications Office pour que ces modifications soient appliquées.
Parfois, le processus d'une application Office continue de s'exécuter après que l'utilisateur a quitté cette application, ce qui empêche les modifications apportées à la stratégie de sécurité de prendre effet. Consultez le Gestionnaire des tâches et assurez-vous que l'application Office ne figure pas dans la liste des processus actifs.
D'autres applications hébergeant des applications Office peuvent également empêcher la mise en vigueur des nouvelles autorisations. Les utilisateurs doivent quitter toutes les applications qui utilisent Office, y compris Internet Explorer, qu'elles soient hébergées ou autonomes, lorsque des stratégies de sécurité sont modifiées.
Empêcher les personnalisations au niveau du document d'exécuter du code
Les administrateurs peuvent utiliser le Registre pour empêcher l'exécution de toutes les personnalisations au niveau du document sur un ordinateur. Lorsqu'un document Word ou un classeur Excel comportant des extensions de code managé est ouvert, le runtime Visual Studio Tools pour Office vérifie s'il existe une entrée portant le nom Disabled sous l'une des clés de Registre suivantes sur l'ordinateur :
HKEY_CURRENT_USER\Software\Microsoft\VSTO
HKEY_LOCAL_MACHINE\Software\Microsoft\VSTO
Pour empêcher les personnalisations au niveau du document d'exécuter du code, créez une entrée Disabled sous l'une de ces clés de Registre, ou sous les deux, et spécifiez un type de données ainsi qu'une valeur pour Disabled parmi les choix suivants :
REG_SZ ou REG_EXPAND_SZ dont la valeur correspond à toute chaîne autre que "0" (zéro).
REG_DWORD dont la valeur est différente de 0 (zéro).
Les utilisateurs peuvent encore ouvrir leurs documents et les modifier lorsque les personnalisations au niveau du document sont désactivées, mais le code de l'assembly ne sera pas exécuté. Pour permettre aux personnalisations au niveau du document d'exécuter du code, affectez la valeur 0 à chacune des entrées Disabled ou supprimez les entrées du Registre.
Voir aussi
Tâches
Comment : déployer des solutions Office (Office System 2003)
Comment : supprimer des extensions de code managé de documents (Office System 2003)
Comment : déployer l'utilisation hors connexion de documents (Office System 2003)
Concepts
Modèles de déploiement (Office System 2003)
Déploiement de personnalisations au niveau du document (Office System 2003)
Déploiement de solutions Office (Office System 2003)
Déploiement de compléments d'application (Office System 2003)