使用集成安全性（SSPI）更好地为Web应用程序访问SQL Server？

我会说只有两个有效的理由使用SQL身份validation：

1. 您正在从域外连接，因此集成了身份validation。
2. 您正在运行TPC-C基准testing，每个周期都很重要。 SQLvalidation速度稍快一点。

对于您提出的场景（Web服务器主机完全被破坏），什么都不能保护你。 黑客可以在数据库服务器上执行至less一些networking服务器可以执行的操作 。 而且我认为，纵深防御可以教会你在这种情况下减less损失：减less你的networking服务器使用的帐户的DB权利，绝对是最低限度所需的，仅此而已。 其次，确定Web服务器主机是否被攻破，它不能被用来提boost于Web服务器帐户的权限（例如，在WWW主机上没有使用比WWW帐户更高权限的凭据的其他服务）。 这些是基本的安全原则，与使用的authenticationscheme无关。

虽然sql auth vs windows auth在你的场景中既没有明确的优势，也有其他问题需要考虑：

1. 集中化策略执行：您可以在一个地方设置密码策略，包括密码生存期和到期期限，帐户终止等。
2. 控制假冒和委托信托。 一旦信任委托链中使用了sql auth，所有的赌注都将被closures，因为这不是真正的“授权”，因此不再受到您的策略的限制
3. 审计：您的LSA甚至没有看到sql auth，所以您的整个审计基础架构都被简单地绕过了。 你需要明确地添加关于sql auth事件的SQL产生的logging，但是混合了苹果和橙子，因为这些事件在事件日志中具有不同的源，提供者和模式

最后一个注意事项：TDS协议在stream量上以明文forms暴露了sqlauthentication密码，但通常通过请求stream量的SSLencryption来缓解。

那么为什么你看到仍然sqlauthenticationWWW主机，在web.config清除存储密码？ 那些是不好的开发者/pipe理员，不要成为其中之一。

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

如果您不使用SSPI，则将用户名和密码硬编码到源文件中。

如果您将用户名和密码硬编码到源文件中，您的所有员工都可以访问它。

这是相对不安全的。 一个不满的前雇员可能会恶意使用这些信息。 访问者可能会在某个屏幕上看到代码。 或者源代码可能会意外地出去。

SSPI的优点是密码永远不会被存储在任何地方。

到目前为止的其他答案是好的，但我会投入另一个：pipe理。

迟早，你可能会最终得到多个SQL Server。 pipe理您的应用程序和多个SQL Server之间的SQL身份validation会变得有点痛苦，尤其是当您遇到安全问题时。 如果您只更改一次Windows身份validation密码，则会立即在所有服务器上进行更改。 如果您需要旋转您的SQL身份validation密码，则更加痛苦 – 您可能根本不会这样做。 这是一个安全风险。

我在这里并不是100％确定的，但我认为最重要的是SQLvalidation是不安全的，所以最好使用Windowsvalidation。 根据您的应用程序的设置，您还可以使用Windows身份validation，在计算机上以encryptionforms存储适当的凭据。 我不认为这是真正可能的SQL身份validation。 你可以混淆它，但最终必须清楚。

另外，仅仅因为黑客可以进入服务器并不意味着游戏结束。 黑客可能获得对非特权进程的控制权，但不能在服务器上进行任何其他操作。 这就是为什么不以pipe理员或系统运行所有内容，而是使用最低权限服务帐户。

最好的办法是限制他们可以做什么如果/当他们闯入Web服务器。 这意味着仅授予应用程序运行所需的SQL权限。 赋予应用程序DBO权限要容易得多，但是如果成功攻击了Web服务器，则会使DB更容易受到攻击。

我将在前言中说，我假设你正在讨论内部专用networking上的内部Web服务器。

我们先来模拟机器。 如果应用程序池标识为“networking服务”，并且在.NET应用程序中没有模拟，则是的，Web应用程序将使用计算机的计算机帐户连接到后端SQL Server。 这就意味着你已经授权访问上述机器账户。 微软的CRM就是这样工作的。

但是，如果您指定了身份，则该用户帐户将需要访问SQL Server。 虽然你是正确的，如果攻击者损害了Web服务器，他们实际上与身份帐户具有相同的访问权限，但事实是，使用SQL Serverlogin不会改变任何内容。 一旦我有权限访问，我可以修改Web应用程序来执行我想要的操作，最大限度地提高后端SQL Server的安全性。

至于为什么要使用SSPI。 首先，您不使用基于SQL Server的login。 这意味着Active Directory是唯一的安全来源。 这意味着您有正常的审计手段来确定无效访问。 其次，这意味着除非有其他应用程序需要它，否则可以将SQL Server保留为仅限Windows身份validation模式。 这意味着不允许SQL Serverlogin。 这意味着任何针对sa的攻击在它们开始之前都会停止。 最后，它使恢复更容易。 如果您使用基于SQL Server的login，则需要使用SID和encryption的密码来提取login名。 如果您使用基于Windows的用户帐户作为“服务帐户”，则当您转到新的SQL Server时，通过创buildlogin名，一旦还原数据库，所有内容都将重新连接，因为login名和数据库用户之间的SID匹配。

问题是哪个“更好”？ 这是很难回答的，因为它依赖于提问者的背景，价值和优先级。

就我个人而言，我喜欢SQL身份validation。

• AD是运行和支持和pipe理服务帐户的另一件事情。
• AD需要在您的托pipe环境中可用。
• AD会使移动到云或混合云很难。
• AD使您可以轻松地将服务帐户添加到组织的其他部门中pipe理员不应该访问的组中。
• SSPI不会绕过encryption连接string的问题，因为您应该在config中encryption您的SQL主机名。
• SQL身份validation很简单，只是文本configuration，易于部署。
• 设置应用程序池标识是自动化，然后隐藏每个环境的自动化脚本中的用户名和密码的另一件事。
• 使用两个连接string，可以方便地使用滚动密码，因此您可以在不停机的情况下更新密码。

最后一点：你编写你的连接pipe理器类来尝试每个连接string，这样你可以更改密码的第一个configuration，推出更改，它将故障转移到第二个连接，然后更新密码在MSQL第一个将再次使用。 需要进行最后的configuration更改，以将第二个密码设置为与第一个密码相同，以备下次使用。

如果用户不会直接操作数据库（通过SQL Server Management Studio等其他客户端工具），那么我通常会为应用程序创build一个SQLlogin名，并授予它所需的访问权限。 在那个时候，用户受限于他们可以做的事情，只要Web应用程序界面允许。