文章总结： CISA承包商在GitHub公开代码库中泄露了包含AWSGovCloud访问密钥的内部代码，导致美国政府敏感云环境面临严重风险。事件暴露了供应链安全薄弱环节和AI工具可能加剧密钥泄露的趋势，建议开发者永远不要将密钥硬编码在源代码中。 综合评分： 84 文章分类： 数据泄露,云安全,供应链安全,安全意识,安全运营

CISA 管理员将 AWS GovCloud 密钥泄漏

原创

骨哥说事 骨哥说事

骨哥说事

2026年5月19日 10:27 上海

在小说阅读器读本章

去阅读

#

#

防走失：https://gugesay.com/

不想错过任何消息？设置星标↓ ↓ ↓

#

想象一个场景：你是一家国家级金库的安检员，每天的工作是检查门锁是否牢固、监控探头是否开启。但你的同事，却把一串 写着“主金库总钥匙位置”的纸条，随手贴在人来人往的市中心公告栏上。

荒诞吧？

然而，就在最近，美国网络安全界的“金库安检员”——大名鼎鼎的网络安全和基础设施安全局（CISA），其承包商就把比这更致命的“钥匙”插在了互联网的公告板上。

这起事件，让许多安全专家不禁感慨：今天，最坚固的系统，可能正在被最脆弱的“人”亲手瓦解。

最该防贼的人，把自家门禁卡丢了

一家与CISA（美国网络安全和基础设施安全局）合作的承包商，犯了一个令人瞠目的“低级错误”：他们将内部开发代码上传到了全球最大的程序员社交网站——GitHub的公开代码库里。

这本来没什么，分享代码在程序员圈子里是常事。

但问题在于，这些代码里，竟然明文镶嵌着一套能打开美国政府最敏感云环境大门的“钥匙串”：

• AWS Access Keys & Secret Keys：像“账号+密码”一样，是访问亚马逊云服务的通行证
• GovCloud配置凭证：这把“钥匙”最要命，它能打开一个名叫 AWS GovCloud 的特殊区域
• 多个内部管理后台的登录信息

说白了，这家公司不仅把设计图（代码）公开了，还把建造金库所需的所有门禁卡、密码锁组合，甚至几道安全门的通用密码，一并附在了后面。

消息一出，安全圈的从业者们在推特上炸了锅。一位资深工程师的吐槽一针见血：“都2026年了，居然还有团队能把云服务的最高权限钥匙扔在GitHub上晒太阳？”

讽刺感瞬间拉满：CISA的职责之一，就是指导全美政府和关键基础设施如何防御此类数据泄露。结果呢？自己的“队友”成了活生生的反面教材。这就好比消防局的合作单位，在消防局门口堆满了汽油桶，还把打火机放在上面。

钥匙开启的可不是普通仓库

如果你觉得，这不过是又一起“程序员手滑把测试密码上传”的小事故，那你就小看它的严重性了。

关键在于那个 AWS GovCloud。这可不是你我平时用的“普通云服务器”。

你可以把它理解为云服务世界里的“五角大楼专供区”或“国家级禁飞区”。它是亚马逊专门为美国政府、国防机构、执法部门以及涉及国家命脉的关键行业（如电网、金融结算）打造的，物理和逻辑上都与公共云完全隔离的超高安全环境。

在GovCloud里运行的系统，处理的数据可能是：

• 国防部的后勤信息
• 联邦调查局（FBI）的部分案件数据
• 国家应急响应中心的指挥系统
• 高度敏感的公民个人信息库

所以，泄露的不仅仅是几行代码或密钥，而是通往“国家数字禁区”的后台通行证。 拿到这些凭证的攻击者，理论上可以像合法管理员一样：

1. 随意访问、删除或窃取其中的敏感数据；
2. 部署恶意软件，长期潜伏；
3. 甚至利用这个“合法跳板”，向更高价值的内部网络发起“横向移动”。

这已经不是“家”被偷了，而是“军火库”的门被焊死了，但钥匙却挂在了门外把手上。

是“神队友”还是“猪队友”？

这次事件，也向我们揭示了一个更令人不安的新趋势：AI工具正在成为密钥泄露的“加速器”。

想想这个场景：一名开发者遇到一个复杂的云配置问题，他习惯性地把整个出错的配置文件（里面可能包含了密钥）复制下来，丢给AI编程助手，问：“嘿，帮我看看哪里错了？” 或者，为了让AI帮忙生成自动化脚本，他把整个项目代码库（内含敏感配置）都上传了。

在这个过程中，人类对敏感信息的警惕性，被AI的高效便捷性“麻痹”了。这催生了新型的“影子IT”——员工未经安全审批，就使用外部AI工具处理本应严格隔离的内部数据。

近期已有多起事故与此相关：OpenAI的API密钥在代码分享中被抓取、企业核心的Kubernetes配置文件被提交到公开仓库……AI在提升我们生产力的同时，也在系统性放大我们的攻击面。 它让“犯错”的成本更低，而发现“犯错”的难度却在几何级增加。

我们正生活在一个“外包”的世界里

为什么又是“承包商”出事？这并非偶然，而是现代IT生态的必然痛点。

无论是政府还是大型企业，其核心系统的建设与维护，早已是一个庞大的、层层嵌套的“外包网络”。CISA的很多项目，也必然依赖第三方安全公司、软件开发团队和云服务集成商。

这就带来一个根本性的安全悖论：你把最核心的堡垒交给别人建造和维护，但你无法确保每一家外包商的每一个员工，都拥有和你同等级别的安全意识和纪律。

这就像一座城堡，你自己把守的城门固若金汤，但后厨采购员进出的小门，锁却锈迹斑斑，甚至为了方便，长期虚掩着。攻击者根本不用攻击你的城门，他们只需要跟踪那个采购员，或者，等着他把钥匙弄丢。

从震惊世界的SolarWinds供应链攻击，到影响数万企业的MOVEit文件传输漏洞，再到这次CISA承包商的GitHub泄露，都在反复验证一个残酷真理：在现代网络战中，最薄弱的一环，往往不在你的防火墙内，而在那条你不得不依赖的、漫长的“信任链”上。

守住那串“数字时代的万能钥匙”

CISA“钥匙”泄露事件，是一面昂贵的镜子，照出了云时代安全管理的集体焦虑。它告诉我们：

• 技术越先进，人性的疏忽就越致命。 再厉害的技术堡垒，也抵不过一次“手滑”。
• 安全的重心，必须从“防外部攻击”向“管内部行为”倾斜。 尤其要管理好那些能打开一切的“秘密”（Secrets）。
• 在拥抱AI加速的同时，必须建立与之匹配的“AI数据安全护栏”，防止高效工具成为泄密通道。

对我们每个普通开发者或项目管理者而言，教训朴素而直接：

永远、永远不要把密钥、密码、令牌等任何秘密信息，直接写进你的源代码、配置文件，然后提交到任何代码仓库——无论你认为它有多么私有、多么临时。

因为在这个“代码即基础设施”的数字世界里，那些看似不起眼的 API Key、Access Token，才是真正掌控一切的“root权限”。一旦它们流落街头，攻击者甚至不需要成为技艺高超的“窃贼”，他们只需弯下腰，捡起那把被主人遗忘在门口的、闪闪发光的钥匙。

参考资料：

• KrebsOnSecurity – CISA Admin Leaked AWS GovCloud Keys on GitHub

• Amazon AWS GovCloud 官方介绍

• END –

感谢阅读，如果觉得还不错的话，动动手指给个三连吧～

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：骨哥说事 骨哥说事 骨哥说事《CISA 管理员将 AWS GovCloud 密钥泄漏》