事件概述 - 一家墨西哥三人初创公司的Google Cloud API密钥被盗，导致在48小时内产生了82,314.44美元（约合人民币57万元）的异常费用，而该公司正常的月均云服务支出仅为180美元，费用激增了约457倍 [2][3][4][5] - 异常费用几乎全部来自Gemini 3 Pro图像与Gemini 3 Pro文本服务的调用 [4] - 公司已采取删除密钥、禁用API、轮换凭证、启用双因素认证等标准安全措施，但谷歌方面依据“共享责任模式”表示客户需对凭证管理负责，因此费用仍需由客户承担，这可能导致公司破产 [5][6][7][12] 系统与风控问题 - 谷歌云计费系统缺乏针对灾难性使用异常的基本防护措施，例如：当使用量达到历史水平的5倍或10倍时，没有自动硬性停止机制；在极端峰值下，没有强制确认要求；没有临时冻结待审查的机制；没有默认的单API消费上限 [5][10][11] - 生成式AI API（如Gemini）的调用成本远高于传统Web服务，一旦凭证泄露，高并发调用可在极短时间内累积巨额费用，这对小型团队构成生存威胁 [12] 安全架构与设计缺陷 - 谷歌云使用单一的API密钥格式（如AIza…）用于两个根本不同的目的：公开身份识别和敏感身份验证，这造成了混淆 [16] - 历史问题在于，谷歌曾告知开发者API密钥可安全嵌入客户端代码（如用于Google Maps），但Gemini API启用后，同一项目中现有的、已公开部署的API密钥会**静默获得访问敏感Gemini端点的权限**，而没有任何警告或通知 [23][24] - 创建新的API密钥时默认设置为“不受限制”，这意味着它会立即对项目中所有已启用的API（包括Gemini）生效，存在不安全的默认设置问题 [24][27] - 安全研究员扫描发现，有2,863个公开的谷歌API密钥存在此类权限提升漏洞，可从前端代码（如网页）中获取并用于访问Gemini API，受害者包括大型金融机构、安全公司等 [29][30] 潜在风险与影响 - 攻击者利用被盗的API密钥不仅可以导致账单飙升，还可能访问用户通过Gemini API上传的文件、缓存的数据集等私有数据 [14][31] - 对于现金流紧张的小型创业公司，此类异常账单可能直接导致破产，突显了云服务成本失控对初创企业的巨大风险 [7][8][12] - 该事件在技术社区引发广泛讨论，焦点集中在平台责任、风控机制设计以及开发者的配置管理上 [32] 行业讨论与建议 - 社区讨论指出，云服务提供商应提供更明确、可配置的“硬性消费上限”机制，以在费用异常时自动中断服务 [32] - 有观点认为，通过工作负载身份和权限（IAM）进行访问控制，比依赖API密钥更安全 [35][36] - 建议受影响的开发者检查是否拥有涵盖云服务异常账单或安全事件的技术责任保险，以作为风险缓冲 [34] - 尽管谷歌安全团队已开始将报告的泄露密钥纳入检测流程并承诺修复根本原因，但尚未看到具体成果，问题根源在于为不同时代设计的密钥管理架构被沿用至Gemini这样的高成本服务 [31]

事件概述 - 一家位于墨西哥、仅有三名开发者的初创公司，其Google Cloud API密钥被盗用，在48小时内产生了高达82,314.44美元（约合人民币57万元）的账单，而该公司正常的月度云服务支出约为180美元 [3][4][5] - 异常账单主要来自Gemini 3 Pro图像与文本服务的调用，金额是正常月度支出的约457倍 [4][5] - 公司立即采取了删除密钥、禁用API、轮换凭证等标准安全措施，但谷歌方面依据“共享责任模式”，表示客户需对凭证管理负责，因此账单仍需支付，这可能导致公司破产 [5][6][7] 技术安全漏洞分析 - 安全研究员指出，谷歌使用单一格式的API密钥（AIza...）用于两个不同目的：公开身份识别和敏感身份验证，这为安全漏洞埋下隐患 [16] - 核心问题在于“追溯性权限扩展”：当在一个已存在旧API密钥（如用于Google Maps）的Google Cloud项目中启用Gemini API后，该旧密钥会静默获得访问敏感Gemini端点的权限，而项目所有者不会收到任何警告 [23][24] - 另一个关键问题是“不安全的默认设置”：在Google Cloud中创建新的API密钥时，默认设置为“不受限制”，可立即访问项目中所有已启用的API（包括Gemini） [24] - 安全公司Truffle Security通过扫描公开网页数据，发现了2,863个存在此类权限提升漏洞的Google API密钥，涉及大型金融机构、安全公司等实体 [30] - 攻击者一旦获取此类暴露在公共代码中的API密钥，不仅可以导致受害者账单飙升，还可能访问其通过Gemini API上传的私有数据和缓存内容 [13][31] 云服务计费与风控机制缺陷 - 受害者质疑云服务商缺乏针对灾难性使用异常的基本防护措施，例如：当使用量达到历史水平的5倍或10倍时，没有自动硬性停止机制；没有对极端峰值进行强制确认；没有默认的单API消费上限 [5][10][11] - 社区讨论指出，由于云服务费用结算通常存在24至36小时的延迟，实现真正的“即时硬性封顶”在系统架构上存在复杂性 [32] - 有观点认为，开发者应自行设置消费限制，并为未设置硬性限制的配置错误承担责任 [33] 行业影响与讨论 - 该事件折射出生成式AI API调用成本高昂带来的结构性焦虑，凭证泄露后，高并发调用可在极短时间内累计巨额费用，这对小型创业团队可能是致命打击 [12] - 技术社区围绕责任归属展开讨论，一方同情小公司处境，认为平台应在极端异常场景提供缓冲；另一方则强调开发者自身配置和风控设置的责任 [12][32][33] - 有资深从业者建议，应厘清“被盗”定义（是系统被入侵还是凭证无意泄露），并检查是否拥有可覆盖此类事件的网络安全保险 [34] - 从最佳实践角度，建议通过工作负载身份和权限管理来授予访问，而非依赖API密钥，以提升安全性 [35] 供应商响应与后续 - 在安全研究员披露漏洞后，Google Cloud漏洞披露计划团队扩展了其泄露凭证检测流程，以保护客户，并承诺修复根本原因，但截至报告时尚未看到具体成果 [31]