1. 权限模型演进路径：从DAC到MAC、从ACL到RBAC、RBAC标准化历程
1.1 边界定义
权限模型决定了谁（主体）能对什么（客体）执行何种操作，是企业应用安全架构的底层逻辑。本章围绕操作系统与大型企业软件中的权限模型演进路径展开，覆盖从自主型到强制型、从访问控制列表到基于角色的访问控制的完整链路，并引入 NIST RBAC 标准化成果。
1.2 演进分层与阶段
权限模型在 40 年间经历了四次关键跃迁，每一阶段解决了前一阶段的核心痛点：
| 阶段 | 模型 | 核心思路 | 代表场景 |
|---|---|---|---|
| 1 | DAC (自主访问控制) | 客体所有者自行决定权限分配 | Unix 文件系统 rwx |
| 2 | MAC (强制访问控制) | 系统根据安全标签统一控制 | 军事分级系统、SELinux |
| 3 | ACL (访问控制列表) | 为每个客体维护用户权限列表 | 早期目录服务、网络设备 |
| 4 | RBAC (基于角色的访问控制) | 通过角色将用户与权限解耦 | 企业 SaaS、ERP、云平台 |
| 5 | NIST RBAC 标准化 | 核心、层级、约束三大规范 | ISO/IEC 标准、Azure RBAC |
1.3 组件职责对比
- 主体 (Subject)：用户、进程、服务账户。DAC 和 ACL 直接关联主体与权限，RBAC 通过角色间接关联。
- 客体 (Object)：文件、数据库表、API 端点。MAC 对客体标注安全级别（绝密/机密/公开）。
- 权限 (Permission)：读、写、执行、删除。DAC 中权限由所有者管理；MAC 中由策略管理器决定。
- 决策机制：DAC 检查主体标识；MAC 匹配安全标签；ACL 遍历列表；RBAC 计算角色-权限映射。
1.4 数据流 / 控制流 / 信任链路
下图展示了四个代表性模型在用户发起“读取文档”请求时的完整交互链路。
图1-1：权限模型演进路径示意图
1.5 选型权衡
- DAC 不适用于企业：权限分散、难以审计；适合个人设备或协作极少的场景。
- MAC 安全性最高但灵活性最低：适用于国防、金融等强监管领域，普通 SaaS 会造成过度约束。
- ACL 适合小型、静态资产：当客体数量超过 10³ 级，维护 ACL 列表的 O(n) 复杂度将导致管理瘫痪。
- RBAC 是企业产品首选：角色作为边界，支持动态变更、分级管理，与组织架构天然对齐。
- 标准化 RBAC（NIST）：提供核心、层级、约束三层模型，是避免自定义陷阱的工程基座。
1.6 风险点
常见落地陷阱：
- 角色爆炸（Role Explosion）：将角色粒度切分过细，导致角色数量与用户数同量级，丧失 RBAC 优势。
- 直接修改权限（Permission Per User）：绕过角色层直接为用户分配权限，退化回 ACL。
- 忽略层级与继承：静态 RBAC 无法支持汇报关系导出，需要手动维护角色关系。
- 无约束检查：缺少职责分离（SoD），如一人同时拥有“创建订单”和“审核订单”角色。
1.7 落地步骤
- 现状盘点：梳理当前系统中的主体、客体、权限表，确定是否已存在角色/组。
- 选择 RBAC 标准层级：小型应用可选核心 RBAC（仅角色-权限映射），大型企业建议层级+约束 RBAC。
- 设计角色结构：按组织职能（如销售、财务、管理员）构建上一层角色，避免过早细粒度。
- 定义权限依赖：将操作（CRUD）与资源（文档、API）进行矩阵化整理。
- 迁移数据：将现有 ACL/用户-权限映射转换为角色-权限映射，审计并清除孤儿权限。
- 上线约束：启用互斥角色、先决条件角色、基数约束等 NIST 约束特性。
- 灰度验证：选取 1~2 个业务模块试运行，对比前后权限变更时间与误配置率。
1.8 验收标准
| 维度 | 验收指标 | 目标值 |
|---|---|---|
| 功能正确性 | 角色-权限映射关系验证 | 100% 无遗漏、无越权 |
| 性能 | 单次权限决策延迟（P99） | ≤ 50ms |
| 可维护性 | 新增业务线时角色新增数量 | ≤ 3 个角色 / 业务线 |
| 审计合规 | 权限变更可追溯 | 操作人、时间、内容全程记录 |
| 约束覆盖 | 核心约束（SoD、基数、前置）启用率 | ≥ 80% |