这正朝着 RBAC(基于角色的访问控制)的方向发展。您可能还想知道是否使用 LBAC - 基于标签的访问控制。而且,根据您的 DBMS,可能还有其他方法可以实现它(例如,考虑 Oracle VPD - 虚拟私有数据库)。所有这些要么是特定于 DBMS 的,要么是非常特定于 DBMS 的——针对不同 DBMS 的不同解决方案。
您似乎在谈论行级别的控制。也就是说,联系人表中的一行可能每个人都可以访问,而另一行只能被一组部门访问,另一行只能被一组人访问,等等。
请记住,关系 DBMS 最适用于集合。单个组是具有一个成员组的一组组;单个用户是具有一个成员用户的一组组。这意味着我们要处理的案件更少。
如果您想在标准 SQL 中实现它,那么我认为您将需要结合使用视图来利用与控制表的连接等。这种系统的难点在于填充控制表并限制管理用户(实际上,约束管理员始终是最困难的部分之一)。
基本技术是:
- 创建具有适当列的基表,以标识适用于表中每一行的权限集。
- 撤销对表的所有公共访问权限。
- 在基表上创建一个视图,该视图显示基表中允许的所有列。这将是一个带有控制表的连接视图,需要立即定义。视图查询条件也将由当前用户决定。
- 授予对视图的适当访问权限。
- 在视图上创建适当的 INSTEAD OF 触发器以处理视图上的插入、删除和更新操作,将更改中继到基表。
- 创建控制表以与基表连接。
- 用适当的数据填充它。
- 浅蓝色触摸纸,靠背站立。
现在,关于那个连接列和控制表......
有人必须指定哪些权限适用于表中新插入的行 - 提供的默认访问权限是什么。并且必须有人定义如何覆盖默认访问权限。两者都可能很混乱。
有几种方式来构造控制表:
一种机制依赖于具有唯一 ID 的基表中的每一行(可能是自动生成的 ID 或只是主键的值)。然后,控制表包含该唯一 ID 的副本,并定义哪些用户或组可以访问它。这意味着对于给定的行,控制表中可能有多个条目,每个可以访问该行的用户或组都有一个条目。在此方案中,控制表具有引用基表的外键。
另一种机制将 ID 号嵌入到作为控制表的外键的基表中。它基本上标识了一组权限,基表中的引用意味着该行具有与访问控制ID相关联的访问权限。控制表背后的结构可能是 ID 0 对任何人都没有访问权限(通过视图),ID 1 对每个人都有访问权限,其他值指定用户和组的组合 - 每个不同的组合都有不同的 ID。有了这个,控制表集中可能有几个表 - 我们也在讨论为每个受保护的表设置一组这些控制表。
显然,对控制表的访问受到严格限制——但对于管理谁可以看到什么也至关重要。
这两者都是管理方面的噩梦——这就是为什么您最终可能会使用 DBMS 提供的访问控制机制而不是通用的 SQL 解决方案。