寄宿多个 ASP.NET 应用程序

asp.net|程序

本单元概要
Microsoft Windows Server 2000 和 Windows Server 2003 操作系统提供了伸缩性非常好、非常可靠的 Web 宿主环境。它们可以用于在一个 Web 服务器或者 Web 服务器场上安全地寄宿成百上千个 Web 站点和 ASP.NET 应用程序。

但是，当在共享宿主场景中使用 ASP.NET 应用程序时，必须考虑如何使应用程序互相独立，以及独立于共享系统资源，包括文件系统、注册表和事件日志。没有足够的独立性，恶意或者设计不良的应用程序会对服务器上的其他应用程序产生负面影响，或者访问未授权的资源。这种应用程序独立对于寄宿多家不同公司的大量应用程序的 Internet 服务提供商 (ISP) 尤其重要。

本单元阐述了在 Windows 2000 和 2003 中可以使用哪些技术隔离 ASP.NET 应用程序，以确保所寄宿的 Web 站点数据的完整性、保密性和真实性。

返回页首
目标
通过本单元能够：

• 理解 Windows 2000 和 2003 中 ASP.NET 的体系结构和主要组成部分。
 
• 使用多个标识、应用程序池和代码访问安全隔离 Web 应用程序。
 
• 配置匿名帐户模拟。
 
• 在使用集成 Windows 身份验证或者证书对用户进行身份验证时，配置固定的帐户模拟以访问本地或者远程的资源。
 
• 提高窗体身份验证的安全性。
 
• 理解在访问 UNC 共享中存储的数据时，如何使用凭据。 
 

返回页首
应用范围
本单元适用于下列产品和技术：

• Microsoft Windows Server 2000 和 2003
 
• Microsoft .NET Framework 1.1 和 ASP.NET 1.1 
 

返回页首
如何使用本单元
本单元主要关注如何获得共享宿主环境中的应用程序独立。关键的要素是代码访问安全。在使用本单元的同时还应该结合以下内容：

• 阅读单元 8“代码访问安全实践”。该单元更详细地解释了代码访问安全的工作原理，以及如何使用它约束单独的程序集，例如限制程序集访问文件系统、注册表、网络和其他关键资源的能力。
 
• 阅读单元 9“在 ASP.NET 中使用代码访问安全”。该单元解释了如何将代码访问安全策略用于 ASP.NET 应用程序，并讨论了构建部分信任应用程序的注意事项和意义。
 
• 阅读单元 16“保护 Web 服务器的安全”。该单元说明了如何保护 Windows 2000 操作系统和 Microsoft .NET Framework。安全的基础平台是保护一个 ASP.NET Web 应用程序或者 Web 服务的前提条件。 
 

本页内容
 本单元概要
 目标
 应用范围
 如何使用本单元
 简介
 Windows 2000 上的 ASP.NET 体系结构
 Windows Server 2003 上的 ASP.NET 体系结构
 用标识隔离应用程序
 用应用程序池隔离应用程序
 用代码访问安全隔离应用程序
 窗体身份验证的问题
 UNC 共享寄宿
 小结

返回页首
简介
在共享宿主场景中，确保应用程序不会对其他应用程序的操作和安全产生负面影响，是非常重要的。

获得应用程序独立有许多方式。可用的选择因 Web 服务器上运行的 .NET Framework 的版本和操作系统的版本的不同而不同。

• 如果运行的是 .NET Framework 的 1.1 版本，可以使用代码访问安全提供的资源约束模型提供一层应用程序独立。这种应用程序独立是通过限制应用程序访问不同类型的资源（如文件系统、注册表、事件日志、Active Directory、数据库、网络资源等等）而实现的。
 
• Windows Server 2003 通过 Internet 信息服务 6.0 (IIS 6) 应用程序池提供了进程独立，可以使多个应用程序运行在不同的 IIS 辅助进程实例中。进程独立在 Windows 2000 上是不可能的，因为所有 Web 应用程序都运行在单独的 ASP.NET 辅助进程实例中，而应用程序域提供了独立性。 
 

表 1 总结了 Windows 2000 和 Windows Server 2003 上应用程序独立的各种选择。

表 1 Windows 2000 和 Windows Server 2003 上的应用程序独立功能
独立功能 Windows 2000 Windows Server 2003
进程独立
 否
 是（IIS 6 应用程序池）
 
应用程序域独立
 是
 是
 
多个线程标识
 是
 是
 
代码访问安全资源约束
 是（.NET Framework 1.1 版）
 是（.NET Framework 1.1 版）
 

运行着 .NET Framework 1.1 版的 Windows Server 2003 是寄宿多个 ASP.NET 应用程序的推荐平台，因为它支持进程独立，并为应用程序独立提供了最大范围的选择。

返回页首
Windows 2000 上的 ASP.NET 体系结构
在 Windows 2000 上，多个 Web 应用程序运行在一个 ASP.NET 辅助进程 (Aspnet_wp.exe) 实例中。每个应用程序都驻留在自己的应用程序域中，为托管代码提供了一定程度的独立性。Windows 2000/IIS 5 体系结构如图 1 所示。

图 1. 带有 IIS 5 的 Windows 2000 上的 ASP.NET 体系结构

表 2 总结了图 1 中所描述的体系结构的组成部分

返回页首
 

Windows Server 2003 上的 ASP.NET 体系结构

在 Windows Server 2003 上，体系结构有所改变，因为 IIS 6 允许多个进程用于寄宿不同的 Web 应用程序。此体系结构如图 2 所示。

注 IIS 6 支持向后兼容模式，从而能够支持 IIS 5 ASP.NET 辅助进程模型。

图 2. 带有 IIS 6 的 Windows Server 2003 上的 ASP.NET 体系结构

与 Windows 2000 下的 ASP.NET 体系结构相比，Windows Server 2003 中的主要区别在于可以用不同的 IIS 辅助进程实例 (W3wp.exe) 寄宿 Web 应用程序。默认时，这些应用程序是使用 NT Authority\NetworkService 帐户运行的，这是一个最低特权本地帐户，它用作跨网络的计算机帐户。运行在网络服务帐户环境下的 Web 应用程序需要给远程服务器提供计算机的凭据以进行身份验证。

为网络服务配置 ACL

为网络服务帐户配置访问控制列表 (ACL) 的过程，对于本地和远程机器而言是不同的。如果要授予本地机器上的网络服务帐户访问权限，需要将网络服务帐户添加到 ACL 中。如果要授予远程机器上的网络服务帐户访问权限，需要将 DomainName\MachineName$ 帐户添加到 ACL 中。

注 不要把网络服务帐户与内置的网络组搞混淆了，后者包括的是跨网络进行身份验证的用户。

表 3 总结了图 2 中所描述的体系结构的主要组成部分。

返回页首
 

用标识隔离应用程序

从操作系统标识的观点来看，可以通过控制用来运行每个应用程序的帐户标识隔离 ASP.NET Web应用程序。如果每个应用程序使用不同的固定帐户标识，就可以分别授权和审核每个应用程序。

注 如果要寄宿使用 .NET Framework 1.0 版构建的 ASP.NET Web应用程序，进程帐户需要适当的对当前文件系统驱动器根的访问权限。有关更多信息，请参阅 Microsoft 知识库文章 317955“FIX:'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page”。

如果共享 Web 服务器上每个应用程序要想都使用不同的固定标识，可以采用两种方式：

匿名帐户模拟

通过匿名帐户模拟，应用程序可以模拟 IIS 指定、并为应用程序的虚拟目录配置的匿名帐户。如果您的应用程序要独立于 IIS 对用户进行身份验证（如，通过使用窗体或者 Microsoft Passport 身份验证），就可以使用此方式。在这些情况下，可以通过使用固定的匿名帐户隔离应用程序。一旦调用方通过了身份验证，角色也经过了检查，就可以将可信服务器模型用于下游的资源访问，其中已配置的匿名帐户提供了可信的标识。

为了支持这一方式，IIS 中的应用程序虚拟目录必须支持匿名访问，必须为每个应用程序配置不同的匿名帐户。应用程序然后必须配置为模拟。这种方式如图 3 所示。本地和远程资源访问假设使用模拟的匿名帐户的安全上下文。

图 3. 用于每个应用程序的多个匿名帐户

为了使用多个匿名帐户进行资源访问

此过程叙f20secmod03.gif述了如何使用多个匿名帐户（每个 Web 应用程序一个）进行资源访问，以支持单独的应用程序授权和审核。

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

固定标识模拟

如果需要 IIS 为应用程序对用户进行身份验证（例如，通过使用集成 Windows 身份验证或者证书身份验证），可以使用一个固定模拟标识来执行 ASP.NET 应用程序。此场景如图 4 所示。

图 4. 应用程序模拟一个固定帐户，并使用它访问资源

可以配置单独的 ASP.NET 应用程序模拟一个固定帐户。这种配置的好处在于，它可以用于任何 IIS 身份验证方法，而且无需 IIS 匿名身份验证。

为了使用多个固定模拟帐户进行资源访问

此过程叙述了如何使用多个固定模拟帐户（每个 Web 应用程序一个）进行资源访问，以支持单独的应用程序授权和审核。

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

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

注 在 Windows 2000 和 .NET Framework 1.0 版上，如果通过使用以上配置模拟一个固定标识，必须给用来运行 Web 应用程序的 ASP.NET 进程帐户授予“Act as part of the operating system”特权。这与最低特权的原则相反。建议您升级到 .NET Framework 1.1 版，这种要求就不再需要了。

返回页首
 

用应用程序池隔离应用程序

如果您的应用程序运行在 Windows Server 2003 上，可以使用应用程序池，并配置每个应用程序运行在自己的辅助进程（这可以提供进程级独立）中。默认时，所有应用程序都运行在一个默认的应用程序池中。通过应用程序池，可以配置每个进程使用不同的标识运行，因此，就无需使用模拟了。

为了提供进程级独立

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

返回页首
 

用代码访问安全隔离应用程序

在 .NET Framework 的 1.1 版中，可以使用 <trust> 元素配置应用程序运行在部分信任级。以下配置说明了如何从 Machine.config 配置一个应用程序的信任级。在此例中，使用了 Medium 信任级。

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

如果配置一个应用程序以“Full”之外的信任级运行，应用程序访问特定资源类型的代码访问安全权限将是受限制的。通过这种方式，可以约束应用程序，防止它们互相交互，以及获得访问系统级资源（如文件系统、注册表、事件日志等等的受限区域）的权限。

有关 ASP.NET 信任级、和如何使用它们提供应用程序独立以及应用程序特定的设计与开发的注意事项方面的更多信息，请参阅“在 ASP.NET 中使用代码访问安全”单元。

注 如果使用代码访问安全提供应用程序独立，应该还考虑到应用程序的操作系统标识。推荐的独立模型是结合使用代码访问安全和 Windows Server 2003 上的进程级独立。

返回页首
 

窗体身份验证的问题

如果在 .NET Framework 的 1.0 版中使用窗体身份验证，应该使用不同的 cookie 路径和名称。如果不这样的话，一个应用程序中身份验证过的某个用户有可能请求另一个应用程序，而不会重定向到该应用程序的登录页。第二个应用程序中的 URL 授权规则可能连使用登录窗体提供登录凭据的机会都不给，就拒绝此用户的访问。

为了避免出现这一问题，每个应用程序的 <forms> 元素都使用唯一的 cookie 路径和名称属性，每个应用程序都使用不同的机器密钥。

.NET Framework 的 1.1 版支持如下所示的 IsolateApps 设置。

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

这确保了机器上的每个应用程序使用不同的密钥进行窗体身份验证 cookie 和视图状态的加密以及验证。

在 .NET Framework 的 1.0 版中，不能使用 IsolateApps，而且必须手工生成 <machineKey> 元素。有关这一问题的更多信息，请参阅 Microsoft 知识库中的以下文章。

返回页首
 

UNC 共享寄宿

如果您要运行一个内容位于通用命名约定 (UNC) 共享中的应用程序，用来访问共享的凭据要么是应用程序的凭据，要么是已通过身份验证的客户端的凭据。这是由管理员在 IIS 中配置的。

当应用程序如此配置时，ASP.NET 模拟它从 IIS 接收到的标记的安全上下文。这不能通过 <identity> 标记配置，除非提供了显式的凭据。

在 .NET Framework 的 1.0 版中，使用 Mscorcfg.msc 根据 URL 创建一个代码组，并授予它完全信任。

当使用一个指向远程共享的虚拟目录寄宿一个 ASP.NET 应用程序时，可能收到一个安全异常。有关更多信息，请参阅 Microsoft 知识库文章 320268“PRB: System.Security.SecurityException:Security error" Error Message when the Virtual Directory Points to a Remote Share in ASP.NET。”

返回页首
 

小结

如果要在一个 Web 服务器上寄宿多个 ASP.NET 应用程序，需要考虑应用程序之间以及应用程序和共享的系统资源（如文件系统、注册表和事件日志）之间的独立。没有足够的独立性，恶意或者设计不良的应用程序可能对服务器上的其他应用程序产生负面影响。

在 Windows Server 2003 上，使用 IIS 6 支持的多辅助进程模型为应用程序提供操作系统进程独立。在 Windows 2000 上，进程独立是不可能的，虽然可以配置多个应用程序使用不同的匿名用户帐户。这提供了单独的应用程序审核，还支持独立的应用程序授权。

在两个平台上，都可以使用代码访问安全提供的资源约束模型作为附加的控制手段，以对哪些应用程序有对哪些资源类型进行访问的权限加以限制。在 ASP.NET应用程序中使用代码访问安全需要 .NET Framework 1.1 版。

有关保护 ASP.NET 应用程序安全的更多信息，请参阅“保护 ASP.NET 应用程序的安全”单元。

以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索net
， windows
， 应用程序
， 运行
， 体系结构
， 模拟帐户
， 单元
身份模拟
，以便于您获取更多的相关知识。