
来源:AI前列股市 配资
作家 | 冬梅
“我刻下处于胆寒和恐慌之中。”
这是帖子的开始。莫得铺垫,莫得布景说明,只须一句神色确凿溢出屏幕的自白。
设备者 Gemini 账户被盗,48 小时耗费 57 万
在 Reddit 发帖的东说念主,是一家位于墨西哥的初创公司纠合独创东说念主,公司只须三名设备者,边界很小,每月在谷歌云作事上的平时支拨节略 180 好意思元。对他们来说,云账单是一项可控老本,是创业早期不错精准计议的变量。
但 2 月 11 日至 12 日这 48 小时,一切齐失控了。
在这两天里,他们的 Google Cloud API 密钥被盗用。具体怎样发生的,他们于今不了了。“咱们不知说念是怎样回事,也莫得发现涌现的很是。”他说。
伸开剩余93%但账单记载相配澄莹:总数 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 小时,照旧成为他们创业过程中最千里重的一课。
议论员揭露谷歌 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 Java 文档还平直携带设备者将密钥平直粘贴到 HTML 中。
这正刚直当。这些密钥被揣度打算为用于计费的格式的识符,况且不错通过诸如 HTTP Referer 允许列表之类的(可绕过的)限度设施进一步限定。它们并非揣度打算为身份考证凭据。
但 Gemini 出现后情况变了。
在 Google Cloud 格式中启用 Gemini API(生成式说话 API)时,该格式中现存的 API 密钥(包括网站行家 Java 代码中的密钥)可能会在后台静默拜访明锐的 Gemini 端点。
莫得任何警告、阐述对话框或电子邮件陈说。
这就产生了两个截然相背的问题:
追念性权限膨胀。比如三年前,您创建了一个 Maps 密钥,并按照 Google 的携带将其镶嵌到您网站的源代码中。上个月,您团队的一位设备东说念主员为里面原型启用了 Gemini API。刻下,您的公钥已变成 Gemini 凭证。任何持取该凭证的东说念主齐不错拜访您上传的文献、缓存的实质,并导致您的 AI 用度飙升。莫得东说念主告诉过您这少量。
不安全的默许设立。在 Google Cloud 中创建新的 API 密钥时,默许设立为“不受限定”,这意味着它立即对格式中悉数已启用的 API(包括 Gemini)齐灵验。用户界面会自大“未经授权使用”的警告,但这种默许架构十足通达。
追念性权限膨胀。比如三年前,您创建了一个 Maps 密钥,并按照 Google 的携带将其镶嵌到您网站的源代码中。上个月,您团队的一位设备东说念主员为里面原型启用了 Gemini API。刻下,您的公钥已变成 Gemini 凭证。任何持取该凭证的东说念主齐不错拜访您上传的文献、缓存的实质,并导致您的 AI 用度飙升。莫得东说念主告诉过您这少量。
不安全的默许设立。在 Google Cloud 中创建新的 API 密钥时,默许设立为“不受限定”,这意味着它立即对格式中悉数已启用的 API(包括 Gemini)齐灵验。用户界面会自大“未经授权使用”的警告,但这种默许架构十足通达。
完了是:数千个底本手脚良性计费 token 部署的 API 密钥刻下变成了存在于行家互联网上的 Gemini 及时凭证。
之是以说这是权限晋升而不是配置很是,是因为事件发生的规定。
设备者创建了一个 API 密钥并将其镶嵌到舆图网站中。(此时,该密钥是无害的。)
Gemini API 已在并吞格式中启用。(刻下,并吞个密钥不错拜访 Gemini 的明锐端点。)
设备东说念主员从未被陈说密钥的权限在其底层发生了变化。(密钥从行家标识符变为机要凭证
诚然用户不错限定 Google API 密钥(按 API 作事和应用门径),但间隙在于不安全的默许设立 (CWE-1188) 和不正确的权限分派 (CWE-269):
隐式信任升级:Google 将明锐权限追念性地应用于已在行家环境中正当部署的现存密钥(举例,Java 包)。
密钥分离不及:安全的 API 揣度打算需要针对不同的环境(公开密钥与私钥)使用不同的密钥。要是对两者齐使用并吞种密钥样式,系统就容易出现安全间隙和絮叨。
隐式信任升级:Google 将明锐权限追念性地应用于已在行家环境中正当部署的现存密钥(举例,Java 包)。
密钥分离不及:安全的 API 揣度打算需要针对不同的环境(公开密钥与私钥)使用不同的密钥。要是对两者齐使用并吞种密钥样式,系统就容易出现安全间隙和絮叨。
安全默许值失效:通过 GCP API 面板生成的密钥的默许现象允许拜访明锐的 Gemini API(假定已启用)。用户在为舆图组件创建密钥时,会在不知情的情况下生成具有治理权限的凭据。
那膺惩者能作念什么?
膺惩者拜访您的网站,检讨页面源代码,并 AIza... 从舆图镶嵌中复制您的密钥。然后他们运行:
403 Forbidden 他们取得的不是 a,而是 200 OK。膺惩者由此不错:
拜访特少见据。`and`/files/ 端点不错 /cachedContents/ 包含上传的数据集、文档暖和存的高下文。格式悉数者通过 Gemini API 存储的任何实质均可拜访。
账单飙升。Gemini API 的使用并非免费。根据具体模子和高下文窗口,膺惩者要是滥用 API 调用,可能每天仅一个受害者账户就会产生数千好意思元的用度。
拜访特少见据。`and`/files/ 端点不错 /cachedContents/ 包含上传的数据集、文档暖和存的高下文。格式悉数者通过 Gemini API 存储的任何实质均可拜访。
账单飙升。Gemini API 的使用并非免费。根据具体模子和高下文窗口,膺惩者要是滥用 API 调用,可能每天仅一个受害者账户就会产生数千好意思元的用度。
用完您的配额。这可能会导致您的 Gemini 正当作事十足住手。膺惩者根底不会触碰你的基础设施。他们仅仅从行家网页上窃取密钥。
为了解问题的严重进程, Truffle Security 扫描了 2025 年 11 月的 Common Crawl 数据集,这是一个广阔的(约 700 TiB)网页归档,其中包含从互联网上公开持取的 HTML、Java 和 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 最终是否会领受不同的身份考证架构。”
网友:我可能会跪求谷歌退款!
这位墨西哥设备者的阅历,很快在本事社区激勉了无为盘问。围绕背负包摄、平台机制以及设备者自身配置问题,不雅点分化涌现。
不少 Reddit 用户对他的处境暗示浓烈怜悯。一位网友直言,要是我方遭受这种情况,“恨不得飞到谷歌总部,跪在地上求他们退款。”在这些东说念主看来,关于一家仅有三名成员的小公司而言,8 万多好意思元的账单确凿等同于“致命打击”。即便本事上存在简易,平台也应在顶点异常场景下提供更多缓冲或协商空间。
但也有用户将盘问焦点转向机制揣度打算自身。他们指出,Google Cloud 的 API Key 体系确乎应该提供更明确、可配置的“硬性糜掷上限”。一朝触及某个阈值,系统应自动中断作事,而不是仅发送领导。与此同期,也有东说念主提到本事终局层面的复杂性——云用度时时并非及时结算,而是在产生后 24 小时以致 36 小时内迟缓计入账单。要是计费数据自身存在蔓延,那么要作念到真确真义上的“即时硬性封顶”,在系统架构上可能并不肤浅。
还有网友以为谷歌方面没什么错,而是他们我方忽略硬性设立酿成的很是。他暗示:
“但刻下照旧有了这些硬性限定设立,我十足不解白楼主为什么还要因为他们厄运的配置很是而申斥谷歌……至少要承认,莫得设定硬性限定是一个巨大的很是。”
“但刻下照旧有了这些硬性限定设立,我十足不解白楼主为什么还要因为他们厄运的配置很是而申斥谷歌……至少要承认,莫得设定硬性限定是一个巨大的很是。”
在这起 API 账单风云激勉无为盘问后,一位有多年云作事教学的网友给出了相对平安的分析。
他领先建议一个关键问题:“所谓‘被盗’,究竟是什么真义?”在他看来,这个界说自身至关迫切。
“是有东说念主真确入侵了系统、打破防地窃取数据?如故设备者在配置或代码治理过程中不测间泄露了凭证?这两种情况在背负永诀与后续处理上十足不同。要是是系统层面的安全入侵,性质更严重;要是是凭证涌现,则更可能被视为配置风险。厘清这少量,是与平台相易的第一步。”
“是有东说念主真确入侵了系统、打破防地窃取数据?如故设备者在配置或代码治理过程中不测间泄露了凭证?这两种情况在背负永诀与后续处理上十足不同。要是是系统层面的安全入侵,性质更严重;要是是凭证涌现,则更可能被视为配置风险。厘清这少量,是与平台相易的第一步。”
这位网友还领导,当事东说念主应检验是否领有网络安全或本事背负干系的保障。有些公司会为云作事异常账单或安全事件投保,在特定条款下不错苦求理赔。诚然这并弗成科罚根底问题,但在现款流垂死时,可能成为缓冲技能。
还有网友暗示,通过权限拜访比通过密钥拜访要靠谱得多。
“这即是为什么应该通过权限而不是密钥来授予拜访权限,以及为什么责任负载身份如斯迫切的原因。”
“这即是为什么应该通过权限而不是密钥来授予拜访权限,以及为什么责任负载身份如斯迫切的原因。”
参考通达:
https://old.reddit.com/r/googlecloud/comments/1reqtvi/82000_in_48_hours_from_stolen_gemini_api_key_my/
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules股市 配资
发布于:北京市股票配资实盘操作_交易步骤与技巧提示:本文来自互联网,不代表本网站观点。