Security Microsoft Access 2010和ODBC连接字符串安全性

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

这样做的一个好方法是要求应用程序管理员在应用程序第一次运行时根据

…使用运行应用程序的帐户的用户特定密钥通过DPAPI加密其值，并将加密值保存在Windows注册表中

accde从登录的windows用户帐户启动，然后应用程序管理员可以按照上述建议登录并设置到数据库的连接

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

我可以创建一个新的windows用户，但这意味着该用户的密码必须保持安全，这意味着我们回到了第一步，保护用于访问某些机密信息的密码

---

必须有一种更简单的方法，有什么想法吗？

您需要在会话之间保留连接字符串的原因吗？您是否可以在应用程序中构建一个登录表单，在该表单中接受用户的凭据、服务器实例和数据库名称，并在应用程序运行时将这些信息保存在内存中

---

这可能会提供更大的灵活性，因为管理员可以决定将数据库移动到新服务器，而不必担心解密连接字符串来更改它并重新加密它。它还允许定义多个数据库——我想在一种情况下，您可以在部署到生产服务器之前定义一个用于测试更改的QA服务器。

如果用户必须输入凭据，他们将知道服务器的位置以及如何在不使用应用程序的情况下登录。应用程序应该是访问信息的唯一途径。我同意，但通过模糊安全性实现的安全性也不起作用。如果您担心用户会通过应用程序以外的其他机制修改数据，请将其置于不允许或不受支持的服务条款中。您知道，如果您只使用Windows安全性而不是SQL Server安全性，整个问题就会消失，在这种情况下，您不需要在链接表中存储凭据。实际上，可以在混合模式下运行SQL Server，也就是说，支持两种类型的安全性，但我从来没有这样做过，我只使用了Windows安全性。我认为这会使SQL Server上的安全性和角色管理变得更加复杂。