一个实例：基于RBAC理论的访问控制实践

Posted 2021-05-01 产品会

加关注，带你看世界

基于角色的访问控制（RBAC）是目前公认的解决大型企业的统一资源访问控制的有效方法。访问控制实际是复杂的，解决方式也是多样的。不用一味追求完善，在有限的资源内选择最合适自己的更重要。

基于角色的访问控制（RBAC）是目前公认的解决大型企业的统一资源访问控制的有效方法，传统的访问控制中我们直接将权限赋予用户，而在基于角色访问控制中先将权限赋予角色，再通过角色与用户连接。

一个实例

这里跳过对理论模型的解释，以最近的一个项目为例，谈下实际项目中的应用。首先交代背景：

（1）简易电商后台版本，意思就是很小不需要什么复杂权限，开始也没考虑权限。

（2）有一个管理员账号运营和开发都在用，一个财务账号给财务导数据，新建供应商同时生成商家账号，给商家上架商品发货这些。

（3）需要增加权限的契机就是随着业务扩大，功能变得复杂了些，再不做就要乱了。

功能模块

权限的功能模块分为三个部分：

用户管理就是给用户添加登录账号，让用户能够登录系统；

角色是告诉你我在这个身份下能在系统干什么；

权限配置是对权限功能的管理，让系统管理员或开发人员更清楚灵活管理配置系统页面权限、功能权限，反正就是普通用户用不着那种。

角色管理

首先是添加角色。

字段非常简单，只要写好角色名称和描述角色是做什么的就可以。

其次是分配权限。

很多系统做法是直接在编辑或者添加页面一起把权限分配做了。我更偏好是一个动作下只做一件事，会比较清晰些。所以这里做了两个步骤，就是角色信息和权限分配独立开。

在页面交互上，这里并没有使用纯树形，而是结合菜单+页面形式：左边展示导航菜单，右边展示对应页面功能。

这种对于页面层级不深的其实是非常直观的，但是如果在该页面下某些二级入口甚至三级入口权限控制就会略显混乱，会比较建议使用树形结构处理。

顺便提一句，后台设计尽量不要让页面层次太深了，这对用户使用并不友好。如果这么做，那么使用多级菜单导航或者关闭式标签导航可能是一种解决方式。

有一些需要注意的点：

1. 超级管理员

为了便于管理，在当前系统中配置了一个超级管理员角色，就是这个角色系统里面什么都能干；这个角色下通常只有一个超管，只有这个超管才能做权限管理，其他角色是不可的。

这一点在不复杂的系统中，是一种便捷管理方式。更复杂系统需要考虑不同层级管理员、考虑角色互斥、角色继承这些问题。

2. 角色禁用启用以及删除

禁用启用都会影响到这个角色下所有用户的使用，这点需要注意。在处理这些敏感的操作时候，一定要做二次确认。

在删除时，还需要判断下当前角色有用户时是否能够删除。能删除则用户怎么处理，不能删除怎么提示。

一种做法是，可以删除但删除后如果用户赋予的角色会为空，再登录时候会对应提示；另外一种做法是要先清空用户才能删除角色。

3. 单角色

RBAC告诉我们一个用户可以有多个角色，但是我这里处理为一个用户只有一个角色。实际上可以做多个角色，但是没有必要，因为我们的业务是单线的，每个角色各司其职。

如果是多角色，从我做过系统看，一个是做好角色的互斥，比如说某项业务的申请和审批不要分配到同一个人上；一个是一次只能获取一个角色，登录进入系统，第一个就是要选择角色。

如果处理更好那就首次登录选择，再次登录记住上次即可，并且支持在个人设置中自由切换。

4. 默认角色

这里商家其实是默认角色，它不可删除。这么做是因为商家某些页面字段显示与其他角色是不一样的，属于数据权限范畴。但是如果单独细化数据权限到字段，投入产出比那真的是划不着，所以直接在角色中写死了。在实际场景中，角色和身份是可以是对等的，比如做校园自然就有教师、学生、家长角色，这一类角色实际是是可以作为默认固定角色而不需要再创建。

用户管理

添加角色以后，我们就可以去用户管理中管理用户，页面如下：

在添加或编辑用户时候我们就会给用户设置角色。这里可能需要注意点有：

（1）用户名

根据实际需求去规定用户名，可以是邮箱可以是手机号，也可以是正常的字母+数字的组合。

当前系统使用是数字+字母的账号，那么在你忘记密码时候，如果不绑定手机号或邮箱还是无法自己找回的。在当前业务条件下，登录页直接给了个联系管理员的提示，由管理员重置密码。

（2）密码

通常会有个初始密码，为了保证系统安全性，最好首次进入强制修改。如果忘记密码需要管理员重置，那需要一个重置的功能，点击二次确认后重置为初始密码。也可以是带输入框弹窗，输入为任意符合规则的密码。

（3）关联商家

可以理解为这是对数据权限的控制手段。在实际的后台权限管理中，有些数据权限是根据组织架构做了限制，有些角色去配置，有些根据用户组，而有些则是根据账号单独去配置。所以在做数据权限时候，要具体问题具体分析，而不是别人的一定合适。

在当前系统中，实际默认有两类用户，一个是平台的，如平台运营、财务；一个是供应商（商家），那么平台对应的数据范围是全部数据，而商家对应的数据范围是自己的。

在做权限之前，在商户管理中，添加商户时候默认会添加一个商户账号，实际已经做了数据隔离，但是统一权限管理后，添加用户并且配了商家角色，实际上并不知道这个用户管理的是哪个商家，那就需要用户和商家中做个链接。

（4）投放限制

是某种特殊的数据限制，进一步说明对单个账号配置必要性。

比如如果做广告，只允许某用户投放某些区域；再比如做校园管理系统中，指派班级学生助理对特定班级成员的管理（也可以通过组织架构做数据权限控制，如果有下篇可以讨论下）。

我做的是社区电商后台，是自带社区限制属性的，有些商家只能投放一个社区，有些商家则能投放多个社区。

权限配置

更准确的说，是菜单和规则的配置。不是必须的，但是建议能够在前端页面中配置。

我负责的系统是php写的，权限是后面增加，所以开发在修改时候，每个功能按钮都做了个if判断，还好页面和功能不多，不然开发估计要哭。

所以这个并不是合理方式。

在其他系统中，则采用的是通过url结合api做的页面和功能控制，有优点也有缺点，本文不进行深入讨论。

当然我也无力探究不同的语言如何实现权限管理，因为我听不懂。不过理解下正在做的系统如何实现的对于非技术出身产品经理而言，则是一种有益学习过程。

通过权限配置，我们能够比较灵活的调整菜单或者功能，比如调整个菜单位置配置个菜单icon，不需要让开发的伙伴去动下代码，能让他们少掉几根头发。

此外，操作日志是一个必不可少的模块，它是对访问控制一个补充，记录了整体系统中所有的行为。特别是在角色中没有控制“只能操作自己内容”时，就会变得尤为重要。

我现在处理这个系统权限问题时候，并没有在角色的维度上去控制数据权限，而是根据实际业务在用户的维度去控制了数据权限。举一个例子，比如说，AB都是商家角色，都能对某个商家进行管理。如果二者数据权限做了控制，那么A只能编辑自己录入商品，B只能编辑自己录入商品。如果没有控制，那么AB都可以编辑彼此录入商品，要是误操作这就不知道是谁干的了。在这种情况下，有日志就能知道谁进行了对应的操作，避免无法追溯问题源头。

理论溯源

理论是实践的基础。虽然枯燥，还是有必要提一下整个RBAC模型的发展脉络。

产品经理社区乃至各大技术社区对于RBAC的介绍和说明已经有很多，挑了以下两篇我觉得说的很清楚文章，看完就基本知道RBAC是整个模型是什么了，感谢二位分享。

RBAC权限管理模型：基本模型及角色模型解析及举例  http://www.woshipm.com/pd/440765.html

总结：SAAS后台权限设计案例分析  http://www.woshipm.com/pd/2310691.html

同时我也结合了自己了解和理解资料，做了一个理论梳理。特别是最上面访问控制技术发展有兴趣的可以进一步探索下，就不贴什么枯燥的概念解释了。实在能力有限，有些是真的看不太懂。

值得一提的是，人们习惯用百度谷歌等搜索引擎去获取专业信息，而很多学术论文中的一些整体解决方案往往被忽视。

学术上这种理论与实践结合研究可能滞后于现实发展的（因为新的实践提升到理论的视角是需要时间积累），但是对于从未接触过人群，这类论文却提供了一种方法论的思路。

是的，你们找不到答案的时候不妨查一下CNKI。——员外

结束语

1. 权限管理是系统的基础功能，在最初规划时候就要考虑到每个行为都能找到是谁干的。

2. 访问控制实际是复杂的，解决方式也是多样的。不用一味追求完善，在有限的资源内选择最合适自己的更重要。

最后，如有不足或者错误地方欢迎指正。计划是能由简单到复杂复盘下自己做访问控制踩过的坑，希望有下一篇，立个flag

#声明#