业务后台系统的产品设计最重要的内容有三项：功能设计、权限设计和流程设计。三项内容还可以按下表细分：
| 后台设计内容 | 说明 |
|---|---|
| 功能设计 | 包括UI设计、交互设计和功能设计 |
| 权限设计 | 包括组织架构设计、人员管理设计 |
| 流程设计 | 即工作流或审批流设计 |
本篇总结的是业务后台系统的权限设计方面的领悟，权限设计同样可以从关键的几点来总结：权限设计模型、权限的构成、角色与权限的关系、权限设计注意点
权限设计模型
RBAC（基于角色的权限访问控制）是权限设计的经典模型，应该是后台系统应用最多最为成熟的权限管理模型。RBAC其实是一组模型的统称，其下根据权限管理的复杂程度由简单至复杂又分为RBAC0-RBAC3四个模型。
RBAC0 基础RBAC模型
RBAC0是RBAC模型的核心基础思想，即用户通过被赋予角色和权限进行关联。用户、角色和权限之间的两两关系均是多对多关系，即一个用户可以被赋予多个角色，一个角色可以被赋予多个用户。一个角色可以拥有多项权限，一项权限可以赋予多个角色。
RBAC1 引入继承关系的RBAC模型
RBAC1是在RBAC0的基础上引入了角色的继承关系，从上图举例，角色2继承自角色1，角色1拥有权限1-3，则无须再单独赋予角色2。角色2自动拥有权限1-3，并且还可以单独赋予权限4-6。
这种一般应用在组织架构的权限中，例如一个部门中的多个业务小组，每个业务小组只能看到自己小组的数据，但部门经理可以看到全部小组的数据。
RBAC2 增加了限制关系的RBAC模型
RBAC2即在用户和角色之间，或角色和权限之间增加的限制。
①互斥角色限制：例如A已经被分配发起流程的角色A，就不能再分配审批流程的角色B，这样就会导致业务流程存在漏洞。但这也会根据所在公司的实际情况而定，并不是必不可少的限制条件。
②角色基数限制：例如单个用户最多只能被赋予3个角色，同样也需要根据所在公司的实际情况而定。
③先决条件限制：例如角色A为角色B的上级，要想为用户分配角色A，则必须先分配角色B。同样也需要根据所在公司的实际情况而定。
④拥有多个角色情况下，运行时只能激活一个角色
以上限制并不是使用RABC过程中必不可少的，往往在实际业务场景中，系统是需要非常灵活的，过多的限制反而会阻碍业务的开展。产品经理在设计时，需要懂得根据实际业务场景，对RBAC模型进行改造利用。如果完全套用，则只能说是“尽信书，不如无书”。
RBAC3 兼有RBAC1和RBAC2特性的RBAC3
RBAC3模型就是RBAC1和RBAC2的结合体，拥有两者的特性。
其他 引入用户组和权限组的RBAC
除了教科书式对RBAC的经典定义外，还有不少其他特性未包含在定义内的。例如用户组和权限组的概念。
用户组：当用户数少时，管理员可以给用户单独赋予权限。但一旦用户多之后，再单个赋予权限就不现实了。这时就需要将同类用户组成一个组，例如部门、项目组等等，按照组来赋予权限。个人理解组的权限是依赖于组而存在的，但某用户离开了当前用户组之后，就自动失去了该组的权限。同时用户在组中时，同样不影响对该用户单独赋予权限。
权限组：权限组则是将多个权限直接打包，在赋予权限时，直接按权限组赋予。
目前比较常用的应该是用户组的这种特性。
权限的构成
权限的构成很简单，可以分为功能权限和数据权限两大类。
| 权限类型 | 权限单元 | 二级权限单元 | 说明 |
|---|---|---|---|
| 功能权限 | 入口/菜单 | 查看 | 后台最常见到的权限控制方式，简单直接。 |
| 页面权限 | 字段 | 页面特定字段/文本的可见权限 | |
| 按钮 | 页面特定按钮的可见权限 | ||
| 附件 | 页面特定附件的可见权限 | ||
| 操作权限 | 按钮 | 页面特定按钮的可操作权限 | |
| 附件 | 页面特定附件的操作差异化权限，例如A角色点击图片附件为预览附件，而B角色点击附件为下载附件。 | ||
| 数据权限 | 报表权限 | 查看 | 某个报表的查看权限 |
| 导出 | 某个报表的查看权限 | ||
| 字段权限 | 查看 | 某个报表字段的查看权限 |
不同的系统可能权限单元颗粒度不一样，逻辑简单角色少的系统或许只需入口级权限就能满足各角色的隔离需求。但在条件允许的情况，还是需要将系统的权限单元颗粒度划分得足够细，这样在系统由简单到复杂的过程中，系统的权限设计框架就无须重构也能支持系统的拓展。
权限的设计思路
在了解了权限的设计模型和权限的构成之后，就不难总结出一套产品在日常工作中使用的设计思路。
1 梳理系统组织架构及权限描述
系统的组织架构需要真实反映业务的组织架构，梳理标准化的部门、岗位。根据标准化的部门和岗位梳理出部门和岗位的基础权限以及特定权限。
在和业务方进行需求调研时，往往能得到的只是某个岗位的碎片化权限描述。所以可以结合部门职责和岗位职责，再加上业务方的口述资料来梳理出部门和岗位的组织关系以及初略的权限。
2 拆解系统权限单元
根据第一步的调研之后，就可以根据业务需求来对系统的功能和数据拆解成一个个权限单元，然后再以权限的维度来分配给岗位（角色）。
如果存在多个部门的情况，还需要按照部门划分来进行分配。
如果需要用到用户组的机制，对部门赋予权限，则需要以部门为单位来分配权限。
权限设计注意点
- 需要考虑人员是否存在兼部门和兼岗情况
- 工作流的审批权限可以和功能权限分开配置，更加灵活
