5

我想实现一个数据库驱动的访问控制系统。我一直在阅读有关 ACL、角色、RBAC 等的信息，但似乎最常见的方案有一些主要缺点。例如，在实现细粒度的访问控制（例如，允许某个角色仅更新特定记录的特定列）时，RBAC 似乎很笨拙。

如果我这样构建访问控制列表会怎样：

| role  | table | action | columns  | conditions        |
| ----- | ----- | ------ | -------- | ----------------- |
| user  | user  | view   | name, id | self.id = user.id |
| user  | user  | update | password | self.id = user.id |
| admin | user  | update | *        |                   |
| admin | user  | create | *        |                   |
| admin | user  | delete | *        |                   |

这个想法是，当用户尝试访问数据库时，将根据该表检查用户的角色（因此，在模型级别实现）。 action可以是任何一个{create, view, update, delete, list}。范围将self是引用当前用户属性的保留关键字。例如，这将允许我们只允许用户更新他们自己的密码（而不是其他人的）。

这是健壮的吗？显然，我仍然需要一个单独的列表来控制对其他类型资源（如 URI 等）的访问。

4

1 回答 1

8

好问题。您正在达到 ACL 和 RBAC 的限制。还有另一种更灵活的方法，称为基于属性的访问控制 (ABAC)。

下图显示了访问控制如何随着时间的推移而发展以适应更复杂的场景（更多用户、更多数据、更多设备、更多上下文）。

历代访问控制

更具体地说，您正在为 RBAC 不支持关系这一事实而苦苦挣扎。然而，ABAC 确实如此。ABAC 基于属性。属性只是一个键值对，例如role == manager或location == Arizona。

ABAC 使用带有属性的策略来表达授权场景。例如，在 ABAC 中，您可以表达以下场景：

  • 如果医生位置 == 患者位置，则角色 == 医生的用户可以执行操作 == 查看类型 == 医疗记录的资源。

有一个称为 XACML（可扩展访问控制标记语言）的标准，您可以使用它来实现 ABAC。甚至还有专门为数据库和数据访问控制提供 XACML 的产品，例如Axiomatics 数据访问过滤器。

如果您想了解有关 ABAC 的更多信息，我建议您转向 2 个很棒的资源：

  1. NIST：基于属性的访问控制 (ABAC) 定义和注意事项指南 ( pdf )
  2. NIST 文档网络研讨会。
于 2015-03-06T10:26:54.397 回答