数据库设计: RBAC还是ABAC？

Question

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

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

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

• 查看客户端卡
• 更新客户端卡
• 删除客户端卡
• 添加客户端卡

这些权限不绑定到单个卡实例，而不是用户可以执行的一般操作。在任何情况下，第一个(查看)似乎都是必需的，因为如果不能够看到任何卡片，就不可能使用系统。

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

RBAC有足够的能力编码这样的要求吗？还是我需要转到ABAC？

Answer 1

经验法则如下：

• 如果您的授权需求中有关系，那么就使用ABAC。

让我解释一下。使用RBAC，您可以执行定义角色、角色层次结构和权限等操作。你也可以做一些静态的职责分离。例如，用户可以被赋予角色经理和角色高级经理。这样，作为一个整体，他们有权查看客户端记录。到目前一切尚好。

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

• 您只能查看您所在地区的客户端。
• 您不能查看与您有个人(父-子)关系的客户端。

那么你需要的不仅仅是RBAC。正如您所指出的，您将需要abac。ABAC并不能完全取代RBAC。您仍然需要用户、用户元数据(例如角色)和从角色到权限的分配。然而，这些任务将发生在策略中，而不是通过角色管理工具进行。

在阿尔法中，这就是策略的样子：

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之间重用..。

有关更多信息，请查看这些资源：

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