域名频道资讯站RBAC模型是通过分离权限与用户的耦合关系，将权限关联在角色上，用户通过扮演适当的角色获得合适的权限的权限管理方式。本文在RBAC模型的基础下，整理权限设计过程中的客户场景、总结设计思路。
一、项目背景
本项目是一个关于OA系统升级改造的ToG项目，涉及3000+单位5万用户，横跨市–区县–镇街3层行政区划。各单位之间业务信息交流频繁，业务上经常需要跨单位、跨部门的协同运作。在系统层面，所有单位均在同一租户下，由基础平台负责各业务子系统权限的统一管理。
二、从组织架构看权限的管理模式
回顾整个项目，在进行权限设计之前，必需先了解现场的组织架构。因为RBAC模型主要描述的只是用户–角色–权限之间的关系，而决定RBAC模型复杂程度的是业务上的组织架构。
当组织架构达到一定量级的复杂程度后，根据系统部署的方式或管理理念的不同，会分化出不同的权限管理模式，不同的管理模式对系统权限设计也会有不一样的要求。
下面以全市组织架构为例进行说明：
图1 组织架构层级
1. 组织架构说明
以上的组织架构主要分为5种层级：
- 行政区划：具有业务属性的单位集合；可用于数据权限划分时的区域划分；
- 集合：没有业务属性的单位集合；通过集合的归类，让用户更便捷地找到所需单位；
- 单位：基础的权限单元，指机关、团体或企业；
- 部门：基础的权限单元，指单位的下级分支机构；
- 用户：组织架构组成的最小单元。
2. 不同组织架构下的权限模型
1）基础权限模型
适用场景：场景一 、场景二
基础权限模型适用于单个单位或组织架构相对扁平的企业。系统完全交付后，通过系统管理员的管理即可满足日常角色与权限的维护，各模块业务数据需求明确，是基本的RBAC模型，其业务管理模式如下：
- 由系统管理员负责角色的权限及用户分配。
- 由系统管理员创建单位管理员角色，由单位管理员负责角色的权限及用户分配。
因此，在这种模式下，系统管理经常兼任单位管理员的管理工作，对权限下放的设计要求不高，其角色树如图2所示。
图2 系统管理员≥单位管理员＞业务角色
RBAC模型已经定义了“用户–角色–权限”的授权模式，将系统功能拆分为操作权限与数据权限两个维度进行设计。在此框架下设计的权限模型，不管面向的企业对象如何变化，操作权限的设计思路都是不变的，仅需要对数据权限进行改造，即可满足企业的业务使用。
2）多单位管理模型
适用场景：场景三 、场景四
多单位管理模型适用于大中型单位组织架构，单位之间存在上下级关系且业务交流频繁。由于单位间的管理关系，需要横向或纵向的跨单位数据管理，考验权限对数据灵活配置的能力。
因此，大型系统的RBAC管理过程更为复杂，此时简单的RBAC已不能满足系统的访问控制分级管理的要求。尤其在信息系统中存储和管理大量企业单位的敏感数据，一旦这些数据被泄露或窃取，会给带来难以弥补的损失。
另外在企业运营中经常需要对组织架构和人员工作进行调整，相应地需要修改系统中访问控制主体和权限的关系。而系统管理员由于不了解调整内容导致授权工作滞后，即使修改后也不一定能准确反映调整状态，常需要多次补充修改，导致授权效率较低，影响正常的业务工作进程。
为了解决信息系统中访问控制管理的问题，适当简化授权工作量，提高权限管理效率，需要建立基于角色的多单位授权管理模型，其业务管理模式如下：
- 由系统管理员负责角色的权限及用户分配。
- 由系统管理员负责角色的权限分配，同时赋予单位管理员对角色分配用户的权限（定义标准角色，实现权限管理的部分下放）。
- 由系统管理员负责创建单位管理员角色，由单位管理员负责角色的权限及用户分配（不定义标准业务角色，实现权限的完全下放）。
在此模式下，系统管理员不再兼任单位管理员工作，需要实现权限的多级下放。
在场景四中，由于业务上对单位群进行划分，需要系统管理员或特定区域管理员管理单位集合或超出单位管理员权限的特殊角色，角色树较场景三更加复杂，具体角色树如图3所示。
图3 系统管理员≥区域管理员＞单位管理员＞业务角色
3）多区域管理模型
适用场景：场景五
多区域管理模式是多单位管理模型的拓展。
首先是对数据管理的要求更高，除了系统、单位、科室、个人的层级外，需要新增区域层级以管理某一范围内的数据信息。
其次，由于涉及多层级的权限管理，在满足多级权限下放需求，需要充分考虑不同层级角色对某一角色的管理问题、小权限角色对大权限角色的管理问题等。例如：区域管理与单位管理对某业务角色进行管理时，由于自身权限不同，可下放给此角色的权限也不相同。
如何避免小权限角色对大权限角色造成影响，需要我们结合业务实际使用情况进行设计。
业务管理模式如下：
- 由系统管理员负责角色的权限分配，同时赋予区域管理员、单位管理员对角色分配用户的权限（定义标准角色，实现权限管理的部分下放）。
- 由系统管理员负责创建区域管理员角色，由区域管理员分配单位管理员角色，由单位管理员负责角色的权限及用户分配（不定义标准业务角色，实现权限的完全下放）。
在此模式下，系统管理员也不再兼任区域管理员工作，角色树如图4所示。其中角色1-3为区域管理员，角色4-8为单位管理员。
图4 系统管理员＞区域管理员＞单位管理员＞业务角色
三、定义角色、职位、职务之间的关系
在我们用户信息管理中，需要填写用户的职位或职务，在定义角色、职位与职务的关系之前，需要先明确职位与职务之间的关系。
职位：指企业的某个员工需要完成的一个或一组任务；例如：销售总监 、销售经理、财务/出纳员、司机、仓库管理员等。
职务：职员所具有的头衔称谓，包括职权和职责两方面内容，随着语义的拓展职位亦有此意思；例如：科员，主任，经理，总经理。
因此，职位包含职务的意义，职务基本也与职位相对应。而系统中的权限，是用户在现实工作中的权限或工作范畴在系统中的映射。为了简化角色与职位之间的关系，定义现实中用户职位或职务中包含的权限，在系统上均通过角色进行管理设置。
四、角色权限的设计
角色设计主要分为角色管理、分配用户及分配权限3个模块，通过对这3个模块的控制，实现多区域管理模型下的权限设计。
1. 角色管理
在多区域管理模型下，需要支持权限统一管理与多层级权限下放两种场景。
分离角色的管理与使用权限，由创建单位对角色权限进行管理，创建单位与使用单位共同分配用户，可满足权限统一管理要求的同时，兼具各单位自行调整用户的需求。
图5 系统角色管理
2. 分配用户
分配用户的页面，需要根据用户当前管理的权限范围进行控制，仅支持查看和分配管辖范围内的用户。例如单位管理员仅支持查看和分配自己单位的用户，系统管理员可查看并分配系统内的所有用户。
由于同一角色可能支持多个管理员分配用户，为了系统安全与方便追溯，可通过操作人字段记录此用户是由谁进行分配的。
图6 分配用户
3. 分配权限
为了实现对系统各模块的权限管理，将每个模块划分为3个部分：菜单、页面数据、按钮。其中将菜单及按钮纳入操作权限，将页面数据归为数据权限。
由于各功能模块都是根据业务具体场景进行设计开发的，因此权限也需要根据业务具体要求而进行划分与设计。但为了系统的统一管理，可以建立统一的设计规范，以维持系统架构统一甚至减少开发工作量。
1）操作权限
操作权限用于控制此角色在系统中可对哪些模块做哪种操作。
通过控制菜单，实现管理用户控制特定模块的需求；通过页面按钮，实现控制用户在此模块下可以进行的操作。
以角色管理页面为例，分配角色管理菜单的用户，即可查看对应的角色数据，再通过对“新增”“删除”“启用”“禁用”等按钮的控制，限制用户在此模块下的操作。
部分页面的字段还需要区分“只读”“可改”，以实现各角色在相同页面中不同的管理需求。
图7 操作权限
2）数据权限
数据权限是权限管理中最核心的部分，随着组织架构的复杂，数据权限的设计也逐渐复杂甚至需要个性化开发。但从通用性上可以将数据权限划为两种类型：管理范围、列表字段。
管理范围用于管理当前模块的数据范围，在多区域管理模式下，主要将数据分为个人、部门、单位、区域及自定义五个维度。
为了支持业务中个性化的数据管理要求，可以通过自定义实现数据的个性化管理；另外区域维度需要组织架构支持，如果区域较少时，可以直接考虑通过自定义来实现。
列表字段用于同一列表同一数据范围下继续细分的数据权限管理，以实现同一数据下对部分敏感信息的隐藏。
图8 数据权限
五、写在最后
从产品角度出发，在RBAC权限模型下，对业务数据的灵活配置，支持数据、操作权限的多层级下放，是满足最多管理场景的设计模式。
但在项目角度，需要做好产品现状及改造的成本评估，结合现场培训、推广及后续维护的工作难度，选择合适的权限管理方式，才能尽快满足项目验收。
以本次项目为例，由于涉及单位较多，大型单位有频繁的角色调整需求，部分一级单位需要查看附属单位业务数据，但镇街级单位或部分附属单位人员较少，对系统使用要求不高。如果所有单位都自行管理系统角色，不仅增加了小型单位人员的工作量，还提高了前期推广的培训成本。
因此，对系统进行权限设计时，需要最大化场景考虑，以支持现场根据管理模式进行灵活调整。但现场也需要从实际业务出发，从自身成本与客户利益角度选择最优的管理方案。
我们规划大型系统平台时，除了关注系统功能之外，还需要了解客户的管理模式，从更宏观的角度观察整个业务的布局。因此在本次复盘中，除了对权限设计的总结外，还尝试归纳不同组织架构下权限的管理方式。
希望与各位一同进步，在ToB领域乘风破浪一往无前！
本文素材来自互联网
