将 IIS 7.5 Web 窗体连接到 SQL Server 的最佳方法答案

【问题标题】：Best method to connect IIS 7.5 Web Forms to SQL Server将 IIS 7.5 Web 窗体连接到 SQL Server 的最佳方法
【发布时间】：2012-02-23 16:31:17
【问题描述】：

我正在从以下位置升级 ASP.NET 4.0 应用程序：

Windows Server 2003 和 IIS 6

到：

Windows Server 2008 和 IIS 7.5

此应用基于 ASP.NET Web 表单 而不是 MVC。我目前使用 SQL 身份验证，但我想在新环境中遵循最佳实践。

IIS 7.5 机器和 SQL Server 2008 机器都将驻留在具有自己的域控制器的DMZ中。如果我们可以在 Dev、Test 和 Prod 环境中使用类似的连接字符串，那就太好了。这种情况的最佳做法是什么？我已经阅读了三个选项。

ApplicationPoolIdentity
在域中创建您自己的服务帐户
SQL 身份验证

这里是讨论相关问题的问题的链接，但似乎没有回答我的具体问题。

User ASP.NET Runs Under

Assign Permissions to ApplicationPoolIdentity Account

【问题讨论】：

标签： asp.net sql-server-2008 iis-7 webforms applicationpoolidentity

【解决方案1】：

我推荐使用 AD 帐户来运行应用程序池。然后，可以在 SQL 服务器上为同一帐户创建权限。应用程序使用的 conn 字符串将完全不必包含帐户信息（受信任的连接），您将不必担心与安全相关的一件事。作为额外的预防措施，从所有用户组中删除该 AD 帐户，并且不要将其用于除此一件事（应用程序池）之外的任何其他事情。授予该用户对网站文件的读取权限，并仅授予对其需要写入的文件夹的写入权限（例如转储日志文件）。

【讨论】：

谢谢，我想这回答了我的问题，但我仍有疑虑。 Microsoft 在创建 ApplicationPoolIdentity 构造时遇到了很多麻烦。如果为每个应用程序池创建一个 AD 帐户是有意义的，他们为什么还要打扰呢？ AD 账户和 ApplicationPoolIdentity 之间的取舍是什么？
不是每个人都有 AD 设置。那么，并不是每个网站都会使用网络共享文件夹和/或 MS SQL 服务器（等）。
我会假设 ApplicationPoolIdentity 在系统（操作系统）上的权限比任何其他用户（例如手动创建的用户）要少，并且这比访问磁盘上的文件更远（例如，它可能只能访问对 asp.net、磁盘、注册表等重要的内容。
谢谢；为了使其尽可能安全，当为此使用 AD 帐户时，将其从所有组中删除（默认情况下，AD 帐户至少在“域用户”组中），甚至不要将其添加到本地来宾组，并特别允许对与应用程序（网站文件，以及应用程序读取或写入的任何网站外文件文件夹）有关的磁盘（在网络盒上）文件夹的权限。
显然，强密码。尽管在封闭环境中，通过知道用户名和密码来破解您的服务器/应用程序的可能性较小，但如果您的应用程序存在该帐户可能会搞砸事情的错误（例如，删除服务器上不相关的文件），那么它有助于不要让它成为管理员组的一部分（例如；我已经看到了）。

【解决方案2】：

就最佳实践而言，我认为您列出的 3 个选项中没有任何一个比另一个更好；如果使用得当，它们都可以安全有效地完成工作。考虑到您的特定环境、公司政策等，您的决定应基于哪些对您有利，但同样，这些都不是坏习惯。

【讨论】：