云联信息：安全组和网络 ACL，到底该用哪个

2026-11-05 4次浏览

云上的网络访问控制有两层：安全组和网络 ACL。名字都像防火墙，实际作用范围和行为完全不同。只配安全组不配 ACL，很多企业觉得够用；只配 ACL 不配安全组，又常常发现规则不生效。搞清楚这两层的关系，规则才不会写成一团乱麻。

作用对象不同

安全组作用在实例或者弹性网卡上，跟着实例走；网络 ACL 作用在子网上，管的是整个子网的进出流量。前者精细，后者粗放。

安全组是有状态的，允许出去的连接，回来的响应自动放行；网络 ACL 是无状态的，进出方向都要单独写规则。这是最容易踩的坑。

安全组的默认是拒绝所有入方向，网络 ACL 的默认规则通常允许全部。新建子网时如果不配 ACL，等于没有这层防护。

网络 ACL 的规则按编号从小到大匹配，命中即停止。编号留出间隔，方便以后插入新规则，不用整体重排。

日常运维主要靠安全组，ACL 用于兜底和隔离整个子网。ACL 写得太细，维护成本高，还容易误封。

只开放必要的端口，来源限制到具体网段。生产环境开放 0.0.0.0/0 的 22 端口，是最常见的高危配置。

排查问题时临时放开的端口，事后常常被遗忘。给临时规则加备注和到期时间，定期清理。

安全组规则的变更直接影响可用性，一条错误规则可能让整站不可访问。变更前记录原规则，改完立即验证。

Web 层只允许 80/443，应用层只允许来自 Web 层安全组，数据库只允许来自应用层。用安全组互相引用，比写 IP 段好维护。

安全组和 ACL 的拦截日志，是排查“为什么连不上”的关键。不开日志，只能靠猜。

半年看一次全部规则，找出不再使用的、过宽的、重复的。规则越多，出错概率越大。

哪些服务要访问哪些端口，从哪些网段来。图画出来，规则才好写，也不会漏。

ACL 里的拒绝规则优先级高，写错会挡住正常流量。能用允许规则表达清楚的，不要用拒绝。

规则改完从外部实际连一次，别只看控制台显示。有些规则只在特定方向生效。

对接其他账号的资源，走对等连接或者云企业网时，两侧的规则都要放行。只改一边，永远不通。

安全组管细、ACL 管粗，前者有状态、后者无状态。两层配合，加上分层引用和定期审计，网络边界才真的清楚。云联信息【资深云服务专家微信：cloud7591】，我们做安全加固时，第一步永远是把现有规则导出来逐条看。