工程经验 - 数据鉴权设计与实践

Liang

2024-04-15

技术技术方案鉴权工程经验

[TOC]

在我们的业务工程中，涉及到两部分鉴权的管控，这里简单做个总结分享 RBAC 和 ACL 模型在我们的工程中的实践

一、概念

1.1 鉴权

权限系统设计的核心目标是限制系统使用者的操作在一个合法的范围内，防止越权访问行为，包括水平越权和垂直越权两种。

水平越权：用户访问了不应该访问的数据。
垂直越权：用户通过非法手段提升了操作权限。

鉴权：在操作前，权限系统需要判断用户是否有权进行该操作，包括对请求数据归属权的校验。

1.2 RBAC（Role Based Access Control）

1.2.1 定义

基于角色的访问控制，通过给用户分配角色来控制权限。角色是 API 操作的聚合，用户通过角色获得操作权限

RBAC-0：基于角色的访问控制，通过给用户分配角色来控制权限。角色是 API 操作的聚合，用户通过角色获得操作权限
RBAC-1：基于角色、角色继承的访问控制，引入了继承制，子角色拥有父角色的权限
RBAC-2：基于角色、角色互斥的访问控制，引入了互斥制，角色互斥代表用户有且只能绑定一个角色
RBAC-3：基于角色、角色继承、角色互斥的访问控制，引入了继承和互斥，子角色拥有父角色的权限，用户有且只能绑定一个角色

RBAC 本质：角色（Role） 的本质其实就是一系列 API 操作 的聚合，通过用户与角色的直接或者间接绑定，使用户具备了某些操作的能力

1.2.2 场景

企业内部系统：一个企业内部的人力资源管理系统可以使用 RBAC 模型进行权限管理。管理员角色可以访问和管理所有员工的信息，而普通员工角色只能访问自己的信息和相关的部门信息。
电子商务平台：一个电子商务平台可以使用 RBAC 模型来管理不同类型的用户权限。管理员角色可以管理商品、订单和用户信息，而普通用户角色只能浏览和购买商品。

1.3 ACL（Access Control List）

1.3.1 定义

访问控制列表（ACL）是一种更细粒度的权限控制模型，用于指定哪些用户或系统可以访问哪些资源，以及他们可以进行哪些操作。ACL 直接关联资源和用户（或用户组），为每个资源维护一个列表，列表中指定了访问权限。

静态 ACL：预先定义的访问控制列表，管理员手动为资源指定访问权限。
动态 ACL：根据访问请求的上下文动态决定访问权限，例如，基于用户的角色、请求时间或地理位置。

ACL 的本质是直接控制主体（如用户或用户组）对对象（如文件、数据库记录）的访问权限，包括读取、写入、执行等操作权限。

1.3.2 场景

网络安全：网络设备，如路由器和防火墙，使用 ACL 来控制进出网络的数据包。可以根据源地址、目的地址、端口号等信息来允许或拒绝数据包的传输。
数据库管理：数据库系统使用 ACL 来控制用户对数据库、表、甚至是行和列的访问权限。这允许数据库管理员细粒度地管理谁可以查看或修改数据。

二、需求

在我们的业务系统中，一共有三种角色：普通用户、管理员、超级管理员三种角色。对用户的权限控制需求有两方面

用户接口权限：业务系统中的用户与角色一一对应，有一些业务接口只能管理员访问，有一些业务接口只能由普通用户访问
数据使用权限：业务系统中存在多份训练任务数据，一个用户只对其中部分数据有使用权限，且数据使用权限存在有效期区间的控制属性

三、设计 & 工程实践

3.1 用户接口权限 - 基于 RBAC-3

用户接口的维度可以有多维度，按照模块、操作、部门等，这里按照最简单的方案进行设计与说明，也即是 按照模块维度进行用户的权限区分

3.1.1 DB 层设计

3.1.2 逻辑层设计

1、预置角色 & 权限信息

-- 角色
INSERT INTO tb_role (id, name) VALUES (1, 'guest_user');

-- 给 id = 1 的用户预制角色
INSERT INTO rel_role_user (id, user_id, role_id) VALUES (1, 1, 1);

-- 给 id = 1 的角色预制模块权限
INSERT INTO rel_role_privilege (role_id, module_id, module_privi) VALUES (1, 1, 'true');
INSERT INTO rel_role_privilege (role_id, module_id, module_privi) VALUES (1, 2, 'true');
INSERT INTO rel_role_privilege (role_id, module_id, module_privi) VALUES (1, 3, 'true');
INSERT INTO rel_role_privilege (role_id, module_id, module_privi) VALUES (1, 4, 'true');

-- 模块
INSERT INTO tb_module (name) VALUES ('inference_service');
INSERT INTO tb_module (name) VALUES ('competition');
INSERT INTO tb_module (name) VALUES ('user');
INSERT INTO tb_module (name) VALUES ('resource');

2、后端接口标注权限以及拦截器 Hook

接口处标记访问角色需要的模块访问权限

@Privilege(values = {"inference_service", "competition", "user"})
@Post("/api/inference")
String inference() {
	// ...
}

拦截器统一 Hook，在其中解析用户信息，校验权限

class PrivilegeInterceptor {
    boolean preHandler() {
        // 解析 cookie 查询用户的权限列表
        // 判断用户的权限列表包含接口要求的所有权限，则返回 true，否则返回 HTTP 403 Forbidden
    }
}

3.2 数据使用权限 - 基于 ACL

3.2.1 数据库层设计

3.2.2 逻辑层设计

管理员给普通用户建立多条访问策略，访问策略可关联多个用户 & 数据，具备时间有效期区间
用户在使用数据时，携带用户信息 & 数据信息，进行数据权限校验
数据权限校验逻辑：查询用户关联有的数据以及数据关联的访问策略列表，列表不为空且列表内存在一个有效的策略。如果有效返回 true，无效返回 false

四、扩展阅读

常见模型

ABAC（Attribute Based Access Control）

定义

基于属性的权限访问控制，根据用户、数据的属性和环境因素动态计算权限

场景

云计算环境：在一个云计算环境中，ABAC 模型可以根据用户的属性和环境条件来控制对云资源的访问。例如，只有具有特定安全级别的用户、来自特定 IP 地址范围的用户或具有特定访问权限的用户才能访问敏感数据。
医疗系统：在医疗系统中，ABAC 模型可以根据医生的专业资质、患者的病历信息和医疗设备的要求来控制对医疗数据和设备的访问。只有具有相应资格、与患者相关的医生才能访问特定患者的敏感数据。

DAC（Discretionary Access Control）

定义

DAC（Discretionary Access Control）：DAC 是一种自主访问控制模型，它允许资源的所有者决定其他用户对其资源的访问权限。DAC 提供了灵活性和可扩展性，适用于小型组织或个人使用。

场景

个人电脑系统：在个人电脑系统中，DAC 模型可以由计算机的所有者决定对文件和文件夹的访问权限。所有者可以设置文件的读、写和执行权限，并决定其他用户是否可以访问这些文件。
文件共享系统：在一个文件共享系统中，DAC 模型可以由文件的所有者决定其他用户对文件的访问权限。所有者可以选择与其他用户共享文件，并指定他们可以访问文件的级别，如只读、读写或完全控制。

MAC（Mandatory Access Control）

定义

MAC 是一种强制性访问控制模型，它根据预定义的安全策略对主体和对象进行分类，并在系统级别强制执行这些分类。MAC 通常用于高安全性环境，如军事和政府系统。

场景

军事系统：在军事系统中，MAC 模型被广泛用于保护敏感信息和资源。例如，军事指挥和控制系统使用 MAC 模型来对不同级别的军事人员和指挥官分配不同的访问权限。只有具有足够安全级别的人员才能访问高度机密的军事计划和作战信息。
政府机构：政府机构通常处理大量的敏感信息和数据，因此 MAC 模型在这些机构中得到广泛应用。例如，情报机构使用 MAC 模型来对不同级别的特工和分析人员分配访问权限，以确保只有授权人员可以访问特定的情报资料。
核能设施：核能设施是高度敏感和危险的场所，需要严格的访问控制。MAC 模型可以用于对核能设施的工作人员和访客进行分类，并根据其安全许可级别对其访问权限进行强制控制。只有经过授权的人员才能进入核能设施的特定区域和操作核设备。