Exporter (0) Imprimer
Développer tout

Module 7 : Sécurité Internet

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

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Avant de commencer Avant de commencer
Connexion de ASP.NET à SQL Server Connexion de ASP.NET à SQL Server
Connexion de ASP.NET à des composants Microsoft Enterprise Services distants et à SQL Server Connexion de ASP.NET à des composants Microsoft Enterprise Services distants et à SQL Server
 Résumé Résumé

Dans ce module

Les applications Internet sont utilisées par de nombreuses personnes, dans de nombreux buts, et leurs spécifications en termes de sécurité sont très diverses. Il peut s'agir d'applications portail qui ne nécessitent aucune authentification de l'utilisateur, d'applications Web qui offrent un contenu à des utilisateurs enregistrés ou encore d'applications de commerce électronique de grande envergure qui nécessitent une authentification, une autorisation et une validation des cartes de crédit ainsi qu'une communication sécurisée des données sensibles sur des réseaux publiques et internes.

Ce module présente les méthodes recommandées dans le cadre de la résolution des problèmes d'authentification, d'autorisation et de communication sécurisée pour les applications Web Internet, en mettant l'accent sur les exigences de deux des architectures d'applications distribuées les plus courantes.

Objectifs

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

  • sécuriser une application .NET Internet ;

  • comprendre les problèmes liés à la sécurité et les solutions recommandées associées à l'utilisation d'une application Web ASP.NET pour communiquer avec SQL Server 2000 dans les scénarios suivants :

    • communication directe ;

    • utilisation de Microsoft Enterprise Services comme intermédiaire.

  • sélectionner la meilleure méthode d'implémentation de l'authentification, de l'autorisation et des communications sécurisées dans une application Web distribuée sur Internet.

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

  • Microsoft Active Directory

  • .NET Framework version 1.0 (avec le service pack 2) et versions ultérieures

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

Avant de commencer

En qualité de développeur d'applications Internet, votre tâche consiste à vous assurer que votre application utilise des systèmes de protection appropriés et qu'elle est conçue pour être évolutive, sécurisée et très performante. Vous devez notamment :

  • Choisir un magasin d'informations d'identification des utilisateurs approprié, une base de données personnalisée ou un service d'annuaire Microsoft Active Directory®, par exemple.

  • Garantir le bon fonctionnement de votre application en présence de pare-feu.

  • Transmettre les informations d'identification sécurisées aux différents niveaux de votre application.

  • Procéder à l'autorisation.

  • Garantir l'intégrité et la confidentialité des données lorsqu'elles transitent sur des réseaux publics et internes.

  • Sécuriser l'état de votre application à l'aide d'une base de données.

  • Garantir l'intégrité des données de votre application.

  • Implémenter une solution qui peut s'adapter à un grand nombre d'utilisateurs potentiels.

Les deux scénarios d'applications Internet courants présentés dans ce module illustrent les techniques recommandées d'authentification, d'autorisation et de communication sécurisée :

  • Connexion de ASP.NET à SQL Server

  • Connexion de ASP.NET à des composants Microsoft Enterprise Services distants et à SQL Server

Remarque : plusieurs scénarios décrits dans ce module modifient le mot de passe du compte ASPNET par défaut afin de permettre, dans le cadre de l'authentification réseau, la création de comptes en double sur des ordinateurs distants. Cette opération nécessite de mettre à jour l'élément <processModel> du fichier Machine.config. Les informations d'identification <processModel> ne doivent pas être stockées en texte brut dans le fichier Machine.config. Faites appel à l'utilitaire aspnet_setreg.exe pour stocker des informations d'identification cryptées dans le Registre. Pour plus d'informations, consultez le Module 8, « Sécurité ASP.NET » et l'article Q329290, « COMMENT FAIRE : Utilisation de l'utilitaire ASP.NET pour crypter les informations d'authentification et les chaînes de connexion de l'état de session » dans la Base de connaissances Microsoft.

Connexion de ASP.NET à SQL Server

Dans ce scénario, qui comporte deux niveaux physiques, les utilisateurs enregistrés se connectent de manière sécurisée à l'application Web à l'aide d'un navigateur Web. L'application Web ASP.NET établit des connexions sécurisées à une base de données Microsoft® SQL Server? pour gérer principalement les tâches d'extraction de données. Il peut s'agir, par exemple, d'une application portail qui fournit des informations aux abonnés inscrits. Ce scénario est présenté dans la figure 7.1.

Scénario d'application Internet Web ASP.NET connectée à SQL Server

Figure 7.1
Scénario d'application Internet Web ASP.NET connectée à SQL Server

Caractéristiques

Les caractéristiques de ce scénario sont les suivantes :

  • Les utilisateurs font appel à différents types de navigateurs Web.

  • Les utilisateurs anonymes peuvent parcourir les pages de l'application dont l'accès n'est pas limité.

  • Les utilisateurs doivent s'inscrire ou se connecter (par l'intermédiaire d'un formulaire HTML) pour être autorisés à consulter les pages à accès limité.

  • Les informations d'identification des utilisateurs sont validées auprès d'une base de données SQL Server.

  • Toutes les entrées des utilisateurs (telles que les informations d'identification) utilisées dans les demandes transmises à la base de données sont validées pour limiter les possibilités d'injection de code SQL.

  • L'application Web frontale est située dans un réseau de périmètre (également appelé zone démilitarisée (DMZ) et sous-réseau filtré), et des pare-feu la séparent du réseau Internet et du réseau interne de l'entreprise (et de la base de données SQL Server).

  • L'application requiert une sécurité forte, des niveaux d'évolutivité élevés et un audit détaillé.

  • La base de données approuve l'application pour permettre l'authentification correcte des utilisateurs (l'application effectue des appels à la base de données pour le compte des utilisateurs).

  • L'application Web se connecte à la base de données en utilisant le compte du processus ASP.NET.

  • Un rôle de base de données défini par l'utilisateur est utilisé dans SQL Server pour l'autorisation de la base de données.

Sécurisation du scénario

Dans ce scénario, l'application Web présente une page de connexion permettant d'accepter les informations d'identification. Les utilisateurs validés sont autorisés à poursuivre leur visite. Les autres se voient refuser l'accès. La base de données effectue une authentification en fonction de l'identité du processus par défaut ASP.NET, qui correspond à un compte doté de privilèges minimum (la base de données approuve l'application ASP.NET).

Tableau 7.1 : Résumé de la sécurité

Catégorie

Détails

Authentification

  • IIS est configuré pour autoriser l'accès anonyme. L'application Web ASP.NET authentifie les utilisateurs avec l'authentification par formulaires pour obtenir les informations d'identification. La validation est effectuée auprès d'une base de données SQL Server.

  • Les mots de passe des utilisateurs ne sont pas stockés dans la base de données. Ce sont des hachages de mot de passe accompagnés de valeurs salt (nombres aléatoires) qui sont stockés. Les valeurs salt limitent les attaques de dictionnaire potentielles.

  • L'authentification Windows® est utilisée pour la connexion à la base de données à l'aide du compte Windows doté de privilèges minimum utilisé pour exécuter l'application Web ASP.NET.

Autorisation

  • Le compte du processus ASP.NET est autorisé à accéder aux ressources système sur le serveur Web. Les ressources sont protégées à l'aide de listes de contrôle d'accès Windows.

  • L'accès à la base de données est autorisé à l'aide de l'identité de l'application ASP.NET.

Communication sécurisée

  • Sécurisez les données sensibles entre les utilisateurs et l'application Web à l'aide de SSL.

  • Sécurisez les données sensibles entre le serveur Web et le serveur de base de données à l'aide de IPSec.

Résultat

La figure 7.2 présente la configuration de la sécurité recommandée pour ce scénario.

Configuration de la sécurité recommandée pour le scénario d'application Internet ASP.NET connectée à SQL Server

Figure 7.2
Configuration de la sécurité recommandée pour le scénario d'application Internet ASP.NET connectée à SQL Server

Étapes de la configuration de la sécurité

Avant de commencer, il est conseillé de consulter les points suivants :

  • Création de comptes ASP.NET personnalisés (voir « Procédure : Créer un compte personnalisé pour exécuter ASP.NET » dans ce guide).

  • Création d'un compte de base de données associé à des privilèges minimum (voir le Module 12, « Sécurité de l'accès aux données »).

  • Configuration de SSL sur un serveur Web (voir « Procédure : Configurer SSL sur un serveur Web » dans ce guide).

  • Configuration de IPSec (voir « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide).

Configuration du serveur Web
Configuration de IIS

Étape

Informations supplémentaires

Activez l'accès anonyme pour le répertoire de la racine virtuelle de l'application Web.

Pour travailler avec les paramètres d'authentification IIS, utilisez le composant logiciel enfichable IIS de la console MMC. Cliquez avec le bouton droit sur le répertoire virtuel de votre application, puis cliquez sur Propriétés.
Cliquez sur l'onglet Sécurité de répertoire , puis sur Modifier dans le groupe Connexions anonymes et contrôle d'authentification.

Configuration de ASP.NET

Étape

Informations supplémentaires

Redéfinissez le mot de passe du compte ASPNET (utilisé pour exécuter ASP.NET) à l'aide d'un mot de passe sécurisé connu.

Cette opération permet de créer un compte local en double (doté du même nom d'utilisateur et du même mot de passe) sur le serveur de base de données. Elle est indispensable pour autoriser le compte ASPNET à répondre aux demandes d'authentification réseau du serveur de base de données lorsque celui-ci se connecte à l'aide de l'authentification Windows.

Une autre méthode consiste à utiliser un compte de domaine doté de privilèges minimum (si l'authentification Windows est autorisée au travers du pare-feu).
Pour plus d'informations, consultez la section « Identité de processus pour ASP.NET » dans le Module 8, « Sécurité ASP.NET ».

Modifiez le fichier Machine.config qui se trouve dans le répertoire %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG

Attribuez le nom d'utilisateur et le mot de passe du compte personnalisé à l'élément <processModel>.

La valeur par défaut

<!-- userName="machine" password="AutoGenerate"
 -->

Devient

<!--
userName="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,password" -->

Notez que l'utilitaire aspnet_setreg.exe a été utilisé pour stocker un mot de passe crypté dans le Registre.

Configurez l'application Web pour qu'elle utilise l'authentification par formulaires (avec SSL).

Modifiez le fichier Web.config dans le répertoire de la racine virtuelle de l'application.
Définissez l'élément <authentication> comme suit :

<authentication mode="Forms" >  
	<forms name="MyAppFormsAuth"
          loginUrl="login.aspx"
          protection="All"  
          timeout="20"         
          path="/" &gt;  
      </forms>
</authentication>

Pour plus d'informations sur l'utilisation de l'authentification par formulaires avec une base de données SQL Server, consultez la section « Procédure : Utiliser l'authentification par formulaires avec SQL Server 2000 » dans ce guide.

Configuration de SQL Server

Étape

Informations supplémentaires

Créez sur l'ordinateur SQL Server un compte Windows qui correspond au compte du processus ASP.NET.

Le nom d'utilisateur et le mot de passe doivent correspondre au compte personnalisé de votre application ASP.NET ou il doit s'agit de ASPNET si vous utilisez le compte par défaut.

Configurez SQL Server pour l'authentification Windows.

 

Créez une connexion SQL Server pour le compte personnalisé de votre application ASP.NET.

Cette opération autorise l'accès à SQL Server.

Créez un utilisateur de base de données et mappez le nom d'utilisateur à l'utilisateur de base de données.

Cette opération autorise l'accès à la base de données indiquée.

Créez un rôle de base de données défini par l'utilisateur dans la base de données et placez l'utilisateur de base de données dans le rôle.

 

Définissez des autorisations de base de données pour le rôle de base de données.

Accordez des autorisations minimales.
Pour plus d'informations, consultez le Module 12, « Sécurité de l'accès aux données ».

Configuration de la communication sécurisée

Étape

Informations supplémentaires

Configurez le site Web pour SSL.

Voir « Procédure : Configurer SSL sur un serveur Web » dans ce guide.

Configurez IPSec entre le serveur d'applications et le serveur de base de données.

Voir « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide.

Analyse

  • L'authentification par formulaires est idéale dans ce scénario, car les utilisateurs ne disposent pas de comptes Windows. La page de formulaire de connexion est utilisée pour obtenir les informations d'identification des utilisateurs. La validation des informations d'identification doit être réalisée par le code de l'application. Tout magasin de données peut être utilisé. La solution la plus courante consiste à faire appel à une base de données SQL Server. Active Directory offre également un magasin d'informations.

  • Avec l'authentification par formulaires, vous devez protéger les informations initiales de connexion à l'aide de SSL. Le ticket d'authentification par formulaires (transmis sous forme de cookie aux demandes Web suivantes à partir du client authentifié) doit également être protégé. Vous pouvez utiliser SSL pour toutes les pages afin de protéger le ticket. Vous pouvez également crypter le ticket d'authentification par formulaires en configurant l'attribut protection de l'élément <forms> (valeur All ou Encrypt) et utiliser la méthode Encrypt de la classe FormsAuthentication pour crypter le ticket.
    L'attribut protection="All" indique que lorsque l'application appelle FormsAuthentication.Encrypt, le ticket doit être validé (vérification de l'intégrité) et crypté. Appelez cette méthode lorsque vous créez le ticket d'authentification, en principe dans le gestionnaire d'événements du bouton Connexion de l'application.

    string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
    

    Pour plus d'informations sur l'authentification par formulaires et le cryptage des tickets, consultez le Module 8, « Sécurité ASP.NET ».

  • ASP.NET étant exécuté en tant que compte ASPNET local doté de privilèges minimum, les dommages potentiels en cas d'atteinte à l'intégrité sont limités.

  • L'autorisation des URL sur le serveur Web permet aux utilisateurs non authentifiés de consulter les pages Web à accès non limité et force l'authentification pour les pages à accès limité.

  • L'emprunt d'identité n'étant pas activé, l'accès aux ressources locales ou distantes effectué par l'application Web est réalisé à l'aide du contexte de sécurité du compte ASPNET. Les listes de contrôle d'accès Windows sur les ressources sécurisées doivent être définies de manière appropriée.

  • Les informations d'identification des utilisateurs sont validées auprès d'une base de données SQL Server personnalisée. Des hachages de mot de passe accompagnés de valeurs salt (nombres aléatoires) sont stockés dans la base de données. Pour plus d'informations, consultez la section « Authentification des utilisateurs auprès d'une base de données » du Module 12, « Sécurité de l'accès aux données ».

  • L'authentification Windows auprès de SQL Server évite de stocker les informations d'identification dans des fichiers sur le serveur Web et de les transmettre sur le réseau.

  • Si votre application utilise actuellement l'authentification SQL, vous devez stocker la chaîne de connexion de la base de données de manière sécurisée car elle contient des noms d'utilisateurs et des mots de passe. Envisagez d'utiliser DPAPI. Pour plus d'informations, consultez la section « Stockage sécurisé des chaînes de connexion de base de données » du Module 12, « Sécurité de l'accès aux données ».

  • L'utilisation d'un compte Windows en double sur le serveur de base de données (correspondant au compte du processus ASP.NET) entraîne une administration plus lourde. Si un mot de passe est modifié sur un ordinateur, il doit être synchronisé et mis à jour sur tous les ordinateurs. Dans certains scénarios, vous pourrez peut-être utiliser un compte de domaine doté de privilèges minimum pour faciliter l'administration.

  • Entre le serveur Web et le serveur de base de données, le protocole IPSec assure la confidentialité des données échangées avec la base de données.

  • Entre le navigateur et le serveur Web, le protocole SSL protège les informations d'identification et les autres données de sécurité sensibles, telles que des numéros de carte de crédit.

  • Si vous utilisez une batterie de serveurs Internet, vérifiez que les clés de cryptage, par exemple celles utilisées pour crypter le ticket d'authentification par formulaires (et indiquées par l'élément <machineKey> dans le fichier Machine.config), sont cohérentes sur tous les serveurs. Pour plus d'informations sur l'utilisation de ASP.NET dans un scénario de batterie de serveurs Internet, consultez le Module 8, « Sécurité ASP.NET ».

Inconvénients

L'application doit transmettre l'identité de l'appelant initial à la base de données pour prendre en charge les fonctionnalités d'audit. L'identité de l'appelant peut être transmise à l'aide de paramètres de procédures stockées.

Scénarios associés

Authentification par formulaires auprès de Active Directory

Les informations d'identification des utilisateurs qui sont acceptées à partir de la page de formulaire de connexion peuvent être authentifiées auprès de différents magasins. Active Directory peut être utilisé à la place d'une base de données SQL Server.

Informations supplémentaires

Pour plus d'informations, consultez la section « Procédure : Utiliser l'authentification par formulaires avec Active Directory » dans ce guide.

Rôles .NET pour l'autorisation

Le scénario précédent ne prend pas en compte les différents types d'utilisateurs qui accèdent à l'application. Par exemple, un serveur portail peut inclure différents niveaux d'abonnement, tels que Standard, Premier et Enterprise.

Si les informations relatives aux rôles sont conservées dans le magasin d'utilisateurs (base de données SQL Server), l'application peut créer un objet GenericPrincipal pour stocker les informations d'identité et de rôle. Une fois l'objet GenericPrincipal créé et ajouté au contexte de la demande Web (à l'aide de HttpContext.User), vous pouvez ajouter des vérifications de rôles par programmation au code des méthodes ou encore ajouter aux méthodes et aux pages des attributs PrincipalPermission pour exiger l'appartenance à des rôles.

Informations supplémentaires

  • Pour plus d'informations sur la création d'objets GenericPrincipal contenant des listes de rôles, consultez la section « Procédure : Créer des objets GenericPincipal avec l'authentification par formulaires » dans ce guide.

  • Pour plus d'informations sur les demandes PrincipalPermission et les vérifications de rôles par programmation, consultez le Module 8, « Sécurité ASP.NET ».

Utilisation d'un compte de domaine anonyme sur le serveur Web

Dans cette variante du scénario, le compte d'utilisateur Internet anonyme par défaut (compte local appelé IUSR_MACHINE) est remplacé par un compte de domaine. Le compte de domaine est configuré avec les privilèges minimum nécessaires pour exécuter l'application (vous pouvez démarrer sans aucun privilège puis ajouter des privilèges de manière incrémentielle). Si vous disposez de plusieurs applications Web, vous pouvez utiliser différents comptes de domaine (un pour chaque application Web ou répertoire virtuel).

Pour transmettre le contexte de sécurité du compte de domaine anonyme de IIS à ASP.NET, activez l'emprunt d'identité pour l'application Web, à l'aide du paramètre suivant du fichier Web.config :

<identity impersonate="true" />

Si l'application Web communique avec une ressource distante telle qu'une base de données, le compte de domaine doit se voir accorder les autorisations nécessaires pour la ressource. Par exemple, si l'application accède à un système de fichiers distant, les listes de contrôle d'accès doivent être configurées correctement pour accorder (au minimum) un accès en lecture au compte de domaine. Si l'application accède à une base de données SQL Server, le compte de domaine doit être mappé à l'aide d'une connexion SQL à une connexion à une base de données.

Dans la mesure où le contexte de sécurité qui est transmis dans l'application est celui du compte anonyme, l'identité de l'appelant initial (obtenue à l'aide l'authentification par formulaires) doit être transmise au niveau de l'application d'un niveau à l'autre (par l'intermédiaire de paramètres de procédures stockées et de méthodes, par exemple).

Informations supplémentaires

  • Pour plus d'informations sur cette méthode, consultez le paragraphe « Utilisation du compte d'utilisateur Internet anonyme » dans la section « Accès aux ressources réseau » du Module 8, « Sécurité ASP.NET ».

  • Avant d'implémenter ce scénario, consultez l'article Q259353, « Must Enter Password Manually After You Set Password Synchronization » (en anglais) de la Base de connaissances Microsoft.

Connexion de ASP.NET à des composants Microsoft Enterprise Services distants et à SQL Server

Dans ce scénario, un serveur Web qui exécute des pages ASP.NET établit des connexions sécurisées à des composants desservis, situés sur un serveur d'applications distant, qui à son tour se connecte à une base de données SQL Server. Comme dans de nombreuses infrastructures d'applications Internet, le serveur Web et le serveur d'applications sont séparés par un pare-feu (et le serveur Web est situé dans un réseau de périmètre). Les composants desservis établissent des connexions sécurisées à SQL Server.

Par exemple, imaginons une application de système bancaire Internet qui fournit des données sensibles (telles que des informations financières privées) aux utilisateurs. Toutes les transactions bancaires du client à la base de données doivent être sécurisées, et l'intégrité des données est essentielle. Le trafic en provenance et à destination de l'utilisateur doit être sécurisé, tout comme le trafic en provenance et à destination de la base de données. Ce scénario est présenté dans la figure 7.3.

Scénario d'application Internet ASP.NET connectée à des composants Microsoft Enterprise Services distants et à SQL Server

Figure 7.3
Scénario d'application Internet ASP.NET connectée à des composants Microsoft Enterprise Services distants et à SQL Server

Caractéristiques

  • Les utilisateurs font appel à différents types de navigateurs Web.

  • Les utilisateurs anonymes peuvent parcourir les pages de l'application dont l'accès n'est pas limité.

  • Les utilisateurs doivent s'inscrire ou se connecter (par l'intermédiaire d'un formulaire HTML) pour être autorisés à consulter les pages à accès limité.

  • L'application Web frontale est située dans un réseau de périmètre (DMZ) et des pare-feu la séparent du réseau Internet et du réseau interne de l'entreprise (et du serveur d'applications).

  • L'application requiert une sécurité forte, des niveaux d'évolutivité élevés et un audit détaillé.

  • L'application Web utilise SOAP pour se connecter à une couche de services Web, qui offre une interface aux composants desservis s'exécutant dans une application Microsoft Enterprise Services sur le serveur d'applications. SOAP est préférable à DCOM en raison des restrictions associées aux pare-feu.

  • SQL Server utilise un seul rôle de base de données défini par l'utilisateur pour l'autorisation.

  • Les données sont sensibles, et l'intégrité et la confidentialité doivent être sécurisées sur le réseau et dans tous les magasins de données persistantes.

  • Des transactions Microsoft Enterprise Services (COM+) sont utilisées pour assurer l'intégrité des données.

Sécurisation du scénario

Dans ce scénario, le service Web accepte les informations d'identification d'une page de connexion par formulaires puis authentifie l'appelant auprès d'une base de données SQL Server. La page de connexion utilise SSL pour protéger les informations d'identification de l'utilisateur transmises sur Internet.

L'application Web communique avec un service Web, qui fournit une interface aux services métier implémentés dans des composants desservis. Le service Web approuve l'application Web (dans le réseau du périmètre) et authentifie l'identité du processus ASP.NET. L'identité de l'utilisateur est transmise dans tous les niveaux au niveau de l'application à l'aide de paramètres de procédures stockées et de méthodes. Ces informations sont utilisées pour auditer les actions des utilisateurs sur les différents niveaux.

Tableau 7.2 : Mesures de sécurité

Catégorie

Détails

Authentification

  • Fournissez une authentification forte sur le serveur Web.

  • Authentifiez l'identité de l'application Microsoft Enterprise Services au niveau de la base de données.

  • IIS est configuré pour un accès anonyme et l'application Web authentifie les utilisateurs à l'aide de l'authentification par formulaires (auprès d'une base de données SQL Server).

  • Le répertoire virtuel du service Web est configuré pour l'authentification intégrée de Windows. Les services Web authentifient l'identité du processus de l'application Web.

  • L'authentification Windows est utilisée pour la connexion à la base de données. La base de données authentifie le compte Windows doté de privilèges minimum utilisé pour exécuter l'application Microsoft Enterprise Services.

Autorisation

  • Le modèle de sous-système approuvé est utilisé. L'autorisation en fonction de chaque utilisateur a lieu uniquement dans l'application Web.

  • L'accès des utilisateurs aux pages sur le serveur Web est géré à l'aide de l'autorisation des URL.

  • Le compte du processus ASP.NET est autorisé à accéder aux ressources système sur le serveur Web. Les ressources sont protégées à l'aide de listes de contrôle d'accès.

  • Les autorisations dans la base de données sont gérées par un rôle défini par l'utilisateur. L'identité de l'application Microsoft Enterprise Services est membre du rôle.

  • Le compte du processus Microsoft Enterprise Services est autorisé à accéder aux ressources système sur le serveur d'applications. Les ressources sont protégées à l'aide de listes de contrôle d'accès.

Communication sécurisée

  • Les données sensibles envoyées entre les utilisateurs et l'application Web sont sécurisées à l'aide de SSL.

  • Les données sensibles envoyées entre le serveur Web et le service Web sont sécurisées à l'aide de SSL.

  • Les données sensibles transmises entre les composants desservis et la base de données sont sécurisées à l'aide de IPSec.

Résultat

La figure 7.4 présente la configuration de la sécurité recommandée pour ce scénario.

Configuration de la sécurité recommandée pour le scénario d'application Internet ASP.NET connectée à des composants Microsoft Enterprise Services distants et à SQL Server

Figure 7.4
Configuration de la sécurité recommandée pour le scénario d'application Internet ASP.NET connectée à des composants Microsoft Enterprise Services distants et à SQL Server

Étapes de la configuration de la sécurité

Avant de commencer, il est conseillé de consulter les points suivants :

  • Création d'un compte de base de données associé à des privilèges minimum (voir le Module 12, « Sécurité de l'accès aux données »).

  • Configuration de SSL sur un serveur Web (voir « Procédure : Configurer SSL sur un serveur Web » dans ce guide).

  • Configuration de IPSec (voir « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide).

  • Configuration de la sécurité Microsoft Enterprise Services (voir « Procédure : Utiliser la sécurité par rôle avec les services Microsoft Enterprise Services » dans ce guide).

Configuration du serveur Web
Configuration de IIS

Étape

Informations supplémentaires

Activez l'accès anonyme pour le répertoire de la racine virtuelle de l'application Web.

 

Configuration de ASP.NET

Étape

Informations supplémentaires

Redéfinissez le mot de passe du compte ASPNET (utilisé pour exécuter ASP.NET) à l'aide d'un mot de passe sécurisé connu.

Cette opération permet de créer un compte local en double (doté du même nom d'utilisateur et du même mot de passe) sur le serveur de base de données. Elle est indispensable pour autoriser le compte ASPNET à répondre aux demandes d'authentification réseau du serveur de base de données lorsque celui-ci se connecte à l'aide de l'authentification Windows.

Il est également possible d'utiliser un compte de domaine doté de privilèges minimum (si l'authentification Windows est autorisée au travers du pare-feu).

Pour plus d'informations, consultez la section « Identité de processus pour ASP.NET » dans le Module 8, « Sécurité ASP.NET ».

Modifiez le fichier Machine.config qui se trouve dans le répertoire %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG

Associez les attributs du mot de passe et du nom d'utilisateur de votre compte personnalisé à l'élément <processModel>.

La valeur par défaut

<!-- userName="machine" password="AutoGenerate" 
-->

Devient

<!--
userName="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,userName" 
password="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,password" -->

Notez que l'utilitaire aspnet_setreg.exe a été utilisé pour stocker un mot de passe crypté dans le Registre.

Configurez votre application Web ASP.NET pour qu'elle utilise l'authentification par formulaires (avec SSL).

Modifiez le fichier Web.config dans le répertoire de la racine virtuelle de l'application.
Définissez l'élément <authentication> comme suit :

 
<authentication mode="Forms" >  
	<forms name="MyAppFormsAuth"         
                loginUrl="login.aspx"          
	       protection="All"        
	       timeout="20"         
	       path="/" >  
         </forms>
 </authentication>

Pour plus d'informations sur l'utilisation de l'authentification par formulaires avec une base de données SQL Server, consultez la section « Procédure : Utiliser l'authentification par formulaires avec SQL Server 2000 » dans ce guide.

Configuration du serveur d'applications
Configuration de IIS

Étape

Informations supplémentaires

Désactivez l'accès anonyme.

 

Configurez l'authentification intégrée de Windows.

IIS authentifie l'identité du processus ASP.NET à partir de l'application Web sur le serveur Web.

Configuration de ASP.NET

Étape

Informations supplémentaires

Utilisez l'authentification Windows.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel du service Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Windows" />
Configuration des services Microsoft Enterprise Services

Étape

Informations supplémentaires

Créez un compte personnalisé doté de privilèges minimum pour l'exécution de l'application serveur Microsoft Enterprise Services.

Remarque : si vous utilisez un compte local, vous devez également créer un compte en double sur l'ordinateur serveur de base de données.

Configurez l'application Microsoft Enterprise Services pour qu'elle utilise le compte personnalisé.

Consultez la section « Configuration de la sécurité » du Module 9, « Sécurité des services Microsoft Enterprise Services ».

Activez la vérification de l'accès par rôle.

Consultez la section « Configuration de la sécurité » du Module 9, « Sécurité des services Microsoft Enterprise Services ».

Ajoutez un seul rôle Microsoft Enterprise Services (COM+) à l'application appelée (Service Web approuvé, par exemple).

L'autorisation complète de l'utilisateur final est effectuée par l'application Web. Le service Web, et les composants desservis, autorisent uniquement l'accès aux membres du rôle Service Web approuvé.

Ajoutez le compte local ASPNET au rôle Service Web approuvé.

Consultez la section « Configuration de la sécurité » du Module 9, « Sécurité des services Microsoft Enterprise Services ».

Configuration de SQL Server

Étape

Informations supplémentaires

Créez sur l'ordinateur SQL Server un compte Windows qui correspond au compte de l'application Microsoft Enterprise Services.

Le nom d'utilisateur et le mot de passe doivent correspondre à votre compte Microsoft Enterprise Services personnalisé.

Configurez SQL Server pour l'authentification Windows.

 

Créez une connexion SQL Server pour votre compte Microsoft Enterprise Services personnalisé.

Cette opération autorise l'accès à l'ordinateur SQL Server.

Créez un utilisateur de base de données et mappez le nom d'utilisateur à l'utilisateur de base de données.

Cette opération autorise l'accès à la base de données indiquée.

Créez un rôle de base de données défini par l'utilisateur et ajoutez l'utilisateur de base de données dans le rôle.

 

Définissez des autorisations de base de données pour le rôle de base de données.

Accordez des autorisations minimales.
Pour plus d'informations, consultez le Module 12, « Sécurité de l'accès aux données ».

Configuration de la communication sécurisée

Étape

Informations supplémentaires

Configurez le site Web pour SSL.

Voir « Procédure : Configurer SSL sur un serveur Web » dans ce guide.

Configurez SSL entre le serveur Web et le serveur d'applications.

Voir « Procédure : Appeler un service Web avec SSL » dans ce guide.

Configurez IPSec entre le serveur d'applications et le serveur de base de données.

Voir « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide.

Analyse

  • L'authentification par formulaires est idéale dans ce scénario, car les utilisateurs ne disposent pas de comptes Windows. La page de formulaire de connexion est utilisée pour obtenir les informations d'identification des utilisateurs. La validation des informations d'identification doit être réalisée par le code de l'application. Tout magasin de données peut être utilisé. La solution la plus courante consiste à faire appel à une base de données SQL Server. Active Directory offre également un magasin d'informations.

  • L'application Web étant exécutée en tant que compte ASPNET local doté de privilèges minimum, les dommages potentiels en cas d'atteinte à l'intégrité sont limités.

  • L'autorisation des URL sur le serveur Web permet aux utilisateurs non authentifiés de consulter les pages Web à accès non limité et force l'authentification pour les pages à accès limité.

  • L'emprunt d'identité n'étant pas activé, l'accès aux ressources locales ou distantes effectué par l'application Web est réalisé à l'aide du contexte de sécurité du compte ASPNET. Les listes de contrôle d'accès doivent être configurées de manière adaptée.

  • Les informations d'identification des utilisateurs sont validées auprès d'une base de données SQL Server personnalisée. Des hachages de mot de passe accompagnés de valeurs salt (nombres aléatoires) sont stockés dans la base de données. Pour plus d'informations, consultez la section « Authentification des utilisateurs auprès d'une base de données » du Module 12, « Sécurité de l'accès aux données ».

  • L'authentification Windows auprès de SQL évite de stocker les informations d'identification dans des fichiers sur le serveur d'applications et de les transmettre sur le réseau.

  • L'utilisation d'un compte Windows en double sur le serveur de base de données (correspondant au compte du processus Microsoft Enterprise Services) entraîne une administration plus lourde. Si un mot de passe est modifié sur un ordinateur, il doit être synchronisé et mis à jour sur tous les ordinateurs. Dans certains scénarios, vous pourrez peut-être utiliser un compte de domaine doté de privilèges minimum pour faciliter l'administration.

  • Lorsque l'application Web appelle le service Web, elle doit configurer le proxy du service Web à l'aide de DefaultCredentials (c'est-à-dire le compte du processus ASP.NET, ASPNET).

    proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
    

    Pour plus d'informations, consultez la section « Transmission aux services Web des informations d'identification pour l'authentification » dans le Module 10, « Sécurité des services Web ».

  • Entre le serveur Web et la couche du service Web (qui est face aux composants desservis sur le serveur d'applications), le protocole SSL garantit la confidentialité des données envoyées entre les deux serveurs.

  • L'application Microsoft Enterprise Services est configurée pour la sécurité par rôle au niveau de l'application. Cette configuration autorise uniquement le compte local ASPNET (utilisé pour exécuter le service Web) à accéder aux composants desservis.

  • Entre le serveur d'applications et le serveur de base de données, le protocole IPSec assure la confidentialité des données échangées avec la base de données.

  • Entre le navigateur et le serveur Web, le protocole SSL protège les informations d'identification et les informations relatives aux comptes bancaires.

Inconvénients

L'application doit transmettre l'identité de l'appelant initial à la base de données pour prendre en charge les fonctionnalités d'audit. L'identité de l'appelant peut être transmise à l'aide de paramètres de procédures stockées.

Scénarios associés

Authentification par formulaires auprès de Active Directory

Les informations d'identification des utilisateurs qui sont acceptées à partir de la page de formulaire de connexion peuvent être authentifiées auprès de différents magasins. Active Directory peut être utilisé à la place d'une base de données SQL Server.

Informations supplémentaires

Pour plus d'informations, consultez la section « Procédure : Utiliser l'authentification par formulaires avec Active Directory » dans ce guide.

Utilisation de DCOM

Windows 2000 (SP3 ou SP2 avec QFE 18.1) ou Windows .NET Server 2003 permet de configurer des applications Microsoft Enterprise Services en vue d'utiliser un point de terminaison statique. Si un pare-feu sépare le client du serveur, vous devez ouvrir uniquement deux ports sur le pare-feu. En d'autres termes, vous devez ouvrir le port 135 pour RPC et un port pour votre application Microsoft Enterprise Services.

Du fait de cette amélioration apportée au protocole DCOM, il est possible de le choisir comme protocole de communication entre le serveur Web et le serveur d'applications. En outre, il n'est plus nécessaire d'utiliser une couche de services Web.

Important : le protocole DCOM doit être utilisé si votre application nécessite la transmission de transactions distribuées entre les deux serveurs. Les transactions ne peuvent pas être transmises par l'intermédiaire de SOAP. Dans un scénario SOAP, les transactions doivent être initiées par les composants desservis sur le serveur d'applications.

Informations supplémentaires

Pour plus d'informations, consultez le Module 9, « Sécurité des services Microsoft Enterprise Services ».

Utilisation de .NET Remoting

Vous pouvez faire appel à .NET Remoting si vous n'avez pas besoin des services fournis par Microsoft Enterprise Services, tels que des transactions, des composants en file d'attente, des regroupements d'objets, etc. Les solutions .NET Remoting gèrent également l'équilibrage de la charge réseau au niveau intermédiaire. Prenez en considération les éléments suivants lorsque vous utilisez .NET Remoting :

  • Pour des performances optimales, utilisez l'hôte et le canal TCP dans un service Windows. Notez que, par défaut, ce canal n'offre aucun système d'authentification et d'autorisation. Le canal TCP est conçu pour des scénarios de sous-systèmes approuvés. Vous pouvez utiliser une stratégie IPSec pour établir un canal sécurisé et garantir que seul le serveur Web communique avec le serveur d'applications.

  • Si vous devez faire appel à des vérifications d'autorisation et d'authentification à l'aide d'objets IPrincipal , vous devez héberger les objets distants dans ASP.NET et utiliser le canal HTTP. Cette procédure permet d'utiliser les fonctionnalités de sécurité de IIS et de ASP.NET.

  • L'objet distant peut se connecter à la base de données à l'aide de l'authentification Windows et utiliser l'identité du processus hôte (soit ASP.NET, soit l'identité d'un service Windows).

Informations supplémentaires

Pour plus d'informations sur la sécurité .NET Remoting, consultez le Module 11, « Sécurité .NET Remoting ».

Résumé

Ce module vous a expliqué comment sécuriser un ensemble de scénarios d'applications Internet courants.

Pour les scénarios d'applications intranet et extranet, consultez le Module 5, « Sécurité intranet » et le Module 6, « Sécurité extranet ».

Afficher:
© 2014 Microsoft