13

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

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

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

4

3 回答 3

3

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

我认为您走在正确的道路上;但是,我建议进行以下更改:

  • 尝试迁移到真正的数据库服务器。访问非常适合 MS Office,但不适用于这种规模的东西。
  • 构建一个管理控制台,允许审核谁在添加和编辑信息(确保谁也可以访问哪些设置)。
  • 构建一个兼容 COM 的 DLL,以便其他系统可以以安全和一致的方式使用它。

编辑:

在这样的系统中工作多年后,我注意到的一点是,它在某些解决方案上稍微束缚了你的手。当连接字符串不再在配置文件中时,许多工具(即 .Net 世界中的 nHibernate、Elmah 等)确实受到限制。许多可以轻松修改以使用您的 API;但是,如果您想使用它,则需要花费更多时间进行调查。仅供参考。

于 2008-11-25T15:22:06.137 回答
2

You can use Windows server to create users that are allowed to access your SQL Server database. Then you can use integrated windows login in connection strings.

BTW Storing passwords in public MDB renders them irelevant. Same as they don't exist.

于 2008-11-25T16:06:51.723 回答
0

是否无法在连接字符串中移至 Window Integrated Security,那么您不必担心安全方面的问题(除非您需要保护我猜的连接的实际位置)。

于 2008-11-25T15:26:39.217 回答