SQL连接字符串安全

问题描述：

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

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

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

由于对网站删除Windows安全性是不是一种选择，我看到遵循MSDN建议的唯一选择是：

忽略MS的建议，并使用SQL身份继续为我们
给每个网站用户与当前SQL Server凭证具有相同的SQL Server访问权限。这意味着如果任何用户直接连接到服务器，他们可以运行自己的查询，而不是限于我们编码的内容。也许某种防火墙规则可以解决这个问题。该业务不是这个想法的粉丝（我不是）
给每个用户连接访问权限（没有其他权限）并使用应用程序角色在用户通过网站连接时提供权限。
每次连接到SQL Server时，都应该在模拟有权访问的域用户的线程上完成。

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

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

号这取决于Web应用程序的配置，但它很可能将其连接到SQL服务器作为_Application pool_凭据。实际上，将Windows凭据传递到SQL Server –

这是一个非常具有挑战性的过程......这是您的选项4，这是许多Web应用程序的功能。 –

对不起@ Nick.McDermaid，你是否说过许多使用Windows安全性运行的Web应用程序（即System.Threading.Thread.CurrentPrincipal =查看站点的用户）会在每次连接时模仿另一个通用用户开销到SQL？你能举出这是最佳实践的例子吗？ – Greg

答

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

正确。

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

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

[...选项...]

应用程序角色是此任务的正式方案。选项（4）也可以工作，但是在认证过程中有开销。不过，我会去为“不关心”的选项，这就是为什么：

我前一段时间实施的TDS协议。（该协议的细节可以在MSDN上找到：https://msdn.microsoft.com/en-us/library/dd357628.aspx）。基本上有两种认证方式：

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

我也见过微软的评论，这也困扰了我当时出于几个不同的原因：

如果您执行集成安全性，它必须检查每个连接的Active Directory。对于少数用户来说这可能很好，但对于很多用户来说，我不会那么喜欢。
只要他们在线提供此评论，SQL Azure就不支持集成安全性。如果它确实非常不安全，那没有任何意义。
主要优点是您不必在web.config中输入用户名和密码。然后，我不会直接将SQL服务器直接暴露给互联网，如果恶意的人可以访问您的Web服务器，他可以直接或间接地为您的数据库执行许多令人讨厌的事情。

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

坦白说，我也可以从另一个角度解释意见是这样的：微软的完全许可模式是基于CAL的，这是由AD帐户数量进行检查。通过推动所有人使用集成安全性，执行这种许可模式要容易得多。

所以，做一个长话短说，我不会理会它，只是坚持的用户名/密码认证。