☰

对于 Web 应用程序来说，使用集成安全性（SSPI）访问 SQL Server 是否更好？

tag-icon • tag-icon sql-server security web-applications
对于 Web 应用程序来说，使用集成安全性（SSPI）访问 SQL Server 是否更好？

将 Web 应用程序（.net）部署到生产环境时，使用集成安全性是否更好，或者这是否重要？

在我看来，如果黑客破坏了网络服务器，这并不重要，因为他们可以轻松冒充该机器。

有什么想法吗？

答案1

我认为使用 SQL 身份验证只有两个有效理由：

  1. 您正在从域外进行连接，因此集成身份验证。
  2. 您正在运行 TPC-C 基准测试，每个周期都很重要。SQL auth 稍快一点。

对于您提出的场景（Web 服务器主机完全被攻陷），没有什么可以保护您。黑客至少可以在数据库服务器上进行以下操作网络服务器能做的一切。我想说的是，纵深防御可以教你如何将这种情况下损失降到最低：将你的 Web 服务器使用的帐户的数据库权限减少到绝对最低限度，仅此而已。其次，确保如果 Web 服务器主机受到威胁，它不能用于提升高于 Web 服务器帐户的权限（即，WWW 主机上没有其他服务使用比 WWW 帐户具有更高数据库权限的凭据）。这些是基本的安全原则，与使用的身份验证方案无关。

虽然 sql auth 与 windows auth 在您的场景中没有明显的优势，但还有其他问题需要考虑：

  1. 集中策略实施：您可以在一个地方设置您的密码策略，包括密码有效期和到期时间、帐户终止等。
  2. 控制模拟和信任委托。一旦在信任委托链中使用 sql auth，所有赌注都将失效，因为这不是真正的“委托”，因此不再受您的政策施加的限制
  3. 审计：您的 LSA 甚至看不到 sql auth，因此您的整个审计基础架构都被绕过了。您需要明确添加 SQL 生成的有关 sql auth 事件的记录，但由于这些事件在事件日志中具有不同的来源、提供程序和架构，因此会混淆两者

最后一点说明：TDS 协议在流量中以明文形式公开 sql auth 密码，但通常可以通过请求流量的 SSL 加密来缓解此问题。

那么，为什么你仍然看到 SQL Auth WWW 主机在 web.config 中以明文形式存储密码？这些是坏的开发人员/管理员，不要成为他们中的一员。

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

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

答案2

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

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

这相对来说不太安全。心怀不满的前员工可能会恶意使用这些信息。访问者可能会在某个屏幕上看到代码。或者源代码可能会意外泄露。

SSPI 的优点是密码永远不会以明文形式存储在任何地方。

答案3

到目前为止其他的答案都很好，但我还要补充一个：管理。

迟早，您可能会拥有多个 SQL Server。管理应用程序和多个 SQL Server 之间的 SQL 身份验证会有些麻烦，尤其是遇到安全问题时。如果您更改一次 Windows 身份验证密码，它会立即在所有服务器上更改。如果您需要轮换 SQL 身份验证密码，那就更麻烦了 - 甚至您可能根本不会这样做。这是一种安全风险。

答案4

最好的办法是限制他们在入侵 Web 服务器时可以做的事情。这意味着只授予应用程序运行所需的 SQL 权限。授予应用程序 DBO 权限要容易得多，但如果 Web 服务器遭到成功攻击，数据库将更容易受到攻击。

相关内容