在 Intranet 环境中保护 .NET Web 应用程序

ASP.NET 到 SQL Server

ASP.NET 到 Enterprise Services 到 SQL Server

ASP.NET 到 Web Services到SQL Server

ASP.NET到Remoting到SQL Server

客户端上安装了 Internet Explorer。

用户帐户位于 Active Directory 中。

应用程序提供每个用户的机密数据。

只有经过身份验证的客户端能够访问应用程序。

数据库委派该应用程序对用户进行正确的身份验证（即，应用程序代表用户对数据库进行调用）。

Microsoft SQL Server 使用单个数据库用户角色进行授权。

创建自定义 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”）

在此方案中，由于所有用户都使用 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 应用程序中的最终用户活动，或者将用户标识作为数据访问调用的参数明确地进行传递。

基本身份验证和 SSL。.大多数浏览器都支持基本身份验证。由于用户的凭据是通过网络传递的，所以必须使用 SSL 来保证此方案的安全。

客户端证书。.可以将各个客户端证书映射到唯一的 Windows 帐户，或者使用单个 Windows 帐户来代表所有客户端。T使用客户端证书还要求使用 SSL。

表单身份验证。表单身份验证可以根据自定义数据存储（如数据库）或 Active Directory 来验证凭据。

如果根据 Active Directory 进行身份验证，请确保仅检索与应用程序有关的必要的组。正如不应该使用 SELECT * 子句对数据库执行查询一样，不应盲目地从 Active Directory 中检索所有的组。

如果根据数据库进行身份验证，您需要仔细分析 SQL 命令中使用的输入值，以防止 SQL 注入攻击，并且应该在数据库中存储密码哈希值（带有 salt），而不是存储明文密码或加密密码。

有关使用 SQL Server 作为凭据存储和将密码存储在数据库中的详细信息，请参见本指南中的“数据访问安全性”。

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

在 Web 服务器和数据库服务器之间，使用 IPSec 或 SSL 来保护通过网络传递的明文凭据。

如果选择此方法，则需要使用 Kerberos 身份验证（将帐户配置为使用委派）或基本身份验证。

本章后面的“将原调用方传递到数据库”部分讨论了委派方案。

还必须在 ASP.NET 中启用模拟。这意味着使用原调用方的安全性上下文执行本地系统资源访问，因此需要正确地配置本地资源（例如注册表和事件日志）的 ACL。

由于原调用方无法共享连接，因此数据库连接池受到限制。每个连接都与调用方的安全性上下文关联。

另一种传递用户安全性上下文的方法是在应用程序级别传递原调用方的标识（例如，通过使用方法和存储过程参数）。

用户安装了 Internet Explorer。

在 Web 服务器上部署了组件。

应用程序处理机密数据，在传输过程中必须保护这些数据的安全。

业务组件使用 Windows 身份验证连接到 SQL Server。

基于调用方的标识来限制这些组件中的业务功能。

将服务组件配置为服务器应用程序（进程外）。

件使用服务器应用程序的进程标识连接到数据库。

在 ASP.NET 中启用模拟（确保基于 Enterprise Services 角色的安全性）。

创建一个权限最少的数据库帐户（请参见本指南中的“数据访问安全性”）

在 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”）

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 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。

HRDept（人力资源部门的成员） 该组的成员可以检索有关任何雇员的详细信息。

PayrollDept（工资部门的成员） 该组的成员可以检索有关任何雇员的详细信息。

Employees （所有雇员） 该组的成员只能检索他们自己的详细信息。

用户安装了 Internet Explorer 5.x 或更高版本。

所有计算机运行的都是 Windows 2000 或更高版本。

用户帐户位于单一目录林的 Active Directory 中。

应用程序将原调用方的安全性上下文一直传递到数据库。

所有层都使用 Windows 身份验证。

将域用户帐户配置为使用委派。

数据库不支持委派。

在 Web 服务器上配置 SSL（请参见本指南中的“How To Set Up SSL on a Web Server”）

配置 IPSec （请参见本指南中的“How To Use IPSec to Provide Secure Communication Between Two Servers”）

在此方案中，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 浏览器。

远程组件由 ASP.NET 驻留。

Web 应用程序使用 HTTP 通道与远程组件进行通信。

ASP.NET 应用程序调用 .NET 远程组件，并传递原调用方的凭据以进行身份验证。基本身份验证提供了这些功能。

由于数据本身所具有的机密性，必须在进程与计算机之间保证数据的安全。

创建一个权限最少的数据库帐户（请参见本指南中的“数据访问安全性”）

在 Web 服务器上配置 SSL（请参见本指南本指南中的“How To Set Up SSL on a Web Server”）

配置 IPSec（请参见本指南中的“How To Use IPSec to Provide Secure Communication Between Two Servers”）

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 组来匹配那些将要访问该应用程序的用户类别（共享相同的安全权限）。

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

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

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

ASP.NET 到 SQL Server

ASP.NET 到 Enterprise Services到SQL Server

基本身份验证使用弹出式对话框提示用户，用户可以在该对话框中键入凭据（用户名和密码）。

数据库必须识别原调用方。果 Web 服务器和数据库位于不同的域中，则必须启用相应的信任关系以允许数据库对原调用方进行身份验证。

用户安装了 Internet Explorer 5.x 或更高版本。

所有计算机运行的都是 Windows 2000 或更高版本。

用户帐户保存在单一目录林的 Active Directory 中。

应用程序将原调用方的安全性上下文（在操作系统级别）一直传递到数据库。

所有层都使用 Windows 身份验证。

将域用户帐户配置为使用委派，而在 Active Directory 中必须将用来运行 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 身份验证）。

传递原调用方安全性上下文的关键是 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 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。