安全组宽规则的持续巡检方案

我见过太多这样的场景：排查一个线上问题，手一抖在安全组里加了一条“源地址 0.0.0.0/0、端口全放通”的临时规则，问题解决了，规则却忘了删。等过几周想起来去翻控制台，才发现自己的数据库、缓存和 SSH 端口一直在全网裸奔，扫描器早就把实例当成了靶子在打。

更麻烦的是，治理这种宽规则不能“一刀切”。直接删掉规则，运气好只是断一下线上连接，运气差就是正在跑的部署脚本失败，甚至把自己锁在服务器外面。我踩过这个坑之后，慢慢整理出一套持续巡检的思路，核心就一句话：不要等出事了再清理，而是让“查宽规则”变成日常运维的固定动作。

先说巡检最该盯什么。我自己的习惯是重点看三类端口：管理通道（SSH 的 22、RDP 的 3389）、数据组件（MySQL 的 3306、Redis 的 6379）、以及面板类服务（8888 这类）。每次巡检先登录实例跑一下 ss -tulpn | grep LISTEN，看清楚服务到底监听在哪个地址上。这里有个容易忽略的细节：如果服务只监听 127.0.0.1，那安全组开了公网也连不进来；真正危险的是监听在 0.0.0.0 或 ::: 上的服务，它们的安全完全取决于安全组和主机防火墙怎么配。

收敛的时候，我坚持“先加白、后删宽”的顺序。在删掉那条 0.0.0.0/0 规则之前，先新增一条只允许办公网固定 IP 或堡垒机 IP 访问的精确规则，然后新开一个终端窗口测试连通性，确认白名单生效了，再去删宽规则。这个过程千万别省，我见过有人图快直接删，结果自己 SSH 断在外面，最后只能靠云控制台的 VNC 进去救火。

巡检不能只看控制台，还要做外部验证。从一台不在白名单里的机器用 nc 探测一下高危端口，如果返回超时说明安全组正确拦截了；如果显示连接成功，那就说明收敛失败了，得赶紧回去查。同时也要在应用节点上测一下内网连通性，确认 Web 能正常连上数据库和缓存，别让收敛变成新的故障源。

最后是规则的生命周期管理。我给自己定了一条铁律：临时调试规则必须带过期时间，在备注里写明“临时-姓名-日期”。同时用云厂商的配置审计功能设告警，只要出现源地址为 0.0.0.0/0 且放通高危端口的新增规则，就自动推消息到群里。这样就算有人手滑加了宽规则，也能在第一时间被发现，而不是等到被爆破成功才反应过来。

说到底，安全组宽规则的治理不是一次性的大扫除，而是需要持续盯着的习惯。每次改完规则多花两分钟验证一下，每次开临时端口都记得写备注和过期时间，长期下来，公网暴露面自然就收住了。