保护访问前端的建议

Question

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

Answer 1

作为一般规则，用户级安全性(ULS)用于确定哪些用户可以打开哪些表单或报表。然而，ULS实际上并不是为了“锁定”应用程序。这是两个截然不同的目标。现在公平地说，ULS可以帮助锁定东西-但它更多的是为了控制用户可以打开或使用应用程序的哪些部分。

在大多数情况下，UI不会说锁定访问UI位和部分的使用。因此，您的应用程序将“工作”或“寻找”，以保持内置的访问部分隐藏。事实上，编译后的accDB可以提供极大的帮助。(因为编译的应用程序剥离了源代码，并且还禁用了在设计模式下打开窗体/报表和代码的功能。

accDE的另一个大优势是什么？任何未处理的代码错误都不会重新设置局部或全局变量。(所以你的可靠性得到了很大的提高)。编译后的accDE的另一个优点当然是使用免费的运行时。这意味着工作站和用户不需要包含访问权限的付费office副本。

所以运行库+一个编译好的accDE有很多好处。(隐藏和锁定访问UI就是这样的好处之一)。实际上，作为运行时运行意味着内置的功能区和菜单不能使用。如上所述，没有源代码或没有针对代码或窗体/报告的设计能力会让事情变得很糟糕。

所以上面的意思很大程度上意味着ULS更多的是为了控制谁可以使用应用程序的哪些部分-而不是从改变或修改应用程序的角度来真正地锁定用户的部分(正如我所说的-两个不同的目标)。

因此，在没有任何ULS安全性的情况下，您可以很好地将应用程序部分锁得像鼓一样紧。

然而，虽然ULS在锁定更改和窥探应用程序方面的损失并不是什么大问题？在控制系统中，谁可以在应用程序中做什么，这肯定是一个很大的损失。既然你没有ULS，那么你就不能用ULS来控制谁可以做什么，也不能用来阻止用户做设计模式之类的事情。所以，现在很大程度上表明你需要编写代码来阻止一些用户打开表单-你必须为此编写代码。

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

上面说过了吗？你必须自己动手。您可能会创建一个返回安全信息的函数。然后，您可以在打开时(而不是加载时)使用表单。如果设置cancel = true，则不会加载和显示有问题的表单。因此，您可以基于表单(或报告) on-open event中的这一单个函数，很好地调整安全模型。在大多数情况下，该事件中几乎没有现有代码( on -open事件不允许修改窗体上的绑定控件-您必须等待并将这些代码放在on-load事件中。

所以，你必须自己动手。既然你在VBA代码中不能真正“阻止”用户在设计模式下打开表单，那该怎么办呢？然后，如果您想要至少“一些”合理的安全级别，那么您必须采用已编译的accDE。

Answer 2

在我的经验中，MS Access的“安全性”是一种幻觉。更好的做法是使用Windows安全性，并使用多个不同的编译前端，每个前端都受到保护。

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