Sécurité des Services RIA WCF
Cette rubrique fournit des conseils permettant de sécuriser l'utilisation des services de domaine. Lorsque vous exposez un service de domaine en appliquant l'attribut EnableClientAccessAttribute, le service de domaine est disponible pour tous les utilisateurs du réseau sur lequel il est exposé. Vous ne pouvez pas supposer que votre application cliente sera la seule à accéder au service de domaine. Ce point est particulièrement important sur un réseau public. Mais il l'est également sur un réseau restreint, par exemple un réseau d'entreprise, lorsque des données sensibles sont exposées.
La boîte de dialogue Ajouter une nouvelle classe de service de domaine produit du code qui vous aidera à débuter avec les services de domaine. Le code produit n'est pas nécessairement prêt pour le déploiement. Vous devez l'examiner et le modifier pour qu'il remplisse les conditions de sécurité de votre application. Vous devez notamment prendre en compte les opérations que vous mettez à la disposition de tous sur le réseau. La liste de contrôle suivante est un bon point de départ pour mieux sécuriser l'utilisation des services de domaine.
Liste de contrôle de sécurité
Pour sécuriser l'utilisation des services de domaine, observez les recommandations suivantes.
Réduisez les données et les opérations exposées par un service de domaine. Ceci est la première ligne de défense contre la divulgation d'informations et les dénis de service.
N'exposez que les entités dont le client a besoin. Cette approche peut exiger que vous sépariez la logique et la validation serveur de la logique et la validation client, si cela vous permet de réduire le nombre d'entités exposées. Par exemple, une application de notes de frais qui n'a pas besoin de l'entité Employé sur le client ne doit pas exposer cette entité via un service de domaine.
Concevez vos entités de façon à éviter d'exposer des données sensibles. Vous pouvez utiliser l'attribut ExcludeAttribute ou les Modèles de présentation pour réduire les données mises à la disposition d'un client. Par exemple, si la date de naissance et le numéro de Sécurité Sociale ne sont pas requis par une application, excluez-les de la forme que le client pourra voir.
Exigez des méthodes de requête qui prennent les paramètres nécessaires à votre application, au lieu de vous reposer sur les capacités de filtrage des données de LINQ. Par exemple, si les notes de frais d'un employé donné sont affichées, vous devez exiger un ID employé comme paramètre de la méthode de requête et ne pas fournir de méthode qui obtienne toutes les notes de frais. Cette approche limite la possibilité de recueillir des données sur tous les employés.
Créez des méthodes de requête qui ne fournissent que les données exigées pour des scénarios spécifiques de votre application. Cette approche signifie que vous pouvez fournir plusieurs méthodes de requête qui retournent des portions de données, plutôt qu'une méthode de requête unique qui retourne toutes les données. Par exemple, si les produits s'affichent par catégorie ou par fournisseur, vous pouvez fournir deux méthodes qui acceptent les informations de catégorie ou de fournisseur, plutôt qu'une méthode unique qui retourne tous les produits.
Filtrez les données pour ne fournir que celles normalement requises pour votre application. Par exemple, vous pouvez avoir une méthode de requête qui ne retourne que les commandes honorées l'année précédente.
Limitez le nombre des résultats pouvant être retournés par une requête afin de réduire les surcharges du serveur, accidentelles ou délibérées. Vous pouvez utiliser la propriété ResultLimit sur l'objet QueryAttribute pour limiter fortement le nombre de résultats pouvant être retournés. Par exemple, si un grand nombre de produits peut être retourné, imposez la pagination sur le client en limitant le nombre de résultats à 20. Vous pouvez aussi envisager d'utiliser l'attribut OutputCacheAttribute pour mettre la sortie en cache afin de réduire la charge pesant sur la couche intermédiaire et la base de données.
Limitez le nombre d'opérations pour chaque entité exposée. Par exemple, si une application de commandes ne doit qu'ajouter ou modifier des commandes, vous devez exposer les opérations de requête, d'insertion et de mise à jour sur l'entité des commandes, mais pas les opérations de suppression. En outre, vous ne devez exposer que les opérations de requête pour l'entité des produits et n'exposer aucune opération de modification des données.
Chaque fois que possible, utilisez des méthodes de mise à jour personnalisée qui limitent les membres pouvant être mis à jour.
Limitez l'accès aux données et aux opérations aux seuls utilisateurs authentifiés et aux utilisateurs ayant des rôles spécifiques.
Chaque fois que possible, évitez les accès anonymes à l'aide de l'attribut RequiresAuthenticationAttribute. Lorsque vous devez autoriser les accès anonymes, limitez-les au jeu de services de domaine et au sous-ensemble d'opérations les plus petits possibles dans ces services de domaine.
Ajoutez l'attribut RequiresRoleAttribute spécifique aux opérations chaque fois que possible. Considérez séparément chaque opération dans un service de domaine. Par exemple, tous les utilisateurs auront peut-être besoin d'exécuter des requêtes sur l'entité des produits, mais seuls les utilisateurs ayant le rôle Administrateur auront besoin de mettre cette entité à jour.
Pensez à utiliser la propriété AuthorizationContext pour fournir un modèle d'autorisation personnalisé.
Traitez toutes les données envoyées par un client comme douteuses. Un client malveillant (même s'il est authentifié et autorisé) peut fournir des valeurs falsifiées à la place des valeurs actuelles ou d'origine dans un jeu de modifications. Votre logique d'application ne doit pas supposer que ces valeurs sont dignes de confiance. Pensez plutôt à des menaces potentielles provenant de valeurs d'origine falsifiées.
Utilisez le protocole https pour l'Authentification par formulaire. L'envoi de mots de passe en texte clair est une faille de sécurité dangereuse, mais que le protocole https peut atténuer.
Exposez un nombre minimal de points de terminaison. Par défaut, les Services RIA créent un point de terminaison binaire pour un service de domaine. N'ajoutez des points de terminaison supplémentaires que si vous avez des clients qui en ont spécifiquement besoin. Désactivez tous les points de terminaison qui ne sont pas en cours d'utilisation.