保护 Access 前端的建议

如何解决保护 Access 前端的建议

我有一个相当大的 Access 数据库，我将把它带入 21 世纪。后端已经改成sql Server而不是MDB了，我正在考虑怎么处理前端，也是MDB。我对用户级安全性非常满意，并广泛使用它来管理对数据和前端元素的权限。这是我第一次使用 ACE/Accdb 进行开发，由于它不支持用户级安全，那么保护表单、查询、报告等的最佳方法是什么？除了已编译的前端之外还有什么吗？

解决方法

嗯，作为一般规则，用户级别安全性 (ULS) 用于确定哪些用户可以打开什么表单或什么报告。但是，ULS 并不是真正以“锁定”应用程序为目的。他们是两个截然不同的目标。公平地说，ULS 可以帮助锁定事物 - 但它更倾向于控制用户可以打开或使用应用程序的哪些部分。

而且在大多数情况下，ULS 不会说锁定 Access UI 位和部件的使用。因此，您的应用程序将“工作”或“寻求”以隐藏内置的 Access 部件。这实际上是编译后的 accDB 可以提供巨大帮助的地方。（因为已编译的应用程序已删除源代码，并且还禁用了在设计模式下打开表单/报表和代码的功能。

accDE 的另一大优势？好吧，任何未处理的代码错误都不会重新设置局部或全局变量。（因此您的可靠性得到了相当大的提高）。编译后的 accDE 的另一个优点当然是使用免费的运行时。这意味着工作站和用户不需要包含 Access 的付费 Office 副本。

所以运行时 + 编译好的 accDE 有不少好处。（隐藏和锁定 Access UI 就是这样一种好处）。事实上，作为运行时运行意味着无法使用内置的功能区和菜单。并且如前所述，没有源代码或没有针对代码或表单/报告的设计能力可以使事情处于锁定状态。

因此，上面的内容在很大程度上意味着 ULS“更多”用于控制谁可以使用应用程序的哪些部分——而不是在更改或修改应用程序方面锁定用户的部分（正如我所说的——两个不同的目标）。

因此，如果没有任何 ULS 安全措施，您可以像鼓一样严密地锁定应用程序部分。

然而，虽然在锁定更改和窥探应用程序方面失去 ULS 没什么大不了的？对于谁可以在应用程序中做什么，这无疑是控制系统中的一大损失。并且由于您没有 ULS，因此您不能使用 ULS 来控制谁可以做什么，也不能使用 ULS 来防止用户做诸如设计模式之类的事情。所以，现在这在很大程度上表明您需要编写代码防止某些用户打开表单 - 您必须为此编写代码。

我当然会遵循用户的经典模型，然后这些用户属于给定的组。如您所知，如果您在 Access 中正确执行此操作，那么您可以在场外获取 FE（前端应用程序部分）的副本。他们可以在现场更改用户属于哪个安全组。只要他们从未将用户分配给给定的对象（表单/报告等），那么您就可以更新 + 部署新版本的软件和所有安全内容，甚至将一些用户添加到“销售组”继续工作 - 即使您更新并部署了新的 FE。但是，一旦您将用户分配给安全组之外的任何其他内容，整个过程就会中断。

上面说了？你必须自己滚动。您可能会创建一个返回安全信息的 SINGLE 函数。然后，您可以使用打开时（而非加载时）的表单。如果您设置取消 = true，则相关表单将不会加载且不会显示。因此，您可以在表单（或报告）打开事件中基于此单一功能改进安全模型。在大多数情况下，该事件中几乎没有或没有现有代码（on-open 事件不允许修改表单上的绑定控件 - 您必须等待并将此类代码放入 on-load 事件中。

所以，你必须自己动手。而且由于您在 VBA 代码中无法真正“阻止”用户在设计模式下打开表单？如果您想要至少“某种”合理的安全级别，那么您就必须采用已编译的 accDE。

根据我的经验，MS Access“安全性”是海市蜃楼。最好使用 Windows 安全性并使用多个不同的编译前端，每个前端都受到保护。

@June7 是对的，这不是一个适合 SO 的问题。