权限设计范式详解
目录
- 概述
- RBAC 基于角色的访问控制
- 2.1 RBAC 概念与作用
- 2.2 RBAC 权限表设计
- 其他权限设计范式
- 3.1 ACL 访问控制列表
- 3.2 DAC 自主访问控制
- 3.3 MAC 强制访问控制
- 3.4 ABAC 基于属性的访问控制
- 3.5 ReBAC 基于关系的访问控制
- 3.6 TBAC/T-RBAC 基于任务/任务角色的访问控制
- 3.7 OBAC 基于对象的访问控制
- 3.8 UCON 使用控制
- 3.9 NGAC 下一代访问控制
- 3.10 CBAC 基于内容的访问控制
- 3.11 IBAC 基于意图的访问控制
- 范式对比与选型建议
- 工程实践要点
- 总结
概述
权限设计是系统安全的核心环节，不仅用于后端服务，也覆盖操作系统、数据库、网络、云资源、企业应用等各个层面。常见的权限设计范式包括：ACL、DAC、MAC、RBAC、ABAC、ReBAC、TBAC/T-RBAC、OBAC、UCON、NGAC 等。
其中 RBAC（基于角色的访问控制） 是最常用的工程落地基线，在企业应用中广泛采用，但并非唯一选择。很多系统会按场景组合多种范式，以实现更灵活、更安全的权限控制。
本文档将重点介绍 RBAC 设计方式，并全面对比其他权限设计范式，帮助开发者和系统架构师选择合适的权限控制方案。
RBAC 基于角色的访问控制
1.1 RBAC 概念与作用
RBAC（Role-Based Access Control，基于角色的访问控制） 是一种按角色来分配权限的授权模型：先把权限聚合成角色，再把角色授予用户，从而让用户获得该角色所包含的权限。
核心思想
RBAC 支持最小权限原则、职责分离等安全原则，便于在大型组织中高效、可审计地管理系统与数据访问。在企业实践中，RBAC 常与**IAM（身份与访问管理）**结合，用于统一认证与授权。
RBAC 核心架构图
┌─────────────────────────────────────────────────────────────┐
│ RBAC 核心架构模型 │
└─────────────────────────────────────────────────────────────┘
┌─────────┐ ┌─────────┐ ┌─────────────┐
│ User │────────▶│ Role │────────▶│ Permission │
│ (用户) │ │ (角色) │ │ (权限) │
└─────────┘ └─────────┘ └─────────────┘
│ │ │
│ │ │
│ 多对多关系 │ 多对多关系 │
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────────┐
│User_Role│ │Role_Perm│ │ Resource │
│ 关联表 │ │ 关联表 │ │ (资源) │
└─────────┘ └─────────┘ └─────────────┘
访问决策流程：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Who │───▶│ Role │───▶│ What │───▶│ How │
│ (用户) │ │ (角色) │ │ (资源) │ │ (操作) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
核心组成与规则
核心要素：
- 用户（User）—角色（Role）—权限（Permission/Privilege）
- 典型为多对多关系（用户可拥有多角色，角色可包含多权限）
会话与会话激活：
- 用户可在一次会话中激活部分角色，按会话动态计算可用权限
三元组判断：
- 访问决策常抽象为 Who（用户）—What（资源）—How（操作）
NIST 三项基本规则：
- 角色分配：用户必须被赋予至少一个有效角色
- 角色授权：用户只能承担已被授权的角色
- 权限授权：权限仅授予通过角色获得授权的用户
常见模型层级
| 模型层级 | 说明 | 特点 |
|---|---|---|
| Core RBAC（核心RBAC） | 最小实现，提供用户-角色-权限的基础映射 | 基础模型，易于实现 |
| Hierarchical RBAC（分级RBAC） | 引入角色继承/层级，上级角色包含下级角色的权限 | 贴合组织汇报链 |
| Constrained RBAC（约束RBAC） | 加入互斥角色、基数约束、先决条件等，强化职责分离（SOD） | 增强安全性 |
| Symmetric RBAC（对称RBAC） | 提供权限↔角色↔用户的全量可见与可回滚 | 便于治理与合规审计 |
RBAC 模型层级演进图
┌─────────────────────────────────────────────────────────────┐
│ RBAC 模型层级演进 │
└─────────────────────────────────────────────────────────────┘
RBAC0 (Core RBAC) - 核心模型
┌─────────┐ ┌─────────┐ ┌─────────────┐
│ User │───▶│ Role │───▶│ Permission │
└─────────┘ └─────────┘ └─────────────┘
基础的用户-角色-权限映射
RBAC1 (Hierarchical RBAC) - 分级模型
┌─────────┐ ┌─────────┐ ┌─────────────┐
│ User │───▶│ Role │───▶│ Permission │
└─────────┘ └─────────┘ └─────────────┘
│
│ 角色继承
▼
┌─────────────────┐
│ Role Hierarchy │
│ (角色层级树) │
└─────────────────┘
例如：管理员 > 经理 > 员工
RBAC2 (Constrained RBAC) - 约束模型
┌─────────┐ ┌─────────┐ ┌─────────────┐
│ User │───▶│ Role │───▶│ Permission │
└─────────┘ └─────────┘ └─────────────┘
│
│ 约束规则
▼
┌─────────────────┐
│ Constraints │
│ - 互斥角色 │
│ - 基数约束 │
│ - 先决条件 │
└─────────────────┘
RBAC3 = RBAC0 + RBAC1 + RBAC2 (完整模型)
包含所有特性：基础映射 + 角色继承 + 约束规则
典型应用与优势
典型场景：
- 企业应用按岗位（如财务、HR、运维）配置角色，快速完成入职/转岗/离职的授权变更
- 医院为"护士"角色授予查看药品与录入病历权限，限制开立处方与检验等越权操作
- 网络设备/安全设备按角色限制命令、菜单与资源（如仅允许特定 VLAN/接口操作）
主要优势：
- 降低授权复杂度与运维成本
- 提升合规性与审计可追溯性
- 强化最小权限，抑制横向移动与内部威胁
1.2 RBAC 权限表设计
核心表结构
采用经典的 RBAC0 五表模型：users、roles、permissions、user_roles、role_permissions。
关键设计要点：
- 为便于直接鉴权，建议在
permissions表中增加permission_code（权限标识，唯一），如view_dashboard、edit_content、delete_content - 所有关联表使用联合主键
(user_id, role_id)、(role_id, permission_id)，并添加外键约束与级联删除 - 字段如
created_at/updated_at便于审计与排查 - 可选扩展：如需对个别用户进行"特批"授权，可新增
user_permissions表（同样使用联合主键与级联删除）
RBAC 数据模型关系图
┌─────────────────────────────────────────────────────────────┐
│ RBAC 数据模型关系图 │
└─────────────────────────────────────────────────────────────┘
┌──────────────┐
│ users │
│──────────────│
│ user_id (PK) │
│ username │
│ email │
│ status │
└──────┬───────┘
│
│ 1:N
│
┌──────▼──────────┐
│ user_roles │
│─────────────────│
│ user_id (FK) │◀──┐
│ role_id (FK) │ │
│ (PK: u_id+r_id) │ │
└──────┬──────────┘ │
│ │
│ N:1 │ N:1
│ │
┌──────▼──────────┐ │
│ roles │ │
│─────────────────│ │
│ role_id (PK) │ │
│ role_name │ │
│ description │ │
└──────┬──────────┘ │
│ │
│ 1:N │
│ │
┌──────▼──────────┐ │
│ role_permissions│ │
│─────────────────│ │
│ role_id (FK) │──┘
│ permission_id │──┐
│ (PK: r_id+p_id) │ │
└──────┬──────────┘ │
│ │
│ N:1 │
│ │
┌──────▼──────────┐ │
│ permissions │ │
│─────────────────│ │
│ permission_id │◀─┘
│ permission_code │◀──┐ (唯一标识)
│ permission_name │ │
│ resource_type │ │
└─────────────────┘ │
│
│ 可选：用户直授权限
│
┌──────▼──────────┐
│ user_permissions │
│─────────────────│
│ user_id (FK) │
│ permission_id │
│ (PK: u_id+p_id) │
└─────────────────┘
完整建表 SQL
-- 用户表
CREATE TABLE users (
user_id BIGINT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
password VARCHAR(255) NOT NULL,
email VARCHAR(100) UNIQUE,
status TINYINT NOT NULL DEFAULT 1,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 角色表
CREATE TABLE roles (
role_id BIGINT AUTO_INCREMENT PRIMARY KEY,
role_name VARCHAR(50) NOT NULL UNIQUE,
description VARCHAR(255),
is_deletable BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 权限表（含唯一权限标识，便于鉴权）
CREATE TABLE permissions (
permission_id BIGINT AUTO_INCREMENT PRIMARY KEY,
permission_code VARCHAR(100) NOT NULL UNIQUE, -- 如 view_dashboard
permission_name VARCHAR(100) NOT NULL,
resource_type VARCHAR(20) NOT NULL DEFAULT 'OPERATION', -- 如 MENU、OPERATION、FILE、ELEMENT
description VARCHAR(255),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 用户-角色关联
CREATE TABLE user_roles (
user_id BIGINT NOT NULL,
role_id BIGINT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (user_id, role_id),
FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE,
FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE
);
-- 角色-权限关联
CREATE TABLE role_permissions (
role_id BIGINT NOT NULL,
permission_id BIGINT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (role_id, permission_id),
FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE,
FOREIGN KEY (permission_id) REFERENCES permissions(permission_id) ON DELETE CASCADE
);
-- 可选：用户直授权限（特批/覆盖）
CREATE TABLE user_permissions (
user_id BIGINT NOT NULL,
permission_id BIGINT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (user_id, permission_id),
FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE,
FOREIGN KEY (permission_id) REFERENCES permissions(permission_id) ON DELETE CASCADE
);
菜单与按钮的权限控制
设计建议：
- 菜单/按钮等"资源"建议单独建模为
menus表，支持多级结构（如parent_id），并通过role_menus控制"可见/可访问"关系 - 按钮级权限可直接用
permissions.permission_code标识（如user:add、user:delete），在接口层或前端指令（如 Shiro 的hasPermission）进行校验
两种常见做法：
- 菜单与权限分离：
menus只管导航与展示，细粒度操作由permissions控制 - 合并式：在
menus中增加type（MENU/BUTTON）与permission字段，既做导航也做权限标识（适合简单系统）
菜单表设计 SQL：
-- 菜单/资源表（支持树形）
CREATE TABLE menus (
menu_id BIGINT AUTO_INCREMENT PRIMARY KEY,
parent_id BIGINT NOT NULL DEFAULT 0,
menu_name VARCHAR(50) NOT NULL,
path VARCHAR(255),
component VARCHAR(255),
icon VARCHAR(50),
sort_order INT DEFAULT 0,
type CHAR(1) NOT NULL DEFAULT 'M', -- M:菜单, B:按钮
permission_code VARCHAR(100), -- 对应 permissions.permission_code
status TINYINT NOT NULL DEFAULT 1,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 角色-菜单关联（可见性/可达性）
CREATE TABLE role_menus (
role_id BIGINT NOT NULL,
menu_id BIGINT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (role_id, menu_id),
FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE,
FOREIGN KEY (menu_id) REFERENCES menus(menu_id) ON DELETE CASCADE
);
常见查询与鉴权 SQL
查询用户的所有权限（角色继承 + 直接授权，去重）：
SELECT DISTINCT p.permission_code
FROM users u
JOIN user_roles ur ON ur.user_id = u.user_id
JOIN role_permissions rp ON rp.role_id = ur.role_id
JOIN permissions p ON p.permission_id = rp.permission_id
WHERE u.user_id = :uid
UNION
SELECT DISTINCT p.permission_code
FROM user_permissions up
JOIN permissions p ON p.permission_id = up.permission_id
WHERE up.user_id = :uid;
查询用户可见的菜单（按角色授权）：
SELECT DISTINCT m.*
FROM users u
JOIN user_roles ur ON ur.user_id = u.user_id
JOIN role_menus rm ON rm.role_id = ur.role_id
JOIN menus m ON m.menu_id = rm.menu_id
WHERE u.user_id = :uid
AND m.status = 1
ORDER BY m.parent_id, m.sort_order;
判断用户是否拥有某权限（permission_code）：
SELECT 1
FROM permissions p
WHERE p.permission_code = :code
AND (
EXISTS (
SELECT 1
FROM user_roles ur
JOIN role_permissions rp ON rp.role_id = ur.role_id
WHERE ur.user_id = :uid
AND rp.permission_id = p.permission_id
)
OR EXISTS (
SELECT 1
FROM user_permissions up
WHERE up.user_id = :uid
AND up.permission_id = p.permission_id
)
)
LIMIT 1;
索引与约束建议
外键与级联：
- 所有关联表设置外键并选择 ON DELETE CASCADE，保证数据一致性与清理便利
唯一约束：
permissions.permission_code唯一- 关联表使用联合唯一键
(user_id, role_id)、(role_id, permission_id)、(role_id, menu_id)
常用索引：
- 在查询条件高频列（如
users.username、roles.role_name、permissions.permission_code、menus.parent_id）上建立索引，提高鉴权与菜单树查询性能
扩展与演进
角色继承（RBAC1）：
- 引入
role_hierarchy(ancestor_role_id, descendant_role_id)表，实现层级/树形角色，简化高层角色授权
角色继承示例：
┌─────────────┐
│ 超级管理员 │ (拥有所有权限)
└──────┬──────┘
│ 继承
▼
┌─────────────┐
│ 管理员 │ (拥有大部分权限)
└──────┬──────┘
│ 继承
▼
┌─────────────┐
│ 普通用户 │ (拥有基础权限)
└─────────────┘
约束与合规（RBAC2）：
- 增加
role_mutex(role_a, role_b)实现互斥 role_assignment_limit(role_id, max_users)控制基数role_precondition(role_id, pre_role_id)实现先决条件
约束示例：
┌─────────────────────────────────────┐
│ 互斥角色：会计 ↔ 出纳 │
│ (同一用户不能同时拥有这两个角色) │
├─────────────────────────────────────┤
│ 基数约束：管理员角色最多5人 │
├─────────────────────────────────────┤
│ 先决条件：必须先有"员工"角色 │
│ 才能获得"经理"角色 │
└─────────────────────────────────────┘
组织与职位：
- 引入
organizations、positions、user_org、position_role等，支持按组织自动授权与数据范围隔离
组织权限模型：
┌──────────────┐
│ Organization│
│ (组织/部门) │
└──────┬───────┘
│
│ 1:N
▼
┌──────────────┐
│ Position │
│ (职位) │
└──────┬───────┘
│
│ N:M
▼
┌──────────────┐
│ Role │
│ (角色) │
└──────────────┘
数据权限：
- 在业务表增加
org_id/creator_id/dept_id等字段，结合行级规则或视图实现"本部门/本人"数据可见性
数据权限示例：
┌─────────────────────────────────────┐
│ 业务表：orders │
│ - order_id │
│ - org_id (组织ID) │
│ - creator_id (创建人ID) │
│ - dept_id (部门ID) │
└─────────────────────────────────────┘
权限规则：
- 本部门：WHERE dept_id = :user_dept_id
- 本人：WHERE creator_id = :user_id
- 本组织：WHERE org_id = :user_org_id
统一权限标识：
- 通过
permissions.resource_type区分MENU/OPERATION/FILE/ELEMENT，便于扩展与统一鉴权口径
工程要点
重要实践：
- 以权限码而非"角色名"做鉴权，避免
if hasRole('hr') then …这类硬编码 - 使用
permission_code统一鉴权口径，便于策略与代码解耦
优点：
- 治理与审计友好、便于最小权限与职责分离落地
- 云厂商（如 Azure RBAC）广泛采用
- 性能好，查询效率高
局限：
- 复杂组织易出现角色爆炸
- 对"按上下文动态授权"支持有限
其他权限设计范式
2.1 ACL 访问控制列表
核心思想： 为每个客体维护一份"主体—操作"的允许/拒绝列表；访问时按列表逐项匹配，通常以"自上而下顺序匹配、末尾隐含 deny any"为规则。
ACL 工作原理图
┌─────────────────────────────────────────────────────────────┐
│ ACL 访问控制模型 │
└─────────────────────────────────────────────────────────────┘
客体（资源）：/var/log/app.log
┌─────────────────────────────────────────────────────────────┐
│ ACL 列表（按顺序匹配） │
├──────┬──────────┬──────────┬──────────┬─────────────────────┤
│ 序号 │ 主体 │ 操作 │ 权限 │ 说明 │
├──────┼──────────┼──────────┼──────────┼─────────────────────┤
│ 1 │ root │ read │ allow │ 管理员可读 │
│ 2 │ admin │ read │ allow │ 管理员组可读 │
│ 3 │ app │ write │ allow │ 应用可写 │
│ 4 │ * │ * │ deny │ 默认拒绝（隐含） │
└──────┴──────────┴──────────┴──────────┴─────────────────────┘
匹配流程：
请求：用户 "app" 要 "write" 文件
↓
按顺序检查 ACL 列表
↓
匹配到第3条：app + write = allow
↓
允许访问 ✓
典型实现
操作系统文件/对象：
- Linux rwx/ACL：传统权限 + 扩展 ACL
- Windows NTFS ACL：基于用户/组的访问控制列表
Linux ACL 示例：
# 文件：/var/log/app.log
# 所有者：app:app (rw-)
# ACL 条目：
user:admin:r--
group:developers:rw-
other::r--
mask::rw-
网络设备 ACL：
- 路由器接口的标准/扩展 ACL
- 按源/目的 IP、端口、协议等匹配
- 用于过滤与策略路由
网络 ACL 示例（Cisco 风格）：
┌─────────────────────────────────────────────────────────────┐
│ 标准 ACL (按源IP) │
├──────┬──────────────┬──────────┬─────────────────────────────┤
│ 序号 │ 动作 │ 源IP │ 说明 │
├──────┼──────────────┼──────────┼─────────────────────────────┤
│ 10 │ permit │ 192.168.1.0/24 │ 允许内网访问 │
│ 20 │ deny │ 10.0.0.0/8 │ 拒绝特定网段 │
│ 30 │ permit │ any │ 允许其他（隐含） │
└──────┴──────────────┴──────────┴─────────────────────────────┘
扩展 ACL (按源/目的IP+端口+协议)：
permit tcp 192.168.1.0/24 any eq 80
deny tcp 10.0.0.0/8 any eq 443
permit ip any any
优点与局限
优点：
- 实现直观、粒度可控、对单客体授权清晰
- 适合细粒度的访问控制
- 规则明确，易于理解
局限：
- 主体/客体规模扩大时，列表膨胀、维护成本高
- 跨客体统一策略复用困难
- 需要为每个资源单独配置
要点：
- 顺序敏感：规则按顺序匹配，第一条匹配即停止
- 默认拒绝：末尾隐含 deny any
- 规则命中即止：找到匹配规则后不再继续
- 网络设备侧常区分 in/out 方向生效
2.2 DAC 自主访问控制
核心思想： 客体"属主"可按意愿将访问权授予其他主体，并可随时回收；典型于 UNIX/Linux 文件权限（u/g/o + rwx） 与 Windows 文件/共享权限。
DAC 工作原理图
┌─────────────────────────────────────────────────────────────┐
│ DAC 自主访问控制模型 │
└─────────────────────────────────────────────────────────────┘
文件：/home/user/document.txt
属主：user (拥有完全控制权)
┌─────────────────────────────────────────────────────────────┐
│ 属主可以自主授权给其他用户 │
├──────┬──────────┬──────────┬───────────────────────────────┤
│ 类型 │ 主体 │ 权限 │ 说明 │
├──────┼──────────┼──────────┼───────────────────────────────┤
│ owner│ user │ rwx │ 属主：读、写、执行 │
│ group│ dev │ r-x │ 组：读、执行（属主授权） │
│ other│ * │ r-- │ 其他：只读（属主授权） │
└──────┴──────────┴──────────┴───────────────────────────────┘
权限传播链：
属主 user
│
├─▶ 授权给组 dev (r-x)
│ │
│ └─▶ 组内成员自动获得权限
│
└─▶ 授权给其他用户 (r--)
│
└─▶ 所有其他用户获得权限
UNIX/Linux 文件权限详解
传统 UNIX 权限模型（9位权限）：
┌─────────────────────────────────────────────────────────────┐
│ rwx rwx rwx │
│ ─── ─── ─── │
│ │ │ │ │
│ │ │ └─ other (其他用户) │
│ │ └───── group (组) │
│ └───────── owner (属主) │
└─────────────────────────────────────────────────────────────┘
权限位说明：
r (read) = 4 = 可读
w (write) = 2 = 可写
x (execute)= 1 = 可执行
示例：
-rwxr-xr-- 1 user dev 1024 document.txt
│││││││││
││││││││└─ other: r-- (只读)
│││││││└── other: r-- (只读)
││││││└─── other: r-- (只读)
│││││└──── group: r-x (读+执行)
││││└───── group: r-x (读+执行)
│││└────── group: r-x (读+执行)
││└─────── owner: rwx (完全控制)
│└──────── owner: rwx (完全控制)
└───────── owner: rwx (完全控制)
数值表示：755 = rwxr-xr-x
Windows 文件权限
Windows NTFS 权限模型：
┌─────────────────────────────────────────────────────────────┐
│ 文件：C:\Users\user\document.txt │
│ 属主：user (完全控制) │
├─────────────────────────────────────────────────────────────┤
│ 权限条目： │
│ ┌──────────────┬──────────────┬─────────────────────────┐ │
│ │ 主体 │ 权限类型 │ 权限 │ │
│ ├──────────────┼──────────────┼─────────────────────────┤ │
│ │ user │ 允许 │ 完全控制 │ │
│ │ dev-group │ 允许 │ 读取和执行 │ │
│ │ Everyone │ 允许 │ 读取 │ │
│ └──────────────┴──────────────┴─────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
权限继承：
父文件夹权限
│
├─▶ 继承到子文件夹
│
└─▶ 继承到文件
优点与局限
优点：
- 灵活放权：属主可以自主决定授权给谁
- 便于个体/小组协作：快速共享资源
- 实现简单：基于文件系统原生支持
局限：
- 权限扩散风险高：恶意软件或误操作可能导致权限放大
- 不适合强合规场景：缺乏集中管控
- 难以审计：权限分散在各资源上
要点：
- 所有权与权限分离：属主可以授权但保持所有权
- 常以 ACL 作为实现载体
- 对系统级强制策略（如 MLS）不构成覆盖
2.3 MAC 强制访问控制
核心思想： 主体与客体都被赋予安全标签（如密级/类别），由系统内核强制按策略判定访问；用户不可覆盖。
MAC 安全标签模型
┌─────────────────────────────────────────────────────────────┐
│ MAC 强制访问控制模型 │
└─────────────────────────────────────────────────────────────┘
安全标签结构：
┌─────────────────────────────────────────────────────────────┐
│ 主体（Subject）标签： │
│ ┌──────────┬──────────┬─────────────────────────────────┐ │
│ │ 密级 │ 类别 │ 说明 │ │
│ ├──────────┼──────────┼─────────────────────────────────┤ │
│ │ 绝密 │ 军事 │ 最高安全级别 │ │
│ │ 机密 │ 财务 │ 高安全级别 │ │
│ │ 秘密 │ 人事 │ 中等安全级别 │ │
│ │ 公开 │ 一般 │ 最低安全级别 │ │
│ └──────────┴──────────┴─────────────────────────────────┘ │
│ │
│ 客体（Object）标签： │
│ ┌──────────┬──────────┬─────────────────────────────────┐ │
│ │ 密级 │ 类别 │ 说明 │ │
│ ├──────────┼──────────┼─────────────────────────────────┤ │
│ │ 绝密 │ 军事 │ 最高安全级别 │ │
│ │ 机密 │ 财务 │ 高安全级别 │ │
│ │ 秘密 │ 人事 │ 中等安全级别 │ │
│ │ 公开 │ 一般 │ 最低安全级别 │ │
│ └──────────┴──────────┴─────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Bell-LaPadula 模型（保密性）
┌─────────────────────────────────────────────────────────────┐
│ Bell-LaPadula 模型 - 防止信息泄露 │
└─────────────────────────────────────────────────────────────┘
安全级别层次：
绝密 (Top Secret) > 机密 (Secret) > 秘密 (Confidential) > 公开 (Unclassified)
两条核心规则：
1. 简单安全属性（Simple Security Property）- "不上读"
┌─────────────────────────────────────────────────────────┐
│ 主体只能读取安全级别 ≤ 自己安全级别的客体 │
│ │
│ 示例： │
│ 主体：机密级别 │
│ ✓ 可以读：公开、秘密、机密 │
│ ✗ 不能读：绝密 │
└─────────────────────────────────────────────────────────┘
2. *-属性（Star Property）- "不下写"
┌─────────────────────────────────────────────────────────┐
│ 主体只能写入安全级别 ≥ 自己安全级别的客体 │
│ │
│ 示例： │
│ 主体：机密级别 │
│ ✓ 可以写：机密、绝密 │
│ ✗ 不能写：公开、秘密 │
└─────────────────────────────────────────────────────────┘
访问矩阵示例：
┌──────────┬──────┬──────┬──────┬──────┐
│ │ 公开 │ 秘密 │ 机密 │ 绝密 │
├──────────┼──────┼──────┼──────┼──────┤
│ 公开主体 │ 读写 │ 拒绝 │ 拒绝 │ 拒绝 │
│ 秘密主体 │ 读写 │ 读写 │ 拒绝 │ 拒绝 │
│ 机密主体 │ 拒绝 │ 拒绝 │ 读写 │ 拒绝 │
│ 绝密主体 │ 拒绝 │ 拒绝 │ 读写 │ 读写 │
└──────────┴──────┴──────┴──────┴──────┘
Biba 模型（完整性）
┌─────────────────────────────────────────────────────────────┐
│ Biba 模型 - 防止信息污染 │
└─────────────────────────────────────────────────────────────┘
完整性级别层次：
高完整性 > 中完整性 > 低完整性
两条核心规则：
1. 简单完整性属性（Simple Integrity Property）- "不下读"
┌─────────────────────────────────────────────────────────┐
│ 主体只能读取完整性级别 ≥ 自己完整性级别的客体 │
│ │
│ 示例： │
│ 主体：中完整性 │
│ ✓ 可以读：中完整性、高完整性 │
│ ✗ 不能读：低完整性 │
└─────────────────────────────────────────────────────────┘
2. *-完整性属性（Star Integrity Property）- "不上写"
┌─────────────────────────────────────────────────────────┐
│ 主体只能写入完整性级别 ≤ 自己完整性级别的客体 │
│ │
│ 示例： │
│ 主体：中完整性 │
│ ✓ 可以写：低完整性、中完整性 │
│ ✗ 不能写：高完整性 │
└─────────────────────────────────────────────────────────┘
实现与场景
操作系统实现：
SELinux (Security-Enhanced Linux)：
┌─────────────────────────────────────────────────────────────┐
│ 主体标签：user_u:role_r:type_t:s0:c0.c1023 │
│ │ │ │ │ │ │
│ │ │ │ │ └─ 类别范围 │
│ │ │ │ └──── 安全级别 │
│ │ │ └─────────── 类型 │
│ │ └────────────────── 角色 │
│ └────────────────────────── 用户 │
│ │
│ 策略规则示例： │
│ allow httpd_t httpd_log_t:file { create write append }; │
│ (允许 httpd_t 类型对 httpd_log_t 类型的文件执行创建、写、追加)│
└─────────────────────────────────────────────────────────────┘
AppArmor：
┌─────────────────────────────────────────────────────────────┐
│ 配置文件：/etc/apparmor.d/usr.bin.firefox │
│ /usr/bin/firefox { │
│ /etc/firefox/** r, │
│ /usr/lib/firefox/** r, │
│ /home/*/.mozilla/** rw, │
│ deny /etc/passwd r, │
│ } │
└─────────────────────────────────────────────────────────────┘
数据库实现：
KingbaseES MAC 行级安全标签：
┌─────────────────────────────────────────────────────────────┐
│ 表：employees │
│ ┌────┬──────┬──────┬──────────┬──────────┐ │
│ │ id │ name │ dept │ sec_level│ category │ │
│ ├────┼──────┼──────┼──────────┼──────────┤ │
│ │ 1 │ 张三 │ 财务 │ 机密 │ 财务 │ │
│ │ 2 │ 李四 │ 人事 │ 秘密 │ 人事 │ │
│ └────┴──────┴──────┴──────────┴──────────┘ │
│ │
│ 用户标签：机密-财务 │
│ ✓ 可以访问：id=1 的记录 │
│ ✗ 不能访问：id=2 的记录 │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 高安全：内核强制，用户无法绕过
- 强合规：满足军事、政府等高安全要求
- 集中策略一致性强：统一的安全策略管理
局限：
- 灵活性不足：配置复杂，难以调整
- 策略设计与运维复杂度高：需要专业的安全管理员
- 性能开销：每次访问都需要标签检查
2.4 ABAC 基于属性的访问控制
核心思想： 用四类属性做策略决策——主体/资源/操作/环境（如部门、密级、时间、位置、IP、协议）。
ABAC 属性模型
┌─────────────────────────────────────────────────────────────┐
│ ABAC 属性访问控制模型 │
└─────────────────────────────────────────────────────────────┘
四类属性维度：
┌─────────────────────────────────────────────────────────────┐
│ 1. 主体属性 (Subject Attributes) │
│ ┌──────────────┬─────────────────────────────────────────┐ │
│ │ 属性名 │ 示例值 │ │
│ ├──────────────┼─────────────────────────────────────────┤ │
│ │ department │ "财务部"、"研发部" │ │
│ │ role │ "经理"、"员工" │ │
│ │ clearance │ "机密"、"秘密" │ │
│ │ employee_id │ "E001"、"E002" │ │
│ └──────────────┴─────────────────────────────────────────┘ │
│ │
│ 2. 资源属性 (Resource Attributes) │
│ ┌──────────────┬─────────────────────────────────────────┐ │
│ │ 属性名 │ 示例值 │ │
│ ├──────────────┼─────────────────────────────────────────┤ │
│ │ type │ "文档"、"数据库" │ │
│ │ owner │ "财务部"、"研发部" │ │
│ │ classification│ "机密"、"公开" │ │
│ │ location │ "北京"、"上海" │ │
│ └──────────────┴─────────────────────────────────────────┘ │
│ │
│ 3. 操作属性 (Action Attributes) │
│ ┌──────────────┬─────────────────────────────────────────┐ │
│ │ 属性名 │ 示例值 │ │
│ ├──────────────┼─────────────────────────────────────────┤ │
│ │ action │ "read"、"write"、"delete" │ │
│ │ method │ "GET"、"POST"、"PUT" │ │
│ └──────────────┴─────────────────────────────────────────┘ │
│ │
│ 4. 环境属性 (Environment Attributes) │
│ ┌──────────────┬─────────────────────────────────────────┐ │
│ │ 属性名 │ 示例值 │ │
│ ├──────────────┼─────────────────────────────────────────┤ │
│ │ time │ "2024-01-01 09:00" │ │
│ │ location │ "北京办公室" │ │
│ │ ip_address │ "192.168.1.100" │ │
│ │ device │ "公司电脑"、"移动设备" │ │
│ │ mfa_status │ "已认证"、"未认证" │ │
│ └──────────────┴─────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
ABAC 策略决策流程
┌─────────────────────────────────────────────────────────────┐
│ ABAC 策略决策引擎 (PDP) │
└─────────────────────────────────────────────────────────────┘
访问请求：
┌─────────────────────────────────────────────────────────────┐
│ 主体：{department: "财务部", role: "经理", clearance: "机密"}│
│ 资源：{type: "文档", owner: "财务部", classification: "机密"}│
│ 操作：read │
│ 环境：{time: "09:00", location: "北京", ip: "192.168.1.100"}│
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 策略规则库 (Policy Repository) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 规则1： │ │
│ │ IF subject.department == resource.owner │ │
│ │ AND subject.clearance >= resource.classification │ │
│ │ AND environment.time BETWEEN "08:00" AND "18:00" │ │
│ │ THEN PERMIT │ │
│ │ │ │
│ │ 规则2： │ │
│ │ IF subject.role == "经理" │ │
│ │ AND action == "read" │ │
│ │ THEN PERMIT │ │
│ │ │ │
│ │ 规则3： │ │
│ │ IF environment.ip_address NOT IN whitelist │ │
│ │ THEN DENY │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 策略评估结果： │
│ ✓ 规则1匹配：允许访问 │
│ ✓ 规则2匹配：允许访问 │
│ ✗ 规则3不匹配：继续评估 │
│ │
│ 最终决策：PERMIT (允许) │
└─────────────────────────────────────────────────────────────┘
XACML 策略示例
XACML (eXtensible Access Control Markup Language) 策略示例：
<Policy PolicyId="财务文档访问策略">
<Target>
<Resources>
<Resource>
<ResourceMatch MatchId="string-equal">
<AttributeValue>文档</AttributeValue>
<ResourceAttributeDesignator AttributeId="type"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="string-equal">
<AttributeValue>read</AttributeValue>
<ActionAttributeDesignator AttributeId="action"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Rule RuleId="部门内访问规则" Effect="Permit">
<Condition>
<Apply FunctionId="string-equal">
<SubjectAttributeDesignator AttributeId="department"/>
<ResourceAttributeDesignator AttributeId="owner"/>
</Apply>
</Condition>
</Rule>
<Rule RuleId="默认拒绝" Effect="Deny"/>
</Policy>
典型应用场景
云资源访问控制：
┌─────────────────────────────────────────────────────────────┐
│ 场景：AWS S3 存储桶访问 │
│ │
│ 策略规则： │
│ IF subject.aws_account == resource.account │
│ AND subject.region == resource.region │
│ AND environment.time BETWEEN "00:00" AND "23:59" │
│ AND subject.mfa_status == "authenticated" │
│ THEN PERMIT │
│ │
│ 示例： │
│ 主体：{account: "123456789", region: "us-east-1", │
│ mfa: "authenticated"} │
│ 资源：{account: "123456789", region: "us-east-1", │
│ bucket: "my-bucket"} │
│ 环境：{time: "14:30"} │
│ 结果：✓ 允许访问 │
└─────────────────────────────────────────────────────────────┘
零信任网络访问：
┌─────────────────────────────────────────────────────────────┐
│ 场景：企业应用访问 │
│ │
│ 策略规则： │
│ IF subject.employee_status == "active" │
│ AND subject.department IN allowed_departments │
│ AND environment.device_compliance == "compliant" │
│ AND environment.location IN corporate_offices │
│ AND environment.time IN business_hours │
│ THEN PERMIT │
│ │
│ 多因素评估： │
│ - 用户身份验证 │
│ - 设备合规性检查 │
│ - 位置验证 │
│ - 时间窗口检查 │
│ - 行为分析 │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 灵活组合：可以表达复杂的业务规则
- 可表达复杂业务与合规规则：支持多维度条件判断
- 适合云资源/IAM/零信任：动态授权场景
- 细粒度控制：可以精确到单个资源属性
局限：
- 规则复杂导致性能与可维护性挑战：策略规则可能非常复杂
- 策略可视化与审计成本较高：需要专业工具
- 策略冲突检测困难：多个规则可能冲突
要点：
- 优先使用"允许列表 + 默认拒绝"
- 做好策略冲突检测与性能优化
- 使用策略引擎（如 OPA、Cedar）统一管理
2.5 ReBAC 基于关系的访问控制
核心思想： 按实体间关系与图结构推导权限（如"文件夹拥有者→子项继承"“组织/项目成员→资源访问”）；适合层级与协作场景。
ReBAC 关系图模型
┌─────────────────────────────────────────────────────────────┐
│ ReBAC 关系访问控制模型 │
└─────────────────────────────────────────────────────────────┘
关系类型：
┌─────────────────────────────────────────────────────────────┐
│ 1. 拥有关系 (Ownership) │
│ owner → resource │
│ │
│ 2. 成员关系 (Membership) │
│ user → group → resource │
│ │
│ 3. 继承关系 (Inheritance) │
│ parent → child (权限继承) │
│ │
│ 4. 协作关系 (Collaboration) │
│ user ↔ project → resource │
└─────────────────────────────────────────────────────────────┘
文件夹层级权限继承示例：
┌─────────────────────────────────────────────────────────────┐
│ /projects │
│ │ owner: admin, permissions: [read, write, delete] │
│ │ │
│ ├── /project-a/ │
│ │ │ owner: alice, permissions: [read, write] (继承父级) │
│ │ │ │
│ │ ├── /project-a/docs/ │
│ │ │ │ owner: alice, permissions: [read, write] (继承) │
│ │ │ │ │
│ │ │ └── /project-a/docs/doc1.txt │
│ │ │ │ owner: alice, permissions: [read, write] (继承)│
│ │ │ │
│ │ └── /project-a/code/ │
│ │ │ owner: bob, permissions: [read] (覆盖父级) │
│ │ │
│ └── /project-b/ │
│ │ owner: charlie, permissions: [read] (继承父级) │
└─────────────────────────────────────────────────────────────┘
权限继承规则：
- 子资源默认继承父资源的权限
- 可以显式覆盖父级权限
- 继承是递归的（子→孙→...）
图数据库表示
Neo4j 图数据库中的 ReBAC 模型：
┌─────────────────────────────────────────────────────────────┐
│ (User:alice)-[:OWNS]->(Folder:project-a) │
│ (User:alice)-[:MEMBER_OF]->(Group:developers) │
│ (Group:developers)-[:HAS_ACCESS]->(Resource:code-repo) │
│ (Folder:project-a)-[:CONTAINS]->(File:doc1.txt) │
│ (Folder:project-a)-[:INHERITS_FROM]->(Folder:projects) │
│ │
│ 查询：alice 对 doc1.txt 的权限？ │
│ 路径：alice → OWNS → project-a → CONTAINS → doc1.txt │
│ 结果：✓ 拥有 read, write 权限 │
└─────────────────────────────────────────────────────────────┘
Cypher 查询示例：
MATCH (user:User {name: 'alice'})-[:OWNS|MEMBER_OF*]->(resource:Resource)
WHERE resource.name = 'doc1.txt'
RETURN user, resource, permissions
协作平台应用
Google Drive / SharePoint 权限模型：
┌─────────────────────────────────────────────────────────────┐
│ 文档：/团队/项目/设计文档.docx │
│ │
│ 权限关系： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 直接权限： │ │
│ │ - 创建者：alice (完全控制) │ │
│ │ - 共享给：bob (编辑) │ │
│ │ │ │
│ │ 继承权限： │ │
│ │ - 团队成员：developers (查看) ← 从父文件夹继承 │ │
│ │ - 组织成员：company (查看) ← 从组织继承 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 权限计算： │
│ alice: 完全控制 (直接权限，最高) │
│ bob: 编辑 (直接权限) │
│ developers成员: 查看 (继承权限) │
│ 其他公司成员: 查看 (继承权限) │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 贴合现实关系：符合实际的组织结构和协作模式
- 减少逐客体授权：通过关系自动推导权限
- 对大规模分布式系统友好：图结构便于扩展
- 支持复杂关系：可以表达多对多、层级等复杂关系
局限：
- 递归/继承计算复杂：需要遍历图结构
- 审计复杂：需要追踪关系链
- 与属性/角色需协同治理：需要与其他模型结合
趋势：
- 在 GenAI/RAG 与协作平台中，常与 ABAC 组合实现"关系 + 上下文"的动态授权
- 使用图数据库（如 Neo4j）存储和查询关系
2.6 TBAC/T-RBAC 基于任务/任务角色的访问控制
核心思想： 围绕工作流/工单/审批的临时上下文授权；用户仅在该任务会话中拥有短时特权。
TBAC 任务生命周期
┌─────────────────────────────────────────────────────────────┐
│ TBAC 任务权限生命周期 │
└─────────────────────────────────────────────────────────────┘
任务创建阶段：
┌─────────────────────────────────────────────────────────────┐
│ 1. 任务创建 │
│ - 创建工单：数据导出申请 │
│ - 分配执行人：alice │
│ - 任务权限：临时授予 "data:export" 权限 │
│ - 有效期：2024-01-01 09:00 至 2024-01-01 18:00 │
│ │
│ 2. 权限激活 │
│ - alice 接受任务 │
│ - 系统激活临时权限 │
│ - 权限范围：仅限该任务相关资源 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 任务执行阶段： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 用户：alice │ │
│ │ 任务：数据导出申请 (ID: TASK-001) │ │
│ │ 权限：data:export (临时) │ │
│ │ 资源：/data/customer.csv (仅限此资源) │ │
│ │ 时间窗口：09:00 - 18:00 │ │
│ │ │ │
│ │ ✓ 允许：导出 /data/customer.csv │ │
│ │ ✗ 拒绝：导出 /data/financial.csv (超出任务范围) │ │
│ │ ✗ 拒绝：在 18:00 后访问 (超出时间窗口) │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 任务完成阶段： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 1. 任务完成 │ │
│ │ - alice 完成数据导出 │ │
│ │ - 提交任务完成报告 │ │
│ │ │ │
│ │ 2. 权限回收 │ │
│ │ - 系统自动撤销临时权限 │ │
│ │ - 记录权限使用日志 │ │
│ │ - 生成审计报告 │ │
│ │ │ │
│ │ 3. 权限失效 │ │
│ │ - alice 不再拥有 data:export 权限 │ │
│ │ - 后续访问需要重新申请 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
工作流集成示例
审批流程中的 TBAC：
┌─────────────────────────────────────────────────────────────┐
│ 流程：财务数据导出审批 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 申请阶段 │───▶│ 审批阶段 │───▶│ 执行阶段 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ │ │ │ │
│ 申请人：alice 审批人：bob 执行人：alice │
│ 权限：无 权限：approve 权限：export (临时) │
│ (仅限此任务) (仅限此任务，24小时) │
│ │
│ 权限时间线： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 09:00 alice 提交申请 (无权限) │ │
│ │ 10:00 bob 审批通过 (激活 approve 权限) │ │
│ │ 10:05 alice 获得临时 export 权限 (24小时) │ │
│ │ 10:10 alice 执行导出 (使用临时权限) │ │
│ │ 次日10:05 临时权限自动失效 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 降低长期赋权风险：权限仅在任务期间有效
- 贴合最小特权与即时授权：按需授予，用完即收
- 便于审计回收：权限使用有明确的开始和结束时间
- 支持细粒度控制：可以限制权限的作用范围和资源
局限：
- 需与流程引擎/任务系统深度集成：需要工作流引擎支持
- 任务边界外的越权需额外校验：需要明确任务范围
- 实现复杂度较高：需要管理任务生命周期和权限状态
场景：
- 运维变更：临时授予服务器操作权限
- 数据导出审批：临时授予数据导出权限
- 临时提权：紧急情况下的临时权限提升
- 敏感操作审批：需要审批后才能执行的操作
2.7 OBAC 基于对象的访问控制
核心思想： 以对象为中心组织权限，强调对象级策略与复用。
优点： 策略复用、组织性强
局限： 设计抽象要求高
2.8 UCON 使用控制
核心思想： 引入义务/条件/持续控制，支持一次性/时效性与持续评估。
优点： 可表达一次性/时效性
局限： 实现与验证复杂
2.9 NGAC 下一代访问控制
核心思想： 用图模型统一表达主体、资源、操作、环境、组织与策略，支持集中、一致、可扩展的细粒度授权与实时撤销。
NGAC 图模型架构
┌─────────────────────────────────────────────────────────────┐
│ NGAC 下一代访问控制图模型 │
└─────────────────────────────────────────────────────────────┘
统一图结构：
┌─────────────────────────────────────────────────────────────┐
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Subject │───▶│ Policy │───▶│ Object │ │
│ │ (主体) │ │ (策略) │ │ (客体) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ User │ │ Rule │ │ Resource│ │
│ │ Group │ │ Condition│ │ File │ │
│ │ Role │ │ Action │ │ Service │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 关系类型： │
│ - ASSIGN: 主体分配到策略 │
│ - ASSOCIATE: 策略关联到客体 │
│ - INHERIT: 继承关系 │
│ - CONTAIN: 包含关系 │
└─────────────────────────────────────────────────────────────┘
示例图结构：
┌─────────────────────────────────────────────────────────────┐
│ (User:alice) │
│ │ │
│ │ ASSIGN │
│ ▼ │
│ (Policy:read-docs) │
│ │ │
│ │ ASSOCIATE │
│ ▼ │
│ (Object:/docs/report.pdf) │
│ │
│ 查询路径：alice → read-docs → report.pdf │
│ 结果：✓ 允许读取 │
└─────────────────────────────────────────────────────────────┘
NGAC 策略表达
NGAC 策略规则示例：
┌─────────────────────────────────────────────────────────────┐
│ 策略定义： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Policy: department-access │ │
│ │ Condition: │ │
│ │ subject.department == object.owner │ │
│ │ Action: │ │
│ │ permit read, write │ │
│ │ Effect: │ │
│ │ allow │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 策略应用： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 主体：alice (department: "财务部") │ │
│ │ 客体：report.pdf (owner: "财务部") │ │
│ │ 操作：read │ │
│ │ │ │
│ │ 评估： │ │
│ │ ✓ department == owner → 条件满足 │ │
│ │ ✓ read in Action → 操作允许 │ │
│ │ → 决策：PERMIT │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
实时撤销机制
NGAC 实时权限撤销：
┌─────────────────────────────────────────────────────────────┐
│ 场景：用户权限变更 │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 初始状态： │ │
│ │ (User:alice) → ASSIGN → (Policy:read-docs) │ │
│ │ alice 拥有读取文档权限 │ │
│ │ │ │
│ │ 权限撤销： │ │
│ │ 1. 管理员撤销 alice 的 read-docs 策略 │ │
│ │ 2. 系统删除 ASSIGN 关系边 │ │
│ │ 3. 实时通知所有相关服务 │ │
│ │ │ │
│ │ 撤销后： │ │
│ │ (User:alice) ✗ (Policy:read-docs) │ │
│ │ alice 立即失去读取文档权限 │ │
│ │ │ │
│ │ 后续访问： │ │
│ │ alice 尝试读取文档 → ✗ 拒绝 (权限已撤销) │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 策略一致性与可观测性强：统一的图模型便于管理
- 便于与微服务/云原生集成：支持分布式权限管理
- 实时撤销：权限变更立即生效
- 可扩展：图结构易于扩展新的实体和关系
局限：
- 概念与工程化门槛较高：需要理解图模型
- 需配套策略治理与工具链：需要专业工具支持
- 性能考虑：大规模图查询可能影响性能
应用场景：
- 大规模分布式系统
- 云原生应用
- 需要实时权限管理的场景
2.10 CBAC 基于内容的访问控制
核心思想： 依据内容分类/敏感度（如关键字、正则、指纹、语义）动态决策访问/脱敏/阻断；常与 DLP 结合。
CBAC 内容识别流程
┌─────────────────────────────────────────────────────────────┐
│ CBAC 内容访问控制流程 │
└─────────────────────────────────────────────────────────────┘
访问请求：
┌─────────────────────────────────────────────────────────────┐
│ 用户：alice │
│ 资源：/documents/report.pdf │
│ 操作：read │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 内容分析引擎 │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 1. 关键字匹配 │ │
│ │ - 检测敏感词：身份证号、银行卡号、密码 │ │
│ │ - 匹配规则：正则表达式 │ │
│ │ │ │
│ │ 2. 数据指纹识别 │ │
│ │ - 计算文档哈希值 │ │
│ │ - 与敏感数据指纹库比对 │ │
│ │ │ │
│ │ 3. 语义分析 │ │
│ │ - NLP 模型分析内容语义 │ │
│ │ - 识别敏感信息类型 │ │
│ │ │ │
│ │ 4. 分类器评估 │ │
│ │ - 机器学习分类器 │ │
│ │ - 输出敏感度评分 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 内容分类结果： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 敏感度级别：高 │ │
│ │ 敏感类型：财务数据、个人信息 │ │
│ │ 置信度：0.95 │ │
│ │ 匹配规则：身份证号正则、银行卡号模式 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 访问控制决策： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 策略规则： │ │
│ │ IF content.sensitivity == "高" │ │
│ │ AND user.clearance < "机密" │ │
│ │ THEN 脱敏显示 (部分内容) │ │
│ │ │ │
│ │ 执行动作： │ │
│ │ ✓ 允许访问，但进行内容脱敏 │ │
│ │ - 身份证号：320***********1234 │ │
│ │ - 银行卡号：**** **** **** 5678 │ │
│ │ - 其他敏感信息：已隐藏 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
敏感数据识别示例
┌─────────────────────────────────────────────────────────────┐
│ 敏感数据识别规则库 │
├─────────────────────────────────────────────────────────────┤
│ 1. 身份证号： │
│ 正则：\d{17}[\dXx] │
│ 示例：320123199001011234 │
│ │
│ 2. 银行卡号： │
│ 正则：\d{13,19} │
│ 示例：6222021234567890123 │
│ │
│ 3. 手机号： │
│ 正则：1[3-9]\d{9} │
│ 示例：13812345678 │
│ │
│ 4. 邮箱： │
│ 正则：[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,} │
│ 示例：user@example.com │
│ │
│ 5. 密码模式： │
│ 检测：password、pwd、passwd 等关键字 │
│ │
│ 6. API 密钥： │
│ 检测：AKIA、sk_live、Bearer token 等模式 │
└─────────────────────────────────────────────────────────────┘
DLP 集成示例
数据防泄漏 (DLP) 集成：
┌─────────────────────────────────────────────────────────────┐
│ 场景：用户尝试复制敏感内容到外部应用 │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 1. 内容检测 │ │
│ │ - 检测到剪贴板包含身份证号 │ │
│ │ - 敏感度评分：0.9 (高) │ │
│ │ │ │
│ │ 2. 策略匹配 │ │
│ │ - 规则：禁止高敏感数据复制到外部应用 │ │
│ │ - 动作：阻断 │ │
│ │ │ │
│ │ 3. 执行动作 │ │
│ │ - 阻止复制操作 │ │
│ │ - 记录安全事件 │ │
│ │ - 通知安全管理员 │ │
│ │ │ │
│ │ 4. 审计日志 │ │
│ │ - 时间：2024-01-01 10:30:00 │ │
│ │ - 用户：alice │ │
│ │ - 操作：复制 │ │
│ │ - 内容：包含身份证号 │ │
│ │ - 结果：已阻断 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
GenAI/RAG 应用
RAG 知识库内容访问控制：
┌─────────────────────────────────────────────────────────────┐
│ 场景：AI 助手回答用户问题 │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 用户问题：公司去年的财务数据是多少？ │ │
│ │ │ │
│ │ 1. 内容检索 │ │
│ │ - 检索相关文档：财务报告.pdf │ │
│ │ - 文档敏感度：高 (包含财务数据) │ │
│ │ │ │
│ │ 2. 权限检查 │ │
│ │ - 用户权限：普通员工 │ │
│ │ - 所需权限：财务数据查看 (机密) │ │
│ │ - 结果：权限不足 │ │
│ │ │ │
│ │ 3. 内容过滤 │ │
│ │ - 移除敏感数据：具体金额 │ │
│ │ - 保留一般信息：增长趋势 │ │
│ │ │ │
│ │ 4. 响应生成 │ │
│ │ - 回答：公司财务数据属于机密信息，无法提供具体数值。 │ │
│ │ - 建议：请联系财务部门获取授权 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 对"敏感数据"识别更精准：可以识别各种格式的敏感信息
- 适合 GenAI/RAG 知识库防泄漏：防止 AI 泄露敏感内容
- 支持动态脱敏：根据用户权限动态调整内容可见性
- 与 DLP 结合：提供完整的数据保护方案
局限：
- 识别准确率与性能权衡：高精度识别可能影响性能
- 需持续训练与更新分类器：需要维护识别规则和模型
- 误报和漏报：可能误判或漏判敏感内容
- 计算开销：内容分析需要额外的计算资源
趋势：
- 与 ABAC/ReBAC 组合，实现"内容 + 关系 + 上下文"的联合防护
- 使用 AI/ML 提升识别准确率
- 集成到数据流中实现实时检测和阻断
2.11 IBAC 基于意图的访问控制
核心思想： 实时解析用户意图/行为链（而非仅静态规则），结合上下文动态授权/拒绝；适配 AI 原生场景。
IBAC 意图分析流程
┌─────────────────────────────────────────────────────────────┐
│ IBAC 意图访问控制流程 │
└─────────────────────────────────────────────────────────────┘
用户行为序列：
┌─────────────────────────────────────────────────────────────┐
│ 行为链： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 1. 用户登录 │ │
│ │ 2. 查看用户列表 │ │
│ │ 3. 查看特定用户详情 │ │
│ │ 4. 尝试修改用户权限 │ │
│ │ 5. 尝试导出用户数据 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 意图分析： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 1. 行为模式识别 │ │
│ │ - 快速浏览多个用户 → 可能在进行信息收集 │ │
│ │ - 查看权限相关功能 → 可能意图越权 │ │
│ │ │ │
│ │ 2. 上下文分析 │ │
│ │ - 时间：非工作时间 │ │
│ │ - 位置：异常IP地址 │ │
│ │ - 设备：新设备首次登录 │ │
│ │ │ │
│ │ 3. 意图评分 │ │
│ │ - 正常操作：0.2 │ │
│ │ - 可疑行为：0.6 │ │
│ │ - 越权意图：0.9 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 访问决策： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ IF 意图评分 > 0.7 │ │
│ │ AND 行为模式 == "越权模式" │ │
│ │ THEN DENY + 告警 │ │
│ │ │ │
│ │ 结果： │ │
│ │ ✗ 拒绝修改用户权限 (检测到越权意图) │ │
│ │ ⚠ 触发安全告警 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
行为模式识别
┌─────────────────────────────────────────────────────────────┐
│ 常见越权行为模式： │
├─────────────────────────────────────────────────────────────┤
│ 1. 权限提升尝试 │
│ - 行为：查看管理员功能 → 尝试访问 → 尝试修改 │
│ - 意图：获取超出当前角色的权限 │
│ │
│ 2. 数据收集模式 │
│ - 行为：快速浏览大量数据 → 批量导出 │
│ - 意图：收集敏感信息 │
│ │
│ 3. 横向移动 │
│ - 行为：访问多个用户数据 → 尝试跨部门访问 │
│ - 意图：扩大访问范围 │
│ │
│ 4. 异常时间访问 │
│ - 行为：非工作时间访问敏感资源 │
│ - 意图：避开监控 │
│ │
│ 5. 组合攻击 │
│ - 行为：多个低权限操作组合 → 达到高权限效果 │
│ - 意图：绕过权限检查 │
└─────────────────────────────────────────────────────────────┘
AI 场景应用
GenAI 安全中的 IBAC：
┌─────────────────────────────────────────────────────────────┐
│ 场景：AI 助手处理用户请求 │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 用户请求序列： │ │
│ │ 1. "帮我查看一下财务数据" │ │
│ │ 2. "能给我详细的数据吗？" │ │
│ │ 3. "可以导出成 Excel 吗？" │ │
│ │ 4. "发送到我的邮箱" │ │
│ │ │ │
│ │ 意图分析： │ │
│ │ - 请求1：正常查询 (意图评分：0.3) │ │
│ │ - 请求2：尝试获取详细信息 (意图评分：0.5) │ │
│ │ - 请求3：尝试导出数据 (意图评分：0.7) │ │
│ │ - 请求4：尝试外部传输 (意图评分：0.9) │ │
│ │ │ │
│ │ 意图链分析： │ │
│ │ - 渐进式获取敏感数据 │ │
│ │ - 最终意图：数据泄露 │ │
│ │ │ │
│ │ 访问控制： │ │
│ │ ✓ 请求1：允许（返回脱敏数据） │ │
│ │ ✓ 请求2：允许（返回脱敏数据） │ │
│ │ ✗ 请求3：拒绝（检测到导出意图） │ │
│ │ ✗ 请求4：拒绝（检测到泄露意图）+ 告警 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
优点与局限
优点：
- 能识别"越权意图"与组合攻击：通过行为分析发现潜在威胁
- 提升对抗性：可以检测静态规则无法发现的攻击模式
- 动态适应：可以根据行为模式调整安全策略
- 适合 AI 场景：可以分析语义和上下文
局限：
- 意图识别准确性与合规解释挑战：可能误判正常行为
- 需与内容/关系/属性策略协同：需要结合其他模型
- 计算开销：需要实时分析行为序列
- 隐私考虑：需要收集和分析用户行为数据
趋势：
- 在 GenAI 安全中，常与 CBAC/ABAC 组合形成"语义理解 + 动态控制"
- 使用机器学习提升意图识别准确率
- 集成到零信任架构中
范式对比与选型建议
3.1 权限范式适用场景对比图
┌─────────────────────────────────────────────────────────────┐
│ 权限范式适用场景矩阵 │
└─────────────────────────────────────────────────────────────┘
场景维度：
┌──────────────┬──────┬──────┬──────┬──────┬──────┬──────┐
│ 场景 │ ACL │ DAC │ MAC │ RBAC │ ABAC │ ReBAC│
├──────────────┼──────┼──────┼──────┼──────┼──────┼──────┤
│ 文件系统 │ ✓✓ │ ✓✓ │ ✓ │ ✗ │ ✗ │ ✗ │
│ 操作系统 │ ✓✓ │ ✓✓ │ ✓✓ │ ✗ │ ✗ │ ✗ │
│ 企业应用 │ ✗ │ ✗ │ ✗ │ ✓✓ │ ✓ │ ✓ │
│ 云资源 │ ✗ │ ✗ │ ✗ │ ✓ │ ✓✓ │ ✓ │
│ 协作平台 │ ✗ │ ✓ │ ✗ │ ✓ │ ✓ │ ✓✓ │
│ 工作流 │ ✗ │ ✗ │ ✗ │ ✓ │ ✓ │ ✗ │
│ 敏感数据 │ ✗ │ ✗ │ ✓✓ │ ✗ │ ✓ │ ✗ │
│ AI/GenAI │ ✗ │ ✗ │ ✗ │ ✗ │ ✓ │ ✓ │
└──────────────┴──────┴──────┴──────┴──────┴──────┴──────┘
图例：✓✓ 非常适合 ✓ 适合 ✗ 不适合
3.2 权限决策流程对比
┌─────────────────────────────────────────────────────────────┐
│ 不同范式的权限决策流程 │
└─────────────────────────────────────────────────────────────┘
ACL 决策流程：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 请求 │───▶│ 查找ACL │───▶│ 顺序匹配 │───▶│ 决策 │
│ │ │ 列表 │ │ 规则 │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
(线性查找) (第一条匹配即停止)
RBAC 决策流程：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 请求 │───▶│ 查找用户 │───▶│ 查找角色 │───▶│ 决策 │
│ │ │ 角色 │ │ 权限 │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
(关联查询) (权限聚合)
ABAC 决策流程：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 请求 │───▶│ 提取属性 │───▶│ 策略评估 │───▶│ 决策 │
│ │ │ 四维度 │ │ 规则引擎│ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
(属性收集) (规则匹配)
ReBAC 决策流程：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 请求 │───▶│ 查找关系 │───▶│ 图遍历 │───▶│ 决策 │
│ │ │ 图结构 │ │ 路径 │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
(关系查询) (路径查找)
3.3 横向对比表
| 模型 | 核心思想 | 典型场景 | 优点 | 局限 | 实现复杂度 |
|---|---|---|---|---|---|
| ACL | 客体维护主体-操作列表 | 文件系统、对象存储 | 简单直观 | 规模大时维护难 | 低 |
| DAC | 拥有者自主授权 | UNIX/Linux/Windows 文件 | 灵活放权 | 易扩散与越权 | 低 |
| MAC | 主体/客体安全标签强匹配 | 军用、涉密 | 高安全、强合规 | 不灵活、成本高 | 高 |
| RBAC | 用户-角色-权限 | 企业应用、后台管理 | 治理与审计友好、性能好 | 角色爆炸、细粒度不足 | 低-中 |
| ABAC | 用户/资源/操作/环境属性组合 | 云资源、跨租户、合规 | 细粒度、动态、可组合 | 规则复杂、性能与治理挑战 | 高 |
| ReBAC | 关系/图推导（如层级继承） | 文档/项目/团队协作 | 贴合关系数据、减少逐标签 | 递归/审计复杂 | 中-高 |
| TBAC/T-RBAC | 任务/流程上下文授权 | 审批、运维工单 | 短时特权、场景化 | 需与流程引擎集成 | 中 |
| OBAC | 以对象为中心的策略 | 复杂对象模型 | 策略复用、组织性强 | 设计抽象要求高 | 中 |
| UCON | 义务/条件/持续控制 | 高合规、持续评估 | 可表达一次性/时效性 | 实现与验证复杂 | 高 |
| NGAC | 图模型统一策略 | 大规模、细粒度、集中治理 | 一致性强、可扩展、实时撤销 | 概念与工程化门槛 | 中-高 |
| CBAC | 内容分类/敏感度识别 | 敏感数据防护、DLP | 精准识别敏感数据 | 识别准确率与性能权衡 | 中-高 |
| IBAC | 意图/行为链解析 | AI 原生场景 | 识别越权意图与组合攻击 | 意图识别准确性与合规挑战 | 高 |
3.4 实际应用场景示例
场景1：企业OA系统
┌─────────────────────────────────────────────────────────────┐
│ 推荐方案：RBAC + ACL │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 基础权限：RBAC │ │
│ │ - 角色：管理员、部门经理、普通员工 │ │
│ │ - 权限：查看、编辑、删除、审批 │ │
│ │ │ │
│ │ 特殊权限：ACL │ │
│ │ - 特定文档的访问控制 │ │
│ │ - 临时共享权限 │ │
│ │ │ │
│ │ 示例： │ │
│ │ alice (部门经理) │ │
│ │ - 通过角色获得：查看部门文档、审批流程 │ │
│ │ - 通过ACL获得：特定项目文档的编辑权限 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
场景2：云平台多租户系统
┌─────────────────────────────────────────────────────────────┐
│ 推荐方案：RBAC + ABAC │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 基础权限：RBAC │ │
│ │ - 角色：租户管理员、开发者、运维 │ │
│ │ - 权限：资源创建、删除、配置 │ │
│ │ │ │
│ │ 动态权限：ABAC │ │
│ │ - 时间限制：仅工作时间可操作 │ │
│ │ - 位置限制：仅允许从公司IP访问 │ │
│ │ - 资源标签：仅能访问本租户资源 │ │
│ │ - MFA要求：敏感操作需要多因素认证 │ │
│ │ │ │
│ │ 示例： │ │
│ │ bob (开发者) │ │
│ │ - 角色权限：可以创建云服务器 │ │
│ │ - ABAC限制： │ │
│ │ ✓ 工作时间 + 公司IP → 允许创建 │ │
│ │ ✗ 非工作时间 → 拒绝创建 │ │
│ │ ✗ 外部IP → 拒绝创建 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
场景3：文档协作平台
┌─────────────────────────────────────────────────────────────┐
│ 推荐方案：ReBAC + ABAC │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 关系权限：ReBAC │ │
│ │ - 文件夹拥有者 → 子文件继承权限 │ │
│ │ - 项目成员 → 项目文档访问权限 │ │
│ │ - 组织成员 → 组织共享文档权限 │ │
│ │ │ │
│ │ 动态权限：ABAC │ │
│ │ - 时间限制：共享链接有效期 │ │
│ │ - 设备限制：仅允许公司设备访问 │ │
│ │ - 位置限制：仅允许特定地区访问 │ │
│ │ │ │
│ │ 示例： │ │
│ │ /projects/project-a/ │ │
│ │ - 拥有者：alice (完全控制) │ │
│ │ - 成员：bob, charlie (编辑权限，继承自项目) │ │
│ │ - 共享链接： │ │
│ │ ✓ 有效期：7天 │ │
│ │ ✓ 仅公司设备 │ │
│ │ ✗ 外部设备 → 拒绝访问 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
场景4：敏感数据处理系统
┌─────────────────────────────────────────────────────────────┐
│ 推荐方案：MAC + CBAC + ABAC │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 强制控制：MAC │ │
│ │ - 安全标签：绝密、机密、秘密、公开 │ │
│ │ - 强制规则：不上读、不下写 │ │
│ │ │ │
│ │ 内容识别：CBAC │ │
│ │ - 检测敏感数据：身份证、银行卡、密码 │ │
│ │ - 动态脱敏：根据用户权限显示内容 │ │
│ │ │ │
│ │ 动态控制：ABAC │ │
│ │ - 时间限制：仅工作时间 │ │
│ │ - 位置限制：仅公司内网 │ │
│ │ - 设备限制：仅公司设备 │ │
│ │ │ │
│ │ 示例： │ │
│ │ 文档：财务报告.pdf (机密级别) │ │
│ │ 用户：alice (秘密级别) │ │
│ │ │ │
│ │ MAC检查： │ │
│ │ ✗ 秘密 < 机密 → 拒绝访问 │ │
│ │ │ │
│ │ 如果用户是机密级别： │ │
│ │ ✓ MAC允许访问 │ │
│ │ → CBAC检查内容 → 脱敏显示敏感字段 │ │
│ │ → ABAC检查环境 → 仅工作时间+公司内网允许 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
3.5 选型建议与组合落地
小型/角色稳定场景
推荐方案： 优先 RBAC（易实施、性能好），必要时叠加 ACL 做对象级特例
中大型/细粒度/跨租户场景
推荐方案： 以 RBAC 为底座，按属性与上下文引入 ABAC（如时间、位置、MFA、资源标签）
强层级/协作关系场景
推荐方案： 引入 ReBAC（文件夹/项目/组织树），与 RBAC/ABAC 组合表达"结构+条件"
高合规/临时授权/持续评估场景
推荐方案： 采用 UCON/TBAC 表达义务与时效，配合 NGAC 做统一策略与审计
敏感数据防护场景
推荐方案： 用 CBAC 做内容识别与脱敏/阻断，优先保护高敏数据
AI 场景
推荐方案： 采用"CBAC + (ABAC|ReBAC)"实现内容与关系的双重校验，必要时叠加 IBAC 识别越权意图
3.6 组合建议
基础快速落地：
- 以 RBAC 为底座，面向资源与对象用 ACL 做特例；强合规/涉密叠加 MAC
细粒度与跨租户：
- 以 ABAC 表达"用户/资源/环境"多维策略，配合 RBAC 做规模化治理
层级/协作数据：
- 引入 ReBAC 表达"拥有/继承/成员"关系，减少逐条授权
临时特权与流程：
- 用 TBAC 管理工单/审批的短时授权
敏感数据防护：
- 用 CBAC 做内容识别与脱敏/阻断，优先保护高敏数据
AI 场景：
- 采用"CBAC + (ABAC|ReBAC)"实现内容与关系的双重校验，必要时叠加 IBAC 识别越权意图
工程实践要点
4.1 策略与代码解耦
推荐做法：
- 使用 OPA/Rego、Cedar 等策略引擎
- 以"权限码"统一鉴权口径
- 策略与代码解耦，便于测试与维护
4.2 默认拒绝与显式允许
核心原则：
- 全链路一致地执行"Deny by Default"
- 显式允许，避免隐式授权
4.3 可观测与回滚
关键实践：
- 策略变更审计
- 灰度/金丝雀发布
- 权限回收与最短存活期
4.4 性能与缓存
优化策略：
- 规则编译/索引
- 热点策略缓存
- 按需失效与批量评估
4.5 认证与鉴权分离
架构原则：
- 认证（Authentication）：验证用户身份
- 鉴权（Authorization）：验证用户权限
- 两者分离，便于独立扩展与优化
总结
关键要点
- RBAC 是最常用的工程落地基线，适合大多数企业应用场景
- 权限设计需要根据场景选择合适的范式，很多系统会组合多种范式
- 以权限码而非角色名做鉴权，避免硬编码，便于策略与代码解耦
- 默认拒绝、显式允许，全链路一致执行安全策略
- 策略与代码解耦，使用成熟的策略引擎，便于测试与维护
快速选型参考
| 场景 | 推荐范式 | 说明 |
|---|---|---|
| 小型/角色稳定 | RBAC + ACL | 基础模型，易于实现 |
| 中大型/细粒度/跨租户 | RBAC + ABAC | 细粒度动态授权 |
| 强层级/协作关系 | RBAC + ReBAC | 关系继承授权 |
| 高合规/临时授权 | UCON/TBAC + NGAC | 统一策略与审计 |
| 敏感数据防护 | CBAC + (ABAC|ReBAC) | 内容与关系双重校验 |
| AI 场景 | CBAC + ABAC/ReBAC + IBAC | 语义理解与动态控制 |
参考资源
- NIST RBAC Model
- XACML Standard
- OPA Policy Engine
- AWS Cedar Policy Language
- OWASP Access Control Cheat Sheet
文档版本：2.0
最后更新：2025-12-05
基于 RBAC 权限表设计与权限设计范式全览整理，已补充 ASCII 图表和详细说明
扫一扫
880
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
