一、访问控制基础：从入门到实战

各位同学好，我是老张。今天咱们聊聊访问控制——这个听起来很基础、但实际坑特别多的领域。

先问个问题：你每天登录系统、点开文件、执行命令，背后是谁在决定「你能做什么」？答案就是访问控制。说白了，它就是一套规则，告诉系统「谁」能对「什么」做「哪些事」。

1.1 什么是访问控制

访问控制，英文叫 Access Control。它不是某个具体技术，而是一套安全机制。我习惯把它理解为「门禁系统」——只不过这个门禁管的是数据、接口、服务器，而不是物理房间。

举个例子：你公司的财务系统，普通员工只能看自己的工资条，财务主管能修改数据，CEO 能看全公司报表。这就是访问控制在起作用。

1.2 访问控制三要素

搞懂访问控制，先记住三个词：主体、客体、操作。我在项目中见过太多人把这仨搞混，结果策略配得一塌糊涂。

要素	英文	定义	实际例子
主体	Subject	发起访问的实体	用户、进程、API 调用方
客体	Object	被访问的资源	文件、数据库表、网络端口
操作	Operation	主体对客体执行的动作	读、写、执行、删除

我记得有一次帮客户排查权限问题，他们配了上百条策略，结果发现「主体」和「客体」写反了——把用户当资源、把文件当操作者。嗯，这种低级错误其实挺常见的。

1.3 访问控制模型概述

模型这东西，说白了就是「套路」。不同场景用不同套路。我这些年接触过的模型主要有四种：DAC、MAC、RBAC、ABAC。下面逐个拆解。

1.3.1 DAC（自主访问控制）

DAC 是最早的模型，也是 Linux 文件权限的基础。它的核心思想是：资源的主人说了算。

• 谁创建文件，谁就能决定谁能访问它
• 典型实现：Linux 的 rwx 权限、Windows 的 NTFS 权限
• 优点：灵活、简单
• 缺点：权限容易扩散，难以集中管理

我曾经在一个创业公司看到，员工离职后他的文件还留在共享目录里，因为每个文件都是他自己设的权限，管理员根本管不过来。这就是 DAC 的典型问题。

1.3.2 MAC（强制访问控制）

MAC 跟 DAC 正好相反——系统说了算，用户不能改。它给每个主体和客体都打上安全标签，系统根据标签决定能否访问。

• 典型实现：SELinux、AppArmor、军事系统的多级安全
• 优点：安全性高，用户无法绕过
• 缺点：配置复杂，运维成本高

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

RBAC 是目前企业用得最多的模型。它的思路是：把权限打包成角色，再把角色分配给用户。

你想想看，如果每个员工都要单独配权限，1000 人的公司得配到猴年马月？RBAC 的做法是：先定义「财务主管」「开发工程师」「运维管理员」这些角色，然后把角色挂到人身上。

角色	权限集合	适用人员
运维管理员	服务器重启、日志查看、配置修改	运维团队
开发工程师	代码提交、测试环境部署	开发团队
审计员	只读访问所有日志	安全团队

我个人的习惯是：新项目优先用 RBAC。它够用、好理解、工具链成熟。但要注意——角色不能太多，超过 50 个角色就该考虑分层了。

1.3.4 ABAC（基于属性的访问控制）

ABAC 是更灵活的模型。它不看「你是谁」，而是看「你是什么样的人、在什么环境、用什么设备」。说白了，就是根据属性组合做决策。

举个例子：

• 主体属性：部门=财务、职级=经理、位置=内网
• 客体属性：敏感度=高、所属部门=财务
• 环境属性：时间=工作时间、设备=公司电脑

策略可以写成：「如果主体部门=财务 且 客体敏感度=高 且 时间=工作时间，则允许读取」。

1.4 四种模型对比

为了方便你选型，我整理了一张对比表：

维度	DAC	MAC	RBAC	ABAC
控制粒度	粗	中	中	细
管理复杂度	低	高	中	高
灵活性	高	低	中	高
安全性	低	高	中	高
典型场景	个人文件共享	军事、政府系统	企业应用	云平台、微服务

1.5 知识体系总览

下面这张图把本章的核心内容串起来了。我建议你保存下来，后面学自动化配置时随时回来对照。

1.6 本章小结

这一章我们走了一遍访问控制的基础。记住三要素（主体、客体、操作）是核心，四种模型各有适用场景。我个人建议：

• 新手先吃透 RBAC，它最实用
• 安全敏感场景考虑 MAC
• 需要灵活策略时上 ABAC
• DAC 只用在个人环境或小团队