数据库设计：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 重复使用...

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

• Attribute Based Access Control (ABAC)
• NIST's take on ABAC