如果你正在处理Security Group，先别急着照搬网上的参数。小张在云上买了一台服务器，部署了一个个人博客。他按照教程在安全组里只放行了80和443端口，心里觉得万无一失。结果第二天发现服务器CPU跑满，日志里全是来自某IP的SSH暴力破解请求——他忘记关22端口了，而且攻击者直接绕过了安全组？不，其实是安全组规则配置错了方向。更让他困惑的是，后来他加了一个网络ACL，发现流量被拦截了两次，有些业务反而连不上了。
这种场景你是不是也遇到过？安全组和网络ACL看似重复，实则各管一摊。把它们理解成两道门：安全组是你家门口的智能猫眼，只认人（状态化）；网络ACL是小区入口的保安亭，只认车牌号（无状态）。两道门都得设对，才能防住乱闯的、绕路的。
为什么需要两层防护？
容易忽略的细节
云上VPC（虚拟私有云）是一个隔离的网络环境，但隔离不等于安全。你仍然需要控制谁可以进出你的子网和服务器。如果只用一层防护，一旦配置有漏洞（比如不小心放行了全0.0.0.0/0的SSH），就等于把家门钥匙挂在门外。
安全组作用于实例级别（弹性云服务器、数据库等），网络ACL作用于子网级别。子网是实例所在的逻辑分区，网络ACL相当于对整片区域进行粗粒度过滤，安全组再对具体房间做细粒度控制。两层叠加，可以降低单点失误的风险。即使安全组规则写错了，网络ACL还能兜底；反过来，网络ACL太宽松，安全组也能收紧。
补充参考：此处可内链到“Security Group故障排查实例”。
安全组：有状态的自学习门禁
先看关键判断
安全组最大的特点是有状态。你放行了一条出站规则（比如允许服务器主动访问公网），那么当外部响应数据包返回时，安全组会自动允许该流量进站，不需要你额外加一条入站规则。同样，允许入站流量后，出站的响应也会自动放行。
这种机制让规则配置量少了很多，你只需要关注主动发起的连接方向。默认安全组会拒绝所有入站流量，允许所有出站流量（但建议修改为最小权限）。
适用场景： 对单个实例进行精细控制，比如数据库只允许应用服务器访问，Web服务器只开放80/443端口，管理端口仅限特定IP。
进阶阅读：此处可内链到“Security Group性能优化”指南。
网络ACL：无状态的固定栅栏
先看关键判断
网络ACL是无状态的，意味着每条进出子网的流量都必须分别匹配入站和出站规则。你允许了入站方向（例如允许来自公网的HTTP请求），但出站方向如果没有明确允许响应流量，那么客户端的请求虽然到了服务器，服务器返回的数据却被ACL拦截了——因为出站规则默认是拒绝所有。
所以使用网络ACL时必须成对配置：入站放行的流量，其响应在出站方向也要显式放行，反之亦然。这看起来麻烦，但给了你更细的控制力，比如可以按端口范围、协议甚至ICMP类型进行无状态过滤。
适用场景： 对整个子网做统一的安全策略，比如禁止某个IP段访问子网内所有机器，或者对敏感子网（如数据库子网）完全关闭公网入站。
相关阅读：此处可内链到“Security Group常见问题”专题。
想继续深入：此处可内链到“Security Group优化清单”文章。
安全组 vs 网络ACL：一图看懂核心区别
我的处理经验
- 作用范围： 安全组绑定到弹性网卡/实例，网络ACL关联到子网。
- 状态性： 安全组有状态（自动追踪连接），网络ACL无状态（需显式配对规则）。
- 规则评估： 安全组只检查允许规则，拒绝默认；网络ACL按规则序号从小到大匹配，匹配即停止（允许或拒绝）。
- 规则数量： 安全组规则有上限（通常100条以内），网络ACL规则更多（比如200条）。
- 层级： 网络ACL是粗粒度第一道，安全组是细粒度第二道。
双重防护设计规范（小白版）
第一步：划分VPC和子网，确定安全边界
不要把所有服务器都放在同一个子网里。至少划分成公网子网（Web层） 和内网子网（应用/数据层）。公网子网里的实例直接对外提供服务，内网子网只允许公网子网访问。
比如：Web子网（/24）挂载安全组SG-Web，只开放80/443；DB子网（/24）挂载安全组SG-DB，只允许来自Web子网的安全组访问3306。
第二步：配置网络ACL作为第一道防线
针对每个子网，创建对应的网络ACL。对于公网子网：
- 入站规则：允许来自0.0.0.0/0的TCP 80/443；拒绝所有其他IP。
- 出站规则：允许目标0.0.0.0/0的TCP 1024-65535（因为响应流量源端口随机）；如果你知道固定端口范围，也可以收紧。
对于内网子网：
- 入站规则：只允许来自Web子网CIDR的TCP 3306（或对应数据库端口）；拒绝其他所有。
- 出站规则：允许目标0.0.0.0/0的TCP 1024-65535（以便响应流量），但建议限制只允许出站到特定服务（如NTP、YUM仓库、DNS）。
注意网络ACL默认规则是拒绝所有，因此需要显式添加这些允许规则，并且一定要添加响应流量的出站规则，否则业务自环。
第三步：配置安全组作为第二道防线
安全组规则更灵活。例如对于Web服务器：
- 入站：只允许0.0.0.0/0的TCP 80/443。如果需要SSH管理，添加源IP为办公场所公网IP的TCP 22。
- 出站：允许所有流量（但可以收紧，比如只允许访问DB子网的3306和公网的80/443）。
对于数据库服务器：
- 入站：只允许Web服务器的安全组ID（或内网IP）的TCP 3306；不允许任何公网IP。
- 出站：允许所有出站（以便数据库拉取更新等）。
安全组的规则更少，但因为是状态化，你不需要操心响应流量。
第四步：验证与测试
配置完成后，用telnet或nc尝试从不同位置访问各端口。比如从办公网telnet Web子网的公网IP 22端口，应该被拒绝（网络ACL和安全组双重拒绝）。从Web服务器telnet DB子网的3306，应该能通（ACL允许，安全组允许）。同时用nmap扫描外部IP，确认只有80/443可见。
如果业务出现不通，优先排查网络ACL的出站规则是否允许了响应流量。一个常见错误：入站允许了HTTP，出站没允许临时端口响应，导致客户端收到连接超时，服务器端却看到SYN_RECV。
延伸阅读：此处可内链到“Security Group配置案例”相关文章。
常见误区澄清与Security Group
故障定位思路
- 误区一：安全组和网络ACL可以互相替代。 不能。安全组不能控制子网间的所有流量，网络ACL不能精细到实例。两者互补。
- 误区二：网络ACL规则序号越大优先级越高。 实际是越小越优先，与防火墙顺序相同。
- 误区三：安全组只影响入站。 安全组同时控制出站，默认出站全开，建议根据业务收紧。
- 误区四：网络ACL配置了入站允许，出站不用管。 无状态特性决定了出站必须显式允许响应流量，否则连接失败。
Security Group：最佳实践总结
验证与回滚
对于生产环境，建议采用“最小权限 + 默认拒绝”原则。网络ACL作为粗粒度防线，对子网整体实施白名单；安全组作为细粒度防线，对特定实例实施白名单。两层之间留出冗余，即使某层配置失误，另一层还能挡一下。同时定期审计规则变更，避免出现0.0.0.0/0的全开规则。
记住：安全不是做一次就完事，而是要随着业务变化持续调整。对于小白来说，先从最简单的两层结构开始：Web子网+DB子网，配上基本的ACL和安全组，然后逐步收窄规则。这样即使出了问题，也容易定位。把这些步骤跑通后，Security Group基本就能稳定落地。
延伸阅读