讯享网

 <p><blockquote id="0B6KSHS8">导读：B端项目上，需要设计实现一个权限管理模块，就要知道到一个很重要的RBAC模型，所以整理总结了RBAC的一些知识。目前，使用最普遍的权限管理模型正是RBAC（Role-Based Access Control）模型，这篇文章主要是介绍基于RBAC的权限管理系统，将会从RBAC是什么、如何设计RBAC两部分来介绍。</blockquote></p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F56f4cc48j00r0wzoe003sc000p000bog.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>一、RBAC模型是什么? 1. RBAC模型概述</p><p id="0B6KSHPI">RBAC模型（Role-Based Access Control：基于角色的访问控制）模型是20世纪90年代研究出来的一种新模型，但其实在20世纪70年代的多用户计算时期，这种思想就已经被提出来，直到20世纪90年代中后期，RBAC才在研究团体中得到一些重视，并先后提出了许多类型的RBAC模型。其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公认。</p><p id="0B6KSHPJ">RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为What、How的问题，Who、What、How构成了访问权限三元组，具体的理论可以去调查RBAC96的研究文件，这里就不做详细的展开介绍，让大家有个了解和即可。</p><p>2. RBAC的组成</p><p id="0B6KSHPK">在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。</p><p id="0B6KSHPL">RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理。</p><p id="0B6KSHPM"><strong>下面在讲解之前，先介绍一些名词：</strong></p><p id="0B6KSHPN">User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色</p><p id="0B6KSHPO">Role（角色）：不同角色具有不同的权限</p><p id="0B6KSHPP">Permission（权限）：访问权限</p><p id="0B6KSHPQ">用户-角色映射：用户和角色之间的映射关系</p><p id="0B6KSHPR">角色-权限映射：角色和权限之间的映射</p><p id="0B6KSHPS"><strong>它们之间的关系如下图所示：</strong></p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F07d336d4j00r0wzof000nc000jc00a3g.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSHPU">例如下图，管理员和普通用户被授予不同的权限，普通用户只能去修改和查看个人信息，而不能创建创建用户和冻结用户，而管理员由于被授 予所有权限，所以可以做所有操作。</p><p id="0B6KSHPV">例如下图，管理员和普通用户被授予不同的权限，普通用户只能去修改和查看个人信息，而不能创建创建用户和冻结用户，而管理员由于被授予所有权限，所以可以做所有操作。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F28ae7a10j00r0wzof000rc000g400bdg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>3. RBAC支持的安全原则</p><p id="0B6KSHQ1">RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则。</p><p id="0B6KSHQ2">最小权限原则：RBAC可以将角色配置成其完成任务所需的最小权限集合。</p><p id="0B6KSHQ3">责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作。</p><p id="0B6KSHQ4">数据抽象原则：可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读、写、执行权限。</p><p>4. RBAC的优缺点</p><p id="0B6KSHQ5"><strong>优点：</strong>简化了用户和权限的关系易扩展、易维护。</p><p id="0B6KSHQ6"><strong>缺点：</strong>RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。</p><p>5. RBAC的3种模型</p><p id="0B6KSHQ7"><strong>1）RBAC0</strong></p><p id="0B6KSHQ8">RBAC0，是最简单、最原始的实现方式，也是其他RBAC模型的基础。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2Fd28aa2b1j00r0wzog0017c000u000d1g.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSHQA">在该模型中，用户和角色之间可以是多对多的关系，即一个用户在不同场景下是可以有不同的角色，例如：项目经理也可能是组长也可能是架构师。同时每个角色都至少有一个权限。这种模型下，用户和权限被分离独立开来，使得权限的授权认证更加灵活。</p><p id="0B6KSHQB"><strong>A、权限是用户可以访问的资源，包括</strong>页面权限、<strong>操作权限</strong>、<strong>数据权限</strong>。</p><p id="0B6KSHQC">a、页面权限：即用户登录系统可以看到的页面,由菜单来控制,菜单包括一级菜单和二级菜单,只要用户有一级和二级菜单的权限,那么用户就可以访问页面。</p><p id="0B6KSHQD">b、操作权限： 即页面的功能按钮，包括查看、新增、修改、删除、审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限，如果是，就可以进行下一步操作，反之提示无权限。有的系统要求”可见即可操作”，意思是如果页面上能够看到操作按钮，那么用户就可以操作，要实现此需求，这里就需要前端来配合，前端开发把用户的权限信息缓存，在页面判断用户是否包含此权限，如果有，就显示该按钮，如果没有，就隐藏该按钮。某种程度上提升了用户体验，但是在实际场景可自行选择是否需要这样做。</p><p id="0B6KSHQE">c、数据权限：数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据，在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，解决方案一般是把数据和具体的组织架构关联起来，举个例子，再给用户授权的时候，用户选择某个角色同时绑定组织如财务部或者合肥分公司，那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2Fc8j00r0wzog000mc000h900aug.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSHQG"><strong>2）RBAC1</strong></p><p id="0B6KSHQH">基于RBAC0模型，引入了角色间的继承关系，即角色上有了上下级的区别。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F793e6414j00r0wzoh001fc000u000gig.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSHQJ">角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。</p><p id="0B6KSHQK"><strong>A、数据范围的继承</strong></p><p id="0B6KSHQL">我们可以将用户进行分级管理，比如建立多层级的组织架构树，将不同用户放置于组织架构的不同根节点上，来实现多层级用户的建立和管理。</p><p id="0B6KSHQM">如果用户的层级如果比较简单（不多于三级），可以将层级关系融入到角色之中。</p><p id="0B6KSHQN">比如用户分为三级：管理员-组长-组员，管理员能看到全部的数据范围和拥有全部的功能权限，而组长能查看组员的数据范围和拥有部分功能权限（比如无法编辑用户），而组员的数据范围仅仅为自己负责的数据和拥有部分功能权限。</p><p id="0B6KSHQO">我们可以在组长这个角色下，允许其绑定组员，针对不同的角色设置不同的数据范围读取方式，管理员可以读取全部数据范围，组长需要读取其组员的，组员只能读取自己的。这种模型适合于角色之间层次分明，可以给角色分组分层。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2Ffbb10037j00r0wzoi0017c000ki00bwg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSH"><strong>RBAC2：</strong></p><p id="0B6KSHQR">RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2Fa20d82c9j00r0wzoj001ic000u000ejg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSHQT">RBAC2中的一个基本限制是互斥角色的限制，互斥角色是指各自权限可以互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。</p><p id="0B6KSHQU"><strong>该模型有以下几种约束：</strong></p><p id="0B6KSHQV">互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。</p><p id="0B6KSHR0">基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的；</p><p id="0B6KSHR1">先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。</p><p id="0B6KSHR2">运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。</p><p id="0B6KSHR3"><strong>RBAC3：</strong></p><p id="0B6KSHR4">最全面的权限管理,它是基于RBAC0,将RBAC1和RBAC2进行了整合。</p><p>二、如何设计RBAC?</p><p id="0B6KSHR5">介绍设计基于RBAC模型的权限系统的功能模块组成、流程以及数据库的设计。</p><p>1. RBAC的功能模块</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2Fdbbcd8d1j00r0wzoj000wc000i900d7g.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>2. RBAC执行流程</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F10d83376j00r0wzok000ic000du00dlg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>3. RBAC数据库设计</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2Fac78fa46j00r0wzok001kc000g500fug.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>4. 用户组</p><p id="0B6KSHR9">平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工,如果直接给用户分配角色，管理员的工作量就会很大，如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。</p><p id="0B6KSHRA">根据用户组是否有上下级关系,可以分为有上下级的用户组和普通用户组。</p><p id="0B6KSHRB">具有上下级关系的用户组：最典型的例子就是部门和职位，可能多数人没有把部门职位和用户组关联起来吧。当然用户组是可以拓展的，部门和职位常用于内部的管理系统，如果是面向C端的系统，比如淘宝网的商家，商家自身也有一套组织架构，比如采购部，销售部，客服部，后勤部等，有些人拥有客服权限，有些人拥有上架权限等等，所以用户组是可以拓展的。</p><p id="0B6KSHRC">普通用户组：即没有上下级关系，和组织架构，职位都没有关系，也就是说可以跨部门，跨职位,举个例子，某电商后台管理系统，有拼团活动管理角色，我们可以设置一个拼团用户组，该组可以包括研发部的后台开发人员，运营部的运营人员，采购部的人员等等。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F2f9a90baj00r0wzol000mc000fs008og.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>5. 组织</p><p id="0B6KSHRE">常见的组织架构如下图：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2021%2F1013%2F12bb5b1ej00r0wzom000ec000hs00adg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="0B6KSHRG">可以把组织与角色进行关联，用户加入组织后，就会自动获得该组织的全部角色，无须管理员手动授予，大大减少工作量，同时用户在调岗时，只需调整组织，角色即可批量调整。</p><p>6. 授权流程</p><p id="0B6KSHRH">授权即给用户授予角色，按流程可分为手动授权和审批授权。权限中心可同时配置这两种，可提高授权的灵活性。</p><p id="0B6KSHRI">手动授权：管理员登录权限中心为用户授权，根据在哪个页面授权分为两种方式：给用户添加角色，给角色添加用户。</p><p id="0B6KSHRJ">给用户添加角色就是在用户管理页面，点击某个用户去授予角色，可以一次为用户添加多个角色；给角色添加用户就是在角色管理页面，点击某个角色，选择多个用户，实现了给批量用户授予角色的目的。</p><p id="0B6KSHRK">审批授权：即用户申请某个职位角色，那么用户通过OA流程申请该角色，然后由上级审批，该用户即可拥有该角色，不需要系统管理员手动授予。</p><p>三、整理总结： 1. RBACM模型</p><p id="0B6KSHRL">RBAC0、RBAC1、RBAC2、RBAC3</p><p id="0B6KSHRM">RBAC0：是RBAC的核心思想。</p><p id="0B6KSHRN">RBAC1：RBAC基础上增加了角色分层模型。</p><p id="0B6KSHRO">RBAC2：RBAC基础上增加了约束模型。</p><p id="0B6KSHRP">RBAC3：其实是RBAC2 + RBAC1。</p><p>2. 权限</p><p id="0B6KSHRQ"><strong>1) 权限赋予</strong></p><p id="0B6KSHRR">权限赋予是把当前用户的权限拉出来，然后分配的客服可以小于等于当前用户的权限。</p><p id="0B6KSHRS"><strong>2) 权限加载</strong></p><p id="0B6KSHRT">正常的加载权限，当用户登录后，并且第一次使用权限判断的时候， Shiro（页面框架） 会去加载权限。</p><p id="0B6KSHRU"><strong>3) 权限判断</strong></p><p id="0B6KSHRV">走正常用户权限判断，但是数据操作需要判断是不是当前归属的用户的数据，其实这个是属于业务层，就算你不是客服，也是需要判断。</p><p id="0B6KSHS0"><strong>(4) 禁用|启用</strong></p><p id="0B6KSHS1">禁用启用，也是正常的用户流程，添加到禁用列表里，如果被禁用，就无法操作任何内容。</p><p id="0B6KSHS2">本文由 @K 原创发布于人人都是产品经理，未经许可，禁止转载。</p><p id="0B6KSHS3">题图来自 Pexels，基于 CC0 协议</p>