MS Access 数据库的密码保护和其他安全措施

Posted 2023-05-06

【中文标题】MS Access 数据库的密码保护和其他安全措施

【英文标题】：Password protection and other security measures for MS Access database

【发布时间】：2011-07-14 18:10:36

【问题描述】：

有人要求我尽可能以***别保护 Access 数据库，但有人告诉我密码保护文件是不够的。我们有非常敏感的数据，我需要尽最大可能保护它。有什么想法吗？

【问题讨论】：

移至 SQL Server。如果前端可以打开你的后端文件，那么用户也可以。

“可能的***别”意味着您不能使用 Jet/ACE 作为数据存储。显然，如果阻止您升级到服务器后端，那么您将无法确保“尽可能高的级别”。

我刚刚发现，您可以从 Access 数据库中将宏、查询和表导出到另一个受密码保护、加密和编译的 Access 数据库。我认为这是一个严重的安全漏洞。

【参考方案1】：

这是我多年来使用 Access 2003 时遇到的问题。我们在数据库上设置了数据库密码以将其锁定，因此用户需要密码才能访问它。不一定是最好的选择，也是一种痛苦。

由于您使用的是 MS Access 2007，因此您可能需要查看 Microsoft 所说的数据库保护选项。

【讨论】：

数据库密码是浪费时间——安全剧院，而不是真正的安全。

我同意，但我们必须在重写应用程序时实现一些东西。

【参考方案2】：

首先，在讨论安全性时，我们必须定义威胁模型。

常见的威胁有：

未经授权访问数据：不应读取数据的人能够读取数据。 未经授权修改数据：不应修改数据的人能够修改数据 未经授权的数据破坏/损坏：有人能够破坏数据库 权限提升：应该能够读取或写入某些数据的人能够读取或写入超出预期的次数 数据泄露：应该能够读取某些数据的人能够复制大量数据并将其移动到外部（或受保护较少的）系统。 恶意软件插入：有人能够将恶意代码插入应用程序

如前所述，Access 的主要防御措施是encrypting the database using a database password。使用 accdb 文件时，这通常可以提供足够的保护，防止未经授权的访问和修改数据。这是一种“一刀切”的方法，有一个密码，如果你有它，你就拥有所有的权限，可以随意读取、写入和插入组件。此外，当您对文件有写入权限但没有密码时，您可以损坏或删除文件。

更高的级别是保护访问文件：使用安全文件服务器仅将文件提供给应该有权访问它的人。这几乎具有加密的所有好处，并且还可以防止破坏，因为未经授权的用户无法访问文件。这也允许我们撤销对该文件夹的权限，假设用户没有制作副本。

如果我们想使用用户权限，我们可以将文件分成不包含特权数据的前端文件和多个后端文件，并分别保护这些文件，方法是为每个文件使用不同的密码文件，或将它们存储在单独的安全位置。同样，安全位置提供了防止破坏的额外好处。

由于 Access 要求用户对文件（用于放置锁）具有写入权限才能具有读取权限，但是，我们不能通过这种方式轻松分离读取和写入权限。我见过的一种方法是使用“影子文件夹”，其中为读取用户创建了一个虚拟文件夹，并且在访问该文件夹时，将最新的数据库文件放入其中，并且每次都被覆盖。然而，设置它并非易事。

另一种非常常见的方法是尝试使用 VBA 来限制用户可以执行的操作，并只允许他们打开特定的表单并对其执行特定的操作。这可能与禁用旁路密钥和/或创建没有原始代码的编译副本 (accde/mde) 等技巧相结合。但是，这些只会阻止新手攻击者，并且实际上总是可以绕过，方法是使用非 Access 程序读取数据（这将忽略 VBA 施加的任何限制），允许通过 COM 绕过密钥，完全禁用 VBA机器等。编译后的数据库只能查看和修改代码，而不是数据，专家也可以通过手动重构代码来绕过这一点（例如commercial service that offers this）。因此，虽然这乍一看似乎是适当的安全措施，但它存在严重缺陷。

编译代码与签署代码结合使用时非常有用，可防止未经授权的恶意软件插入。由于反编译、修改然后重新编译的副本没有有效的签名，假设攻击者无法访问用于签署代码的可信证书，并且系统可以配置为不打开没有该签名的编译数据库，这可以提供帮助检测对数据库的恶意修改。

如果我们想拥有单独的用户权限，但无法使用单独保护的文件夹强制执行此操作，则可以选择使用不同的密钥单独加密后端。出于可用性目的，我们可以使用密钥加密密钥为每个用户设置一个单独的密码，并让该密码授予对允许用户使用的后端的访问权限。我创建了一个使用密钥加密密钥for this Q&A 的数据库示例，但现在我会进行一些更改，例如使用带有 KEK 和链接表到加密数据库的单个前端，并使用用于在 VBA 中快速加密的 CNG API。

请注意，其中一些选项会增加很多复杂性，并且没有一个选项可以适当地防止数据泄露（这在我工作的国家和部门中是一个日益严重的威胁）。通常，在基础架构、管理等方面，使用与 Access 不同的后端要简单得多。这仍然可以让您将 Access 用作前端，因此用户甚至可能不会注意到更改，但权限管理由后端确定，后端可以通过为每个用户使用不同的密码来保护，或者，以防万一SQL 服务器，通过将安全性链接到 AD 域 (SSPI)。

在 SQL Server 中，我们还可以添加日志记录，通过仅授予存储过程权限来限制获取大型数据集，并随着时间的推移限制请求数量，以减少数据泄露。但是，如果您只使用存储过程链接表不可用并且 Access 往往会发出不必要的请求，那么这给使用 Access 作为客户端带来的额外复杂性通常会使选择不同的客户端更加明智。

请注意，在选择使用不同的后端时，仍然建议编译和签署Access数据库以缓解恶意软件插入，这不依赖于所使用的后端。

---

奖金：

用户级别的安全性如何？这是一项专门为每个用户提供读写权限的技术，以及用于修改数据库和管理用户的单独权限。不幸的是，它是不安全的，有很多工具可以删除它，而且它只适用于 mdb 和 mde 数据库格式，所以没有任何用处。

当然，您还可以通过保护运行 Access 的环境来保护用户。我见过一个部署，其中用户只被允许访问防火墙后面的虚拟环境中的资源，不允许所有互联网访问, 仅限于打开这个特定的数据库，不允许存储设备，并且不与主环境共享剪贴板。这允许您使用 VBA 拥有一个安全的数据库，但严重限制了数据库的可用性（尤其是复制粘贴限制让用户感到沮丧，但复制和粘贴可用于数据泄露）。

【讨论】：

-1，所有用户使用一个允许所有人完全读/写的密码是不合适的。归根结底，编译后的 accde 可以反转为 accdb。

@FrankR。阅读完整答案。它包含 4 个不同的选项，用于保护每个用户具有单独密码的 Access 数据库。此外，这里讨论了将 accde 恢复为 accdbs，并且正如所讨论的，acde 的唯一真正优势是它在签名时可以防止恶意软件插入。此外，这简直就是事实。如果您有更好的解决方案，请随时提供您自己的答案，但我讨论了所有合理的解决方案。

更好的解决方案是不将 Access 用作前端或后端。尽管您有所有的 Access 安全剧院，但它根本不够用。需要更高的安全级别。

@FrankR。首先，阅读帖子的结尾（在奖金之前），这就是我说使用不同后端的地方。其次，Access+SQL server做后端，Access数据库编译签名，未签名的数据库不信任（默认）有什么问题？那是可靠的安全，而不是安全剧院。如果你依赖你的代码是秘密的，那么这就是默默无闻的安全性，如果数据库是签名的，那么对代码的任何修改都会使签名无效。

【参考方案3】：

我建议你把它放在文件服务器上，并有一个严格的访问控制列表。

在数据库中强制用户登录然后 添加触发器以在记录更改时写出审计信息（使用用户信息、日期/时间）。