Recommandations de sécurité pour les services de workflow
Vous trouverez ci-dessous des recommandations de sécurité à utiliser lors de la création et du déploiement des services de workflow.
Utilisez des messages signés et chiffrés lors des communications entre le client et le service, ou le service et la base de données de persistance, pour empêcher des utilisateurs malveillants de lire ou de modifier les données envoyées via le réseau. Pour plus d'informations sur les niveaux de protection des messages, consultez Understanding Protection Level.
Utilisez des autorisations principales et des revendications au lieu d'ID de conversation ou d'ID d'instance pour l'authentification ou l'autorisation. Pour plus d'informations sur l'utilisation des autorisations principales et des revendications, consultez How to: Restrict Access With the PrincipalPermissionAttribute.
Utilisez des listes de contrôle d'accès (Access Control List ou ACL) et des assemblys signés provenant de sources fiables pour empêcher des utilisateurs malveillants de personnifier le service de workflow.
Suivez les recommandations d'obscurcissement pour vous assurer que des utilisateurs malveillants ne peuvent pas désassembler l'assembly de service de workflow ni lire les informations de liaison ou les valeurs de propriété statiquement définies (ou les deux) dans l'assembly.
Verrouillez l'accès à la base de données de persistance et effectuez un audit de la base de données pour vérifier qu'il n'existe aucune violation d'accès. Utilisez des ACL et l'audit de fichier si vous stockez des données sérialisées dans le système de fichiers.
Faites en sorte que le cache de fabrication de canal sur le client ne puisse pas être accédé publiquement afin d'empêcher des utilisateurs malveillants d'utiliser un compte d'utilisateur de domaine dans l'application pour modifier le cache de fabrication de canal et rediriger les clients vers un service de workflow différent.
Protégez tous les fichiers de configuration par des ACL et facultativement chiffrez la chaîne de connexion contenue dans l'élément connectionStrings pour empêcher des utilisateurs malveillants de découvrir la chaîne de connexion que vous utilisez pour vous connecter à la base de données.
Envisagez d'utiliser un fichier basé sur la base de données à l'aide d'ASP NET VirtualPathProvider au lieu de déployer le fichier réel de balise de workflow &.rules dans IIS.
Présentez un ensemble minime d'autorisations au processus qui héberge le service de workflow et évitez d'exécuter le processus (IIS App pool) avec les privilèges d'administrateur.
Faites en sorte que les composants tiers, tels que les activités personnalisées, les services d'hébergement personnalisés et les composants du répartiteur personnalisés, soient tous fiables et se conforment au thème de sécurité globale de l'application.
Utilisez la clé de Registre MaxFieldLength pour HTTP.sys afin de limiter la taille des en-tête http que le service reçoit de clients. Cela empêchera des utilisateurs malveillants de joindre un cookie de contexte HTTP volumineux aux messages envoyés au serveur. Pour plus d'informations sur la définition de cette clé de Registre, consultez les paramètres du Registre pour IIS (page pouvant être en anglais).
Utilisez EncryptandSign ou le protocole de transport Https pour empêcher des utilisateurs malveillants de lire un en-tête de contexte confidentiel ou des informations de cookie en transit entre le client et le service.
Comprenez que lors de l'utilisation d'une liaison de contexte pour le transport de session, l'identité n'est pas immuable pendant la durée de vie d'une session.
Voir aussi
Autres ressources
Considérations sur la sécurité pour les services de workflow et les services fiables
Copyright ©2007 par Microsoft Corporation. Tous droits réservés.