Procédure : évaluer et approuver un modèle de formulaire

Mise à jour : 2007-06-07

Dans cet article :

  • À propos de l’évaluation des modèles de formulaire

  • Facteurs à prendre en compte lorsque vous évaluez un modèle de formulaire

Cet article fournit des informations détaillées à l’intention des administrateurs d’une batterie de serveurs Microsoft Office SharePoint Server 2007 sur l’évaluation d’un modèle de formulaire certifié par l’administrateur pour approbation. Notez que cet article ne vise pas à fournir une liste complète de tous les facteurs à prendre en compte. En fonction de votre environnement, d’autres aspects risquent ne pas figurer dans cet article.

À propos de l’évaluation des modèles de formulaire

Si vous êtes chargé de l’approbation et du chargement des modèles de formulaire d’Office InfoPath 2007 sur une batterie de serveurs qui utilise InfoPath Forms Services, vous devez savoir comment identifier les problèmes potentiels des modèles de formulaire que vous approuvez. Comme les modèles de formulaires peuvent contenir des fonctionnalités qui utilisent des ressources sur le serveur ou établissent des connexions avec des sources de données à l’extérieur de la batterie de serveurs (par exemple, le code managé ajouté par le développeur de formulaires), il est important d’évaluer avec soin l’incidence d’un modèle de formulaire sur les performances et la sécurité d’une batterie de serveurs.

Office InfoPath 2007 est conçu pour impliquer un administrateur dans le flux de travail d’approbation pour les modèles de formulaire. Si l’administrateur chargé de l’approbation des modèles de formulaire n’apporte pas le soin requis lors de l’approbation d’un modèle de formulaire, les conséquences peuvent notamment inclure :

  • Violations de sécurité entraînant des intrusions réseau ou une perte de données.

  • Impact négatif sur les performances de la batterie de serveurs.

  • Défaillance du modèle de formulaire entraînant la perte de données utilisateur.

  • Défaillance générale de la batterie de serveurs Office SharePoint Server.

Il convient donc d’évaluer rigoureusement chaque modèle de formulaire approuvé par l’administrateur avant de charger le modèle de formulaire dans la batterie de serveurs. Notez qu’une bonne évaluation d’un modèle de formulaire nécessite la compréhension de la structure et de la logique des modèles de formulaire. Pour plus d’informations sur les modèles de formulaire d’Office InfoPath 2007, consultez Aide et procédures InfoPath 2007 (https://office.microsoft.com/fr-fr/infopath/FX100647031036.aspx).

Facteurs à prendre en compte lorsque vous évaluez un modèle de formulaire

Les facteurs importants à prendre en compte lorsque vous évaluez un modèle de formulaire sont les suivants :

  • Code managé   Établissez des instructions appropriées et appliquez des méthodes conseillées pour l’écriture du code des modèles de formulaire. Les modèles de formulaire qui contiennent du code managé doivent bénéficier du niveau de sécurité de domaine ou du niveau de sécurité Confiance totale, et par conséquent peuvent poser un problème de sécurité. Vérifiez que le code dans un modèle de formulaire est indispensable au bon fonctionnement du formulaire. Si la fonctionnalité désirée peut être obtenue sans utiliser de code, recréez le modèle de formulaire et attribuez-lui le niveau de sécurité le plus restrictif possible. Notez que l’évaluation du code dans un modèle de formulaire peut nécessiter des compétences de niveau développeur.

    La liste suivante présente les facteurs clés à prendre en compte lors de l’évaluation du code dans un modèle de formulaire.

    • Les assemblys .NET dans le modèle de formulaire doivent être signés avec des noms forts afin d’empêcher la falsification malveillante de l’assembly. Pour plus d’informations, voir Comment : signer un assembly avec un nom fort (https://msdn2.microsoft.com/fr-fr/library/xc31ft41(VS.80).aspx?amp%3bclcid=0x40c).

    • Les appels d’accès à des ressources externes, telles que des bases de données et des services Web, doivent être soigneusement vérifiés. Certaines demandes à des ressources externes peuvent ne pas fonctionner si l’authentification Kerberos n’a pas été déployée dans l’environnement de batterie de serveurs. En outre, des données qui résident sur un ordinateur dans un autre domaine peuvent être demandées et partagées avec des utilisateurs qui n’ont pas l’autorisation d’afficher les données.

    • Envisagez l’automatisation de la validation des stratégies de code pour les assemblys .NET à l’aide de FxCop. FxCop est un outil d’analyse de code Microsoft qui vérifie les assemblys de code managé .NET pour garantir la conformité aux directives de conception du Microsoft .NET Framework. Pour plus d’informations, consultez FxCop Team Page (https://go.microsoft.com/fwlink/?linkid=91446&clcid=0x40C).

  • **Planification des performances et de la capacité   **La conception et l’utilisation de modèles de formulaire risquent d’avoir une incidence significative sur les performances de la batterie de serveurs, et doivent être planifiées dans tout environnement de production. Si le formulaire est utilisé pour envoyer des données à la batterie de serveurs, assurez-vous que la capacité de la batterie est adéquate pour stocker les données, sinon une perte des données de l’utilisateur pourrait survenir. Pour plus d’informations, consultez Planifier les performances et la capacité (Office SharePoint Server).

  • Vérifier le modèle de formulaire   Avant de charger le modèle de formulaire dans le site Web Administration centrale, cliquez sur le bouton Vérifier dans la page Télécharger un modèle de formulaire. Si vous ne vérifiez pas manuellement le modèle de formulaire, il sera vérifié automatiquement pendant le processus de transfert. Cependant, la vérification manuelle retourne des messages et des erreurs, tandis que la vérification automatique ne retourne que les erreurs, le cas échéant. Pour plus d’informations sur la vérification et le chargement d’un modèle de formulaire, consultez Déployer des modèles de formulaires approuvés par l’administrateur (Office SharePoint Server).

  • Authentification   Si l’authentification NTLM est utilisée, sachez que NTLM peut uniquement authentifier l’ordinateur client. Dans un scénario où le jeton d’authentification doit être passé à une troisième ressource, par exemple lorsqu’un service Web appelé par le formulaire doit soumettre des données à une base de données, l’authentification NTLM à la troisième ressource va échouer. Dans ce cas, envisagez d’utiliser une autre méthode d’authentification, telle que l’authentification Kerberos, qui est conçue pour passer le jeton d’authentification. Dans la mesure du possible, des modèles de formulaire doivent utiliser des fichiers de connexion de données dans un magasin de connexions de données géré de manière centralisée pour établir des connexions à des sources de données externes. Pour plus d’informations sur les connexions de données, consultez « Connexions de données » plus loin dans cet article.

  • Niveau de sécurité   Assurez-vous que le niveau de sécurité du modèle de formulaire convient à la finalité du formulaire. Par exemple, un modèle de formulaire qui n’utilise pas de connexions de données exigeant une authentification de domaine, ne contient pas de code managé ou ne demande pas de données à une ressource d’un autre domaine, ne doit pas être configuré au niveau de sécurité Autorisation totale. Pour plus d’informations, consultez Niveaux de sécurité des formulaires InfoPath (https://office.microsoft.com/fr-fr/infopath/HP101534981036.aspx).

  • Mots de passe   Vérifiez que les mots de passe et autres informations d’authentification ne sont pas codées en dur dans le modèle de formulaire. Toute fonctionnalité dans le modèle de formulaire qui requiert l’authentification doit être authentifiée par les utilisateurs au moment du remplissage du formulaire, ou à l’aide de connexions de données authentifiées. En outre, les mots de passe ne doivent pas être stockés dans la source de données d’un modèle de formulaire, et ne doivent pas être envoyés en texte brut.

  • Autorisations   Les auteurs de modèle de formulaire doivent limiter l’accès à un modèle de formulaire de production en affectant des autorisations en lecture seule aux utilisateurs du formulaire, un accès en écriture au personnel de maintenance des formulaires et aucun accès à tout le monde. Même si des modèles de formulaire sont installés sur des ordinateurs d’utilisateur par un script d’ouverture de session, vous pouvez quand même contrôler l’accès au fichier .xsn si l’utilisateur n’est pas connecté en tant qu’administrateur. Vous pouvez le faire en attribuant à l’utilisateur un accès en lecture seule au fichier de modèle.

  • Données sensibles   Office InfoPath 2007Les modèles de formulaire sont des documents XML en texte brut, et ne doivent pas contenir des données que vous ne souhaitez pas exposer à des utilisateurs. Un utilisateur malveillant disposant d’un accès en lecture peut lire le contenu d’un formulaire XML d’Office InfoPath 2007 à l’aide du Bloc-notes ou de tout autre éditeur de texte, contournant ainsi toute logique d’authentification.

  • Logique métier   Office InfoPath 2007 utilise le modèle de formulaire pour stocker toute la logique de formulaire. Comme les utilisateurs doivent accéder au modèle de formulaire pour ouvrir tout formulaire basé sur ce modèle, ils peuvent potentiellement modifier le modèle de formulaire, contournant ainsi les restrictions que l’auteur a pu mettre en place. Cela signifie que l’authentification et l’autorisation effectuées côté client ne peuvent pas être considérées sécurisées. Pour garantir la sécurité, les calculs et la validation des données doivent être effectués côté serveur.

    Les exemples suivants illustrent diverses manières de concevoir un modèle de formulaire pour utiliser le calcul et l’authentification côté serveur.

    • Ne stockez pas de données sensibles dans le fichier XML. Stockez plutôt des clés dans le fichier XML et effectuez des requêtes qui remplissent le reste des données à l’aide d’une connexion de base de données ou d’un service Web. Si l’utilisateur n’est pas autorisé, retournez un ensemble de données vide. Vous pouvez détecter une telle condition côté client et afficher un message d’erreur convivial si l’utilisateur n’est pas autorisé à afficher les données de formulaire.

    • Lors de la soumission d’un envoi, envoyez les données à un service Web et effectuez toutes les validations possibles côté serveur. Par exemple, si une condition empêche les employés d’envoyer des notes de frais supérieures à 100 € sans spécifier d’approbateur, demandez au service Web de traiter l’ensemble de données et de vérifier que la condition est satisfaite avant d’envoyer les données.

  • Connexions de données   Vérifiez que, dans la mesure du possible, les auteurs de modèle de formulaire utilisent les paramètres de connexion de données des fichiers de connexion de données stockés dans le magasin de connexions de données géré de manière centralisée pour établir des connexions à des ressources externes à partir d’un modèle de formulaire. L’utilisation de fichiers de connexion de données gérés de manière centralisée présente les avantages suivants :

    • Plusieurs formulaires peuvent utiliser le même fichier de connexion de données, il n’est donc pas nécessaire de recréer la même connexion de données à partir de zéro pour chaque formulaire.

    • Si les paramètres d’emplacement ou de connexion d’une source de données externe changent, vous ne devez mettre à jour que le fichier de connexion de données, et non chaque modèle de formulaire.

    • Le fichier de connexion de données peut contenir des informations d\rquote authentification secondaires pouvant être utilisées par le serveur quand un utilisateur remplit un formulaire dans un navigateur.

    • Les formulaires qui sont remplis dans un navigateur sans un niveau de sécurité Autorisation totale peuvent se connecter à un ordinateur dans un autre domaine si toutes les connexions de données sur le formulaire utilisent des fichiers de connexion de données. Pour plus d’informations, consultez Présentation des connexions de données (https://office.microsoft.com/fr-fr/infopath/HP012304861036.aspx).

  • Dépendances externes   Les modèles de formulaire peuvent utiliser des ressources externes telles que des connexions de données, des services Web, des bases de données et des bibliothèques de documents. Vérifiez que toutes les ressources externes sont valides et disponibles avant de mettre à disposition un modèle de formulaire à utiliser.

  • Gestion des droits relatifs à l’information   La gestion des droits relatifs à l’information (IRM) ne peut pas être utilisée pour protéger des modèles de formulaire pour navigateur.

Voir aussi

Autres ressources

Notions relatives à la sécurité des modèles de formulaires et des formulaires
Niveaux de sécurité des formulaires InfoPath
Aide et procédure InfoPath 2007
Présentation des connexions de données
Définir le niveau de sécurité requis pour un modèle de formulaire
Recommandations en matière de codage sécurisé
Page de l’équipe FxCop
Comment : signer un assembly avec un nom fort