内容简介

基于 Intranet Web 应用程序的安全性并不是不重要，因为它存在于许多控制网络中，并且对一个限制集合中的用户是可以访问的。不同个体和部门可能需要对应用程序提供的功能和数据有不同的访问等级，所以在传输过程中仍然必须保护机密数据的安全性。为了使问题复杂化，应用程序的安全性结构必须补偿任何安全性相关的问题，这些问题源于存在的基础和要配置应用程序的 Intranet 的操作特点。

通过关注某些常用分布式应用程序结构的要求，本章介绍了基于 Intranet Web 应用程序的身份验证、授权、安全通信的推荐解决方法。

目标

使用本章的目的：

• 保护 Intranet .NET 应用程序
• 理解安全问题和下面方案中推荐的与使用 ASP.NET Web 应用程序和 SQL Server 2000通信相关的解决方案：
• 直接通信
• 使用 Enterprise Services 作为中介
• 使用 Web 服务作为中介
• 使用 .NET Remoting 作为中介
• 在基于 Intranet 分布式 Web 应用程序中决定实现身份验证、授权、安全通信的最好方法。

适用于：

本章适用于下面的产品和技术：

• Microsoft Windows_ XP 或者 Windows 2000 Server (带有 service pack 3) 和更高版本操作系统
• Microsoft Internet Information Services (IIS) 5.0 和更高版本操作系统
• Microsoft Active Directory_ 目录服务
• .NET Framework 1.0 版本(带有 service pack 2) 和更高版本
• SQL Server 2000 (带有 service pack 2) 和更高版本

如何使用本章

为了从本章中获得最大的益处：

• 您必须有开发和配置 ASP.NET、SQL Server、IIS 的经验。
• 您必须有配置 Windows 安全性和 Active Directory 的经验。
• 您必须有配置 Enterprise Services (COM+) 应用程序的经验。
  
• 请参阅本指南中的“构建安全 ASP.NET 应用程序介绍”。这部分定义了分布式 Web 应用程序身份验证、授权、安全通信的重要性。
  
• 请参阅本指南中的“ASP.NET 应用程序安全性模型”。这部分概括阐述在创建分布式 ASP.NET Web 应用程序中使用的结构和技术，并强调身份验证、授权、安全通信适合本结构中的哪些部分。

结合下面的章节使用本章，它们阐明了本章中讨论的技术：

• “How To Create a Custom Account to Run ASP.NET”。
• “How To Implement Kerberos Delegation for Windows 2000”。
• “How To Create a DPAPI Library”。
• “How To Use DPAPI (Machine Store) from ASP.NET”。
• “How To Use DPAPI (User Store) from ASP.NET with Enterprise Services”。
• “How To Use Role-based Security with Enterprise Services”。
• “How To Set Up SSL on a Web Server”。
• “How To Use IPSec to Provide Secure Communication Between Two Servers”。
• “How To Use SSL to Secure Communication with SQL Server 2000”。

本页内容

• 预备知识
• ASP.NET 到 SQL Server
• ASP.NET 到 Enterprise Services 到 SQL Server
• ASP.NET 到 Web Services 到 SQL Server
• ASP.NET 到 Remoting 到 SQL Server
• 将原调用方传递到数据库
• 小结

预备知识

对 Intranet 应用程序的访问被限制到一组有限的授权用户（例如，属于某个域的雇员）。虽然 Intranet 设置限制了应用程序的公开，但是当您制定身份验证、授权和安全通信策略时，可能仍要面临一些难题。例如，您可能包含非信任域，因此很难将调用方的安全性上下文和标识传递到系统内的后端资源。另外，您的运行环境可能是具有混合浏览器类型的异类环境。因此，更加不便使用通用身份验证机制。

如果同类 Intranet 中的所有计算机均运行 Microsoft Windows 2000 或更高版本的操作系统，并且在域中信任用户使用委派，则可以选择将原调用方的安全性上下文委派到后端。

您还必须考虑安全通信问题。尽管您的应用程序运行在 Intranet 环境中，也不能认为在网络中传送的数据是安全的。除了需要保护应用程序服务器和数据库之间传送的数据外，可能还需要保护浏览器和 Web 服务器之间传送的数据。

本章使用以下常见的 Intranet 方案来阐释主要的身份验证、授权和安全通信技术：

• ASP.NET 到 SQL Server
• ASP.NET 到 Enterprise Services 到 SQL Server
• ASP.NET 到 Web Services到SQL Server
• ASP.NET到Remoting到SQL Server

此外，本章还介绍了一个 Windows 2000 委派方案（“将原调用方传递到数据库”）。在此方案中，使用中间 Web 服务器和应用程序服务器，在操作系统级别将原调用方的安全性上下文和标识从浏览器传递到数据库。

注本章中描述的几个方案或者替换用于运行 ASP.NET 应用程序的默认 ASPNET 帐户，或者更改其密码以允许在远程计算机上创建重复的帐户。这些方案要求更新 Machine.config 中的 <processModel> 元素。<processModel> 凭据不应该以明文形式存储在 machine.config 中。而应该使用 aspnet_setreg.exe 工具以加密凭据的形式存储在注册表中。有关详细信息请参见本指南中的“ASP.NET安全性”和 Microsoft 知识库文章 Q329290 “HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings”（如何做：使用 ASP.NET 工具加密凭证和会话状态链接字符串）。

ASP.NET 到 SQL Server

在此方案中，人力资源数据库在同类 Intranet 中安全地提供每个用户的数据。应用程序使用受信任的子系统模型并代表原调用方执行调用。应用程序使用集成 Windows 身份验证来验证调用方的身份，并使用 ASP.NET 进程标识来调用数据库。由于数据本身所具有的机密性，因此，在 Web 服务器和客户端之间使用了 SSL。

图 1 显示此应用程序方案的基本模型。

图 1. ASP.NET 到 SQL Server

特点

本方案具有以下特点：

• 客户端上安装了 Internet Explorer。
• 用户帐户位于 Active Directory 中。
• 应用程序提供每个用户的机密数据。
• 只有经过身份验证的客户端能够访问应用程序。
• 数据库委派该应用程序对用户进行正确的身份验证（即，应用程序代表用户对数据库进行调用）。
• Microsoft SQL Server 使用单个数据库用户角色进行授权。

保护方案

在此方案中，Web 服务器验证调用方的身份，并通过使用调用方的标识限制对本地资源的访问。要限制原调用方对资源的访问，您不必在 Web 应用程序中进行模拟。数据库验证 ASP.NET 默认进程标识（它是权限最少的帐户）的身份（即数据库信任 ASP.NET 应用程序）。

表 1:安全措施

结果

图 2 显示了此方案的建议安全配置。

图 2. ASP.NET 到 SQL Server Intranet 方案的建议安全配置

安全配置步骤

在开始之前，您需要查看以下内容：

• 创建自定义 ASP.NET 帐户（请参见本指南中的“How To Create a Custom Account to Run ASP.NET”）
• 创建一个权限最少的数据库帐户（请参见本指南中的“数据访问安全性”）
• 在 Web 服务器上配置 SSL（请参见本指南中的“How To Set Up SSL on a Web Server”）
• 配置 IPSec（请参见本指南中的“How To Use IPSec to Provide Secure Communication Between Two Servers”）

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

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

分析

• 在此方案中，由于所有用户都使用 Windows 帐户并且使用的是 Microsoft Internet Explorer，所以在 IIS 中最好使用集成 Windows 身份验证。集成 Windows 身份验证的优点是从不通过网络传送用户的密码。此外，由于 Windows 使用当前交互式用户的登录会话，所以对于用户来说登录是透明的。
• ASP.NET 作为权限最少的帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。
• 要执行 .NET 角色检查或在 Windows ACL 中针对原调用方保证资源的安全，您不必在 ASP.NET 中进行模拟。为了对原调用方执行 .NET 角色检查，按如下所示从 HTTP 上下文中检索代表原调用方的 WindowsPrincipal 对象：
  WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
  if ( wp.IsInRole("Manager") )
  {
  // User is authorized to perform manager-specific functionality
  }
  ASP.NET FileAuthorizationModule 针对原调用方在 ACL 中检查在 IIS 中映射到 aspnet_isapi.dll 的 ASP.NET 文件类型。对于静态文件类型（例如 .jpg、.gif 和 .htm 文件），IIS 充当关守，它根据文件的相关 NTFS 权限，使用原调用方的标识执行访问检查。
• 对 SQL Server 使用 Windows 身份验证意味着，不必将凭据存储在文件中并通过网络将凭据传递到数据库服务器。
• 在数据库服务器上使用重复的 Windows 帐户（与 ASP.NET 本地帐户匹配的帐户）会导致增加管理负担。如果一台计算机上的密码有改动，则必须在其他计算机上同步并更新它。在某些方案中，您可能能够使用权限最少的域帐户进行更简单的管理。
• 当设置防火墙时（此时 Windows 身份验证所需的端口可能没有打开），重复的本地帐户方法同样有效。在此方案中可能无法使用 Windows 身份验证和域帐户。
• 您需要确保 Windows 组的粒度与您的安全要求一样。由于基于 .NET 角色的安全性以 Windows 组成员身份为基础，所以此解决方案依赖于以正确的粒度设置 Windows 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。这里用来管理角色的 Windows 组可以是此计算机的本地组或域组。
• SQL Server 数据库用户角色优先于 SQL Server 应用程序角色，这样可以避免与使用 SQL 应用程序角色有关的密码管理和连接池问题。

应用程序通过用角色名和密码调用内置的存储过程，来激活 SQL 应用程序角色。因此，必须安全地存储密码。当使用 SQL 应用程序角色时，还必须禁用数据库连接池，因为它会严重影响应用程序的可伸缩性。

有关 SQL Server 数据库用户角色和 SQL Server 应用程序角色的详细信息，请参见本指南中的“数据访问安全性”。

• 将数据库用户添加到数据库用户角色中，并且为角色指定了权限，因此，当数据库帐户更改时，您不必更改所有数据库对象的权限。

问与答

• 为什么我不能启用 Web 应用程序模拟，以便使用配置的 ACL 针对原调用方来保护 Web 应用程序所访问的资源？
  如果启用模拟，则模拟的安全性上下文不具有网络凭据（假定未启用委派并且您使用的是集成 Windows 身份验证）。因此，对 SQL Server 的远程调用将使用 NULL 会话，而这将会导致调用失败。如果禁用模拟，则远程请求使用 ASP.NET 进程标识。
  上述方案使用 ASP.NET FileAuthorizationModule，它使用 Windows ACL 针对原调用方标识执行授权，并且不要求进行模拟。
  如果您使用基本身份验证而不是集成 Windows 身份验证 (NTLM)，并且确实启用了模拟，则每个数据库调用都将使用原调用方的安全性上下文。每个用户帐户（或用户所属的 Windows 组）都要求使用 SQL Server 登录。需要限制 Windows 组（或原调用方）访问数据库对象的权限以确保安全性。
• 数据库不知道谁是原始调用方。我如何能创建一条审核记录？
  审核 Web 应用程序中的最终用户活动，或者将用户标识作为数据访问调用的参数明确地进行传递。

相关方案

非 Internet Explorer 浏览器

对 IIS 执行集成 Windows 身份验证需要使用 Internet Explorer。在混合浏览器环境中，您的典型选项包括：

• 基本身份验证和 SSL。.大多数浏览器都支持基本身份验证。由于用户的凭据是通过网络传递的，所以必须使用 SSL 来保证此方案的安全。
• 客户端证书。.可以将各个客户端证书映射到唯一的 Windows 帐户，或者使用单个 Windows 帐户来代表所有客户端。T使用客户端证书还要求使用 SSL。
• 表单身份验证。表单身份验证可以根据自定义数据存储（如数据库）或 Active Directory 来验证凭据。
  如果根据 Active Directory 进行身份验证，请确保仅检索与应用程序有关的必要的组。正如不应该使用 SELECT * 子句对数据库执行查询一样，不应盲目地从 Active Directory 中检索所有的组。
  如果根据数据库进行身份验证，您需要仔细分析 SQL 命令中使用的输入值，以防止 SQL 注入攻击，并且应该在数据库中存储密码哈希值（带有 salt），而不是存储明文密码或加密密码。
  有关使用 SQL Server 作为凭据存储和将密码存储在数据库中的详细信息，请参见本指南中的“数据访问安全性”。
  注意，在所有情况中，如果您没有使用集成 Windows 身份验证（其中，由平台为您管理凭据），则最后将使用 SSL。不过，此优点仅限于身份验证过程。如果您通过网络传递安全机密数据，则仍须使用 IPSec 或 SSL。

对数据库的 SQL 身份验证

在有些方案中，您可能必须使数据访问安全性而不是首选的 Windows 身份验证。例如，在 Web 应用程序和数据库之间可能设置了防火墙，或者由于安全原因，Web 服务器可能不属于您所在的域。这也会妨碍 Windows 身份验证。这种情况下，您可以在数据库和 Web 服务器之间使用 SQL 身份验证。为保证此方案的安全，您应该：

使用数据保护 API (DPAPI) 来保护包含用户名和密码的数据库连接字符串。有关详细信息，请参阅以下内容：

• 请参见本指南中的“数据访问安全性”中的“安全存储数据库连接字符串”。
  • "How To Use DPAPI (Machine Store) from ASP.NET"
  • "How To Use DPAPI (User Store) from ASP.NET with Enterprise Services"
  • "How To Create a DPAPI Library"
• 在 Web 服务器和数据库服务器之间，使用 IPSec 或 SSL 来保护通过网络传递的明文凭据。

将原调用方传递到数据库

在此方案中，使用原调用方的安全性上下文从 Web 应用程序调用数据库。使用此方法时，一定要注意以下几点：

• 如果选择此方法，则需要使用 Kerberos 身份验证（将帐户配置为使用委派）或基本身份验证。
  本章后面的“将原调用方传递到数据库”部分讨论了委派方案。
• 还必须在 ASP.NET 中启用模拟。这意味着使用原调用方的安全性上下文执行本地系统资源访问，因此需要正确地配置本地资源（例如注册表和事件日志）的 ACL。
• 由于原调用方无法共享连接，因此数据库连接池受到限制。每个连接都与调用方的安全性上下文关联。
• 另一种传递用户安全性上下文的方法是在应用程序级别传递原调用方的标识（例如，通过使用方法和存储过程参数）。

ASP.NET 到 Enterprise Services 到 SQL Server

在此方案中，ASP.NET 页面调用 Enterprise Services 应用程序中驻留的业务组件，而 Enterprise Services 应用程序又连接到数据库上。例如，请看一个内部定单系统，它通过 Intranet 进行交易并允许内部部门下定单。图 3 中显示了此方案。

图 3. ASP.NET 会在 Enterprise Services 中调用一个组件，该组件将调用该数据库

特点

本方案具有以下特点：

• 用户安装了 Internet Explorer。
• 在 Web 服务器上部署了组件。
• 应用程序处理机密数据，在传输过程中必须保护这些数据的安全。
• 业务组件使用 Windows 身份验证连接到 SQL Server。
• 基于调用方的标识来限制这些组件中的业务功能。
• 将服务组件配置为服务器应用程序（进程外）。
• 件使用服务器应用程序的进程标识连接到数据库。
• 在 ASP.NET 中启用模拟（确保基于 Enterprise Services 角色的安全性）。

保护方案

在此方案中，Web 服务器验证原调用方的身份，并将调用方的安全性上下文传递到服务组件。服务组件基于原调用方的标识授予业务功能的访问权限。数据库根据 Enterprise Service 应用程序的进程标识进行身份验证（即数据库信任 Enterprise Services 应用程序中的服务组件）。当服务组件调用数据库时，它在应用程序级别传递用户的标识（通过使用受信任的查询参数）。

结果

图 4 显示了此方案的建议安全配置。

安全配置步骤

在开始之前，您需要查看以下内容：

• 创建一个权限最少的数据库帐户（请参见本指南中的“数据访问安全性”）
• 在 Web 服务器上配置 SSL（请参见本指南中的“How To Set Up SSL on a Web Server”）
• Configuring IPSec (see the module, "How To Use IPSec to Provide Secure Communication Between Two Servers")
• 配置 IPSec（请参见本指南中的“How To: Use Role-Based Security with Enterprise Services”）

< comImpersonationLevel="Impersonate"> 

[assembly: ApplicationActivation(ActivationOption.Server)] 

分析

• ASP.NET 和 Enterprise Services 作为权限最少的帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。当任何一方的进程标识遭到攻击时，由于帐户仅具有有限的权限，因此缩小了危害的范围。另外，在 ASP.NET 中，如果注入了恶意脚本，也可以限制潜在的危害。
• 要将原调用方的安全性上下文传递到 Enterprise Services 组件（以支持基于 Enterprise Services (COM+) 角色的授权），必须配置 ASP.NET 应用程序以支持模拟。如果不进行模拟，则对进程标识（即 ASP.NET 辅助进程）进行角色检查。模拟影响被授予资源访问权限的对象。
• 在未进行模拟时，针对 ASP.NET 进程标识进行系统资源检查。在进行模拟时，针对原调用方进行系统资源检查。有关从 ASP.NET 访问系统资源的详细信息，请参见本指南中的“ASP.NET安全性”。
• 通过使用 Enterprise Services (COM+) 角色，将访问检查推到中间层（业务逻辑所在的位置）进行。在这种情况下，在入口处检查调用方，将其映射到角色，以及基于角色调用业务逻辑。这可避免不必要的后端调用。Enterprise Services (COM+) 角色的另一优点是：可以在部署时使用组件服务管理器创建和管理角色。
• 对 SQL 的 Windows 身份验证意味着，可以避免在文件中存储凭据并通过网络进行传送。
• 当设置了防火墙时（此时 Windows 身份验证所需的端口可能没有打开），仍然可以使用本地帐户运行 Enterprise Services 应用程序，以及在数据库服务器上使用重复的帐户。在此方案中可能无法使用 Windows 身份验证和域帐户。

缺陷

• 在数据库服务器上使用重复的 Windows 帐户（与 Enterprise Services 进程帐户匹配的帐户）会导致增大管理负担。密码应当定期手动更新并同步。
• 由于基于 .NET 角色的安全性以 Windows 组成员身份为基础，此解决方案依赖于以正确的粒度设置 Windows 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。

ASP.NET 到 Web Services 到 SQL Server

在此方案中，运行 ASP.NET 页的 Web 服务器连接到远程服务器上的 Web 服务。该服务器又连接到远程数据库服务器。例如，请看一个提供用户特定机密数据的人力资源 Web 应用程序。此应用程序依赖 Web 服务进行数据检索。图 5 显示了此应用程序方案的基本模型。

Web 服务公开一个允许个别雇员检索他或她的个人详细信息的方法。必须使用 Web 应用程序只给通过身份验证的个人提供详细信息。 Web 服务还提供了一个支持任何雇员详细信息检索的方法。只有人力资源或工资部门的成员可以使用此功能。在此方案中，将雇员分为三个 Windows 组：

• HRDept（人力资源部门的成员） 该组的成员可以检索有关任何雇员的详细信息。
• PayrollDept（工资部门的成员） 该组的成员可以检索有关任何雇员的详细信息。
• Employees （所有雇员） 该组的成员只能检索他们自己的详细信息。

由于数据本身所具有的保密性，应保证所有节点之间通信的安全。

特点

• 用户安装了 Internet Explorer 5.x 或更高版本。
• 所有计算机运行的都是 Windows 2000 或更高版本。
• 用户帐户位于单一目录林的 Active Directory 中。
• 应用程序将原调用方的安全性上下文一直传递到数据库。
• 所有层都使用 Windows 身份验证。
• 将域用户帐户配置为使用委派。
• 数据库不支持委派。

在此方案中，驻留 ASP.NET Web 应用程序的 Web 服务器验证原调用方的标识，并将它们的安全性上下文传递到驻留 Web 服务的远程服务器。这样就可以对 Web 方法应用授权检查，以允许或拒绝对原调用方的访问。数据库验证 Web 服务进程标识的身份（数据库信任 Web 服务）。Web 服务反过来调用数据库，并使用存储过程参数在应用程序级别传递用户的标识。

结果

图 6 显示了此方案的建议安全配置。

安全配置步骤

在开始之前，您需要查看以下内容：

• 在 Web 服务器上配置 SSL（请参见本指南中的“How To Set Up SSL on a Web Server”）
• 配置 IPSec （请参见本指南中的“How To Use IPSec to Provide Secure Communication Between Two Servers”）

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

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

分析

• 在此方案中，IIS 中的集成 Windows 身份验证是理想的选择。这是因为，所有用户都使用 Windows 2000 或更高版本、Internet Explorer 5.x 或更高版本，并且都使用 Active Directory 帐户，因此具备了使用 Kerberos 身份验证协议（其支持委派）的条件。T这样，您就可以跨计算机边界传递用户的安全性上下文。
• 在 Active Directory 中，不能将最终用户帐户标记为“敏感，不能被委派”。在 Active Directory 中，必须将 Web 服务器计算机帐户标记为“可以委派其他帐户”。有关详细信息，请参见本指南中的“How To Implement Kerberos Delegation for Windows 2000”。
• Web 服务器和应用程序服务器上的 ASP.NET 作为权限最少的本地帐户（本地 ASPNET 帐户）运行，这样一旦遭到攻击，潜在危害被大大降低。
• 将 Web 服务和 Web 应用程序配置为使用 Windows 身份验证。将两台计算机上的 IIS 配置为使用集成 Windows 身份验证。
• 当从 Web 应用程序调用 Web 服务时，默认情况下不传递凭据。要响应下游 Web 服务器上 IIS 发出的网络身份验证质询，必须使用凭据。必须使用以下方法设置 Web 服务代理的 Credentials 属性以明确地指定这一点：

  wsproxy.Credentials = CredentialCache.DefaultCredentials; 
  

  有关使用凭据调用 Web 服务的详细信息，请参见本指南中的“Web 服务安全性”。

• 将 Web 应用程序配置为使用模拟。因此，在从 Web 应用程序调用 Web 服务时，就会传递原调用方的安全性上下文，并且允许 Web 服务对原调用方进行身份验证（和授权）。
• 在 Web 服务中使用 .NET 角色，基于用户所属的 Windows 组（HRDept、PayrollDept 和 Employees）对用户进行授权。 HRDept 和 PayrollDept 的成员可以检索任何雇员的雇员详细信息，而 Employees 组的成员仅有权检索他们自己的详细信息。

  可以使用 PrincipalPermissionAttribute 类在 Web 方法中加上注释，以查询特定的角色成员身份，如以下代码示例所示。注意，可以用 B>PrincipalPermission 代替 PrincipalPermissionAttribute。这是所有 .NET 属性类型的共同特性。

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

  上述代码中显示的属性表示，只允许 DomainName\HRDept Windows 组的成员调用 RetrieveEmployeeDetails 方法。如果任何非成员试图调用此方法，就会发生安全异常。

• ASP.NET 文件授权（在 Web 应用程序和 Web 服务中）针对调用方在 ACL 中检查在 IIS 元数据库中是否将任何文件类型映射到 Aspnet_isapi.dll。IIS 检查不存在 ISAPI 映射的静态文件类型（例如 .jpg、.gif、.htm 等），同样使用的是附加到文件中的 ACL。
• 因为将 Web 应用程序配置为使用模拟，所以必须用 ACL 来配置应用程序本身所访问的资源，以便给原调用方至少授予读取权限。
• Web 服务不使用模拟或委派；因此，它使用 ASP.NET 进程标识来访问本地系统资源和数据库。因此，所有调用都是使用单个进程帐户完成的。因此，可以使用数据库连接池。如果数据库不支持委派（例如 SQL Server 7.0 或更低版本），则最好选择此方案。
• 对 SQL Server 进行的 Windows 身份验证意味着不必在 Web 服务器上存储凭据，也意味着不必通过网络将凭据发送到 SQL Server 计算机。
• 原调用方和 Web 服务器之间的 SSL 保护传递到和来自 Web 应用程序的数据。
• 下游 Web 服务器和数据库之间的 IPSec 保护传递到和来自数据库的数据。

缺陷

• 在数据库服务器上使用重复的 Windows 帐户（与 ASP.NET 进程帐户匹配的帐户）会导致增大管理负担。密码应当定期手动更新并同步。

  另一种方法是，考虑使用权限最少的域帐户。有关选择 ASP.NET 进程标识的详细信息，请参见本指南中的“ASP.NET 安全性”。

• 因为基于 .NET 角色的安全性以 Windows 组成员为基础，所以此解决方案需要根据相应层次的 Windows 组来匹配那些将要访问该应用程序的用户类别（共享相同的安全权限）。
• Kerberos 委派是不受限制的，因此必须严格控制在 Web 服务器上运行的应用程序标识。为了提高安全门槛，应从 Domain Users 组中删除域帐户以限制域帐户的访问范围，并且只从相应的计算机提供访问。有关详细信息，请参见 Microsoft Web 网站 http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp 上的“Default Access Control Settings”（默认访问控制设置）白皮书。

问与答

数据库不知道谁是原始调用方。我如何能创建一条审核记录？

审核 Web 服务中的最终用户活动，或者将用户的标识作为数据访问调用的参数明确地进行传递。

相关方案

如果您需要连接到非 SQL Server 数据库，或者目前使用的是 SQL 身份验证，则必须使用连接字符串明确地传递数据库帐户凭据。如果您这样做，请确保安全地存储连接字符串。

有关详细信息，请参见本指南中的“数据访问安全性”中的“安全存储连接字符串”。

ASP.NET 到 Remoting 到 SQL Server

在此方案中，运行 ASP.NET 页的 Web 服务器安全地连接到远程应用程序服务器上的远程组件。Web 服务器通过使用 .NET Remoting 在 HTTP 通道上与该组件进行通信。远程组件由 ASP.NET 驻留。图 7 显示了此方案。

特点

• 用户使用不同类型的 Web 浏览器。
• 远程组件由 ASP.NET 驻留。
• Web 应用程序使用 HTTP 通道与远程组件进行通信。
• ASP.NET 应用程序调用 .NET 远程组件，并传递原调用方的凭据以进行身份验证。基本身份验证提供了这些功能。
• 由于数据本身所具有的机密性，必须在进程与计算机之间保证数据的安全。

保护方案

在此方案中，驻留 ASP.NET Web 应用程序的 Web 服务器验证原调用方的身份。Web 应用程序可以从 HTTP 服务器变量中检索调用方的身份验证凭据（用户名和密码）。然后，Web 应用程序通过配置远程组件代理，使用这些凭据连接到驻留远程组件的应用程序服务器。数据库使用 Windows 身份验证来验证 ASP.NET 进程标识的身份（即，数据库信任远程组件）。远程组件反过来调用数据库，并使用存储过程参数在应用程序级别传递原调用方的标识。

结果

图 8 显示了此方案的建议安全配置。

安全配置步骤

在开始之前，您需要查看以下内容：

• 创建一个权限最少的数据库帐户（请参见本指南中的“数据访问安全性”）
• 在 Web 服务器上配置 SSL（请参见本指南本指南中的“How To Set Up SSL on a Web Server”）
• 配置 IPSec（请参见本指南中的“How To Use IPSec to Provide Secure Communication Between Two Servers”）

配置应用程序服务器

<!-- 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" /> 

分析

• Web 服务器和应用程序服务器上的 ASP.NET 作为权限最少的本地帐户运行，因此一旦遭到攻击，潜在危害被大大降低。这两种情况下，均使用默认的 ASPNET 帐户。

  使用 ASPNET 本地帐户（在 SQL Server 计算机上具有重复的帐户）可进一步降低潜在的安全风险。数据库服务器上的重复 Windows 帐户允许在应用程序服务器上使用权限最少的 ASP.NET 帐户来运行远程组件。

• 在 Web 服务器上，基本身份验证允许 Web 应用程序使用用户的凭据响应来自应用程序服务器的 Windows 身份验证质询。

  为使用调用方的凭据来调用远程组件，Web 应用程序按如下所示的代码段来配置远程组件代理。

  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; 
  

  有关将安全凭据传递到远程组件的详细信息，请参见本指南中的“.NET Remoting安全性”。

• 在 ASP.NET Web 应用程序中禁止使用模拟，因为远程处理代理是使用基本身份验证获取的用户凭据专门配置的。 Web 应用程序所访问的任何其他资源均使用 ASP.NET 进程帐户提供的安全性上下文。
• 用户和 Web 服务器之间的 SSL 保护传递到或来自 Web 服务器的数据，并且还保护在身份验证过程中以明文传递的基本凭据。
• 在应用程序服务器上，集成 Windows 身份验证提供对原调用方的 .NET 角色检查。角色对应于 Windows 组。

  即使没有模拟，也可以执行基于角色的检查。

• ASP.NET 文件授权针对调用方在 ACL 中检查在 IIS 元数据库中是否将任何文件类型映射到 aspnet_isapi.dll。IIS 对静态文件（在 IIS 中没有映射到 ISAPI 扩展）执行访问检查。
• 因为在应用程序服务器上没有启用模拟，所以远程组件执行的任何本地或远程资源访问均使用 ASPNET 安全性上下文。应该相应地设置 ACL。
• 对 SQL Server 进行的 Windows 身份验证意味着不必在应用程序服务器上存储凭据，也意味着不必通过网络将凭据发送到 SQL Server 计算机。

缺陷

• 在数据库服务器上使用重复的 Windows 帐户（与 ASP.NET 进程帐户匹配的帐户）会导致增大管理负担。密码应当定期手动更新并同步。
• 因为基于 .NET 角色的安全性以 Windows 组成员为基础，所以此解决方案需要根据相应层次的 Windows 组来匹配那些将要访问该应用程序的用户类别（共享相同的安全权限）。

相关方案

Web 服务器使用 Kerberos 来验证调用方的身份。使用 Kerberos 委派将原调用方的安全性上下文传递到应用程序服务器上的远程组件。

此方法要求将所有用户帐户配置为使用委派。还将 Web 应用程序配置为使用模拟，并且 Web 应用程序使用 DefaultCredentials 来配置远程组件代理。本指南中的“.NET Remoting安全性”中的“传送原调用方”部分深入讨论了这种技术。

将原调用方传递到数据库

前面讨论的方案使用了受信任的子系统模型，并且在所有情况下，数据库都信任应用程序服务器或 Web 服务器以便正确地对用户进行身份验证和授权。虽然受信任的子系统模型具有许多优点，但是某些方案（多半是出于审核原因）可能要求您使用模拟/委派模型，并且跨计算机边界将原调用方的安全性上下文一直传递到数据库。

需要将原调用方传递到数据库的典型原因包括：

• 您需要细分数据库访问，并且权限受对象限制。特定的用户或组可以读取个别对象，而其他用户或组可以写入个别对象。

  这与没有细分且基于任务的授权正好相反，后者由角色成员身份决定特定对象的读写能力。

• 您可能需要使用平台的审核功能，而不是在应用程序级别传递标识和执行审核。

如果您确实选择了模拟/委派模型（或者由于公司的安全策略而必须这样做），并将原调用方的上下文通过应用程序层传递到后端，则在设计时必须考虑委派和网络访问问题（在跨多台计算机时，这个问题很重要）。共享资源池（如数据库连接）也是一个关键的问题，它可能会显著降低应用程序的伸缩性。

这部分说明如何为两个最常见的应用方案实现模拟/委派：

• ASP.NET 到 SQL Server
• ASP.NET 到 Enterprise Services到SQL Server

有关受信任的子系统模型和模拟/委派模型及其相对优点的详细信息，请参见本指南中的“身份验证和授权设计”。

ASP.NET 到 SQL Server

在此方案中，使用原调用方的安全性上下文来调用数据库。这部分描述的身份验证选项包括基本身份验证和集成 Windows 身份验证。“ASP.NET 到 Enterprise Services 到 SQL Server”部分描述了 Kerberos 委派方案。

在 Web 服务器上使用基本身份验证

以下基本身份验证配置设置允许将原调用方一直传递到数据库。

在此方法中，一定要注意以下几点：

• 基本身份验证使用弹出式对话框提示用户，用户可以在该对话框中键入凭据（用户名和密码）。
• 数据库必须识别原调用方。果 Web 服务器和数据库位于不同的域中，则必须启用相应的信任关系以允许数据库对原调用方进行身份验证。

在 Web 服务器上使用集成 Windows 身份验证

集成 Windows 身份验证导致 NTLM 或 Kerberos 身份验证，具体情况取决于客户机和服务器计算机的配置。

NTLM 身份验证不支持委派，因此不允许将原调用方的安全性上下文从 Web 服务器传递到物理上的远程数据库。在浏览器和 Web 服务器之间使用单个网络中继点以便进行 NTLM 身份验证。要使用 NTLM 身份验证，必须在 Web 服务器上安装 SQL Server，这可能仅适用于很小的 Intranet 应用程序。

ASP.NET到 Enterprise Services 到 SQL Server

在此方案中，ASP.NET 页调用远程 Enterprise Services 应用程序中驻留的业务组件，而这些组件又连接到数据库上。原调用方的安全性上下文从浏览器一直传递到数据库。图 9 中显示了这种情况。

特点

• 用户安装了 Internet Explorer 5.x 或更高版本。
• 所有计算机运行的都是 Windows 2000 或更高版本。
• 用户帐户保存在单一目录林的 Active Directory 中。
• 应用程序将原调用方的安全性上下文（在操作系统级别）一直传递到数据库。
• 所有层都使用 Windows 身份验证。
• 将域用户帐户配置为使用委派，而在 Active Directory 中必须将用来运行 Enterprise Services 应用程序的帐户标记为“可以委派其他帐户”。

保护方案

在此方案中，Web 服务器验证调用方的身份。然后，您必须将 ASP.NET 配置为使用模拟，以便将原调用方的安全性上下文传递到远程 Enterprise Services 应用程序。在 Enterprise Services 应用程序中，组件代码必须明确地模拟调用方（使用 CoImpersonateClient），确保将调用方的上下文传递到数据库。

结果

图 10 显示了此方案的建议安全配置。

图 10. ASP.NET 调用 Enterprise Services 中的一个组件，该组件调用数据库。原调用方的安全性上下文传递到数据库。

安全配置步骤

在开始之前，应注意以下配置问题：

• 在 Active Directory 中，必须将 Enterprise Services 进程帐户标记为“可以委派其他帐户”，不能将最终用户帐户标记为“敏感，不能委派”。有关详细信息，请参见本指南中的“How To: Implement Kerberos Delegation for Windows 2000”。
• 所有计算机都要求安装 Windows 2000 或更高版本。这包括客户端（浏览器）计算机和所有服务器。
• 所有计算机都必须在 Active Directory 中，并且必须属于单个目录林。
• 驻留 Enterprise Services 的应用程序服务器必须运行 Windows 2000 SP3。
• 如果在 Windows 2000 上使用 Internet Explorer 6.0，则它默认使用 NTLM 身份验证，而不是所需的 Kerberos 身份验证。要启用 Kerberos 委派，请参见 Microsoft 知识库文章 Q299838 “Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6” （在升级到 Internet Explorer 6 之后，无法协商 Kerberos 身份验证）。

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)] 
Decorate classes with the following attribute: 
[ComponentAccessControl(true)] 

分析

• 传递原调用方安全性上下文的关键是 Kerberos 身份验证（它生成委派级别令牌）。当服务器进程 (IIS) 收到委派级别令牌后，它可以将该令牌传递到在同一台计算机上使用某个帐户运行的任何其他进程，而无需更改它的委派级别。是使用本地帐户还是域帐户运行辅助进程都无关紧要。重要的是 IIS 的运行方式。如果它不是使用 LocalSystem 帐户运行的，则需要在 Active Directory 中将运行它的帐户标记为“可以委派其他帐户”。

  如果 IIS 是使用 LocalSystem 帐户运行的，则必须将计算机帐户标记为“可以委派其他帐户”。有关详细信息，请参见本指南中的“How To Implement Kerberos Delegation for Windows 2000”。

• 在此方案中，由于所有用户都使用 Windows 帐户并且使用的是 Internet Explorer 5.x 或更高版本，所以在 IIS 中最好使用集成 Windows 身份验证（带 Kerberos）。集成 Windows 身份验证的优点是从不通过网络发送用户的密码。另外，登录是透明的，因为 Windows 使用当前交互用户的登录会话。
• ASP.NET 构造一个 WindowsPrincipal 对象，并将它附加到当前的 Web 请求上下文 (HttpContext.User)。如果您需要在 Web 应用程序中执行授权检查，则可以使用下面的代码。

  WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal); 
  if ( wp.IsInRole("Manager") ) 
  { 
    // User is authorized to perform manager-specific functionality 
  } 
  

  ASP.NET FileAuthorizationModule 针对原调用方在 ACL 中检查在 IIS 中映射到 Aspnet_isapi.dll 的 ASP.NET 文件类型。对于静态文件类型（例如 .jpg、.gif 和 .htm 文件），IIS 充当关守，它使用原调用方的标识执行访问检查。

• 过对 SQL 使用 Windows 身份验证，可以避免在应用程序服务器的文件中存储凭据，也可以避免通过网络传递它们。例如，在连接字符串中包含 Trusted_Connection 属性：

  ConStr="server=YourServer; database=yourdatabase; Trusted_Connection=Yes;" 
  

• 经过所有层传递原调用方的上下文，这使审核变得非常容易。可以使用平台级审核（例如，Windows 和 SQL Server 提供的审核功能）。

缺陷

• 如果在 Windows 2000 上使用 Internet Explorer 6.0，则协商的默认身份验证机制是 NTLM（而不是 Kerberos）。有关详细信息，请参见 Microsoft 知识库文章 Q299838 “Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6” （在升级到 Internet Explorer 6 之后，无法协商 Kerberos 身份验证）。
• 与使用受信任的子系统模型相比，跨层委派用户在性能和应用程序伸缩性方面费用很高。您无法利用数据库连接池的优点，因为数据库连接与原调用方的安全性上下文绑定在一起，因此无法有效地进行池处理。
• 此方法也依赖于符合应用程序安全需要的 Windows 组粒度。也就是说，必须在正确的粒度级别设置 Windows 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。

小结

本章介绍了如何保护一套常见的 Intranet 应用程序方案。

有关 Extranet 和 Internet 应用程序方案，请参见本指南中的“在 Extranet 环境中保护 .NET Web 应用程序 ”和“在 Internet 环境中保护 .NET Web 应用程序 ”。