SQL 连接字符串安全性

本文关键字：安全性 字符串 连接 SQL | 更新日期: 2023-09-27 18:37:05

我们有一个内部 asp.net 网站运行在带有Windows安全中心的IIS上。根据我的理解（和观察），这意味着每个线程都使用连接到网站的用户的凭据运行。

该网站连接到 SQL Server 2014 数据库。我们使用 SQL Server 用户名和密码进行连接。查看 MSDN，我发现不建议使用 SQL Server 身份验证。

SQL Server 帐户登录的密码。不推荐。为了保持高级别的安全性，我们强烈建议您改用"集成安全性"或"Trusted_Connection"关键字。SqlCredential 是为使用 SQL Server 身份验证的连接指定凭据的更安全方法。

由于删除网站的Windows安全中心不是一个选项，因此我看到遵循MSDN建议的唯一选项是：

  1. 忽略MS建议并继续使用SQL身份验证，就像我们一样

  2. 为每个网站用户提供与当前 SQL Server 凭据相同的 SQL Server 访问权限。这意味着如果任何用户直接连接到服务器，他们可以运行自己的查询，而不是局限于我们编码的内容。也许某种防火墙规则可以解决这个问题。企业不喜欢这个想法（我也不是）

  3. 授予每个用户连接访问权限（无其他权限），并在用户通过网站连接时使用应用程序角色提供权限。

  4. 每次与 SQL Server 建立连接时，都应在模拟具有访问权限的域用户的线程上完成连接。

这些选项听起来都不比使用 SQL Server 用户名和密码更好。

连接到数据库的推荐方法是什么？

SQL 连接字符串安全性

我们有一个内部 asp.net 网站在具有Windows安全中心的IIS上运行。根据我的理解（和观察），这意味着每个线程都使用连接到网站的用户的凭据运行。

正确。

该网站连接到 SQL Server 2014 数据库。我们使用 SQL Server 用户名和密码进行连接。

好的，所以在这个过程中，你会丢失传递给网站的 Windows/NTLM 安全令牌。

[...选项...]

应用程序角色是此任务的正式解决方案。选项 （4） 也可以工作，但在身份验证期间有开销。尽管如此，我还是会选择"不在乎"选项，这就是为什么：

我前段时间已经实现了TDS协议。（协议的详细信息可以在MSDN上找到：https://msdn.microsoft.com/en-us/library/dd357628.aspx）。基本上有两种身份验证方式：

  • 使用标准质询-响应协议（例如用户名/密码身份验证）;
  • 使用集成安全性，AD/kerberos 身份验证;
  • 在所有情况下，您都可以选择TLS/SSL加密。

从安全角度来看，它足够安全。也就是说：我不会直接将我的SQL Server暴露给互联网，但这主要是因为这对我来说没有意义......

我之前也看过Microsoft的评论，由于几个不同的原因，当时也让我感到困惑：

  • 如果您执行集成安全性，则必须检查每个连接的活动目录。对于一些用户来说，这可能很好，但对于很多用户来说，我不喜欢这样。
  • SQL Azure 不支持集成安全性，只要他们在线有此评论。如果它真的非常不安全，那没有任何意义。
  • 主要优点是您不必在web.config中输入用户名和密码。再说一次，无论如何，我不会直接将SQL服务器暴露给互联网，如果恶意人员可以访问您的Web服务器，那么无论如何他都可以对您的数据库做很多令人讨厌的事情（直接或间接）。

在某些情况下，Windows 身份验证更有意义，特别是如果您在数据库中使用基于角色的安全性来限制单个角色对架构等的访问。在这些情况下，使用单个帐户毫无意义。

老实说，我也可以从另一个角度解释这样的评论：Microsoft的完整许可模型基于 CAL，这是通过 AD 帐户的数量来检查的。通过推动每个人使用集成安全性，实施这种许可模型要容易得多。

因此，长

话短说，我不会打扰它，只需坚持用户名/密码身份验证。

相关文章：