保护连接字符串的选项

Question

只是一个普遍的架构问题。

我知道对于网站，可以使用IIS内置的功能来加密连接字符串部分。但是，我不确定的是......如果我这样做然后将web.config复制到另一个项目，新项目是否仍然可以解密配置文件中的连接字符串部分？

这成为问题的是生产数据库访问。我们不希望任何人能够将生产中的配置文件复制到他们的项目中，并且可以对生产数据库进行全权访问。

目前我公司的做法是将加密的连接字符串存储在服务器的注册表中，然后使用自行开发的工具来读取注册表并动态解密该值。这可以防止有人只是查看注册表或Web配置以查看连接字符串。

此外，对于胖客户端（WinForms，WPF等）应用程序，这可能会有点问题，因为再次，我不确定IIS加密技巧是否会起作用，因为应用程序不会在IIS上运行。我们目前有一个kludgy解决方案，涉及相同的本土应用程序，但从二进制文件读取加密字符串并动态解密。

它看起来非常紧密，我们正在寻找更好的方法（即行业标准，当前技术等）

所以，更普遍的问题是......

您使用哪些方法来保护连接字符串？特别是涉及到访问它的多种应用程序类型，加密等

Answer 1

快速Google搜索会向您显示其他人尝试加密部分或全部应用配置文件（即Google“ecnrypting应用程序配置文件”）。

但通常情况下，我发现更好的答案是正确保护您所关注的资源（通常是数据库）。 Windows身份验证始终是SQL身份验证的首选，因此密码不需要存储在配置文件中，尽管这可能并不总是一个选项。如果您想阻止对资源的访问（特别是如果它通常通过任何类型的Web层访问，如Web服务或网站本身），那么将资源托管在不同的服务器上（无论如何都是首选的），而不是允许从内部网络外部访问它。如果攻击者可以访问您的内部网络，那么通常比您试图保护的资源更为关注。

如果您担心恶意人员执行即使您的应用程序无法执行的操作（例如删除数据库），那么请确保应用程序使用的凭据也不具有该类型的权限。这显然不会阻止攻击，但它可以减少从中造成的伤害量。

保护位于用户机器上的配置文件中的信息通常不值得花时间，恕我直言。在一天结束时，机器本身将需要能够解密信息，并且如果机器具有这样做的手段，那么用户也是如此。你可以让用户很难做到，但它通常仍然可行。

这不是你问题的直接答案，但我希望它能让你思考一条可能导致可接受解决方案的不同路径。

Answer 2

根据我的理解，加密连接字符串的保护（例如文章Importing and Exporting Protected Configuration RSA Key Containers中提供的内容）保护了用户级别的连接字符串。

这意味着只有运行IIS（NT AUTHORITY\NETWORK SERVICE）的帐户才能访问加密密钥以解密连接字符串。因此，这仅针对能够登录到包含web.config文件的服务器的用户。但它可以扩展到限制对某些应用程序的访问。

关于胖客户端，可能有一种方法可以缩小界面范围：

将所有SQL命令定义为服务器上的存储过程，并将使用过的用户帐户的设置更改为仅允许执行这些存储过程。这会将对数据库的访问限制为可以使用SQL登录凭据执行的操作。

Answer 3

我会使用SQL DB帐户管理功能，仅具有特定权限（例如，在最抽象的情况下 - 允许执行只读SQL命令），并且仅使用允许的主机和/或域。