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

基于角色的访问控制（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

本文由 @员外丁 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议