Sécurité dans l'accès distant
En général, les applications qui utilisent .NET Framework Remoting se caractérisent par un ensemble plus complexe de questions relatives à la sécurité que les applications locales.
La sécurisation d'applications distribuées pose un problème qu'il est difficile de résoudre sans recourir à des mesures qui affectent les performances. Si l'extrémité d'une communication est à l'écoute d'un appel, un client non autorisé connaissant le point d'entrée qui est à l'écoute peut tenter de passer des informations sérialisées pour que les informations soient désérialisées et appelées à l'autre extrémité. Le seul moyen d'être quasiment sûr que la communication a lieu entre des composants fiables est de procéder à l'authentification mutuelle suivie du chiffrement du contenu. Par conséquent, vous devez commencer par évaluer les besoins en matière de sécurité de votre application d'accès distant, puis évaluer les besoins en performances. Vous devez exposer les données et les points d'entrée sans authentification ni chiffrement au degré d'intégrité que vous exigez pour les données de votre application.
Les délégués d'accès distant illustrent le problème. Étant donné que des délégués peuvent envelopper les informations de types des méthodes statiques, qui ne s'exécutent jamais à distance, vos applications serveur doivent toujours déclarer un type de délégué personnalisé avec des paramètres personnalisés qui, pris ensemble, ne correspondent jamais à une méthode statique pouvant être appelée sur l'ordinateur serveur. Vous ne devez jamais autoriser un client à définir et à passer à votre application un type que votre serveur pourrait désérialiser.
Une bonne connaissance du niveau de sécurité souhaité et de son emplacement est un aspect important de la conception d'applications distribuées utilisant l'infrastructure .NET Framework Remoting. Cette section décrit les diverses approches en matière de sécurité en fonction de certaines décisions de conception. Tous les scénarios ne sont pas évoqués, mais ces rubriques représentent un bon point de départ pour prendre des décisions.
Sécurité d'accès du code
La sécurité d'accès du code contrôle l'accès du code exécutable aux ressources et aux opérations en fonction de la stratégie de sécurité définie par l'administrateur de cet ordinateur. Toutefois, étant donné que la sécurité d'accès du code ne parcourt pas la pile sur une connexion distante, les développeurs d'applications d'accès distant doivent comprendre que l'infrastructure de l'accès distant exige un niveau de confiance suffisant pour s'exécuter sur le client ou le serveur. Toute utilisation non autorisée d'une application d'accès distant fournit un accès non autorisé aux autorisations FullTrust.
Avertissement
Vous ne devez jamais essayer de créer un wrapper accessible à distance pour un objet AppDomain. Si vous le faites, vous risquez de pouvoir publier une référence à cet objet AppDomain à distance, ce qui expose la méthode AppDomain.CreateInstance (ou d'autres méthodes) à distance et réduit à néant la sécurité d'accès du code de cet objet AppDomain. Des clients non autorisés se connectant à l'objet AppDomain distant risquent d'obtenir l'accès à des ressources auxquelles l'objet AppDomain peut accéder. En fait, vous ne devez pas créer un wrapper accessible à distance pour les types qui étendent MarshalByRefObject et implémentent des méthodes susceptibles d'être utilisées par des clients non autorisés pour contourner le système de sécurité.
Notes
De manière plus générale, plusieurs types système étendent MarshalByRefObject mais effectuent également des contrôles de sécurité au moment de l'exécution pour empêcher qu'un élément situé hors du domaine de l'application n'appelle un objet de ce type MarshalByRefObject à distance. AppDomain et System.Windows.Forms.Form sont deux exemples de ces types système. Il serait simple de penser que vous pouvez étendre MarshalByRefObject et obtenir une référence à distance, mais cela n'est pas le cas avec ces types spéciaux. Vous pouvez envelopper la référence in-process avec un autre type accessible à distance, mais cela contourne accidentellement la sécurité d'accès du code et ne doit donc jamais être effectué.
Considérations relatives à la sécurité des applications distantes
En général, il existe deux aspects relatifs à la sécurité que vous pouvez avoir besoin d'aborder dans vos applications distribuées en fonction de votre scénario particulier. Vous pouvez sécuriser le canal de communication et le message lui-même ou protéger l'application contre toute utilisation incorrecte. Vous pouvez également effectuer les deux dans une certaine mesure.
Généralement, pour sécuriser le canal de communication, vous devez chiffrer le canal, chiffrer le contenu du message d'un côté du flux et le déchiffrer de l'autre ou faire les deux. Le contenu du message peut exiger un contrôle d'intégrité, pour s'assurer que personne ne l'a falsifié. Il peut également être nécessaire de confirmer l'identité du client ou du serveur (ou les deux).
Tout d'abord, vous devez toujours authentifier les clients pour confirmer qu'ils disposent des autorisations pour utiliser la ressource. Vous devez ensuite chiffrer toutes les conversations afin de protéger les données lors de la transmission. Ces deux étapes sont entièrement prises en charge par HttpChannel et TcpChannel. Le canal IPC fonctionnant uniquement sur le même ordinateur, l'authentification Windows est prise en charge, mais pas le chiffrement.
Certains scénarios constituent des exceptions aux deux règles précédentes. Le chiffrement peut être supprimé si les besoins en performances sont suffisamment élevés et si la valeur des données est suffisamment basse pour que l'observation et la manipulation de données perdent de leur importance. Le chiffrement peut également être désactivé lorsque la communication se déroule sur un réseau chiffré, tel qu'un réseau sécurisé par IPsec.
Vous pouvez aussi améliorer la protection de l'application contre des utilisations non autorisées en enregistrant le comportement de l'utilisateur pour reconstruire ensuite les modèles d'utilisation.
Avertissement
.NET Framework Remoting n'effectue aucune authentification ni aucun chiffrement par défaut. Par conséquent, il est recommandé d'effectuer toutes les opérations nécessaires pour vous assurer de l'identité des clients ou des serveurs avant d'interagir avec eux à distance. Étant donné que les applications .NET Framework Remoting exigent les autorisations FullTrust pour s'exécuter, si un client non autorisé se voyait accorder l'accès à votre serveur, il pourrait exécuter du code comme s'il était d'un niveau de confiance suffisant. Authentifiez toujours vos points d'entrée et chiffrez les flux de communication, en hébergeant vos types distants dans IIS (Internet Information Services) ou en créant une paire de récepteurs de canal personnalisée pour effectuer cette tâche. Dans le .NET Framework version 2.0, vous n'avez plus besoin de générer un récepteur personnalisé pour sécuriser la communication. Les fonctionnalités d'authentification et de chiffrement (activées en définissant secure = true pour le canal TCP) permettent de sécuriser la communication. Le canal TCP vous permet désormais d'authentifier l'utilisateur qui se connecte, de chiffrer des données sur le réseau et de déterminer l'identité et l'adresse IP d'un client qui se connecte.
Voir aussi
Référence
RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices
Concepts
Authentification avec le canal HTTP
Autres ressources
Vue d'ensemble de .NET Framework Remoting
Sécurité basée sur les rôles
Sécurité d'accès du code