使用机器帐户 (DOMAIN\MACHINENAME$) 从 IIS7.5 连接到 SQL Server 2008+ 的安​​全问题/风险

Question

我正在与一组工程师合作进行 .NET 4 / MVC 3 开发，本地使用 Windows 7 Enterprise 和 IIS 7.5，并连接到 MSSQL 2008+ 开发/测试数据库。这些数据库是远程的，但仍在同一个 Active Directory 环境中。

我们当前的设置要求我们的本地开发环境以个人帐户（例如）的形式连接到 SQL DOMAIN\Paul，我们通过将应用程序池的凭据设置为与我们用于登录工作站的凭据相同来实现这一点。在数据库服务器上，我们配置了一个DOMAIN\EngineerGroup对我们的开发/测试数据库具有适当访问权限的组（例如）。这似乎工作得相当好，除了每次更改密码时都必须在 IIS 中更新凭据的不便。（我们的公司/组策略强制我们必须定期更改密码。）

我想知道使用内置帐户是否存在任何安全风险或其他问题。我已通过创建与 对应的新 SQL 登录名并授予其与我们授予 相同的访问权限，ApplicationPoolIdentity使其在隔离环境中工作。我的建议是创建一个新的 Active Directory 组，例如，其成员是每个工程师的工作站（而不是每个工程师的用户帐户），并向新组授予相同的访问权限。DOMAIN\MYMACHINE$DOMAIN\EngineerGroupDOMAIN\EngineerWorkstationGroup

理想情况下，我正在寻找一些相当权威的文章或文档（可能来自 Microsoft），其中详细说明了这些MACHINENAME$帐户的安全性、它们与用户帐户的不同之处以及使用它们会给我们带来哪些（如果有的话）额外风险。到目前为止，我发现的最好的来源是一篇关于互联网。我尝试过多次搜索，但并没有找到其他讨论使用不同 AD 帐户类型的权衡的内容。

提前致谢！

PS 我们还考虑过使用中央域帐户（例如创建一个单独的帐户DOMAIN\EngineerAppPool，让每个人都从该帐户从 IIS 连接到 SQL），但我认为这会使审计和分析更加困难。

Answer 1

我认为这是对常见身份验证方案的一个奇怪的解决方案。通常的做法是让客户端使用自己的用户/密码进行身份验证，然后使用模拟来访问数据库。要实现这一点，您必须使用信任进行委派和双跳 Kerberos 身份验证（不支持 NTLM）

这样，应用程序池就可以作为机器帐户或服务帐户运行。用户使用其用户/密码（单点登录）进行身份验证。然后，应用程序池的机器帐户或服务帐户被信任，可以在访问数据库时模拟用户身份。

然而，您必须对您的应用程序进行一些修改才能使其正常工作。