谷歌曾称“非秘密”的密钥，在Gemini时代成提款机：三人创业团队48小时濒临破产

"我现在处于震惊和恐慌之中。"这是帖子的开头。没有铺垫，没有背景说明，只有一句情绪几乎溢出屏幕的自白。 1. 开发者Gemini账户被盗，48小时损失57万 在Reddit发帖的人，是一家位于墨西哥的初创公司联合创始人，公司只有三名开发者，规模很小，每月在谷歌云服务上的正常支出大约180美元。对他们来说，云账单是一项可控成本，是创业早期可以精确计算的变量。 但2月11日至12日这48小时，一切都失控了。 在这两天里，他们的Google Cloud API密钥被盗用。具体怎么发生的，他们至今不清楚。“我们不知道是怎么回事，也没有发现明显的错误。”他说。 但账单记录非常清晰：总额82,314.44美元（约合人民币57万）。几乎全部来自两项服务——Gemini 3 Pro图像与Gemini 3 Pro文本。 180美元与82,314美元之间，是457倍的差距。 那一刻，这不再是技术问题，而是生存问题。 他们第一时间采取了所有能想到的补救措施：删除泄露的密钥，禁用Gemini API，轮换全部凭证，在所有账号上启用双因素认证，收紧身份与访问管理（IAM）权限，并向谷歌提交了支持请求。从操作流程上看，这是一次标准、迅速且完整的安全响应。 但真正让他感到恐慌的，是随后与平台沟通的结果。 根据他的说法，谷歌方面提到了Google Cloud的“共享责任模式”——平台负责基础设施安全，用户负责凭证管理。因此，这笔未经授权产生的API费用，仍然需要由客户承担。 “这真的让我非常担心。”他写道，“如果谷歌试图强制收取哪怕三分之一的费用，我们公司就会破产。”这不是夸张的修辞。对一家现金流本就紧张、寄希望于产品爆发的三人团队而言，哪怕2万多美元的账单，都足以击穿银行账户余额。 他反复强调，他们是一家小公司。这笔账单远远超出了公司的承受能力。 但让他难以理解的，不只是费用归属问题，而是整个系统的风控逻辑。 在他看来，这82,000多美元并不是“正常波动”，而是明显的异常滥用行为。48小时内，从月均180美元的基线，暴涨到8.2万美元，系统却没有触发任何强制停止机制。 “为什么没有针对灾难性使用异常情况的基本防护措施？”他提出一连串问题—— 为什么当使用量达到历史水平的5倍或10倍时，没有自动硬性停止？ 为什么在极端峰值下，不需要强制确认？ 为什么在审查期间，没有临时冻结？ 为什么没有默认的单API消费上限？ 这些问题并不带有攻击性，更像是一个技术人员在复盘事故时的困惑。对他来说，API密钥被盗已经是既成事实，但计费系统为什么允许异常规模在48小时内持续放大，是另一层无法理解的风险。 帖子的最后，他向社区求助：有没有人成功申诉过类似情况？有没有减免费用的经验？他甚至向FBI提交了网络犯罪报告，希望通过正式渠道记录这次攻击。 截至发帖时，谷歌方面的态度仍然是：除了付款，没有别的选择。 这篇帖子之所以引发大量关注，并不是因为8万美元这个数字本身，而是它折射出的结构性焦虑。生成式AI API的调用成本远高于传统Web服务接口，一旦凭证泄露，高并发调用可以在极短时间内累计巨额费用。对于大企业而言，这或许只是一次可谈判的异常账单；对于小团队而言，却可能是一次致命打击。 “简而言之，”他在帖子中总结，“Gemini API密钥被盗，48小时内产生82,314美元费用。我们正常月费180美元，飙升457倍。我们已经采取安全措施，但谷歌以‘共同责任’为由拒绝赔偿。如果坚持收取费用，我们将破产。” 目前尚不清楚这家墨西哥公司的最终结局。是否减免费用、是否达成和解、是否能继续运营，都还是未知数。但可以确定的是，这48小时，已经成为他们创业过程中最沉重的一课。 2. 研究员揭露谷歌API密钥核心问题 《The Register》援引安全公司Truffle Security安全研究员Joe Leon的博客内容，进一步揭示了问题的结构性根源。Leon在2月25日的文章中写道：“有了有效的密钥，攻击者就可以访问上传的文件、缓存的数据，并将LLM使用量计入您的帐户。” 它意味着风险并不局限于“刷调用次数”导致账单飙升，还可能涉及数据访问与缓存内容读取。API Key不再只是计费通道，而可能成为访问路径。 Joe Leon在博客中详细解释了为什么谷歌API密钥（例如用于地图、Firebase等服务的密钥）并非秘密这件事在以前没什么问题，但Gemini出来后，情况就变了，核心问题到底是什么。 Joe Leon在博客中提到，Google Cloud使用单一API密钥格式(AIza...)用于两个根本不同的目的：公开身份识别和敏感身份验证。 多年来，谷歌一直明确告知开发者，API密钥可以安全地嵌入客户端代码中。Firebase自身的安全检查清单也指出，API密钥并非秘密信息。 注意：这些与用于支持GCP的服务帐户JSON密钥截然不同。 Google Maps JavaScript文档还直接指示开发者将密钥直接粘贴到HTML中。 这合情合理。这些密钥被设计为用于计费的项目标识符，并且可以通过诸如HTTP Referer允许列表之类的（可绕过的）控制措施进一步限制。它们并非设计为身份验证凭据。 但Gemini出现后情况变了。 在Google Cloud项目中启用Gemini API（生成式语言API）时，该项目中现有的API密钥（包括网站公共JavaScript代码中的密钥）可能会在后台静默访问敏感的Gemini端点。 没有任何警告、确认对话框或电子邮件通知。 这就产生了两个截然不同的问题： * 追溯性权限扩展。比如三年前，您创建了一个Maps密钥，并按照Google的指示将其嵌入到您网站的源代码中。上个月，您团队的一位开发人员为内部原型启用了Gemini API。现在，您的公钥已变成Gemini凭证。任何抓取该凭证的人都可以访问您上传的文件、缓存的内容，并导致您的AI费用飙升。没有人告诉过您这一点。 * 不安全的默认设置。在Google Cloud中创建新的API密钥时，默认设置为“不受限制”，这意味着它立即对项目中所有已启用的API（包括Gemini）都有效。用户界面会显示“未经授权使用”的警告，但这种默认架构完全开放。 结果是：数千个原本作为良性计费token部署的API密钥现在变成了存在于公共互联网上的Gemini实时凭证。 之所以说这是权限提升而不是配置错误，是因为事件发生的顺序。 1. 开发者创建了一个API密钥并将其嵌入到地图网站中。（此时，该密钥是无害的。） 2. Gemini API已在同一项目中启用。（现在，同一个密钥可以访问Gemini的敏感端点。） 3. 开发人员从未被告知密钥的权限在其底层发生了变化。（密钥从公共标识符变为秘密凭证 虽然用户可以限制Google API密钥（按API服务和应用程序），但漏洞在于不安全的默认设置(CWE-1188)和不正确的权限分配(CWE-269)： * 隐式信任升级：Google将敏感权限追溯性地应用于已在公共环境中合法部署的现有密钥（例如，JavaScript包）。 * 密钥分离不足：安全的API设计需要针对不同的环境（公开密钥与私钥）使用不同的密钥。如果对两者都使用同一种密钥格式，系统就容易出现安全漏洞和混乱。 * 安全默认值失效：通过GCP API面板生成的密钥的默认状态允许访问敏感的Gemini API（假设已启用）。用户在为地图组件创建密钥时，会在不知情的情况下生成具有管理权限的凭据。 那攻击者能做什么？ 攻击者访问您的网站，查看页面源代码，并AIza...从地图嵌入中复制您的密钥。然后他们运行： curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY" 403 Forbidden他们得到的不是a，而是200 OK。攻击者由此可以： * 访问私有数据。and /files/端点可以/cachedContents/包含上传的数据集、文档和缓存的上下文。项目所有者通过Gemini API存储的任何内容均可访问。 * 账单飙升。Gemini API的使用并非免费。根据具体模型和上下文窗口，攻击者如果滥用API调用，可能每天仅一个受害者账户就会产生数千美元的费用。 * 用完您的配额。这可能会导致您的Gemini合法服务完全停止。攻击者根本不会触碰你的基础设施。他们只是从公共网页上窃取密钥。 为了解问题的严重程度，Truffle Security扫描了2025年11月的Common Crawl数据集，这是一个庞大的（约700 TiB）网页存档，其中包含从互联网上公开抓取的HTML、JavaScript和CSS网页。Truffle Security团队发现了2,863个存在权限提升漏洞的Google API密钥。 前端源代码中用于Google Maps的示例Google API密钥，但也可以访问Gemini。 Truffle Security团队指出，这些并非业余爱好者的副业项目。受害者包括大型金融机构、安全公司、全球招聘公司，以及谷歌自身。如果供应商自己的工程团队都无法避免这个陷阱，指望每个开发者都能正确应对是不现实的。 在Truffle Security团队提出一系列漏洞及其相关证据后，GCP VDP团队开始认真对待这个问题。 他们扩展了泄露凭证检测流程，将Truffle Security团队报告的密钥纳入其中，从而主动保护真正的谷歌客户免受利用其Gemini API密钥的威胁行为者的侵害。他们还承诺修复根本原因，但Joe Leon表示他们尚未看到具体成果。 Joe Leon写道：“构建像谷歌这样规模的软件极其困难，而Gemini API沿用了为不同时代设计的密钥管理架构。谷歌已经意识到我们报告的问题，并采取了切实有效的措施。目前尚待解答的问题是：谷歌是否会告知客户其现有密钥存在的安全风险，以及Gemini最终是否会采用不同的身份验证架构。” 3. 网友：我可能会跪求谷歌退款！ 这位墨西哥开发者的经历，很快在技术社区引发了广泛讨论。围绕责任归属、平台机制以及开发者自身配置问题，观点分化明显。 不少Reddit用户对他的处境表示强烈同情。一位网友直言，如果自己遇到这种情况，“恨不得飞到谷歌总部，跪在地上求他们退款。”在这些人看来，对于一家仅有三名成员的小公司而言，8万多美元的账单几乎等同于“致命打击”。即便技术上存在疏漏，平台也应在极端异常场景下提供更多缓冲或协商空间。 但也有用户将讨论焦点转向机制设计本身。他们指出，Google Cloud的API Key体系确实应该提供更明确、可配置的“硬性消费上限”。一旦触及某个阈值，系统应自动中断服务，而不是仅发送提醒。与此同时，也有人提到技术实现层面的复杂性——云费用往往并非实时结算，而是在产生后24小时甚至36小时内逐步计入账单。如果计费数据本身存在延迟，那么要做到真正意义上的“即时硬性封顶”，在系统架构上可能并不简单。 还有网友认为谷歌方面没什么错，而是他们自己忽略硬性设置造成的错误。他表示： “但现在已经有了这些硬性限制设置，我完全不明白楼主为什么还要因为他们糟糕的配置错误而责怪谷歌……至少要承认，没有设定硬性限制是一个巨大的错误。” 在这起API账单风波引发广泛讨论后，一位有多年云服务经验的网友给出了相对冷静的分析。 他首先提出一个关键问题：“所谓‘被盗’，究竟是什么意思？”在他看来，这个定义本身至关重要。 “是有人真正入侵了系统、突破防线窃取数据？还是开发者在配置或代码管理过程中无意间泄露了凭证？这两种情况在责任划分与后续处理上完全不同。如果是系统层面的安全入侵，性质更严重；如果是凭证暴露，则更可能被视为配置风险。厘清这一点，是与平台沟通的第一步。” 这位网友还提醒，当事人应检查是否拥有网络安全或技术责任相关的保险。有些公司会为云服务异常账单或安全事件投保，在特定条件下可以申请理赔。虽然这并不能解决根本问题，但在现金流紧张时，可能成为缓冲手段。 还有网友表示，通过权限访问比通过密钥访问要靠谱得多。 “这就是为什么应该通过权限而不是密钥来授予访问权限，以及为什么工作负载身份如此重要的原因。”