在构建企业级平台或复杂应用系统时，权限管理是一个至关重要的环节。它决定了哪些用户可以访问哪些资源，以及可以进行哪些操作，一个健全的权限管理架构，在确保系统正常运行的同时，也能有效防止数据泄露和非法访问，从而为企业带来可信赖的信息保障。选择合适的权限模型，不仅能保障系统的安全性，还能提升管理效率。为了满足身份管理法规要求并规避风险，企业必须清点、分析和管理用户的访问权限。然而，面对多种不同的权限模型，企业应该如何做出正确的选择呢？

权限管理面临困境

权限复杂度增加，管理难度加大

随着企业规模的扩大和业务的多样化，权限管理的复杂性也随之增加。不同部门、岗位、员工的权限需求各不相同，加之企业内部组织结构的频繁变动，导致权限的设置和调整变得非常复杂。管理者可能难以全面掌控每个用户的具体权限，容易出现权限交叉、权限重叠、或不必要的权限扩大，导致管理难度加大。权限的无序扩展不仅增加了管理者的工作负担，还可能导致敏感数据的泄漏和滥用风险。但传统权限管理方法无法实现细粒度的权限授予，缺乏统一的权限实体，难以贴合业务现况。

权限变更不及时，安全隐患增加

企业中的权限变更往往滞后于实际的业务需求。例如，当员工离职、岗位调动或职责发生变化时，权限可能不会及时调整或撤销，导致前员工仍然拥有对敏感系统或数据的访问权限。权限延迟会增加数据泄露和系统滥用的风险。如果员工岗位调动时，权限未及时更新，新岗位的员工可能获得不必要的权限，而旧岗位的权限则可能被滥用，为企业的数据安全带来了极大的风险。

缺乏统一标准，权限管理不规范

在缺乏统一权限管理标准的企业中，权限分配往往依赖于个人的判断或临时需求，导致权限设置不一致，缺乏系统性和规范性。不同部门或系统可能采用不同的权限管理方法，增加了整体管理的复杂性，也可能导致权限管理的盲点或疏漏，最终影响企业的安全性和合规性。例如，在某个部门中，员工的权限可能是根据其直接主管的判断分配的，而在另一个部门，权限分配则可能基于过去的惯例或紧急情况的需要。但差异化的权限管理方法，虽然在短期内能够满足部门的需求，但长期来看，会给企业的整体管理带来极大的复杂性。

在面对权限管理中的诸多挑战时，企业引入权限模型来管理员工权限显得尤为重要。通过权限模型，企业能够更加系统化、规范化地管理和分配员工的权限，避免权限设置的混乱和不一致，提升管理效率，并有效减少安全隐患。但三种权限模型分别是哪三种？他们之间有何区别？企业应该如何选择呢？

 

三大权限模型介绍

什么是基于角色的访问控制（RBAC）

基于角色的访问控制（Role-based access control，简称 RBAC），指的是通过用户的角色（Role）授权其相关权限，这实现了更灵活的访问控制，相比直接授予用户权限，要更加简单、高效、可扩展。

 

当使用 RBAC 时，通过分析系统用户的实际情况，基于共同的职责和需求，授予他们不同角色。你可以授予给用户一个或多个角色，每个角色具有一个或多个权限，这种 用户-角色、角色-权限 间的关系，让我们可以不用再单独管理单个用户，用户从授予的角色里面继承所需的权限。

以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。

我们授予某个用户「Admin」这个角色，他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。不直接给用户授权策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。

什么是基于属性的访问控制（ABAC）

ABAC 是一种基于用户属性、资源属性、环境属性和操作属性等多种属性进行访问控制的权限管理模型。通过将这些属性进行组合和关联，形成一个多维度的访问控制策略，实现动态的访问控制。当用户发起访问请求时，ABAC 会根据请求中的属性信息和预先定义的策略进行匹配和评估，最终决定是否允许该请求。适用于需要细粒度访问控制、权限策略需要动态调整的场景。

ABAC主要包括策略定义和策略评估两个过程：

策略定义：策略定义决定了哪些用户可以访问哪些资源，以及如何进行访问控制。策略定义可以通过编写规则、表达式或脚本等方式来实现。

策略评估：当用户发起访问请求时，ABAC 的评估引擎会根据请求中的属性信息和策略规则进行匹配和计算，最终得到一个访问控制决策结果。

在系统中实现 ABAC 需要考虑到系统的架构、性能、安全性等因素。一般来说，可以将 ABAC 作为一个独立的权限管理模块集成到系统中，或者将 ABAC 的实现与现有的 RBAC 或其他权限管理模型进行结合。ABAC 基于用户、资源、环境等多种属性实现高度细粒度的权限控制，可以根据属性变化实时调整权限。适用于需要处理大量数据和用户，需要动态和细粒度管控以及确保不同租户之间的数据隔离等对数据安全和隐私保护有严格要求的场景。

什么是下一代访问控制模型 （NGAC ）

NGAC，即下一代访问控制。NGAC 可以实现系统化、策略一致的访问控制方法，以高精细度授予或拒绝用户管理能力。NGAC 使用图的概念以简单、集中的方式管理访问。它可以在任何组织规模下线性扩展，并且不会出现性能问题。它最大的好处是灵活性——它可以允许基于对象属性、时间、位置或任何其他标准进行访问。NGAC 的另一个独特功能是它支持实时访问，例如，它可以授予承包商对资源的一次性访问权以进行维护，然后自动撤销访问权。

面向场景

NGAC 是基于这样一个假设：你可以用一个图来表示你要保护的系统，这个图代表了你要保护的资源和你的组织结构，这个图对你有意义，并且符合你的组织语义。在这个对你的组织非常特殊的模型之上，你可以叠加策略。在资源模型和用户模型之间，定义了权限。其本质上就是创建了一个图，以对每个组织都有意义的方式对用户想要保护的资源和组织结构进行建模。基于此自定义的组织模型，管理员可以添加访问策略和权限。这样 NGAC 提供了一种优雅的方式来表示你要保护的资源，系统中的不同角色，以及如何用权限把这两个世界联系在一起。

我该如何选择使用哪种权限模型

在这里，组织的规模是至关重要的因素。由于 ABAC 最初的设计和实施困难，对于小型企业而言，考虑起来可能太复杂了。对于中小型企业，RBAC 是 ABAC 的简单替代方案。每个用户都有一个唯一的角色，并具有相应的权限和限制。当用户转移到新角色时，其权限将更改为新职位的权限。这意味着，在明确定义角色的层次结构中，可以轻松管理少量内部和外部用户。

但是，当必须手动建立新角色时，对于大型组织而言，效率不高。一旦定义了属性和规则，当用户和利益相关者众多时，ABAC 的策略就更容易应用，同时还降低了安全风险。

简而言之，如果满足以下条件，请选择 ABAC：

你在一个拥有许多用户的大型组织中；

你需要深入的特定访问控制功能；

你有时间投资远距离的模型；

你需要确保隐私和安全合规；

但是，如果满足以下条件，请考虑 RBAC：

你所在的是中小型企业；

你的访问控制策略广泛；

你的外部用户很少，并且你的组织角色得到了明确定义；

如果想要更加细粒度的权限模型，请考虑 NGAC：

NGAC 通过采用一种新颖且巧妙的方法，解决了传统访问控制模型中的这些不足：它在用户提供的现有世界表示之上叠加访问策略。在 NGAC 模型中，你同样可以对 RBAC 和 ABAC 策略进行建模。在 ABAC（基于属性的访问控制）中，需要持续跟踪所有对象的属性，给管理带来了极大的负担。而 RBAC（基于角色的访问控制）虽然减少了这一负担，因为它提取了所有角色的访问信息，但这种模式容易导致角色爆炸问题，最终同样难以管理。而 NGAC 以一种紧凑、集中的方式提供了我们所需的一切，简化了管理的复杂性。

下表从几个方面对 ABAC、RBAC 和 NGAC 进行了比较。

 

 

如何将权限模型集成至你的应用

集成 RBAC 权限模型到你的应用系统

创建角色

你可以使用 Authing 控制台创建角色：在权限管理 - 角色管理中，点击添加角色按钮：

· 角色 code: 该角色的唯一标志符，权限分组内具有唯一性，只允许包含英文字母、数字、下划线 _、横线 -，这里我们填 admin。

· 角色描述：该角色的描述信息，这里我们填管理员。

授权用户角色

在角色详情页面，你可以将此角色授权给用户。你可以通过用户名、手机号、邮箱、昵称搜索用户。选择用户之后点击确认，你可以查看被授权此角色的用户列表。

 

在后端通过用户角色控制权限

当用户成功认证、获取到 Token 之后，你可以解析到当前用户的 ID，接下来你可以使用我们提供的 API & SDK 在后端获取该用户被授予的角色，

这里以 Node SDK 为例，我们同时还支持 Python、Java、C#、PHP 等语言的 SDK 。

首先获取用户的被授予的所有角色列表：

import { ManagementClient } from 'authing-js-sdk'const managementClient = new ManagementClient({userPoolId: 'YOUR_USERPOOL_ID',secret: 'YOUR_USERPOOL_SECRET',})const { totalCount, list } = await managementClient.users.listRoles('USER_ID')

得到用户的所有角色之后，我们可以判断该用户是否具备 devops 这个角色：

if (!list.map((role) => role.code).includes('devops')) {throw new Error('无权限操作！')}

创建资源

上一步我们通过用户是否具备某个角色来控制权限，这种权限控制还是比较粗粒度的，因为只判断了用户是否具备某个角色，而没有判断其是否具备某个特定的权限。Authing 在基于角色的访问控制模型（RBAC）的基础上，还能够围绕资源进行更细粒度的授权。

你可以把系统的一些对象抽象为资源，在这些资源上可以定义了一些操作。比如在本文的场景中，Repository、Tag、PR、Release Notes 都是资源，且这些资源都有对应的操作：

· Repository：创建、删除等。

· PR：开启、评论、合并等。

· Tag：创建、删除等。

· Release Notes：创建、阅读、编辑、删除等。

授权角色操作资源的权限

Authing 还同时支持给用户、角色授权，如果用户在某个角色中，他也将继承这个角色被授权的权限。所以 Authing 既能够实现标准的 RBAC 权限模型，也能在这基础上进行更细粒度、更动态的权限控制。

比如下面这个例子中，我们给 admin 这个角色授权了 repository 资源的 Create 和 Delete 权限：

 

集成 ABAC 权限模型到你的应用系统

在上面介绍了如何将 RBAC 权限模型的集成方法，相信你也意识到了，RBAC 权限模型是静态的，也就是没有环境、对象属性等动态属性参与，所以很难实现类似于以下场景的访问控制：

· 当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档；

· 当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档；

· 早上九点前禁止 A 部门的人访问 B 系统；

· 在除了上海以外的地方禁止以管理员身份访问 A 系统；

ABAC 的主要组成部分

在 ABAC 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。

· 对象：对象是当前请求访问资源的用户。用户的属性包括ID，个人资源，角色，部门和组织成员身份等；

· 资源：资源是当前访问用户要访问的资产或对象（例如文件，数据，服务器，甚至API）。资源属性包含文件的创建日期，文件所有者，文件名和类型以及数据敏感性等等；

· 操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”；

· 环境：环境是每个访问请求的上下文。环境属性包含访问尝试的时间和位置，对象的设备，通信协议和加密强度等。

ABAC 如何使用属性动态计算出决策结果

在 ABAC 的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC 决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。

例如，策略「当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档」会被以下属性匹配：

· 对象（用户）的部门 = 资源的所属部门；

· 资源 = “文档”；

· 操作 = “访问”；

策略「早上九点前禁止 A 部门的人访问B系统；」会被以下属性匹配：

· 对象的部门 = A 部门；

· 资源 = “B 系统”；

· 操作 = “访问”；

· 环境 = “时间是早上 9 点”。

在 Authing 中授权资源的时候指定限制条件

我们在授权资源的时候，可以指定限制条件。例如在下面的例子中，我们添加了一个限制条件：要求当前请求的用户经过了 MFA 认证。

除了 MFA 认证这个属性外，你还可以在 Authing 的策略引擎上下文中获取以下属性：

· 用户对象属性，如性别、组织机构、分组、角色、邮箱是否验证、手机号是否验证、自定义数据、是否经过了 MFA 认证、用户上次 MFA 认证时间等；

· 环境属性：客户端 IP、客户端 UA、客户端浏览器、请求来源国家、请求来源省份、请求来源城市等；

· 资源属性：资源创建时间、资源拥有者、资源标签等；

你可以根据这些属性组成灵活的策略授权语句。

集成 NGAC 权限模型到你的应用系统

NGAC 是最好的一种模型。选择 NGAC 的理由其实和选择图数据库还是关系型数据库上做对比。为什么选择图数据库？因为业务是不断变化的，这就导致了数据模型是经常变化的，用关系型数据库需要不停变更元字段、关联关系和查询语句以匹配业务需求，而用图模型只需要改变两个数据之间的连接关系，如下所示：

 

同样是表示一种多层级关系，用图数据库是符合人类的直觉的，而用关系型数据库，却需要建多个表做联合查询。不管是 RBAC 还是 ABAC 都是关系型数据库的关联关系模型，而 NGAC 是跳脱出关联模型的图模型，这也是为什么 NGAC 被称作下一代访问控制。虽然 NGAC 模型已经很好，但以上所有这些模型都有一个致命的缺陷 —— 没有计算能力。而 OPA 是具有计算能力的 NGAC 模型。OPA 就是遵循同样理念的，对权限模型重新设计的权限编程语言。他既有 NGAC 的表现能力，又有 Prolog 的计算能力。

Authing 将 OPA 作为决策引擎，改善自适应认证、自适应 MFA 和持续认证能力，底层模型全面改由 OPA 支撑，并为用户提供 Rego 编程语言达到完全定制化的权限模型定义和计算。Authing IDaaS 提供基于 OPA 引擎的 RBAC & ABAC 权限管理模型，既可以管理业务中的实体资源，也可以管理数据、API、菜单、按钮等细颗粒度权限控制。不仅如此，Authing IDaaS 完善 OPA 计算监控、请求监控、决策监控、决策设计器、代码编写，覆盖决策和决策计算的全生命周期，成为下一代决策引擎和风控引擎。