云上被薅走一台GPU集群，常常只因为一行写死的AccessKey

某家做图像处理的公司，凌晨收到欠费短信：一天之内多出十几台 GPU 实例，外网下行流量十几 TB。日志里翻不到任何漏洞利用痕迹——攻击者用的是公司自己的 AccessKey，权限齐全，调用完全合法。复盘只花了一小时：开发为了联调方便，把 AK/SK 写进了前端配置，随一个对公网开放的小程序页面上线。

真正的问题不是"开发不规范"，而是密钥一旦离开可信环境，它就不再是身份，而是一张可以被无限复制的通行证。

一、AK/SK 为什么比账号密码更难防

账号密码至少有交互环节：登录触发风控，异地登录会发短信。AccessKey 恰恰相反，它就是给脚本用的——调用 API 不需要人参与，也没有二次验证的位置。

一旦泄露，攻击者拿到的是与持有者完全等同的权限：创建算力、读取对象存储、调用按量计费的模型服务。整条链路上不会出现"疑似异常登录"，因为在平台看来，这些请求来自合法密钥、合法签名。

更麻烦的是复制成本为零。一个字符串贴进聊天工具、写进一次 commit、打进一层镜像，几分钟内就可能进入扫描器的视野。公开代码托管平台的密钥扫描每年拦截的泄露凭据以百万计，相当一部分在被人发现前就已被用过。

二、三个最常见的泄露位置

前端是重灾区。 为了让浏览器或小程序直接把文件传到对象存储，不少方案把 AK 写进前端代码——这些代码对用户完全可见，等同于把钥匙贴在门上。正确做法是服务端签发临时凭证，限定有效期、桶和路径前缀、操作类型，前端只拿这份短票据。

提交历史比工作区更危险。 密钥从文件里删掉不等于它没出现过，Git 会保留每一次改动，攻击者扫全部 commit 的命中率远高于扫当前分支。这也是"删掉再提交一次"不算修复的原因，必须走密钥轮换。

构建产物是第三个死角。 把 .env 打进镜像、在 CI 里把密钥打印进日志、配置模板的占位符被换成真实值后再上传，都很常见，且往往在镜像仓库里长期存留，比源码活得更久。

三、把身份做短，把权限做窄

身份层：能用委托或角色就不发长期 AK。实例、容器、函数都可以绑定角色，由运行环境自动获取临时凭证，代码里不出现任何密钥字符串。

权限层：给每个用途单独的身份，只授予真正需要的动作和范围。只读日志的脚本不该能创建实例，只写单个前缀的上传服务不该能列出全部对象——权限越宽，横向移动越容易。

审计层：盯几类高信号行为——凌晨创建 GPU 实例、跨区域批量下载对象、密钥首次从陌生 IP 使用、短时间内大量创建类调用。账单异常通常滞后数小时，审计日志是实时的，这个时间差就是损失差额。云厂商普遍提供密钥泄露检测和轮换策略，打开的成本几乎为零。

四、出口与流量也要单独设计

即便密钥没泄露，数据从哪个口出去也值得规划。把存储和计算放在同一区域、走内网 endpoint，可以避开"读取不收费、下行收费"的账单陷阱；给桶配访问日志和防盗链，能在批量拉取时留下证据。很多事件的损失被放大，不是因为数据被读走，而是攻击者顺手把流量费和算力费刷了上去。

结语

云上事故的多数成因，不是攻防对抗的失败，而是默认值没改、临时方案留了下来。检查清单不必很长：代码里还有没有密钥字符串、身份是不是长期有效、权限是不是过宽、审计有没有人真的在看。这四条里任何一条失守，都可能让第二天的账单替安全团队做汇报。

标签：云安全、密钥管理、AccessKey、最小权限、云上审计