构建安全高效的权限管理系统：指南与最佳实践

#产品观察# 2024-9-12 14:44 360人围观产品观察

一、为什么需要权限系统（背景与目的）
每个企业都有自己的分工协作体系；不同岗位的员工，负责不同的工作内容；不属于岗位职责范围内的事情，员工通常不具有参与权和知情权。
如果每个岗位地员工都可以参与所有的工作、看到所有的信息，就会给企业的分工协作体系造成巨大冲击，导致内部管理混乱。
企业通过对员工在系统中拥有的权限进行控制，让不同岗位、层级的员工，只能使用和看到其职权范围内的功能和信息，以确保分工协作体系能顺畅运作，同时维护企业信息安全。

二、权限系统解决什么问题
权限系统，是指对用户在系统中可操作的功能、可查看数据范围进行控制的功能模块。
通俗的解释是：权限系统通过设定不同的用户角色，再将权限分配给各个角色，控制不同的用户，能在系统中使用什么功能、查看什么信息，是企业对员工进行权限控制的工具。

设定运营人员为“电商运营”角色，并分配商品管理、订单管理、活动管理权限。
权限系统允许了运营人员查看和编辑商品信息、订单信息、活动信息，禁止了他们对财务等非岗位职责范围内的功能操作和信息查看。

并非所有的系统都需要做权限控制——只有当系统功能足够多、使用角色多样时，才有对用户进行权限控制的必要。

三、权限模型有哪些
在权限系统中我们会遇到类似这样的权限：

访问权限：控制用户能否登录系统和访问系统资源的权限。
功能权限：控制用户可以使用的系统功能和操作的权限。
数据权限：控制用户可以访问、查看、修改或删除的数据的权限。配置权限：控制用户可以修改系统配置和设置的权限。
审计权限：控制用户可以查看系统日志和审计记录的权限。安全权限：控制用户可以管理系统账户和权限的权限。
文件权限：控制用户可以操作系统文件和文件夹的权限。执行权限：控制用户可以执行哪些程序、脚本或命令的权限。
通信权限：控制用户可以使用哪些通信方式和进行何种通信的权限。

常见的权限设计控制模型有：自主访问控制（DAC）强制访问控制（MAC）访问控制列表(ACL)、基于角色的访问控制(RBAC) 、基于任务和工作流的访问控制(TBAC) 、基于任务和角色的访问控制(T-RBAC)、基于对象的访问控制（OBAC）、使用控制模型( UCON)、基于属性的访问控制（ABAC）

四、权限系统的要求
稳定可靠、灵活方便、容易实现、维护成本不高

五、RBAC权限模型（Role-Based-Access-Control）
权限设计从业务分类上来讲权限可以分为数据查看权限，数据修改权限等，对应到系统设计中有页面权限、菜单权限、按钮权限等。菜单也分一级菜单、二级菜单甚至三级菜单，菜单对应的页面里又有很多按钮，我们在设计的时候最好把权限设计成树形结构，这样在申请权限的时候就可以一目了然的看到菜单的结构，需要哪些权限就非常的明了了，如下图所示：

为什么需要角色权限结构梳理清晰之后，需要思考怎么把权限分配给用户，用户少的情况下，可以直接分配，一个用户可以有多个权限，统一一个权限可以被多个用户拥有，用户-权限的模型结构如下所示：

这种模型能够满足权限的基本分配能力，但是随着用户数量的增长，这种模型的弊端就凸显出来了，每一个用户都需要去分配权限，非常的浪费管理员的时间和精力，并且用户和权限杂乱的对应关系会给后期带来巨大的维护成本。用户-权限对应关系图：

这种对应关系在用户多的情况下基本无法维护了。其实很多用户负责同一个业务模块所需要的权限是一样的，这样的话我们是不是可以借助第三个媒介，把需要相同的权限都分配给这个媒介，然后用户和媒介关联起来，用户就拥有了媒介的权限了。这就是经典的RBAC模型，其中媒介就是我们通常所说的角色。
权限模型的演进RBAC0模型
有了角色之后可以把权限分配给角色，需要相同权限的用户和角色对应起来就可以了，一个权限可以分配给多个角色，一个角色可以拥有多个权限，同样一个用户可以分配多个角色，一个角色也可以对应多个用户，对应模型如下所示：

这就是经典的RBAC模型了（role-based-access-control），在这里面角色起到了桥梁左右，连接了用户和权限的关系，每个角色可以拥有多个权限，每个用户可以分配多个角色，这样用户就拥有了多个角色的多个权限。
同时因为有角色作为媒介，大大降低了错综复杂的交互关系，比如一家有上万人的公司，角色可能只需要几百个就搞定了，因为很多用户需要的权限是一样的，分配一样的角色就可以了。这种模型的对应关系图如下所示：

用户和角色，角色和权限都是多对多的关系，这种模型是最通用的权限管理模型，节省了很大的权限维护成本，但是实际的业务千变万化，权限管理的模型也需要根据不同的业务模型适当的调整，比如一个公司内部的组织架构是分层级的，层级越高权限越大，因为层级高的人不仅要拥有自己下属拥有的权限，二期还要有一些额外的权限。
RBAC模型可以给不同层级的人分配不同的角色，层级高的对应角色的权限就多，这样的处理方式可以解决问题，但是有没有更好的解决办法呢，答案肯定是有的，这就引出角色继承的RBAC模型。
RBAC1模型（角色继承的RBAC模型）
角色继承的RBAC模型又称RBAC1模型。每个公司都有自己的组织架构，比如公司里管理财务的人员有财务总监、财务主管、出纳员等，财务主管需要拥有但不限于出纳员的权限，财务总监需要拥有但不限于财务主管的权限，像这种管理关系向下兼容的模式就需要用到角色继承的RBAC模型。角色继承的RBAC模型的思路是上层角色继承下层角色的所有权限，并且可以额外拥有其他权限。

从模型图中可以看出下级角色拥有的权限，上级角色都拥有，并且上级角色可以拥有其他的权限。角色的层级关系可以分为两种，一种是下级角色只能拥有一个上级角色，但是上级角色可以拥有多个下级角色，这种结构用图形表示是一个树形结构，如下图所示：

还有一种关系是下级角色可以拥有多个上级角色，上级角色也可以拥有多个下级角色，这种结构用图形表示是一个有向无环图，如下图所示：

树形图是我们比较常用的，因为一个用户一般情况下不会同时有多个直属上级，比如财务部只能有一个财务总监，但是可以有多个财务主管和收纳员。
RBAC2模型（带约束的RBAC模型）
带约束的RBAC模型又成RBAC2模型。在实际工作中，为了安全的考虑会有很多约束条件，比如财务部里同一个人不能即是会计又是审核员，跟一个人同一时间不能即是运动员又是裁判员是一个道理的，又比如财务部的审核员不能超过2个，不能1个也没有。因为角色和权限是关联的，所以我们做好角色的约束就可以了。
常见的约束条件有：角色互斥、基数约束、先决条件约束等。
角色互斥：如果角色A和角色B是互斥关系的话，那么一个用户同一时间不能即拥有角色A，又拥有角色B，只能拥有其中的一个角色。
比如我们给一个用户赋予了会计的角色就不能同时再赋予审核员的角色，如果想拥有审核员的角色就必须先去掉会计的角色。假设提交角色和审核角色是互质的，我们可以用图形表示：

基数约束：同一个角色被分配的用户数量可以被限制，比如规定拥有超级管理员角色的用户有且只有1个；用户被分配的角色数量也需要被限制，角色被分配的权限数量也可以被限制。
先决条件约束：用户想被赋予上级角色，首先需要拥有下级角色，比如技术负责人的角色和普通技术员工角色是上下级关系，那么用户想要用户技术负责人的角色就要先拥有普通技术员工的角色。
用户划分用户组
我们创建角色是为了解决用户数量大的情况下，用户分配权限繁琐以及用户-权限关系维护成本高的问题。抽象出一个角色，把需要一起操作的权限分配给这个角色，把角色赋予用户，用户就拥有了角色上的权限，这样避免了一个个的给用户分配权限，节省了大量的资源。
同样的如果有一批用户需要相同的角色，我们也需要一个个的给用户分配角色，比如一个公司的客服部门有500多个人，有一天研发部研发了一套查询后台数据的产品，客服的小伙伴都需要使用，但是客服由于之前并没有统一的一个角色给到所有的客服小伙伴，这时候需要新加一个角色，把权限分配给该角色，然后再把角色一个个分配给客服人员，这时候会发现给500个用户一个个添加角色非常的麻烦。但是客服人员又有共同的属性，所以我们可以创建一个用户组，所有的客服人员都属于客服用户组，把角色分配给客服用户组，这个用户组下面的所有用户就拥有了需要的权限。
RBAC模型添加用户组之后的模型图如下所示：

很多朋友会问，用户组和角色有什么区别呢？简单的来说，用户组是一群用户的组合，而角色是用户和权限之间的桥梁。用户组把相同属性的用户组合起来，比如同一个项目的开发、产品、测试可以是一个用户组，同一个部门的相同职位的员工可以是一个用户组，一个用户组可以是一个职级，可以是一个部门，可以是一起做事情的来自不同岗位的人。
用户可以分组，权限也可以分组，权限特别多的情况下，可以把一个模块的权限组合起来成为一个权限组，权限组也是解决权限和角色对应关系复杂的问题。
比如我们定义权限的时候一级菜单、二级菜单、按钮都可以是权限，一个一级菜单下面有几十个二级菜单，每个二级菜单下面又有几十个按钮，这时候我们把权限一个个分配给角色也是非常麻烦的，可以采用分组的方法把权限分组，然后把分好的组赋予角色就可以了。
给权限分组也是个技术活，需要理清楚权限之间的关系，比如支付的运营后台我们需要查各种信息，账务的数据、订单的数据、商户的数据等等，这些查询的数据并不在一个页面，每个页面也有很多按钮，我们可以把这几个页面以及按钮对应的权限组合成一个权限组赋予角色。加入权限组之后的RBAC模型如下所示：

实际工作中我们很少给权限分组，给用户分组的场景会多一些，有的时候用户组也可以直接和权限关联，这个看实际的业务场景是否需要，权限模型没有统一的，业务越复杂业务模型会约多样化。
组织
每个公司都有自己的组织架构，很多时候权限的分配可以根据组织架构来划分。因为同一个组织内的小伙伴使用的大部分权限是一样的。如下所示一个公司的组织架构图：

按照这个组织架构，每一个组织里的成员使用的基础权限很可能是一样的，比如人力资源都需要看到人才招聘的相关信息，市场推广都需要看到行业分析的相关信息，按照组织来分配角色会有很多优势：
实现权限分配的自动化：和组织关系打通之后，按照组织来分配角色，如果有新入职的用户，被划分在某个组织下面之后，会自动获取该组织下所有的权限，无需人工分配。又比如有用户调岗，只需要把组织关系调整就可以了，权限会跟着组织关系自动调整，也无需人工干预。这么做首先需要把权限和组织关系打通。
控制数据权限：把角色关联到组织，组织里的成员只能看到本组织下的数据，比如市场推广和大客定制，市场推广针对的是零散的客户，大可定制针对的是有一定体量的客户，相互的数据虽然在一个平台，但是只能看自己组织下的数据。
加入组织之后的RBAC模型如下所示：

用户可以在多个组织中，因为组织也有层级结构，一个组织里只可以有多个用户，所以用户和组织的关系是多对多的关系，组织和角色的关系是一对一的关系。这个在工作中可以根据实际情况来确定对应关系。
职位
一个组织下面会有很多职位，比如财务管理会有财务总监、财务主管、会计、出纳员等职位，每个职位需要的权限是不一样的，可以像组织那样根据职位来分配不同的角色，由于一个人的职位是固定的，所以用户跟职位的对应关系时一对一的关系，职位跟角色的对应关系可以是多对多的关系。加入职位的RBAC模型如下所示：

理想的RBAC模型
RBAC模型根据不同业务场景的需要会有很多种演变，实际工作中业务是非常复杂的，权限分配也是非常复杂的，想要做出通用且高效的模型很困难。我们把RBAC模型的演变汇总起来会是一个支撑大数据量以及复杂业务的理想的模型。把RBAC、RBAC1、RBAC2、用户组、组织、职位汇总起来的模型如下所示：

按照这个模型基本上能够解决所有的权限问题，其中的对应关系可以根据实际的业务情况来确定，一般情况下，组织和职位是一对多的关系，特殊情况下可以有多对多的情况，需要根据实际情况来定。
理想的RBAC模型并不是说我们一开始建权限模型就可以这么做，而是数据体量、业务复杂度达到一定程度之后可以使用这个模型来解决权限的问题，如果数据量特别少，比如刚成立的公司只有十几个人，那完全可以用用户-权限模型，都没有必要使用RBAC模型。

六、从0到1搭建RBAC权限系统
权限系统的业务框架权限系统在实际的企业it系统中起到一个中转的作用，业务系统将想要控制的内容同步到权限系统，权限系统再将控制结果下发到各个业务系统，从而达到权限控制的目的。

权限控制的维度权限是用户可以访问的资源，包括菜单功能权限，数据权限；

功能权限：包括系统的目录导航、菜单的访问权限，以及按钮和 API 操作的权限
数据权限：包括定义数据的查询范围权限，包括可见、不可见等

功能权限
功能权限为可见、可以操作的功能范围；常见的有菜单目录、功能按钮等。

数据权限
数据权限为用户可见的数据信息；常见的有行数据、字段数据；

附录：其他权限控制模型
常见的权限设计控制模型有：自主访问控制（DAC）强制访问控制（MAC）访问控制列表(ACL)、基于角色的访问控制(RBAC) 、基于任务和工作流的访问控制(TBAC) 、基于任务和角色的访问控制(T-RBAC)、基于对象的访问控制（OBAC）、使用控制模型( UCON)、基于属性的访问控制（ABAC）
一、ACL模型：访问控制列表
Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。
原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。
例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。
缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。
二、DAC模型：自主访问控制
Discretionary Access Control，DAC是ACL的一种拓展。
原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。
例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。
缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。
三、MAC模型：强制访问控制
Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。
原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。
例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。
缺点：控制太严格，实现工作量大，缺乏灵活性。
四、ABAC模型：基于属性的访问控制
Attribute-Based Access Control，能很好地解决RBAC的缺点，在新增资源时容易维护。
原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。这个模型在云系统中使用的比较多，比如 AWS，阿里云等。
考虑下面这些场景的权限控制：
授权某个人具体某本书的编辑权限
当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档
当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档
早上九点前禁止 A 部门的人访问 B 系统
在除了上海以外的地方禁止以管理员身份访问 A 系统
用户对 2022-06-07 之前创建的订单有操作权限
可以发现上述的场景通过 RBAC模型很难去实现，因为 RBAC模型仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，RBAC模型本身是没有这些限制的。但这恰恰是 ABAC模型的长处，ABAC模型的思想是基于用户、访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。
在 ABAC模型中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。
对象：对象是当前请求访问资源的用户。用户的属性包括 ID，个人资源，角色，部门和组织成员身份等
资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至 API
操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等
在 ABAC模型的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。
例如：早上9:00，11:00期间A、B两个部门一起以考生的身份考试，下午14:00，17:00期间A、B两个部门相互阅卷。
缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少
六、TBAC模型：基于任务的访问控制
对象的访问权限控制并不是静止不变的，而是随着执行任务的上下文环境发生变化。
TBAC模型由工作流，授权结构体，受托人集，许可集四部分组成。
TBAC模型一般用五元组（主体，客体，许可，生命周期，授权步）来表示。
如：去银行办理：柜员在窗口有读取权，上交上一级后失去这个权利。
被赋予某个任务的时候才能有这个权限。
七、T-RBAC模型：基于任务和角色的访问控制模型
T-RBAC 模型把任务和角色置于同等重要的地位，它们是两个独立而又相互关联的重要概念。任务是RBAC 和TBAC能结合的基础。
T-RBAC 模型中是先将访问权限分配给任务，再将任务分配给角色，角色通过任务与权限关联，任务是角色和权限交换信息的桥梁。
在T-RBAC模型中，任务具有权限，角色只有在执行任务时才具有权限，当角色不执行任务时不具有权限;权限的分配和回收是动态进行的，任务根据流程动态到达角色，权限随之赋予角色，当任务完成时，角色的权限也随之收回;角色在工作流中不需要赋予权限。这样，不仅使角色的操作、维护和任务的管理变得简单方便，也使得系统变得更为安全。
八、OBAC模型：基于对象的访问控制
将访问控制列表与受控对象或受控对象的属性相关联，并将访问控制选项设计成为用户，组或角色及其对应权限的集合。
允许对策略和规则进行重用，继承和派生操作。派生对象可以继承父对象的访问控制设置。
可以减轻由于信息资源的派生，演化和重组等带来的分配
一个单位可能混合使用五种访问控制机制。最常用是OBAC，强制访问控制比较少。学校里有基于角色的，有基于任务的。
网络访问控制的应用
MAC地址过滤：自主访问控制，网桥自行定义。
ACL访问控制列表：自主访问控制，用IP来做访问控制。有一个路由表（选路，确定网域）。
VLAN隔离：OBAC，虚拟网络需要一个表，网域切分。
防火墙访问控制：TBAC任务流，决定账号，packet等能不能通过，由于机制比较多，使用比较多的表。
控制策略和控制规则是OBAC访问控制系统的核心所在，在基于受控对象的访问控制模型中，将访问控制列表与受控对象或受控对象的属性相关联，并将访问控制选项设计成为用户、组或角色及其对应权限的集合；同时允许对策略和规则进行重用、继承和派生操作。这样，不仅可以对受控对象本身进行访问控制，受控对象的属性也可以进行访问控制，而且派生对象可以继承父对象的访问控制设置，这对于信息量巨大、信息内容更新变化频繁的管理信息系统非常有益，可以减轻由于信息资源的派生、演化和重组等带来的分配、设定角色权限等的工作量。
OBAC从信息系统的数据差异变化和用户需求出发，有效地解决了信息数据量大、数据种类繁多、数据更新变化频繁的大型管理信息系统的安全管理。OBAC从受控对象的角度出发，将访问主体的访问权限直接与受控对象相关联，一方面定义对象的访问控制列表，增、删、修改访问控制项易于操作，另一方面，当受控对象的属性发生改变，或者受控对象发生继承和派生行为时，无须更新访问主体的权限，只需要修改受控对象的相应访问控制项即可，从而减少了访问主体的权限管理，降低了授权数据管理的复杂性。
九、UCON模型：使用控制( UsageControl:UCON) 模型
使用控制( UsageControl:UCON) 模型，也称ABC模型。UCON模型包含三个基本元素: 主体、客体、权限和另外三个与授权有关的元素: 授权规则、条件、义务。
UCON模型中的主要元素如下:
主体( Subjects)。它是具有某些属性和对客体(Objects)操作权限的实体。主体的属性包括身份、角色、安全级别、成员资格等。这些属性用于授权过程。客体( Objects) 。它是主体的操作对象，它也有属性，包括安全级别、所有者、等级等。这些属性也用于授权过程。
权限( Rights)。它是主体拥有的对客体操作的一些特权。权限由一个主体对客体进行访问或使用的功能集组成。UCON中的权限可分成许多功能类，如审计类、修改类等。
授权规则( AuthorizationRules) 。它是允许主体对客体进行访问或使用前必须满足的一个需求集。授权规则是用来检查主体是否有资格访问客体的决策因素。
条件( Conditions)。它是在使用授权规则进行授权过程中，允许主体对客体进行访问权限前必须检验的一个决策因素集。条件是环境的或面向系统的决策因素。条件可用来检查存在的限制，使用权限是否有效，哪些限制必须更新等。
义务( Obligations)。它是一个主体在获得对客体的访问权限后必须履行的强制需求。分配了权限，就应有执行这些权限的义务责任。
在UCON模型中，授权规则、条件、义务与授权过程相关，它们是决定一个主体是否有某种权限能对客体进行访问的决策因素。基于这些元素， UCON有四种可能的授权过程，并由此可以证明:UCON模型不仅包含了DAC，MAC， RBAC，而且还包含了数字版权管理(DRM)、信任管理等。UCON 模型涵盖了现代商务和信息系统需求中的安全和隐私这两个重要的问题。因此， UCON模型为研究下一代访问控制提供了一种有希望的方法，被称作下一代访问控制模型。
本文来源 @波罗哥。未经作者许可，禁止转载

文章来源:“波罗哥”，未经允许不得转载。

文章代表作者观点，版权归原作者所有，热传平台仅提供信息存储空间服务。