acl - 这是实现访问控制的好策略吗？

Question

我想实现一个数据库驱动的访问控制系统。我一直在阅读有关 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 scope 将是引用当前用户属性的保留关键字。例如，这将允许我们只允许用户更新他们自己的密码(而不是其他人的)。

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

Answer 1

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

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



更具体地说，您正在为 RBAC 不支持关系这一事实而苦苦挣扎。然而，ABAC 确实如此。 ABAC 基于属性。属性只是一个键值对，例如角色 == 经理或位置 == 亚利桑那州。

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

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

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

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

NIST:基于属性的访问控制 (ABAC) 定义和注意事项指南 ( pdf )

Webinar在 NIST 文档上。