Étape de planification 4 : Planifier la sécurité des applications
par Keith Newman et Robert McMurray
Durant cette phase de conception de votre site web, tenez compte des besoins de sécurité de votre application ASP.NET. Les sections suivantes décrivent les paramètres de sécurité disponibles dans IIS 8 :
4.1. Isoler les applications web
L'une des méthodes les plus efficaces pour améliorer la sécurité de votre application web consiste à l'isoler des autres applications sur votre serveur web. Un pool d'applications a son propre processus de travail, qui traite les demandes et exécute le code de l'application. Le processus de travail a un identificateur de sécurité (SID) et chaque pool d'applications a une identité de pool d'applications unique. Par défaut, quand vous créez une application web, un nouveau pool d'applications est également créé avec le même nom que l'application. Si vous conservez les applications web dans des pools d'applications distincts, vous pouvez les isoler les unes des autres.
L'isolation des applications web implique les opérations suivants :
- Isolation de site : séparez différentes applications dans différents sites avec différents pools d'applications.
- Privilèges minimums : exécutez votre processus de travail en tant qu'identité à faible privilège (identité du pool d'applications virtuelle) unique par site.
- Isolation temporaire : configurez un dossier temporaire ASP.NET distinct par site et n'accordez l'accès qu'à l'identité de processus appropriée.
- Isolation de contenu : veillez à définir une liste de contrôle d'accès sur chaque racine du site pour autoriser uniquement l'accès à l'identité de processus appropriée.
Conseil
il vaut mieux héberger votre site web et votre contenu d'application web sur un lecteur autre que votre lecteur système (C:).
4.2. Niveaux de confiance .NET
Le niveau de confiance d'une application détermine les autorisations accordées par la stratégie de sécurité d'accès du code (CAS) ASP.NET. La sécurité d'accès du code définit deux catégories de confiance : confiance totale et confiance partielle. Une application qui a des autorisations de confiance totale peut accéder à tous les types de ressources sur un serveur et effectuer des opérations à privilèges. Les applications de confiance totale sont uniquement affectées par les paramètres de sécurité du système d'exploitation.
Les applications web de confiance partielle sont celles qui ne disposent pas d'une confiance totale et qui ont un jeu limité d'autorisations d'accès du code. Ainsi, les applications de confiance partielle sont limitées dans leur capacité à accéder aux ressources sécurisées et à effectuer d'autres opérations à privilèges. Certaines autorisations sont refusées aux applications de confiance partielle. Ainsi, les ressources qui ont besoin de ces autorisations ne sont pas accessibles directement. D'autres autorisations sont attribuées de façon limitée. Ainsi, les ressources nécessitant ces autorisations peuvent être accessibles, mais d'une façon limitée. Par exemple, l'autorisation d'E/S de fichier restreinte permet à l'application d'accéder au système de fichiers, mais uniquement dans les répertoires sous la racine du répertoire virtuel de l'application.
En configurant une application web ou un service web pour la confiance partielle, vous pouvez limiter la capacité de l'application à accéder aux ressources système cruciales ou à celles qui appartiennent à d'autres applications web. En accordant uniquement les autorisations dont l'application a besoin, vous pouvez générer des applications web à moindres privilèges et limiter les dommages potentiels si l'application web est compromise par une attaque par injection de code.
La liste suivante montre les restrictions associées à chaque niveau de confiance :
- Les applications de confiance totale ont un accès illimité à tous les types de ressources et peuvent effectuer des opérations à privilèges.
- Les applications de confiance élevée, moyenne, faible ou minimale ne peuvent pas appeler de code managé ou de composants de service, écrire dans le journal des événements, accéder aux files d'attente Message Queuing ou accéder à des sources de données OLE DB.
- Les applications de confiance élevée ont un accès illimité au système de fichiers.
- Les applications de confiance moyenne ont un accès limité au système de fichiers et peuvent accéder uniquement aux fichiers de leur propre hiérarchie de répertoire d'applications.
- Les applications de confiance faible ou minimale ne peuvent pas accéder à des bases de données SQL Server.
- Les applications de confiance minimale ne peuvent accéder à aucune ressource.
4.3. Authentification .NET
L'authentification vous permet de vérifier l'identité des clients qui demandent l'accès à vos sites et applications. Quand l'authentification est activée, IIS 8 utilise les informations d'identification de compte fournies par l'utilisateur pour déterminer les autorisations accordées à l'utilisateur et les ressources auxquelles l'utilisateur peut accéder.
Cette section décrit les modes d'authentification qui sont spécifiques aux applications ASP.NET.
Authentification par formulaire ASP.NET
L’authentification par formulaire utilise la redirection côté client pour transférer les utilisateurs non authentifiés vers un formulaire HTML dans lequel ils peuvent entrer leurs informations d’identification, qui sont habituellement un nom d’utilisateur et un mot de passe. Une fois les informations d’identification validées, les utilisateurs sont redirigés vers la page initialement demandée. L'authentification par formulaire utilise souvent des cookies pour passer les informations d'identification utilisateur entre le serveur et le navigateur client.
Les sections suivantes décrivent ce que vous devez savoir pour planifier l'ajout de l'authentification par formulaire à votre site :
Notions de base de l'authentification par formulaire
L'authentification basée sur les formulaires ASP.NET fonctionne bien pour les sites ou applications sur des serveurs web publics qui reçoivent de nombreuses requêtes. Ce mode d'authentification vous permet de gérer l'inscription et l'authentification du client au niveau de l'application, plutôt que d'utiliser les mécanismes d'authentification du système d'exploitation.
Important
Étant donné que l'authentification par formulaire envoie le nom d'utilisateur et un mot de passe au serveur web en texte brut, vous devez utiliser le chiffrement SSL (Secure Sockets Layer) pour la page d'ouverture de session et pour toutes les autres pages de votre application à l'exception de la page d'accueil. Pour plus d’informations sur SSL, voir 4.5. Communication TLS/SSL
L'authentification par formulaire permet aux utilisateurs d'ouvrir une session à l'aide des identités d'une base de données d'appartenance ASP.NET. Cette méthode d'authentification utilise la redirection vers une page d'ouverture de session HTML pour confirmer l'identité de l'utilisateur. Vous pouvez configurer l'authentification par formulaire au niveau du site ou de l'application.
L'authentification par formulaire est pratique pour les raisons suivantes :
- Elle permet d'utiliser un magasin de données personnalisé, par exemple une base de données SQL Server ou Active Directory, pour l'authentification.
- Elle s'intègre facilement à une interface utilisateur web.
- Les clients peuvent utiliser n'importe quel navigateur.
Si vous souhaitez utiliser des rôles d'appartenance pour l'autorisation, utilisez l'authentification par formulaire ou une méthode d'authentification personnalisée similaire.
Important
Si vous sélectionnez l'authentification par formulaire, vous ne pouvez pas utiliser l'une des méthodes d'authentification basée sur les stimulations en même temps.
Par défaut, l'URL de connexion pour l'authentification par formulaire est Login.aspx. Vous pouvez créer une page de connexion unique pour les clients qui visitent un site ou une application. Par exemple, vous souhaiterez peut-être recueillir des informations spécifiques de la part des visiteurs ou proposer une appartenance à certaines pages du site ou à certaines applications.
La valeur de délai d'attente par défaut pour l'authentification par formulaire est de 30 minutes. Vous pouvez réduire la valeur de délai d'attente pour réduire la durée de vie de session et réduire les risques d'attaques par relecture de cookie.
Cookies d'authentification
Les cookies d'authentification sont utilisés en tant que jeton pour vérifier qu'un client a accès à toutes les pages d'une application. En revanche, les cookies de personnalisation contiennent des paramètres spécifiques à l'utilisateur qui déterminent l'expérience utilisateur sur un site ou une application spécifique.
Important : les cookies d'authentification étant transmis entre le client et le serveur lors de chaque demande, vous devez toujours les sécuriser à l'aide du protocole SSL (Secure Sockets Layer). Pour plus d’informations sur SSL, voir 4.5. Communication TLS/SSL
Les cookies sont plus efficaces pour assurer le suivi des visiteurs d'un site que les chaînes de requête, car ils ne nécessitent pas de redirection. Toutefois, ils dépendent du navigateur et certains navigateurs ne prennent pas en charge leur utilisation. En outre, l'utilisation de l'authentification basée sur les cookies n'est pas toujours efficace, car certains utilisateurs désactivent la prise en charge des cookies dans leur navigateur.
Par défaut, le nom du cookie pour les applications ASP.NET est .ASPXAUTH. Toutefois, vous pouvez utiliser un nom de cookie et un chemin d'accès uniques pour chaque application. Cela peut empêcher que des utilisateurs authentifiés pour une application soient authentifiés pour d'autres applications sur un serveur web.
Vous pouvez choisir l'un des modes de cookies suivants pour votre site ou application :
| Mode | Description |
|---|---|
| Utiliser les cookies | Les cookies sont toujours utilisés quel que soit l'appareil. |
| Ne pas utiliser les cookies | Les cookies ne sont pas utilisés. |
| Détection automatique | Les cookies sont utilisés si le profil de périphérique prend en charge les cookies. Sinon, aucun cookie n’est utilisé. Pour les navigateurs de bureau qui prennent en charge les cookies, ASP.NET effectue une vérification afin de déterminer si les cookies sont activés. Il s’agit du paramètre par défaut. |
| Utiliser le profil de périphérique | Les cookies sont utilisés si le profil de périphérique prend en charge les cookies. Sinon, aucun cookie n’est utilisé. ASP.NET n’effectue pas de vérification pour déterminer si les cookies sont activés sur les périphériques qui prennent en charge les cookies. Ce paramètre est la valeur par défaut pour IIS 8. |
Le mode de protection de cookie définit la fonction qu'un cookie d'authentification par formulaire effectue pour une application spécifique. Le tableau suivant montre les modes de protection de cookie que vous pouvez définir :
| Mode | Description |
|---|---|
| Chiffrement et validation | Indique que l'application utilise la validation des données et le chiffrement pour protéger le cookie. Cette option utilise l'algorithme de validation des données configuré (basé sur la clé d'ordinateur). Si triple-DES (3DES) est disponible et si la clé est suffisamment longue (48 octets ou plus), 3DES est utilisé pour le chiffrement. Ce paramètre est la valeur par défaut (et recommandée). |
| Aucun | Indique que le chiffrement et la validation sont désactivés pour les sites qui utilisent des cookies uniquement pour la personnalisation et qui ont des exigences de sécurité plus faibles. Nous déconseillons d'utiliser les cookies de cette manière ; toutefois, si vous voulez activer la personnalisation à l'aide de .NET Framework, c'est cette approche qui consomme le moins de ressources. |
| Chiffrement | Indique que le cookie est chiffré à l'aide de Triple-DES ou DES, mais que la validation des données n'est pas effectuée sur le cookie. Les cookies utilisés de cette manière peuvent être soumis à des attaques de texte brut. |
| Validation | Indique qu'un schéma de validation vérifie que le contenu d'un cookie chiffré n'a pas été modifié lors du transit. |
Important
Pour des raisons de sécurité, vous pouvez séparer le chiffrement et la validation des cookies. Le vol de cookies de chiffrement est un plus grand risque pour la sécurité que le vol de cookies de validation.
Si une application contient des objets souvent demandés par les clients, améliorez les performances de l'application par la mise en cache de ces objets. Si l'utilisateur accède à l'objet mis en cache avant l'expiration du cookie d'authentification, IIS 8 autorise l'objet mis en cache à rester dans le cache et le minuteur est réinitialisé. Toutefois, si l'utilisateur n'accède pas à l'objet mis en cache durant ce laps de temps, IIS 8 supprime l'objet du cache.
Vous pouvez activer ce paramètre dans les situations suivantes :
- Vous avez une quantité de mémoire disponible limitée pour la mise en cache.
- Vous avez de nombreux objets dans le cache, car ce paramètre permet uniquement de conserver dans le cache les objets les plus fréquemment demandés.
Remarque
Vous spécifiez le nombre de minutes avant l'expiration du cookie d'authentification avec Délai d'attente du cookie d'authentification (en minutes).
Authentification par emprunt d'identité ASP.NET
Utilisez l'emprunt d'identité ASP.NET quand vous souhaitez exécuter votre application ASP.NET sous un contexte de sécurité différent du contexte de sécurité par défaut pour les applications ASP.NET.
Si vous activez l’emprunt d’identité pour une application ASP.NET, cette application peut s’exécuter dans l’un des deux contextes suivants : en tant qu’utilisateur authentifié par IIS 8 ou en tant que compte arbitraire que vous définissez. Par exemple, si vous utilisez l'authentification anonyme et que vous choisissez d'exécuter l'application ASP.NET en tant qu'utilisateur authentifié, l'application s'exécute sous un compte qui est configuré pour les utilisateurs anonymes (en général, IUSR). De même, si vous choisissez d’exécuter l’application sous un compte arbitraire, elle sera exécutée sous le contexte de sécurité défini pour ce compte.
Par défaut, l'emprunt d'identité ASP.NET est désactivé. Si vous activez l'emprunt d'identité, votre application ASP.NET s'exécute dans le contexte de sécurité de l'utilisateur authentifié par IIS 8.
4.4. Paramètres de clé d’ordinateur
Les clés d'ordinateurs aident à protéger les données des cookies d'authentification par formulaire et les données d'état d'affichage au niveau de la page. Elles vérifient également l'identification de l'état de session out-of-process. ASP.NET utilise les types de clés d'ordinateurs suivants :
- Une clé de validation calcule un code MAC (Message Authentication Code) pour confirmer l'intégrité des données. Cette clé est ajoutée au cookie d'authentification par formulaire ou à l'état d'affichage d'une page spécifique.
- Une clé de déchiffrement est utilisée pour chiffrer et déchiffrer les tickets d'authentification par formulaire et l'état d'affichage.
IIS 8 vous permet de configurer les paramètres de validation et de chiffrement et de générer des clés d'ordinateurs pour une utilisation avec des services d'application ASP.NET, tels que l'état d'affichage, l'authentification par formulaire, l'appartenance, les rôles et l'identification anonyme.
Avant de générer des clés d'ordinateurs pour votre application, vous devez prendre les décisions de conception suivantes :
- Déterminez la méthode de validation à utiliser : AES, MD5, SHA1 (valeur par défaut), TripleDES, HMACSHA256, HMACSHA384 ou HMACSHA512.
- Déterminez la méthode de chiffrement à utiliser : Auto (par défaut), AES, TripleDES ou DES.
- Décidez s'il faut générer automatiquement la clé de validation au moment de l'exécution.
- Décidez s'il faut générer une clé de validation unique pour chaque application.
- Décidez s'il faut générer automatiquement la clé de déchiffrement au moment de l'exécution.
- Décidez s'il faut générer une clé de déchiffrement unique pour chaque application.
4.5. Communication TLS/SSL
Le protocole TLS (Transport Layer Security) et son prédécesseur, le protocole SSL (Secure Sockets Layer), assurent la sécurité des communications de votre site web. Vous pouvez utiliser TLS/SSL pour authentifier les serveurs et clients, puis pour chiffrer les messages entre les parties authentifiées.
Dans le processus d’authentification, un client TLS/SSL envoie un message à un serveur TLS/SSL qui répond avec les informations dont il a besoin pour s’authentifier. Le client et le serveur effectuent un échange de clés de session supplémentaire, puis la boîte de dialogue d’authentification se ferme. Une fois l'authentification terminée, les communications SSL sécurisées peuvent commencer entre le serveur et le client à l'aide des clés de chiffrement symétriques établies pendant le processus d'authentification.
Pour configurer TSL/SSL pour votre site web, procédez comme suit :
- Obtenez un certificat de serveur à partir d'une autorité de certification. Voir Certificats de serveur.
- Ajoutez la liaison SSL au site. Voir Liaison SSL.
- Configurez IIS pour exiger le protocole SSL sur le site. Voir Exiger le protocole SSL pour votre site.
- Utilisez éventuellement des certificats clients pour votre site. Voir Certificats clients.
Certificats de serveur
Vous pouvez obtenir un certificat de serveur à partir d'une autorité de certification. L'obtention d'un certificat de serveur à partir d'une autorité de certification est l'une des étapes de la configuration du protocole Secure Sockets Layer (SSL) ou Transport Layer Security (TLS). Vous pouvez obtenir des certificats de serveur à partir d'une autorité de certification tierce. Une autorité de certification tierce peut vous demander de fournir une preuve d'identité avant de délivrer un certificat. Vous pouvez également émettre vos propres certificats de serveur à l'aide d'une autorité de certification en ligne, telle que Microsoft Certificate Services.
Les certificats numériques sont des fichiers électroniques qui fonctionnent comme un mot de passe en ligne pour vérifier l'identité d'un utilisateur ou d'un ordinateur. Ils servent à créer le canal chiffré SSL utilisé pour les communications clientes. Un certificat est une instruction numérique émise par une autorité de certification qui garantit l'identité du détenteur du certificat et permet aux parties de communiquer de manière sécurisée à l'aide du chiffrement.
Les certificats numériques effectuent les opérations suivantes :
- Ils authentifient le fait que leurs propriétaires (personnes, sites web et même ressources réseau telles que des routeurs) sont réellement ce qu'ils prétendent être.
- Ils protègent les données qui sont échangées en ligne contre le vol ou la falsification.
Les certificats numériques sont émis par une autorité de certification tierce approuvée ou par une infrastructure à clé publique (PKI) Microsoft Windows à l'aide des Services de certificats, ou ils peuvent être auto-signés. Chaque type de certificat présente des avantages et des inconvénients. Chaque type de certificat numérique est protégé contre la falsification.
Les certificats peuvent être émis à différentes fins, y compris l'authentification des utilisateurs web, l'authentification du serveur web, S/MIME (Secure/Multipurpose Internet Mail Extensions), la sécurité IPsec (Internet Protocol security), la sécurité TLS (Transport Layer Security) et la signature du code.
Un certificat contient une clé publique et joint cette clé publique à l'identité d'une personne, d'un ordinateur ou d'un service qui détient la clé privée correspondante. Les clés publiques et privées sont utilisées par le client et le serveur pour chiffrer les données avant leur transmission. Pour les utilisateurs, les ordinateurs et les services Windows, l'approbation envers une autorité de certification est établie quand il existe une copie du certificat racine dans le magasin de certificats racines de confiance et que le certificat contient un chemin d'accès de certification valide. Pour que le certificat soit valide, il ne doit pas avoir été révoqué et la période de validité ne doit pas avoir expiré.
Liaison SSL
Vous pouvez affecter plusieurs liaisons à un site quand vous avez du contenu de site qui sert à différentes fins ou pour lequel vous devez utiliser un protocole différent. Par exemple, un site de commerce peut avoir une application qui exige que les utilisateurs se connectent à un compte pour acheter des articles. La société héberge le site via HTTP, mais les utilisateurs doivent se connecter à leur compte sur une page HTTPS. Dans cet exemple, le site aurait deux liaisons : une pour la partie HTTP et une pour la partie HTTPS.
Par défaut, vous ne pouvez pas ajouter de liaisons pour des protocoles autres que HTTP et HTTPS à l'aide de IIS Manager. Si vous souhaitez ajouter une liaison pour un protocole différent, par exemple un protocole pris en charge par Windows Communication Foundation (WCF), utilisez l'un des autres outils d'administration. Toutefois, si vous installez le serveur FTP (File Transfer Protocol) d'IIS, vous pouvez ajouter des liaisons FTP à l'aide de IIS Manager. D'autres modules ou fonctionnalités tierces qui étendent l'interface utilisateur peuvent également être disponibles en téléchargement.
Exigez le protocole SSL pour votre site
Le chiffrement Secure Sockets Layer (SSL) protège les informations personnelles ou confidentielles envoyées entre un client et un serveur. Quand SSL est activé, les clients distants accèdent à votre site à l'aide d'URL qui commencent par https://.
Tout d'abord, configurez un certificat de serveur et créez une liaison HTTPS pour activer tous les paramètres SSL. Ensuite, exigez le chiffrement SSL dans un ou plusieurs des cas suivants :
- Quand du contenu personnel ou confidentiel sur votre serveur doit être protégé par un canal chiffré.
- Quand vous souhaitez que les utilisateurs puissent confirmer l'identité de votre serveur avant de transmettre des informations personnelles.
- Quand vous souhaitez utiliser des certificats clients pour authentifier les clients qui accèdent à votre serveur.
Certificats clients
Quand vous souhaitez que les clients vérifient leur identité avant d'accéder au contenu de votre serveur web, configurez des certificats clients. Par défaut, les certificats clients sont ignorés.
Pour pouvoir configurer des certificats clients sur votre site web, vous devez configurer un certificat de serveur et créer une liaison HTTPS pour activer tous les paramètres SSL.
Si vous voulez que tous les clients vérifient leur identité, spécifiez que les certificats clients sont obligatoires. Si certains clients peuvent accéder au contenu sans vérifier au préalable leur identité, spécifiez que les certificats clients sont acceptés.