RBAC模型和ABAC模型是什么，有什么区别

RBAC的核心思想是，访问权限不直接授予用户，而是授予“角色”（Role）。然后，将用户分配到相应的角色中。这样，用户就通过其所属的角色，间接地拥有了该角色所包含的所有权限。

它的关系可以简化为：用户-角色-权限 (Who -> What roles -> What permissions)。权限的集合是静态地绑定在角色上的。

让我们以一个常见的内容管理系统（CMS）为例：

用户 (Users): 张三、李四、王五
角色 (Roles):
- 管理员 (Admin): 拥有系统的所有权限。
- 编辑 (Editor): 可以创建、修改和发布文章。
- 撰稿人 (Contributor): 只能创建和修改自己的文章草稿，不能发布。
权限 (Permissions):
- post:create (创建文章)
- post:edit (修改文章)
- post:publish (发布文章)
- user:manage (管理用户)

在这个模型中，我们的授权逻辑如下：

我们将权限分配给角色：
- 管理员角色拥有 post:create, post:edit, post:publish, user:manage 权限。
- 编辑角色拥有 post:create, post:edit, post:publish 权限。
- 撰稿人角色拥有 post:create, post:edit 权限。
我们将用户分配给角色：
- 张三是管理员。
- 李四是编辑。
- 王五是撰稿人。

现在，当王五尝试发布文章时，系统会检查：王五是“撰稿人”角色 -> “撰稿人”角色没有 post:publish 权限 -> 拒绝操作。

RBAC的优点是模型清晰，易于理解和管理。在用户和权限数量众多时，通过角色这个中间层，极大地简化了授权管理。

ABAC是一种更为灵活和精细的访问控制模型。它的核心思想是基于一系列“属性”（Attribute）来动态地决定是否授予访问权限。这些属性可以来自任何地方。

通常，ABAC的决策逻辑基于一个“策略”（Policy），这个策略会评估以下四类属性：

它的决策可以表述为：当主体的属性、客体的属性、操作和环境属性满足某个策略时，允许或拒绝访问。

我们以一个企业报销系统为例，这个场景用RBAC会非常复杂：

假设有一个策略 (Policy)：
“允许一个用户审批报销单，当且仅当：

在这个模型下：

当用户A尝试审批报销单C时，系统评估：

当用户A尝试审批报销单D时，因为 8000 不小于 5000，操作将被拒绝。而用户B则可以审批报销单D。

可以看到，ABAC不需要为“5000元额度经理”和“10000元额度经理”创建两个不同的角色，而是通过动态评估属性来实现更细粒度的控制。

	RBAC (基于角色的访问控制)	ABAC (基于属性的访问控制)
核心思想	以“角色”为中心，权限静态地赋予角色。	以“策略”和“属性”为中心，权限是动态计算出来的。
授权粒度	较粗。权限控制到角色级别。	非常精细。可以控制到每一次具体访问的上下文。
灵活性	较低。对于超出角色定义的场景，需要创建新角色，可能导致“角色爆炸”。	极高。可以组合无限的属性来定义复杂的访问规则，无需修改主体或客体。
管理复杂度	概念简单，易于上手。但在复杂场景下，角色管理会变得困难。	初期设置复杂，需要设计策略引擎和属性来源。但对于复杂规则，长期维护更清晰。
适用场景	适用于企业内部系统、CMS等权限结构稳定、分层明确的场景。	适用于金融、云计算、物联网等需要高度灵活、动态和上下文感知权限控制的场景。