第 5 章 –Intranet 安全性

保护 Intranet .NET 应用程序的安全。

了解在下列方案中使用 ASP.NET Web 应用程序与 SQL Server 2000 通信时可能存在的安全问题以及建议使用的解决方案：

确定在基于 Intranet 的分布式 Web 应用程序中实现身份验证、授权和安全通信的最佳方法。

Windows XP 或 Windows 2000 Server (Service Pack 3) 以及更高版本的操作系统

Microsoft Internet 信息服务 (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 的经验。

您必须具有配置企业服务 (COM+) 应用程序的经验。

阅读第 1 章简介。这一章说明了身份验证、授权和安全通信对于分布式 Web 应用程序的重要性。

阅读第 2 章 ASP.NET 应用程序的安全模型。这一章简要介绍了创建分布式 ASP.NET Web 应用程序所采用的体系结构和技术，并重点说明了身份验证、授权和安全通信在此体系结构中的作用。

请结合以下章节学习本章，这些章节将举例说明本章所述的技术：

ASP.NET 到 SQL Server

ASP.NET 到企业服务到 SQL Server

ASP.NET 到 Web 服务到 SQL Server

ASP.NET 到 Remoting 到 SQL Server

客户端上安装了 Internet Explorer。

用户帐户位于 Microsoft Active Directory® 目录服务中。

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

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

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

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

创建自定义 ASP.NET 帐户（请参见本指南中的如何创建自定义帐户来运行 ASP.NET）

创建一个权限最少的数据库帐户（请参见第 12 章数据访问安全性）

在 Web 服务器上配置 SSL（请参见本指南中的如何在 Web 服务器上设置 SSL）

配置 IPSec（请参见本指南中的如何使用 IPSec 在两个服务器之间进行安全通信）

在此方案中，由于所有用户都使用 Windows 帐户并且使用的是 Microsoft Internet Explorer，所以最好使用 IIS 中的集成 Windows 身份验证。集成 Windows 身份验证的优点是从不通过网络传送用户的密码。此外，由于 Windows 使用当前交互式用户的登录会话，所以对于用户来说登录是透明的。

ASP.NET 作为权限最少的帐户运行，因此在出现安全问题的情况下可能会减轻受破坏的程度。

您不必在 ASP.NET 中进行模拟即可针对原调用方执行 .NET 角色检查或在 Windows ACL 中保证资源的安全。为了对原调用方执行 .NET 角色检查，按如下所示从 HTTP 上下文中检索代表原调用方的 WindowsPrincipal 对象：

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("Manager") )
{
  // 用户被授权执行特定于 manager（经理）的功能
}

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 应用程序角色的详细信息，请参见第 12 章数据访问安全性。

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

为什么我不能启用 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 帐户来代表所有客户端。如果使用客户端证书，则将要求使用 SSL。

窗体身份验证。窗体身份验证可以根据自定义数据存储（如数据库）或 Active Directory 来验证凭据。
如果根据 Active Directory 进行身份验证，请确保仅检索与应用程序有关的必要的组。正如不应该使用 SELECT * 子句对数据库执行查询一样，不应盲目地从 Active Directory 中检索所有的组。
如果根据数据库进行身份验证，您需要仔细分析 SQL 命令中使用的输入值，以防止 SQL 注入式攻击，并且应该在数据库中存储密码哈希值（带有 Salt），而不是存储明文密码或加密密码。
有关使用 SQL Server 作为凭据存储以及将密码存储在数据库中的详细信息，请参见第 12 章数据访问安全性。

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

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

如果选择此方法，则需要使用 Kerberos 身份验证（将帐户配置为使用委派）或基本身份验证。
本章后面的将原调用方传递到数据库部分讨论了委派方案。

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

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

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

用户安装了 Internet Explorer。

组件部署在 Web 服务器上。

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

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

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

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

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

在 ASP.NET 中启用模拟（以便实现企业服务基于角色的安全性）。

创建一个权限最少的数据库帐户（请参见第 12 章数据访问安全性）

在 Web 服务器上配置 SSL（请参见本指南中的如何在 Web 服务器上设置 SSL）

配置 IPSec（请参见本指南中的如何使用 IPSec 在两个服务器之间进行安全通信）

配置企业服务安全性（请参见本指南中的如何将基于角色的安全性用于企业服务）

ASP.NET 和企业服务作为权限最少的帐户运行，因此在出现安全问题的情况下可能会减轻受破坏的程度。当上述任何一个进程标识出现安全问题时，由于该帐户的权限非常有限，因此缩小了危害的范围。另外，在 ASP.NET 中，如果注入了恶意脚本，也可以限制潜在的危害。

要将原调用方的安全性上下文传递给企业服务组件（以支持基于企业服务 (COM+) 角色的授权），必须配置 ASP.NET 应用程序以支持模拟。如果不进行模拟，则对进程标识（即 ASP.NET 辅助进程）进行角色检查。模拟将影响到谁将获得资源访问权限。
在未进行模拟时，针对 ASP.NET 进程标识进行系统资源检查。如果进行模拟，则针对原调用方进行系统资源检查。有关从 ASP.NET 访问系统资源的详细信息，请参见第 8 章 ASP.NET 安全性中的访问系统资源。

通过使用企业服务 (COM+) 角色，将访问检查推到中间层（业务逻辑所在的位置）进行。在这种情况下，将在入口处检查调用方并将其映射到角色，而且将基于角色调用业务逻辑。这可避免不必要的后端调用。企业服务 (COM+) 角色的另一优点是：可以在部署时使用组件服务管理器创建和管理角色。

对 SQL 的 Windows 身份验证意味着，可以避免在文件中存储凭据并通过网络进行传送。

当设置了防火墙时（此时 Windows 身份验证所需的端口可能没有打开），仍然可以使用本地帐户运行企业服务应用程序，以及在数据库服务器上使用重复的帐户。在此方案中可能无法使用 Windows 身份验证和域帐户。

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

因为基于 .NET 角色的安全性以 Windows 组成员为基础，所以此解决方案需要根据相应层次的 Windows 组来匹配那些访问该应用程序的用户类别（具有相同的安全权限）。

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

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

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

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

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

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

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

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

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

数据库不支持委派。

在 Web 服务器上配置 SSL（请参见本指南中的如何在 Web 服务器上设置 SSL）

配置 IPSec（请参见本指南中的如何使用 IPSec 在两个服务器之间进行安全通信）

在此方案中，IIS 中的集成 Windows 身份验证是理想的选择。这是因为，所有用户都使用 Windows 2000 或更高版本、Internet Explorer 5.x 或更高版本，并且都使用 Active Directory 帐户，因此具备了使用 Kerberos 身份验证协议（其支持委派）的条件。这样，您就可以跨计算机边界传递用户的安全性上下文。

在 Active Directory 中，不能将最终用户帐户标记为“敏感，不能被委派”。在 Active Directory 中，必须将 Web 服务器计算机帐户标记为“可以委派其他帐户”。有关详细信息，请参见本指南中的如何为 Windows 2000 实现 Kerberos 委派。

Web 服务器和应用程序服务器上的 ASP.NET 作为权限最少的本地帐户（本地 ASPNET 帐户）运行，因此在出现安全问题的情况下可能会减轻受破坏的程度。

将 Web 服务和 Web 应用程序均配置为使用 Windows 身份验证。将两台计算机上的 IIS 均配置为使用集成 Windows 身份验证。

从 Web 应用程序调用 Web 服务时，默认情况下不传递凭据。要响应下游 Web 服务器上 IIS 发出的网络身份验证质询，必须使用凭据。必须使用以下方法设置 Web 服务代理的 Credentials 属性以明确地指定这一点：

wsproxy.Credentials = CredentialCache.DefaultCredentials;

有关使用凭据调用 Web 服务的详细信息，请参见第 10 章 Web 服务安全性。

将 Web 应用程序配置为使用模拟。因此，在从 Web 应用程序调用 Web 服务时，就会传递原调用方的安全性上下文，并且允许 Web 服务对原调用方进行身份验证（和授权）。

在 Web 服务中使用 .NET 角色并基于用户所属的 Windows 组（HRDept、PayrollDept 和 Employees）来对用户进行授权。HRDept 和 PayrollDept 的成员可以检索任何雇员的详细信息，而 Employees 组的成员仅有权检索他们自己的详细信息。
可以使用 PrincipalPermissionAttribute 类在 Web 方法中加上注释，以获得特定的角色成员身份，如以下代码示例所示。注意，可以用 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 进程标识的详细信息，请参见第 8 章 ASP.NET 安全性。

因为基于 .NET 角色的安全性以 Windows 组成员为基础，所以此解决方案需要根据相应层次的 Windows 组来匹配那些将要访问该应用程序的用户类别（具有相同的安全权限）。

Kerberos 委派是不受限制的，因此必须严格控制在 Web 服务器上运行的应用程序标识。为了提高安全性，应从“域用户”组中删除域帐户以限制域帐户的访问范围，并且只允许从有关的计算机进行访问。有关详细信息，请参见 Microsoft 网站 http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp 上的 Default Access Control Settings（默认访问控制设置）白皮书。

用户使用不同类型的 Web 浏览器。

远程组件由 ASP.NET 承载。

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

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

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

创建一个权限最少的数据库帐户（请参见第 12 章数据访问安全性）

在 Web 服务器上配置 SSL（请参见本指南中的如何在 Web 服务器上设置 SSL）

配置 IPSec（请参见本指南中的如何使用 IPSec 在两个服务器之间进行安全通信）

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;

有关将安全凭据传递到远程组件的详细信息，请参见第 11 章 .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 到企业服务到 SQL Server

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

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

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

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

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

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

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

将域用户帐户配置为使用委派，而在 Active Directory 中必须将用来运行企业服务应用程序的帐户标记为“可以委派其他帐户”。

在 Active Directory 中，必须将企业服务进程帐户标记为“可以委派其他帐户”，不得将最终用户帐户标记为“敏感，无法被委派”。有关详细信息，请参见本指南中的如何为 Windows 2000 实现 Kerberos 委派。

要求所有计算机都安装 Windows 2000 或更高版本。这包括客户端（浏览器）计算机和所有服务器。

所有计算机都必须在 Active Directory 中，并且必须属于单个目录林。

承载企业服务的应用程序服务器必须运行 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 帐户运行的，则必须将计算机帐户标记为“可以委派其他帐户”。有关详细信息，请参见本指南中的如何为 Windows 2000 实现 Kerberos 委派。

在此方案中，由于所有用户都使用 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") )
{
  // 用户被授权执行管理特定功能
}

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