MS Access 数据库的密码保护和其他安全措施
我被要求以尽可能高的级别保护 Access 数据库，但有些情况告诉我密码保护文件是不够的。我们拥有非常敏感的数据，我需要最大程度地保护它。有什么想法吗？
I have been asked to secure an Access database at the highest level possible, and something tells me password protecting the file is not sufficient. We have really sensitive data and I need to protect it to the greatest extent possible. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是我多年来在使用 Access 2003 时遇到的一个问题。我们在数据库上设置了数据库密码来锁定它，以便用户需要密码才能访问它。不一定是最好的选择，而且有点痛苦。
由于您使用的是 MS Access 2007，因此您可能需要查看 Microsoft 说是数据库保护选项。
This has been an issue that I have had for several years with Access 2003. We set a Database Password on the database to lock it down so users would need the password to access it. Not necessarily the best option and kind of a pain.
Since you are using MS Access 2007 you might want to check out want Microsoft says are database protection options.
首先，在讨论安全时，我们必须定义威胁模型。
常见的威胁有：
正如所讨论的，Access 的主要防御措施是 使用数据库加密数据库密码。使用 accdb 文件时，这通常可以提供足够的保护，防止未经授权的访问和修改数据。这是一种“一权限适合所有人”的方法，有一个密码，如果你拥有它，你就拥有所有权限，并且可以随意读取、写入和插入组件。此外，当您拥有该文件的写入权限但没有密码时，您就可以损坏或删除该文件。
更高的级别是保护访问文件：使用安全文件服务器仅将文件提供给那些应该有权访问它的人。这几乎具有加密的所有优点，并且还可以防止破坏，因为未经授权的用户无法访问该文件。假设用户尚未制作副本，这还允许我们撤销对该文件夹的权限。
如果我们想使用用户权限，我们可以将文件分为一个不包含特权数据的前端文件和多个后端文件，并通过为每个文件使用不同的密码来单独保护这些文件，或者将它们存放在单独安全的位置。同样，安全位置还提供了防止破坏的额外好处。
然而，由于 Access 要求用户拥有文件的写权限（用于放置锁）才能具有读权限，因此我们无法轻松地通过这种方式分离读写权限。我见过的一种方法是使用“影子文件夹”，其中为读取用户创建一个虚拟文件夹，并且在访问该文件夹时，最新的数据库文件被放置在其中，并且每次都会被覆盖。然而，设置这一点并不简单。
另一种非常常见的方法是尝试使用 VBA 来限制用户可以执行的操作，并只允许他们打开特定的表单并对其执行特定的操作。这可能与禁用旁路键和/或创建没有原始代码的编译副本（accde/mde）等技巧相结合。然而，这些只会阻止新手攻击者，并且实际上总是可以被绕过，方法是使用非 Access 程序读取数据（这将忽略 VBA 施加的任何限制），允许通过 COM 绕过密钥，完全禁用 VBA编译后的数据库只会导致无法查看和修改代码，而无法查看和修改数据，专家也可以通过手动重构代码来绕过这个问题（例如 提供此服务的商业服务）。因此，虽然乍一看这似乎是适当的安全措施，但它存在严重缺陷。
与对代码进行签名结合使用时，编译代码非常有用，可以防止未经授权的恶意软件插入。由于反编译、修改然后重新编译的副本不会有有效的签名，假设攻击者无法访问用于签署代码的受信任证书，并且系统可以配置为在没有该签名的情况下不打开已编译的数据库，这会有所帮助检测数据库的恶意修改。
如果我们想要拥有单独的用户权限，但无法使用单独的安全文件夹强制执行此操作，则可以选择使用不同的密钥单独加密的后端。出于可用性目的，我们可以使用密钥加密密钥为每个用户提供单独的密码，并让该密码授予对允许用户使用的后端的访问权限。我已经创建了一个使用密钥加密密钥用于此问答的数据库示例，但现在我会一些更改，例如使用具有 KEK 和加密数据库链接表的单一前端，以及使用 CNG API 在 VBA 中进行快速加密。
请注意，其中一些选项增加了很多复杂性，并且没有一个能够正确防止数据泄露（这在我工作的国家/地区是一个日益严重的威胁）。通常，就基础架构、管理等而言，使用与 Access 不同的后端要简单得多。这仍然允许您使用 Access 作为前端，因此用户甚至可能不会注意到更改，但权限的管理由后端决定，可以通过为每个用户使用不同的密码来保护后端，或者以防万一SQL Server 的安全性，通过将安全性链接到 AD 域 (SSPI)。
在 SQL Server 中，我们还可以添加日志记录，通过仅授予存储过程权限来限制获取大型数据集，并限制一段时间内的请求量，以减少数据泄露。但是，如果仅使用存储过程，则链接表不可用，并且 Access 往往会发出不必要的请求，因此使用 Access 作为客户端会增加复杂性，这通常会使选择不同的客户端更加明智。
请注意，当选择使用不同的后端时，仍然建议对 Access 数据库进行编译和签名，以减少恶意软件插入，这与所使用的后端无关。
奖励：
用户级安全性怎么样？该技术专门用于提供每个用户的读写权限，以及修改数据库和管理用户的单独权限。不幸的是，它不安全，有很多工具可以删除它，而且它仅适用于 mdb 和 mde 数据库格式，因此没有任何用处。
当然，您还可以通过保护 Access 运行的环境来保护用户的安全。我见过这样的部署：仅允许用户访问虚拟环境中的资源，该虚拟环境位于防火墙后面，不允许所有 Internet 访问，这是有限的只打开这个特定的数据库，不允许存储设备，并且不与主环境共享剪贴板。这允许您使用 VBA 拥有一个安全的数据库，但严重限制了数据库的可用性（尤其是复制粘贴限制让用户感到沮丧，但复制和粘贴可能会用于数据泄露）。
First, when discussing security, we have to define the threat model.
Common threats are:
The main defense for Access, as discussed, is encrypting the database using a database password. When using an accdb file, this generally offers sufficient protection against unauthorized access and modification of the data. This is a "one privilege fits all" approach, there is one password, if you have it, you have all privileges and can read, write, and insert components at will. Also, when you have write access to the file, but not the password, you are able to damage or delete the file.
A level higher is securing the Access file: using a secure file server to only serve the file to those who should have access to it. This comes with practically all benefits of encryption, and protects against destruction too, as unauthorized users cannot access the file. This also allows us to revoke rights to that folder, assuming the user hasn't made a copy.
If we want to work with user rights, we can separate the file into a front-end file, which does not contain privileged data, and multiple backend files, and secure these files separately, by either using a different password for each file, or storing them on separately secured locations. Again, secure locations offer the additional benefit of protecting against destruction.
Since Access requires users to have write permission to the file (for placing locks) to have read access, however, we can't easily separate read and write permissions this way. One approach I've seen used is using a "shadow folder", where a virtual folder is created for read users, and upon accessing the folder, the most recent database file is placed in it, and overwritten each time. Setting this up, however, is nontrivial.
Another approach which is very common is trying to use VBA to limit which actions users can take, and allowing them only to open specific forms and take specific actions on them. This is possibly combined with tricks like disabling the bypass key, and/or creating a compiled copy (accde/mde) without the original code. However, these will only stop novice attackers, and can practically always be bypassed, either by using a non-Access program to read the data (which will ignore any restriction imposed by VBA), allowing the bypass key through COM, disabling VBA altogether on the machine, etc. A compiled database only makes it impossible to view and modify the code, not the data, and this also can be bypassed by experts by manually reconstructing the code (example commercial service that offers this). Thus, while this may look like proper security at first glance, it has severe flaws.
Compiling the code is useful when combined with signing the code, to protect against unauthorized malware insertion. Since a decompiled, modified and then recompiled copy won't have a valid signature, assuming the attacker can't access the trusted certificate used to sign the code, and systems can be configured not to open compiled databases without that signature, this can help detect malicious modification of the database.
If we want to have separate user privileges, but cannot enforce this using separately secured folders, an option is to have separately encrypted backends with different keys. For usability purposes, we can use a key encryption key to have a separate password for each user, and have that password grant access to the backends which the user is allowed to use. I've created a sample of a database that uses key encyption keys for this Q&A, but nowadays I'd make some changes, such as using a single front-end with both the KEKs and linked tables to the encrypted databases, and using the CNG API for fast encryption in VBA.
Note that some of these options add a lot of complexity, and none properly protects against data exfiltration (which is an increasing threat in the country + sector I work in). Often, it's a lot more simple, in terms of infrastructure, management, etc. to use a different back-end than Access. This can still allow you to use Access as the front end, so users might not even notice a change, but management of permissions is determined by the back end, which can either be secured by using different passwords for each users, or, in case of SQL server, by linking security to an AD domain (SSPI).
In SQL server, we can also add logging, restrict fetching large datasets by only granting rights to stored procedures and limit the amount of requests over time, to mitigate data exfiltration. However, the added complexity this brings to using Access as a client often makes choosing a different client more sensible, if you only use stored procedures linked tables are not available and Access tends to make more requests than necessary.
Note that when choosing to use a different back-end, it is still recommended to compile and sign the Access database to mitigate malware insertion, which is not dependent on the back-end used.
Bonuses:
What about user-level security? That was a technology specifically intended to offer per-user read and write rights, and separate rights for modifying the database and managing users. Unfortunately, it was insecure and there are many tools out there to remove it, and it only applies to the mdb and mde database formats, so is not of any use.
And, of course, you can also secure the user by securing the environment that Access runs in. I've seen a deployment where users are only allowed to access resources in a virtual environment that is behind a firewall disallowing all internet access, is limited to only opening this specific database, doesn't allow storage devices, and doesn't share the clipboard with the main environment. That allows you to have a secure database by using VBA, but severely limits usability of the database (especially the copy-paste limitation frustrates users, but copying and pasting could be used for data exfiltration).
我建议你把它放在文件服务器上并有严格的访问控制列表。
然后在数据库中强制用户登录
添加触发器以在记录更改时写出审核信息（使用用户信息、日期/时间）。
I would suggest you put it on a file server and have a strict access control list.
In the database force users to log in then
add triggers to write out audit info when a record changes (with the user info,date/time).