集中和保护连接字符串的最佳方法是什么？

Question

集中和保护应用程序使用的连接字符串的最佳方法是什么？在我的环境中，我们有许多内部应用程序每个应用程序都需要一个或多个连接字符串才能访问数据库。我们的目标是集中所有这些连接字符串（特别是SQL登录名和密码），这样我们就可以在一个地方而不是35个不同的.config文件，注册表项等中更改密码。

目前，我们正在使用一个本地增长的组件，它从访问数据库中提取连接字符串信息，这涵盖了集中化要求，但并不是特别安全。此外，我们还使用经典的asp，vb6，delphi，c ++ ,. net等语言编写应用程序，因此所有这些应用程序都需要使用该解决方案。

有没有人知道如何更好地做到这一点，或者我们是否需要重新设计我们的应用程序访问数据库的方式。

Answer 1

我工作的公司通过SQL Server数据库使用了类似的情况。我们最终创建了一个符合COM的.net DLL来简化和保护API到数据库中，并确保在经典的asp，.Net和DTS包之间使用相同的逻辑。它对我们来说效果很好，虽然我们很多人都想用它做一些重构项目，但解决服务器迁移或重命名等问题一直很棒。

我认为你走的是正确的道路;但是，我建议进行以下更改：

• 尝试移动到真正的数据库服务器。访问非常适合MS Office，但不适合这种规模。
• 构建一个管理控制台，允许审核谁在添加和编辑信息（有权访问哪些设置的安全人员）。
• 构建符合COM的DLL，以便其他系统以安全和一致的方式使用它。

编辑：

在这样的系统中工作多年之后我注意到的一点是它在某些解决方案上略微牵制你的双手。当连接字符串不再出现在配置文件中时，那里的许多工具（即.Net世界中的nHibernate，Elmah等）确实受到限制。可以轻松修改许多以使用您的API;但是，如果您想使用它，需要花费更多时间进行调查。只是一个FYI。

Answer 2

您可以使用Windows服务器创建允许访问SQL Server数据库的用户。然后，您可以在连接字符串中使用集成的Windows登录。

BTW在公共MDB中存储密码会使它们变得无关紧要。它们不存在相同。

Answer 3

是否无法在连接字符串中移动到Window Integrated Security，那么您不必担心安全方面（除非您需要确保连接的实际位置）。