2

如何设计权限系统?

 1 year ago
source link: https://www.jdon.com/64695.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

如何设计权限系统?

23-01-25 banq


权限系统可以简单理解为权限限制,即不同的人拥有不同的权限,看到的和能用的可能不一样。对应于一个系统,一个用户可能有不同的数据权限和操作权限。
主流的权限模型主要有两种:

  • ACL 模型:访问控制列表
  • RBAC 模型:基于角色的访问控制

1.ACL模型:访问控制列表

Access Control List,ACL是最早也是最基本的访问控制机制。它是一种基于对象的控制模型,在其他模型中也使用了ACL。为了解决一一配置相同权限用户的问题,后来也采用了用户组的方式。

原理:每个客体都有一个列表,记录了哪些主体可以对这个客体做哪些行为,很简单。
例如:当用户A要编辑一篇文章时,ACL会先检查文章编辑功能的控制列表中是否有用户A。
又如:不同级别的会员可以使用产品中不同的功能。

缺点:当受试者数量较多时,配置和维护工作成本高且容易出错。

2. RBAC,基于角色的访问控制

v2-dc3b6dcbfe9e0038974877773f0560ec_720w.jpg?source=d16d100b

Role-Based Access Control的核心是用户只与角色相关联,角色代表权限,是权限的集合。

RBAC的三要素:

  • 用户: 系统中的所有帐户
  • 角色:权限的集合(如管理员、开发者、审计管理员等)
  • 权限:菜单、按钮、数据的增删改查的详细权限。

在 RBAC 中,权限与角色相关联,用户通过成为相应角色的成员来获得这些角色的权限。

创建角色是为了完成各种任务,用户根据职责和资格分配相应的角色。可以轻松地将用户从一个角色分配到另一个角色。

可以根据新的需求和系统集成赋予角色新的权限,也可以根据需要收回角色的权限。角色与角色之间也存在继承关系,防止越界。

优点:角色划分容易,授权管理更灵活,授权粒度最小。

三、RBAC权限管理在实际系统中的应用
RBAC权限模型由三部分组成,分别是用户管理、角色管理和权限管理。
用户管理按企业架构或业务线架构划分。这些结构本身都比较清晰,扩展性和可读性都很好。
角色管理必须在深入理解业务逻辑之后进行设计。一般以各部门的真实角色为基础,再根据业务逻辑进行扩展。
权限管理是前两种管理方式的强化。太薄会太碎,太厚又不够安全。这里需要根据经验和实际情况进行设计。

3.1 用户管理
用户管理中的用户是企业中的每一位员工。他们有自己的组织结构。我们可以直接以企业部门架构为线索,构建用户管理系统。

v2-b39d5957300f1ab2ed287a34e9fc69b3_720w.jpg?source=d16d100b

上图企业部门架构

需要特别注意的是:实际业务中的组织架构可能与企业部门架构、业务条线架构不同,需要考虑数据共享机制。一般的做法是授权某个人或某个角色组在某个组织层面共享某个对象组的数据。

3.2 角色管理
在设计系统角色时,要深入了解公司结构和业务结构,然后根据需要设计角色和角色内部的层级。
通常,角色相对于用户是固定的,每个角色都有其明确的权限和限制。这些权限在系统设计时就确定了,以后不会轻易改变。

自动获取基础字符
员工加入部门后,员工账号自动添加到部门对应的基础角色,并拥有对应的基础权限。此操作是为了保证系统安全,减少管理员的大量人工操作。使新员工能够快速使用系统,提高工作效率。

临时角色和到期时间
公司的业务有时需要外部支持。他们不是公司的员工,只是在某个时候支持公司。这时候我们就需要设置临时角色来应对这种可能跨部门协作的临时员工。
如果公司安全级别高,这类账户默认有固定的失效时间,当达到失效时间后,需要重新审核才能重新开通。避免因流程不完善导致临时账户遗忘在系统中,造成安全隐患。

虚拟角色
部门角色中的层级可以授权同层级的员工拥有相同的权限,但部分员工因工作原因需要调用角色层级外的权限,同层级的不同员工需要不同的权限。
对于这种超出角色级别且合理的权限授予,我们可以设置虚拟角色。这个虚拟角色可以集成这个工作所需的所有权限,然后可以分配给特定的员工。这样既不需要调整组织架构和相应的角色,又能满足工作中特殊情况的权限需求。

黑白名单
白名单:部分用户不拥有某个部门的顶级角色,但由于业务需要,需要在角色之外授予高级权限。然后我们可以设计一个范围有限的白名单,把需要的用户加入进去。

在安全流程中,我们只需要为白名单设计一个安全流程,对白名单中的特殊用户进行审核,对特殊权限的用户进行监控,降低安全风险。

比较常见的黑名单场景是,一些犯错的员工,虽然在工作,但是不能再赋予他们任何公司权限。在这种既不能取消角色关联,又不能完全停用账号的情况下,可以设置黑名单,让此类用户可以登录账号查看基本信息,但大部分关键权限已经被限制黑名单。

3.3权限管理
权限管理一般限于三个方面。页面/菜单权限、操作权限、数据权限。

v2-3f0cda7689fe6aceccaf9aaa9cbc5cff_720w.jpg?source=d16d100b

上图页面/菜单权限

对于没有操作权限的用户,直接隐藏相应的页面入口或菜单选项。这种方法简单、快捷、直接,对于一些对安全性不敏感的权限非常有效。

操作权限
操作权限通常是指不同用户是否可以对同一组数据进行增删改查。某些用户的只读浏览数据,其他用户的可编辑数据。

数据权限
对于安全性要求高的权限管理,仅从前端限制隐藏菜单和编辑按钮是不够的,还需要对数据接口进行限制。如果用户试图通过非法手段编辑不属于其权限的数据,服务器将进行识别、记录和限制访问。

如何控制数据权限
数据权限分为行权限和列权限。

  • 行访问控制:看有多少条数据
  • 列权限控制:一条数据看多少字段

在一个简单的系统中,可以通过组织结构来控制行权限,可以根据角色配置列权限。但是在复杂的情况下,组织结构无法承载复杂的行权限控制,角色无法承载列的专业化展示。

目前业界的做法是提供行-列级别的数据权限规则配置,将规则分配给某个角色或某个用户​​,作为类似的权限点配置。

4 用户管理系统权限设计
4.1 超级管理员

超级管理员是用来启动系统和配置系统的帐户。配置系统并创建管理员后,应隐藏此帐户。超级管理员账号拥有系统所有权限,可以穿梭查看各部门数据。如果使用不当,会给系统管理带来安全隐患。

4.2 如何处理互斥角色
当用户已经可用的角色和待添加的角色互斥时,在添加新角色时应提示管理员由于角色互斥而无法添加新角色。如需添加,必须先撤销之前的角色,再添加新的角色。

4.3 用户管理权限体系设计必须简洁明了
在设计权限系统时,一定要理清思路,一切从简,不能添加多余的角色和权限逻辑。因为随着公司业务的扩大,权限和角色也会增加。如果一开始的设计思路不严谨,随着业务的扩大,权限体系会变得无限混乱。这个时候整理权限已经来不及了。所以初期的设计一定要清晰、简单、明了,可以避免后续很多不必要的麻烦。

4.4 未经许可的提示页面
有时候员工A会直接把自己正在处理的页面分享给员工B,但是员工B可能没有权限查看。此时,我们应该考虑在这里增加一个“无权限提示页面”,避免粗鲁的404页面让员工B认为系统出错。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK