ACL 模型详解：访问控制列表

ACL，全称 Access Control List，翻译过来就是「访问控制列表」。这玩意儿可以说是权限模型里最古老、最直观的一种了。我刚开始做安全设计那会儿，接触的第一个权限方案就是 ACL，说白了它就是个清单——谁对哪个资源能干什么事，全列在上面。

一句话定义：ACL 是一个附着在资源上的列表，里面记录了哪些主体（用户/进程）对该资源拥有哪些操作权限。

ACL 的核心组成

一个标准的 ACL 条目通常包含三个要素：

  • 主体（Subject）：谁要访问？可以是用户 ID、用户组、角色或进程。
  • 资源（Resource）：要访问什么？文件、目录、数据库记录、网络端口都算。
  • 操作（Operation）：允许做什么？读、写、执行、删除、修改属性等。

举个例子，在 Linux 文件系统里，一个文件的 ACL 条目可能是这样：

user:zhangsan:rwx
group:developers:r-x
other:---

嗯，这里要注意，ACL 的粒度可以很细。我在项目中遇到过一种情况：业务方要求「A 部门的张三能读财务目录，但不能看里面的工资表」。这种需求用传统 Unix 的 owner/group/other 三位模型根本搞不定，但 ACL 可以——给工资表单独加一条 deny 规则就行。

ACL 的工作原理

ACL 的工作流程其实不复杂，我画了张图帮你理解：

ACL 访问控制流程图 主体（Subject） 访问请求 ACL 检查引擎 遍历 ACL 条目，匹配主体+资源+操作 匹配到 允许规则？ ✅ 允许访问 返回数据 ❌ 拒绝访问 返回错误 检查顺序：先匹配显式拒绝 → 显式允许 → 默认拒绝（白名单原则）

流程其实就三步：

  1. 发起请求：主体带着身份信息和操作意图来找资源。
  2. 遍历 ACL：系统从资源上挂着的 ACL 列表里，从上到下逐条匹配。
  3. 裁决结果：匹配到第一条规则就停止，按规则放行或拒绝。如果整个列表都没匹配上，默认拒绝。

避坑指南：我曾经在一个金融项目中踩过坑——ACL 规则顺序写反了。先写了一条允许所有人读，后面才写拒绝某个人。结果拒绝规则永远不生效，因为匹配到第一条就停了。记住：ACL 是顺序匹配、首条生效。拒绝规则一定要放在允许规则前面。

ACL 的优缺点分析

任何模型都有两面性，ACL 也不例外。我用了十几年 ACL，总结下来就是：

维度 优点 缺点
理解成本 概念直观，非技术人员也能看懂「谁对什么能做什么」 列表一长就眼花，维护起来费劲
粒度控制 可以精确到单个用户对单个资源的权限 用户一多，ACL 条目爆炸式增长
性能 小规模场景下查询效率极高 资源数×用户数=百万级条目时，遍历性能急剧下降
扩展性 支持 deny 规则，能实现黑名单 权限变更时需要逐个修改资源上的 ACL，批量操作困难
审计 每个资源的权限清单清晰可查 跨资源审计时，需要遍历所有资源的 ACL，效率低

警告：ACL 最怕「权限蔓延」。我见过一个系统上线两年后，某个目录的 ACL 列表长达 300 多条，里面有一半是离职员工的账号。没人敢删，因为不知道删了会不会影响业务。所以用 ACL 一定要配合定期审计，把僵尸条目清理掉。

ACL 在文件系统中的应用

ACL 最经典的应用场景就是文件系统。Linux 从 2.6 内核开始原生支持 ACL，Windows 的 NTFS 更是从设计之初就把 ACL 作为核心安全机制。

Linux 文件系统 ACL

Linux 上用 setfacl 和 getfacl 命令操作 ACL。我习惯这么用：

# 给用户 zhangsan 设置对 /data/project 的读写执行权限
setfacl -m u:zhangsan:rwx /data/project

# 给组 developers 设置读执行权限
setfacl -m g:developers:rx /data/project

# 查看 ACL
getfacl /data/project

# 输出示例：
# # file: /data/project
# # owner: root
# # group: root
# user::rwx
# user:zhangsan:rwx
# group::r-x
# group:developers:r-x
# mask::rwx
# other::---

这里有个细节——mask。mask 是 ACL 的「上限阀门」，它限制了所有命名用户和命名组的最大权限。比如 mask 是 r-x，就算你给 zhangsan 设了 rwx，实际生效的也只有 r-x。我刚开始学 ACL 时就被 mask 坑过，权限设了半天就是不生效，后来才发现是 mask 在作怪。

Windows NTFS ACL

Windows 的 ACL 比 Linux 更复杂，它支持「继承」和「传播」。比如你给一个文件夹设了 ACL，子文件夹和文件默认会继承父级的权限设置。这在企业文件服务器上非常实用——你只需要配好顶层目录，下面自动继承。

Windows ACL 的权限类型也更丰富：

  • 完全控制：所有操作，包括修改权限和删除
  • 修改：读写删改，但不能改权限
  • 读取和执行：看文件、运行程序
  • 列出文件夹内容：只看目录结构
  • 读取：只能看文件内容
  • 写入：只能写内容，不能读

实战经验：我在帮一家企业做文件服务器迁移时，发现他们的 NTFS ACL 继承链长达 7 层。最顶层是「所有人可读」，中间某层加了「财务部可写」，最底层又加了「张三拒绝删除」。这种多层继承的 ACL 排查起来非常痛苦。我的建议是：继承层级控制在 3 层以内，超过就考虑用组策略或者单独配。

ACL 在文件系统中的典型问题

用 ACL 管文件权限，有几个坑我几乎每次培训都会提：

  • 权限叠加混乱：一个用户同时属于多个组，每个组有不同的 ACL 条目，最终权限取并集还是交集？Linux 取并集（任一允许即允许），Windows 取拒绝优先（有 deny 就 deny）。
  • 继承导致的权限膨胀：子目录越来越多，ACL 条目越积越厚。我曾经清理过一个目录，里面 80% 的 ACL 条目都是继承来的冗余规则。
  • 跨平台兼容：Linux 的 ACL 和 Windows 的 ACL 不互通。用 Samba 做文件共享时，两边 ACL 的映射经常出问题。

说白了，ACL 适合小规模、权限变化不频繁的场景。一旦用户数超过 100、资源数超过 1000，你就该考虑 RBAC 或者 ABAC 了——那是后面几章的内容。

← 上一章 📖 返回目录 下一章 →