驻留多个 Web 应用程序
驻留多个 Web 应用程序
本页内容
本模块内容 | |
目标 | |
适用范围 | |
如何使用本模块 | |
简介 | |
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 的应用程序隔离功能
隔离功能 | 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 体系结构显示在图 20.1 中。
图 20.1
在 Windows 2000 和 IIS 5 中的 ASP.NET 体系结构
图 20.1 中所描述的体系结构的组件总结在表 20.2 中。
表 20.2:Windows 2000 ASP.NET 体系结构的组件
组件 | 说明 |
Inetinfo.exe |
主要的 IIS 进程。在本地 SYSTEM 帐户下运行的 Windows 服务。 |
Aspnet_isapi.dll |
IIS 脚本映射与在 Inetinfo.exe 中运行的、具有 ASP.NET ISAPI 扩展名的 ASP.NET 文件类型相关联。它负责通过异步的指定管道向 ASP.NET 工作进程转发请求。它还启动工作进程并执行状态监测。ISAPI 扩展不包含托管代码,自身不执行任何请求进程。 |
Aspnet_filter.dll |
轻量级 ISAPI 筛选器仅用于支持 ASP.NET 应用程序的无 cookie 会话状态。 在 Inetinfo.exe 的内部运行。 |
Aspnet_wp.exe |
ASP.NET 工作进程。在用于提供隔离的独立应用程序域中驻留多个 Web 应用程序。通常每个服务器一个实例,尽管在多处理器服务器上 Web 园模式可以支持与给定处理器具有相近关系的多个相同进程。将特定的 Web 应用程序分成不同的进程是不可能的。这要求 IIS 6 和 Windows Server 2003。Aspnet_wp.exe 在本地 ASPNET 帐户下运行,尽管可以使用自定义帐户。 |
Aspnet_state.exe |
一个可选的 Windows 服务,用来存储 ASP.NET 应用程序的会话状态。它可以在 Web 服务器上运行,也可以在远程计算机(Web 场方案所要求的)上运行。它在本地 ASPNET 帐户下运行,尽管可以使用通过服务管理单元配置的自定义帐户。 |
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 体系结构的组件
组件 | 说明 |
Aspnet_isapi.dll |
将要由托管代码 ASP.NET 引擎处理的请求排队并执行状态监测。 |
Aspnet_filter.dll |
轻量级 ISAPI 筛选器仅用于支持 ASP.NET 应用程序的无 cookie 会话状态。 在内部运行 W3wp.exe。 |
W3wp.exe |
包含托管代码 ASP.NET 处理引擎的 IIS 工作进程。可以使用 IIS 6 应用程序池将 URL 空间在不同的 W3wp.exe 实例之间任意切分。也支持 Web 园模式。请求从以内核模式运行的 Http.sys 直接路由到 W3wp.exe 进程实例。默认情况下,进程在网络服务帐户下运行,但可以对其进行配置。 |
Aspnet_state.exe |
一个可选的 Windows 服务,用来存储 ASP.NET 应用程序的会话状态。它可以在 Web 服务器上运行,也可以在远程计算机(Web 场方案所要求的)上运行。在网络服务帐户下运行,但可以使用服务管理单元进行配置。 |
按标识隔离应用程序
通过控制用于运行每个应用程序的帐户标识,可以将 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 应用程序一个帐户)进行资源访问,以支持单个应用程序授权和审核。
|
固定标识模拟
当您需要 IIS 为您的应用程序验证用户身份时(例如,使用集成的 Windows 身份验证或证书验证),您可以使用固定模拟标识来执行 ASP.NET 应用程序。此方案如图 20.4 所示。
图 20.4
应用程序模拟固定帐户并使用此帐户访问资源
可以配置各个 ASP.NET 应用程序来模拟固定帐户。此配置的优点是它可以用于任何 IIS 身份验证方法,而且不要求 IIS 匿名验证。
• |
为资源访问使用多个固定模拟帐户 本过程介绍了如何对资源访问使用多个固定模拟帐户(每个 Web 应用程序一个帐户),以支持各个应用程序授权何审核。
|
注意 在 Windows 2000 和 .NET Framework 版本 1.0 上,如果使用以上配置模拟固定标识,则必须为用来运行 Web 应用程序的 ASP.NET 进程帐户授予“作为操作系统的一部分”权限。 这违背了最少权限原则。建议升级到 .NET Framework 版本 1.1,其中并无此要求。
使用应用程序池隔离应用程序
如果应用程序在 Windows Server 2003 中运行,则可以使用应用程序池,并将每个应用程序配置为在其自身的提供进程级别隔离的工作进程中运行。默认情况下,所有的应用程序都在默认应用程序池中运行。通过应用程序池,您可以将每个进程配置为使用独立标识运行,结果,您无需使用模拟。
• |
提供进程级别的隔离
|
使用代码访问安全隔离应用程序
在 .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 服务的安全。
posted on 2004-08-10 11:48 LiShijin.Net 阅读(878) 评论(0) 编辑 收藏 举报