3. 自主访问控制模型：DAC模型原理、ACL与Capability实现、优缺点分析
3.1 DAC模型核心原理
自主访问控制（Discretionary Access Control, DAC）是访问控制领域最基础的模型之一。其核心思想是：资源的拥有者（Owner）有权自主决定其他主体（用户/进程）对该资源的访问权限。在工程分析平台中，DAC 通常表现为“谁创建的数据，谁就拥有完全控制权，并可自行授权给他人”。
关键特征： 权限的传递性——用户 A 可以将其对文件 X 的读权限授予用户 B，用户 B 获得权限后，在支持传递的系统中甚至可以进一步授予用户 C。
DAC 模型在工程分析平台中的典型应用场景包括：
- 个人工作区： 工程师对自己创建的仿真模型、分析脚本、结果报告拥有完全控制权。
- 项目协作： 项目负责人可以自主将特定分析任务的查看或编辑权限授予团队成员。
- 临时共享： 需要将某个分析结果截图或数据快照分享给跨部门同事时，由数据所有者直接授权。
3.2 ACL 实现机制
访问控制列表（Access Control List, ACL） 是 DAC 模型最主流的实现方式。ACL 将权限信息附着在资源（Object）上，为每个资源维护一个列表，记录哪些主体（Subject）可以对该资源执行哪些操作。
3.2.1 ACL 数据结构
在工程分析平台中，一个典型的 ACL 条目包含以下字段：
| 字段 | 说明 | 示例值 |
|---|---|---|
| 主体标识 | 用户 ID、用户组 ID 或角色 ID | user_10086 / group_analyst |
| 权限掩码 | 位掩码表示的操作权限集合 | 0x7 (读|写|执行) |
| 继承标志 | 该 ACL 是否可被子资源继承 | true / false |
| 审计标志 | 是否记录该条目的访问日志 | true / false |
3.2.2 ACL 权限判定流程
- 请求到达： 主体 S 请求对资源 O 执行操作 op。
- 查找 ACL： 系统定位资源 O 关联的 ACL 列表。
- 顺序匹配： 按 ACL 条目顺序查找匹配主体 S 的条目（先精确匹配用户，再匹配用户组）。
- 权限裁决：
- 若找到匹配条目且权限掩码包含 op → 允许。
- 若找到匹配条目但权限掩码不包含 op → 拒绝。
- 若遍历完 ACL 无匹配 → 默认拒绝。
工程实践注意： ACL 条目顺序至关重要！在多数实现中，一旦找到匹配项就停止查找。因此，拒绝（Deny）条目应放在允许（Allow）条目之前，否则可能被允许条目覆盖导致权限绕过。
3.3 Capability 实现机制
能力（Capability）机制 是 DAC 模型的另一种实现方式，与 ACL 相反，它将权限信息附着在主体（Subject）上。每个主体持有一组“能力令牌”，每个令牌代表对某个资源的特定操作权限。
3.3.1 Capability 数据结构
// 工程分析平台中的 Capability 令牌结构示例
{
"cap_id": "cap_a1b2c3d4",
"type": "object_capability",
"object_id": "simulation_model_789",
"object_type": "SimulationModel",
"permissions": ["read", "execute"],
"issuer": "user_10086",
"issued_at": 1712345678,
"expires_at": 1712432078,
"signature": "0x7a8b9c..." // 防篡改签名
}3.3.2 Capability 权限判定流程
- 请求到达： 主体 S 请求对资源 O 执行操作 op，并附带其持有的 Capability 令牌。
- 令牌验证： 系统验证令牌的签名、有效期、颁发者合法性。
- 权限检查： 检查令牌中 object_id 是否匹配资源 O，permissions 是否包含 op。
- 裁决： 验证通过且权限匹配 → 允许；否则 → 拒绝。
3.4 ACL 与 Capability 对比分析
| 对比维度 | ACL | Capability |
|---|---|---|
| 权限存储位置 | 资源端（Object） | 主体端（Subject） |
| 权限查询效率 | O(n)，n 为 ACL 条目数 | O(1)，直接验证令牌 |
| 权限撤销 | 容易，直接修改资源 ACL | 困难，需追踪所有令牌副本 |
| 权限传递 | 需显式修改 ACL | 令牌可直接传递 |
| 分布式适用性 | 较差，依赖中心化资源服务器 | 较好，令牌可离线验证 |
| 防篡改能力 | 强，ACL 由系统保护 | 依赖签名机制 |
| 工程分析平台典型场景 | 文件系统、项目仓库 | 微服务间调用、API 授权 |
3.5 DAC 模型优缺点分析
3.5.1 优点
- 灵活性高： 资源所有者可根据实际协作需求自主授权，无需管理员介入。
- 实现简单： ACL 和 Capability 机制都有成熟的工程实现，开发成本低。
- 用户友好： 符合“谁创建谁拥有”的直觉认知，学习曲线平缓。
- 细粒度控制： 可精确到单个用户对单个资源的特定操作权限。
3.5.2 缺点
- 权限管理分散： 权限分散在大量资源所有者手中，难以形成统一的全局安全策略。
- 信息泄露风险： 用户可能无意中将敏感数据授权给不适当的对象。
- 权限蔓延： 随着时间推移，权限授予关系变得复杂且难以审计。
- 无法强制全局策略： 例如“所有分析报告必须经过合规审查才能共享”这类全局规则难以在 DAC 中强制实施。
工程分析平台选型建议： DAC 模型适用于个人工作区、小团队协作、临时共享等场景。对于需要严格合规管控、全局统一策略的企业级平台，建议将 DAC 作为基础层，在其上叠加 MAC（强制访问控制）或 RBAC（基于角色的访问控制）模型。
3.6 工程分析平台中的 DAC 实践案例
某工程分析平台采用混合 DAC 架构：
| 资源类型 | 实现机制 | 默认权限 | 特殊策略 |
|---|---|---|---|
| 个人仿真模型 | ACL | 仅创建者读写 | 可授予团队读权限 |
| 项目分析报告 | ACL + 继承 | 项目成员读，负责人读写 | 子报告继承父目录 ACL |
| 微服务 API | Capability | 无默认权限 | 服务间通过 JWT 令牌调用 |
| 共享数据集 | ACL + 组 | 数据组读，创建者写 | 支持临时授权链接 |
该实践表明，在工程分析平台中，ACL 更适合管理静态资源（文件、模型、报告）的访问权限，而 Capability 更适合动态服务调用和分布式场景。合理组合两种机制可以发挥 DAC 模型的最大价值。