搞网络、管服务器的人对“ACL”这三个字母绝对不会陌生它全称是 Access Control List中文一般叫访问控制列表。说白了ACL 就是一套规则清单回答一个特别基础但特别要命的问题某个访问者到底能不能对某个资源做某个操作。我最早接触 ACL 是在配置路由器的时候后来发现 Linux 文件权限、云存储桶策略、接口鉴权全都在用同一个思想。这篇文章就把“是什么、为什么用、怎么配、坑在哪”一次性讲透给正在搞网络或系统运维的读者一个能直接上手的参考。很多人把 ACL 想复杂了其实它就是一张“门禁表”核心只有三件事谁、对什么、做什么。你只要把这个框架装进脑子里后面看什么设备的配置、看什么系统的权限模型都能快速套进去。接下来我按从概念到实操的顺序拆开讲。1. ACL 是什么一张带条件的门禁名单1.1 ACL 的核心定义与规则三要素我习惯把 ACL 理解成小区门口保安手里那张登记表。表上不是乱写一堆名字而是每一条都很明确哪些人能进、哪些人不能进、什么时间段能进、能进到哪一栋楼。网络设备、操作系统里的 ACL本质上就是这张表。一条 ACL 规则通常包含三个要素主体Who。谁要访问。在网络场景里是源 IP、源网段在文件场景里是用户名、用户组。客体What。要访问什么。网络里是目的 IP、目的端口文件系统里是某个目录或文件。动作Allow / Deny。允许还是拒绝。有些规则还会加上“条件”维度比如协议类型、时间范围、MAC 地址。比如一条典型的网络 ACL 规则允许 192.168.10.0/24 网段的设备通过 HTTPS443端口访问某台核心服务器其余统统丢弃。这就是主体、客体、动作三要素完整结合的例子。文件系统里的 ACL 也一个道理允许某个同事对 /var/log/app.log 有读写权限拒绝其他人写入。理解到这个层面ACL 的概念你就拿下了。1.2 ACL、防火墙、RBAC三兄弟别搞混我遇到过不少刚入门的朋友把 ACL 和防火墙规则、RBAC 权限模型搞混。它们确实有关系但角度不同。防火墙是一种安全设备它会把安全策略翻译成规则去过滤流量。很多防火墙规则就是 ACL 的一种工程化实现。只不过防火墙还具备状态检测、应用层识别等进阶能力ACL 相对更“裸”一些通常工作在包过滤层面。RBAC基于角色的访问控制是一种权限管理模型把权限先打包成“角色”再把角色分配给用户。它解决的是“如何管理一堆人的权限”的问题比如一个公司里设管理员、运营、审计三种角色。ABAC基于属性的访问控制则更进一步权限判断依据不只是身份还包括时间、地点、设备状态等动态属性。ACL 本身更接近“直接列出谁可以干什么”的权限表。它和 RBAC 的区别在于ACL 是站在资源角度写的规则RBAC 是站在组织角色角度设计的模型。实际系统里经常混合用底层还是 ACL 那一套规则在生效。1.3 三个最常见的 ACL 存在位置搞清楚概念后你得知道去哪儿碰它。我整理了一下日常工作里 ACL 主要出现在三个层面网络设备。路由器、交换机上配标准 ACL 或扩展 ACL用来做访问控制、流量过滤、安全隔离。这是最经典的应用场景。操作系统文件系统。Linux 上的 POSIX ACL、Windows 上的 NTFS ACL用来控制文件/目录的读、写、执行权限。标准 chmod 权限不够用的时候ACL 能补上“单独给某个用户授权”的能力。对象存储、API 网关、消息队列等云服务。存储桶策略、对象级 ACL、接口鉴权策略很多底层都是 ACL 思想。我自己的建议是刚入门可以从网络 ACL 开始学因为网络 ACL 规则简单、逻辑直白、配置后立刻能看到效果但文件系统 ACL 更贴近日常开发维护也值得尽早掌握。两者都吃透后再看云平台那一堆权限策略就轻松多了。2. 用 ACL 到底图什么目的拆解2.1 最核心的目的让最小权限原则落地做运维或者搞安全的都知道“最小权限”这四个字。意思是任何用户、任何组件、任何外部访问都只给完成任务所必需的最小权限多了不给。没有 ACL 的时候权限管理很粗放经常出现“所有人同一个权限”的情况。比如某个内部系统所有同事都能登录服务器都能看配置文件都能改代码目录那一旦有人误操作或者账号泄露风险就完全失控了。上了 ACL 之后你就可以针对具体用户、具体网段、具体服务端口把权限收窄到正好够用。我在实际配置中常用的做法是先把“允许列表”写清楚明确哪个用户组能访问哪台服务器的哪个端口剩下的访问全部拒绝。这样即使某个测试账号被扫到了攻击者也拿不到更多入口。最小权限不是嘴上说说ACL 是它落地的最直接工具。2.2 第二个目的流量管控与边界防护网络层的 ACL 还有一个重要职责就是做流量管控。你可以理解成在大楼门口设了安检闸机哪些人能进、从哪个门进、去哪个楼层都要按规则走。举个例子某个公司只允许办公区域的网段通过 SSH 访问核心跳板机其他来源一律丢弃。用 ACL 实现这个策略配置并不复杂但效果立竿见影——扫描器扫不到、暴力破解的来源被拒之门外、内部横向移动的路径也被砍掉一截。配置边界 ACL 时我一般不搞“先全部放行再加几条 deny”的方式。默认全放行的策略你加的那几条 deny 就像大海里扔石头看得见但拦不住所有东西。正确的思路是“显式放行 末尾默认拒绝”这才是 ACL 该有的姿态。网络 ACL 越靠外层的设备和接口规则越要精简因为每一条规则都会消耗设备 CPU 的处理时间规则越多转发性能越受影响。2.3 第三个目的满足审计要求留下“可解释的记录”刚工作那会儿我比较烦写规则觉得直接能通就行。后来有一次线上故障排查系统被某个来源的流量打挂一堆人查来查去最后是靠 ACL 规则顺序和命中计数锁定了异常来源。从那之后我就明白ACL 不只是“通不通”的问题它更是一条可以解释的记录。从合规角度讲很多企业的安全审计框架都要求“访问可控、操作可查”。ACL 规则本身可以导出、可以备份、可以差异比对。定期评审 ACL能发现不少潜在问题有没有“半年没人用的放行规则”有没有规则已经和业务不符这些都是隐性债务攒多了迟早出事。而且成体系的 ACL 还有一个好处方便协作。规则有注释、有分段半年后新来的同事看你的配置也能快速知道每条规则是干嘛的。这一点我后面细讲。3. 从网络到服务器到云ACL 实操全流程3.1 网络设备上的标准 ACL 与扩展 ACL 怎么配网络 ACL 最常见的是标准 ACL 和扩展 ACL。不同厂商设备的配置命令有差异但思想是通用的下面我用一种在业界很主流的风格来演示这类语法在很多设备上都能找到影子。你在实际环境里以手上的设备文档为准即可。标准 ACL 只看源地址不能区分协议和端口适合做简单的网段隔离。一条标准的规则长这样access-list 10 permit 192.168.10.0 0.0.0.255 access-list 10 deny any这里有个新手容易懵的地方为什么子网写成0.0.0.255这不是子网掩码而是通配符掩码。0 表示必须匹配255 表示可以忽略。192.168.10.0 0.0.0.255的意思就是匹配前 24 位固定、后 8 位任意也就是 192.168.10.0/24 网段。把它和 255.255.255.0 当成一回事就错了两者在 ACL 里含义完全不同。扩展 ACL 就强大多了能基于源 IP、目的 IP、协议、源端口、目的端口做精细控制。比如这句access-list 100 permit tcp 192.168.10.0 0.0.0.255 host 10.20.30.40 eq 443 access-list 100 deny ip any any意思是允许 192.168.10.0/24 网段访问主机 10.20.30.40 的 443 端口HTTPS其他 IP 流量全部丢弃。重点在于大多数 ACL 的最后都藏着一条隐式规则——deny any any也就是“默认拒绝”。你只写了允许规则但没写deny any any设备也会帮你默默拒绝其余流量。很多初次配置的人以为没写 deny 就全放行结果业务断了一片折腾半天才发现是这个原因。配好规则之后还要把它“应用”到具体接口的入方向或出方向。我的经验是能放在入方向就放在入方向因为流量一进接口就被处理过滤效率更高也能减轻设备后续的处理压力。放错方向是另一个高频问题原因也很简单你没想清楚这条规则匹配的对象是从哪边进来的。3.2 Linux 服务器上用 setfacl 改文件权限照着做就行Linux 默认的权限模型是 所有者/所属组/其他人 三段式用chmod就能改。但有一种常见需求搞不定让某个特定用户对某个文件有读权限但它既不是文件所有者也不在所属组里。这时候就要上文件 ACL 了。大多数 Linux 发行版默认装好了 ACL 工具如果没有先装一下# Debian/Ubuntu 系 sudo apt install acl # CentOS/RHEL 系 sudo yum install acl查看一个文件的 ACL 权限用getfaclgetfacl /var/log/app.log给某个用户单独加权限用setfacl# 给用户 zhangsan 添加读写权限 sudo setfacl -m u:zhangsan:rw /var/log/app.log # 给 devteam 这个组添加只读权限 sudo setfacl -m g:devteam:r /var/log/app.log # 删除某条 ACL sudo setfacl -x u:zhangsan /var/log/app.log还有一类更实用的是默认 ACLdefault ACL它只能设置在目录上作用是该目录下新建的文件自动继承权限。这在团队共享目录里特别常用sudo setfacl -d -m u:zhangsan:rwx /data/share之后在 /data/share 里新建的文件zhangsan 就自动有相应权限了不用每次新建文件再手动授权。文件系统里配好 ACL 后用ls -l查看权限位后面会出现一个加号说明这个文件上有额外 ACL 规则。这里必须多说一句ACL 的权限不是简单做加法。如果你只是给某个人加读权限但他自己没有写权限最后的有效权限仍然是由“用户权限、ACL 权限、mask”共同决定的。mask 是什么它是所有命名用户和命名组的“权限天花板”。后面常见问题里我会专门讲这个坑。3.3 对象存储与云平台上的 ACL从桶策略到 API 鉴权到了云平台这一层ACL 概念又换了个马甲。你在对象存储服务里经常能看到三样东西存储桶策略Bucket Policy、对象 ACL、以及更上层的访问管理策略IAM Policy。很多人被这几层搞晕其实底层逻辑还是“主体-客体-动作-允许/拒绝”。对象 ACL粒度最细控制某个存储桶里某个对象的读、写、查看等权限。适合简单的公开读/私有写等固定场景。桶策略以 JSON 描述的一组规则可以指定某个网段、某个账号对某个前缀路径的限定操作。比如“只允许办公 IP 段访问这个桶”用桶策略写就很直接。IAM 策略更偏“角色”概念把权限分配给子账号、应用或角色适合企业多账号、多项目协作场景。我自己的选择经验是对象少、授权关系简单的时候直接用对象/桶 ACL 就行一旦牵涉多个团队、多个环境、频繁变动授权就去用 IAM 策略因为可维护性高很多。纯 ACL 一条条堆上去后面没人讲得清哪条该删哪条该留这种“配置债务”比欠代码债还烦。4. 常见问题与排查技巧实录4.1 网络 ACL 配置后没生效八成是这三个原因ACL 配了却没效果这种事我见过太多回了。排障时我一般按优先级查三件事规则顺序对不对。绝大多数 ACL 从上往下逐条匹配一旦命中就停止。如果你把一条“全部放行”写在前面后面再写“拒绝某 IP”就是空的。所以顺序非常重要先写精细规则再写兜底规则。通配符掩码有没有写反。0.0.0.255和255.255.255.0的含义完全不一样前者是匹配整个网段后者是匹配单个地址。配错后最常见表现是部分 IP 能通、部分不能通而且你一眼还看不出来。有没有应用到正确的接口方向。入方向和出方向搞反规则等于挂错了门。排查时用ping、telnet测试连通性同时配合设备的 ACL 命中计数看规则有没有真的被走到。命中计数一直为零那就是规则压根没被流量碰到不用怀疑机制先怀疑方向。4.2 我踩过的 mask 坑配了 rwx 却只有 r-x有一次我设置 Linux 文件 ACL给某用户加了rwx权限getfacl一看写着“effective: r-x”实际只能读和进入目录写操作直接报错。当时我一度以为是系统 bug后来才查到元凶是 mask。文件有 ACL 后mask 是一把“限位器”。它限制的是所有命名用户、命名组和默认组的最高权限。你即使给某个用户配了rwx只要 mask 是r-x有效权限就只有r-x。而且有个特别容易踩的坑当你对文件执行chmod gw或类似操作时系统会同步改变 ACL 的 mask 值导致原有 ACL 权限被悄悄“裁剪”。解决方法很简单重新设置 masksudo setfacl -m m::rwx /data/share设置完一定要用getfacl复核一遍看到 effective 和预期一致了才算完。养成“配完 ACL 就 getfacl 看一下”的习惯可以省掉很多表面诡异的问题。4.3 规则越堆越多维护困难怎么办网络 ACL 和云策略还有个共性问题时间一长规则就膨胀。原因不难理解业务需求不断变化每条规则都有人加但没人敢删——因为不知道还有没有流量在用。时间一长规则变成一座没人敢动的“屎山”。我的处理习惯是给规则分模块命名。在注释里写清楚“从哪来、给谁开、为什么开”。比如“allow-web-server-to-rds-443”和一条光秃秃的permit tcp 10.1.1.0/24 host 10.2.2.3 eq 3306维护成本天差地别。按来源或用途预留编号区间。访问控制规则用一个区间日志记录规则用另一个区间看到编号就知道职责。定期做规则命中分析和清理。能导出的场景尽量导出对比哪些规则长时间没有命中计数和业务方确认后删除。这个动作我能保证一点只要坚持做规则数量至少能砍掉三成。4.4 一个关于权限尺度的取舍建议配置 ACL 时我还见过一种心态为了“安全”拼命写 deny把能拒绝的全拒绝结果业务端口没放通线上直接出问题。出问题之后慌了又把整段 ACL 删掉排查安全策略一夜回到解放前。我的实际操作态度是先放后收。先把必要业务放通保证核心链路跑通再一步步收紧非必要访问。收紧的节奏可以这样掌握第一步只放行明确需要的源和目标。第二步观察一段时间的日志和命中计数确认没有正常业务被误伤。第三步封闭剩余不需要的路径。收紧的时候宁慢勿快线上稳定永远是第一优先级。ACL 的价值不是为了制造“看起来很安全”的配置而是在不影响业务的前提下缩小暴露面。本末倒置的话配置再好看也是一张废纸。5. 我觉得最值得记住的三句话最后分享几点我在实际配置里的个人体会不是大道理但每条都是从故障现场换来的。第一ACL 不是配完就结束的一次性工作。它是一件需要持续维护的“活配置”。业务变了、团队变了、网段变了规则就得跟着复查。长期不看 ACL 的人最终都会在最忙的时候被 ACL 咬一口。第二判断一组 ACL 写得好不好标准不是“现在能不能通”而是“半年后别人不问你能不能看懂”。好的规则本身就带着上下文看到它就能知道当初为什么这么做。第三入门别贪多。找一台测试设备或者一台 Linux 虚拟机从一条“拒绝所有、只放行某个网段”的规则开始练习逐步叠加场景。不要一上来就搞几十条的大配置那样既学不到要点出了问题也排查不动。把最小的规则逻辑摸透了后面面对任何花里胡哨的权限系统都不会犯怵。 
长河君 · 2026/10/13 13:57:46 · 阅读 1.2k ACL访问控制列表详解：网络、Linux与云权限配置实战
搞网络、管服务器的人对“ACL”这三个字母绝对不会陌生它全称是 Access Control List中文一般叫访问控制列表。说白了ACL 就是一套规则清单回答一个特别基础但特别要命的问题某个访问者到底能不能对某个资源做某个操作。我最早接触 ACL 是在配置路由器的时候后来发现 Linux 文件权限、云存储桶策略、接口鉴权全都在用同一个思想。这篇文章就把“是什么、为什么用、怎么配、坑在哪”一次性讲透给正在搞网络或系统运维的读者一个能直接上手的参考。很多人把 ACL 想复杂了其实它就是一张“门禁表”核心只有三件事谁、对什么、做什么。你只要把这个框架装进脑子里后面看什么设备的配置、看什么系统的权限模型都能快速套进去。接下来我按从概念到实操的顺序拆开讲。1. ACL 是什么一张带条件的门禁名单1.1 ACL 的核心定义与规则三要素我习惯把 ACL 理解成小区门口保安手里那张登记表。表上不是乱写一堆名字而是每一条都很明确哪些人能进、哪些人不能进、什么时间段能进、能进到哪一栋楼。网络设备、操作系统里的 ACL本质上就是这张表。一条 ACL 规则通常包含三个要素主体Who。谁要访问。在网络场景里是源 IP、源网段在文件场景里是用户名、用户组。客体What。要访问什么。网络里是目的 IP、目的端口文件系统里是某个目录或文件。动作Allow / Deny。允许还是拒绝。有些规则还会加上“条件”维度比如协议类型、时间范围、MAC 地址。比如一条典型的网络 ACL 规则允许 192.168.10.0/24 网段的设备通过 HTTPS443端口访问某台核心服务器其余统统丢弃。这就是主体、客体、动作三要素完整结合的例子。文件系统里的 ACL 也一个道理允许某个同事对 /var/log/app.log 有读写权限拒绝其他人写入。理解到这个层面ACL 的概念你就拿下了。1.2 ACL、防火墙、RBAC三兄弟别搞混我遇到过不少刚入门的朋友把 ACL 和防火墙规则、RBAC 权限模型搞混。它们确实有关系但角度不同。防火墙是一种安全设备它会把安全策略翻译成规则去过滤流量。很多防火墙规则就是 ACL 的一种工程化实现。只不过防火墙还具备状态检测、应用层识别等进阶能力ACL 相对更“裸”一些通常工作在包过滤层面。RBAC基于角色的访问控制是一种权限管理模型把权限先打包成“角色”再把角色分配给用户。它解决的是“如何管理一堆人的权限”的问题比如一个公司里设管理员、运营、审计三种角色。ABAC基于属性的访问控制则更进一步权限判断依据不只是身份还包括时间、地点、设备状态等动态属性。ACL 本身更接近“直接列出谁可以干什么”的权限表。它和 RBAC 的区别在于ACL 是站在资源角度写的规则RBAC 是站在组织角色角度设计的模型。实际系统里经常混合用底层还是 ACL 那一套规则在生效。1.3 三个最常见的 ACL 存在位置搞清楚概念后你得知道去哪儿碰它。我整理了一下日常工作里 ACL 主要出现在三个层面网络设备。路由器、交换机上配标准 ACL 或扩展 ACL用来做访问控制、流量过滤、安全隔离。这是最经典的应用场景。操作系统文件系统。Linux 上的 POSIX ACL、Windows 上的 NTFS ACL用来控制文件/目录的读、写、执行权限。标准 chmod 权限不够用的时候ACL 能补上“单独给某个用户授权”的能力。对象存储、API 网关、消息队列等云服务。存储桶策略、对象级 ACL、接口鉴权策略很多底层都是 ACL 思想。我自己的建议是刚入门可以从网络 ACL 开始学因为网络 ACL 规则简单、逻辑直白、配置后立刻能看到效果但文件系统 ACL 更贴近日常开发维护也值得尽早掌握。两者都吃透后再看云平台那一堆权限策略就轻松多了。2. 用 ACL 到底图什么目的拆解2.1 最核心的目的让最小权限原则落地做运维或者搞安全的都知道“最小权限”这四个字。意思是任何用户、任何组件、任何外部访问都只给完成任务所必需的最小权限多了不给。没有 ACL 的时候权限管理很粗放经常出现“所有人同一个权限”的情况。比如某个内部系统所有同事都能登录服务器都能看配置文件都能改代码目录那一旦有人误操作或者账号泄露风险就完全失控了。上了 ACL 之后你就可以针对具体用户、具体网段、具体服务端口把权限收窄到正好够用。我在实际配置中常用的做法是先把“允许列表”写清楚明确哪个用户组能访问哪台服务器的哪个端口剩下的访问全部拒绝。这样即使某个测试账号被扫到了攻击者也拿不到更多入口。最小权限不是嘴上说说ACL 是它落地的最直接工具。2.2 第二个目的流量管控与边界防护网络层的 ACL 还有一个重要职责就是做流量管控。你可以理解成在大楼门口设了安检闸机哪些人能进、从哪个门进、去哪个楼层都要按规则走。举个例子某个公司只允许办公区域的网段通过 SSH 访问核心跳板机其他来源一律丢弃。用 ACL 实现这个策略配置并不复杂但效果立竿见影——扫描器扫不到、暴力破解的来源被拒之门外、内部横向移动的路径也被砍掉一截。配置边界 ACL 时我一般不搞“先全部放行再加几条 deny”的方式。默认全放行的策略你加的那几条 deny 就像大海里扔石头看得见但拦不住所有东西。正确的思路是“显式放行 末尾默认拒绝”这才是 ACL 该有的姿态。网络 ACL 越靠外层的设备和接口规则越要精简因为每一条规则都会消耗设备 CPU 的处理时间规则越多转发性能越受影响。2.3 第三个目的满足审计要求留下“可解释的记录”刚工作那会儿我比较烦写规则觉得直接能通就行。后来有一次线上故障排查系统被某个来源的流量打挂一堆人查来查去最后是靠 ACL 规则顺序和命中计数锁定了异常来源。从那之后我就明白ACL 不只是“通不通”的问题它更是一条可以解释的记录。从合规角度讲很多企业的安全审计框架都要求“访问可控、操作可查”。ACL 规则本身可以导出、可以备份、可以差异比对。定期评审 ACL能发现不少潜在问题有没有“半年没人用的放行规则”有没有规则已经和业务不符这些都是隐性债务攒多了迟早出事。而且成体系的 ACL 还有一个好处方便协作。规则有注释、有分段半年后新来的同事看你的配置也能快速知道每条规则是干嘛的。这一点我后面细讲。3. 从网络到服务器到云ACL 实操全流程3.1 网络设备上的标准 ACL 与扩展 ACL 怎么配网络 ACL 最常见的是标准 ACL 和扩展 ACL。不同厂商设备的配置命令有差异但思想是通用的下面我用一种在业界很主流的风格来演示这类语法在很多设备上都能找到影子。你在实际环境里以手上的设备文档为准即可。标准 ACL 只看源地址不能区分协议和端口适合做简单的网段隔离。一条标准的规则长这样access-list 10 permit 192.168.10.0 0.0.0.255 access-list 10 deny any这里有个新手容易懵的地方为什么子网写成0.0.0.255这不是子网掩码而是通配符掩码。0 表示必须匹配255 表示可以忽略。192.168.10.0 0.0.0.255的意思就是匹配前 24 位固定、后 8 位任意也就是 192.168.10.0/24 网段。把它和 255.255.255.0 当成一回事就错了两者在 ACL 里含义完全不同。扩展 ACL 就强大多了能基于源 IP、目的 IP、协议、源端口、目的端口做精细控制。比如这句access-list 100 permit tcp 192.168.10.0 0.0.0.255 host 10.20.30.40 eq 443 access-list 100 deny ip any any意思是允许 192.168.10.0/24 网段访问主机 10.20.30.40 的 443 端口HTTPS其他 IP 流量全部丢弃。重点在于大多数 ACL 的最后都藏着一条隐式规则——deny any any也就是“默认拒绝”。你只写了允许规则但没写deny any any设备也会帮你默默拒绝其余流量。很多初次配置的人以为没写 deny 就全放行结果业务断了一片折腾半天才发现是这个原因。配好规则之后还要把它“应用”到具体接口的入方向或出方向。我的经验是能放在入方向就放在入方向因为流量一进接口就被处理过滤效率更高也能减轻设备后续的处理压力。放错方向是另一个高频问题原因也很简单你没想清楚这条规则匹配的对象是从哪边进来的。3.2 Linux 服务器上用 setfacl 改文件权限照着做就行Linux 默认的权限模型是 所有者/所属组/其他人 三段式用chmod就能改。但有一种常见需求搞不定让某个特定用户对某个文件有读权限但它既不是文件所有者也不在所属组里。这时候就要上文件 ACL 了。大多数 Linux 发行版默认装好了 ACL 工具如果没有先装一下# Debian/Ubuntu 系 sudo apt install acl # CentOS/RHEL 系 sudo yum install acl查看一个文件的 ACL 权限用getfaclgetfacl /var/log/app.log给某个用户单独加权限用setfacl# 给用户 zhangsan 添加读写权限 sudo setfacl -m u:zhangsan:rw /var/log/app.log # 给 devteam 这个组添加只读权限 sudo setfacl -m g:devteam:r /var/log/app.log # 删除某条 ACL sudo setfacl -x u:zhangsan /var/log/app.log还有一类更实用的是默认 ACLdefault ACL它只能设置在目录上作用是该目录下新建的文件自动继承权限。这在团队共享目录里特别常用sudo setfacl -d -m u:zhangsan:rwx /data/share之后在 /data/share 里新建的文件zhangsan 就自动有相应权限了不用每次新建文件再手动授权。文件系统里配好 ACL 后用ls -l查看权限位后面会出现一个加号说明这个文件上有额外 ACL 规则。这里必须多说一句ACL 的权限不是简单做加法。如果你只是给某个人加读权限但他自己没有写权限最后的有效权限仍然是由“用户权限、ACL 权限、mask”共同决定的。mask 是什么它是所有命名用户和命名组的“权限天花板”。后面常见问题里我会专门讲这个坑。3.3 对象存储与云平台上的 ACL从桶策略到 API 鉴权到了云平台这一层ACL 概念又换了个马甲。你在对象存储服务里经常能看到三样东西存储桶策略Bucket Policy、对象 ACL、以及更上层的访问管理策略IAM Policy。很多人被这几层搞晕其实底层逻辑还是“主体-客体-动作-允许/拒绝”。对象 ACL粒度最细控制某个存储桶里某个对象的读、写、查看等权限。适合简单的公开读/私有写等固定场景。桶策略以 JSON 描述的一组规则可以指定某个网段、某个账号对某个前缀路径的限定操作。比如“只允许办公 IP 段访问这个桶”用桶策略写就很直接。IAM 策略更偏“角色”概念把权限分配给子账号、应用或角色适合企业多账号、多项目协作场景。我自己的选择经验是对象少、授权关系简单的时候直接用对象/桶 ACL 就行一旦牵涉多个团队、多个环境、频繁变动授权就去用 IAM 策略因为可维护性高很多。纯 ACL 一条条堆上去后面没人讲得清哪条该删哪条该留这种“配置债务”比欠代码债还烦。4. 常见问题与排查技巧实录4.1 网络 ACL 配置后没生效八成是这三个原因ACL 配了却没效果这种事我见过太多回了。排障时我一般按优先级查三件事规则顺序对不对。绝大多数 ACL 从上往下逐条匹配一旦命中就停止。如果你把一条“全部放行”写在前面后面再写“拒绝某 IP”就是空的。所以顺序非常重要先写精细规则再写兜底规则。通配符掩码有没有写反。0.0.0.255和255.255.255.0的含义完全不一样前者是匹配整个网段后者是匹配单个地址。配错后最常见表现是部分 IP 能通、部分不能通而且你一眼还看不出来。有没有应用到正确的接口方向。入方向和出方向搞反规则等于挂错了门。排查时用ping、telnet测试连通性同时配合设备的 ACL 命中计数看规则有没有真的被走到。命中计数一直为零那就是规则压根没被流量碰到不用怀疑机制先怀疑方向。4.2 我踩过的 mask 坑配了 rwx 却只有 r-x有一次我设置 Linux 文件 ACL给某用户加了rwx权限getfacl一看写着“effective: r-x”实际只能读和进入目录写操作直接报错。当时我一度以为是系统 bug后来才查到元凶是 mask。文件有 ACL 后mask 是一把“限位器”。它限制的是所有命名用户、命名组和默认组的最高权限。你即使给某个用户配了rwx只要 mask 是r-x有效权限就只有r-x。而且有个特别容易踩的坑当你对文件执行chmod gw或类似操作时系统会同步改变 ACL 的 mask 值导致原有 ACL 权限被悄悄“裁剪”。解决方法很简单重新设置 masksudo setfacl -m m::rwx /data/share设置完一定要用getfacl复核一遍看到 effective 和预期一致了才算完。养成“配完 ACL 就 getfacl 看一下”的习惯可以省掉很多表面诡异的问题。4.3 规则越堆越多维护困难怎么办网络 ACL 和云策略还有个共性问题时间一长规则就膨胀。原因不难理解业务需求不断变化每条规则都有人加但没人敢删——因为不知道还有没有流量在用。时间一长规则变成一座没人敢动的“屎山”。我的处理习惯是给规则分模块命名。在注释里写清楚“从哪来、给谁开、为什么开”。比如“allow-web-server-to-rds-443”和一条光秃秃的permit tcp 10.1.1.0/24 host 10.2.2.3 eq 3306维护成本天差地别。按来源或用途预留编号区间。访问控制规则用一个区间日志记录规则用另一个区间看到编号就知道职责。定期做规则命中分析和清理。能导出的场景尽量导出对比哪些规则长时间没有命中计数和业务方确认后删除。这个动作我能保证一点只要坚持做规则数量至少能砍掉三成。4.4 一个关于权限尺度的取舍建议配置 ACL 时我还见过一种心态为了“安全”拼命写 deny把能拒绝的全拒绝结果业务端口没放通线上直接出问题。出问题之后慌了又把整段 ACL 删掉排查安全策略一夜回到解放前。我的实际操作态度是先放后收。先把必要业务放通保证核心链路跑通再一步步收紧非必要访问。收紧的节奏可以这样掌握第一步只放行明确需要的源和目标。第二步观察一段时间的日志和命中计数确认没有正常业务被误伤。第三步封闭剩余不需要的路径。收紧的时候宁慢勿快线上稳定永远是第一优先级。ACL 的价值不是为了制造“看起来很安全”的配置而是在不影响业务的前提下缩小暴露面。本末倒置的话配置再好看也是一张废纸。5. 我觉得最值得记住的三句话最后分享几点我在实际配置里的个人体会不是大道理但每条都是从故障现场换来的。第一ACL 不是配完就结束的一次性工作。它是一件需要持续维护的“活配置”。业务变了、团队变了、网段变了规则就得跟着复查。长期不看 ACL 的人最终都会在最忙的时候被 ACL 咬一口。第二判断一组 ACL 写得好不好标准不是“现在能不能通”而是“半年后别人不问你能不能看懂”。好的规则本身就带着上下文看到它就能知道当初为什么这么做。第三入门别贪多。找一台测试设备或者一台 Linux 虚拟机从一条“拒绝所有、只放行某个网段”的规则开始练习逐步叠加场景。不要一上来就搞几十条的大配置那样既学不到要点出了问题也排查不动。把最小的规则逻辑摸透了后面面对任何花里胡哨的权限系统都不会犯怵。