这是实施访问控制的好策略吗？

Is this a good strategy for implementing access control?

我想实现一个数据库驱动的访问控制系统。我一直在阅读有关 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 | *        |                   |

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

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

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

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

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

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

  • 具有 role == doctor 的用户可以对 type 的资源执行 action == view ==病历如果医生位置==患者位置。

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

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

  1. NIST：基于属性的访问控制 (ABAC) 定义和注意事项指南 (pdf)
  2. Webinar 在 NIST 文件上。