Sur cette page

Dans ce module
Objectifs
S'applique à
Introduction
Architecture d'ASP.NET sur Windows 2000
Architecture d'ASP.NET sur Windows Server 2003
Isolation des applications par identité
Isolation d'applications grâce à des pools d'applications
Isolation d'applications à l'aide de la sécurité d'accès au code
Problèmes liés à l'authentification par formulaire
Hébergement de partage UNC
Résumé

Dans ce module

Les systèmes d'exploitation Windows Server 2000 et 2003 fournissent des environnements d'hébergement Web très robustes et évolutifs. Ils permettent d'héberger de manière sécurisée des centaines de sites Web et applications ASP.NET sur un seul serveur Web ou sur une batterie de serveurs Web.

Toutefois, lorsque vous utilisez des applications ASP.NET dans des scénarios d'hébergement partagé, vous devez faire très attention à la manière dont les applications sont isolées les unes des autres et isolées des ressources système partagées, notamment le système de fichiers, le Registre et les journaux d'événements. Sans une bonne isolation, une application malveillante ou mal conçue pourrait nuire aux autres applications du serveur ou accéder à des ressources protégées. L'isolation des applications est particulièrement important du point de vue des fournisseurs d'accès Internet (FAI) qui hébergent de nombreuses applications appartenant à différentes entreprises.

Ce module explique les techniques que vous pouvez mettre en œuvre dans Windows 2000 et 2003 pour isoler les applications ASP.NET en vue de garantir l'intégrité, la confidentialité et l'authenticité des données des sites Web que vous hébergez.

Haut de page

Objectifs

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

• comprendre l'architecture et les principaux composants d'ASP.NET dans Windows 2000 et 2003 ;

• isoler les applications en utilisant plusieurs identités, les pools d'applications et la sécurité d'accès au code ;

• configurer l'emprunt d'identité d'un compte anonyme ;

• configurer l'emprunt de l'identité d'un compte fixe pour accéder aux ressources locales ou distantes lorsque les utilisateurs sont authentifiés à l'aide de l'authentification Windows ou de certificats ;

• améliorer la sécurité de l'authentification par formulaire ;

• comprendre de quelle manière les informations d'authentification sont utilisées lors de l'accès aux données stockées dans des partages UNC.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

• Microsoft Windows Server 2000 et 2003 ;

• Microsoft .NET Framework 1.1 et ASP.NET 1.1.

Haut de page

Introduction

Dans un scénario d'hébergement partagé, il est indispensable de veiller à ce que les applications ne puissent pas nuire au fonctionnement et à la sécurité des autres applications.

Plusieurs méthodes d'isolation des applications existent. Les options disponibles dépendent de la version de .NET Framework et de la version du système d'exploitation que vous exécutez sur le serveur Web.

• Si vous exécutez la version 1.1 de .NET Framework, vous pouvez utiliser le modèle de limitation des ressources fourni par la sécurité d'accès au code pour mettre en œuvre un certain degré d'isolation des applications. Cette isolation est obtenue en empêchant l'application d'accéder à différents types de ressources comme le système de fichiers, le Registre, le journal d'événements, Active Directory, les bases de données, les ressources réseau, etc.

• Windows Server 2003 assure l'isolation des processus par l'intermédiaire des pools d'applications d'Internet Information Services 6.0 (IIS 6) qui permettent d'exécuter plusieurs applications dans des instances distinctes du processus de traitement d'IIS. L'isolation des processus n'est pas possible sur Windows 2000 car toutes les applications Web s'exécutent dans une seule instance du processus de traitement ASP.NET, l'isolation étant assurée par les domaines d'application.

Le tableau 20.1 récapitule les différentes options d'isolation des applications disponibles sur Windows 2000 et Windows Server 2003.

Tableau 20.1 : Fonctions d'isolation des applications pour Windows 2000 et Windows Server 2003

La plate-forme recommandée pour l'hébergement de plusieurs applications ASP.NET est la version 1.1 de .NET Framework exécutée sur Windows Server 2003, car elle prend en charge l'isolation de processus et fournit le plus large éventail d'options d'isolation des applications.

Haut de page

Architecture d'ASP.NET sur Windows 2000

Sur Windows 2000, les applications Web multiples s'exécutent sur une seule instance du processus de traitement ASP.NET (Aspnet_wp.exe). Chaque application réside dans son propre domaine d'application, lequel assure un certain degré d'isolation au code géré. L'architecture de la plate-forme Windows 2000/IIS 5 est schématisée à la figure 20.1.

Figure 20.1
Architecture d'ASP.NET sur Windows 2000 et IIS 5

Les composants de l'architecture schématisée à la figure 20.1 sont récapitulés dans le tableau 20.2.

Tableau 20.2 : Composants de l'architecture d'ASP.NET sur Windows 2000

Haut de page

Architecture d'ASP.NET sur Windows Server 2003

Sur Windows Server 2003, l'architecture est différente car IIS 6 permet d'utiliser plusieurs processus pour héberger différentes applications Web. Reportez-vous à la figure 20.2.

Remarque : IIS 6 fournit un mode de compatibilité descendante qui, à son tour, prend en charge le modèle du processus de traitement ASP.NET d'IIS 5.

Figure 20.2
Architecture d'ASP.NET sur Windows Server 2003 et IIS 6

La principale différence de l'architecture d'ASP.NET sur Windows Server 2003 par rapport à celle de Windows 2000 réside dans le fait que plusieurs instances distinctes du processus de traitement d'IIS (W3wp.exe) peuvent être utilisées pour héberger des applications Web. Par défaut, ces instances s'exécutent avec le compte Autorité NT\Service réseau, un compte local doté de privilèges minimum qui se comporte comme le compte ordinateur sur le réseau. Une application Web qui s'exécute dans le contexte du compte Service réseau présente les informations d'authentification de l'ordinateur aux serveurs distants pour être authentifiée.

Configuration des listes de contrôle d'accès pour le compte Service réseau

La configuration des listes de contrôle d'accès pour le compte Service réseau varie selon qu'il s'agit d'ordinateurs locaux ou distants. Si vous souhaitez que le compte Service réseau puisse accéder à un ordinateur local, ajoutez-le à une liste de contrôle d'accès. Si vous souhaitez que le compte Service réseau puisse accéder à un ordinateur distant, ajoutez le compte NomDomaine\NomOrdinateur$ à une liste de contrôle d'accès.

Remarque : ne confondez pas le compte Service réseau avec le groupe prédéfini Réseau, qui contient les utilisateurs authentifiés sur le réseau.

Les principaux composants de l'architecture, schématisés à la figure 20.2, sont récapitulés dans le tableau 20.3.

Tableau 20.3 : Composants de l'architecture d'ASP.NET sur Windows Server 2003

Haut de page

Isolation des applications par identité

Vous pouvez isoler les applications Web ASP.NET d'après les identités du système d'exploitation, en contrôlant l'identité de compte utilisée pour exécuter chaque application. Si chaque application utilise sa propre identité de compte prédéfinie, vous pouvez autoriser et auditer chaque application séparément.

Remarque : si vous hébergez une application Web ASP.NET conçue dans .NET Framework version 1.0, le compte de processus doit posséder les autorisations appropriées sur la racine du lecteur du système de fichiers actuel. Reportez-vous à l'article 317955 de la Base de connaissances Microsoft, « FIX: 'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page ».

Il existe deux manières d'utiliser des identités prédéfinies distinctes pour chaque application d'un serveur Web partagé :

• emprunt d'identité d'un compte anonyme ;

• emprunt d'identité d'un compte prédéfini.

Emprunt d'identité d'un compte anonyme

Si vous utilisez l'emprunt d'identité d'un compte anonyme, l'application emprunte l'identité du compte anonyme spécifié par IIS et configuré pour le répertoire virtuel de l'application. Vous pouvez choisir cette méthode si votre application authentifie les utilisateurs indépendamment d'IIS, en utilisant par exemple l'authentification par formulaire ou l'authentification Microsoft Passport. Dans ces scénarios, vous pouvez isoler l'application en utilisant un compte anonyme prédéfini. Une fois l'appelant authentifié et les rôles vérifiés, le modèle du serveur de confiance peut être utilisé pour contrôler l'accès aux ressources en aval, le compte anonyme configuré fournissant l'identité approuvée.

Pour que cette méthode puisse être mise en œuvre, les répertoires virtuels de l'application définis dans IIS doivent prendre en charge l'accès anonyme et un compte anonyme distinct doit être configuré pour chaque application. Vous devez ensuite configurer l'application pour qu'elle utilise l'emprunt d'identité. La méthode est illustrée à la figure 20.3. L'accès aux ressources locales et distantes s'effectue en considérant le contexte de sécurité du compte anonyme représenté.

Figure 20.3
Utilisation de plusieurs comptes anonymes pour chaque application

• Pour accéder aux ressources en utilisant plusieurs comptes anonymes :

  La procédure ci-dessous indique comment utiliser plusieurs comptes anonymes (un par application Web) pour l'accès aux ressources afin d'appliquer les stratégies d'autorisation et d'audit de chaque application.

  1. Créez de nouveaux comptes utilisateur anonymes (un par application).
     Pour plus d'informations sur la création d'un compte utilisateur anonyme, reportez-vous à la section « Comptes » du module 16, « Sécurisation de votre serveur Web ».

     Si vous devez accéder aux ressources distantes à l'aide du compte anonyme, vous pouvez soit utiliser un compte de domaine très peu privilégié, soit utiliser un compte local et en créer une copie sur le serveur distant en gardant le même nom d'utilisateur et le même mot de passe.

  2. Utilisez les balises <location> de Machine.config pour activer l'emprunt d'identité dans chaque application Web.

     <location path="Web Site Name/VDirName" allowOverride="false" >
       <system.web>
         <identity impersonate="true" />
       <system.web>
     <location>
     

     Le paramètre allowOverride="false" évite qu'une application puisse changer cette configuration dans un fichier Web.config. Pour plus d'informations sur l'élément <location>, reportez-vous à la section « Description de Machine.Config et de Web.Config » du module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

  3. Dans le Gestionnaire des services Internet, configurez le répertoire virtuel de chaque application afin qu'il utilise un compte d'utilisateur anonyme différent.

     1. Lancez le Gestionnaire des services Internet à partir du groupe de programmes Outils d'administration.

     2. Sélectionnez le répertoire virtuel de l'application, cliquez avec le bouton droit de la souris, puis cliquez sur Propriétés.

     3. Cliquez sur l'onglet Sécurité, puis sur le bouton Modifier.

     4. Vérifiez que Accès anonyme est sélectionné, puis cliquez sur Modifier.

     5. Entrez le nom d'utilisateur du compte anonyme que vous avez créé ou cliquez sur Parcourir pour sélectionner le nom d'utilisateur dans une liste.

     6. Si vous souhaitez utiliser le compte pour accéder à une ressource distante, désactivez l'option Autoriser la vérification de mot de passe par IIS pour le compte anonyme.

        Si vous activez l'option Autoriser la vérification de mot de passe par IIS, la session ouverte à l'aide du compte anonyme spécifié possède des informations d'identification réseau NULL et ne permet pas d'accéder aux ressources réseau qui requièrent une authentification. Si vous désactivez la case, la session devient une session interactive dotée d'informations d'identification réseau. Cependant, s'il s'agit d'un compte local d'ordinateur, aucun autre ordinateur du réseau ne peut authentifier le compte. Dans ce cas, créez une copie du compte sur le serveur distant cible.

        Remarque : le type de session ouverte dépend du paramètre LogonMethod de la métabase IIS. Par défaut, il s'agit d'une session interactive qui requiert que le compte possède le privilège d'utilisateur « Autoriser l'ouverture de session locale ».
        L'option Autoriser la vérification de mot de passe par IIS n'est pas disponible dans IIS 6. Dans IIS 6, le paramètre LogonMethod par défaut est Réseau texte en clair, qui requiert que le compte possède le privilège d'utilisateur « Accéder à cet ordinateur à partir du réseau ». Cela permet l'authentification du compte par un serveur réseau.

  4. Configurez les autorisations NTFS de chaque compte de manière à ce que chaque compte puisse uniquement accéder aux dossiers et aux fichiers du système de fichiers approprié, et qu'il ne puisse pas accéder aux ressources stratégiques telles que les outils du système d'exploitation.
     Pour plus d'informations sur la configuration des autorisations NTFS pour le compte anonyme, reportez-vous au module 16, « Sécurisation de votre serveur Web ».

     Remarque : si vous lancez l'Assistant IISLockdown, celui-ci crée un groupe Utilisateurs Web anonymes. Les membres de ce groupe se voient refuser l'accès aux outils et aux répertoires système.

Emprunt d'identité d'un compte prédéfini

Lorsque vous avez besoin qu'IIS authentifie les utilisateurs de votre application, en utilisant l'authentification Windows intégrée ou l'authentification de certificats par exemple, vous pouvez utiliser l'emprunt d'une identité prédéfinie pour exécuter l'application ASP.NET. Ce scénario est illustré à la figure 20.4.

Figure 20.4
Les applications empruntent l'identité d'un compte prédéfini et l'utilisent pour accéder aux ressources

Vous pouvez configurer chaque application ASP.NET de sorte qu'elle emprunte l'identité d'un compte prédéfini. Cette configuration présente l'avantage de pouvoir être utilisée quelle que soit la méthode d'authentification IIS. Elle ne nécessite pas l'authentification anonyme d'IIS.

• Pour accéder aux ressources en utilisant plusieurs comptes prédéfinis :

  La procédure ci-dessous indique comment utiliser plusieurs comptes prédéfinis (un par application Web) pour l'accès aux ressources afin d'appliquer les stratégies d'autorisation et d'audit de chaque application.

  1. Créez de nouveaux comptes utilisateur anonymes (un par application).
     Pour plus d'informations sur la création d'un compte utilisateur anonyme, reportez-vous à la section « Comptes » du module 16, « Sécurisation de votre serveur Web ».

     Si vous devez accéder aux ressources distantes à l'aide du compte anonyme, vous pouvez soit utiliser un compte de domaine très peu privilégié, soit utiliser un compte local et en créer une copie sur le serveur distant en gardant le même nom d'utilisateur et le même mot de passe.

  2. Stockez les informations d'authentification sous forme cryptée dans le Registre.
     Exécutez Aspnet_setreg.exe pour stocker les informations d'authentification du nouveau compte sous forme cryptée dans le Registre. Reportez-vous à l'article 329290 de la Base de connaissances Microsoft, « 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 ».

  3. Activez l'emprunt d'identité dans chaque application Web.
     Vous pouvez le faire dans le fichier Machine.config ou Web.config. Pour configurer plusieurs applications en lui affectant différentes identités, utilisez les balises <location> de Machine.config. Le résultat de l'exécution de l'outil Aspnet_setreg.exe, utilisé à l'étape précédente, vous indique le format à adopter pour les valeurs d'attributs userName et password de l'élément <identity>. En voici quelques exemples :

     <location path="Web Site Name/appvDir1" allowOverride="false" >
       <system.web>
          <identity impersonate="true"
                    userName=
               "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,userName"
                    password=
               "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,password"/>
       </system.web>
     </location>
     
     <location path="Web Site Name/appvDir2" allowOverride="false" >
       <system.web>
           <identity impersonate="true"
                     userName=
             "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,userName"
                     password=
             "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,password"/>
       </system.web>
     </location>
     

     Pour configurer l'emprunt d'identité au niveau d'une application, ajoutez un élément <identity> dans le fichier Web.config de l'application, comme indiqué dans l'exemple ci-dessous.

     <identity impersonate="true"
        userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
        password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
     

  4. Configurez les autorisations NTFS de chaque compte de manière à ce que chaque compte puisse uniquement accéder aux dossiers et aux fichiers du système de fichiers approprié, et qu'il ne puisse pas accéder aux ressources stratégiques telles que les outils du système d'exploitation.
     Pour plus d'informations sur la configuration des autorisations NTFS pour le compte anonyme, reportez-vous au module 16, « Sécurisation de votre serveur Web ».

Remarque : sur Windows 2000 et .NET Framework version 1.0, si vous empruntez l'identité d'un compte prédéfini en utilisant la configuration décrite ci-dessus, vous devez accorder le privilège « Agir en tant que partie du système d'exploitation » au compte de processus ASP.NET servant à exécuter les applications Web. Cela va à l'encontre du principe du moindre privilège. Il est recommandé de passer à .NET Framework version 1.1, qui n'exige plus ce privilège.

Haut de page

Isolation d'applications grâce à des pools d'applications

Si vos applications s'exécutent sur Windows Server 2003, vous pouvez utiliser des pools d'application et configurer chaque application pour qu'elle s'exécute dans son propre processus de traitement afin d'obtenir une isolation au niveau des processus. Par défaut, toutes les applications s'exécutent dans un pool d'applications par défaut. Avec les pools d'applications, vous pouvez configurer chaque processus pour qu'il s'exécute à l'aide d'une identité différente ; vous n'avez donc plus besoin de passer par l'emprunt d'identité.

• Pour fournir une isolation au niveau des processus :

  1. Créez un ensemble de nouveaux comptes Windows, (un par application, pour exécuter chaque instance de processus de traitement).

  2. Configurez les autorisations NTFS de chaque compte de manière à ce que chaque compte puisse uniquement accéder aux dossiers et aux fichiers du système de fichiers approprié, et qu'il ne puisse pas accéder aux ressources stratégiques telles que les outils du système d'exploitation.

     Pour plus d'informations sur la configuration des autorisations NTFS pour le compte anonyme, reportez-vous au module 16, « Sécurisation de votre serveur Web ».

  3. Désactivez l'emprunt d'identité dans les applications Web.
     Vous pouvez le faire dans le fichier Machine.config ou Web.config. Pour désactiver l'emprunt d'identité dans plusieurs applications, placez des éléments <identity> à l'intérieur d'éléments <location> dans le fichier Machine.config, comme indiqué dans l'exemple ci-dessous.

     Utilisez la configuration ci-dessous. Elle n'effectue pas d'emprunt d'identité.

     <location path="Web Site Name/appvDir1" allowOverride="false" >
       <system.web>
          <identity impersonate="false"
       </system.web>
     </location>
     

     Remarque : par défaut, les applications ASP.NET n'effectuent pas d'emprunt d'identité.

  4. Créez de nouveaux pools d'applications et configurez-les pour qu'ils utilisent les nouveaux comptes.
     Utilisez IIS 6 pour créer de nouveaux pools d'applications en gardant les paramètres par défaut, puis configurez l'identité de chaque pool en utilisant les comptes créés à l'étape 1, de manière à ce que chaque pool s'exécute avec une identité différente.

  5. Configurez chaque application pour qu'elle s'exécute dans son propre pool d'applications.
     Dans l'onglet Répertoire de chaque application IIS, choisissez le pool d'applications dans lequel l'application doit s'exécuter.

Haut de page

Isolation d'applications à l'aide de la sécurité d'accès au code

Dans la version 1.1 de .NET Framework, vous pouvez configurer les applications pour qu'elles s'exécutent à un niveau de confiance partielle, en utilisant l'élément <trust>. La configuration ci-dessous montre comment configurer le niveau de confiance d'une application dans Machine.config. Dans cet exemple, le niveau de confiance moyenne est choisi.

<location path="Web Site Name/appvDir1" allowOverride="false" >
  <system.web>
    <trust level="Medium" originUrl="" />
  </system.web>
</location>

Si vous configurez une application pour qu'elle s'exécute à un niveau de confiance autre que « Total », l'application dispose d'autorisations limitées par la sécurité d'accès au code pour accéder à certains types de ressources. De cette manière, vous pouvez restreindre le champ d'action des applications pour éviter qu'elles interfèrent les unes avec les autres et qu'elles accèdent aux ressources système telles que les zones protégées du système de fichiers, le Registre, le journal d'événements, etc.

Pour plus d'informations sur les niveaux de confiance d'ASP.NET, sur la manière de les utiliser à des fins d'isolation d'application et sur les questions spécifiques au développement et à la conception d'applications, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Remarque : si vous utilisez la sécurité d'accès au code à des fins d'isolation d'application, vous devez encore tenir compte de l'identité du système d'exploitation de l'application. Le modèle d'isolation recommandé consiste à associer la sécurité d'accès au code à l'isolation de niveau processus sur Windows Server 2003.

Haut de page

Problèmes liés à l'authentification par formulaire

Si vous utilisez l'authentification par formulaire dans la version 1.0 de .NET Framework, vous devez utiliser des chemins et des noms de cookie séparés. Si vous ne le faites pas, il est possible qu'un utilisateur authentifié dans une application lance une requête vers une autre application sans être redirigé vers la page de connexion de cette application. Les règles d'autorisation d'accès à l'URL de la deuxième application peuvent alors rejeter l'utilisateur, sans lui laisser la possibilité de fournir ses informations d'authentification à l'aide du formulaire d'ouverture de session.

Pour éviter cela, utilisez des attributs de nom et de chemin de cookie uniques dans l'élément <forms> de chaque application. Utilisez également des clés d'ordinateur distinctes pour chaque application.

La version 1.1 de .NET Framework prend en charge le paramètre IsolateApps illustré ci-dessous.

<machineKey validationKey="AutoGenerate,IsolateApps"            
            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

Il permet de veiller à ce que toutes les applications de l'ordinateur utilisent une clé séparée pour le cryptage et la validation des cookies d'authentification par formulaire et de l'état d'affichage.

Dans la version 1.0 de .NET Framework, vous ne pouvez pas utiliser IsolateApps et vous devez générer manuellement les éléments <machineKey>. Pour plus d'informations sur ce problème, consultez les articles suivants de la Base de connaissances Microsoft :

• 313116, « PRB: Forms Authentication Requests Are Not Directed to loginUrl Page »

• 312906, « How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication »

Haut de page

Hébergement de partage UNC

Si vous hébergez une application dont le contenu est basé sur un partage UNC (Universal Naming Convention), les informations d'authentification utilisées pour accéder au partage sont soit celles de l'application, soit celles du client authentifié. Cette option doit être définie par un administrateur dans IIS.

Lorsqu'une application est configurée de la sorte, ASP.NET emprunte l'identité du contexte de sécurité du jeton qu'IIS lui envoie. Vous ne pouvez pas le définir à l'aide de la balise <identity> à moins que des informations d'authentification explicites aient été fournies.

Dans la version 1.0 de .NET Framework, utilisez Mscorcfg.msc pour créer un groupe de codes basé sur l'URL et lui accorder une confiance totale.

Si vous utilisez un répertoire virtuel pointant vers un partage distant pour héberger une application ASP.NET, il est possible qu'une exception de sécurité se produise. Reportez-vous à l'article 320268 de la Base de connaissances Microsoft, « PRB: "System.Security.SecurityException: Security error" Error Message when the Virtual Directory Points to a Remote Share in ASP.NET ».

Haut de page

Résumé

Si vous hébergez plusieurs applications ASP.NET sur un seul serveur Web, vous devez faire attention à la manière dont les applications sont isolées les unes des autres et isolées des ressources système partagées telles que le système de fichiers, le Registre et les journaux d'événements. Sans une bonne isolation, une application malveillante ou mal conçue pourrait nuire aux autres applications du serveur.

Sur Windows Server 2003, utilisez le modèle de processus de traitement multiples pris en charge par IIS 6 pour fournir aux applications l'isolation des processus du système d'exploitation. Sur Windows 2000, l'isolation des processus n'est pas possible, bien que vous puissiez configurer plusieurs applications de sorte qu'elles utilisent des comptes utilisateur anonymes distincts. Cela permet de séparer l'audit des applications et de prendre en charge des règles d'autorisation propres à chaque application.

Sur ces deux plates-formes, vous pouvez utiliser le modèle de limitation des ressources fourni par la sécurité d'accès au code. Il permet de renforcer le contrôle de l'accès des applications aux différents types de ressources. Pour utiliser la sécurité d'accès au code dans les applications ASP.NET, vous devez disposer de la version 1.1 de .NET Framework.

Pour plus d'informations sur la sécurisation des applications ASP.NET, reportez-vous au module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Haut de page