云上防火墙别只守入口：出站流量才是数据外泄的主通道

不少团队做云上加固时，习惯把精力全放在入口：关闭高危端口、收敛公网 IP、给 SSH 加跳板机。这些动作有效，但只解决了一半问题。打开安全组详情会发现，入站规则往往只有寥寥几条，出站规则却是一条 0.0.0.0/0 全放行。入口被守成了堡垒，出口还是敞开的大门。

一、入口越收越紧，出口依然敞开
云厂商安全组的默认行为是入站拒绝、出站放行，这个设计方便业务快速跑通，也埋下了隐患。一台被 Getshell 的 ECS，只要还能访问互联网，攻击者就可以用 curl 或 wget 把数据库导出文件直接推到自己的对象存储，全程走 HTTPS 443，和正常调用第三方 API 没有区别。按 100 Mbps 的出网带宽计算，20 GB 数据传完大约只需 27 分钟，而监控大盘上只会看到一条普通的带宽上涨曲线。

更麻烦的是，很多事故复盘只查入站告警和登录日志，不看目的地址分布，导致"主机被入侵"确认了，"数据是否泄露"却始终说不清。

二、三种最常见的出站外传路径
第一种是 HTTP 上传。攻击者不需要自建服务器，用公开的对象存储、网盘甚至社交平台接口都能落地数据，成本接近于零。第二种是 DNS 隧道。DNS 查询几乎不会被防火墙拦截，攻击者把数据编码进子域名，单次查询塞进一百来字节，一小时也能搬运几 MB，量不大但足够偷走密钥、配置和用户表结构。第三种是借用云服务 API。对象存储、数据库、消息队列的域名都在白名单里，攻击者用失窃的临时凭证调用它们，流量方向完全"合规"。

这三种路径的共同点，是都不需要新的入站端口。只盯入口的防护体系，对它们几乎失效。

三、把出口当入口管
出站管控不等于"一刀切断网"，而是按业务画像给白名单。数据库只允许访问备份存储与监控端点，Web 前端只允许访问指定的 API 网关和依赖仓库，其余一律拒绝。对无法枚举的第三方调用，走统一出口代理，由代理完成域名鉴权与日志留存，既保留灵活性，也让每一次外连可追溯。

配套要做三件事：一是把安全组的出站规则纳入代码化管理，禁止控制台随手加 0.0.0.0/0；二是对 DNS 做集中解析，记录查询域名长度与熵值，异常长的随机子域名基本就是隧道特征；三是保留 VPC 流日志，至少记录五元组，出现大流量外连时能反查是哪台主机、哪个进程。云防火墙类产品可以做出站域名白名单和告警，但规则背后仍需要一张业务流量地图，否则只会把正常调用也拦掉。

四、落地顺序：先画地图，再动规则
建议先用两周采集全量出站流量，按"主机—目的域名—端口—时段"聚合，分出核心依赖、偶发调用和无人认领三类。第一轮只对无人认领的流量做拒绝并观察一周，确认没有误杀后再收紧核心依赖。同时给高风险主机（对外提供服务的 ECS、承载数据库的节点）单独设更严的出口策略，把爆炸半径压到最小。

结语
云安全的边界不在公网入口，而在每一次数据离开 VPC 的瞬间。入站规则决定谁能进来，出站规则决定东西能不能出去。把出口当成入口一样管理，才算是完整的防线；只守一边，等于给攻击者留了一条不需要撬锁的通道。

标签：云安全,出站流量,数据防泄漏,VPC,安