Microsoft Access 2010 和 ODBC 连接字符串安全性
我正在使用带有未绑定表单的 Microsoft Access 2010。不允许链接表，否则连接字符串将存储在表定义中。因此，我们将使用没有名称的查询定义来访问 SQL SERVER。这是微软推荐的。不过，我们需要从某个地方获取连接字符串。因此建议从名称模糊的方法中返回它。建议不要在应用程序源中以纯文本形式嵌入连接字符串。所以我们使用加密。
执行此操作的一个好方法是要求应用程序管理员在首次运行应用程序时根据这篇 msdn 文章
...使用运行应用程序的帐户的用户特定密钥通过 DPAPI 对其值进行加密，并将加密值保存在 Windows 注册表中。
accde 从登录的 Windows 用户帐户启动，之后应用程序管理员可以按照上述建议登录并设置与数据库的连接。
我现在看来最薄弱的环节是 Windows 用户帐户。似乎任何登录该帐户的人都可以解密连接字符串，如果他们知道安全方案的实现。这意味着系统仍然不够安全。
我可以创建一个新的 Windows 用户，但这意味着该用户的密码必须保持安全，这意味着我们回到了第 1 步，保护用于访问某些秘密信息的密码。
一定有更简单的方法，有什么想法吗？
I am using Microsoft Access 2010 with unbound forms. No linked tables allowed, otherwise the connections string is stored in the table definitions. So it follows that we will use a query definition with no name to access SQL SERVER. This is recommended by Microsoft. We need to get the connection string from somewhere though. So it is recommended to return it from a method with a obfuscated name. It is recommended not to embed the connection string in plain text in the application source. So we use encryption.
A good way of doing this is to require the applications administrator to define the connection string at the first run of the application and according to this msdn article
...encrypt its value via DPAPI with a user-specific key of the account under which the application runs, and save the encrypted value in the Windows registry.
The accde launches from the logged on windows user account, after which the apps admin can login and setup the connection to the database, following the recommendations above.
The weakest link i now seem to have is the windows user account. It seems that anyone logged in to that account could decrypt the connectionstring if they knew the implementation of the security scheme. Which means that the system still is not secure enough.
I could create a new windows user, but that would mean that the password for that user must be kept safe, which means we are back at square 1, securing the password that is used to access some secret information.
There must be an easier way, any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否需要在会话之间保留连接字符串？您是否可以在应用程序中构建一个登录表单，在其中接受用户的凭据、服务器实例和他们将连接到的数据库名称，并在应用程序运行时将此信息保留在内存中？
这可能提供更大的灵活性，因为管理员可以决定将数据库移动到新服务器，而不必担心解密连接字符串以更改它并重新加密它。它还允许定义多个数据库 - 我正在考虑这样一种情况，在推出到生产服务器之前，您将定义一个 QA 服务器来测试更改。
Is there a reason you need to persist the connection string from session to session? Could you instead build a log-in form in your application where you accept the user's credentials, server instance and database name that they will be connecting to and keep this information in memory while the application is running?
This might provide more flexibility in that the administrator could decide to move the database to a new server and wouldn't have to worry about decrypting the connection string to change it and re-encrypt it. It would also allow for multiple databases to be defined - I'm thinking of a situation where you would have a QA server defined for testing changes before rolling out to the production server.