本页内容

本模块内容
目标
适用范围
如何使用本模块
简介
Windows 2000 上的 ASP.NET 体系结构
Windows Server 2003 上的 ASP.NET 体系结构
按标识隔离应用程序
使用应用程序池隔离应用程序
使用代码访问安全隔离应用程序
表单身份验证问题
UNC 共享驻留
小结

本模块内容

Windows Server 2000 和 2003 操作系统提供了可伸缩性和健壮性非常高的 Web 驻留环境。使用它们，可以在一个 Web 服务器或 Web 场上安全地驻留上百个 Web 站点和 ASP.NET 应用程序。

但是，在共享驻留方案中使用 ASP.NET 应用程序时，您必须考虑如何在应用程序之间以及应用程序与共享的系统资源（包括文件系统、注册表和事件日志）之间进行隔离。如果没有进行充分的隔离，恶意的或开发不完善的应用程序可能会对服务器上的其他应用程序造成不利影响，或会访问未经授权的资源。因为 Internet 服务提供商 (ISP) 驻留了来自不同公司的数量巨大的应用程序，因此对应用程序进行这种隔离对于 ISP 尤为重要。

本模块介绍了在 Windows 2000 和 2003 中可以用哪些技术来隔离 ASP.NET 应用程序，以确保所驻留的网站数据的完整性、机密性和真实性。

目标

使用本模块可以实现：

• 了解 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 服务安全的先决条件。

简介

在共享驻留方案中，确保应用程序不会对其他应用程序的运行和安全构成不利影响是十分必要的。

通过许多方法都可以实现应用程序隔离。可用的选项可能会有所不同，这取决于 Web 服务器运行的操作系统的版本和 .NET Framework 的版本。

• 如果正在运行 .NET Framework 1.1，则可以使用代码访问安全性所提供的资源限制模型，以提供一个级别的应用程序隔离。这样的应用程序隔离是通过限制应用程序对不同类型的资源（如文件系统、注册表、事件日志、Active Directory、数据库、网络资源等）的访问来实现的。

• Windows Server 2003 通过 Internet 信息服务 6.0 (IIS 6) 应用程序池提供进程隔离，通过这些应用程序池，多个应用程序可以在单独的 IIS 工作进程实例中运行。Windows 2000 上无法实现进程隔离，因为所有 Web 应用程序都运行于 ASP.NET 工作进程的单个实例中，由应用程序域提供隔离。

表 20.1 总结了 Windows 2000 和 Windows Server 2003 上可用于应用程序隔离的各种选项。

表 20.1：Windows 2000 和 Windows Server 2003 的应用程序隔离功能

其上运行 .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 体系结构显示在图 20.1 中。

图 20.1
在 Windows 2000 和 IIS 5 中的 ASP.NET 体系结构

图 20.1 中所描述的体系结构的组件总结在表 20.2 中。

表 20.2：Windows 2000 ASP.NET 体系结构的组件

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

在 Windows Server 2003 上，体系结构发生更改，因为 IIS 6 允许使用多个进程来驻留独立的 Web 应用程序。如图 20.2 所示。

注意 IIS 6 支持向后兼容模式，该模式支持 IIS 5 ASP.NET 工作进程模型。

图 20.2
Windows Server 2003 及 IIS 6 上的 ASP.NET

与 Windows 2000 下的 ASP.NET 体系结构相比，Windows Server 2003 中的ASP.NET 体系结构的主要区别在于可以使用单独的 IIS 工作进程实例 (W3wp.exe) 来驻留 Web 应用程序。默认情况下，它们使用 NT Authority\NetworkService 帐户，此帐户是具有最少权限的本地帐户，用作网络上的计算机帐户。在网络服务帐户下运行的 Web 应用程序会将计算机的凭据提交给远程服务器以便进行身份验证。

配置网络服务的 ACL

为网络服务帐户配置访问控制列表 (ACL) 因本地和远程计算机而异。如果您要为本地计算机上的网络服务帐户授予访问权，请将网络服务帐户添加到 ACL。如果您要为远程计算机上的网络服务帐户授予访问权，则需将 DomainName\MachineName$ 帐户添加到 ACL。

注意 不要混淆网络服务帐户和网络内置组，后者包含通过网络进行身份验证的用户。

表 20.3 总结了图 20.2 所描述的体系结构的主要组件。

表 20.3：Windows Server 2003 ASP.NET 体系结构的组件

按标识隔离应用程序

通过控制用于运行每个应用程序的帐户标识，可以将 ASP.NET Web 应用程序与操作系统标识隔离。如果每个应用程序使用独立的固定帐户标识，那么您可以单独对每个应用程序进行授权和审核。

注意 如果您驻留的一个 ASP.NET Web 应用程序是使用 .NET Framework 版本 1.0 创建的，则进程帐户需要对当前文件系统驱动器的根目录具有相应的权限。有关更多信息，请参考 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 中的应用程序的虚拟目录必须支持匿名访问，而且必须为每个应用程序配置单独的匿名帐户。然后必须针对模拟对应用程序进行配置。此方法显示在图 20.3 中。本地和远程资源访问假定模拟匿名帐户具有安全的环境。

图 20.3
用于每个应用程序的多个匿名帐户。

• 在访问资源时使用多个匿名帐户

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

  1. 创建新的匿名用户帐户，每个应用程序一个匿名帐户。
     有关创建匿名用户帐户的更多信息，请参考模块 16 保护 Web 服务器中的“帐户”一节。

     如果需要使用匿名帐户访问远程资源，请使用最少权限的域帐户，或者使用本地帐户并在远程服务器上创建一个具有匹配的用户名和密码的重复的本地帐户。

  2. 使用 Machine.config 中的 <location> 标记来针对模拟配置每个 Web 应用程序。

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

     
     

     allowOverride="false" 设置防止各个应用程序在 Web.config 文件中覆盖此设置。有关 <location> 元素的更多信息，请参考模块 19 确保 ASP.NET 应用程序和 Web Services 的安全中的“Machine.config 和 Web.config 解释”。

  3. 使用 Internet 服务管理器来配置每个应用程序的虚拟目录，以使用单独的匿名帐户。

     1. 从管理工具程序组启动 Internet 服务管理器。

     2. 选择应用程序的应用程序目录，单击右键然后单击“属性”。

     3. 单击“安全”选项卡然后单击“编辑”按钮。

     4. 确保已选择“匿名访问”并单击“编辑”。

     5. 输入已创建的匿名帐户的用户名，或单击“浏览”以从列表中选择用户名。

     6. 如果要使用帐户访问远程资源，则清除匿名帐户的“允许 IIS 控制密码”复选框。

        如果您选择“允许 IIS 控制密码”，则使用指定的用户帐户创建的登录会话具有空的网络凭证，而且不能用来访问要求进行身份验证的网络资源。如果您清除了此复选框，则登录会话是使用网络凭证的交互的登录会话。但是，如果此帐户对计算机而言是本地的，则网络上没有其他计算机可以对此帐户进行身份验证。在此方案中，在目标远程服务器上创建一个复制帐户。

        注意 创建的登录会话的类型由LogonMethod IIS 元数据库设置来控制。默认为交互登录会话，它要求帐户具有“允许本地登录”用户权限。
        “允许 IIS 控制密码”选项在 IIS 6 上不可用。IIS 6 将默认的 LogonMethod 设置为“网络明文”，它要求帐户具有“从网络访问此计算机”的用户权限。这允许网络服务器对帐户进行身份验证。

  4. 为每个帐户配置 NTFS 权限，以确保每个帐户只可访问相应的文件系统的文件和文件夹，而不能访问关键资源如操作系统工具。
     有关为匿名帐户配置 NTFS 权限的更多信息，请参考模块 16 保护 Web 服务器。

     注意 如果您运行 IISLockdown 向导，它将创建一个“Web 匿名用户”组。本组的成员不可访问系统目录和工具。

固定标识模拟

当您需要 IIS 为您的应用程序验证用户身份时（例如，使用集成的 Windows 身份验证或证书验证），您可以使用固定模拟标识来执行 ASP.NET 应用程序。此方案如图 20.4 所示。

图 20.4
应用程序模拟固定帐户并使用此帐户访问资源

可以配置各个 ASP.NET 应用程序来模拟固定帐户。此配置的优点是它可以用于任何 IIS 身份验证方法，而且不要求 IIS 匿名验证。

• 为资源访问使用多个固定模拟帐户

  本过程介绍了如何对资源访问使用多个固定模拟帐户（每个 Web 应用程序一个帐户），以支持各个应用程序授权何审核。

  1. 创建新的匿名用户帐户，每个应用程序一个匿名帐户。
     有关创建匿名用户帐户的更多信息，请参考模块 16 保护 Web 服务器中的“帐户”一节。

     如果需要使用匿名帐户访问远程资源，或者使用最少权限的域帐户，或者使用本地帐户并在远程服务器上创建一个重复的本地帐户，该帐户具有对应的用户名和密码。

  2. 在注册表中存储加密的帐户凭证。
     运行 Aspnet_setreg.exe 以在注册表中存储新帐户的加密凭证。有关更多信息，请参考 Microsoft 知识库文章 329290 How To:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings（英文）。

  3. 针对模拟配置 Web 应用程序。
     可以在 Machine.config 或 Web.config 中进行此配置。要配置具有不同标识的多个应用程序，则需使用 Machine.config 中的 <location> 标记。上一步运行的输出显示 <identity> 元素的用户名、密码属性值所需的格式。以下显示了一些示例。

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

     
     

     要在应用程序级别配置模拟，则需在应用程序的 Web.config 文件中使用 <identity> 元素，如下所示。

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

     
     

  4. 为每个帐户配置 NTFS 权限以确保每个帐户只可访问相应的文件系统的文件和文件夹，而不能访问关键资源，如操作系统工具。
     有关配置 匿名帐户的 NTFS 权限的更多信息，请参考模块 16 保护 Web 服务器。

注意 在 Windows 2000 和 .NET Framework 版本 1.0 上，如果使用以上配置模拟固定标识，则必须为用来运行 Web 应用程序的 ASP.NET 进程帐户授予“作为操作系统的一部分”权限。 这违背了最少权限原则。建议升级到 .NET Framework 版本 1.1，其中并无此要求。

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

如果应用程序在 Windows Server 2003 中运行，则可以使用应用程序池，并将每个应用程序配置为在其自身的提供进程级别隔离的工作进程中运行。默认情况下，所有的应用程序都在默认应用程序池中运行。通过应用程序池，您可以将每个进程配置为使用独立标识运行，结果，您无需使用模拟。

• 提供进程级别的隔离

  1. 创建一组新的 Windows 帐户，使每个应用程序具有一个帐户来运行工作进程实例。

  2. 为每个帐户配置 NTFS 权限，以确保每个帐户仅可访问相应的文件系统的文件和文件夹，而不能访问重要资源，如操作系统工具。

     有关配置匿名帐户 NTFS 权限的更多信息，请参考模块 16 保护 Web 服务器。

  3. 禁用 Web 应用程序模拟。
     可以在 Machine.config 或 Web.config 中执行此操作。要在 Machine.config 中禁用多个应用程序模拟，则需将 <identity> 元素放在 <location> 元素中，如下所示。

     使用以下配置。此配置将不使用模拟。

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

     
     

     注意 ASP.NET 应用程序默认情况下不进行模拟。

  4. 创建新应用程序池，并将其配置为在新帐户下运行。
     使用 IIS 6 采用默认设置创建新应用程序池，并使用步骤 1 中创建的帐户来配置每个池的标识，以使每个池以独立标识运行。

  5. 将每个应用程序配置为在其自身的应用程序池中运行。
     在每个 IIS 应用程序的“目录”选项卡上，选择要在其中运行应用程序的应用程序池。

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

在 .NET Framework 的版本 1.1 中，可以使用<信任>元素使应用程序在部分信任级别运行。以下配置显示了如何从 Machine.config 配置应用程序的信任级别。在此例中，使用了中等信任级别。

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

如果配置应用程序以信任级别而非“完全级别”运行，则应用程序在访问特定类型的资源时具有受限制的代码访问安全权限。采用此方式，可以限制应用程序，以防止应用程序彼此交互，也防止应用程序访问系统级别的资源，如文件系统的限制区域、注册表、事件日志等。

有关 ASP.NET 信任级别、如何使用此级别来提供应用程序隔离已经有关应用程序特定设计和开发注意事项的更多信息，请参考模块 9 ASP.NET 代码访问安全性。

注意 如果使用代码访问安全来提供应用程序隔离，应该还要考虑应用程序的操作系统标识。推荐的隔离模型是将代码访问安全与 Windows Server 2003 上的进程级别隔离一起使用。

表单身份验证问题

如果将表单身份验证与 .NET Framework 的版本 1.0 一起使用，应该使用单独的 cookie 路径和名称。如果不这样做，那么可能一个用户在一个应用程序中通过身份验证后，当他请求访问另一个应用程序时，并不能将其定向到该应用程序的登录页。在第二个应用程序内的 URL 授权规则可能拒绝用户的访问，而不提供使用户使用登录表单输入登录凭证的机会。

为避免此问题，在每个应用程序的<表单>元素中使用唯一的 cookie 路径和名称属性，并对每个应用程序使用单独的计算机密钥。

.NET Framework 的版本 1.1 支持下面显示的 IsolateApps 设置。

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

这确保了计算机上的每个应用程序使用单独的密钥对表单身份验证 cookie 和视图状态进行加密和验证。

在 .NET Framework 的版本 1.0 中，不能使用 IsolateApps 而且必须手动生成<machineKey>元素。有关此问题的更多信息，请参考 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（英文）

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 应用程序，则需考虑如何在应用程序之间和应用程序与共享系统资源（如文件系统、注册表和事件日志）之间进行隔离。没有充分的隔离，rogue 应用程序或开发得不好的应用程序将会对服务器上的其他应用程序造成不利影响。

在 Windows Server 2003 上，使用 IIS 6 支持的多个工作进程模型来提供操作系统进程与应用程序的隔离。在 Windows 2000 上，尽管可以配置多个应用程序使用单独的匿名用户帐户，但是进程隔离是不可能的。 这提供了单独的应用程序审核并支持独立的应用程序验证。

在以上两个平台上，都可以将代码访问安全提供的资源约束模型用作一个附加控制，以限制哪些应用程序可以访问哪些资源类型。将代码访问安全与 ASP.NET 应用程序一起使用时要求使用 .NET Framework 的版本 1.1。

有关确保 ASP.NET 应用程序安全的更多信息，请参考模块 19 确保 ASP.NET 应用程序和 Web 服务的安全。