在日常工作中,权限管理问题时时刻刻伴随着我们。当程序员刚加入一家公司时,通常需要请求开通各种权限,如网络连接、代码下载提交、监控平台登录以及运营平台数据查看等。
经常会觉得繁琐的权限申请给工作带来了不便。有时候临时需要查看某些数据,却发现没有相应的权限,就需要再次经历审批流程,这会耗费大量时间。那么,为什么我们仍然需要如此严格的权限管理呢?
一家支付公司有运营后台,可以查看所有商户信息、法人代表信息、交易信息和费率配置信息。若未加筛选地将这些信息提供给每位员工,市场人员就能操作商家的费率信息。若误操作导致费率变更,将带来巨大损失。
商户信息属于极其重要的机密,一些不良意图的员工将这些信息出售给商家的竞争对手,将给商家带来严重不良后果。尽管这些行为是个别员工的过失,但从制度上来说,若这些信息不被公开,将在很大程度上防止违法乱纪事件的发生。
总体来讲,权限管理对于公司数据安全至关重要。根据不同岗位和级别的不同,数据可见性和操作限制也各不相同。例如,涉及资金的信息只对财务相关岗位开放,涉及配置的信息只对运营相关岗位开放,这样各司其职可避免许多不必要的安全问题。
如何确保各个岗位在系统中各司其职,
这就是权限管理需要解决的问题。
Part.01
权限模型
1.1
权限设计
从业务分类角度看,权限可分为数据查看权限、数据修改权限等,在系统设计中对应页面权限、菜单权限、按钮权限等。菜单可分为一级、二级甚至三级菜单,以乐科科HR人事系统左侧菜单栏为例是,分为两级菜单。
菜单页面中包含许多按钮,最好将权限设计为树形结构,这样在申请权限时可以清晰地看到菜单结构,明确需要哪些权限。
如下图所示:
按照这个架构,按钮的父级是二级菜单,二级菜单的父级是一级菜单,这样用户申请权限时可以清晰地看到自己需要哪些权限。
1.2
为什么需要角色
权限结构梳理清晰后,需要考虑如何将权限分配给用户。在用户数量较少的情况下,可以直接进行分配,一个用户可以拥有多个权限,同时一个权限也可以被多个用户拥有。用户-权限的模型结构如下所示:
这种模型虽然能够满足基本的权限分配需求,但随着用户数量增长,其弊端变得明显。每个用户都需要分配权限,这会极大浪费管理员的时间和精力,而且用户与权限之间杂乱的对应关系将导致后期巨大的维护成本。用户-权限对应关系图:
在用户数量较多的情况下,这种对应关系基本无法维护。实际上,许多用户负责同一业务模块所需的权限是相同的。因此,我们是否可以借助第三方媒介,将相同权限分配给该媒介,然后将用户与媒介关联,使用户获得媒介的权限。这就是经典的RBAC模型,其中媒介通常指的是角色。
1.3
权限模型的演变
1.3.1 RBAC模型
当你拥有角色后,可以将权限分配给该角色。只需将具有相同权限的用户与角色进行关联即可。一个权限可以分配给多个角色,一个角色可以拥有多个权限。同样,一个用户可以分配多个角色,一个角色也可以对应多个用户,对应模型如下所示:
这就是经典的RBAC模型了(role-based-access-control),在这个模型中,角色起到了连接用户和权限关系的桥梁作用。每个角色可以拥有多个权限,每个用户可以被分配多个角色,从而使用户具备多个角色的多个权限。
由于角色作为中介,大大简化了复杂的交互关系。举例来说,对于一家拥有上万名员工的公司,可能只需要几百个角色就足够,因为许多用户所需的权限是相同的,只需分配相同的角色即可。这种模型的对应关系图如下所示:
用户和角色、角色和权限之间都是多对多的关系。这种模型是最通用的权限管理模型,节省了大量的权限维护成本。然而,随着实际业务的多样化,权限管理模型也需要根据不同的业务需求进行适当调整。例如,对于一个公司内部的分层组织架构,随着层级的提升,权限也会增加,因为高层级的人员需要拥有下属的权限,并且可能需要额外的权限。
RBAC模型可以为不同层级的人员分配不同的角色,高层级的角色拥有更多的权限。虽然这种处理方式可以解决问题,但是否存在更好的解决方案呢?答案肯定是有的,这就引出角色继承的RBAC模型。
1.3.2 角色继承的RBAC模型
角色继承的RBAC模型又称RBAC1模型。每家公司都有其独特的组织结构。举例来说,在公司中负责财务管理的人员可能包括财务总监、财务主管、出纳等。财务主管需拥有但不仅限于出纳员的权限,财务总监需要拥有但不仅限于财务主管的权限,这种向下兼容的管理关系模式需要使用角色继承的RBAC模型。在角色继承的RBAC模型中,上层角色会继承下层角色的所有权限,并且可以额外拥有其他权限。
模型如下所示:
模型图显示,下级角色的权限上级角色都具备,并且上级角色可以拥有其他权限。角色的层级关系可分为两种:一种是下级角色只能有一个上级角色,但上级角色可以有多个下级角色。这种结构在图中呈现为树形结构,如下图所示:
1.3.3 带约束的RBAC模型
带约束的RBAC模型,又称RBAC2模型。在实际工作中,出于安全考虑,会存在多个约束条件。例如,在财务部门,同一人不应同时担任会计和审核员;类似地,一个人不能同时是运动员和裁判员。此外,财务部的审核员人数不能超过2人,也不能没有。由于角色和权限相关联,因此我们需要正确设置角色的约束条件。
常见的约束条件有:
角色互斥、基数约束、先决条件约束等。
▪ 角色互斥
如果角色A和角色B是互斥关系的话,那么一个用户同一时间不能既拥有角色A,又拥有角色B,只能拥有其中的一个角色。
还是刚才提到的例子,如果想拥有审核员的角色就必须先去掉会计的角色。假设提交角色和审核角色是互质的,我们可以用图形表示:
▪ 基数约束
同一个角色分配给的用户数量可以受限制,例如规定拥有超级管理员角色的用户只能有1个,用户被分配的角色数量,以及角色分配的权限数量也可以被限制。
▪ 先决条件约束
用户想要被赋予上级角色,首先需要拥有下级角色。举例来说,技术负责人角色和普通技术员工角色存在上下级关系,因此用户想要拥有技术负责人角色就必须先拥有普通技术员工角色。
1.4
用户划分
1.4.1 用户组
我们创建角色是为了解决用户数量大的情况下,用户分配权限繁琐以及用户—权限关系维护成本高的问题。抽象出一个角色,把需要一起操作的权限分配给这个角色,把角色赋予用户,用户就拥有了角色上的权限,这样避免了一个个的给用户分配权限,节省了大量的资源。
同样,如果一批用户需要相同的角色,我们也需要逐个为用户分配角色。例如,一个公司的客服部门有500多名员工。某一天,研发部门开发了一套后台数据查询产品,所有客服人员都需要使用。然而,由于之前并未统一为所有客服人员分配一个角色,现在需要新增一个角色,将权限分配给该角色,然后再逐个将角色分配给客服人员。发现为500名用户逐个添加角色非常繁琐。然而,客服人员具有共同属性,因此我们可以创建一个用户组,所有客服人员都属于该客服用户组,将角色分配给客服用户组,这样该用户组下的所有用户便拥有了所需权限。
RBAC模型添加用户组之后的模型图如下所示:
很多朋友会问,用户组和角色有什么区别呢?简单的来说,用户组是一群用户的组合,而角色是用户和权限之间的桥梁。 用户组将具有相同属性的用户组合在一起,例如同一项目的开发、产品、测试人员可以构成一个用户组,同一部门中担任相同职位的员工可以构成一个用户组,一个用户组可以代表一个职级、一个部门,或者一群来自不同岗位但共同合作的人。
用户可以分组,权限也可以分组。在权限特别繁多的情况下,可以将一个模块的权限组合成一个权限组,这有助于简化权限和角色之间的对应关系。
例如,在定义权限时,一级菜单、二级菜单、按钮都可以作为权限。当一个一级菜单下有多个二级菜单,每个二级菜单下又包含多个按钮时,逐个为角色分配权限将变得非常繁琐。这时,可以采用分组的方式对权限进行分类,然后将分类好的组分配给角色,从而简化权限管理流程。
对权限进行合理分组是一项技术性工作,关键在于清晰梳理各类权限之间的内在关联。以支付运营后台为例,我们需访问多种信息,如账务数据、订单详情、商户资料等,尽管这些数据分散于不同页面,且各页面包含诸多操作按钮。对此,适宜的做法是将涉及的相关页面及其按钮所对应的权限整合为一个权限组,再将其赋予相应的角色,实现权限管理的系统化与便捷化。
加入权限组之后的RBAC模型如下所示:
在实际工作中,相较于直接对权限进行分组,更多情况下我们会选择对用户进行分组,并根据需求将用户组与特定权限相关联。这种做法的采用频率,取决于实际业务场景的具体需求。业务越是复杂多元,相应的权限模型设计也越可能呈现出丰富多样的特点。
1.4.2 组织
每个公司内部均构建有其独特的组织架构,而在实践中,权限分配常常会依据这一架构进行细化划分。其原因在于,同一组织单元内的成员通常需要执行相似的工作职能,因而对权限的需求大体一致。
如下所示一个公司的组织架构图:
遵循公司的组织架构,同一组织内成员所配备的基础权限往往具有较高的一致性。例如,人力资源部门的所有成员通常都需要查阅与人才招聘相关的各类信息,市场推广团队则需随时掌握行业分析的最新动态。这种按照组织架构来设定角色并分配权限的做法,实际上包括以下两个优势:
▪ 实现权限分配的自动化
实现组织关系与权限系统的深度融合后,对于新入职员工,只需将其归入相应的组织单元,其角色权限便会自动继承该组织下的所有权限设定,无需逐一进行人工分配。同样,当员工发生岗位调动时,仅需对其组织关系作出相应调整,权限配置将随之联动更新,全程无须人工介入。此方案的实施首要前提是实现权限体系与组织结构间的有效对接。
▪ 控制数据权限
通过将角色与特定组织紧密关联,确保该组织成员仅能访问其所属组织层级内的数据。以市场推广部门与大客户定制部门为例:前者专注于零散客户的营销活动,后者则服务于具有较大业务规模的客户。尽管两部门数据均在同一平台上存储,但得益于权限设置,各部门成员仅能查看与自身组织直接相关的数据,实现了跨部门数据的隔离与保护。
加入组织之后的RBAC模型如下所示:
用户可以在多个组织中,因为组织也有层级结构,一个组织里只可以有多个用户,所以用户和组织的关系是多对多的关系,组织和角色的关系是一对一的关系。这个在工作中可以根据实际情况来确定对应关系。
1.4.3 职位
一个组织下面会有很多职位,比如财务管理会有财务总监、财务主管、会计、出纳员等职位,每个职位需要的权限是不一样的,可以像组织那样根据职位来分配不同的角色,由于一个人的职位是固定的,所以用户跟职位的对应关系时一对一的关系,职位跟角色的对应关系可以是多对多的关系。
加入职位的RBAC模型如下所示:
Part.02
权限系统表设计
2.1
标准RBAC模型表设计
标准RBAC模型的表是比较简单了,要表示用户—角色—权限三者之前的关系,
首先要创建用户表、角色表、权限表,用户和角色是多对多的关系,角色和权限是多对多的关系,需要再创建两章关系表,分别是用户-角色关系表和角色-权限关系表。
这六张表的ER图如下所示:
2.2
理想RBAC模型表设计
理想的RBAC模型是标准RBAC模型经过多次扩展得到的,表结构也会比较复杂,因为要维护很多关系,如下图所示是理想的RBAC模型的ER图:
本文循序渐进地详述了权限模型的设计过程,强调在实际工作中应依据企业具体状况灵活定制。对于员工规模在千人以下的企业,基础的RBAC模型已足以满足其权限管理需求,无须过度复杂化设计。选择何种权限模型,应充分考量公司规模、业务特性和员工人数等因素。
总之最适合自家企业的权限模型才是最佳模型。如同设计模式旨在高效解决问题一样,权限模式的根本目的亦在于此。因此,切勿为了应用模型而生搬硬套,应确保其真正服务于企业的实际管理需求。
✦✦
由于微信公众号修改了推送规则,
没有加“星标★”的订阅号,
收到的推送只有标题和小图,
而且会慢慢收不到最新的推送。
想要不错过各类讯息,
小伙伴们可以将【乐科科集团】公众号
加个星标❤
你 “在看” 我吗?