SQL连接字符串安全性

Question

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

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

  

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

由于无法删除网站的Windows安全性，因此我认为遵循MSDN建议的唯一选项是：

1. 忽略MS建议并继续使用SQL身份验证

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

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

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

这些选项都没有比使用SQL Server用户名和密码更好听。

建议连接数据库的方法是什么？

Answer 1

  

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

正确。

  

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

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

  

[...选项......]

应用程序角色是此任务的正式解决方案。选项（4）也可以工作，但在身份验证期间有开销。不过，我会选择“不关心”选项，这就是原因：

前段时间我实施了TDS协议。 （协议的详细信息可以在MSDN上找到：private networks）。基本上有两种身份验证方式：

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

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

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

• 如果您执行集成安全性，则必须检查Active Directory的每个连接。对于少数用户来说这可能没问题，但是对于很多用户来说，我不喜欢这样。
• 只要在线发布此评论，SQL Azure就不支持集成安全性。如果真的非常不安全，那就毫无意义了。
• 主要优点是您不必在web.config中输入用户名和密码。再说一遍，我不会直接将SQL服务器暴露给互联网，如果恶意的人有权访问你的网络服务器，他可以为你的数据库做很多讨厌的事情（直接或间接）。

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

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

所以，总而言之，我不打扰它，只需坚持用户名/密码验证。