一、什么是访问控制模型？
访问控制模型是定义主体（用户、进程）对客体（文件、数据库、API）如何授予或拒绝访问权限的规则框架。在实际系统设计中，选择哪种模型直接影响安全性、可维护性和灵活性。下面我们逐一拆解四种经典模型，并结合典型场景说明如何应用。
二、自主访问控制（DAC）
核心逻辑
DAC（Discretionary Access Control）允许客体所有者自主决定谁可以访问其资源。例如在Linux文件系统中，文件所有者可通过chmod命令设置读、写、执行权限给其他用户或组。
操作步骤
- 创建文件或资源后，所有者使用
chmod或chown命令设定权限。 - 指定特定用户或组（如
chmod u+rwx,g+rx,o-rwx file.txt）。 - 其他用户根据权限访问，所有者可随时修改。
典型场景
- 个人电脑上的文件共享。
- 小团队协作中临时开放某个文档的编辑权。
限制条件与误区
- 权限扩散风险：用户可能无意中将资源开放给所有人，造成数据泄露。
- 无法集中管理：管理员缺乏全局视图，审计困难。
- 常见误区：认为DAC等同于“任意授予”，实际还需依赖操作系统权限位。
三、强制访问控制（MAC）
核心逻辑
MAC（Mandatory Access Control）由系统强制实施安全标签（如绝密、机密、公开），主体和客体都有标签，只有标签满足预定义规则（如“向下读、向上写”）才允许访问。典型代表是SELinux和Biba模型。
判断依据
系统检查安全等级：主体敏感级≥客体敏感级时允许读；主体敏感级≤客体敏感级时允许写（Bell-LaPadula模型用于保密性）。
典型场景
- 军事或政府部门处理分级文档。
- 需要防止数据泄露的高安全环境。
限制条件与误区
- 配置复杂：需要为每个资源定义标签，维护成本高。
- 灵活性差：不适合快速变化的业务需求。
- 常见误区：MAC可以完全阻止非法信息流，但实际仍可能通过隐蔽信道绕过。
四、基于角色的访问控制（RBAC）
核心逻辑
RBAC（Role-Based Access Control）将权限授予角色，用户通过分配角色获得权限。角色之间支持继承和层级，简化管理。例如在OA系统中，“经理”角色可审批报销，“员工”角色只能提交。
实施步骤
- 梳理业务角色（如管理员、操作员、审计员）。
- 定义每个角色所需的权限集合。
- 将用户关联到对应角色（可多角色）。
- 通过角色-权限映射实现访问控制。
典型场景
- 企业ERP、CRM系统。
- 云平台多租户权限管理（如AWS IAM）。
限制条件与误区
- 角色爆炸：当权限粒度细且组合多时，角色数量激增。
- 动态权限不足：无法根据上下文（如时间、地点）动态调整。
- 常见误区：RBAC只能用于中大型组织，实际上小型系统也可使用简化版（如仅“管理员”和“普通用户”）。
五、基于属性的访问控制（ABAC）
核心逻辑
ABAC（Attribute-Based Access Control）通过评估主体属性、客体属性、环境条件和操作属性的组合来决策。策略通常用规则引擎（如XACML）实现。
判断依据
例如规则：“允许员工在上班时间（9:00-18:00）通过公司内网访问项目文档，但禁止下载敏感文件”。决策引擎检查属性：主体部门=开发、位置=公司IP段、时间=10:00、操作=读取、客体密级=内部。
典型场景
- 云服务中的细粒度授权（如AWS S3桶策略）。
- 物联网设备中根据传感器状态控制访问。
限制条件与误区
- 策略管理复杂：属性维度和规则数量增长可能导致性能下降。
- 需统一属性目录：属性来源不一致（如HR系统、AD）时整合困难。
- 常见误区：ABAC可完全取代RBAC，实际上两者可结合使用（如先RBAC定角色，再ABAC做细粒度过滤）。
六、对比总结与选型建议
模型安全性管理成本灵活性适用场景DAC低低高个人、小团队MAC高高低军事、核心数据RBAC中中中企业信息系统ABAC高高高大型、分布式、动态环境
实际项目中，许多系统会混合使用多种模型。例如，前端业务用RBAC控制菜单权限，后端API用ABAC根据请求属性做二次校验。关键是根据业务对安全粒度和运维成本的权衡，避免过度设计。
参考资料
延伸阅读