当 SQL Server 位于另一台服务器上时，IIS 7.5 ApplicationPoolidentity

Question

有人可以就以下场景下为 Web 服务设置应用程序池标识的最佳实践提供建议吗？

互联网信息服务7.5

1. Web 服务需要对 SQL 数据库的读/写权限
2. IIS 和 SQL 位于不同的服务器上，但位于同一域中

如果使用 ApplicationPoolIdentity \$，并将其添加为 SQL 用户，这是否会使我们的服务器面临任何特定的安全风险，而不是添加新的域用户并将该用户分配为应用程序池标识并授予该用户对 SQL 数据库的权限？

互联网信息服务

同样的场景，但使用 NetworkService 内置用户作为应用程序池标识。同样，与添加新域用户相比，这是否会使我们的服务器面临任何特定的安全风险？

谢谢

Answer 1

使用 AppPool Identity 来访问远程 SQL 服务器本质上意味着你授予了 Web 服务器的 AD 计算机帐户访问 SQL 数据库的权限。因此，在计算机帐户上下文中在 Web 服务器上运行的任何其他程序还有权访问 SQL 服务器。从安全性方面来说，您的表现可能会差很多，但明确定义的域帐户肯定更好，因为您可以确保使用它的唯一代码是您的网站。

如果管理基于域的帐户（及其必要的密码）太麻烦，并且您的 Web 服务器在 2008 R2 或 Win7 上运行，您可能能够使用托管服务帐户它基本上为您提供了 AppPool Identity 的可管理性优势和域帐户的安全性。

我个人还没有机会使用托管服务帐户。所以我不确定 TechNet 文档是否有任何缺陷或警告。但是，如果您有时间并且您的环境满足所有要求，那么值得一试。但它们肯定不会在您的 IIS6 机器上运行。

Answer 2

使用应用程序池标识更安全：-

1-将用户能力限制在本地，而不是网络或域，因此该用户运行的任何进程都不允许在任何网络资源上运行，因为它不是域\用户名。（更安全的域）

2-允许此应用程序文件夹的 NTFS 权限仅为 Web 应用程序提供更多安全性（更本地安全）

3-我不同意 Ryan 的观点：用户帐户 = 计算机\机器帐户 = 组只是经过 SID 身份验证和授权 => 域成员计算机也是 AD 中的 Kerberos 主体，这意味着域控制器具有关联的帐户密码哈希，它们可以在计算机联机时使用该哈希对计算机进行身份验证。此密码与计算机帐户对象相关联

微软表示：随着越来越多的 Windows 系统服务开始以网络服务的身份运行，问题逐渐出现。这是因为以网络服务身份运行的服务可能会干扰以相同身份运行的其他服务。由于 IIS 工作进程默认运行第三方代码（经典 ASP、ASP.NET、PHP 代码），因此是时候将 IIS 工作进程与其他 Windows 系统服务隔离，并以唯一身份运行 IIS 工作进程了。Windows 操作系统提供了一项称为“虚拟帐户”的功能，允许 IIS 为其每个应用程序池创建一个唯一身份。