信任边界重叠：云安全机制为何常常形同虚设

安全组配了、WAF 开了、堡垒机也上了，真出事那天翻日志，攻击者走的是一条谁都没设防的内网通路。这种事在云上不算少见，事后复盘往往发现每个环节都“工作正常”，绿勾一排，就是没人拦住。信任边界重叠云安全机制为何常常形同虚设，问题不在哪个产品菜，而在于边界被画了好几层，层与层之间的缝隙没人认领。

每个组件都默认别人在守门

安全组觉得内网流量是自己人，主机防火墙觉得安全组已经拦过一轮，应用层鉴权觉得网关做过认证，网关觉得自己只对公网负责。这套默契在单机时代勉强凑合，上了云、加了 VPC、接了负载均衡和 CDN 之后，每一层的“上游”都换了人，可假设还是老的那一套。于是出现一种挺别扭的状态：控制台里安全产品一片祥和，真出问题一查，绕过去的那条路干干净净，一条告警都没留下。

还有个细节容易被忽略：这些东西的默认策略往往是“用起来方便”，不是“关起来安全”。开一台新机器，端口先跑通再说，策略先放行再收紧，结果“再收紧”这一步永远排在明天。

信任边界重叠云安全机制为何常常形同虚设，三处缝隙最常见

第一处是网络打通。VPC 对等连接、专线、VPN 一接，两个本来互不相干的信任域就黏在一起了，A 网里一台被打穿的小机器，能直接去敲 B 网数据库的门，而 B 网的安全组里常常写着允许整个内网段进来。第二处是回源。流量走 CDN 和 WAF 的时候防护是有的，可源站 IP 一旦泄露，攻击者直接打源站，那一层就等于不存在。

第三处是权限。图省事给子账号挂个管理员策略，或者把长期 AK 写进配置文件里，前面网络层做得再细也没意义，凭证本身就是通行证。这三处有个共同点：它们都不属于任何单一产品的责任范围，所以最容易空着。

内网默认可信，是笔老账

很多架构在起步阶段都图快：数据库只监听内网、Redis 不设密码、内部管理后台只允许内网访问。这些做法在“内网就是机房那几台机器”的年代说得过去，云上内网的范围早就变了，快照、镜像、容器网络、临时实例、外包人员的跳板机，全在这张网里。东西向流量没有边界，横向移动的成本就低得离谱。

更麻烦的是，这类问题很少在第一次扫描里冒出来，因为它不叫漏洞，叫配置。扫描器不会告诉你“这台机器太相信隔壁那台”。

权限宽一寸，防线退一丈

云上的 IAM 其实有两层，一层是谁能调 API，一层是这个资源能被谁访问。前一层常被写成“先用管理员，回头再收”，回头一般不会来；后一层常见的是存储桶策略开成公开读、角色信任策略写成允许整个账号甚至所有人切换。这些东西在控制台里看着不起眼，实际是把边界直接抹掉了。

有个顺序上的经验：做权限收敛别指望一次到位。先把长期密钥换成临时凭证，再按实际调用记录把管理员策略削一轮，最后才动那些历史遗留的角色。反过来做，很容易在业务高峰出事故。

日志各说各话，等于没有日志

WAF 一套日志、云防火墙一套、主机安全一套、应用自己再一套，时间还不同步，出了事得几个人对着导出的表格拼图。更常见的是告警重叠：同一个扫描被三个产品同时报，真正的横向登录尝试一个都没覆盖。值班的人被无用告警喂了几个月，慢慢就不看了。

想改善不用一上来就上大平台。先把时间同步对齐，把关键资产的登录、提权、外联这三类事件集中到一处，再定一条“谁能拍板处置”的规则，比买什么系统都实在。

把几张重叠的边界捋成一条线

动手的次序我一般这么排：先画一张数据流图，标清楚每个入口是谁在做认证、谁能绕过它；然后按资产分级，核心库和后台单独划子网、单独安全组，默认拒绝一切东西向访问，需要开的口子写清用途；回源这块，源站只放行防护节点的回源地址段，或者干脆做源站隐藏；凭证层面，长期密钥退役，临时凭证配上权限边界；最后做一次验证，把 WAF 关掉、或者从内网直连源站，看看到底还剩几层拦得住。

这一步最容易被跳过，因为验证结果通常不好看。但只有关掉一层看剩下的，才知道你的防线是叠着的还是串着的。具体到某个云厂商的策略写法、地址段、产品开关，各家的控制台差别不小，以服务商官方文档页面说明为准，别照抄别人的截图。

安全这行当里没有哪一层能单独顶住。产品买得再多，边界画重了、画歪了，缝隙还是那几条缝隙。下回做评估，先别数控制台里有几个绿勾，问一句就够了：这条路上，每一层到底在信谁。