实现相关数据资源的权限控制

Question

想象一下一家电力公司的数据模型，以及它所驱动的城市。该公司有几个部门，管理着城市中至少一个街区。该公司的数据库包括每个社区的住宅信息，安装在家中的计价器，记帐历史等。部门中的任何员工都可以登录并查看所有不同类型的数据，但他们只能查看部门管理的邻居的数据。示例模式：

部门

• ID
• 名字

邻里

• ID
• 名字

DepartmentsToNeighborHoods (LinkTable)

• DepartmentID
• NeighborhoodID

员工

• ID
• 名字
• DepartmentID (外键)

安家

• ID
• 地址
• NeighborhoodID (外键)

计量器

• ID
• HomeID (外键)

考虑到这个数据模型，我正在尝试实现一个restful接口，在这个接口中，员工可以提取数据，但只能在他们所在部门的资源上。例如，如果员工希望访问特定家庭的计费历史记录，则只有当该家庭位于由员工部门管理的社区时，才能访问该记录。

我能想到这样做的唯一方法是实现一个权限函数，该函数检查用户是否可以访问给定其用户id的特定资源。A可能的实现(伪码)：

getMeterDetails(meterID, employeeID) {
    permissionQuery = "
        select 1
        from Meters
            join Homes on Homes.ID = Meters.HomeID
            join Neighborhoods on NeighborHoods.ID = Homes.NeighborHoodID
            join DepartmentsToNeighborhoods as DTN on DTN.NeighborhoodID = Neighborhoods.ID
            join Employees on  Employees.DepartmentID = DTN.DepartmentID
        where Meters.ID = ?
            and Employees.ID = ?
    "

    result = db.runQuery(permissionsQuery, meterID, employeeID)

    if (result == 1) {
        return MeterModel.get(meterID);
    }
    else {
        return ERROR_VALUE;
    }
}

一般的问题是，我想限制访问特定资源的基础上，在另一个遥远的相关资源的成员资格。我的当前方法要求每次请求资源时都要进行额外的数据库查询。我还必须为我公开的每个资源编写自定义权限查询，因为每个资源都使用不同的关系集来确定是否允许当前员工访问这个特定资源。是否有更好的方法来实现这种权限控制？

Answer 1

这是对你问题的更详细的答复。您遇到的挑战是，您有具有多个参数/维度的授权需求。您想要定义的权限不仅取决于用户的身份、角色或组，而且还基于他们要访问的数据，更重要的是用户和数据之间的关系。

最流行的授权框架是所谓的RBAC或基于角色的访问控制。RBAC由国家标准和技术研究所NIST正式确定。在您的例子中，RBAC面临的挑战是，它是以身份为中心的，因为它只考虑用户的参数(角色、组)。您可以定义一个角色(例如manager )，该角色将被分配给权限(如viewMeterData )。但这对你来说还不够。

为了解决这个问题，NIST提出了一个基于属性的访问控制( ABAC )模型。在ABAC中，您现在可以使用更多的元数据/参数。例如，你可以考虑：

• 用户的身份，角色，职位，地点，部门，出生日期.
• 资源的类型(仪表)，位置，所有者，价值，部门.
• 上下文信息，例如一天中的时间
• 用户在资源上尝试的操作。

所有这些都被称为属性。属性是ABAC的基础，因此它的名称。您可以将这些属性组合成策略。政策有点像ABAC的秘方。策略可以授予和拒绝访问权限。例如：

• 如果员工和仪表位于同一区域，则员工可以查看该表。
• 在下午五时至早上八时期间不准使用电表读数。

策略可以用来表示高级场景。

• 职责分离
• 基于时间的约束(见上文)
• 基于关系的访问控制(见上文)
• 委托规则，例如委托Bob访问Alice的仪表。

有两种主要语法可用于编写策略：

• 缩写的授权语言(阿尔法 )
• eXtensible访问控制标记语言(XACML)

ABAC还提供了一个体系结构来定义如何评估和执行策略。

该体系结构包含以下组件：

• 策略执行点(PEP)：这是保护您想要保护的API /应用程序的组件。PEP拦截流程，分析它，并向PDP发送授权请求(见下文)。然后，它收到它执行的决定(许可/拒绝)。
• 决策点(PDP)接收授权请求(例如，Alice查看表#123?)并根据已配置的策略集对其进行评估。它最终达成了一个决定，并将其发送回PEP。在评估过程中，PDP可能需要额外的元数据，例如用户的职称。为此，它可以求助于政策信息点(PIP)。
• 策略信息点(PIP)是PDP与底层数据源(例如LDAP、数据库、REST服务)之间的接口，其中包含关于用户、资源或其他方面的元数据。您可以使用PIP检索PDP在运行时可能需要的信息，例如风险评分、仪表位置或其他信息。

Implementations

有几个开放源码和商业实现可用。例如，公理化政策服务器 (商业--这是我工作的地方)。你会找到全部在线列表的。