Module 4 – Communication sécurisée

  • Article

Dernière mise à jour le 31 août 2004

Sur cette page

Dans ce module
Objectifs
S'applique à
Comment utiliser ce module
Avant de commencer
Quels éléments sécuriser ?
SSL/TLS
IPSec
Cryptage RPC
Sécurité point à point
Choix entre IPSec et SSL
Utilisation de plusieurs sites et équilibrage de charge
Résumé

Dans ce module

Les applications distribuées traitent fréquemment des informations sensibles : des informations d'identification utilisées pour l'authentification des utilisateurs ou des renseignements confidentiels sur une personne (historique médical ou curriculum vitae, par exemple). Ces informations doivent être sécurisées en permanence, qu'elles soient stockées dans une base de données ou transmises sur un réseau entre des composants de l'application distribuée.

La communication sécurisée entre les composants d'une application Web distribuée est un aspect important d'une architecture de sécurité renforcée, notamment lorsque l'application utilise des réseaux publics (comme Internet) pour transmettre des informations sensibles.

Ce module explique pourquoi les communications sécurisées sont nécessaires et décrit les technologies disponibles dans ce domaine pour les applications Web ASP.NET.

Haut de page

Objectifs

Ce module vous permet d'effectuer les opérations suivantes :

  • comprendre pourquoi et comment sécuriser les communications réseau entre les différents niveaux des applications Web .NET distribuées ;

  • comprendre la nature, les fonctionnalités et les limites de trois technologies importantes pour l'implémentation de communications sécurisées : cryptage SSL/TLS, IPSec et RPC ;

  • décider de la méthode la plus indiquée (cryptage SSL/TLS, IPSec, RPC) pour sécuriser les communications entre les différents éléments de l'application Web distribuée.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Windows XP ou Windows 2000 Server (avec le service pack 3) et systèmes d'exploitation ultérieurs

  • Microsoft Internet Information Services (IIS) versions 5.0 et ultérieures

  • SQL Server 2000 (avec le service pack 2) et versions ultérieures

Haut de page

Comment utiliser ce module

Pour tirer le meilleur parti possible de ce module :

  • Lisez le Module 1, « Introduction ». Ce module souligne l'importance des communications sécurisées dans le cadre des applications Web distribuées.

  • Lisez le Module 2, « Modèle de sécurité pour les applications ASP.NET ». Ce module présente l'architecture et les technologies exploitées pour créer des applications Web ASP.NET distribuées et explique comment les communications sécurisées s'intègrent dans cette architecture.

  • Consultez les modules suivants, qui expliquent l'implémentation des techniques de communication sécurisée présentées dans ce module :

    • « Procédure : Appeler un service Web avec SSL ».

    • « Procédure : Configurer SSL sur un serveur Web ».

    • « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs ».

    • « Procédure : Utiliser SSL pour sécuriser les communications avec SQL Server 2000 ».

Haut de page

Avant de commencer

De nombreuses applications transmettent des données confidentielles sur des réseaux, entre différents utilisateurs finaux et entre des nœuds d'applications intermédiaires. Il peut s'agir, entre autres, d'informations d'identification utilisées pour l'authentification, de données telles que des numéros de carte de crédit ou d'informations liées à des transactions bancaires. Pour éviter la divulgation involontaire des informations et pour empêcher une modification non autorisée des données durant leur transit, le canal entre les points de terminaison de la communication doit être sécurisé.

La communication sécurisée offre les deux fonctionnalités suivantes :

  • Confidentialité. La confidentialité consiste à garantir le caractère privé et confidentiel des données et à empêcher des personnes susceptibles d'être équipées de logiciels de surveillance du réseau de consulter ces données. La confidentialité est généralement assurée au moyen du cryptage.

  • Intégrité. Les canaux de communication sécurisés doivent également garantir que les données sont protégées contre toute modification accidentelle ou délibérée (malveillante) lors de leur transit. L'intégrité est généralement assurée au moyen de codes d'authentification des messages (MAC, Message Authentication Code).

Ce module décrit les technologies de communication sécurisée suivantes :

  • SSL (Secure Sockets Layer) / TLS (Transport Layer Security). Ces technologies sont le plus souvent utilisées pour sécuriser le canal entre un navigateur et un serveur Web. Cependant, elles permettent aussi de sécuriser les communications et les messages des services Web échangés en provenance et à destination d'un serveur de base de données qui exécute Microsoft® SQL Server™ 2000.

  • IPSec (Internet Protocol Security). Le protocole IPSec offre une solution de communication sécurisée au niveau du transport et peut être utilisé pour sécuriser les données transmises entre deux ordinateurs, un serveur d'applications et un serveur de base de données, par exemple.

  • Cryptage RPC (Remote Procedure Call). Le protocole RPC utilisé par DCOM (Distributed COM) offre un niveau d'authentification (confidentialité des paquets) qui entraîne le cryptage de chaque paquet de données envoyé entre le client et le serveur.

Haut de page

Quels éléments sécuriser ?

Lorsqu'une demande Web transite sur les différents niveaux de déploiement physique de votre application, elle traverse plusieurs canaux de communication. Un modèle de déploiement d'application Web couramment utilisé est présenté dans la figure 4.1.

Figure 4.1 Modèle de déploiement Web courant

Dans ce modèle de déploiement courant, une demande transite par trois canaux distincts. La liaison client/serveur Web peut être établie sur Internet ou sur l'intranet de l'entreprise et utilise généralement le protocole HTTP. Les deux liaisons restantes sont établies entre des serveurs internes dans le domaine de l'entreprise. Néanmoins, les trois liaisons peuvent engendrer des problèmes de sécurité potentiels. De nombreuses applications reposant purement sur un intranet transmettent des données sensibles entre les différents niveaux : des applications de ressources humaines et de gestion des salaires qui traitent des données confidentielles relatives aux employées, par exemple.

La figure 4.2 indique comment chaque canal peut être sécurisé grâce à l'association du cryptage RPC, SSL et IPSec.

Figure 4.2 Modèle de déploiement Web courant doté de communications sécurisées

Le choix de la technologie dépend de plusieurs facteurs, notamment du protocole de transport, des technologies sur les points de terminaison et de considérations concernant l'environnement (telles que le matériel, les versions de système d'exploitation, les pare-feu).

Haut de page

SSL/TLS

SSL/TLS permet d'établir un canal de communication crypté entre le client et le serveur. Le système d'établissement de liaison utilisé pour mettre en place le canal sécurisé est présenté en détail dans les articles suivants de la Base de connaissances Microsoft :

Utilisation du protocole SSL

Lorsque vous utilisez le protocole SSL, veillez à prendre en compte les considérations suivantes :

  • Lorsque SSL est utilisé, le client fait appel au protocole HTTPS (et spécifie une URL https://), et le serveur est à l'écoute du port TCP 443.

  • Vous devez surveiller les performances de votre application lorsque vous activez SSL. SSL utilise des fonctions de cryptage complexes pour crypter et décrypter les données. Ces fonctions ont une incidence sur les performances de votre application. L'impact le plus important en termes de performances intervient pendant l'établissement de liaison initial, lorsque le cryptage asymétrique clé publique/privée est utilisé. Par la suite (une fois qu'une clé de session sécurisée a été générée et échangée), un cryptage symétrique, plus rapide, est utilisé pour crypter les données des applications.

  • Vous devez optimiser les pages qui utilisent SSL en y plaçant moins de texte et des graphiques simples.

  • Dans la mesure où l'impact en termes de performances associé à SSL est plus important durant l'établissement d'une session, assurez-vous que vos connexions n'expirent pas. Vous pouvez régler ce paramètre en augmentant la valeur de l'entrée de Registre ServerCacheTime. Pour plus d'informations, consultez l'article Q247658, « HOW TO: Configure Secure Sockets Layer Server and Client Cache Elements » (en anglais) de la Base de connaissances Microsoft.

  • SSL nécessite l'installation d'un certificat d'authentification serveur sur le serveur Web (ou le serveur de base de données si vous utilisez SSL pour communiquer avec SQL Server 2000). Pour plus d'informations sur l'installation de certificats d'authentification serveur, consultez la section « Configurer SSL sur un serveur Web » dans ce guide.

Haut de page

IPSec

Le protocole IPSec peut être utilisé pour sécuriser les données envoyées entre deux ordinateurs, entre un serveur d'applications et un serveur de base de données, par exemple. IPSec est entièrement transparent pour les applications dans la mesure où les services de cryptage, d'intégrité et d'authentification sont implémentés au niveau du transport. Les applications continuent de communiquer normalement les unes avec les autres à l'aide des ports TCP et UDP.

IPSec vous permet d'effectuer les opérations suivantes :

  • Assurer la confidentialité des messages en cryptant toutes les données envoyées entre deux ordinateurs.

  • Assurer l'intégrité des messages entre deux ordinateurs (sans crypter les données).

  • Assurer une authentification mutuelle entre deux ordinateurs (et non des utilisateurs). Vous pouvez par exemple faciliter la sécurisation d'un serveur de base de données en établissant une stratégie qui autorise uniquement les demandes émanant d'un ordinateur client spécifique (un serveur Web ou un serveur d'applications, par exemple).

  • Limiter les ordinateurs qui peuvent communiquer entre eux. Vous pouvez également restreindre la communication à des protocoles IP et des ports TCP/UDP spécifiques.

Remarque : IPSec n'est pas conçu pour se substituer à la sécurité au niveau de l'application. À l'heure actuelle, il est utilisé comme système de protection renforcée ou pour sécuriser des applications non sécurisées sans les modifier, et pour sécuriser les protocoles non-TLS contre les attaques au niveau des câbles du réseau.

Utilisation du protocole IPSec

Lorsque vous utilisez le protocole IPSec, veillez à prendre en compte les considérations suivantes :

  • IPSec peut être utilisé à la fois pour l'authentification et pour le cryptage.

  • Il n'existe aucune API IPSec qui permette aux développeurs de gérer les paramètres par programmation. IPSec est intégralement géré et configuré par l'intermédiaire du composant logiciel enfichable IPSec, dans la Stratégie de sécurité locale de la console MMC (Microsoft Management Console).

  • Dans le système d'exploitation Microsoft Windows® 2000, IPSec ne peut pas sécuriser tous les types de trafic IP. Plus précisément, il ne peut pas être utilisé pour sécuriser le trafic de diffusion, de multidiffusion, Internet Key Exchange ou Kerberos (qui est déjà un protocole sécurisé).

    Pour plus d'informations, consultez l'article Q253169, « Traffic That Can--and Cannot--Be Secured by IPSec » (en anglais) de la Base de connaissances Microsoft.

  • L'utilisation des filtres IPSec permet de savoir quand IPSec est appliqué. Pour tester les stratégies IPSec, utilisez le moniteur IPSec. Le moniteur IPSec (Ipsecmon.exe) fournit des informations sur la stratégie IPSec active et indique si un canal sécurisé est établi entre les ordinateurs.

    Pour plus d'informations, consultez les articles suivants de la Base de connaissances Microsoft (articles en anglais) :

  • Pour établir une relation d'approbation entre deux serveurs, vous pouvez utiliser IPSec avec une authentification mutuelle. Des certificats sont utilisés pour authentifier les deux ordinateurs.

    Pour plus d'informations, consultez les articles suivants de la Base de connaissances Microsoft (articles en anglais) :

  • Si vous devez utiliser IPSec pour sécuriser les communications entre deux ordinateurs séparés par un pare-feu, vérifiez que ce dernier n'utilise pas la traduction d'adresses réseau (NAT, Network Address Translation). IPSec ne fonctionne pas avec les périphériques NAT.

    Pour obtenir des informations supplémentaires et la procédure de configuration, consultez l'article Q233256, « HOW TO Enable IPSec Traffic through a Firewall » (en anglais) de la Base de connaissances Microsoft et la section « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide.

Haut de page

Cryptage RPC

RPC est le mécanisme de transport sur lequel repose DCOM. RPC fournit différents niveaux d'authentification configurables, qui vont de l'absence d'authentification (aucune protection des données) au cryptage total de l'état des paramètres.

Le niveau le plus sécurisé (confidentialité des paquets RPC) crypte l'état des paramètres pour chaque appel de procédure distante (et par conséquent pour chaque appel de méthode DCOM). Le niveau de cryptage RPC, 40 bits ou 128 bits, dépend de la version du système d'exploitation Windows exécutée sur les ordinateurs client et serveur.

Utilisation du cryptage RPC

Vous souhaiterez probablement utiliser le cryptage RPC si votre application Web doit communiquer avec des composants desservis (dans des applications serveur Microsoft Enterprise Services) situés sur des ordinateurs distants.

Dans ce cas, pour utiliser l'authentification (et le cryptage) Confidentialité des paquets RPC, vous devez configurer le client et le serveur. Un processus de négociation optimale intervient entre le client et le serveur, ce qui garantit l'utilisation des paramètres les plus élevés des deux (client et serveur).

Les paramètres du serveur peuvent être définis au niveau de l'application (Microsoft Enterprise Services), soit à l'aide d'attributs .NET dans votre assembly de composants desservis, soit à l'aide de l'outil d'administration Services de composants lors du déploiement.

Si le client est un service Web ou une application Web ASP.NET, le niveau d'authentification utilisé par le client est configuré à l'aide de l'attribut comAuthenticationLevel sur l'élément <processModel> du fichier Machine.config. Cet attribut fournit le niveau d'authentification par défaut de toutes les applications ASP.NET qui s'exécutent sur le serveur Web.

Informations supplémentaires

Pour plus d'informations sur la négociation du niveau d'authentification RPC et la configuration des composants desservis, consultez le Module 9, « Sécurité des services Microsoft Enterprise Services ».

Haut de page

Sécurité point à point

Les scénarios de communication point à point peuvent être classés dans les rubriques suivantes :

  • Navigateur/serveur Web

  • Serveur Web/serveur d'applications distant

  • Serveur d'applications/serveur de base de données

Pour sécuriser les données sensibles envoyées entre un navigateur et un serveur Web, utilisez SSL. Vous devez utiliser SSL dans les situations suivantes :

  • Vous utilisez l'authentification par formulaires et vous devez protéger les informations d'identification en texte brut envoyées à un serveur Web à partir d'un formulaire de connexion. Dans ce scénario, vous devez utiliser SSL pour sécuriser l'accès à toutes les pages (pas uniquement à la page de connexion) pour garantir que le cookie d'authentification, généré sur le processus d'authentification initial, reste sécurisé durant toute la durée de la session du navigateur du client avec l'application.

  • Vous utilisez l'authentification de base et vous devez sécuriser les informations d'identification en texte brut (codées en mode Base64). Vous devez utiliser SSL pour sécuriser l'accès à toutes les pages (pas uniquement la connexion initiale), car l'authentification de base envoie les informations d'identification en texte brut au serveur Web avec toutes les demandes soumises à l'application (pas uniquement la demande initiale).

    Remarque : le mode Base64 permet de coder les données binaires en tant que texte ASCII imprimable. Contrairement au cryptage, il n'assure pas l'intégrité ou la confidentialité des messages.

  • Votre application transmet des données sensibles entre le navigateur et le serveur Web (et vice versa), des numéros de carte de crédit ou des informations de compte bancaire, par exemple.

Serveur Web/serveur d'applications distant

Le canal de transport entre un serveur Web et un serveur d'applications distant doit être sécurisé à l'aide du cryptage IPSec, SSL ou RPC. Le choix dépend des protocoles de transport, des facteurs d'environnement (version des systèmes d'exploitation, pare-feu, etc.).

  • Services Microsoft Enterprise Services. Si votre serveur distant héberge un ou plusieurs composants desservis (dans une application serveur Microsoft Enterprise Services) et que vous communiquez directement avec eux (vous utilisez par conséquent DCOM), utilisez le cryptage de confidentialité des paquets RPC.

    Pour plus d'informations sur la configuration du cryptage RPC entre une application Web et un composant desservi distant, consultez le Module 9, « Sécurité des services Microsoft Enterprise Services ».

  • Services Web. Si votre serveur distant héberge un service Web, vous avez le choix entre IPSec et SSL. Vous devez généralement faire appel au protocole SSL, car le service Web utilise déjà le transport HTTP. SSL permet aussi de crypter uniquement les données en provenance ou à destination du service Web (et non la totalité trafic entre les deux ordinateurs). IPSec entraîne le cryptage de la totalité le trafic entre les deux ordinateurs.

    Remarque : la sécurité au niveau des messages (notamment le cryptage des données) est gérée par l'initiative GXA (Global XML Web Services Architecture), et plus particulièrement par la spécification WS-Security. Microsoft fournit le Kit de développement des services Web, qui permet d'élaborer des solutions de sécurité au niveau des messages. Vous pouvez vous procurer ce kit à l'adresse http://msdn.microsoft.com/webservices/building/wsdk/.

  • Composants .NET (avec .NET Remoting). Si votre serveur distant héberge un ou plusieurs composants .NET et que vous établissez la connexion par l'intermédiaire du canal TCP, vous pouvez utiliser IPSec pour fournir une communication sécurisée. Si vous hébergez les composants .NET dans ASP.NET, vous pouvez utiliser SSL (configuré à l'aide de IIS).

Serveur d'applications/serveur de base de données

Vous pouvez utiliser IPSec pour sécuriser les données transmises entre un serveur d'applications et un serveur de base de données. Si votre serveur de base de données exécute SQL Server 2000 (et que les bibliothèques réseau SQL Server 2000 sont installées sur le serveur d'applications), vous pouvez utiliser SSL. Cette option nécessite l'installation d'un certificat d'authentification serveur dans le magasin de l'ordinateur du serveur de base de données.

Vous devrez peut-être sécuriser la communication au serveur de base de données dans les situations suivantes :

  • Vous vous connectez au serveur de base de données et vous n'utilisez pas l'authentification Windows. Vous pouvez par exemple utiliser l'authentification SQL auprès de SQL Server ou vous connecter à une base de données non-SQL Server. Dans ces cas de figure, les informations d'identification sont transmises en texte brut, ce qui peut constituer un souci majeur en matière de sécurité.

    Remarque : l'un des principaux avantages de l'authentification Windows auprès de SQL Server est que les informations d'identification ne sont jamais transmises sur le réseau. Pour plus d'informations sur l'authentification Windows et SQL, consultez le Module 12, « Sécurité de l'accès aux données ».

  • Votre application peut soumettre et extraire des données sensibles à partir de la base de données ou à destination de celle-ci (par exemple, des données concernant les salaires).

Utilisation de SSL pour SQL Server

Prenez en compte les éléments suivants si vous utilisez SSL pour sécuriser le canal vers une base de données SQL Server :

  • Pour que SSL fonctionne, vous devez installer un certificat d'authentification serveur dans le magasin de l'ordinateur du serveur de base de données. L'ordinateur client doit également disposer d'un certificat racine émanant de l'autorité de certification qui a émis le certificat serveur (ou d'un organisme de confiance).

  • Les bibliothèques de connectivité SQL Server 2000 doivent être installées sur les clients. Les versions antérieures ou les bibliothèques génériques ne sont pas prises en charge.

  • SSL fonctionne uniquement pour TCP/IP (protocole de communication recommandé pour SQL Server) et les canaux nommés.

  • Vous pouvez configurer le serveur afin de forcer l'utilisation du cryptage pour toutes les connexions (de tous les clients).

  • Sur le client, vous pouvez :

    • forcer l'utilisation du cryptage pour toutes les connexions sortantes ;

    • autoriser les applications clientes à opter, ou non, pour l'utilisation du cryptage lors de chaque connexion, en utilisant la chaîne de connexion.

  • Contrairement à IPSec, des modifications de configuration ne sont pas nécessaires si les adresses IP du serveur ou du client changent.

Informations supplémentaires

Pour plus d'informations concernant l'utilisation de SSL pour SQL Server, consultez les ressources suivantes :

Haut de page

Choix entre IPSec et SSL

Prenez en compte les éléments suivants lorsque vous effectuez un choix entre IPSec et SSL :

  • IPSec permet de sécuriser l'ensemble du trafic IP entre les ordinateurs, tandis que SSL est spécifique à une application donnée.

  • IPSec est un paramètre au niveau de l'ordinateur et ne gère pas le cryptage de connexions réseau spécifiques. Toutefois, les sites peuvent être partitionnés pour utiliser SSL sur certaines zones uniquement. Par ailleurs, lorsque vous utilisez SSL pour établir une connexion à SQL Server, vous pouvez choisir d'utiliser ou de ne pas utiliser SSL pour chaque connexion (à partir de l'application cliente).

  • IPSec est transparent pour les applications. Il peut ainsi être utilisé avec des protocoles sécurisés qui s'exécutent au-dessus du protocole IP, tels que HTTP, FTP et SMTP. Cependant, SSL/TLS est étroitement lié à l'application.

  • IPSec peut être utilisé pour l'authentification de l'ordinateur, en plus du cryptage. Ceci est particulièrement important pour les scénarios de sous-systèmes approuvés, dans lesquels la base de données autorise une identité fixe à partir d'une application spécifique (exécutée sur un ordinateur spécifique). IPSec peut être utilisé pour garantir que seul le serveur d'applications spécifique peut se connecter au serveur de base de données, afin d'empêcher les attaques en provenance d'autres ordinateurs.

  • IPSec nécessite Windows 2000 ou une version ultérieure sur les deux ordinateurs.

  • Contrairement à IPSec, SSL peut fonctionner au travers d'un pare-feu de traduction d'adresses réseau.

Haut de page

Utilisation de plusieurs sites et équilibrage de charge

Si vous utilisez SSL avec plusieurs sites Web virtuels, vous devez utiliser des adresses IP uniques ou des numéros de port uniques. Vous ne pouvez pas utiliser plusieurs sites dotés d'adresses IP et de numéros de ports identiques. Si l'adresse IP est associée à un paramètre d'affinité du serveur dans un équilibrage de charge, cette solution fonctionnera correctement.

Informations supplémentaires

Pour plus d'informations, consultez l'article Q187504, « HTTP 1.1 Host Headers Are Not Supported When You Use SSL » (en anglais) de la Base de connaissances Microsoft.

Haut de page

Résumé

Ce module vous a présenté pourquoi l'association du cryptage SSL, IPSec et RPC peut se révéler utile pour offrir à une application distribuée une solution de communication sécurisée, de bout en bout. En résumé, les points que vous devez retenir sont les suivants :

  • La sécurité des canaux est une considération importante pour les données transmises sur Internet et sur l'intranet d'une entreprise.

  • Prenez en compte les questions de sécurité du navigateur Web au serveur Web, du serveur Web au serveur d'applications et du serveur d'applications aux liens du serveur de base de données.

  • Une communication sécurisée garantit la confidentialité et l'intégrité. Elle ne vous protège pas contre la non-répudiation. Vous devez pour cela utiliser des certificats clients.

  • Les options de sécurité des canaux incluent le cryptage SSL, IPSec et RPC. Cette dernière option s'applique lorsque l'application utilise DCOM pour communiquer avec des composants desservis distants.

  • Si vous utilisez SSL pour communiquer avec SQL Server, l'application peut opter, pour chaque connexion, pour le cryptage de cette dernière.

  • IPSec crypte l'ensemble du trafic IP transitant entre les deux ordinateurs.

  • Le choix du système de sécurité dépend du protocole de transport, des versions de système d'exploitation et de l'environnement du réseau (notamment les pare-feu).

  • Il est toujours nécessaire d'aboutir à un compromis entre la communication sécurisée et les performances. Choisissez le niveau de sécurité qui convient aux impératifs de votre application.

Haut de page