由于信息安全越来越被重视，企业的身份管理已经成为市场焦点，对于实施企业级安全策略和身份管理的需求随之迅速上升。而作为权限访问控制策略的 RBAC（基于角色的访问控制）模型也已被广泛使用到组织机构管理中，本文将带领各位了解 RBAC 权限模型如何用作组织机构管理。

01.

RBAC 是什么？

RBAC（ Role-Based Access Control）即基于角色的访问控制模型，该模型的核心是所有访问都是通过「角色」进行的，所有「用户」都只能通过分配给他们的角色或通过角色层级结构继承的角色获得对应权限。与传统的 ACL（Access Control List）权限模型不同的是，ACL 是将权限直接授予给具体的用户，而 RBAC 则是分配给用户对应的角色，该用户就可以获得角色的所有权限，这样可以实现用户和权限的逻辑分离，极大程度上简化用户的权限管理。

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

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

图：Authing 控制台实操画面

不直接给用户授权的策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。

02.

什么是角色？角色和组有何不同？

在 RBAC 模型中，角色本质上是权限的集合，是用于构建权限的语义结构。在一个组织内，角色相对稳定，而用户和权限会随着企业规模和业务发展变化很快，因此，通过角色控制所有访问可以简化访问控制的管理和审查。

角色和传统的组的定义有何不同？传统组指的是用户的集合，权限可以与用户及其所属的组相关联。在基于组的权限管理机制中，将权限直接绑定至用户的权限管理策略，难以胜任现代信息安全管理的要求。而 RBAC 中角色同时具备用户集合和权限集合的概念，角色是这两个集合的媒介。RBAC 区别于传统组的另一个方面是会话的概念，它允许激活分配给用户的角色子集。

03.

RBAC 模型的优劣势

如上文所述，RBAC 简化了用户与权限的关系，使其管理更灵活高效以及更易拓展。RBAC 提供了一种系统化的方法，用于定义和维护角色，让管理者仅需通过赋予用户角色来提供一致性的访问权限，从而降低数据泄露风险。虽然 RBAC 是一种无确定性质策略模型，但仍然支持三大安全原则：

即通过对每个角色赋予相应的权限，通过对每个用户赋予相应的角色，从而实现给用户分配相应的权限，保障该权限不超过该用户完成其任务所需要的权限即可。

针对特殊安全要求任务，可以通过设置和调用相互独立互斥的角色来共同完成。

通过抽象权限来实现。例如财务操作可以抽象为用借款、存款等权限，而不是使用典型的读、写来执行权限。

对于没有特殊权限管理需求的组织架构的企业或机构，RBAC 可以帮助企业：

RBAC 也并非适用所有的组织机构，对于大型组织机构或者有特殊权限访问控制需求的企业，RBAC 并不能全然满足。例如：

RBAC 权限管理模型足以满足大多数中小微企业的权限管理需求，并且我们还提供快速集成 RBAC 权限模型至你的应用系统中的方案，点击文章底部阅读原文即可了解。另外如果你在一个拥有众多用户的大型组织中，或者你的组织需要有特定访问控制功能，我们的身份专家也能为您提供最可靠完备的解决方案。

Authing 是国内唯一以开发者为中心的全场景身份云产品，为企业和开发者提供高安全、高性能、高生产力的用户认证和访问管理服务。

Authing 目前已经服务包括可口可乐、招商银行、三星集团、中国石油、元气森林在内的 30000+ 企业和开发者。

了解 Authing