引言

在云上安全体系中，安全组和网络ACL是两道最基础也最容易被混淆的防线。很多团队的做法是"开了安全组就够了"，结果要么权限过大导致横向渗透，要么规则冲突让流量在两道墙之间"打架"。实际上，安全组和ACL并非替代关系，而是互补关系——安全组工作在实例层级，控制的是"哪台机器能收什么流量"；ACL工作在子网层级，控制的是"哪个网段能进什么流量"。两者协同，才能构建起从网络边界到单台实例的纵深防御体系。天翼云的安全组支持有状态检测，网络ACL支持无状态过滤，两者配合可覆盖从L3到L7的全链路流量控制需求。本文将从7种典型业务场景出发，系统拆解ACL与安全组如何协同工作，让每一条流量都在精确的规则下运行。

一、先搞清楚：安全组和ACL到底有什么区别？

在进入场景之前，必须先厘清两个概念的边界，否则后续的协同策略无从谈起。

关键结论：安全组是"贴身保镖"，ACL是"小区门禁"。 保镖管的是这个人能不能进这间房，门禁管的是这个人能不能进这个小区。两者配合，才能既防住外面的人，也防住里面的人乱窜。

二、7种典型协同场景

场景一：多层子网隔离——前中后端流量分层管控

这是最经典的协同场景，也是等保三级的硬性要求。

架构设计：将业务拆分为前端子网、应用子网、数据子网三层，每层一个子网，每层配置独立的ACL和安全组。

ACL的职责：在子网边界做粗粒度隔离。前端子网的ACL只允许来自公网的80/443端口流量；应用子网的ACL只允许来自前端子网的流量；数据子网的ACL只允许来自应用子网的流量。任何跨层的非授权流量在ACL层就被直接丢弃。

安全组的职责：在实例层级做细粒度控制。即使流量通过了ACL进入应用子网，每台应用服务器的安全组也只允许来自前端子网特定IP段的流量，且仅开放业务所需的端口。

协同效果：ACL挡掉了80%的非法跨层流量，安全组再过滤掉剩余20%中的精准攻击。即使某台应用服务器被攻破，攻击者也无法通过安全组访问数据子网，因为数据子网的ACL根本不允许应用子网的流量直连数据库端口。

场景二：白名单精细化管控——网络层与应用层双重校验

很多团队只在安全组里配置白名单，结果一旦安全组规则被误改，整个实例就暴露在公网之下。更稳妥的做法是在ACL和安全组两层同时配置白名单，形成双重校验。

ACL层：在子网ACL中只允许公司办公网IP段访问业务子网，拒绝一切其他来源。这一层相当于"小区门禁只认业主"。

安全组层：在实例安全组中进一步限定，只允许办公网IP段中的特定几台跳板机访问SSH端口和RDP端口。这一层相当于"进了小区还得有门禁卡才能上楼"。

协同效果：即使安全组被误操作开放了所有IP的SSH访问，ACL层依然会拒绝非办公网IP的流量。两层白名单叠加，误操作的爆炸半径被压缩到最小。

场景三：防止东西向流量攻击——阻断实例间横向渗透

等保2.0明确要求控制东西向流量。一旦攻击者通过Web漏洞拿到了一台云主机的控制权，第一件事就是扫描内网其他实例，寻找可利用的跳板。

ACL的职责：在每个子网的出站ACL中，明确限制该子网可以访问哪些其他子网的哪些端口。例如，Web服务器子网的出站ACL只允许访问应用子网的8080端口，拒绝访问数据库子网的3306端口。

安全组的职责：在每台实例的入站安全组中，只开放同子网内实例之间的必要通信端口。跨子网的通信必须经过负载均衡或API网关，不允许实例直接互访。

协同效果：ACL从网络层切断了跨子网的非法路径，安全组从实例层确保即使同子网内的通信也是最小化授权。攻击者拿到Web服务器后，既无法通过ACL访问数据库子网，也无法通过安全组扫描同子网的其他实例，横向移动被彻底封死。

场景四：合规审计——网络层与实例层日志双留痕

等保三级要求安全审计日志留存不少于6个月，且需覆盖网络层和主机层。

ACL的职责：天翼云网络ACL支持日志记录功能，可将被ACL规则拒绝或放行的流量信息记录到日志服务中。由于ACL工作在子网层，其日志反映的是整个子网的流量进出情况，适合做网络层的合规审计。

安全组的职责：安全组的日志记录的是每台实例的入站和出站流量明细，精确到五元组（源IP、目的IP、源端口、目的端口、协议）。适合做实例层的行为审计。

协同效果：ACL日志回答"哪个网段在什么时间尝试访问了什么"，安全组日志回答"哪台实例在什么时间收到了来自哪里的什么请求"。两套日志交叉比对，可以完整还原一次攻击的全链路路径，满足等保审计的双层留痕要求。

场景五：临时封堵与长期策略分离——安全组做"急诊"，ACL做"保健"

业务运行中经常遇到突发安全事件：某个IP在疯狂扫描端口、某个地区的流量出现异常、某次攻击正在进行中。这种场景下，需要在秒级时间内完成封堵。

安全组做急诊：安全组支持实时修改规则，且立即生效。当发现攻击源IP时，直接在目标实例的安全组中添加一条拒绝规则，3秒内生效。这是"急诊手术"，快但不宜常用——因为安全组规则数量有限（单实例最多50条），且频繁修改容易出错。

ACL做保健：将临时性的封堵需求沉淀为ACL规则。ACL规则数量上限更高（单子网最多100条入站+100条出站），且不占用安全组的规则配额。攻击事件处理完毕后，将临时封堵的IP段从安全组移至ACL，作为长期策略保留。

协同效果：安全组负责"秒级响应"，ACL负责"长期沉淀"。两者配合，既保证了应急速度，又避免了安全组规则膨胀导致的管理混乱。

场景六：跨VPC流量管控——ACL守边界，安全组管内网

当业务涉及多个VPC时（如生产VPC与测试VPC隔离、业务VPC与管理VPC隔离），流量控制的复杂度会显著上升。

ACL的职责：在每个VPC的子网ACL中，明确拒绝来自其他VPC网段的所有流量。这是VPC之间的"硬隔离"——即使路由表配置了跨VPC互通，ACL也会在网络层直接丢弃，确保物理上不可达。

安全组的职责：在需要跨VPC通信的特定场景下（如监控系统需要采集各VPC的指标），仅在目标实例的安全组中开放来自监控VPC特定IP的特定端口，其余全部拒绝。

协同效果：ACL确保默认情况下VPC之间完全隔离，安全组在需要通信时开"精确的小窗口"。这种"默认拒绝、按需开放"的策略，是多VPC架构下最安全的流量控制模式。

场景七：零信任架构落地——永不信任，始终验证

零信任的核心理念是"永不信任，始终验证"。在天翼云上落地零信任，ACL和安全组的协同是最基础的一环。

ACL层：所有子网的ACL默认拒绝一切入站流量，仅显式开放业务必需的端口和IP范围。没有任何"隐式允许"——这是零信任在网络层的体现。

安全组层：每台实例的安全组不信任任何来源，包括同子网内的其他实例。所有通信必须经过显式授权，且授权精确到IP+端口+协议的五元组级别。

协同效果：ACL构建了"网络层零信任"——不管你从哪里来，不在白名单里就进不来；安全组构建了"实例层零信任"——即使你进了网络，没有实例级授权也访问不了任何服务。两层零信任叠加，攻击面被压缩到理论最小值。

三、最佳实践：配置协同的五条铁律

写在最后

安全组和ACL不是二选一的关系，而是"一个管点、一个管面"的协同关系。单独用安全组，子网级别的流量失控你看不见；单独用ACL，实例级别的精准控制你做不到。只有两者配合，才能从网络边界到单台实例构建起真正的纵深防御。

从今天起，检查你的云上网络：ACL是不是还在用默认策略？安全组是不是开了全放？东西向流量有没有被ACL拦住？临时封堵是不是还堵在安全组里没挪到ACL？这四个问题的答案，决定了你的流量控制是"形同虚设"还是"滴水不漏"。真正的安全，从来不是靠一道墙，而是靠每一层墙都守住了自己该守的那一段。