2011-04-13 126 views
1

我正在使用带有未绑定表单的Microsoft Access 2010。不允许链接表,否则连接字符串存储在表定义中。因此,我们将使用没有名字的查询定义来访问SQL SERVER。这是Microsoft推荐的。我们需要从某处获取连接字符串。所以建议从名称混淆的方法中返回它。建议不要以纯文本形式在应用程序源中嵌入连接字符串。所以我们使用加密。Microsoft Access 2010和ODBC连接字符串安全性

这样做的一个好方法是要求管理员应用程序在应用程序第一次运行来定义连接字符串,并根据this msdn article

...通过DPAPI与用户加密其价值该应用程序运行的帐户的特定密钥,并将加密值保存在Windows注册表中。

accde从登录的Windows用户帐户启动,之后应用程序管理员可以按照上述建议登录并设置与数据库的连接。

我现在看起来最薄弱的环节是windows用户帐户。似乎任何登录到该帐户的人都可以解密连接字符串,如果他们知道安全方案的实施。这意味着系统仍然不够安全。

我可以创建一个新的Windows用户,但这意味着该用户的密码必须保持安全,这意味着我们回到了第1个方格,确保用于访问某些秘密信息的密码。

必须有一个更简单的方法,任何想法?

+0

您知道,如果您只是使用Windows安全性而不是SQL Server安全性,则整个问题将消失,因为在这种情况下,您不需要在链接表中存储凭据。实际上,可以以混合模式运行SQL Server,即支持这两种安全类型,但我从来没有这样做过(我只使用Windows安全性)。我想这会使SQL Server上的安全和角色管理变得更加复杂。 – 2011-04-18 05:17:34

回答

0

是否有一个原因,你需要从会话持续连接字符串到会话?您是否可以在您的应用程序中构建一个登录表单,以便在应用程序运行时接受用户的凭据,服务器实例和数据库名称,并将这些信息保存在内存中?

这可能会提供更大的灵活性,因为管理员可以决定将数据库移动到新的服务器,并且不必担心解密连接字符串以更改它并重新加密它。它还允许定义多个数据库 - 我正在考虑在将产品推出到生产服务器之前定义一个用于测试更改的QA服务器的情况。

+0

那么,如果用户不得不输入凭据,他们就会知道服务器在哪里以及如何在不使用应用程序的情况下登录到服务器。应用程序应该是访问信息的唯一方式。 – cmaduro 2011-04-15 14:26:08

+0

我同意,但通过obfuscurity的安全性往往不起作用。如果您担心用户将通过除您的应用程序之外的其他机制来修改数据,请将其放入服务条款中,这是不被允许或不被支持的。 – 2011-04-19 15:57:46