先别急着给中转站扣帽子。看这条消息的朋友第一反应基本都是是不是中转站被人日穿了——6TB大模型调用日志被打包出售里头躺着19家企业的API密钥这画面确实像极了平台侧漏洞捅穿后的一锅端。但把这条链路的每一环掰开揉碎之后你会发现真正的问题恰恰不在那个被人骂翻天的中转站而在更上游的密钥管理、调用链设计和开发者的使用习惯上。这篇文章我就以东半球最普通的大模型重度用户半个安全从业者的视角把这起事件的里三层外三层拆给你看。适合谁读所有在用大模型API做产品、做自动化、做数据管线的开发者以及企业里负责模型账号安全和成本管控的人。看完你会明白密钥是怎么在不知不觉中被搂走的、为什么中转站只是运输工具、以及事件发生后3小时里到底该做什么动作才能止损。1. 事件还原6TB日志意味着什么1.1 一个货架商品的重量先别被6TB这个数字唬住咱把它换算成能感知的量。大模型调用日志的常见构成是时间戳、来源IP、用户标识、模型名称、请求参数、token计费信息、返回码以及——很不幸的——很多平台会把API Key或token直接拼在请求头里一起落库目的是为了方便排障和账单对账。如果每条日志压缩后按2~4KB估算6TB大概对应20亿到30亿条调用记录。这个量级意味着什么一个中小型企业级API网关跑一年大概能积攒1~2TB的日志6TB则相当于一个相当活跃的中型平台跑了一年半或者一个大型渠道商跑了半年。这批数据的含金量不仅是密钥而是完整的行为画像——哪个企业、在什么时间段、用哪个模型、问了什么问题、烧了多少token全在里头。这已经不是靠撞库撞出来的散装九手数据而是被人从某个内部水龙头里直接拧下来的原浆。更值得注意的是被打包出售这个动作本身。说明这批日志已经被离线整理过、清洗过、标过索引甚至可能已经有人写好了查询接口按行业或者按密钥归属方做了分类。19家企业的密钥之所以能被数出来说明买家或卖家已经做过一轮图谱分析——哪些密钥指向哪家企业、权限多大、用量多少一目了然。换句话说这批数据不是裸奔那么简单而是已经穿上衣服、贴上价签、摆在货架上了。1.2 日志里面躺着谁的钥匙这里说的钥匙就是API密钥行业黑话叫API Key或Access Token。它的作用等同于保险柜钥匙你拿着它就能以对应主体身份调用大模型服务相关的费用自然记在这个主体账上。19家企业的密钥意味着至少有19家企业的主体身份被完整暴露。但密钥和常见认知里的密码有区别——密码是登录用的API Key是机器之间通信用的通常有三种形态根密钥/管理员密钥权限最大可以创建子密钥、查账单、改配额。一旦泄露企业账号基本等于拱手让人。项目专属密钥绑定了某个项目或某个bucket权限范围可控但若项目里配了完整资费接口同样能烧钱。临时token/会话token有效期短通常几小时到几天相对人畜无害但如果被塞进6TB日志并被打包攻击者可以顺着临时token反推出当时的网络拓扑和调用链。很多人以为我的密钥只在大模型官网上用过怎么会被打包——这是典型误区。一坨日志里只要有其中一条带上你的原始API Key你再怎么只在官网用只要你的服务在中间接了一层路由、负载均衡、网关代理或第三方SDK密钥就可能以明文形式被转发并记录。1.3 标题里的关键反转为什么根因不是中转站这条新闻最耐人寻味的地方就是那句问题不在中转站。我先说结论中转站是数据的运载工具而不是泄露的源头。中转站是什么它本质是一个API网关你通过它去请求各家大模型服务它帮你做模型切换、计费、配额管理。企业为什么用中转站因为省事——不用分别对接多家厂商的SDK多个模型在一个服务商那里统一出账。但中转站本身只是一个转发层它得先收到你的请求包括密钥才能帮你转发。所以在这个事件里中转站承担的角色更像快递运输车你把自己的钥匙复制了一把交给快递员快递员开车时把钥匙和包裹放在一起结果车被偷了。我们能怪快递车厂车门不够结实吗能但也仅仅是一部分责任。更深的责任在于为什么你要把原始钥匙交给快递员为什么你给快递员的集装箱里还塞了6TB的完整调用记录为什么你从不检查快递员的仓库为什么这把钥匙你用了十年从来不换这些都是比中转站漏洞更根治性的问题——密钥管理策略缺失、敏感日志不分级、第三方平台信任边界模糊。标题的反直觉之处就是为了逼我们去看水面下的部分。2. 中转站是怎么夹带密钥的2.1 中转站的本质一个替你跑腿的转发柜台形象点说大模型服务商有自己的登录窗口控制台和一套API接口规则。你作为企业用户可以在官方平台上拿到一把密钥然后构造HTTP请求去调用。这个流程本身不复杂但当你需要对接5家模型服务商、几十个模型、几百个业务线时维护起来就很痛苦——每个服务商的鉴权方式不一样、计费粒度不一样、限流策略不一样。中转站解决的正是这个多对多的问题。你在中转站注册账号它会给你一把中转站的key你用这把key去请求中转站的统一接口中转站自动帮你路由到底层的大模型服务商。好到这里你会发现一件微妙的事中转站想要帮你转发请求就得有能力访问你的底层模型账号。要么你把自己的底层密钥配置在中转站后台要么中转站本身有量和上游服务商做批发采购然后给你一个二手额度。现实中两种模式都存在。第一种模式下你的原始密钥会保存在中转站的服务端第二种模式下你的原始密钥不在中转站手里但你的业务行为、请求内容、消费量全部经过中转站。不管是哪种只要中转站的网关在记录请求日志你的调用数据包括可能出现的密钥就会沉淀下来。2.2 密钥进入日志的三条通道密钥是怎么从你的代码溜进别人日志包里的我在实际排查和应急审计里见得比较多的是这三条通道接口层直接透传。开发者在写代码时图省事直接把API Key放在HTTP请求的Header里比如Authorization: Bearer sk-xxx。如果中转站的处理逻辑是记录完整请求头方便排障那这把密钥就被当作普通字段写进日志了。很多日志收集组件默认会记录所有Header除非你显式配置脱敏。回调地址或重定向URL带参。有些模型服务支持异步回调结果回调URL上直接挂着token或session参数。这类参数如果在网关层没被剥离就会被一并记入访问日志。代码包和配置文件落入日志仓库。以为是日志实际上打包内容里可能还包括.env文件、application.yml、远程配置中心的缓存快照。这些文件里往往躺着明文密钥。所谓6TB日志可能实际是日志目录配置文件临时调试文件的大杂烩。这三条通道单独看都不算高级漏洞但串联起来就形成了一个完整的密钥搬运流水线你的代码把密钥交给插件/中转站插件/中转站把它写进日志日志系统把它备份到对象存储对象存储又因为某个配置错误或后台权限过大而被导出打包。2.3 企业账号被抽走的核心漏洞回到19家企业本身。为什么偏偏是这些企业中招除了它们调用量大、数据价值高之外它们普遍存在几个共通漏洞第一密钥权限过宽。很多企业在大模型控制台创建一个管理员密钥后所有开发环境、测试环境、生产环境全用这一把。一旦密钥被抽走等于所有环境的闸门同时对攻击者敞开。第二缺少独立的密钥生命周期管理。从密钥创建到轮换、回收没有一套流程。很多企业一年甚至两年都不换一次密钥。密钥在6TB日志里躺多久风险就持续多久。第三对第三方平台的信任边界实在太模糊。把生产环境密钥直接配到中转站后台、把包含业务数据的请求全部转发给中转站、又完全没有和中转站签署任何数据处理的合规协议——这种情况不在少数。你觉得你只是买了一项网关服务但你把企业最核心的业务语料、客户信息和调用凭证都一起托管过去了。3. 把责任掰开看中转站、企业与调用链上的每个人3.1 中转站该背多少锅说实话中转站作为技术载体在密钥保护方面确实有不可推卸的责任至少有四个层面做得不够日志脱敏没做到位比如Header里的Authorization字段应当默认打码访问控制过于单一不该有全局导出的权限对离线数据包的下载行为没有审计告警运营者自己也可能存在惰性——明知日志里有敏感信息还为了排障方便继续全量保存。但是如果我们把所有锅都砸给中转站会掩盖真正应该被追责的环节。中转站泄露的只是日志而日志之所以成为金矿是因为里面有某个环节的密钥长期不轮换、访问控制不严密、对第三方无底线信任。就算没有这个中转站只要企业的密钥还在别的中间层流转同样可能从别处漏出去。行业里被公开过的案例有的是从开源SDK仓库里翻出密钥有的是从公开的Grafana面板上抓到内网地址再顺藤摸瓜找到API网关日志——路径五花八门出口千千万。3.2 企业侧为何如此容易中招我接触过不少被类似事件波及的企业它们的问题常常不在技术不够好而在管理上的三个盲区账号和密钥的所有权不清晰。到底是AI部门申请的还是基础架构部门申请的归口在谁离职了密钥回收没有一问三不知。成本与安全是两条线。负责成本优化的人可能只关心用量和计费负责安全的人又不一定能看到模型调用日志。中间没有人去做交叉监控。密钥被偷刷了三天成本报表上只是多了几笔备注模糊的消费根本没人注意到。业务增速远超安全水位。三个月前还是一个10人小团队在试点两个月后业务量翻了十倍直接从中转站买量但安全策略还停留在大家注意不要把密钥传群里的原始阶段。这意味着即使没有这次6TB日志的抛售事件这批企业未来大概率也会在其他数据泄漏事件中出现。可以说被抽走密钥不可怕可怕的是被抽完之后企业还不一定能感知到。3.3 开发者的习惯是最后一根稻草聊完企业层面必须承认很多问题的根源其实就是开发者习惯。我在各种技术群里观察到一个很普遍的怪象大家宁愿把密钥写死在代码里然后推到GitHub也不愿意多花80秒配一个环境变量宁愿把生产密钥贴到中转站后台的小输入框里也不愿意先问一句中转站这边对我的密钥加密存储吗。有人可能会说我们公司没有专职安全岗顾不上这些。但密钥管理本来就不该只是安全岗位的事它和代码规范一样属于工程基本功。你的代码里如果到处是硬编码密钥那就好比把家门钥匙放在门口地垫下就算没遇到这次6TB抛售迟早也会被别的顺手牵羊的人拿走。所以问题不在中转站这句话更深层的含义是当一个个开发者在各种不可控的第三方平台上都习惯性地复制粘贴生产密钥时全网至少有成千上万把企业钥匙散落在你不知道的角落。这次6TB日志曝出的19家只是浮出水面的那部分水下的规模可能远超想象。4. 事件之后的黄金3小时密钥泄露应急响应4.1 第一步判断我中没中收到风声之后先别慌也别马上把中转站后台关掉第一件事是判断自己的密钥是否真的在泄露包里。怎么判断有几个快捷路径查官方平台的登录记录和API调用记录。主流大模型服务商的控制台都会提供近期调用明细看有没有来自异常地域、异常IP段、异常时间窗口的调用。看账单。对比上个月的消费趋势如果某天突然多了几个小时的密集调用或者出现了你根本不认识的模型名称、批量处理任务那大概率已经有人用你的密钥在跑量。用泄露数据交叉比对。如果你自己有渠道能拿到泄露包的关键索引比如文件名的哈希、去标识化后的样本可以尝试用自己的密钥前缀做匹配。但注意不要为了检验而把明文密钥发给任何人哪怕对方说自己是溯源团队。正确的做法是拿密钥的哈希或前缀去比对。这里踩过坑的人都知道判断阶段最容易犯的错误是自我安慰——觉得自己调用量小、不明显可能只是统计误差。我建议宁可把情况想得更坏一点。因为密钥一旦出现在第三方日志里你无法确定对方是只拿了一个备份还是早就开始持续监控。4.2 第二步毫不留情地轮换判断出可能中招或者不确定中招之后第二个动作就一个字换。立刻去官方控制台吊销那批可能泄露的密钥然后创建新密钥。这个事没有缓冲余地也不建议等到业务低谷再换。轮换时有几个细节要注意新旧密钥之间最好设置一个短暂的过渡窗口。有些长任务可能还持着旧密钥如果你秒杀老密钥未完成任务会全部失败。合理的做法是先在控制台停用旧密钥观察10~15分钟确认没有尚在执行的任务再彻底删除。不要把新密钥直接用在中转站上。正确顺序是先在你的业务代码里验证新密钥直连官方接口正常再决定是否把新密钥交回给中转站。如果中转站还要继续用至少要确认它支持加密存储而不是明文落库。更新所有环境变量和配置中心。做完控制台操作别忘记本地开发机、测试服务器的.env文件、Docker Compose配置、CI/CD流水线里的Secret——这些地方都可能是旧密钥的藏身处。轮换这个动作听起来简单真正做起来往往耗掉半天时间因为很多团队的密钥布点实在太多了。这也反过来说明平时做好密钥资产管理紧急时候能救你一命。4.3 第三步地毯式审计与止损轮换完密钥只是止血接下来还得做一次地毯式审计否则下次还会在同样的地方倒下。审计至少覆盖四个维度调用链审计梳理从你的业务系统到最终大模型服务商之间所有的中间环节。把所有经过的网关、代理、SDK、中转服务列成一张清单逐一确认它们是否在记录请求日志、是否对日志字段做了脱敏、日志保留周期多长。权限审计在各大模型控制台和云厂商后台检查现有的API密钥、子账号、角色绑定关系把那些权限过大的密钥降权不用的密钥立刻删掉离职员工的密钥第一时间回收。数据审计翻一翻对象存储、日志服务、Elasticsearch索引里是否存在明文密钥。搜Authorization、Bearer、sk-这类特征字段看看命中的条目分布在哪些项目里评估暴露面。成本审计把过去90天的账单按项目和API Key维度拉一遍标记出可疑消费。同时设置消费阈值告警比如日消费突增50%以上就触发通知。不少企业在这里会卡壳因为日志量太大人工翻不现实。我的建议是优先排查高危敏感字段和高峰期日志不追求全覆盖先把最有可能藏密钥的路径都过一遍后面再做持续扫描。5. 长期防线让密钥不再被顺走5.1 密钥的最小权限使用原则把这次事件当成一次免费的架构审视机会其实很划算。首先要建立的第一个长期思想是最小权限四个字。不同环境用不同密钥。开发环境、测试环境、生产环境必须完全分开就算开发环境的密钥被扒走攻击者也只能看到无关紧要的玩具流量。不同业务线用不同密钥。比如客服机器人、数据分析平台、内容生成服务各自配各自的密钥和预算上限。这样即使某个业务线密钥泄露损失也可以被限制在单条业务线内。不同的操作层级用不同的凭证。管理员操作、普通调用操作、只读查询操作权限要分开。能看账单的不一定能发起调用能发起调用的不一定能改配额。实现最小权限并不复杂多数大模型平台已经支持创建多个子密钥并分配不同权限。刻意用嫌麻烦来回避最小权限等于把风险层层积累最后一次性爆出来那就不是麻烦两个字能带过的了。5.2 建立密钥生命周期管理密钥不是创建一次用一年的资源。它和密码、证书一样必须有生命周期申请、审批、创建、使用、轮换、回收。我建议企业至少设定三条规则第一密钥最长有效期不超过90天到时间强制轮换第二所有密钥创建必须有申请记录和责任人不能一个人默默建了一把管理员密钥半年没人知道第三密钥回收和员工离职流程绑定人走钥匙必须立刻失效。对个人开发者或小团队哪怕不搞复杂的审批流程也可以用一些轻量工具保住底线。我自己习惯的做法是把密钥放在.env文件里.env文件不进Git仓库本地开发时用direnv自动加载环境变量CI流水线里的密钥统一放到CI平台的Secret管理功能里绝不直接写进YAML。还有一点容易被忽视就是密钥的明文传播。别把密钥放在团队群、共享文档、截图里。如果实在需要协作分发用支持过期时间的一次性分享链接并且分享之后要跟踪有没有被打开过。虽然不如专业密钥管理那么严但已经能挡掉90%的随手转发。5.3 用网关做隔离层而不是直接甩出生产密钥如果你真的需要多个模型之间灵活切换或者有较多的自动化调用需求我建议自己搭一层轻量网关而不是把生产密钥直接甩给第三方中转站。自己搭网关有很多成熟方案比如BricksLLM、LiteLLM Gateway或云厂商的API Gateway它们都支持统一的鉴权入口、请求转发、日志存储和限流控制。核心思路是你的业务代码只需要和自己的网关通信网关里保存真正的上游模型密钥业务侧拿到的只是网关签发的一把临时访问凭证。这样一来模型提供商的真实密钥永远只存在于你自己的服务器环境里不会经过任何第三者。日志里的字段可以在网关层做统一脱敏就算日志被人拖走密钥也已经打了马赛克。你可以在网关层按业务、按用户维度做配额限制谁在什么时间、用什么模型、烧多少token全部有据可查。将来切换模型服务商时只需要改网关配置不需要让每一套业务系统的开发者都感知。顺便说一句中转站在行业里不是不能用而是要看怎么用。如果只是个人学习或低敏感场景用中转站图个方便完全没问题但当企业内部业务数据开始流经第三方时就必须走一套完整的风险评估、数据合规审核和密钥隔离流程。把好钢用在刀刃上才是成熟团队该有的姿势。6. 常见误判与自查清单6.1 三个典型误判每次出这类事件我都会看到很多人在下面争论但其实很多讨论本身就建立在误判上。这里挑三个最常见的第一个误判只要我用的中转站是大平台密钥就是安全的。——规模大不代表安全水位高更不代表日志保管没有问题。平台大只说明它影响面大一旦出事反而是精准打击。安全这事跟规模没有必然关系跟具体的安全投入有关系。第二个误判我的密钥在日志里被打码了所以安全。——很多网关确实会显示sk-****abcd这种打码形态但这只能防住人眼偷窥。如果日志系统本身被完整拖走攻击者往往可以结合请求上下文、计费信息、用户标识反推出完整密钥甚至直接利用密文重放攻击。打码是缓解不是终点。第三个误判密钥泄露之后只要删掉密钥就安全了。——密钥只是入口攻击者真正想要的是数据和应用权限。他可能已经缓存了你的大量业务上下文或者利用泄露的密钥探测出了你的网络结构和内部系统。删密钥之后至少要持续观察一到两周确认没有二次入侵的迹象。6.2 给个人开发者的自查清单如果你是一个人维护几个小项目这块可以根据下面这个清单快速自查检查所有仓库包括私有仓库里是否有以sk-开头的硬编码密钥。可以用grep -R sk-快速扫一遍也可以用gitleaks这类工具做历史提交扫描。检查本地代码中是否用环境变量读取密钥。不要用config.py或者const.js存放密钥。排查所有出站请求哪些请求是发给第三方中转服务或者测试平台的做到心里有数。检查是否有多个项目在复用同一把密钥。如果有拆开成不同项目专属密钥。给自己的大模型账号开启消费告警绑定微信、钉钉或邮件短信最好。消费通常有延迟但比没有强。把密钥轮换做成定期任务比如设一个90天的日历提醒。真到换的那一刻你就知道平时做好分类管理可以省多少事。6.3 给企业安全负责人的自查清单企业的风险面更大常规做法和团队还不太一样建议至少覆盖以下几点建立模型服务账号清单有哪些平台、哪些项目、哪些密钥负责人是谁创建时间、最后轮换时间、权限范围。这张表本身就是企业资产应该放进机密文档库。明确第三方接入的审批流程任何业务想要对接中转站或外部网关必须经过安全评估。评估重点包括对方的日志策略、数据存储位置、加密方式、是否支持密钥轮换、能否配合安全审计。对日志中的敏感字段做统一脱敏方案在日志采集端就过滤掉Authorization、Cookie等敏感Header从源头阻断密钥落入日志仓库。部署成本异常告警把大模型调用费用接入企业的监控大盘按维度项目、调用方、模型设置异常波动告警。定期做密钥泄露演练每季度拿一个低权限测试密钥故意泄漏到模拟环境里检验团队发现、响应、轮换的速度。演习过和没演习过真正出事时的反应完全是两个水平。这次6TB日志打包出售事件说到底是一次安全水位的大考。密钥本身只是一根导火索真正被炸出来的是长期以来很多团队对API密钥管理、第三方调用链审计和敏感日志治理的忽视。19家企业的钥匙被公开摆上货架证明的恰恰是——中转站只是泄露的管道而根子在水管工、在物业、在那些从没检查过水表的人。我在给企业做应急响应的过程中反复验证过一个朴素的道理安全这事没有一劳永逸今天没出事也只是运气还没用完。趁着事件还热乎赶紧回去把自家的大模型调用链路重新捋一遍把密钥管起来把日志脱敏做起来把最小权限四个字刻进团队每一次代码评审里。别等下一个6TB被拖走的时候里面有你的名字。
