📚 课程目录第4章访问控制模型入门

访问控制模型入门：DAC、MAC、RBAC

做权限系统，绕不开三个老牌模型——DAC、MAC、RBAC。你可能会问：都2025年了，还有必要学这些几十年前的东西吗？说实话，我当年也有这个疑问。直到在一次军工项目中，我发现客户对数据分级的要求完全就是MAC的定义；另一个电商项目里，运营团队天天改权限表，我被迫重构了一版RBAC才收场。说白了，这些模型不是古董，而是解决问题的工具箱。

1. 自主访问控制（DAC）

DAC是“谁说了算”的模型——资源所有者自己决定谁能访问。你创了个文件夹，就能给张三读、给李四写。听起来很自由吧？我在项目里见过最典型的DAC实现就是Linux的文件权限：chmod 755，所有者想怎么分就怎么分。但问题也出在这里——权限可以传递。比如你把文档共享给团队，他们又顺手转发给了外部顾问，这时候你根本控制不了。

个人经验：我曾在一个内部协作平台里禁用了DAC的权限传递特性，只允许一级授权。结果用户投诉说“不能转发给同事，流程走不动”。后来加了个“代理授权”开关，才平衡了安全与效率。

DAC的特点我列了个表，方便对比：

维度	DAC 表现
控制者	资源所有者
灵活性	高，自由分配权限
风险点	权限扩散、难以审计
适用场景	小团队、个人文件共享

避坑指南：我曾经在一个SaaS项目中误用DAC管理租户权限，结果租户A能看到租户B的数据。原因就是DAC的“所有者授权”特性没做隔离。记住，多租户场景下DAC要配合容器化隔离使用。

2. 强制访问控制（MAC）

MAC和DAC正好相反——用户说了不算，系统说了算。系统给每个主体（用户、进程）和客体（文件、数据）打上安全标签，比如“绝密”“机密”“公开”。标签是全局的，不可更改。你想想看，这就像核电站的门禁卡，就算你是一号领导，没有对应的级别也刷不开反应堆区域。我在政府部门做过一个数据分级项目，就是用MAC来实现“密级不低于查看者”的强制规则。

实现MAC的关键数据结构很简单：

-- 主体安全标签表
CREATE TABLE subject_security (
    user_id INT,
    clearance_level INT   -- 1=公开, 2=内部, 3=秘密, 4=绝密
);

-- 客体安全标签表
CREATE TABLE object_security (
    object_id INT,
    classification INT     -- 同上，但决定可读性
);

判断逻辑就是：用户只能读取分类级别 ≤ 自己密级的数据，写入时必须 ≥ 客体级别。嗯，这就是“不上读、不下写”原则。为什么这么严格？因为你不能把绝密信息写到公开目录里。

  关键认知：MAC是安全策略的“天花板”，它不依赖用户的善意。如果你的系统要处理政府机密或金融核心数据，MAC几乎是唯一选择。

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

RBAC是目前最通用的模型，说白了就是“职位决定权限”。你不用给每个员工单独配权限，只要定义几个角色：管理员、编辑、访客，再把用户挂到角色下面。权限系统会自动继承。我在电商后台做过RBAC设计——运营角色有商品上架权限，客服角色只有查看订单权限，财务角色能看到结算数据。角色多了怎么办？用角色分层+职责分离。

一个经典的RBAC表结构：

-- 角色表
CREATE TABLE role (
    role_id INT PRIMARY KEY,
    role_name VARCHAR(50)
);

-- 用户-角色关联
CREATE TABLE user_role (
    user_id INT,
    role_id INT
);

-- 角色-权限关联
CREATE TABLE role_permission (
    role_id INT,
    permission_code VARCHAR(50)
);

RBAC最大的好处是“易管理”。员工离职了，移出角色就行，不用逐个收回权限。但要注意一个陷阱：角色爆炸。我见过一个系统定义了200多个角色，每个角色只有一两项权限差别，维护成本直线上升。这时候就该用RBAC的进阶版——引入权限分组或属性约束。

我的做法：为每个业务域（订单、用户、商品）创建独立的角色组，再通过“角色继承”减少冗余。比如“高级运营”继承“运营”的所有权限，再加一条特殊权限。

三种模型怎么选？

我直接给一个决策表，不废话：

需求场景	推荐模型	说明
个人文件共享	DAC	简单灵活，无需中央管理
多级安全（国防、金融）	MAC	强制策略，标签不可篡改
企业级应用（OA、ERP）	RBAC	角色清晰，权限变更成本低
混合需求	RBAC + MAC 组合	角色控制基本权限，MAC约束敏感数据

  一个教训：我曾在一个创业项目中只用了RBAC，结果财务和研发共用一个“高级管理员”角色——仅仅因为懒得新定义。数据泄露后花了三周重建权限体系。记住：没有银弹，根据威胁模型选模型，必要时组合使用。

三种模型的核心区别就在这里了。DAC把信任交给用户，MAC把信任交给系统，RBAC把信任交给角色设计。你想想看，你现在的系统里，权限是怎么控制的？是不是还在用最原始的 if-else 硬编码？如果是，别急，后面我们会讲怎么把DAC/MAC/RBAC落地到代码里。现在先把概念吃透，踩坑时少走弯路。