Partager via

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

  • Article

Mise à jour : novembre 2007

S'applique à

Les informations de cette rubrique s'appliquent uniquement aux projets et versions Visual Studio Tools pour Office spécifiés de Microsoft Office.

Type de projet

  • Projets au niveau du document

  • Projets au niveau de l'application

Version de Microsoft Office

  • Microsoft Office 2003

Pour plus d'informations, consultez Fonctionnalités disponibles par type d'application et de projet.

Pensez aux questions suivantes quand vous planifiez le stratégie de sécurité des personnalisations au niveau du document et des compléments au niveau de l'application :

Ajout de conditions à la stratégie de sécurité

Microsoft .NET Framework fournit deux méthodes principales pour déployer la stratégie :

L'utilisation d'un fichier Windows Installer permet une évaluation de stratégie plus prévisible car le niveau de stratégie entier (en général, Entreprise ou Ordinateur) est copié vers l'ordinateur de l'utilisateur final. Toutefois, cela peut créer des conflits si différents groupes dans une société souhaitent publier la stratégie indépendamment les uns des autres, ou si des utilisateurs doivent modifier leur stratégie.

L'utilisation de Caspol.exe pour modifier la stratégie permet à plusieurs utilisateurs de mettre à jour la stratégie indépendamment les uns des autres, mais il n'est pas garanti que toutes les modifications auront l'effet souhaité en raison d'interactions inconnues entre différents groupes de codes. Par exemple, si un département déploie une modification de la stratégie en attribuant la confiance totale à un site Intranet particulier, ce département s'attend à ce que tout code provenant de ce site soit digne de confiance. En revanche, si un autre département déploie la stratégie avec un attribut Exclusive qui refuse l'accès à ce site, aucun code ne s'exécutera. Pour plus d'informations sur l'attribut Exclusive, consultez Administration à l'aide d'attributs de groupe de codes et Comment : rendre des groupes de codes exclusifs ou de niveau final.

Les administrateurs doivent trouver un juste équilibre entre la prévisibilité des fichiers Windows Installer et la souplesse de Caspol.exe lorsqu'ils décident de la manière de mettre à jour la stratégie.

Bien qu'il soit également possible d'écrire du code managé pour manipuler directement la stratégie à travers les API Microsoft .NET Framework, cette procédure est sujette aux erreurs et est fortement déconseillée.

Vérification de la stratégie actuelle

Si un assembly ne s'exécute pas, vous pouvez rechercher la cause possible en passant en revue les autorisations assignées à cet assembly. Microsoft .NET Framework fournit deux méthodes de vérification de la stratégie actuelle pour un assembly :

Ces outils affichent la stratégie de sécurité qui s'applique à l'assembly, et indiquent comment la preuve de l'assembly correspond à ces règles dans le Common Language Runtime (CLR). Cela révèle si la stratégie est configurée correctement, et si l'assembly correspond groupes de codes corrects. Les principaux problèmes révélés par cette technique comprennent notamment les suivants :

  • Une règle de réseau (par exemple, l'assignation de la confiance totale à http://serveur) a été ajoutée à la zone MyComputer alors qu'elle aurait dû se trouver dans LocalIntranet, ou a été ajoutée à LocalIntranet alors qu'elle aurait dû se trouver dans TrustedSites.

  • Une erreur existe dans le nom de fichier ou l'URL.

  • Le chemin d'accès au répertoire ne contient pas l'astérisque (*) qui indique que tous les fichiers et sous-dossiers sous ce dossier doivent être inclus dans la stratégie.

Pour plus d'informations, consultez Résolution de problèmes de stratégie de sécurité à l'aide de Caspol.exe.

Définition de la stratégie par défaut pour l'entreprise

Visual Studio permet aux entreprises de définir leur propre stratégie par défaut. Normalement, lorsque vous exécutez une réinitialisation de la stratégie de sécurité, les paramètres par défaut présents lorsque le Framework est installé sont restaurés pour la stratégie. En cas d'utilisation de la stratégie par défaut spécifique à l'entreprise, une réinitialisation restaure la stratégie de base comme définie par l'entreprise concernée. Par exemple, l'entreprise peut ajouter un éditeur approuvé au niveau de l'entreprise et bloquer tout le code provenant de la zone Internet.

Pour plus d'informations sur la restauration de la stratégie par défaut, consultez Comment : retourner aux paramètres de stratégie de sécurité par défaut à l'aide de Caspol.exe et Outil .NET Framework Configuration (Mscorcfg.msc). Pour plus d'informations sur la stratégie de sécurité par défaut, consultez Stratégie de sécurité par défaut.

Recommandations générales

Référez-vous aux indications suivantes lorsque vous définissez la stratégie pour vos solutions Office :

  • Utilisez toujours des groupes de codes nommés plutôt que des numéros (par exemple, utilisez MyComputer_Zone plutôt que 1.1). Bien qu'un utilisateur puisse renommer un groupe (par exemple, renommer « Internet » « MyComputer »), cela reste moins probable que la modification des numéros.

  • Soyez aussi restrictif que possible concernant le code auquel une règle s'appliquera. N'ajoutez jamais de règles au groupe All_Code au niveau de l'ordinateur ; ajoutez-les toujours à une Zone ou à un autre sous-groupe sous des Zones. Il est préférable de ne pas avoir de règles inattendues régissant le code.

  • Ajoutez en premier les règles à large portée, par exemple zone, puis site, puis éditeur, plutôt qu'éditeur, puis site, puis zone. De cette façon, les règles de zone spécifiques peuvent être appliquées au code spécifique, et ne seront pas appliquées à l'ensemble du code de l'éditeur tant que les restrictions sont nécessaires.

  • Si un groupe parent, par exemple le groupe LocalIntranet_Zone, n'existe plus, vous devez le recréer. Notez que vous devez exécuter cette opération avec le jeu d'autorisations Nothing. Le jeu d'autorisations Nothing empêche l'application d'autorisations par défaut que l'administrateur a désactivées en supprimant le groupe de codes. Par exemple, si l'administrateur supprime LocalIntranet_Zone, l'ensemble du code de l'intranet local cesse de s'exécuter. Quand vous recréer le groupe de codes et que vous utilisez le jeu d'autorisations Nothing, aucune nouvelle autorisation ne peut être ajoutée.

  • Désactivez les avertissements de changement de stratégie dans les fichiers batch et n'oubliez pas de les réactiver ensuite s'ils étaient activés pour le démarrage. De cette façon, vos fichiers batch ne seront pas arrêtés, dans l'attente d'une entrée de l'utilisateur. Ce paramètre s'applique à tous les utilisateurs et pas seulement à l'utilisateur actuel. Pour plus d'informations, consultez Comment : supprimer les avertissements de modification de la stratégie à l'aide de Caspol.exe.

  • Lorsque vous utilisez Caspol.exe, spécifiez explicitement le niveau de stratégie à modifier (Entreprise, Ordinateur ou Utilisateur) ; ne vous fiez pas à la valeur par défaut. La valeur par défaut peut être incorrecte pour la stratégie que vous modifiez. Pour plus d'informations, consultez Niveaux de stratégie de sécurité.

  • N'utilisez pas les attributs Exclusive ou Level-Final, sauf en cas d'absolue nécessité, car ils peuvent provoquer un comportement inattendu si un nouveau groupe de codes est ajouté. Pour plus d'informations, consultez Attributs de groupe de codes.

Voir aussi

Concepts

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

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

Autres ressources

Administration de stratégie de sécurité générale

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