随着系统用户角色的增多，这个时候，权限管理系统就应运而生了，结合权限管理系统，企业可以让用户只能访问自己被授权的资源。那么企业怎么基于RBAC基本模型和业务形态，搭建合适自身的权限管理模型呢？一起来看看作者的解读。

(资料图)

随着企业的发展，就会出现不同权限和不同的岗位的员工，针对不同权限或者工作职责的员工就会产生不同的权限；系统也是一样的，随着一个系统用户或者角色的增多，针对不同用户和角色的权限控制就会应运而生。

什么是权限管理？了解什么是权限管理前，我们得先明白什么是资源？

我们通常在设计或者使用系统时会听到“菜单”“按钮”“查看”等。没错，资源可以理解为一个“菜单”、一个“按钮”、一个“查看”，只要你理解的可控制可操作可查看的一个东西，那么他就可以称之为一个“资源”。

那么我们再来看什么是权限管理，权限管理就是根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。

说白了，就是配置用户能够点开的菜单、能够操作的按钮、能够查看的数据，能够操作的数据。

权限管理作为一个系统必不可少的功能，在20世纪90年代就有大量的专家进行了深入研究，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。

主要以“最小特权原则”“责任分离原则”和“数据抽象原则”三个安全原则创建出了RBAC96模型（包含RBAC0、RBAC1、RBAC2、RBAC3四个概念模型）。

RBAC模型中包括用户、角色、许可权三个基本数据元素，这三个元素也是组成权限控制最基础的东西。有了这三个元素，我们就能够搭建起一套简单的权限管理模块。

上文我们已经提到RBAC96有4种模型，分别是RBAC0、RBAC1、RBAC2、RBAC3，随着0~3的递进，对用户权限的管理也越来越细致和精确以及复杂。

1）RBAC0

通过将权限赋予角色，再将角色赋予用户的形式。将权限分配给用户，其中用户和角色，以及角色和权限都是多对多的关系，这就实现了身兼多职用户的权限开放和管理。

2）RBAC1

RBAC1就是建立在RBAC0之上，只是在角色中多增加了继承的概念。实际业务上看就是主管也拥有下属的功能权限。主要实现了权限的继承。

3）RBAC2

针对多个角色的用户，根据不同的使用场景控制角色的激活。举个例子。

4）RBAC3

RBAC3就是整合0~2的统一模型，既包含角色控制权限的功能，也有继承和各种规则的限制。

针对不同的业务或者领域，会依据特殊情况而对权限管理进行调整。例如，在设计履约类或者财务类的数据为主领域的系统时，我们就要将结合功能权限和数据权限做一套复杂的结合型权限模块。再比如像系统需要根据不同属性（IP地址、职级、时间等）来对进行权限控制。

当一家公司系统多了以后，出于能够统一管理以及方便管理的目的，就会建立一个管理系统IAM（身份与访问管理），因为公司不单单要考虑单个系统的权限管理，也要考虑多系统的权限管理，甚至多租户的权限管理。

其中最常见的问题就是因为业务管理和行政管理上的差异而导致的多系统组织和中台组织有冲突的时候，这个问题要分三种情况来看。

各系统组织需要共用，这种类型的系统也是比较常见的，场景更多因为用户池内的用户为企业员工（包含HRM、CRM等内部管理系统），此时组织和行政组织是一致的。各系统之间没有因为复杂的业务形态衍生出来与行政组织不一致的组织，只需要根据公司的管理方式考虑权限是收拢在管理系统控制还是分散在各个系统进行管理。

各系统有自我的组织，但是各系统的权限授权是统一管理，那么数据权限在这个时候就出现了业务组织和行政组织冲突的情况。

针对这种情况，一般会采用行政组织和业务组织剥离的方式，即用户的组织关系使用行政组织管理，业务的组织关系独立设立，再将用户和业务组织挂钩，业务组织和行政组织进行关联，从而实现用户在不同系统权限控制和组织数据权限控制。通过这样的方式方法来解决组织出现不一致的问题。

不同企业会有不一样的权限管理需求，我们需要基于RBAC基本的模型再结合业务形态搭建合适自身的权限管理模型。

本文由 @L.Hwang 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。