文章目录
部门目前主要研发的是一套新零售 SAAS 系统，作为 SAAS ，不仅要为商家提供业务上的能力，还需要提供严格的权限管理能力。例如多个企业、门店的权限，同一个业务主体下，还有老板、店长、业务员、库管等等角色，这些都需要系统提供管理权限的能力来支撑。本篇主要总结常见的权限管理模型。
ACL（Access Control List）
访问控制列表 ACL 是最早的、最基本的一种访问控制机制，是基于客体（资源）进行控制的模型，在其他模型中也有 ACL 的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。
原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。
举例：当用户 A 要对一篇文章进行编辑时，ACL 会先检查一下文章编辑功能的控制列表中有没有用户 A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。
优点：模型比较简单直接，效率高，实现简单。常见于文件系统的权限管理。
缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。
RBAC（Role Base Access Control）
基于角色的访问控制（Role-Based Access Control，简称 RBAC） 指的是通过用户的角色（Role）授权其相关权限，实现了灵活的访问控制，相比直接授予用户权限，要更加简单、高效、可扩展。
一个用户可以拥有若干角色，每一个角色又可以被分配若干权限这样，就构造成“用户-角色-权限” 的授权模型。在这种模型中，用户与角色、角色与权限之间构成了多对多的关系、
通过 RBAC模型 ，当存在多个用户拥有相同权限时，我们只需要创建好拥有该权限的角色，然后给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。它是防止权限泛滥，实现最小特权原则的经典解决方案。
优点：比 ACL 更具扩展性；在粗粒度的访问控制中工作得特别好，比如这样的场景：拥有经理角色的用户可以批准采购单。
缺点：随着组织的演进，往往出现角色爆炸的现象；另外资源与角色紧藕合，改一个角色会影响多个资源；安全管理成本较高。
适用于：
- 组织结构明确的系统，即系统具备明确定义角色和职责的组织，例如企业内部系统或公司网络。
- 提供较简单的访问控制需求，其中权限只基于用户的角色。
简单的 RBAC 模型可以按照如下关系设计：
另外 RBAC 模型又可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用 RBAC0 的模型就可以。另外，RBAC0 相当于底层逻辑，后三者都是在 RBAC0 模型上的拔高。
- RBAC0
即基本的 RBAC 模型；
-
RBAC1
主要在角色中引入继承的概念，增加了角色分级逻辑，即下级可以继承上级的权限。
使用场景：如某个业务部门，有经理、小组长、专员。小组长的权限不能大于经理，专员的权限不能大于小组长，如果采用RBAC0模型做权限系统，极可能出现分配权限失误，最终出现小组长拥有经理都没有的权限的情况。
而 RBAC1 模型就很好解决了这个问题，创建完经理角色并配置好权限后，小组长角色的权限继承经理角色的权限，并且支持在经理权限上删减小组长权限。
-
RBAC2
基于 RBAC0 模型，对角色增加了更多约束条件，如角色互斥，角色数量限制等。主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。
-
RBAC3
RBAC3 = RBAC1 + RBAC2，包含了 RBAC1 和 RBAC2，用于大型的非常复杂的系统，一般的系统用的比较少。
ABAC（Attribute Base Access Control）
基于属性的访问控制（Attribute-Based Access Control，简称 ABAC）是一种比 RBAC 更加灵活的授权模型，它的原理是通过各种属性来动态判断一个操作是否可以被允许（动态计算一个或者一组属性是否满足某一条件来进行授权）。ABAC 中一般来说包含用户属性、环境属性、操作属性以及资源属性。
比如，以下是一个表达门禁访问权限的伪代码（ABAC 通常会设计 DSL 来表达，如 XML 等）：
如果当前时间在 8 点到 18 点之间，并且用户拥有员工角色
这个模型在云系统中使用的比较多，比如 AWS，阿里云等。
好处
- 能够地从组织内部自然获取到的信息来做访问控制决策
- 集中化管理
- 可以在不需要部署应用的情况下更改这个决策
- 可以按需实现不同颗粒度的权限控制
- 易于审计
坏处
- 比较复杂，管理维护实现都比较复杂
- 实施难度较大
- DSL 的学习曲线
- 权限判断需要实时执行，规则过多会导致性能问题
适用于：
- 复杂的、灵活的访问控制需求，需要基于多种属性、策略和环境条件实现访问控制的复杂系统，例如云计算环境、大型组织或跨组织的系统；
- 需要动态调整访问权限的系统，根据用户的属性和环境条件进行访问控制。
DAC（Discretionary Access Control）
DAC 自主访问控制，让客体（资源）的所有者来定义访问控制规则。它是 Trusted Computer System Evaluation Criteria （TCSEC）定义的和一种访问控制机制，在 DAC 中，系统会根据被操作对象的权限控制列表中的信息，来决定当前用户能够对其进行哪些操作，用户可以将其具备权限直接或者间接授予其他用户。
比如百度网盘的资源上传者，需要将文件分享给他人时，就可以定义是对所有人公开，还是只对百度网盘用户公开，还是只对知道密码的人公开等等，并且可以定义对哪些人只读，对哪些人可以修改等等权限。
好处
- 灵活
- 维护成本低
- 降低了管理员的工作难度
坏处
- 增强了整体访问控制监管的难度
- 安全性没有保证，完全取决于所有者的个人安全意识
MAC（Mandatory Access Control）
强制访问控制，通过定义安全级别标签来进行访问控制，也叫非自主访问控制，它可以限制主体对资源（客体）执行某种操作。它的安全策略由安全策略管理员集中控制，用户无权覆盖策略。比如为了保证机密性，MAC 不允许低级别的主体读取高级别的客体、不允许高级别的主体写入低级别的客体；为了保证完整性，MAC 不允许高级别的主体读取低级别的客体，不允许低级别的主体写入高级别的客体。一般普通公司不会采取 MAC，除非有相应的合规要求。
好处
- 非常安全
坏处
- 对实施要求很高
- 需要对所有数据进行标记
参考