访问控制权限模型分析梳理
1. 概述
权限模型(Access Control Models)是信息安全领域用于管理资源访问的核心机制。它们定义了谁(主体)可以对什么(客体)进行哪些操作(如读、写、执行)。常见的模型包括DAC、MAC、RBAC、ABAC等。这些模型可单独使用或组合(如RBAC与ABAC的混合)。选择模型取决于系统需求,如灵活性、安全性、复杂度和规模。
几种主要模型的分析。
| 模型名称 | 全称 | 核心原理 | 优点 | 缺点 | 典型使用场景 |
|---|---|---|---|---|---|
| DAC | Discretionary Access Control (自主访问控制) | 用户(资源所有者)自行决定谁能访问其资源,通常基于访问控制列表 (ACL)。例如,文件所有者设置权限。 | 灵活性高,用户自主管理;易于实现。 | 安全性低,易受恶意用户影响(如病毒传播);不适合高安全环境。 | 个人文件系统(如Windows NTFS、Unix文件权限);小型协作工具。 |
| MAC | Mandatory Access Control (强制访问控制) | 系统强制执行基于标签的安全策略(如机密级别:公开、秘密、绝密)。主体和客体都有标签,访问需匹配规则。 | 高安全性,防止信息泄露;适合多级安全。 | 灵活性差,用户无法 override;管理复杂。 | 军事/政府系统(如SELinux、AppArmor);高保密环境如银行核心系统。 |
| RBAC | Role-Based Access Control (基于角色的访问控制) | 用户分配角色,角色绑定权限。权限不直接赋给用户,而是通过角色间接管理。支持角色继承和会话。 | 易于管理大规模用户;符合最小权限原则;便于审计。 | 角色爆炸问题(太多角色);静态,不易处理动态上下文。 | 企业应用(如ERP系统、HR软件);云平台(如AWS IAM角色)。 |
| ABAC | Attribute-Based Access Control (基于属性的访问控制) | 基于主体、客体、环境和操作的属性(如用户部门、时间、位置)动态评估策略。通常用XACML语言定义规则。 | 高度灵活,支持动态决策;细粒度控制。 | 复杂,实现和性能开销大;策略管理困难。 | 云服务(如Azure AD);IoT系统;需要上下文感知的场景如远程访问。 |
| Rule-Based | Rule-Based Access Control (基于规则的访问控制) | 定义一组规则(如IP过滤、时间限制),访问请求匹配规则通过。常与防火墙结合。 | 简单直接;易于自动化。 | 规则冲突可能;不适合复杂权限。 | 网络防火墙(如iptables);API网关(如Kong)。 |
| Capability-Based | Capability-Based Access Control (基于能力的访问控制) | 用户持有“能力”(token-like),能力直接授予对特定资源的访问权,无需检查所有者。 | 高效,减少中央检查;支持分布式系统。 | 能力泄露风险;撤销困难。 | 操作系统(如Capsicum in FreeBSD);分布式文件系统(如Google's Spanner)。 |
2. 详细分析
- DAC的使用:在日常开发中,常用于文件共享系统。实现示例:在Python中使用os.chmod设置文件权限。但在多用户环境中,易导致权限滥用,因此常与审计日志结合。
- MAC的使用:适用于严格分级系统,如在Linux上启用SELinux。策略文件定义标签,系统内核强制执行。缺点是调试复杂,但可防止越权(如root用户也受限)。
- RBAC的使用:最流行模型。在数据库中存储用户-角色-权限表。示例:在Spring Security中配置@PreAuthorize("hasRole('ADMIN')")。扩展时可添加角色层次(如admin继承user)。
- ABAC的使用:现代趋势,支持AI驱动决策。使用Policy Decision Point (PDP)评估属性。示例:在OAuth2中结合JWT token的claims进行属性检查。适合微服务架构,但需优化规则引擎以避免延迟。
- 混合模型:实际项目中常混合使用,如RBAC+ABAC(称为RBAC扩展),角色提供粗粒度,属性提供细粒度。示例:AWS使用角色(RBAC)+条件键(ABAC)。
3. 实施建议
- 选择依据:小型系统用DAC/RBAC;高安全用MAC/ABAC;动态环境用ABAC。
- 最佳实践:遵循最小权限原则(Least Privilege);定期审计权限;使用工具如Open Policy Agent (OPA)统一管理多模型。
- 潜在风险:权限膨胀(权限过多导致漏洞);配置错误(如默认全开权限)。
- 工具推荐:身份管理 - Keycloak/OAuth;策略引擎 - OPA;监控 - ELK Stack。
4. 权限模型的表格设计
-
DAC(自主访问控制) → 基于 ACL(Access Control List)
核心思想:每个资源(对象)拥有自己的权限列表,由资源拥有者决定谁能访问。
| 表名 | 说明 | 主要字段 | 关系说明 |
|---|---|---|---|
| resources | 资源表(文件、文章、记录等) | id, owner_id, name, type... | - |
| acls | 访问控制列表(ACL) | id, resource_id, subject_id(用户/组ID), subject_type(user/group), permission(read/write/execute/delete), granted_by(授予者) | 多对一关联 resource |
CREATE TABLE resources ( id BIGINT PRIMARY KEY AUTO_INCREMENT, owner_id BIGINT NOT NULL, -- 资源拥有者(用户ID) name VARCHAR(255) NOT NULL, type ENUM('file','post','record') NOT NULL ); CREATE TABLE acls ( id BIGINT PRIMARY KEY AUTO_INCREMENT, resource_id BIGINT NOT NULL, subject_id BIGINT NOT NULL, -- 用户ID 或 组ID subject_type ENUM('user','group') NOT NULL, permission ENUM('read','write','execute','delete','all') NOT NULL, granted_by BIGINT, -- 谁授予的权限(可选,用于审计) created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (resource_id) REFERENCES resources(id) ON DELETE CASCADE );
-
RBAC(基于角色的访问控制) → 最常用模型
核心思想:用户 → 角色 → 权限
| 表名 | 说明 | 主要字段 | 关系说明 |
|---|---|---|---|
| users | 用户表 | id, username... | - |
| roles | 角色表 | id, name, description | - |
| permissions | 权限表(细粒度操作) | id, code(唯一标识,如 user:view), name, resource, action | - |
| user_roles | 用户-角色关联(多对多) | user_id, role_id | 多对多 |
| role_permissions | 角色-权限关联(多对多) | role_id, permission_id | 多对多 |
CREATE TABLE roles ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) UNIQUE NOT NULL, description VARCHAR(255) ); CREATE TABLE permissions ( id BIGINT PRIMARY KEY AUTO_INCREMENT, code VARCHAR(100) UNIQUE NOT NULL, -- 如 user:view, post:delete name VARCHAR(100) NOT NULL, resource VARCHAR(50), action VARCHAR(20) ); CREATE TABLE user_roles ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id), FOREIGN KEY (role_id) REFERENCES roles(id) ); CREATE TABLE role_permissions ( role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, PRIMARY KEY (role_id, permission_id), FOREIGN KEY (role_id) REFERENCES roles(id), FOREIGN KEY (permission_id) REFERENCES permissions(id) );
-
ABAC(基于属性的访问控制) → 最灵活但最复杂
核心思想:不依赖固定角色,而是根据主体属性 + 客体属性 + 环境属性 + 操作动态评估。
常见实现方式有两种:
-
-
- 策略表 + 属性表(纯数据库实现,较重)
- 外部策略引擎(如 OPA、Casbin)+ 数据库只存属性
-
| 表名 | 说明 | 主要字段 |
|---|---|---|
| attributes | 属性定义表 | id, name, type(user/object/environment), description |
| user_attributes | 用户属性值 | user_id, attribute_id, value |
| object_attributes | 资源属性值 | object_id, object_type, attribute_id, value |
| policies | 策略表(核心) | id, name, effect(allow/deny), description |
| policy_rules | 策略规则(一条策略可有多条规则) | policy_id, attribute_id, operator(=,>,in等), value |
| policy_actions | 策略允许的操作 | policy_id, action(read/write/delete) |
| policy_targets | 策略适用的资源范围 | policy_id, resource_type, resource_id(可选) |
CREATE TABLE attributes ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) UNIQUE NOT NULL, category ENUM('subject','resource','environment','action') ); CREATE TABLE user_attributes ( user_id BIGINT NOT NULL, attribute_id BIGINT NOT NULL, value VARCHAR(255) NOT NULL, PRIMARY KEY (user_id, attribute_id) ); CREATE TABLE object_attributes ( object_id BIGINT NOT NULL, object_type VARCHAR(50) NOT NULL, attribute_id BIGINT NOT NULL, value VARCHAR(255) NOT NULL, PRIMARY KEY (object_id, object_type, attribute_id) ); CREATE TABLE policies ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, effect ENUM('allow','deny') NOT NULL ); -- 规则示例:部门=销售 且 时间在工作日 且 操作=read CREATE TABLE policy_conditions ( id BIGINT PRIMARY KEY AUTO_INCREMENT, policy_id BIGINT NOT NULL, attribute_id BIGINT NOT NULL, operator ENUM('=','!=','>','<','in','contains'), value VARCHAR(255) );
-
MAC(强制访问控制) → 高安全场景
核心思想:系统强制基于安全标签(如机密级别:公开、内部、秘密、绝密)决定访问。
| 表名 | 说明 | 主要字段 |
|---|---|---|
| security_levels | 安全级别定义 | id, name(UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET), level_value(数字越大越密) |
| users | 用户表(扩展) | ... + clearance_level_id(许可级别) |
| objects | 资源表(扩展) | ... + classification_level_id(分类级别) + compartments(可选:项目A、项目B等) |
| compartments | 范畴/类别(需知原则) | id, name |
| object_compartments | 资源所属范畴(多对多) | object_id, compartment_id |
访问规则示例(Bell-LaPadula模型):
-
-
- 读:主体许可级别 ≥ 客体分类级别 且 主体范畴包含客体所有范畴
- 写:主体许可级别 ≤ 客体分类级别 且 主体范畴 ⊆ 客体范畴
-
CREATE TABLE security_levels ( id INT PRIMARY KEY, name VARCHAR(50) UNIQUE NOT NULL, level_value INT NOT NULL -- 数字越大越密 ); CREATE TABLE compartments ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) UNIQUE NOT NULL ); -- 用户许可级别(clearance) ALTER TABLE users ADD clearance_level_id INT REFERENCES security_levels(id); -- 资源分类级别 ALTER TABLE objects ADD classification_level_id INT REFERENCES security_levels(id); -- 资源所属范畴(多对多) CREATE TABLE object_compartments ( object_id BIGINT NOT NULL, compartment_id BIGINT NOT NULL, PRIMARY KEY (object_id, compartment_id) );
-
Capability-Based(基于能力的访问控制)
核心思想:用户持有“能力令牌”(Capability),令牌直接指向资源+操作,无需查中央权限表。
| 表名 | 说明 | 主要字段 |
|---|---|---|
| capabilities | 能力令牌表 | id, token(唯一字符串或UUID), user_id, resource_id, resource_type, permissions(JSON或多字段), expires_at, revoked |
| capability_scopes | 能力作用范围(可选) | capability_id, scope(特定记录ID等) |
CREATE TABLE capabilities ( id BIGINT PRIMARY KEY AUTO_INCREMENT, token VARCHAR(255) UNIQUE NOT NULL, -- JWT 或 UUID user_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, resource_type VARCHAR(50) NOT NULL, permissions JSON NOT NULL, -- ["read","write"] expires_at TIMESTAMP, revoked BOOLEAN DEFAULT FALSE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
总结:
| 模型 | 推荐场景 | 表数量 | 复杂度 | 灵活性 | 性能 |
|---|---|---|---|---|---|
| DAC | 文件系统、个人资源共享 | 2-3 | 低 | 高 | 高 |
| RBAC | 企业级SaaS、中后台系统 | 4-6 | 中 | 中高 | 高 |
| ABAC | 云服务、IoT、需要上下文的场景 | 6+ | 高 | 极高 | 中 |
| MAC | 军事、政府、高保密系统 | 4-6 | 中高 | 低 | 高 |
| CapBAC | 分布式系统、微服务、临时授权 | 2-4 | 中 | 高 | 高 |

浙公网安备 33010602011771号