数据库设计：RBAC 还是 ABAC？

Question

我有一个 SaaS 服务，多个用户可以在其中相互协作。到目前为止，同一个订阅帐户下的用户可以共享同一个数据库和 view/edit/delete 彼此之间的所有内容。

现在我想实现一个权限系统，这样用户就只能执行特定的操作，例如查看、编辑、更新和删除内容（在我的 SaaS 系统上，内容主要是客户卡片列表）。

我的第一个猜测是使用 RBAC 技术，定义角色和不同操作的位掩码，例如

查看客户名片
正在更新客户卡
正在删除客户卡
正在添加客户卡

这些权限与单个卡片实例无关，而不是用户可以执行的通用操作。第一个（查看）似乎在任何情况下都是必需的，因为如果看不到任何卡片就无法使用该系统。

不幸的是，我想我还需要某种针对每张卡的权限。例如，管理员用户可能希望让给定用户仅查看卡片的一部分，而不是全部。或者，管理员用户可以允许一组用户在特定卡片（或特定卡片）上进行协作，从而有效地在用户之间划分卡片列表。无论如何，我从未遇到过非管理员用户可以为自己或其他用户设置此类权限的场景。

RBAC 的表达能力是否足以对此类要求进行编码？或者我需要切换到 ABAC 吗？

Answer 1

经验法则如下：

如果你的授权要求中有关系，那就去ABAC。

让我解释一下。使用 RBAC，您可以执行定义角色、角色层次结构和权限等操作。您还可以进行某种程度的静态职责分离。例如，可以为用户指定角色经理和角色高级经理。总的来说，这赋予了他们查看客户记录的权利。到目前为止一切顺利。

但是...如果你需要说这样的话：

您只能查看您所在地区的客户
您无法查看与您有私人（亲子）关系的客户

那么您需要的不仅仅是 RBAC。正如您指出的那样，您将需要 abac。 ABAC 并没有完全取代 RBAC。您仍然需要用户、用户元数据（例如角色）以及从角色到权限的分配。不过，这些分配不会通过角色管理工具进行，而是会在策略中进行。

在 alfa 中，政策如下所示：

policy clientAccess{
    target 
           clause action.name == "view"
           object.Type == "client record"
    apply firstApplicable
    rule managersCanViewAll{
        target clause user.role == "manager"
        permit
    }
    rule employeeCanViewSameState{
        target clause user.role == "employee"
        permit
        condition user.state == client.state
    }
}

这条语句 condition user.state == client.state 是 ABAC 的秘诀。

当然，ABAC 还有其他好处，例如：

更容易成长和进化
更容易审核
更容易跨应用程序和 API 重用...

查看这些资源以获取更多信息：

数据库设计：RBAC 还是 ABAC？

Database design: RBAC or ABAC?

database-design

permissions

user-permissions

rbac

abac