弹性云服务器 ECS 安全组与网络隔离的最佳实践

上云之后，很多团队把精力放在了应用和业务逻辑上，网络隔离却常常停留在“能通就行”的状态。直到某天，一台本不该暴露的数据库端口被扫到，或者一台测试机成了跳板，才发现安全组规则早已失控。本文结合弹性云服务器 ECS 的实际使用，把安全组与网络隔离的做法梳理成几条可以直接落地的原则，帮助你在不增加太多运维负担的前提下，把云上网络的口子收紧。

一、先理解安全组：它到底在管什么

安全组是一种虚拟防火墙，作用在弹性云服务器的网卡一级，控制进出这台云服务器的流量。它有两个关键特性，理解了它们，后面的规则才不会写错。

第一，安全组是有状态的。放行了一个入方向的请求，它的返回流量会自动放行，不需要再单独写一条出方向规则。反过来也一样，出方向主动发起的连接，返回包同样自动放行。这个特性意味着规则可以只关注“谁可以主动发起连接”，而不用成对地写规则。

第二，安全组默认“入方向拒绝、出方向放行”的思路下工作。以华为云的默认安全组为例，入方向只放行来自同一安全组的流量，其余一律拒绝；出方向则默认全部放行。新手最常见的错误，就是以为买了云服务器就等于裸奔在公网上，或者反过来以为默认规则已经足够安全。这两种理解都不对：默认规则只是一个起点，真正的安全来自你随后补上的精细化规则。

第三，安全组规则是“白名单”逻辑：只要有一条规则匹配并放行，流量就通过；没有任何规则匹配时，流量被拒绝。规则之间没有优先级高低之分，不需要像传统防火墙那样纠结顺序。这让安全组的管理相对简单，但也意味着一条过于宽松的规则就能让所有收紧的努力白费。

二、原则一：默认拒绝，按需放行

最小权限原则在安全组上的体现，就是“默认拒绝、按需放行”。每一条入方向规则在添加之前，都应当能回答三个问题：放行哪个端口、放行给谁、为什么必须放行。答不上来的规则，就不要加。

一个常见的反面例子是图省事放行全部端口，或者放行 1-65535 的端口段。这样做等于把安全组旁路掉，云服务器上任何一个服务、任何一个不小心启动的调试端口都直接暴露在外。正确的做法是只放行业务必需的端口：Web 服务放行 80 和 443，数据库不放行任何公网端口，管理端口只对指定地址放行。

出方向同样值得收紧。虽然默认出方向全部放行省事，但它也意味着一旦某台机器被入侵，攻击者可以不受限制地向外连接、下载恶意程序或外传数据。对于生产环境的服务器，建议把出方向也逐步收敛：允许访问必要的软件源、域名解析、对象存储和内部服务，其余拒绝。收敛出方向要分阶段做，先观察、再收紧，避免一刀切导致业务中断。

三、原则二：按角色分组，别把所有机器塞进一个组

安全组应当按“角色”划分，而不是按“项目”一锅烩。把 Web 服务器、应用服务器、数据库全部放进同一个安全组，是最常见的结构性错误：一旦规则为某个角色放行了端口，同组的其他角色也被动地获得了同样的放行范围。

推荐的分层方式是经典的三层结构：Web 层、应用层、数据层。

这里的关键是“源地址写安全组而不是写 IP”。华为云安全组支持把源地址设置为另一个安全组，这样做的好处是伸缩性：Web 层扩容、IP 变化时，应用层的规则不需要跟着改。数据层的规则只认“应用层安全组”这个身份，而不认某一台机器的具体地址。

分层之后，攻击路径也被拉长了：即使 Web 层某台机器被攻破，攻击者面对数据层时仍然要过一道安全组的关，而数据库本身不监听公网端口，进一步缩小了暴露面。分层不是为了好看，而是让每一层的失守都不至于直接导致核心数据的失守。

四、原则三：源地址写具体，拒绝 0.0.0.0/0 泛滥

0.0.0.0/0 是安全组规则里最需要警惕的写法。它本身没有错，Web 服务本来就需要对公众开放 80 和 443；问题在于它被滥用到了不该出现的地方：管理端口、数据库端口、中间件控制台、内部接口，凡是图方便的地方都写上了 0.0.0.0/0。

管理端口是最典型的重灾区。22 端口的 SSH 和 3389 端口的远程桌面一旦对全网放行，就会立刻被全网的扫描器盯上，暴力破解的尝试从不间断。正确的做法是：只对办公网出口 IP 或堡垒机的地址放行管理端口；如果办公出口 IP 不固定，可以改用 VPN 或云堡垒机接入，彻底关掉管理端口的公网放行。

对于只在云内使用的服务，源地址应当限定为具体的网段或安全组。例如数据库只允许应用层所在的子网网段访问；对象存储、消息队列等云服务，优先使用内网地址和 VPC 终端节点访问，避免流量绕公网。源地址越具体，规则被误用或被利用的空间就越小。

一个实用的检查方法是定期导出全部安全组规则，逐条过一遍源地址列。凡是源地址为 0.0.0.0/0 且端口不是 80、443 的规则，都应当被打上问号，要么收紧，要么写下明确的放行理由并设置复查时间。

五、原则四：安全组与网络 ACL 分层配合

安全组工作在实例网卡一级，网络 ACL 工作在子网一级。两者不是二选一，而是纵深防御的两层。理解它们的分工，才能避免“配了两层却等于没配”的情况。

网络 ACL 是无状态的，入方向放行的流量，返回流量需要出方向规则显式放行；而且规则有优先级，按编号从小到大匹配。这让它适合做粗粒度的兜底策略：例如在子网一级拒绝所有来自公网的数据库端口访问，哪怕某台机器的安全组被误改，子网 ACL 仍然能挡住一层。

推荐的分工是：网络 ACL 做“子网级兜底”，拦截明显不合理的流量，例如在数据库所在子网拒绝任何公网来源的入方向连接；安全组做“实例级精细控制”，按角色放行具体端口和来源。两者叠加后，单点误操作的影响被大幅压缩：改错一条安全组规则，不至于让数据库直接暴露；改错一条 ACL，也还有安全组兜底。

需要注意的是，网络 ACL 的默认规则是拒绝所有流量，启用时必须先配好放行规则，否则会直接阻断业务。建议先在测试子网验证，再应用到生产子网，变更前后都通过连通性测试确认业务不受影响。

六、原则五：管理端口要“藏”起来

除了收紧规则，减少“被看见”本身也是一种防护。管理端口、中间件控制台、各类后台页面，能不暴露公网就不要暴露。

具体做法有几条。第一，数据库、缓存、消息队列等数据类服务不要绑定弹性公网 IP，只保留内网地址，应用通过内网访问。第二，管理操作走堡垒机或 VPN，云服务器的管理端口只对堡垒机放行。第三，确实需要临时从公网排查问题的场景，可以临时添加一条限定源 IP 的规则，排查结束立即删除，而不是长期保留一条宽松规则。第四，定期自查实例上实际监听的端口，对照安全组规则做一次“账实相符”的核对。

自查可以用系统自带的工具完成，例如在 Linux 云服务器上执行：

ss -tlnp

这条命令会列出本机正在监听的 TCP 端口和对应的进程。把输出结果和安全组入方向规则逐一对照：凡是正在监听、却不应该对外提供服务的端口，要么关闭服务，要么确认安全组没有放行它。这个对照动作每个月做一次，就能发现不少“悄悄长出来”的暴露面，比如开发调试时临时启动的服务忘记关闭。

七、原则六：定期审计与变更留痕

安全组最怕的不是配错一次，而是长期无人打理：人员变动后旧规则没人敢删，临时放行的端口变成永久规则，历史遗留的宽松规则越积越多。对抗这种熵增，需要制度化的审计。

建议建立每月一次的例行审计，内容包括：列出所有对 0.0.0.0/0 开放的端口并复核必要性；清理来源为已下线 IP 或已废弃网段的规则；删除标注为“临时”但已超期的规则；确认每个安全组都有明确的负责人和用途说明。审计结果应当留档，规则的每一次增删改都应当能追溯到需求或工单，而不是某个人随手的操作。

云上也提供了辅助手段：通过云审计服务记录安全组规则的变更操作，出现异常变更时可以回溯；通过 VPC 流日志观察实际流量，验证规则是否按预期工作，例如某条放行规则长期没有任何流量命中，就值得怀疑它是否还有存在的必要。审计的意义不在于一次查出多少问题，而在于让规则库始终处于可解释、可追溯的状态。

八、一个可以直接照抄的检查清单

把前面的原则收敛成一份清单，新建或接手一套环境时逐项核对：

1. 是否存在放行全部端口或 1-65535 端口段的规则？如有，立即收紧。
2. 除 80、443 外，是否还有对 0.0.0.0/0 开放的端口？逐条复核。
3. 22、3389 等管理端口是否只对指定地址放行？
4. 数据库、缓存等数据层服务是否没有公网 IP、只对应用层安全组放行？
5. 安全组是否按 Web、应用、数据分层，源地址是否优先使用安全组而非固定 IP？
6. 数据库所在子网的网络 ACL 是否兜底拒绝了公网来源的数据库端口？
7. 本月是否执行过 ss -tlnp 对照检查，监听端口与安全组规则是否一致？
8. 是否有超过 30 天无人复核的“临时”规则？
9. 安全组变更是否有记录可查，负责人是否明确？
10. 出方向规则是否至少收敛到了“已知必需”的范围？

结语

安全组配置没有一劳永逸的终点，它更像是一项持续的整理工作：业务在变、人员在变、IP 在变，规则库如果不定期整理，就会慢慢偏离最初的意图。最小权限、按角色分层、源地址具体化、双层防护、定期审计，这几条原则都不复杂，难的是坚持执行。把这份清单固定为每月一次的例行动作，云上网络的暴露面就会长期保持在可控范围之内。与其等到出问题再补救，不如现在就花半小时，对照清单把自己负责的安全组检查一遍。