立竿见影 – Token 被盗刷风险防护措施与指南

摘要：越来越多的企业把大语言模型（LLM）能力接入生产业务，模型调用凭证（AK/SK、API Key）也随之成为高价值的攻击目标。一旦凭证泄漏，攻击者可以在短时间内发起大量高价值的模型调用，造成快速累积的经济损失。本文面向已经或即将在 AWS 上构建 LLM 应用的客户，给出三个可在当天落地、见效较快的应对方案，并附一份完整的加固 Checklist。读完本文，你将了解：Token 滥用为什么频发、其风险来源有哪些，以及如何用账单异常监控、凭证来源限制、Amazon GuardDuty AI Protection 这三项措施建立分层防护。

01 一、前提条件（Prerequisites）

02 二、为什么 Token 滥用值得单独重视

03 三、方案一：账单异常监控——3 层兜底机制

04 四、方案二：为凭证设置请求来源限制（重点）

05 五、方案三：Amazon GuardDuty AI Protection

06 六、加固 Checklist

07 七、小结（Conclusion）

一、前提条件（Prerequisites）

在实施本文方案前，建议先具备以下基础：

一个可用的 AWS 账户，并具备配置 IAM、AWS Budgets、Amazon GuardDuty 的权限；
已启用 AWS CloudTrail（用于事后审计与调用来源排查）；
了解自身 LLM 应用的调用架构与出口方式（是否经 VPC Endpoint、是否有固定出口 IP）；
已在使用或计划使用 Amazon Bedrock、Amazon SageMaker AI 或第三方模型服务。

二、为什么 Token 滥用值得单独重视

先明确术语：本文所说的 Token 滥用，指攻击者获取到模型调用凭证（AK/SK、API Key）后，冒用身份发起大量模型调用，从而消耗受害者的算力与预算。它之所以值得从传统 API 滥用中单独拎出来讨论，是因为发作更快、损失更集中，背后有三重叠加的原因：

暴露面广，且泄漏窗口极短。在云原生与 AI 应用的开发节奏下，凭证容易在不经意间被硬编码进代码、写入配置文件、打进容器镜像，或随日志、前端一起暴露，再经由公共代码仓库、CI/CD 流水线、协作平台扩散。公开的凭证往往在几分钟内就会被自动化扫描器发现，攻击者的自动化程度通常高于团队的响应速度。
AI 让“变现”更直接、成本更高。传统云资源的凭证泄露——比如 EC2 实例被拿去挖矿——至少还有物理上限：磁盘会写满、实例配额会触顶。但 LLM 推理 API 不一样：它没有天然的消费天花板。这类攻击被安全研究界称为 LLM jacking。由于 LLM 调用单位成本较高，损失可能在数小时内快速累积。
发现与止损普遍滞后。不少企业既没有对 AI 服务调用做异常监测，也没有对凭证设置来源限制，且调用模式与正常推理高度相似，难以区分，往往要等到账单异常或云厂商告警时才发现，而此时损失已经产生。

对企业而言，这不仅是一笔意外账单，还可能带来数据与模型资产暴露、合规与声誉风险。

2.1 典型 LLM 应用架构与风险来源

在典型的 LLM 应用架构中，客户应用部署在 VPC 内，通过 API 网关（如 Amazon API Gateway 或 LiteLLM 等开源代理）向后调用模型服务——可能是 Amazon Bedrock 托管的基础模型、第三方模型 API，或客户自建的模型服务。凭证贯穿这条链路的始终。

[图 1：典型 LLM 应用调用链路示意图]

常见的风险来源如下表所示：

风险类别	说明
① 凭证泄漏	硬编码进代码、误提交到 Git、日志/前端暴露——目前最高频
② 组件漏洞	LiteLLM 等网关/依赖组件自身漏洞被利用
③ 配置错误	权限过宽、Key 无来源限制、无过期时间
④ 人为因素	离职账号/Key 未回收、内部误用与共享
⑤ 供应链风险	第三方库/镜像投毒、CI/CD 流水线泄漏凭证
⑥ 缺乏监测	无账单/调用监控，异常发生数天后才被发现

风险类别	说明
① 代码仓库泄露	.env / config 中硬编码 Key 被推送到 GitHub / GitLab
② 供应链攻击	恶意 Python 包窃取凭证（如 LiteLLM 事件）
③ 信息窃取木马	开发者笔记本感染 Stealer，shell_history / .env 被盗
④ 权限静默扩张	旧 Key 自动获得新服务权限（如 Google Gemini 事件）
⑤ Agent 自身暴露	AI Agent 被提示注入诱导泄露内置 API Key（如 METR 事件）
⑥ 长期 AK/SK 未轮转	存活数月/年的 IAM User Key，无过期策略、无使用监控
⑦ AI 代理网关集中风险	LiteLLM 等网关集中存储多家 LLM Key，一破全丢

针对这些风险，尤其是最高频的凭证泄漏，下面推荐三个可以并行推进、当天即可落地的对策。

2.2 两个公开的安全事件

案例一： METR — API Key 被盗，三周烧掉 60 万美元

一名研究员在个人 EC2 实例上运行了一个「vibe-coded」应用，该应用包含公共模型账户的 API Key。攻击者通过证书透明日志发现了该实例，诱骗 Agent 泄露了 API Key，并植入 SSH Key 保持持久访问。三周内消耗了价值约$600,000 的模型信用额度。

案例二：EXPOSEDORNOT——大规模 API Key 泄漏查询平台

2025 年 1 月，安全研究机构 CloudSEK 发布了名为 EXPOSEDORNOT 的工具，能够检索和分析互联网上已泄漏的 API Key。其数据库中包含来自公开代码仓库、Paste 网站、移动应用反编译等渠道的大量凭证，显示了凭证泄漏的普遍性和自动化收割的规模。

⚠️ 数据汇总

Sysdig 研究报告：单个被盗的凭证可造成$46,000 ~$100,000+/天的损失。被盗 LLM API Key 在暗网最低 $30 即可买到。Hugging Face 上的分析指出：“泄露的 Key 不需要攻破你的基础设施就能伤害你——只需要一台开发者的笔记本感染了信息窃取木马，.env 文件或 shell history 中的 Key 就完了。”

三、方案一：账单异常监控——3 层兜底机制

即使凭证已经泄漏，限流和预算控制能在几分钟内切断失控的消费。建议同时启用以下三层，形成主动 + 被动、预算 + 用量的立体监控体系：

1. AWS Budgets —— 预算硬上限

AWS Budgets 是最直接的费用护栏。创建以 Bedrock 服务为筛选条件的月度预算，将每月预期 LLM 支出作为阈值，并配置在达到 80% 和 100% 时通过 SNS 发送告警。还可以配合 Budget Action，在超预算时自动触发 IAM 策略变更或账户操作。

2. AWS Cost Anomaly Detection —— 智能基线检测

Cost Anomaly Detection 是最后一层防线，不是实时防线。与固定阈值不同，Anomaly Detection 使用机器学习自动建立历史支出基线，在支出模式偏离常态时发出告警。选择监控类型： AWS Services（推荐）— 自动为每个 AWS 服务独立建模，Bedrock 会被当作独立服务监控，设置告警阈值：例如只在异常影响超过 $100 时告警（避免小额波动导致噪音）。无需手动调整基线，系统会持续学习正常模式。

阈值设定逻辑参考

层级	工具	触发逻辑	告警速度
第一层	AWS Budgets	月度预算的 80% / 100%	按天评估
第二层	Cost Anomaly Detection	ML 基线偏离	按天检测，异常后分钟级告警
第三层	CloudWatch Alarm	调用量/Token 用量 > N	分钟级触发

3. Cost Sentry —— Token 级预算哨兵解决方案

Token 级预算哨兵（Cost Sentry）来自 AWS 官方博客，分为两篇：

Part 1（核心架构 + 预算执行）：Build a proactive AI cost management system for Amazon Bedrock – Part 1
Part 2（高级监控 + 成本分摊标签）：Build a proactive AI cost management system for Amazon Bedrock – Part 2

Part 1 详细介绍了用 Step Functions + CloudWatch + DynamoDB 编排的预算哨兵工作流——每次 Bedrock 调用前先查当月 Token 用量，对比预算上限，超限直接拒绝请求。Part 2 在此基础上增加了 invocation-level tagging 和 QuickSight 可视化报表。

四、方案二：为凭证设置请求来源限制（重点）

即使凭证被窃取，如果在 IAM 策略中通过 Condition Key 限定了请求来源，攻击者从外部网络发起的调用会被直接拒绝。这是成本最低、见效最快的防护手段之一。下面按两种典型场景分别说明。

4.1 场景 A：通过 VPC Endpoint 调用 Bedrock

最佳实践为 Amazon Bedrock 创建 VPC Endpoint（PrivateLink），配合 VPC Endpoint Policy 限制只允许特定角色调用特定模型。即使凭证泄露，攻击者也无法从 VPC 外部发起调用。如果应用已在 VPC 内通过 Bedrock 的 VPC Endpoint 调用模型，可以通过以下 Condition Key 限制凭证只能从指定 VPCE 发起调用：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowBedrockOnlyFromVpce",
    "Effect": "Deny",
    "Action": "bedrock:InvokeModel*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:sourceVpce": "vpce-0abc1234def56789a"
      },
"BoolIfExists": { "aws:ViaAWSService": "false" }
    }
  }]
}

关键点：aws:sourceVpce 会将调用限制在指定的 VPC Endpoint 内。即使 AK/SK 泄漏，攻击者从外部网络发起的调用会被直接拒绝。

4.2 场景 B：通过公网固定出口 IP 调用

为了方便给所有调用 Bedrock API 的身份加上网络边界控制。建议通过 SCP 策略，先应用到测试账户上验证效果，最后附加到生产账户。如果无法应用 SCP，比如管理账户无法访问的情况，则使用权限边界，给所有具有 bedrock 调用权限的身份添加权限边界。适用于应用通过 NAT Gateway 的固定公网 IP 调用 Bedrock 或第三方 API，可以使用 aws:SourceIp 限制：

 {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockOutsideNetworkPerimeter",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:Converse",
        "bedrock:ConverseStream"
      ],
      "Resource": "*",
      "Condition": {
        "NotIpAddressIfExists": {
          "aws:SourceIp": ["198.51.100.10/32", "203.0.113.20/32"]
        },
        "StringNotEqualsIfExists": {
          "aws:SourceVpc": ["vpc-0abc123456789def0"]
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false",
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

ℹ️ 注意：

aws:SourceIp 仅在请求直接来自公网时有效。如果当它“既不来自白名单 IP、又不来自指定 VPC、又不是 AWS 服务主体、又不是 AWS 代发”时，四个条件同时 true → 才 Deny。攻击者拿被盗 Key 从自己机器上调 Bedrock 就会失败。

4.3 AWS 凭证安全最佳实践澄清

在凭证安全方面，需要区分两类场景：

长期运行的应用（如 EC2、ECS、Lambda）：应使用 IAM 角色（Role）而非长期 AK/SK。角色提供临时凭证，自动轮换，是 AWS 推荐的标准实践。
不得不使用 AK/SK 的场景：例如本地开发、第三方系统集成、跨云调用等。此时应确保：使用最小权限、定期轮换、配合本文的来源限制策略。
第三方模型 API Key：不在 IAM 体系内，但同样需要存入 Secrets Manager、设置自动轮换、并在网关层做 IP / 来源限制。

五、方案三：Amazon GuardDuty AI Protection

2025 年 6 月，AWS 推出了 Amazon GuardDuty AI Protection，专门用于检测与 AI 工作负载相关的威胁。它不需要手动配置规则，只要在 GuardDuty 控制台开启 AI Protection 功能，即可自动开始监控。

5.1 三类核心检测

目前已支持的三类检测：

检测类型	场景举例
凭证异常使用	泄漏的 AK/SK 被用于从异常 IP/区域调用 Bedrock
异常调用模式	突发的模型调用量飙升、调用的模型与历史模式不符
未授权访问	尝试调用未获授权的模型或资源

5.2 告警通知与处置闭环

启用 GuardDuty AI Protection 后，建议配合以下闭环：

告警通知：通过 EventBridge 将 GuardDuty Finding 转发至 SNS、Slack/企业微信、或工单系统；
自动处置：使用 EventBridge + Lambda 在检测到高严重性 Finding 时自动禁用泄漏的 AK/SK、调整 IAM 权限；
事后审计：结合 CloudTrail 日志进行调用来源回溯，确认泄漏范围并轮换受影响凭证。

六、加固 Checklist

以下清单涵盖技术与管理两类措施，建议作为团队内部的安全加固自检表。

6.1 技术措施

检查项	对应风险	优先级
应用均使用 IAM Role，而非长期 AK/SK	①③	P0
Bedrock API Key 仅使用短期 Key（≤12h），生产环境禁用长期 Key	①⑥	P0
必须使用 AK/SK 的场景已配置来源限制（VPCE/IP）	①③	P0
AK/SK 定期轮换（建议 ≤90 天）	①③	P0
第三方 API Key 存入 Secrets Manager 并自动轮换	①③	P0
启用 AWS Budgets + Cost Anomaly Detection	⑥	P0
CloudWatch 对 Bedrock 调用量/Token 用量设置告警	⑥	P0
启用 GuardDuty AI Protection	①②⑥	P1
启用 CloudTrail 并开启 Bedrock 数据事件日志	①⑤⑥	P1
CI/CD 流水线集成凭证扫描（git-secrets / Gitleaks）	①②	P1
定期审计未使用的 IAM User / AK/SK（IAM Access Advisor）	③⑥	P1
为高消费场景实现 Token 级 Cost Sentry（Step Functions + CW + DDB）	⑥	P1
考虑 Bedrock 的跨区域推理（Cross-Region Inference）或 AgentCore Gateway 替代第三方代理层，从根本上消除 Key 集中存储的问题	⑦	P2

6.2 管理措施

检查项	对应风险	优先级
明确凭证责任人与发放/回收流程	全部	P0
建立凭证泄漏应急响应预案（Runbook）	全部	P0
定期进行安全培训：“禁止硬编码凭证”	①④	P1
离职/转岗流程纳入凭证回收环节	④	P1
将 Checklist 纳入季度安全评审，持续迭代改进	全部	P2

6.3 落地建议

第一周：完成所有 P0 项目——这些是成本最低、见效最快的措施。

第二周：推进 P1 项目，建立完整的监测、审计与流程体系。

持续优化：定期复查 P2 项目与新增的安全服务功能。

七、小结（Conclusion）

Token 滥用是 AI 时代企业必须正视的安全风险。凭证泄漏的窗口可能只有几分钟，而经济损失可以在数小时内快速累积。本文给出的三个方案——账单异常监控、凭证来源限制、GuardDuty AI Protection——可以并行推进，形成分层防护：

账单监控是成本熔断护栏，确保损失不会无限扩大；
来源限制是即时拦截，让泄漏的凭证无法被外部使用；
GuardDuty AI Protection 是智能检测，持续发现未知威胁。

建议从本文的加固 Checklist 开始，在第一周内完成 P0 项目。如果您需要更深入的实施指导，欢迎参考 AWS 官方文档或联系云架构师团队。

➡️ 下一步行动：

相关产品：

Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
Amazon GuardDuty — 智能威胁检测
Amazon VPC — 隔离云网络
Amazon IAM — 身份管理和访问权限
Amazon CloudTrail — 审计跟踪

相关文章：

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客