logo标签列表

如何控制用户对Access数据库的权限？

ms-accesspermissions
7

如何在本地网络上最简单地允许一个用户具有写入权限，而其他所有人只有只读权限来访问 MS Access 数据库？

我相信我的用户，但不幸的是，Access 将更改保存到数据时，只要表的一行被取消选择。即使用户没有请求保存更改，意外按键也会被保存。

我认为您的问题标题有误。您询问的不是安全性，而是控制用户对数据的权限。这可以通过Jet ULS安全性来实现，除非您使用的是Access 2007 ACCDB格式。 - David-W-Fenton
6个回答
9
关于控制Jet数据存储用户权限的一些想法：

  1. 如果您真的想锁定事物，那么您永远无法通过Jet来管理它，因为用户必须具有对MDB文件的写访问权限，这使其固有易受攻击。

  2. 如果您满足于控制前端应用程序中数据的权限，则可以提供不同的前端（一个用于WRITE用户，一个用于只读用户）。

  3. 如果您没有使用ACCDB格式，则可以使用Jet用户级安全性。 如果您真的想要限制对数据的访问，则必须严格遵循Jet Security White Paper中的所有说明，否则您的数据将向任何拥有标准Jet工作组文件的人开放。 即使完成了所有步骤，它也是可破解的（但需要花费$$$购买破解软件）。 顺便说一下，Access 2007之前的数据库密码完全无用且容易被破解。 Access 2007通过提高数据加密级别增强了安全性，但是数据库密码会引起许多问题，并且不允许您具有多个访问级别（除非您提供具有不同密码的两个不同前端-参见＃2）。

  4. 如果您只想在前端应用程序中使用Jet ULS控制访问权限，则可以将用户添加到组中，然后在前端UI对象（即表单）中检查组成员身份，并授予具有该级别访问权限的用户WRITE权限。 假设您具有比WRITE权限更多的只读用户，则最简单的方法是让只读用户作为默认管理员用户登录（即，对其设置不做任何操作），并让WRITE用户作为具有WRITE权限的用户组中的用户登录。 换句话说，如果他们没有作为用户“admin”登录，则他们具有完全的WRITE访问权限。

  5. 另一种选择是使用NTFS安全组。 该API代码可在Access Web上找到，但它需要Windows管理员来为您实现。 再次强调，您将限制前端应用程序中的访问，而不是实际限制后端MDB中的用户权限。

只有Jet ULS实际允许您防止只读用户（未破解工作组文件的用户）编辑数据。 所有用户都必须能够访问后端MDB的网络，但是即使不跳过实施Jet ULS的步骤，您也可以使他们难以访问数据。以下是一些步骤（是一种“安全性通过混淆”的形式，只会减缓决心破解您的后端的只读用户）：

  1. 在后端数据库中右键单击每个表格并打开 HIDDEN 属性。这也可以在代码中完成（请参见帮助中的 SetHiddenAttribute）。当然，如果最终用户将其 Access 选项设置为显示隐藏的表格，则此操作将无效。但是大多数最终用户不知道这一点，如果您的用户在运行时中运行应用程序，则他们将无法选择此选项。

  2. 更改后端数据库的启动属性，使其不显示数据库窗口并且不使用特殊键。您可以在“AllowBypassKey”帮助主题中找到设置启动属性的代码。

  3. 在后端中创建一个名为 AutoExec 的宏，并添加一个命令 Quit。如果禁用了特殊键，则没有办法阻止执行此宏，而且只要用户尝试打开后端（即使他们按住 SHIFT 键，即绕过所有启动例程的标准按键），数据库（以及 Access 实例）将关闭。

现在，所有这些都可以被知道如何做的人撤销。如果你给我一个实施了这些事情的后端，我只需在另一个 Access 数据库中运行代码即可更改所有这些启动属性以获得访问权限。

但是您的最终用户可能没有那种专业知识。任何这样的用户都应该是 WRITE 用户，对吧？ :)

当然，所有这些事情都可以很容易地被擅长的人破解。但是对于拥有正确工具的人来说，在几秒钟内轻松闯入您的房子也是很容易的。这并不意味着您不锁门，即使它不能完全防止入室盗窃。

另一个考虑因素是，如果您为用户提供的只是 Access 运行时而不是完整的 Access，则他们将无法撤消您的后端 MDB 中的任何设置。

最后：

安全性不仅仅是技术问题 - 实际上，大部分是人员问题。为了让人们完成工作，您必须在一定程度上信任他们以获取对数据的访问权限。例如，没有可靠的系统管理员问题的技术解决方案，而保护数据的唯一方法是根本不给他们任何访问权限。

@David 谢谢您的建议！我已经澄清了我的问题，因为我认为我们需要一个更简单的解决方案。 - Liam
6
最简单的方法是使用共享权限。将写访问权限授予一个组，并将必须对数据库进行写操作的用户放入该组中。将其他所有人放入读取组中。当然，这假设您拥有Windows域。 这里是一个网站，其中提供了一些有关保护Access数据库的信息。它涉及到Access 2000，可能有更多新版本的选项。
访问Access数据库出现问题的一个非常普遍的原因是并非所有用户都对目录拥有完全权限。 - Fionnuala
1
实际上，他们不需要完全的权限 - 只需要除了删除权限之外的所有权限。这意味着LDB文件不会被删除，但这并不重要。这是Jet在3.0版本之前默认的工作方式。 - David-W-Fenton
1
谢谢，将.mdb文件放在一个共享文件夹中，其中只有一个用户拥有完全权限，而其他用户仅具有读取权限似乎很好地解决了问题。 - Liam
1

这是一个调皮的回答，但如果你需要更好的安全性，认真考虑升级到一个更强大的关系数据库管理系统（RDBMS）。

1
我认为Access旨在成为个人桌面的简单数据库，而不是多用户企业解决方案。如果是这样的话，就没有理由使用SQL Server了。 - duffymo
1
我也曾这么想，但我经常看到网络上共享的Word文档和电子表格，而大多数人也同样对待Access。 - Liam
很遗憾，我曾经在某个地方不得不编写一个多用户访问数据库，因为他们不给我们 SQL Server。可以说这是一种痛苦的经历。 - Neil Aitken
@Neil：SQL Server Express（或过去的MSDE）可以解决这个问题。 - HardCode
1
我认为使用ODBC连接，可以将Access作为接口连接到几乎任何数据库。例如，我已成功地配置了一个SQL Server 2008 Express Edition数据库，其中包括两个用户，一个具有读/写权限，另一个只读权限。通过打开ODBC数据源，我已能够从Access连接到数据库。因此，用户可以使用他们熟悉的基于Office的报告生成和邮件合并功能。但是可以连接到任何数据库服务器。
是的，你肯定会选择 SQL Server Express 而不是 .MDB 后端。很好的选择！ - HardCode
1
这段对话可能有点老了，但出于某些原因，我最近遇到了同样的问题。它不适用于每个人，因为它不依赖于M$ SQL Server，而是依赖于MySQL。使用MySQL ODBC连接器（可在此处下载：http://dev.mysql.com/downloads/connector/odbc/），并将您的表存储在MySQL服务器上。Access用户对表的权限将继承自MySQL用户的权限。非常容易定制...
0
事实是，对于访问数据库，没有功能性安全性。
下面的链接销售软件，即使有密码，也可以“恢复”您的访问数据库。
很高兴他们存在。当我的一个客户的前任程序员去世，没有其他人知道密码时，他们的程序曾经拯救了我的客户。由于这个程序，我们能够进入数据库，没有数据丢失。

http://www.stellarinfo.com/access-recovery.htm

在你想到之前，我要声明一下，我并不为他们工作。

数据库密码确实不是特别安全的设备。但这并不意味着不存在“功能性安全措施”。在2007年之前，用户安全模型相当强大。我怀疑 Stellar Info 工具无法运行于2007年之前的用户安全系统，并且我没有看到其支持的2007版本。 - John Mo
不，.mdb文件上确实没有功能性安全保障。有更多的免费工具可以从中提取密码，因为写一个这样的工具是微不足道的。借助此文档：http://jabakobob.net/mdb/first-page.html ，我可以在半天内使用各种编程语言编写一个很好的控制台应用程序来提取密码。 "用户安全模型"可能很强大，但它相当于一扇紧挨着无法解锁的窗户旁边的钢芯门。 - Rob K
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接