访问控制模型：DAC、MAC、RBAC、ABAC 模型对比与选型

聊到网关的访问控制，很多人第一反应就是「搞个权限表」。但实际落地时你会发现，光有权限表远远不够。我这些年参与过的安全网关项目，几乎每个都在访问控制模型上踩过坑。选错了模型，轻则权限混乱，重则直接成为攻击突破口。

今天咱们就把四种主流模型掰开揉碎讲清楚。DAC、MAC、RBAC、ABAC，它们各自解决什么问题？在网关场景下该怎么选？

1. DAC：自主访问控制

DAC 是最早出现的模型。它的核心思想很简单——谁创建，谁做主。文件的主人可以随意决定谁能读、谁能写。

我记得刚入行时做过一个内部文档系统，用的就是 DAC。每个用户上传文件后，可以手动勾选「允许张三查看」「允许李四编辑」。听起来很灵活对吧？但问题很快就来了——权限分散，无法统一管控。

• 优点：灵活，用户自主性强，实现简单
• 缺点：权限分散，容易泄露；无法集中审计；不适合企业级网关
• 网关场景：几乎不用。网关是守门员，不能让每个设备自己决定谁可以进门

2. MAC：强制访问控制

MAC 和 DAC 正好相反。它不信任任何人，所有权限由系统强制规定。每个主体（用户/进程）和客体（文件/资源）都被打上安全标签，只有标签匹配才能访问。

说白了，MAC 就是「系统说了算，用户别想改」。这在军方和政府机构中很常见，比如绝密、机密、秘密三级。

• 优点：安全性极高，无法绕过；适合高保密场景
• 缺点：僵化，缺乏灵活性；维护成本高；用户体验差
• 网关场景：适用于涉密网络或工业控制网关，但日常企业网关很少用

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

RBAC 是目前企业级系统中最主流的模型。它的核心是「角色」——把权限打包成角色，再把角色分配给用户。

举个例子：你不需要告诉网关「张三可以读日志、写配置、重启服务」，你只需要说「张三属于管理员角色」。管理员这个角色已经包含了所有权限。

我在做智慧园区网关时，用的就是 RBAC。设备管理员、运维人员、审计员、访客——四个角色覆盖了所有场景。权限清晰，审计方便。

• 优点：管理简单，权限与用户解耦；支持分层；易于审计
• 缺点：角色爆炸（角色一多就乱）；细粒度不够；静态绑定
• 网关场景：非常适合。大多数企业网关、API 网关都用 RBAC 做基础权限模型

4. ABAC：基于属性的访问控制

ABAC 是近年来最受关注的模型。它不再依赖固定的角色，而是根据属性动态计算权限。属性可以是：

• 主体属性：用户角色、部门、安全等级、地理位置
• 客体属性：资源类型、敏感级别、所属项目
• 环境属性：访问时间、网络 IP、设备状态、风险评分

你想想看，RBAC 只能回答「这个角色能不能做这个操作」，而 ABAC 可以回答「这个人在这个时间、这个地点、用这个设备，能不能做这个操作」。

我在做零信任网关时，ABAC 几乎是必选项。比如：

策略示例：
IF 用户.部门 = "研发" 
   AND 资源.项目 = "A" 
   AND 时间 BETWEEN "09:00" AND "18:00" 
   AND 设备.信任等级 >= 3
THEN 允许访问

• 优点：极度灵活；细粒度；支持动态上下文；适合零信任
• 缺点：策略复杂；性能开销大；需要策略引擎；调试困难
• 网关场景：零信任网关、IoT 网关、多云网关的首选

5. 四种模型对比

咱们直接上表格，一目了然：

维度	DAC	MAC	RBAC	ABAC
控制粒度	粗	中	中	细
灵活性	高	低	中	高
安全性	低	高	中	高
管理成本	低	高	中	高
动态能力	无	无	弱	强
网关适用性	不推荐	特殊场景	推荐	强烈推荐（零信任）

6. 网关场景下的选型建议

说了这么多，到底怎么选？我根据自己的项目经验，给出几条实操建议：

1. 传统企业网关：RBAC 打底，够用。别折腾。
2. 零信任网关：ABAC 是核心，必须上。但建议先做 RBAC 过渡。
3. 工业/涉密网关：MAC + RBAC 组合。MAC 保底，RBAC 提效。
4. IoT 设备网关：ABAC 优先。设备属性、环境属性变化快，RBAC 扛不住。
5. API 网关：RBAC + ABAC 混合。基础权限用 RBAC，敏感接口用 ABAC 做二次校验。

7. 四种模型的关系图

下面这张图帮你理清四种模型的核心逻辑和演进关系：

8. 总结一下

四种模型，各有各的脾气。DAC 太散，MAC 太死，RBAC 中庸，ABAC 灵活但复杂。网关场景下，我个人的经验是：

• 别迷信任何一种模型。现实项目永远是混合的。
• 从 RBAC 起步。它是最稳妥的中间态，进可攻退可守。
• ABAC 是未来方向。尤其是零信任和 IoT 场景，ABAC 几乎是必选项。
• 别忘了兜底。再好的模型，没有审计和熔断机制也是白搭。