这是实施访问控制的好策略吗？ [英] Is this a good strategy for implementing access control?

问题描述

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

I'd like to implement a database-driven access control system. I've been reading about ACL, roles, RBAC, etc., but it seems like the most common schemes have some major drawbacks. RBAC, for example, seems to be clunky when it comes to implementing fine-grained access control (for example, allowing a certain role to update only particular columns of a particular record).

如果我这样构造访问控制列表怎么办：

What if I structured my access control list like this:

| 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 | *        |                   |

这个想法是，当用户尝试访问时，将对照此表检查用户的角色数据库（因此，在模型级别实现）。 操作可以是 {创建，查看，更新，删除，列出} 中的任何一个。 self 范围将是引用当前用户属性的保留关键字。例如，这将使我们仅允许用户更新自己的密码（而不允许其他人的密码）。

The idea is that a user's role(s) would be checked against this table when they try to access the database (so, implemented at the model level). action can be any one of {create, view, update, delete, list}. The self scope would be a reserved keyword that references the current user's properties. This would allow us for example, to only allow users to update their own passwords (and not someone else's).

这是否可靠？显然，我仍然需要一个单独的列表来控制对URI等其他类型资源的访问。

Is this robust? Obviously I would still need a separate list to control access to other types of resources like URIs, etc.

推荐答案

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

Great question. You are hitting the limitations of ACLs and RBAC. There is another way which is more flexible called attribute-based access control (ABAC).

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

The following diagram shows how access control has evolved over time to cater to more complex scenarios (more users, more data, more devices, more context).

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

More specifically, you are struggling with the fact that RBAC doesn't support relationships. ABAC does however. ABAC is based on attributes. An attribute is just a key-value pair e.g. role == manager or location == Arizona.

ABAC使用具有属性的策略来表达授权方案。例如，在ABAC中，您可以表达以下情形：

ABAC uses policies with attributes to express authorization scenarios. For instance, in ABAC you can express scenarios such as:

• 具有 role == doctor 的用户可以如果医生位置==患者位置，请对类型==病历的资源进行操作==视图。

• A user with the role == doctor can do the action == view on a resource of type == medical record if the doctor location == the patient location.

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

There is a standard called XACML (eXtensible Access Control Markup Language) which you can use to implement ABAC. There are even products that offer XACML specifically for databases and data access control such as the Axiomatics Data Access Filter.

如果您想了解有关ABAC的更多信息，建议您转到2大量资源：

If you want to learn more on ABAC I recommend you turn to 2 great resources:

1. NIST：基于属性的访问控制（ABAC）定义和注意事项指南（ pdf ）


2. 网络研讨会上的NIST文档。

1. NIST: Guide to Attribute Based Access Control (ABAC) Definition and Considerations (pdf)
2. Webinar on the NIST document.

这篇关于这是实施访问控制的好策略吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！