数据库设计：RBAC 还是 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 重用...

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

• 基于属性的访问控制 (ABAC)
• NIST 对 ABAC 的看法