Dans cet article nous allons décrire les différentes tâches à mettre en place pour sécuriser les connexions utilisées par une application .Net. Nous sécuriserons à la fois les connexions externes que les clients ouvrent pour se connecter à notre application, mais aussi les connexions internes utilisées pour communiquer avec les différents composants de l’application.
Par défaut, Visual Studio configure ces connexions sans aucune forme de sécurité. Néanmoins, dans un environnement de production, il est souhaitable de sécuriser ces connexions pour éviter que les données puissent être lues ou modifiées par des personnes non autorisées.
Nous verrons comment sécuriser l’application en utilisant un certificat SSL (Secure Socket Layer). Pour ceci, nous nous baserons sur un exemple d’application avec un architecture N-tier de 4 couches comme décrit ci-dessous :
Dans cette application, nous avons ajouté une couche d’accès aux données, mise en place avec un service Windows qui héberge un service WCF. La couche web accède aux données en utilisant ce service. Ainsi, nous séparons la couche web de la base de données, ce qui augmente le niveau de sécurité.
Comme d’habitude, les clients externes se connecteront à l’application par HTTP. Dans l’exemple, nous avons choisi un modèle d’application qui contient un web site et un web service. Ceci nous permettra de voir comme sécuriser les deux cas. En revanche, pour la connexion interne entre la couche web et le service d’accès à données, les Endpoints exposés par le service WCF sont du type netTCPBinding. Par défaut, VisualStudio configure ces Endpoints comme netTCPBinding dans la mesure où c’est beaucoup plus efficient que le protocole HTTP.
Notre but sera de sécuriser les liens marqués en rouge dans le schéma de l’application : la connexion HTTP avec les clients externes, et la connexion TCP entre la couche web et la couche d’accès aux données. La connexion avec la base de données ne sera pas abordée dans cet article.
Obtenir un certificat SSL
Dans un environnement de production, il faut utiliser un certificat émis par une autorité de certification. Pour un environnement de développement, nous pouvons générer par nous même un certificat auto-signé avec l’aide de IIS.
Dans le cas d’un certificat émis par une autorité de certification, les navigateurs reconnaissent, en principe, l’autorité de Certification (Verisign, Digicert, etc). Les navigateurs vérifient que la signature du certificat du site web est la même que celle gardée par le client dans sa base d’autorités reconnues.
Néanmoins, dans le cas d’un certificat auto-signé, c’est notre machine qui signe le certificat, et aucun client nous reconnaitra comme une autorité de certification, sauf si nous acceptons explicitement faire confiance au certificat.
Pour générer un certificat auto-signé, il faut suivre les étapes suivantes :
1. Dans IIS Manager, il faut sélectionner l’option Certificats du serveur, puis l’option Créer un certificat auto-signé
2. Sur le dialogue, il faut renseigner le nom du certificat :
Le certificat généré sera valable pour un domaine avec le nom de notre machine (dans l’exemple MyDomain.private). Les clients qui acceptent ce certificat, vérifieront que le domaine auquel ils se connectent est le même que celui du certificat. Sinon, la connexion ne sera pas établie.
Par défaut, le certificat auto-signé est installé dans la machine qui l’a généré, et donc, si les clients de notre application sont exécutés dans la même machine, le certificat sera reconnu automatiquement. Mais si le client est exécuté dans une machine externe, le client devra être configuré pour reconnaître notre certificat explicitement.
Pour identifier le certificat, nous utiliserons le champ Thumbprint (Empreinte numérique). Pour lire ce champ, dans IIS, nous ferons double click sur le certificat installé, et nous sélectionnerons l’onglet Détails :
Une fois le certificat installé, nous allons voir comment configurer les connexions pour l’utiliser dans les points suivants.
Sécurisation du web site
Le but est de passer les connexions à notre site web (MyWebSite) en HTTPS, en utilisant le certificat installé dans le serveur. Pour ceci, dans IIS Manager, il faut sélectionner le site web, et après, sur le panneau droit, l’option Liaisons :
Dans le dialogue, il faut ajouter une nouvelle liaison en HTTPS et supprimer l’ancienne liaison en HTTP si nous voulons que le site ne soit plus accessible en HTTP :
Les paramètres de la nouvelle liaison ajoutée seront :
- Type : https
- Nom de l’hôte : Il doit contenir le nom de notre machine. Il est important qu’il soit le même que le domaine pour lequel le certificat a été généré.
- Certificat SSL : Il faut sélectionner notre certificat dans la liste déroulante.
Désormais, le site web ne sera accessible qu’en HTTPS. Les navigateurs qui se connectent au site, devront reconnaître l’autorité de certification qui a émis le certificat (par défaut, ils reconnaissent la plupart des autorités les plus connues). Si nous avons utilisé un certificat auto-signé, le client devra le reconnaître explicitement.
Sécurisation du web service
Si notre web service (MyWebService) est hébergé dans un IIS, nous devrons, dans un 1er temps, configurer en HTTPS la liaison au service. Pour ceci, il faudra suivre exactement les mêmes étapes que celles suivies dans le cas du web site (Sécurisation du web site).
En plus, dans le fichier de configuration du service, nous devrons apporter les modifications suivantes :
- Dans la section system.serviceModel : Il faut déclarer l’endpoint exposé par le service, et référencer la configuration du binding qui contient les paramètres de sécurité :
- Dans la section basicHttpBinding : Il faut renseigner les paramètres de configuration du binding :
– Security mode = Transport : Avec ceci, le service fonctionnera en HTTPS et avec un certificat SSL.
– ClientCredentialType = None : Avec ceci, le service acceptera des clients anonymes, qui n’ont pas besoin de s’authentifier.
Sécurisation du service Data Access
Dans notre modèle d’application, le service d’accès aux données est un service WCF hébergé dans un service Windows. Dans le fichier de configuration du service Windows, nous trouverons les sections qui configurent le service WCF. Ci-dessous, nous pouvons voir, encadrées en vert, les sections qui nous intéressent pour sécuriser l’Endpoint :
Les points importants à prendre en compte sont :
- Adresse de l’Endpoint (paramètres address et baseAddress ) : Il est important que le domaine de l’adresse indiquée soit le domaine pour lequel le certificat a été livré.
- Configuration du binding netTcpBinding : Le binding va être sécurisé grâce à la section ajoutée . Ceci sécurisera l’envoi de messages point-to-point.
- La section fait référence au certificat installé sur le serveur et identifié par son thumbprint.
Avec ceci, nous aurons sécurisé l’Endpoint exposé par notre service. Mais il faudra configurer les clients de ce service (dans notre cas MyWebSite et MyWebService) pour se connecter à cet Endpoint. Pour ceci, il faut apporter les modifications suivantes dans leurs fichiers de configuration :
- Adresse de l’Endpoint : Il est important que le domaine soit le domaine pour lequel le certificat a été livré :
- Il faut ajouter la section security dans le binding dataAccessEndPoint:
Également, il est important que les serveurs qui hébergent ces composants, reconnaissent l’autorité de certification qui a livré le certificat.
Dans cet article nous avons vu les différentes étapes pour sécuriser les connexions de notre application. Toutes les modifications sont apportées uniquement sur les fichiers de configuration et sur la configuration de IIS, sans nécessité de faire des changements au niveau du code source de notre application. Cette tâche qui devra être faite par les administrateurs.
