3. 权限模型设计：DAC、MAC、RBAC

权限模型是什么？说白了，就是决定“谁能访问什么”的那套规则。我做SDK输出权限管理这些年，见过不少团队在这上面翻车。选错了模型，轻则权限混乱，重则数据泄露。

今天我带你把这三种主流模型——DAC、MAC、RBAC——彻底捋一遍。我会结合自己踩过的坑，告诉你每个模型什么时候用，什么时候千万别用。

3.1 自主访问控制（DAC）

DAC 是最直观的模型——谁拥有资源，谁说了算。就像你手机里那张照片，你想分享给谁就分享给谁。资源所有者可以自定义授权。

我有一个项目经历特别典型。当时做一个企业内部文档共享SDK，用了DAC。结果上线三个月，权限乱成一锅粥。员工A把文件夹权限设成了“所有人可编辑”，然后整个部门的人都能改他的方案。你想想看，这种雪崩式的权限扩散，多可怕。

特点一览：

• 控制者：资源所有者（用户）
• 灵活性：极高，可以随时授权/撤回
• 安全性：低，容易产生权限泛滥
• 典型场景：社交应用、个人云盘、团队协作工具

3.2 强制访问控制（MAC）

MAC 正好相反，它不依赖用户的主观判断。系统根据预定的安全标签（比如“机密”“秘密”“绝密”）强制控制流向。说白了，即使你拿到了别人的账号，也无法访问比你级别高的数据。

我曾经参与过一个政府项目SDK，对方要求用MAC。我当时心里还犯嘀咕：这玩意儿太死板了吧？后来发现确实有必要——在涉密系统里，你不能让一个小职员误操作把绝密文件共享出去。安全标签是写死在系统内核里的，用户根本改不了。

特点一览：

• 控制者：系统管理员/安全策略
• 灵活性：极低，用户无自主权
• 安全性：极高，难以被绕过
• 典型场景：军事系统、金融核心、医疗档案

3.3 基于角色的访问控制（RBAC）

RBAC 是我在SDK权限管理中最推荐的方案。它引入角色作为中间层，把权限分配给角色，再把角色分配给用户。你想想看，一个公司几百号人，如果每个人单独配置权限，累死人。但如果你定义了“管理员”“编辑者”“查看者”三个角色，再把人往里一塞，后续调整角色权限即可。

我之前做的一个企业级隐私共享SDK，就是用RBAC起家的。一开始只设了三个角色，后来业务扩展到了十几个角色，但核心逻辑没变。每次新功能上线，我只需要改角色的权限表，用户那边自动生效。维护成本低到令人感动。

下面是我常用的角色-权限映射表结构（简化版）：

角色	可读	可写	可共享	可审计
超级管理员	✅	✅	✅	✅
内容管理者	✅	✅	✅	❌
普通用户	✅	❌	✅（仅自己）	❌
审计员	✅（只读）	❌	❌	✅

3.4 三大模型对比

直观上怎么选？我习惯用这张对比表来帮团队做决策：

对比维度	DAC	MAC	RBAC
控制者	资源所有者	系统管理人员	角色管理员
灵活性	极高	极低	中高（可配置）
安全性	低	极高	中高
维护复杂度	低（但易失控）	高（策略多）	中等（角色定义清晰则简单）
典型应用	个人共享	涉密系统	企业级应用

总结一下我的选择逻辑：

• 用户自己管理自己的一亩三分地？ → DAC 够用，但要加防护网。
• 数据泄露会坐牢的那种？ → 别犹豫，上 MAC。
• 其他 90% 的通用场景？ → 闭眼选 RBAC，不会后悔。