Module 5 : Sécurité intranet

Sur cette page

Dans ce module
Objectifs
S'applique à
Avant de commencer
Connexion de ASP.NET à SQL Server
Connexion entre ASP.NET, Microsoft Enterprise Services et SQL Server
Connexion entre ASP.NET, des services Web et SQL Server
Connexion entre ASP.NET, .NET Remoting et SQL Server
Transmission de l'appelant initial à la base de données
Résumé

Dans ce module

La sécurité d'une application Web intranet est une question importante, même si une application de ce type se situe au sein des limites d'un réseau contrôlé et n'est accessible qu'à un ensemble restreint d'utilisateurs. Les personnes et les services peuvent nécessiter différents niveaux d'accès aux fonctionnalités et aux données de l'application, mais il reste nécessaire de sécuriser les données sensibles pendant leur transmission. L'architecture de la sécurité de l'application doit en outre, ce qui est plus compliqué encore, gérer les différents problèmes de sécurité liés aux caractéristiques d'architecture et de fonctionnement de l'intranet sur lequel l'application doit être déployée.

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 intranet, en mettant l'accent sur les exigences de certaines architectures d'applications distribuées les plus courantes.

Haut de page

Objectifs

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

• sécuriser une application .NET intranet ;

• 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 ;

  • utilisation de services Web comme intermédiaire ;

  • utilisation de .NET Remoting 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 intranet.

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

• 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

Haut de page

Avant de commencer

L'accès aux applications intranet est limité à un groupe d'utilisateurs autorisés (des employés qui appartiennent à un domaine, par exemple). Bien qu'un paramètre intranet limite la disponibilité de votre application, vous pouvez être confronté à plusieurs situations difficiles lorsque vous développez des stratégies d'authentification, d'autorisation et de communication sécurisée. Vous pouvez par exemple disposer de domaines non autorisés à approuver, ce qui complique la transmission de l'identité et du contexte de sécurité de l'appelant au niveau des ressources principales du système. Vous pouvez également travailler dans un environnement hétérogène qui comporte divers types de navigateurs. Dans ce contexte, l'utilisation d'un système d'authentification commun est plus difficile.

Si votre intranet est homogène, si tous les ordinateurs exécutent le système d'exploitation Microsoft® Windows® 2000 ou une version ultérieure et si les utilisateurs de votre domaine sont approuvés pour la délégation, la délégation du contexte de sécurité de l'appelant initial vers le niveau principal est alors une option.

Vous devez également envisager une communication sécurisée. Bien que votre application soit exécutée dans un environnement intranet, vous ne pouvez pas considérer que les données envoyées sur le réseau sont sécurisées. Vous devrez probablement sécuriser les données transmises entre les navigateurs et le serveur Web parallèlement aux données transmises entre les serveurs d'applications et les bases de données.

Les scénarios courants d'intranet présentés ci-après sont utilisés dans ce module pour illustrer les techniques clés d'authentification, d'autorisation et de communication sécurisée :

• Connexion de ASP.NET à SQL Server

• Connexion entre ASP.NET, Microsoft Enterprise Services et SQL Server

• Connexion entre ASP.NET, des services Web et SQL Server

• Connexion entre ASP.NET, .NET Remoting et SQL Server

Ce module décrit en outre un scénario de délégation Windows 2000 (transmission de l'appelant initial à la base de données), dans lequel l'identité et le contexte de sécurité de l'appelant initial sont transmis au niveau du système d'exploitation, du navigateur vers la base de données, à l'aide de serveurs d'applications et de serveurs Web intermédiaires.

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. Exécutez 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, « HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings » (en anglais) de la Base de connaissances Microsoft.

Haut de page

Connexion de ASP.NET à SQL Server

Dans ce scénario, une base de données de ressources humaines gère des données au niveau de chaque utilisateur, de manière sécurisée, sur un intranet homogène. L'application utilise un modèle de sous-système approuvé et exécute des appels pour le compte des appelants initiaux. L'application authentifie les appelants en utilisant l'authentification intégrée de Windows et transmet des appels à la base de données à l'aide de l'identité du processus ASP.NET. En raison de la nature confidentielle des données, le protocole SSL est utilisé entre le serveur Web et les clients.

Le modèle de base de ce scénario d'application est présenté dans la figure 5.1.

Figure 5.1
Connexion de ASP.NET à SQL Server

Caractéristiques

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

• Les clients disposent de Internet Explorer.

• Les comptes d'utilisateurs sont situés dans le service d'annuaire Microsoft Active Directory®.

• L'application fournit des données sensibles, au niveau de chaque utilisateur.

• Seuls les clients authentifiés doivent pouvoir accéder à l'application.

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

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

Sécurisation du scénario

Dans ce scénario, le serveur Web authentifie l'appelant et limite l'accès aux ressources locales en utilisant l'identité de ce dernier. Vous ne devez pas nécessairement effectuer un emprunt d'identité dans l'application Web pour limiter l'accès aux ressources en fonction de l'appelant initial. 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 (c'est-à-dire que la base de données approuve l'application ASP.NET).

Tableau 5.1 : Mesures de sécurité

Résultat

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

Figure 5.2
Configuration de la sécurité recommandée pour le scénario d'application intranet 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 de IIS

Configuration de ASP.NET

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

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

<authentication mode="Windows" />

<identity impersonate="false" />

Configuration de SQL Server

Configuration de la communication sécurisée

Analyse

• L'authentification intégrée de Windows dans IIS est idéale dans ce scénario, car tous les utilisateurs disposent de comptes Windows et utilisent Microsoft Internet Explorer. L'avantage de l'authentification intégrée de Windows réside dans le fait que le mot de passe de l'utilisateur n'est jamais transmis sur le réseau. De plus, la connexion est transparente pour l'utilisateur, car Windows utilise la connexion interactive actuelle de l'utilisateur.

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

• Il n'est pas nécessaire d'effectuer un emprunt d'identité dans ASP.NET pour procéder à des vérifications de rôles .NET ou pour sécuriser les ressources dans les listes de contrôle d'accès Windows par rapport à l'appelant initial. Pour procéder à des vérifications de rôles .NET par rapport à l'appelant initial, l'objet WindowsPrincipal qui représente l'appelant initial est extrait du contexte HTTP, comme suit :

  WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
  if ( wp.IsInRole("Responsable") )
  {
    // L'utilisateur est autorisé à exécuter des fonctionnalités réservées aux responsables.
  }
  

  La classe FileAuthorizationModule ASP.NET assure les vérifications des listes de contrôle d'accès par rapport à l'appelant initial pour les types de fichiers ASP.NET qui sont mappés au fichier aspnet_isapi.dll dans IIS. Pour les types de fichiers statiques tels que les fichiers .jpg, .gif et .htm, IIS fait office d'opérateur de contrôle d'appels et effectue les vérifications d'accès à l'aide de l'identité de l'appelant initial, en fonction des autorisations NTFS associées au fichier.

• L'utilisation de l'authentification Windows auprès de SQL Server permet d'éviter de stocker les informations d'identification dans des fichiers et de les transmettre au serveur de base de données sur le réseau.

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

• La méthode consistant à utiliser le compte local en double fonctionne également en présence d'un pare-feu lorsque les ports requis pour l'authentification Windows ne sont pas forcément ouverts. Il est possible que l'utilisation de comptes de domaine et de l'authentification Windows ne fonctionne pas dans ce scénario.

• Vous devrez vous assurer que vos groupes Windows sont assez précis pour répondre à vos besoins en matière de sécurité. Dans la mesure où la sécurité par rôle .NET est fonction de l'appartenance aux groupes Windows, cette solution repose sur une configuration correcte du niveau de précision des groupes Windows, qui doivent correspondre aux catégories d'utilisateurs (partageant les mêmes privilèges de sécurité) qui accèdent à l'application. Les groupes Windows que vous utilisez ici pour gérer les rôles peuvent être locaux sur cet ordinateur ou dans ces groupes de domaines.

• Les rôles d'utilisateurs de base de données SQL Server sont préférables aux rôles d'applications SQL Server pour éviter les problèmes de gestion des mots de passe et de regroupement de connexions associés à l'utilisation des rôles d'applications SQL.
  Les applications activent les rôles d'application SQL en appelant une procédure stockée intégrée avec un nom de rôle et un mot de passe. Par conséquent, le mot de passe doit être stocké de manière sécurisée. Le regroupement de connexions aux bases de données doit également être désactivé lorsque vous utilisez les rôles d'application SQL, ce qui a une incidence importante sur l'évolutivité des applications.

  Pour plus d'informations sur les rôles d'utilisateurs de bases de données SQL Server et sur les rôles d'applications SQL Server, consultez le Module 12, « Sécurité de l'accès aux données ».

• L'utilisateur de la base de données est ajouté à un rôle d'utilisateur de base de données, et des autorisations sont affectées au rôle de sorte que si le compte de la base de données change, vous n'avez pas besoin de modifier les autorisations pour tous les objets de base de données.

Questions et réponses

• Pourquoi ne puis-je pas activer l'emprunt d'identité pour l'application Web dans le but de protéger les ressources auxquelles mon application Web accède à l'aide de listes de contrôle d'accès configurées par rapport à l'appelant initial ?
  Si vous activez l'emprunt d'identité, le contexte de sécurité dont l'identité a été empruntée n'inclura pas les informations d'identification réseau (en supposant que la délégation n'est pas activée et que vous utilisiez l'authentification intégrée de Windows). L'appel distant à SQL Server utilisera donc une session NULL et l'appel échouera. Si l'emprunt d'identité est désactivé, la demande distante utilisera l'identité du processus ASP.NET.

  Le scénario précédent utilise la classe ASP.NET FileAuthorizationModule, qui procède à l'autorisation à l'aide de listes de contrôle d'accès Windows par rapport à l'identité de l'appelant initial et ne nécessite pas l'emprunt d'identité.

  Si vous utilisez l'authentification de base à la place de l'authentification intégrée de Windows (NTLM) et que vous activez l'emprunt d'identité, chaque appel de la base de données utilise le contexte de sécurité de l'appelant initial. Chaque compte d'utilisateur (ou les groupes Windows auxquels l'utilisateur appartient) nécessite alors des connexions SQL Server. Les autorisations pour les objets de base de données doivent être sécurisées par rapport au groupe Windows (ou l'appelant initial).

• La base de données ne sait pas qui est l'appelant initial. Comment puis-je créer un journal d'audit ?
  Auditez l'activité de l'utilisateur final dans l'application Web ou transmettez l'identité de l'utilisateur explicitement sous forme de paramètre de l'appel d'accès aux données.

Scénarios associés

Navigateurs autres que Internet Explorer

L'authentification intégrée de Windows dans IIS requiert Internet Explorer. Dans un environnement comprenant plusieurs types de navigateurs, les options standard à votre disposition sont les suivantes :

• Authentification de base et SSL. L'authentification de base est prise en charge par la plupart des navigateurs. Dans la mesure où les informations d'identification de l'utilisateur sont transmises sur le réseau, vous devez utiliser SSL pour sécuriser le scénario.

• Certificats clients. Différents certificats clients peuvent être mappés à un compte Windows unique, ou un seul compte Windows peut être utilisé pour représenter tous les clients. L'utilisation des certificats clients requiert également SSL.

• Authentification par formulaires. L'authentification par formulaires peut valider les informations d'identification auprès d'un magasin de données personnalisé (une base de données, par exemple) ou auprès de Active Directory.
  Si vous effectuez l'authentification auprès de Active Directory, vérifiez que vous récupérez uniquement les groupes qui sont utiles pour votre application. Vous ne devez pas envoyer de demandes à une base de données à l'aide de clauses SELECT *. De la même manière, vous ne devez pas extraire aveuglement tous les groupes à partir de Active Directory.
  Si vous effectuez l'authentification auprès d'une base de données, vous devez soigneusement analyser l'entrée utilisée dans les commandes SQL pour vous protéger contre les injections de code SQL. Vous devez également stocker des hachages de mot de passe (avec valeur salt) dans la base de données à la place des mots de passe cryptés ou en texte brut.
  Pour plus d'informations sur l'utilisation de SQL Server en tant que magasin d'informations d'identification et sur le stockage des mots de passe dans la base de données, consultez le Module 12, « Sécurité de l'accès aux données ».

Notez que dans tous les cas, si vous n'utilisez pas l'authentification intégrée de Windows (pour laquelle la plate-forme gère les informations d'identification à votre place), vous devrez utiliser SSL. Cet avantage s'applique toutefois uniquement au processus d'authentification. Si vous transmettez des données de sécurité sensibles sur le réseau, vous devez utiliser IPSec ou SSL.

Authentification SQL dans la base de données

Dans certains scénarios, vous pouvez être contraint d'utiliser l'authentification SQL au lieu de l'authentification Windows recommandée. Par exemple, il est possible qu'un pare-feu soit présent entre l'application Web et la base de données, ou que, pour des raisons de sécurité, le serveur Web ne soit pas membre de votre domaine. L'authentification Windows est alors également impossible. Dans ce cas, vous pouvez utiliser l'authentification SQL entre la base de données et le serveur Web. Pour sécuriser ce scénario, vous devez procéder comme suit :

• Utilisez l'API de protection des données (DPAPI) pour sécuriser les chaînes de connexion de la base de données qui contiennent des noms d'utilisateurs et des mots de passe. Pour plus d'informations, consultez les ressources suivantes :

  • « Stockage sécurisé des chaînes de connexion de base de données » dans le Module 12, « Sécurité de l'accès aux données ».

  • « Procédure : Utiliser DPAPI (magasin de l'ordinateur) à partir de ASP.NET » dans ce guide.

  • « Utiliser DPAPI (magasin d'utilisateurs) à partir de ASP.NET avec Microsoft Enterprise Services » dans ce guide.

  • « Procédure : Créer une bibliothèque DPAPI » dans ce guide.

• Utilisez IPSec ou SSL entre le serveur Web et le serveur de base de données pour protéger les informations d'identification transmises en texte brut sur le réseau.

Transmission de l'appelant initial à la base de données

Dans ce scénario, les appels sont effectués de l'application Web à la base de données, à l'aide du contexte de sécurité de l'appelant initial. Tenez compte des points suivants dans le cadre de cette méthode :

• Si vous choisissez cette méthode, vous devez utiliser l'authentification Kerberos (avec des comptes configurés pour la délégation) ou l'authentification de base.
  Vous trouverez un scénario de délégation dans la section « Transmission de l'appelant initial à la base de données » plus loin dans ce module.

• Vous devez également activer l'emprunt d'identité dans ASP.NET. L'accès aux ressources locales du système est ainsi effectué à l'aide du contexte de sécurité de l'appelant initial et les listes de contrôle d'accès des ressources locales, telles que le Registre et le journal d'événements, nécessitent une configuration appropriée.

• Le regroupement de connexions à la base de données est limité, car les appelants initiaux ne sont pas en mesure de partager les connexions. Chaque connexion est associée au contexte de sécurité de l'appelant.

• Une autre méthode de transmission du contexte de sécurité de l'utilisateur consiste à transmettre l'identité de l'appelant initial au niveau de l'application (en utilisant des paramètres de procédures stockées et de méthodes, par exemple).

Haut de page

Connexion entre ASP.NET, Microsoft Enterprise Services et SQL Server

Dans ce scénario, les pages ASP.NET appellent des composants métier hébergés dans une application Microsoft Enterprise Services qui se connecte à son tour à une base de données. Prenons l'exemple d'un système interne de bons de commande qui utilise des transactions sur l'intranet et qui permet aux services internes d'émettre des commandes. Ce scénario est présenté dans la figure 5.3.

Figure 5.3
ASP.NET appelle un composant dans une application Microsoft Enterprise Services, qui appelle la base de données

Caractéristiques

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

• Les utilisateurs disposent de Internet Explorer.

• Les composants sont déployés sur le serveur Web.

• L'application gère les données confidentielles qui doivent être sécurisées lors de leur transit.

• Les composants métier se connectent à SQL Server à l'aide de l'authentification Windows.

• Les fonctionnalités métier dans ces composants sont limitées en fonction de l'identité de l'appelant.

• Les composants desservis sont configurés en tant qu'application serveur (out-of-process).

• Les composants se connectent à la base de données à l'aide de l'identité du processus de l'application serveur.

• L'emprunt d'identité est activé dans ASP.NET (pour faciliter la sécurité par rôle Microsoft Enterprise Services).

Sécurisation du scénario

Dans ce scénario, le serveur Web authentifie l'appelant initial et transmet le contexte de sécurité de l'appelant au composant desservi. Le composant desservi autorise l'accès aux fonctionnalités métier en fonction de l'identité de l'appelant initial. La base de données procède à l'authentification en fonction de l'identité du processus de l'application Microsoft Enterprise Services (elle approuve les composants desservis dans l'application Microsoft Enterprise Services). Lorsque le composant desservi lance un appel à la base de données, il transmet l'identité de l'utilisateur au niveau de l'application (en utilisant des paramètres de demande approuvés).

Tableau 5.2 : Mesures de sécurité

Résultat

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

Figure 5.4
Configuration de la sécurité recommandée pour le scénario d'application intranet ASP.NET connectée aux services Microsoft Enterprise Services locaux 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 de IIS

Configuration de ASP.NET

<authentication mode="Windows" />

<identity impersonate="true" />

<processModel
    comImpersonationLevel="Impersonate"

Configuration de Microsoft Enterprise Services

[assembly:
ApplicationActivation(ActivationOption.Server)]

Configuration de SQL Server

Configuration de la communication sécurisée

Analyse

• ASP.NET et Microsoft Enterprise Services étant exécutés en tant que comptes dotés de privilèges minimum, les dommages potentiels en cas d'atteinte à l'intégrité sont limités. Si l'intégrité de l'identité de l'un des deux processus venait à être compromise, les privilèges minimum du compte limiteraient alors l'étendue des dommages. En outre, dans le cas de ASP.NET, si un script malveillant était injecté, les dommages potentiels seraient limités.

• L'application ASP.NET doit être configurée pour l'emprunt d'identité afin de transmettre le contexte de sécurité de l'appelant initial aux composants Microsoft Enterprise Services (pour gérer l'autorisation par rôle Microsoft Enterprise Services (COM+)). Si vous n'utilisez pas l'emprunt d'identité, les vérifications de rôles sont effectuées en fonction de l'identité du processus (c'est-à-dire le processus de travail ASP.NET). L'emprunt d'identité concerne les personnes par rapport auxquelles l'autorisation des ressources est effectuée.
  Sans l'emprunt d'identité, les vérifications des ressources système sont effectuées en fonction de l'identité du processus ASP.NET. Avec l'emprunt d'identité, les vérifications des ressources système sont effectuées par rapport à l'appelant initial. Pour plus d'informations sur l'accès aux ressources système à partir de ASP.NET, consultez la section « Accès aux ressources système » du Module 8, « Sécurité ASP.NET ».

• Si les rôles Microsoft Enterprise Services (COM+) sont utilisés, les vérifications d'accès sont repoussées vers le niveau intermédiaire (« middle-tier »), qui contient la logique métier. Dans ce cas, les appelants sont vérifiés au niveau du portail puis mappés aux rôles, et les appels transmis à la logique métier reposent sur les rôles. Cette opération permet d'éviter les appels inutiles au niveau principal. Un autre avantage des rôles Microsoft Enterprise Services (COM+) réside dans le fait que vous pouvez créer et administrer les rôles au moment du déploiement, à l'aide du Gestionnaire des services de composants.

• L'authentification Windows auprès de SQL permet d'éviter de stocker les informations d'identification dans des fichiers et de les envoyer sur le réseau.

• La méthode consistant à utiliser un compte local pour exécuter l'application Microsoft Enterprise Services et un compte en double sur le serveur de base de données fonctionne également en présence d'un pare-feu lorsque les ports requis pour l'authentification Windows ne sont pas forcément ouverts. Il est possible que l'utilisation de comptes de domaine et de l'authentification Windows ne fonctionne pas dans ce scénario.

Inconvénients

• 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. Les mots de passe doivent être régulièrement mis à jour et synchronisés de manière manuelle.

• Dans la mesure où la sécurité par rôle .NET est fonction de l'appartenance aux groupes Windows, cette solution repose sur une configuration correcte du niveau de précision des groupes Windows, qui doivent correspondre aux catégories d'utilisateurs (partageant les mêmes privilèges de sécurité) qui accèdent à l'application.

Haut de page

Connexion entre ASP.NET, des services Web et SQL Server

Dans ce scénario, un serveur Web qui exécute des pages ASP.NET se connecte à un service Web sur un ordinateur distant. Ce serveur se connecte à son tour à un serveur de base de données distant. Par exemple, imaginons une application de ressources humaines qui fournit des données sensibles spécifiques à un utilisateur. L'application s'appuie sur le service Web pour l'extraction des données. Le modèle de base de ce scénario d'application est présenté dans la figure 5.5.

Figure 5.5
Connexion de ASP.NET au service Web distant et à SQL Server

Le service Web met à disposition une méthode qui autorise un employé à extraire ses informations personnelles. Les informations doivent être fournies uniquement à des personnes authentifiées à l'aide de l'application Web. Le service Web fournit également une méthode qui gère l'extraction des informations de tous les employés. Cette fonctionnalité doit être disponible uniquement pour les membres du service de paie ou des ressources humaines. Dans ce scénario, les employés sont répartis en trois groupes Windows :

• HRDept (membres du service des ressources humaines)
  Les membres de ce groupe peuvent extraire des informations sur tous les employés.

• PayrollDept (membres du service de paie)
  Les membres de ce groupe peuvent extraire des informations sur tous les employés.

• Employees (tous les employés)
  Les membres de ce groupe peuvent extraire uniquement les informations les concernant.

En raison de la nature confidentielle des données, le trafic doit être sécurisé entre tous les nœuds.

Caractéristiques

• Les utilisateurs disposent de Internet Explorer version 5.x ou ultérieure.

• Tous les ordinateurs exécutent Windows 2000 ou version ultérieure.

• Les comptes d'utilisateurs figurent dans l'annuaire Active Directory, au sein d'une seule forêt.

• L'application transmet le contexte de sécurité de l'appelant initial jusqu'à la base de données.

• Tous les niveaux utilisent l'authentification Windows.

• Les comptes d'utilisateurs de domaine sont configurés pour la délégation.

• La base de données ne gère pas la délégation.

Sécurisation du scénario

Dans ce scénario, le serveur Web qui héberge l'application Web ASP.NET authentifie l'identité de l'appelant initial et transmet son contexte de sécurité au serveur distant qui héberge le service Web. Cette opération permet d'appliquer des vérifications d'autorisations aux méthodes Web afin d'autoriser ou de refuser l'accès à l'appelant initial. La base de données procède à l'authentification en fonction de l'identité du processus du service Web (la base de données approuve le service Web). Le service Web effectue alors des appels à la base de données et transmet l'identité de l'utilisateur au niveau de l'application, à l'aide de paramètres de procédures stockées.

Tableau 5.3 : Mesures de sécurité

Résultat

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

Figure 5.6
Configuration de la sécurité recommandée pour le scénario d'application intranet ASP.NET connectée au service Web et à SQL Server

Étapes de la configuration de la sécurité

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

• 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 (qui héberge l'application Web)

<authentication mode="Windows" />

<identity impersonate="true" />

Configuration du serveur d'applications (qui héberge le service Web)

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

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

<authentication mode="Windows" />

<identity impersonate="false" />

Configuration de SQL Server

Configuration de la communication sécurisée

Analyse

• L'authentification intégrée de Windows dans IIS est idéale dans ce scénario, car tous les utilisateurs sont équipés de Windows 2000 ou version ultérieure et de Internet Explorer 5.x ou version ultérieure, et disposent de comptes dans Active Directory, ce qui permet d'utiliser le protocole d'authentification Kerberos (lequel gère la délégation). Vous pouvez ainsi transmettre le contexte de sécurité de l'utilisateur sur différents ordinateurs.

• Les comptes des utilisateurs finaux ne doivent PAS être signalés comme « sensibles et ne pouvant pas être délégués » dans Active Directory. Le compte de l'ordinateur du serveur Web doit être signalé comme « approuvé pour la délégation » dans Active Directory. Pour plus d'informations, consultez la section « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » dans ce guide.

• ASP.NET sur le serveur Web et le serveur d'applications s'exécutant avec un compte doté de privilèges minimum (le compte ASPNET par défaut), les dommages potentiels en cas d'atteinte à l'intégrité sont limités.

• Le service Web et l'application Web sont tous deux configurés pour l'authentification Windows. IIS est configuré sur les deux ordinateurs pour l'authentification intégrée de Windows.

• Lorsqu'un appel au service Web est effectué à partir de l'application Web, aucune information d'identification n'est transmise par défaut. Ces informations sont nécessaires pour répondre aux demandes d'authentification réseau émises par IIS sur le serveur Web en aval. Vous devez le spécifier explicitement en définissant la propriété Credentials du proxy du service Web, comme suit :

  wsproxy.Credentials = CredentialCache.DefaultCredentials;
  

  Pour plus d'informations sur l'appel de services Web avec des informations d'identification, consultez le Module 10, « Sécurité des services Web ».

• L'application Web est configurée pour l'emprunt d'identité. En conséquence, les appels de l'application Web au service Web transmettent le contexte de sécurité de l'appelant initial et autorisent le service Web à authentifier (et à autoriser) l'appelant initial.

• Les rôles .NET sont utilisés dans le service Web pour autoriser les utilisateurs en fonction du groupe Windows auquel ils appartiennent : HRDept (ressources humaines), PayrollDept (paie) et Employees (employés). Les membres des groupes HRDept et PayrollDept peuvent extraire des informations concernant tous les employés, tandis que les membres du groupe Employees sont autorisés à extraire uniquement leurs propres informations.
  Les méthodes Web peuvent être annotées avec la classe PrincipalPermissionAttribute pour exiger des appartenances à des rôles précis, comme l'indique l'exemple de code suivant. Notez que PrincipalPermission peut être utilisé à la place de PrincipalPermissionAttribute. Il s'agit d'une fonctionnalité commune à tous les types d'attributs .NET.

  [WebMethod]
  [PrincipalPermission(SecurityAction.Demand,
                    Role=@"DomainName\HRDept)]
  public DataSet RetrieveEmployeeDetails()
  {
  }
  

  L'attribut indiqué dans le code précédent implique que seuls les membres du groupe Windows NomDomaine\HRDept (Ressources humaines) sont autorisés à appeler la méthode RetrieveEmployeeDetails. Si une personne qui n'est pas membre du groupe tente d'appeler la méthode, une exception de sécurité est lancée.

• L'autorisation de fichiers ASP.NET (dans l'application Web et le service Web) effectue une vérification des listes de contrôle d'accès par rapport à l'appelant pour tout type de fichier pour lequel un mappage existe dans la métabase IIS, qui mappe le type de fichier à Aspnet_isapi.dll. Les types de fichiers statiques (.jpg, .gif ou .htm, par exemple), pour lesquels il n'existe pas de mappage ISAPI, sont vérifiés par IIS (également à l'aide de la liste de contrôle d'accès associée au fichier).

• Puisque l'application Web est configurée pour l'emprunt d'identité, les ressources auxquelles l'application accède doivent être configurées à l'aide d'une liste de contrôle d'accès qui accorde au moins un accès en lecture à l'appelant initial.

• Le service Web ne procède pas à l'emprunt d'identité ou à la délégation. Il accède par conséquent aux ressources système locales et à la base de données à l'aide de l'identité du processus ASP.NET. Ainsi, tous les appels sont effectués à l'aide du compte de processus unique. Le regroupement de connexions à la base de données peut donc être utilisé. Si la base de données ne gère pas les délégations (SQL Server versions 7.0 et antérieures, par exemple), ce scénario est une option adaptée.

• L'authentification Windows auprès de SQL Server permet d'éviter de stocker les informations d'identification sur le serveur Web. Elle permet également de ne jamais transmettre les informations d'identification à l'ordinateur SQL Server sur le réseau.

• Entre l'appelant initial et le serveur Web, le protocole SSL protège les données échangées avec l'application Web.

• Entre le serveur Web en aval et la base de données, le protocole IPSec protège les données échangées avec la base de données.

Inconvénients

• 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. Les mots de passe doivent être régulièrement mis à jour et synchronisés de manière manuelle.
  Une autre solution consiste à utiliser des comptes de domaines dotés de privilèges minimum. Pour plus d'informations sur le choix d'une identité de processus ASP.NET, consultez le Module 8, « Sécurité ASP.NET ».

• Dans la mesure où la sécurité par rôle .NET dépend de l'appartenance aux groupes Windows, cette solution repose sur une configuration correcte du niveau de précision des groupes Windows, qui doivent correspondre aux catégories d'utilisateurs (partageant les mêmes privilèges de sécurité) qui accèdent à l'application.

• La délégation Kerberos n'est pas limitée. Vous devez par conséquent déterminer soigneusement les identités d'applications qui s'exécutent sur le serveur Web. Pour renforcer la sécurité, limitez la portée du compte de domaine en supprimant le compte du groupe Utilisateurs du domaine et accordez l'accès uniquement à partir des ordinateurs appropriés. Pour plus d'informations, consultez le livre blanc « Default Access Control Settings » (en anglais) sur le site Web de Microsoft, à l'adresse http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp.

Questions et réponses

La base de données ne sait pas qui est l'appelant initial. Comment puis-je créer un journal d'audit ?

Auditez l'activité de l'utilisateur final dans le service Web ou transmettez l'identité de l'utilisateur explicitement sous forme de paramètre de l'appel de l'accès aux données.

Scénarios associés

Si vous devez vous connecter à des bases de données non-SQL Server ou si vous utilisez actuellement l'authentification SQL, vous devez transmettre explicitement les informations d'identification du compte de la base de données à l'aide de la chaîne de connexion. Dans ce cas, assurez-vous de stocker la chaîne de connexion de manière sécurisée.

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 ».

Haut de page

Connexion entre ASP.NET, .NET Remoting et SQL Server

Dans ce scénario, un serveur Web qui exécute des pages ASP.NET établit des connexions sécurisées à un composant distant sur un serveur d'applications distant. Le serveur Web communique avec le composant à l'aide de .NET Remoting sur le canal HTTP. Le composant distant est hébergé par ASP.NET, comme l'illustre la figure 5.7.

Figure 5.7
Connexion de ASP.NET à un composant distant (à l'aide de .NET Remoting) et à SQL Server

Caractéristiques

• Les utilisateurs se servent de différents types de navigateurs Web.

• Le composant distant est hébergé par ASP.NET.

• L'application Web communique avec le composant distant à l'aide du canal HTTP.

• L'application ASP.NET appelle le composant .NET distant et transmet les informations d'identification de l'appelant initial pour l'authentification (informations issues de l'authentification de base).

• Les données sensibles doivent être sécurisées entre les processus et les ordinateurs.

Sécurisation du scénario

Dans ce scénario, le serveur Web qui héberge l'application Web ASP.NET authentifie les appelants initiaux. L'application Web est en mesure d'extraire les informations d'authentification de l'appelant (nom d'utilisateur et mot de passe) à partir des variables du serveur HTTP. Elle peut ensuite les utiliser pour établir la connexion au serveur d'applications qui héberge le composant distant, en configurant le proxy de ce dernier. La base de données utilise l'authentification Windows pour procéder à l'authentification en fonction de l'identité du processus ASP.NET (la base de données approuve le composant distant). Le composant distant appelle alors la base de données et transmet l'identité de l'appelant initial au niveau de l'application à l'aide des paramètres des procédures stockées.

Tableau 5.4 : Mesures de sécurité

Résultat

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

Figure 5.8
Configuration de la sécurité recommandée pour le scénario d'application intranet ASP.NET connectée au service Web distant 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 du serveur Web

<authentication mode="Windows" />

Configuration du serveur d'applications

<authentication mode="Windows" />

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

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

<identity impersonate="false" />

Configuration de SQL Server

Configuration de la communication sécurisée

Analyse

• ASP.NET sur le serveur Web et le serveur d'applications étant exécuté en tant que compte local doté de privilèges minimum, les dommages potentiels en cas d'atteinte à l'intégrité sont limités. Le compte ASPNET par défaut est utilisé dans les deux cas.
  L'utilisation du compte local ASPNET (en double sur l'ordinateur SQL Server) limite encore les risques potentiels en termes de sécurité. Un compte Windows dupliqué sur le serveur de base de données permet au composant distant de s'exécuter avec un compte ASP.NET doté de privilèges minimum sur le serveur d'applications.

• L'authentification de base au niveau du serveur Web permet aux informations d'identification de l'utilisateur d'être utilisées par l'application Web pour répondre aux demandes d'authentification Windows du serveur d'applications.
  Pour appeler le composant distant à l'aide des informations d'identification de l'appelant, l'application Web configure le proxy du composant distant, comme l'indique le fragment de code suivant.

  string pwd = Request.ServerVariables["AUTH_PASSWORD"];
  string uid = Request.ServerVariables["AUTH_USER"];
  IDictionary channelProperties =
                           ChannelServices.GetChannelSinkProperties(proxy);
  NetworkCredential credentials;
  credentials = new NetworkCredential(uid, pwd);
  ObjRef objectReference = RemotingServices.Marshal(proxy);
  Uri objectUri = new Uri(objectReference.URI);
  CredentialCache credCache = new CredentialCache();
  credCache.Add(objectUri, "Negotiate", credentials);
  channelProperties["credentials"] = credCache;
  channelProperties["preauthenticate"] = true;
  

  Pour plus d'informations sur la transmission des informations d'autorisation sécurisées à un composant distant, consultez le Module 11, « Sécurité .NET Remoting ».

• L'emprunt d'identité n'est pas activé dans l'application Web ASP.NET, car le proxy du composant distant est configuré spécifiquement à l'aide des informations d'identification de l'utilisateur obtenues par l'authentification de base. Toute autre ressource à laquelle l'application Web accède utilise le contexte de sécurité fourni par le compte du processus ASP.NET.

• Entre l'utilisateur et le serveur Web, le protocole SSL protège les données échangées avec le serveur Web, et protège également les informations d'identification de base transmises en texte brut lors du processus d'authentification.

• L'authentification intégrée de Windows au niveau du serveur d'applications fournit des vérifications de rôles .NET par rapport à l'appelant initial. Les rôles correspondent aux groupes Windows.

  Des vérifications par rôle peuvent être effectuées, même sans emprunt d'identité.

• L'autorisation de fichiers ASP.NET effectue des vérifications de listes de contrôle d'accès par rapport à l'appelant pour tout type de fichier pour lequel un mappage existe dans la métabase IIS, qui mappe le type de fichier à aspnet_isapi.dll. IIS effectue des vérifications d'accès pour les fichiers statiques (qui ne sont pas mappés à une extension ISAPI dans IIS).

• L'emprunt d'identité n'étant pas activé sur le serveur d'applications, l'accès aux ressources locales ou distantes effectué par le composant distant est effectué à l'aide du contexte de sécurité ASPNET. Les listes de contrôle d'accès doivent être définies de manière adaptée.

• L'authentification Windows auprès de SQL Server permet d'éviter de stocker les informations d'identification sur le serveur d'applications. Elle permet également de ne pas transmettre les informations d'identification à l'ordinateur SQL Server sur le réseau.

Inconvénients

• 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. Les mots de passe doivent être régulièrement mis à jour et synchronisés de manière manuelle.

• Dans la mesure où la sécurité par rôle .NET est fonction de l'appartenance aux groupes Windows, cette solution repose sur une configuration correcte du niveau de précision des groupes Windows, qui doivent correspondre aux catégories d'utilisateurs (partageant les mêmes privilèges de sécurité) qui accèdent à l'application.

Scénarios associés

Le serveur Web utilise le protocole Kerberos pour authentifier les appelants. La délégation Kerberos est utilisée pour transmettre le contexte de sécurité de l'appelant initial au composant distant sur le serveur d'applications.

Cette méthode implique la configuration de tous les comptes d'utilisateurs pour la délégation. L'application Web doit également être configurée pour l'emprunt d'identité et doit utiliser DefaultCredentials pour configurer le proxy du composant distant. Cette technique est traitée plus en détail dans la section « Transmission de l'appelant initial » du Module 11, « Sécurité .NET Remoting ».

Haut de page

Transmission de l'appelant initial à la base de données

Les scénarios présentés ci-dessus ont utilisé le modèle de sous-système approuvé et, dans tous les cas, la base de données a approuvé le serveur d'applications ou le serveur Web afin qu'il authentifie et qu'il autorise les utilisateurs. Bien que le modèle de sous-système approuvé offre de nombreux avantages, certains scénarios (peut-être pour des raisons d'audit) peuvent nécessiter l'utilisation du modèle d'emprunt d'identité ou de délégation et transmettent le contexte de sécurité de l'appelant initial sur différents ordinateurs jusqu'à la base de données.

Les principales raisons qui peuvent justifier la nécessité de transmettre l'appelant initial à la base de données sont les suivantes :

• Vous avez besoin d'un accès précis dans la base de données et les autorisations sont limitées par objet. Certains utilisateurs ou groupes peuvent lire les différents objets, tandis que d'autres peuvent écrire dans les différents objets.
  Cela s'oppose à l'autorisation par tâche, moins précise, pour laquelle l'appartenance aux rôles détermine les fonctionnalités de lecture et d'écriture pour des objets spécifiques.

• Vous souhaiterez peut-être utiliser les fonctionnalités d'audit de la plate-forme, au lieu de transmettre l'identité et d'effectuer l'audit au niveau de l'application.

Si vous choisissez un modèle d'emprunt d'identité ou de délégation (ou si vous devez le faire en raison de la stratégie de sécurité de l'entreprise) et que vous transmettez le contexte de l'appelant initial dans les différents niveaux de votre application jusqu'au niveau principal, vous devez prendre en compte la délégation et l'accès réseau dans la conception (tâche non négligeable lorsque de nombreux ordinateurs sont concernés). Le regroupement des ressources partagées (telles que des connexions à une base de données) devient également un souci essentiel et peut réduire de façon importante les possibilités d'évolutivité de l'application.

Cette section vous indique comment implémenter l'emprunt d'identité ou la délégation pour deux des scénarios d'application les plus courants :

• Connexion de ASP.NET à SQL Server

• Connexion entre ASP.NET, Microsoft Enterprise Services et SQL Server

Pour plus d'informations sur le sous-système approuvé et les modèles d'emprunt d'identité ou de délégation, ainsi que leurs avantages respectifs, consultez le Module 3, « Authentification et autorisation ».

Connexion de ASP.NET à SQL Server

Dans ce scénario, les appels transmis à la base de données sont effectués à l'aide du contexte de sécurité de l'appelant initial. Les options d'authentification décrites dans cette section incluent l'authentification de base et l'authentification intégrée de Windows. Vous trouverez un scénario de délégation Kerberos dans la section « Connexion entre ASP.NET, Microsoft Enterprise Services et SQL Server ».

Utilisation de l'authentification de base sur le serveur Web

Les paramètres de configuration de l'authentification de base ci-après vous permettent de transmettre l'appelant initial jusqu'à la base de données.

Tableau 5.5 : Mesures de sécurité

Dans le cadre de cette méthode, prenez note des points suivants :

• L'authentification de base fait apparaître une boîte de dialogue dans laquelle l'utilisateur peut saisir ses informations d'identification (nom d'utilisateur et mot de passe).

• La base de données doit reconnaître l'appelant initial. Si le serveur Web et la base de données sont dans des domaines différents, des relations d'approbation appropriées doivent être activées pour permettre l'authentification de l'appelant initial.

Utilisation de l'authentification intégrée de Windows sur le serveur Web

L'authentification intégrée de Windows implique l'authentification NTLM ou Kerberos et est dépendante de la configuration des ordinateurs serveur et client.

L'authentification NTLM ne prend pas en charge la délégation et ne permet par conséquent pas de transmettre le contexte de sécurité de l'appelant initial du serveur Web à une base de données physiquement distante. Le seul tronçon réseau autorisé pour l'authentification NTLM est utilisé entre le navigateur et le serveur Web. Pour utiliser l'authentification NTLM, SQL Server doit être installé sur le serveur Web, cette configuration étant probablement appropriée uniquement pour les applications intranet de très petite taille.

Connexion entre ASP.NET, Microsoft Enterprise Services et SQL Server

Dans ce scénario, les pages ASP.NET appellent des composants métier hébergés dans une application Microsoft Enterprise Services distante qui communique à son tour avec une base de données. Le contexte de sécurité de l'appelant initial est transmis du navigateur jusqu'à la base de données. Ce scénario est présenté dans la figure 5.9.

Figure 5.9
ASP.NET appelle un composant dans une application Microsoft Enterprise Services qui appelle la base de données

Caractéristiques

• Les utilisateurs disposent de Internet Explorer versions 5.x ou ultérieures.

• Tous les ordinateurs utilisent Windows 2000 ou version ultérieure.

• Les comptes d'utilisateurs sont gérés dans Active Directory dans une seule forêt.

• L'application transmet le contexte de sécurité de l'appelant initial (au niveau du système d'exploitation) jusqu'à la base de données.

• Tous les niveaux utilisent l'authentification Windows.

• Les comptes d'utilisateurs de domaine sont configurés pour la délégation et le compte utilisé pour exécuter l'application Microsoft Enterprise Services doit être signalé comme « Approuvé pour la délégation » dans Active Directory.

Sécurisation du scénario

Dans ce scénario, le serveur Web authentifie l'appelant. Vous devez ensuite configurer ASP.NET pour l'emprunt d'identité afin de transmettre le contexte de sécurité de l'appelant initial à l'application Microsoft Enterprise Services distante. Dans l'application Microsoft Enterprise Services, le code du composant doit explicitement emprunter l'identité de l'appelant (à l'aide de CoImpersonateClient) pour garantir que le contexte de l'appelant est transmis à la base de données.

Tableau 5.6 : Mesures de sécurité

Résultat

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

Figure 5.10
ASP.NET appelle un composant Microsoft Enterprise Services qui appelle la base de données. Le contexte de sécurité de l'appelant initial est transmis à la base de données.

Étapes de la configuration de la sécurité

Avant de commencer, veillez à prendre en compte les considérations suivantes :

• Le compte du processus Microsoft Enterprise Services doit être signalé comme « approuvé pour la délégation » dans Active Directory et les comptes des utilisateurs ne doivent pas être signalés comme « sensibles et ne pouvant pas être délégués ». Pour plus d'informations, consultez la section « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » du présent guide.

• Le système d'exploitation Windows 2000, ou version ultérieure, est requis sur tous les ordinateurs ; notamment les ordinateurs client (navigateur) et tous les serveurs.

• Tous les ordinateurs doivent figurer dans l'annuaire Active Directory et faire partie d'une seule forêt.

• Le serveur d'applications qui héberge les services Microsoft Enterprise Services doit exécuter Windows 2000 SP3.

• Si vous utilisez Microsoft Internet Explorer 6.0 sur Windows 2000, l'authentification NTLM est adoptée par défaut à la place de l'authentification Kerberos requise. Pour activer la délégation Kerberos, consultez l'article Q299838, « Impossible de négocier l'authentification Kerberos après la mise à niveau vers Internet Explorer 6 » dans la Base de connaissances Microsoft.

<authentication mode="Windows" />

<identity impersonate="true" />

<processModel comImpersonationLevel="Delegate"

<processModel
comAuthenticationLevel="PktPrivacy"

 class COMSec
 {
  [DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
 public static extern long CoImpersonateClient();
 
 [DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
 public static extern long CoRevertToSelf();
 }
 

COMSec.CoImpersonateClient();
COMSec.CoRevertToSelf();

  [assembly:
  ApplicationActivation(ActivationOption.Server)]
  

[assembly: ApplicationAccessControl(
	  Authentication =
	  AuthenticationOption.Privacy)]

 [assembly: 
ApplicationAccessControl(AccessChecksLevel= 
AccessChecksLevelOption. ApplicationComponent)]

 [ComponentAccessControl(true)]

Analyse

• L'élément essentiel sur lequel repose la transmission du contexte de sécurité de l'appelant initial est l'authentification Kerberos, qui génère un jeton de niveau délégation. Une fois que le processus serveur (IIS) a reçu ce jeton, il peut le transmettre à tout autre processus, exécuté sous un compte sur le même ordinateur, sans modifier son niveau de délégation. Peu importe si le processus de travail est exécuté en tant que compte de domaine ou compte local. Il est toutefois important de savoir comment IIS est exécuté. Si les services IIS ne s'exécutent pas en tant que LocalSystem, le compte sous lequel ils sont exécutés doit être marqué comme étant « approuvé pour la délégation » dans Active Directory.
  Si les services IIS s'exécutent en tant que LocalSystem, le compte d'ordinateur doit être marqué comme étant « approuvé pour la délégation ». Pour plus d'informations, consultez la section « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » du présent guide.

• L'authentification intégrée de Windows (avec Kerberos) dans IIS est idéale dans ce scénario, car tous les utilisateurs disposent de comptes Windows et utilisent Internet Explorer version 5.x ou ultérieure. L'avantage de l'authentification intégrée de Windows réside dans le fait que le mot de passe de l'utilisateur n'est jamais transmis sur le réseau. De plus, la connexion est transparente, car Windows utilise la connexion interactive actuelle de l'utilisateur.

• ASP.NET construit un objet WindowsPrincipal et lui associe le contexte actif de la demande Web (HttpContext.User). Si vous devez effectuer des vérifications d'autorisation dans l'application Web, vous pouvez utiliser le code suivant.

  WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
  if ( wp.IsInRole("Responsable") )
  {
    // L'utilisateur est autorisé à exécuter des fonctionnalités réservées aux responsables.
  }
  

  La classe ASP.NET FileAuthorizationModule est chargée de la vérification des listes de contrôle d'accès par rapport à l'appelant initial pour les types de fichiers ASP.NET qui sont mappés dans IIS au fichier aspnet_isapi.dll. Pour les types de fichiers statiques tels que les fichiers .jpg, .gif et .htm, IIS fait office d'opérateur de contrôle d'appels et effectue les vérifications d'accès à l'aide de l'identité de l'appelant initial.

• 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 envoyer sur le réseau. Par exemple, incluez l'attribut Trusted_Connection dans la chaîne de connexion :

  ConStr="server=VotreServeur; database=VotreBaseDeDonnées; Trusted_Connection=Yes;"
  

• Le contexte de l'appelant initial est transmis sur tous les niveaux, ce qui facilite grandement l'audit. Vous pouvez utiliser l'audit au niveau de la plate-forme (par exemple les fonctions d'audit offertes par Windows et SQL Server).

Inconvénients

• Si vous utilisez Internet Explorer 6.0 sur Windows 2000, le système d'authentification par défaut qui est négocié est NTLM (et non Kerberos). Pour plus d'informations, consultez l'article Q299838, « Impossible de négocier l'authentification Kerberos après la mise à niveau vers Internet Explorer 6 » dans la Base de connaissances Microsoft.

• La délégation des utilisateurs sur les différents niveaux est moins intéressante, en termes de performances et d'évolutivité des applications, que le modèle du sous-système approuvé. Vous ne pouvez pas tirer parti du regroupement de connexions à la base de données, car les connexions à la base de données sont liées au contexte de sécurité de l'appelant initial et ne peuvent donc pas être regroupées de manière efficace.

• Cette méthode repose également sur la précision des groupes Windows correspondant aux exigences de sécurité de votre application. C'est-à-dire que le niveau de précision des groupes Windows doit être défini correctement pour que les groupes correspondent aux catégories d'utilisateurs (partageant les mêmes autorisations de sécurité) qui accèdent à l'application.

Haut de page

Résumé

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

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

Haut de page