我该如何安全地存储SQL Server连接字符串以便远程应用程序可以访问?

4
我们现在有许多运行在不同机器上的.NET应用程序。数据库连接字符串存储在每个应用程序的设置XML文件中。每次启动应用程序,它都会首先从其设置文件中加载此字符串。这种方法可以正常工作,但是如果我们需要更改登录信息,那么找到所有已存储信息的地方将是一场噩梦。而且,随着虚拟机的增加,我们不断添加新的机器,理想情况下只需部署exe/dll文件即可自动安全地获取应用程序的连接字符串。
我考虑过对该字符串进行加密,并将其放在Web服务器上,以便远程应用程序可以通过HTTP和DNS名称获取并解密它,但这种方法过于简单,由于此信息的安全性非常重要,因此我需要非常小心谨慎。
因此,问题是,如何安全地向远程应用程序传递连接字符串,以便在启动时它们就知道如何连接到数据库?一旦它们能够做到这一点,它们就可以从数据库中的配置表中获取其他设置。

1
如果客户端直接使用用户ID和密码连接到SQL,则该信息不安全。考虑使用三层架构,其中客户端通过WCF连接到业务/数据层,然后只有服务连接到SQL。 - paparazzo
不幸的是,重写大量代码以添加层是不可能的。此外,同样的问题存在,客户端如何安全地知道WCF服务器在哪里,以及如何以透明的方式进行身份验证? - powlette
1
没有同样的问题存在。直接连接 SQL 并使用诸如 delete * 和 drop table 的命令,与返回数据的 WCF 服务不同。WCF 有许多身份验证选项,并为此而构建。 - paparazzo
不是在每个客户端上放置连接字符串,而是将WCF服务器详细信息和身份验证放置在其中。我会面临同样的问题。我想解决的是如何安全地将连接字符串存储在一个位置,并允许经过身份验证的客户端通过某些公共方法获取它。 - powlette
如果客户端无法存储身份验证信息,那么就无法帮助您进行身份验证。 - paparazzo
1个回答

3
您系统中信任的部分是什么?您必须100%信任客户端,因为一旦他们拥有连接字符串(他们必须拥有),他们可以对数据库进行任何操作。您还必须信任服务器。
所以看起来您信任所有人。这使得保护系统变得容易:无论您如何分发连接字符串,它已经是安全的。
当涉及到保存和分发密码和连接字符串时,我见过很多迷信行为。许多人感到不舒服,因为它们以明文形式发送并存储。这是不合理的,因为客户端最终确实以明文形式拥有它。这是无法防止的。
因此,我的建议是:创建一个简单的Web服务,提供以下API:
string GetConfigSetting(string name)

客户可以向该服务请求连接字符串。该服务如此简单,其接口可能永远不会更改。

在这种情况下,加密没有什么意义。客户端应用程序可以轻松反编译以访问任何解密例程。此外,客户端必须最终解密秘密。此时,控制客户机的攻击者可以清晰地读取秘密。


@Nattrass,感谢您对我的回答进行补充!虽然您的编辑被拒绝了,但我已经手动添加了您的内容。 - usr
+1 是为了指出许多人的严重心理崩溃 - 无论如何,最终你必须信任客户端。Point。集成安全性可以修复至少来自其他不受信任机器的用户,但最终,在这里实现安全是不可能的,因此即使尝试也不会取得很大成效。 - TomTom
@TomTom集成的安全功能可能会防止明文查看密码(不确定其内部工作原理)。这是个好观点。但攻击者仍然可以通过篡改客户端应用程序的内存来实现他想要的操作(就像操作大脑控制思维一样...)。 - usr
是的,但至少他必须使用AD用户。没有秘密 - 它使用AD集成安全性(票证)。但这并不能阻止用户启动访问,例如,执行纯SQL。 - TomTom

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接