database-design - 数据库设计: RBAC or ABAC?

Question

我有一个 SaaS 服务，多个用户可以在其中相互协作。到目前为止，同一订阅帐户下的用户可以共享同一个数据库并查看/编辑/删除彼此的所有内容。

现在我想实现一个权限系统，这样用户可能只能执行特定的操作，例如查看、编辑、更新和删除内容(在我的 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 重用...

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

Attribute Based Access Control (ABAC)

NIST's take on ABAC