4. 访问控制模型

说到数据保护，访问控制是绕不开的核心。说白了，就是搞清楚一个问题：谁能碰什么数据，在什么条件下可以碰。

我在项目里见过太多因为访问控制没做好而翻车的情况。有人把生产库的读写权限直接给了全部门，有人给实习生配了管理员账号。嗯，这些事后都成了安全审计的重灾区。

今天咱们就把四种主流的访问控制模型掰开揉碎了聊。DAC、MAC、RBAC、ABAC，一个一个来。

4.1 DAC - 自主访问控制

DAC 是最早出现的模型，也是 Linux/Unix 文件权限的基础。

核心逻辑：资源的所有者说了算。你创建了一个文件，你就可以决定谁能读、谁能写、谁能执行。这就是“自主”的含义——权限由用户自由支配。

DAC 的优点就是灵活。但正因为太灵活，也容易出问题。我记得有一次做数据泄露调查，发现一个核心数据库的备份文件被某个工程师设置了 777 权限（任何人都可以读写执行）。问起来，人家说“方便同事排查问题”。结果就是任何人都能下载这份备份。

4.2 MAC - 强制访问控制

MAC 和 DAC 正好相反。资源的所有者说了不算，系统级的安全策略说了算。

核心逻辑：系统给每个主体（用户/进程）和每个客体（文件/数据）打一个安全标签。只有标签匹配，才能访问。你没办法自己修改安全级别，你也没办法把文件权限随意分配给其他人。

MAC 的代表是 SELinux 和 AppArmor。我在做政府项目的时候接触过 SELinux，那个配置的复杂度，说句实话，第一次接触真的头皮发麻。

对比维度	DAC	MAC
权限决策者	资源所有者	系统安全策略
灵活性	高	低
安全性	低（容易泄露）	高（难以绕过）
典型场景	个人电脑、小团队	军方、政府、金融核心系统
管理成本	低	高

4.3 RBAC - 基于角色的访问控制

RBAC 是目前企业级应用最广泛的模型。为什么？因为它解决了权限管理的规模化问题。你想想看，如果公司有 5000 人，你给每个人单独分配权限，那不得累死？

核心逻辑：不直接给用户分配权限，而是给角色分配权限，再把角色分配给用户。

举个例子：

• 角色“财务审核员” → 拥有“查看财务报表”和“提交审核报告”的权限
• 用户张三 → 被分配到“财务审核员”角色
• 张三自然就拥有了上面的权限

这样做的好处很明显：当员工离职或转岗时，只需要调整他/她的角色就行，不用去翻几百条权限记录。我曾经在一个项目中优化权限体系，从 DAC 迁移到了 RBAC，光这一项就把年度安全审计的工时从两周压缩到了两天。

来个简单的 RBAC 权限校验伪代码：

// RBAC 权限校验示例
class AccessController {
    // 用户 → 角色 映射
    private userRoles = {
        'alice': ['admin', 'editor'],
        'bob': ['viewer']
    }
    
    // 角色 → 权限 映射
    private rolePermissions = {
        'admin': ['read', 'write', 'delete'],
        'editor': ['read', 'write'],
        'viewer': ['read']
    }
    
    function checkAccess(user, action) {
        roles = this.userRoles[user]
        for (role in roles) {
            if (this.rolePermissions[role].includes(action)) {
                return true
            }
        }
        return false
    }
}

4.4 ABAC - 基于属性的访问控制

ABAC 是这四种模型里最灵活、粒度最细的。它的核心思想是：权限决策不只看“你是谁”，还要看“你在哪”、“用什么设备”、“当前时间是多少”、“数据敏感级别是什么”等等。

核心逻辑：把权限决策要素抽象成属性进行匹配。

• 主体属性：用户 ID、部门、职级、安全等级
• 客体属性：文件类型、敏感级别、所属项目
• 环境属性：访问时间、IP 地址、设备类型
• 操作属性：读取、写入、删除、导出

比如一条 ABAC 策略可以写成：

// ABAC 策略示例（伪代码）
策略：仅允许高级工程师在办公网络下，
      访问敏感级别为“机密”且属于“项目X”的文档，
      但禁止下载或打印。

条件：
  user.department == 'engineering'
  user.level >= 'senior'
  network.ip_range == 'office_vpn'
  doc.sensitivity == 'confidential'
  doc.project == 'project_x'
  action not in ['download', 'print']

我在做 SaaS 平台的数据隔离方案时就用到了 ABAC。不同租户之间不仅要隔离，还要允许交叉授权（比如某个客户授权给供应商的员工查看部分数据）。这种情况下 RBAC 很难满足，但 ABAC 可以通过“租户 ID + 用户角色 + 数据范围”的组合策略轻松搞定。

4.5 四种模型对比总结

模型	核心理念	灵活性	管理复杂度	适用场景
DAC	所有者决定权限	高	低	个人电脑、小团队文件共享
MAC	系统级标签强制控制	低	高	高安全等级环境（军事、金融核心）
RBAC	通过角色分配权限	中	中	企业级应用（ERP、CRM）
ABAC	基于属性集动态决策	极高	极高	复杂权限场景（多租户、微服务）

下面这张图比较直观地展示了四种模型的关系和演进逻辑：

4.6 实战选择策略

模型理论讲完了，咱们聊聊怎么选。说实话，没有唯一的正确答案，但我有几点经验可以分享：

• 小团队（< 20人）：DAC + 简单的共享文件夹权限就够了。别搞复杂，管理成本比安全收益还高。
• 中型企业（20-500人）：RBAC 是最好的起点。把角色定义清楚，覆盖 80% 的场景，剩下的用例外策略处理。
• 大型企业/高安全场景：RBAC + MAC 组合。核心系统用 MAC 兜底，应用层用 RBAC 管理日常权限。
• 复杂多租户/微服务场景：直接上 ABAC。我最近在做的一个项目就是把 RBAC 升级到了 ABAC，因为客户的需求实在太复杂——同一个用户在不同项目里的权限都不同，甚至同一个文档在不同的时间段权限也不同。这种情况 RBAC 的角色根本定义不过来。