3. 自主访问控制：DAC模型原理、ACL实现、在工程平台中的优缺点
3.1 DAC模型核心原理
自主访问控制（Discretionary Access Control, DAC）是访问控制领域最经典的模型之一，其核心思想是：资源的拥有者（Owner）有权自主决定谁可以访问该资源，以及授予何种访问权限。在工程分析平台中，DAC 模型通常表现为“谁创建的数据，谁拥有管理权限”。
DAC 模型三要素：
- 主体（Subject）：用户或用户组，是访问行为的发起者。
- 客体（Object）：被保护的资源，如仿真模型、分析报告、测试用例、参数文件。
- 权限（Permission）：主体对客体可执行的操作，如读取、写入、执行、删除、授权。
DAC 的“自主性”体现在：客体所有者可以将自己拥有的权限传递给其他主体，且这种传递通常没有严格的限制。例如，一位结构工程师创建了一个有限元分析模型，他可以自主地将“读取”权限授予项目组同事，将“写入”权限授予合作方，甚至将“授权”权限转授给团队负责人。
3.2 ACL实现机制
在工程分析平台中，DAC 模型最常见的实现方式是访问控制列表（Access Control List, ACL）。ACL 是一个与客体关联的列表，记录了哪些主体拥有对该客体的哪些权限。每个客体（如一个仿真项目文件夹、一份分析报告）都维护一个独立的 ACL。
3.2.1 ACL 数据结构
ACL 在工程平台后端通常以键值对或关系表的形式存储。以下是一个典型的 ACL 条目结构：
| 字段 | 类型 | 说明 | 示例值 |
|---|---|---|---|
| object_id | UUID | 被保护客体的唯一标识 | proj-2024-001 |
| subject_id | UUID | 主体（用户或用户组）标识 | user-zhangwei |
| permissions | Bitmask | 权限位掩码（R=1, W=2, X=4, G=8） | 7（R+W+X） |
| grantor | UUID | 授权者（权限来源） | user-lixia |
| created_at | Timestamp | 授权时间 | 2024-03-15 10:30:00 |
3.2.2 ACL 权限验证流程
当用户尝试访问工程平台中的某个资源时，权限验证模块按以下步骤执行：
- 获取客体 ACL：根据请求的
object_id从数据库或缓存中加载该客体的 ACL 列表。 - 匹配主体：遍历 ACL 条目，查找与当前用户 ID 或用户所属组 ID 匹配的条目。
- 权限检查：对匹配到的条目，检查其
permissions位掩码是否包含请求的操作（如写入操作需检查 W 位）。 - 继承检查：如果客体位于目录树中，且自身 ACL 未匹配，则向上递归检查父目录的 ACL（平台可选配置）。
- 返回结果：允许或拒绝访问，并记录审计日志。
工程实践建议：在 ACL 实现中，建议使用位掩码（Bitmask）而非字符串列表来存储权限。位掩码支持高效的按位与运算，单次 CPU 指令即可完成权限检查，在工程平台高频访问场景下性能优势明显。
3.3 在工程分析平台中的优缺点
DAC/ACL 模型在工程分析平台中应用广泛，但其适用性取决于平台的规模和管控要求。以下从工程实践角度进行对比分析：
| 维度 | 优点 | 缺点 |
|---|---|---|
| 灵活性 | 资源所有者可自主、细粒度地控制权限，适合跨团队协作场景。例如，仿真工程师可临时将模型权限授予外部顾问。 | 权限分散在个体手中，缺乏统一管控，容易形成权限碎片化。离职员工的资源可能成为孤儿数据。 |
| 易用性 | 用户理解成本低，符合“我的数据我做主”的直觉。工程人员无需学习复杂的策略语言。 | 当客体数量庞大（如数万个仿真文件）时，ACL 维护成本急剧上升，管理开销不可忽视。 |
| 安全性 | 支持最小权限原则的落地，所有者可以精确控制每个用户的访问级别。 | 权限提升漏洞风险较高。恶意用户可能通过社会工程学获取授权，进而横向扩散权限。 |
| 性能 | 位掩码 ACL 检查时间复杂度为 O(1)，适合高频读取场景（如实时查看仿真结果）。 | ACL 列表过长时（如一个项目有 500+ 授权用户），存储和缓存压力增大，影响写入性能。 |
| 审计 | ACL 条目天然记录了授权关系，可追溯“谁授予了谁什么权限”。 | 缺乏对权限使用过程的审计，只能看到静态授权，无法感知权限是否被滥用。 |
工程平台避坑指南：
- 避免纯 DAC 模型：在大型工程分析平台中，不建议单独使用 DAC。建议采用 DAC + RBAC 混合模型，由 DAC 处理个人资源的细粒度授权，由 RBAC 处理角色级批量授权。
- 警惕 ACL 膨胀：定期清理无效 ACL 条目（如离职员工、过期项目），建议设置 ACL 条目数上限（如每个客体不超过 200 条）。
- 权限传递控制：默认关闭“授权传递”能力，仅允许所有者授权，防止权限无限扩散。
3.4 工程平台中的典型应用场景
在工程分析平台中，DAC/ACL 最适合以下场景：
- 个人工作区：工程师个人创建的仿真草稿、临时分析脚本，仅本人可见，可自主分享给协作者。
- 项目级资源共享：项目负责人创建的项目文件夹，通过 ACL 将“读取”权限授予项目成员，“写入”权限授予核心贡献者。
- 外部协作：与供应商或客户共享特定分析报告时，使用 ACL 设置临时访问权限和过期时间。
- 审批流程中的临时授权：在模型评审阶段，评审人通过 ACL 获得临时“读取”权限，评审结束后自动回收。
关键指标参考：
- ACL 条目平均长度：中小型平台建议控制在 10~50 条/客体，大型平台建议不超过 200 条。
- 权限验证延迟：基于位掩码的 ACL 检查应在 1ms 内完成（含缓存命中）。
- ACL 存储方案：推荐使用 Redis 缓存热点 ACL，MySQL/PostgreSQL 持久化存储全量 ACL。