2026-10-27 17:04:44 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

AK/SK 泄露全景分析

原创

SharkJ0001
SharkJ0001

Neon-X Sec

2026年10月26日 19:10
北京

去阅读

摘要

2025 年 6 月 25 日，阿里云在官网发布《【风险通告】关于用户 AccessKey 保管不当导致勒索和数据泄漏的风险预警》。标题没有使用“配置不当”“权限过高”这类技术化表述，而是直接把“AccessKey 保管不当”与“勒索”“数据泄漏”两个业务后果并列。这个信号很清楚：云上攻击的主战场，正在从服务器和网络边界，转向身份与凭据。

AccessKey ID 与 SecretAccessKey（合称 AK/SK）是调用云 API 的长期身份凭证。它不像控制台密码那样需要登录、输入验证码或完成多因素认证；只要持有这对字符串，攻击者就可以在任意地点、以程序化方式、按账号被授予的权限操作云资源。泄露的后果也因此被放大：从批量创建 ECS 挖矿，到接管对象存储、横向进入云主机控制台，再到删除数据、索要赎金，整条链路可以在数小时内完成。


核心结论　第一，AK/SK 是云账号权限的“离线副本”，泄露即失陷，主账号 AK 风险最高；第二，五起公开事件显示，泄露点已经从代码和客户端，延伸到主机、CI/CD 与软件供应链；第三，危害远不止账单，还包括数据泄露、勒索、横向接管、业务中断与合规责任；第四，防护必须围绕身份、凭据生命周期、检测响应和供应链四条线同时展开；第五，事发后的前 4 小时决定损失上限：先控身份、再控资源，止损与取证并行。

核心结论　第一，AK/SK 是云账号权限的“离线副本”，泄露即失陷，主账号 AK 风险最高；第二，五起公开事件显示，泄露点已经从代码和客户端，延伸到主机、CI/CD 与软件供应链；第三，危害远不止账单，还包括数据泄露、勒索、横向接管、业务中断与合规责任；第四，防护必须围绕身份、凭据生命周期、检测响应和供应链四条线同时展开；第五，事发后的前 4 小时决定损失上限：先控身份、再控资源，止损与取证并行。

本文以阿里云、腾讯云官方文档和 2024—2026 年公开披露的五起事件为基础，回答五个问题：攻击者究竟从哪里拿到 AK/SK；拿到之后如何把一组权限变成实际控制；会造成哪些超出“账单”之外的损失；企业应当如何把凭据当作身份来治理，并把防护延伸到软件供应链；事件发生后如何快速止损、定位根因并还原全过程。文中的案例事实均来自公开来源，分析部分则基于这些事实做攻击链还原与防御推演。

一、AK/SK 的技术本质：为什么泄露即失陷

1.1 一对字符串如何变成云账号

云 API 的认证不依赖“会话”，而依赖“签名”。AccessKey ID 是公开的身份标识，SecretAccessKey 是只有持有者知道的密钥。客户端调用 API 时，用 SK 对请求参数、时间戳等信息计算签名，服务端用同一把 SK 复算并校验。SK 本身不会出现在网络请求中，但一旦泄露，攻击者就能在本地生成完全合法的签名，服务端无法区分请求来自真实程序还是攻击者。

这带来一个关键结论：长期 AK/SK 是账号权限的“离线副本”。它不受登录页、验证码、异地登录风控的保护，也不天然受 MFA 约束。控制台账号被盗，攻击者还需要绕过登录环节；AK 泄露，攻击者直接拥有 API 层的通行证。腾讯云文档对 AK 的定义写得很直接：AK 代表账号身份及权限，SecretKey 参与请求签名，必须保密。

表 1　控制台账号与长期 AK/SK 的风险差异


维度	控制台账号密码	长期 AK/SK
认证方式	交互式登录	直接调用云 API
多因素认证	可强制开启	长期 AK 默认没有二次验证
使用主体	人	程序、脚本、CI/CD、客户端
操作速度	手工、分钟级	批量、并发、秒级
发现难度	异地登录、异常登录告警	混在正常 API 调用中，常在账单或数据异常后才暴露
权限边界	受登录风控与角色限制	由策略决定；主账号 AK 权限不受 RAM 策略约束

表中最后一行值得单独说明。阿里云明确建议不要创建主账号 AccessKey，原因不只是“权限大”，而是主账号 AK 的权限无法像 RAM 用户那样通过策略收窄。在后面的“28 小时”案例里，运维人员试图限制实例创建权限却做不到，只能逐台删除攻击者创建的 ECS，这正是主账号 AK 的结构性风险。

1.2 官方风险通告释放的信号

阿里云 2025 年 6 月的风险通告把 AK 保管不当与勒索、数据泄漏直接关联，说明攻击者的变现方式已经发生变化。过去，AK 泄露更多被理解为“被人拿去挖矿”；现在，攻击者会先枚举对象存储、数据库、日志和备份，评估数据价值，再决定是窃取、删除还是加密勒索。算力盗用是“用你的钱赚他的币”，数据勒索则是“用你的数据向你要钱”，后者的损失上限更高，也更难在短时间内恢复。

腾讯云在《Cloud API Key Security Usage Scheme》中列出的泄露路径，基本覆盖了企业最常见的疏忽：代码仓库硬编码、客户端反编译、文档或示例代码泄露、客户端临时密钥被劫持、日志/监控/环境变量残留、服务器被攻破后读取明文配置。把这些路径与后文的真实事件对照，会发现它们并非理论风险，而是已经被反复验证的攻击入口。

二、五起事件：泄露点在哪里，攻击链如何展开

2.1 小学小程序：密钥藏在客户端的请求包里

2024 年 5 月，阿里云开发者社区披露了一起针对某小学的云账号接管案例。测试人员在微信小程序的登录请求包中发现了腾讯云 AK/SK。请求带有明显的小程序特征：Xweb\_xhr: 1、MicroMessenger、MiniProgramEnv/Windows；相关数据采用 PHP 序列化格式，反序列化后即可提取出凭据。

攻击链并不复杂，但每一步都踩在常见的防护盲区上：小程序请求包泄露 AK/SK，反序列化提取凭据，验证凭据归属腾讯云，接管对象存储桶，横向控制 RAM 用户与云主机控制台，最终获取控制台账号密码。披露者称已删除控制台自动创建的后门用户，未进行其他增删改查，漏洞已上报并修复。

这起事件的核心问题不是“密钥强度不够”，而是“长期密钥根本不应该出现在客户端”。小程序、App、H5 的一切代码和数据都可能被抓包、反编译、调试；把长期 AK/SK 写进客户端，等于把云账号的一部分权限随安装包一起分发。客户端需要的不是一把长期钥匙，而是一个受约束的临时身份：由后端做身份校验，换取分钟级有效、绑定资源和操作的 STS 凭证。

来源：阿里云开发者社区.《AKSK 泄露导致横向移动并接管云主机控制台》. 2024-05-08. https://developer.aliyun.com/article/1503148

2.2 28 小时、37 万元：主账号 AK 躺在跳板机里

2025 年 3 月，阿里云开发者社区发表《AK 泄漏 28 小时：运维工程师的极限自救》，主角是一位化名“赵明明”的运维工程师。为了赶项目，他在周五 21:09 用主账号创建了一个拥有全部服务访问权限的 AK，并把它明文保存在跳板机的配置文件中。他的判断是：跳板机只开放内网，测试完删掉即可。

但攻击并不是从这把 AK 开始的。一个月前，公司一台公网暴露的老旧开发服务器就被扫中。那台机器运行着存在已知漏洞的 Apache Struts，长期未修补，攻击者利用远程代码执行拿到权限并植入后门。此后，攻击者持续在内网扫描，周五晚发现跳板机，用弱口令暴力破解 SSH 登录，再通过历史命令记录找到配置文件中的主账号 AK。

周六晚，攻击者确认主机无活动后，用这把 AK 通过 API 批量创建 ECS 实例，植入挖矿程序。挖矿病毒继续横向扩散，感染关键业务实例，并具备自动重启的持久化能力。周日下午赵明明醒来时，手机上有 23 个未接来电、数百条告警短信，账单金额 372,584 元，时间跨度约 28 小时。由于使用的是主账号 AK，他无法通过 RAM 策略限制实例创建，只能逐台检查、删除非法实例；部分关键业务实例已被感染，不能简单释放，最终由云安全工程师查杀病毒、阻断矿池访问。事后，他新建了 RAM 子账号和 AK 替换原使用场景，本人也受到公司处分。

这起事件最值得复盘的不是“某个人犯了错”，而是三层防御同时失效：公网资产存在未修复的 RCE，跳板机使用弱口令，高权限凭据明文落盘。任何一层守住，攻击链都会中断。安全事件很少由单点失误造成，它更像是一串“刚好都能用”的巧合。

来源：阿里云开发者社区.《AK 泄漏 28 小时：运维工程师的极限自救》. 2025-03-05. https://developer.aliyun.com/article/1655604

2.3 accesskey\_tools：500 stars 的云利用工具，AWS 模块全军覆没

2026 年 5 月 14 日，先知社区发布《速速自查！500stars 云利用工具投毒分析》。作者在审计一款拥有 500 stars、名为 accesskey\_tools 的多云 AccessKey 利用工具集时，发现 AWS 模块藏有后门：aliyun 和 tencentcloud 目录使用官方 SDK、代码干净，aws 目录下 7 个功能脚本则全部通过同一条链路外泄凭证。6 月 11 日，FreeBuf 进一步报道该事件，并称后门已存在约三年。

后门有三层伪装。第一层把 C2 域名藏进名为 iam\_md5 的变量：aws/aws\_select\_iam.py 第 50 行的字符串看似哈希，实为十六进制编码，去掉首字符后解码得到 api.aliyun-sdk-requests.xyz；主域名 aliyun-sdk-requests.xyz 刻意模仿阿里云官方域名 aliyuncs.com。第二层是静默安装恶意依赖：脚本用 pip install -qqq --disable-pip-version-check 安装第三方包，再用 os.execv 原地重启进程；包来自 GitHub 账号 andresrianch 的 enumerate-iam 项目，而合法项目作者是 andresriancho，只少了一个字母 o。第三层是 SDK 端点劫持：恶意包中的 get\_client 支持通过 components 参数注入自定义端点，脚本再用 botocore 的 ComponentLocator.register\_component(name='AWS\_ENDPOINT', ...) 覆盖端点解析，把原本发往 \*.amazonaws.com 的请求整体重定向到 C2。

后门借助 Python 的 import 机制传播：运行 AWS 目录下任意脚本，都会触发 import aws\_select\_iam，完成安装并激活。不同脚本对应不同目标：aws\_select\_iam.py 把 IAM 查询路由到 C2；aws\_url\_console.py 风险最高，它通过 get\_federation\_token 申请的临时凭证包含 AccessKeyId、SecretAccessKey 和 SessionToken，在高权限场景下可能带来 AdministratorAccess 级别的临时访问；aws\_download\_s3.py 泄露 S3 凭证；aws\_list\_ec2.py 和 aws\_ec2\_exec.py 泄露 EC2 与 SSM 凭证。恶意 get\_client 在创建客户端时就能接触凭据，ComponentLocator 又把请求整体转发，因此 AK/SK、SessionToken 以及带 SigV4 签名的完整 API 请求都会落到攻击者手里。

这类工具的可怕之处在于“信任倒置”：用户为了检查云账号安全，主动把最高权限凭据交给来路不明的工具。处置建议是停止使用并删除项目、轮换所有密钥、检查 CloudTrail 异常调用、卸载 aws\_enumerateiam 和 enumerate-iam，只从官方 PyPI 安装。

来源：先知社区.《速速自查！500stars 云利用工具投毒分析》. 2026-05-14. https://xz.aliyun.com/news/92135；FreeBuf.《投毒事件：AKSK 利用工具存在后门投毒》. 2026-06-11. https://www.freebuf.com/news/485905.html

2.4 GhostAction：CI/CD 成为凭据收割机

2026 年 8 月 31 日至 9 月 30 日，名为 GhostAction 的供应链攻击活动再次活跃。攻击者利用盗取的 GitHub 账号权限，向仓库注入恶意 Actions 工作流，文件名伪装成 github\_actions\_security.yml（显示名 Github Actions Security）或 security-check.yml（显示名 Security Check），提交信息写成“Add Github Actions Security workflow”这类日常维护口吻。

恶意工作流不是盲目收集所有环境变量，而是先检查仓库已有的工作流和配置历史，找出${{ secrets.NAME }} 形式的引用，把具体的 secret 名称写进恶意文件；随后等待普通 push 事件触发，读取指定 secret，再通过 curl POST 外传。外传使用明文 HTTP，目的 IP 为 193.32.204.199。攻击者还更新了 92 个此前残留的恶意文件，把收集地址改为新端点；旧文件如果未清除，后续正常 push 仍可能再次触发。

根据披露数据，这一轮有 772 个公共仓库、373 个用户或组织被植入恶意工作流，2,577 个敏感凭证被列为目标。复核 605 个仓库的 3,669 次运行后发现，多数被平台拦下并转入人工批准，但仍有 32 个仓库的 499 次实际运行，其中 336 次成功，13 个仓库的 26 个凭证被窃。截至 2026 年 10 月 5 日，仅 124 个仓库（约 16%）在公开提交历史中完成清理。目标包括云密钥、SSH 凭据、容器注册表登录信息、数据库密码和 GitHub 令牌；上一轮活动（2025 年 9 月）曾影响 817 个公共仓库，至少窃取 3,325 个凭证。

来源：FreeBuf.《GhostAction供应链攻击卷土重来，恶意GitHub Actions窃取CI/CD凭证》. 2026-10-08. https://www.freebuf.com/articles/development/505321.html

2.5 Shai-Hulud：一个 npm 包，卷走多云凭据

2026 年 9 月 8 日，JFrog China 披露了新一轮 Shai-Hulud npm 蠕虫活动：影响 400 多个 npm 包、1,700 多个版本，首批包括 keyv 6.0.0、cacheable 2.5.1 和 @cacheable/\*。受感染包在 preinstall 阶段执行 node setup.mjs；如果本机没有 Bun，就下载 Bun 1.3.13，运行 math\_init.js，完成后删除临时文件。

它的传播方式把“供应链”三个字演绎得很完整。npm 蠕虫部分会先验证 token 满足 bypass\2fa === true 且具备写权限，再对所有可写包下载最新 tarball、植入 math\_init.js 和 setup.mjs、替换 scripts、提升补丁版本，最后通过认证 PUT 发布。GitHub 仓库感染部分会向每个仓库最多 50 个分支写入 5 个钩子文件，打开 VS Code 文件夹或启动 Claude 会话即可触发，提交信息为 chore: update config，并伪造 Claude 共同作者。Actions 窃密部分则用 ghp\/gho\_ 令牌枚举最多 100 个可推送仓库，创建 dependabot/github\_actions/format/setup-formatter 分支，注入 codeql\_analysis.yml（工作流名为 Run Copilot），把 secrets 写入 format-results.txt 后作为制品上传，再删除运行记录和分支。

它窃取的内容几乎覆盖了开发者的整个身份体系：npm token、GitHub PAT/OAuth/Actions 令牌、AWS/Azure/GCP/阿里云/腾讯云凭据、Kubernetes/Helm/Vault、.env、Shell 历史、SSH 私钥、VPN、浏览器凭据、聊天软件、加密钱包，以及 OpenAI、Anthropic、Claude、Cursor、Codex、Gemini 等 AI 凭据；还包括 /etc/shadow、/proc/self/environ、Linux Actions Runner 进程内存中的 secret-store，以及 AWS Secrets Manager/SSM 中 17 个区域的密钥。C2 不写死域名，而是通过以太坊合约的 eth\_call 动态获取，数据经 AES-256-GCM 加密、再用内嵌 RSA 公钥封装；C2 返回的 code 还能进入 eval，形成远程代码执行。GitHub 公开仓库还被用作备用外传通道。

来源：JFrog China.《代号“Shai Hulud”的大规模攻击行动再次波及 npm，影响了 keyv 及 400 多个软件包》. 2026-09-08. https://www.jfrogchina.com/blog/shai-hulud/

2.6 五起事件的横向对比

表 2　五起公开事件对比


事件与时间	初始泄露点	关键手法	直接后果
小学小程序（2024-05）	小程序请求包	抓包、PHP 反序列化	OSS、RAM、云主机控制台被接管
28 小时（2025-03）	跳板机配置文件	Struts RCE、SSH 弱口令、历史命令	批量 ECS 挖矿，账单 372,584 元
accesskey\_tools（2026-05）	第三方 AK 工具	500 stars；7 个 AWS 脚本带后门、endpoint 劫持	AWS 凭据、STS Token 与 API 请求外泄
GhostAction（2026-10）	GitHub 账号与 CI	恶意 workflow 读取 secrets	772 个仓库被植入，26 个凭证被窃
Shai-Hulud（2026-09）	npm 包	蠕虫、CI/AI 工具钩子、动态 C2	多云凭据与开发者身份批量泄露

把五起事件放在一起看，会发现一条清晰的迁移路径：泄露点从“人写在配置里”，到“程序写在客户端”，再到“工具和依赖替你写”。攻击者越来越不需要直接入侵企业，只需要污染企业信任的某个环节。

三、利用场景全景：攻击者在哪里找到钥匙

3.1 攻击面地图

表 3　AK/SK 的八层暴露面


层次	典型载体	高发原因
代码层	源码、示例、注释、commit 历史、fork、公开仓库	开发者便利优先，历史记录难清除
客户端层	小程序、App、H5、SDK	客户端可被抓包、反编译
主机层	配置文件、环境变量、Shell 历史、crontab、镜像层、K8s Secret	凭据明文落盘，权限过大
CI/CD 层	环境变量、构建日志、制品、OIDC token	密钥集中，权限放大
配置与协作层	Nacos、Apollo、Wiki、工单、IM	AK 被当作普通配置传播
供应链层	第三方工具、依赖包、Action、镜像、AI 插件	默认信任，缺乏审计
运行时层	RCE、任意文件读取、SSRF	可直接读取主机或元数据中的凭据
人的层	钓鱼、外包、离职、共享账号	长期 AK 不受 MFA 保护

3.2 六类高发场景

第一类是客户端硬编码。小程序尤其危险，因为抓包门槛低、请求结构清晰，且很多团队会把后端签名逻辑直接下沉到前端。案例 1 就是典型：AK/SK 被放在登录请求的数据结构里，反序列化即可还原。正确的做法是后端持有长期凭据，客户端只拿 STS 临时凭证；临时凭证的有效期、权限范围、资源前缀都要收紧，并绑定业务身份，而不是简单地“发一把能用的钥匙”。

第二类是代码仓库与历史提交。硬编码、示例代码、调试输出、注释、配置文件、CI 日志，都可能出现 AK。公开仓库的爬取已经产业化，攻击者会用关键词、正则和熵检测持续扫描。更麻烦的是，删除当前文件并不等于清除泄露：commit 历史、fork、PR、制品和缓存都可能保留旧凭据。企业需要把 secret scanning 放到 pre-commit、PR 和仓库历史三个层面，而不是只在代码评审时靠人眼。

第三类是主机与运维设施。配置文件、环境变量、Shell 历史、crontab、备份脚本、容器镜像层、Kubernetes Secret 都是高发位置。Kubernetes Secret 默认只是 base64 编码，不是加密；有节点或 etcd 权限的人可以直接读取。案例 2 中，攻击者正是通过历史命令找到配置文件路径，再拿到主账号 AK。跳板机、堡垒机、构建机这类“运维枢纽”往往同时拥有高权限和多套凭据，一旦被攻破，收益远高于普通业务服务器。

第四类是配置中心与协作工具。Nacos、Apollo 等配置中心一旦未授权或弱口令，攻击者可以批量读取所有配置；Wiki、工单、群聊里也经常出现“临时发一下 AK”的对话。AK 被当作普通配置传播后，泄露路径就从“技术漏洞”变成了“管理漏洞”，很难通过单点加固解决。

第五类是 CI/CD 与供应链。CI 环境天然聚合代码、密钥和云权限：构建需要拉代码，部署需要云凭据，测试需要数据库密码。案例 4 用一个 workflow 文件就读取了仓库 secrets，案例 5 用一个 npm 包就卷走了多云凭据，案例 3 则让用户在“主动使用”中交出 AK/SK。攻击者不需要突破生产网，只需要进入开发者信任的工具链。

第六类是运行时漏洞与元数据服务。公网 RCE（如案例 2 的 Apache Struts）、任意文件读取、SSRF 都可以直接读取主机上的凭据。云主机元数据服务是另一个常被忽视的入口：阿里云 ECS 的元数据地址是 100.100.100.200，AWS 是 169.254.169.254；如果实例绑定了过大的角色权限，又没有启用元数据访问加固（例如 AWS IMDSv2 或云厂商提供的等效机制），攻击者就可能通过 SSRF 换取 STS 临时凭证。临时凭证虽然有效期短，但在有效期内同样可以造成实质性破坏。

3.3 拿到 AK 之后：标准攻击链

攻击者拿到 AK/SK 后，通常会按“验证—枚举—提权—变现”四步走。

第一步是验证与画像。调用身份接口（各云厂商都提供 GetCallerIdentity 类接口）确认账号、用户或角色身份，判断这把 AK 属于主账号、RAM 用户还是 STS 临时凭证，再结合权限试探确定能做什么。这个阶段调用量很小，混在正常请求中几乎不可见。

第二步是枚举资产。攻击者会遍历 ECS、RDS、OSS/COS、SLS、RAM、VPC、域名、证书、密钥管理等服务，重点寻找对象存储、数据库快照、备份、日志和高价值数据。对象存储尤其受青睐，因为一个桶里可能同时有业务数据、备份、配置和凭据。

第三步是提权与持久化。常见的 API 包括 CreateUser、CreateAccessKey、AttachPolicyToUser、CreateLoginProfile、CreateRole、PassRole，以及修改桶策略的 PutBucketAcl、PutBucketPolicy。攻击者可能新建一个看起来正常的 RAM 用户，绑定一个高权限策略，再创建一把新 AK；也可能修改角色信任策略，让外部账号可以扮演。即使原来的 AK 被删除，后门仍然存在。

第四步是变现。挖矿是最直接的方式，弹性算力让攻击者可以在几小时内拉起大量高配实例；数据窃取与勒索则更高收益，先批量下载，再删除或加密，最后索要赎金；还有短信轰炸（调用 SendSms、SendBatchSms）、DDoS、代理跳板，以及以被攻陷的云账号为跳板横向进入企业 IDC 或其他云。整个链条在 API 层面往往只需要数十次调用，耗时以分钟到小时计，而防守方常在账单或数据异常时才察觉。

四、危害评估：账单只是最表层的损失

4.1 直接经济损失

案例 2 的 372,584 元账单是一个直观的样本，但它不是上限。攻击者可以创建 GPU 实例、高配内存机型、按量付费的数据库和带宽，还可以利用短信、CDN、对象存储请求产生费用。云账单通常有延迟，等到发现时，资源可能已经运行了数小时甚至数天。更棘手的是，部分费用发生在删除资源之后才结算，止损并不等于停止计费。

4.2 数据泄露与勒索

阿里云风险通告把“勒索”和“数据泄漏”放在标题里，说明这两类后果已经被官方视为 AK 保管不当的典型风险。攻击者拿到对象存储或数据库权限后，可以先把数据批量下载，再通过 PutBucketAcl、PutBucketPolicy 把桶设为公开，或直接 DeleteObject、删除快照。勒索团伙的常见做法是“先窃取、再删除、后索要”，即使企业有备份，恢复时间、业务停摆、客户信任损失也会构成二次伤害。

4.3 横向移动与账号接管

案例 1 展示了一条完整的横向路径：从对象存储到 RAM 用户，再到云主机控制台，最后拿到控制台账号密码。很多企业会把控制台密码、数据库密码、第三方 API Key 存放在对象存储或代码仓库里，一旦 AK 泄露，攻击者就能沿着“钥匙串”继续扩张。云账号被接管后，攻击者还可以修改告警配置、删除日志、创建新的管理员身份，增加溯源和恢复难度。

4.4 业务中断与合规责任

DeleteInstance、DeleteDBInstance、DeleteBucket 这类操作可以在几分钟内造成不可逆的业务损失。对于金融、医疗、教育等行业，数据泄露还可能触发《数据安全法》《个人信息保护法》以及等级保护要求下的报告、通知和整改义务；云账号被用于挖矿、诈骗短信或其他违法活动，也会带来监管问询和声誉风险。安全事件的处理成本，往往数倍于直接的资源账单。

4.5 供应链放大

前三个案例是“单点泄露”，后两个案例则是“批量泄露”。一个被投毒的 AK 工具影响所有使用它的安全人员；一个恶意 workflow 影响 772 个仓库；一个 npm 包影响 400 多个包、1,700 多个版本。供应链攻击把“某家企业疏忽”放大为“一批企业同时失守”，也让传统的“逐家排查”变得低效。

表 4　AK/SK 泄露的影响维度


影响维度	典型攻击动作	直接后果	主要发现线索
经济	批量创建 ECS、GPU、带宽	账单激增，资源被用于挖矿	账单异常、实例数突增
数据	下载对象存储、导出数据库	数据泄露、勒索	访问日志、外联流量
身份	创建用户、AK、角色	账号被持久化控制	RAM/API 审计
业务	删除实例、数据库、桶	业务中断、数据丢失	可用性告警、删除事件
合规	数据外泄、账号被用于违法	监管问责、客户索赔	事件报告、舆情
供应链	投毒工具、包、Action	批量凭证泄露	CI 日志、包发布记录

五、防护体系：把密钥当作身份来治理

5.1 四条原则

AK/SK 防护可以压缩成四句话：身份最小化，凭据短时化，使用可观测，泄露可止损。身份最小化，是指任何一把 AK 只拥有完成当前任务所需的最小权限；凭据短时化，是指优先使用 STS 临时凭证，长期 AK 只作为例外；使用可观测，是指每一次敏感 API 调用都能对应到人、程序、源 IP 和时间；泄露可止损，是指发现泄露后能在分钟级完成限权、轮换和取证，而不是等到账单出来。

5.2 身份与权限

第一，不创建主账号 AK。主账号只用于极少数必须由主账号完成的管理操作，并开启 MFA；日常运维、CI/CD、第三方集成全部使用 RAM 子账号或角色。阿里云官方建议很明确：不要使用主账号创建 AccessKey，不要授予 AdministratorAccess，OSS 只读场景应使用 AliyunOSSReadOnlyAccess 这类细粒度策略。

第二，按最小权限授权。权限策略要落到具体资源、具体动作，必要时加上源 IP、时间、MFA 等条件；能用资源组、标签隔离的，不要用账号隔离；能用只读的，不要给读写；能给单个桶的，不要给整个 OSS。对于需要跨账号访问的场景，优先使用角色扮演和信任策略，而不是共享 AK。

第三，控制台用户与 API 用户分离。需要登录控制台的人员开启 MFA，只调用 API 的程序使用独立的 RAM 用户，不共享凭据。腾讯云文档把“API 用户与控制台用户分开”列为最佳实践，原因是一旦混用，一把 AK 泄露就可能同时威胁控制台和 API 两条路径。

第四，配置网络访问限制。为 AK 设置 IP 白名单或网络访问限制，把“可用范围”从“全球”收缩到“已知出口”。这不能阻止凭据泄露，但可以显著降低攻击者使用泄露凭据的成功率，也为检测争取时间。

5.3 凭据生命周期

生成阶段，要回答三个问题：谁需要、做什么、用多久。默认不生成长期 AK；确需生成时，记录用途、责任人、源 IP 和过期时间。存储阶段，优先使用 KMS、Secrets Manager 或云厂商的凭据管理服务；不要把 AK 写进代码、镜像、配置文件、Wiki 或工单。环境变量比硬编码好，但不是安全边界：进程内存、/proc/self/environ、崩溃转储、日志和监控都可能把它带出去，Shai-Hulud 就专门读取了 /proc/self/environ。

使用阶段，要区分“人”和“程序”。人使用控制台加 MFA；程序使用角色加 STS；CI/CD 使用 OIDC 联合身份换取短期凭证，而不是把长期 AK 存进 Secret。轮换阶段，要建立双密钥过渡流程：创建新 AK、替换调用方、验证业务、禁用旧 AK、观察、删除。阿里云的操作细节值得注意：RAM 用户禁用 AK 需完成 MFA 验证；如果最近 60 天有调用记录，系统会提示业务中断风险；禁用未满 7 天删除会再次提示；删除后进入回收站保留 30 天，可恢复。

回收阶段，要覆盖所有“藏钥匙的地方”。阿里云官方列出的排查位置包括本地开发机（环境变量、SDK 配置、CLI 凭证文件）、CI/CD（环境变量、凭证仓库、部署脚本）、第三方应用与 SaaS、容器与镜像（镜像层、Kubernetes Secret、编排模板）、定时任务与运维脚本（crontab、备份脚本、监控脚本），以及短信等消息通知服务的调用方。只轮换主应用、漏掉定时任务或第三方 SaaS，是泄露后二次失陷的常见原因。

5.4 检测与告警

阿里云提供了三层与 AK 相关的保护：外部线索监测与通知、AccessKey 限制性保护、登录自动保护。发现 AK 已公开时，阿里云会通过短信、邮箱、站内信通知；对确认泄露的 AK 实施限制性保护，禁止其调用部分云产品的高危权限 API；检测到风险后，还可能自动限制关联 RAM 用户登录控制台，出现 Authentication.Block.AccountFrozen 或“当前账号不允许登录”的报错。企业应把安全联系人、告警可达性和处置权限纳入日常管理，避免案例 2 中“23 个未接来电”的情况重演。

审计是第一现场。阿里云操作审计的 AccessKey 审计支持按 AccessKey ID 查询最近 90 天的 API 调用记录，包括时间、操作、源 IP、云服务。需要特别注意的是，OSS、SLS 等未接入操作审计的数据类操作，不会完整出现在管控事件里，必须结合各产品自己的访问日志。仅看 90 天的管控事件，可能会漏掉数据面的下载和删除行为。

表 5　需要重点监控的高危 API


高危 API	风险	建议动作
CreateUser、CreateAccessKey、CreateLoginProfile	建立后门身份	告警并人工确认
AttachPolicyToUser、CreatePolicyVersion、SetDefaultPolicyVersion	提权	告警并核对变更单
CreateRole、UpdateRole、PassRole	角色信任滥用、权限传递	告警并核对信任策略
DeleteInstance、DeleteDBInstance、DeleteBucket	破坏业务与数据	告警并阻断非变更窗口操作
PutBucketAcl、PutBucketPolicy	数据暴露	告警并立即核查桶策略
DeleteObject、DeleteLogStore、DeleteProject	销毁数据与痕迹	告警并启用版本控制/合规保留
SendSms、SendBatchSms	短信滥用、诈骗	限额、告警并核对模板

行为基线同样重要。非常用 IP 或地域、非工作时间、短时间大量调用、单一 AK 跨多个产品、UserAgent 与业务不符、调用量突然放大，都是值得告警的信号。账单侧可以监控 ECS 实例数突增、按量付费高配机型、GPU 实例、带宽和短信费用。把“身份行为”和“费用行为”放在一起看，往往比单看日志更早发现问题。

检测只是第一步。确认泄露后如何按顺序止损、如何定位根因、如何还原全过程，见第六章。

5.5 开发与 CI/CD 防线

在开发侧，secret scanning 应该覆盖三个位置：开发者本地的 pre-commit、代码平台的 PR 检查、仓库的全量历史扫描。工具可以选择 gitleaks、trufflehog 等开源方案，也可以使用云厂商或代码平台自带的检测。规则上，除了常见前缀（阿里云 LTAI、腾讯云 AKID、AWS AKIA/ASIA），还应结合熵检测和上下文，避免只靠正则漏掉自定义格式。

在 CI/CD 侧，优先用 OIDC 联合身份替代静态 AK：GitHub Actions、GitLab CI 等平台可以给工作流签发短期身份令牌，再由云平台的角色信任策略换取临时凭证。这样即使仓库或工作流被攻破，攻击者能拿到的也只是短时、受限的凭证。对必须使用 Secret 的场景，要做到日志脱敏、禁止 echo、限制 fork PR 访问、为环境设置审批、把第三方 Action 固定到完整 commit SHA、给 GITHUB\_TOKEN 最小权限、限制 Runner 的出网访问。

在依赖侧，使用锁文件、私有制品库或代理、SBOM 和 SCA；对刚发布的新版本设置“成熟度”门槛，避免在投毒事件爆发后的几小时内自动升级；关闭不必要的 install scripts，npm 12 及以上默认不执行 preinstall，可以降低一类攻击面，但不能替代凭据轮换。在工具侧，只从官方源下载，校验哈希或签名，阅读安装脚本，尽量在隔离环境、低权限账号下运行；不要把生产凭据交给“来路不明的安全工具”。

5.6 组织与流程

技术措施之外，还需要一套可执行的管理机制。第一，建立 AK 台账：记录 AccessKey ID、用途、责任人、源 IP、绑定权限、创建时间、最后调用时间、轮换周期。腾讯云文档把“事前梳理 AK 请求状态”作为核心建议，目的就是在泄露发生时能快速定位影响面、快速替换。第二，建立变更审批：新增高权限 AK、修改角色信任策略、调整桶策略都要走审批。第三，建立离职与项目回收流程：人员离职、项目结束、外包退场时，回收 AK、角色和权限。第四，建立演练机制：每季度模拟一次 AK 泄露，计时完成限权、轮换、排查和恢复，验证告警是否真的能找到人。

六、应急处置：黄金 4 小时、根因定位与全程还原

告警响起时，企业面对的是一连串选择题：先删 AK 还是先看日志，先隔离主机还是先救业务，先清后门还是先取证。顺序错了，损失会扩大；证据没了，复盘只能靠猜。本章给出以阿里云为主、可映射到其他云的动作序列，目标是在 4 小时内控制损失、24 小时内还原过程。

6.1 处置顺序：先控身份，再控资源

发现泄露后的处置，建议按以下顺序执行。第一，确认泄露范围：是主账号 AK、RAM 用户 AK 还是 STS，是否还有其他凭据同时暴露。第二，判断是否仍在使用：未使用的立即禁用并删除；仍在使用的创建新 AK、替换调用方、验证业务、禁用旧 AK、再删除。第三，短期内无法轮换的，先缩小权限：阿里云官方提供了一组 Deny 策略，覆盖 RAM 提权类 API、ECS 删除、RDS 删除、OSS 删除与桶策略修改、SLS 删除、短信发送等；在旧 AK 禁用、删除前不要解除限制。第四，检查 MFA 和异常身份：排查新创建的 RAM 用户、角色、AK，删除非正常或闲置身份。第五，检查异常费用并清理恶意资源。第六，修复泄露根因：代码仓库、配置中心、主机漏洞、CI/CD 配置。第七，按要求完成通知、报告和复盘。

需要强调一点：仅禁用 AccessKey 可能不足以解除云平台的安全限制，必须完成删除或轮换操作；如果 RAM 用户已被冻结、无法登录，需要用主账号进入 RAM 控制台处置，处置后仍无法登录再提交工单申请解除风控。

下面是一段精简后的 RAM Deny 策略示例，取自阿里云官方《AccessKey 泄露处理方案》，用于在无法立即轮换时先阻断高危操作。实际使用时，应结合业务权限评估，避免误伤。


{ \"Version\": \"1\", \"Statement\": [ { \"Effect\": \"Deny\", \"Action\": [ \"ram:CreateUser\", \"ram:CreateAccessKey\", \"ram:CreateLoginProfile\", \"ram:CreateRole\", \"ram:AttachPolicyToUser\", \"ram:AttachPolicyToRole\", \"ram:CreatePolicyVersion\", \"ram:SetDefaultPolicyVersion\", \"ram:PassRole\", \"ram:UpdateRole\", \"ram:UpdateUser\" ], \"Resource\": \"\\" }, { \"Effect\": \"Deny\", \"Action\": [ \"ecs:DeleteInstance\", \"ecs:DeleteInstances\", \"rds:DeleteDBInstance\", \"rds:DestroyDBInstance\", \"oss:DeleteBucket\", \"oss:DeleteObject\", \"oss:PutBucketAcl\", \"oss:PutBucketPolicy\", \"log:DeleteProject\", \"log:DeleteLogStore\", \"dysms:SendSms\", \"dysms:SendBatchSms\" ], \"Resource\": \"\\" } ] }

{ \"Version\": \"1\", \"Statement\": [ { \"Effect\": \"Deny\", \"Action\": [ \"ram:CreateUser\", \"ram:CreateAccessKey\", \"ram:CreateLoginProfile\", \"ram:CreateRole\", \"ram:AttachPolicyToUser\", \"ram:AttachPolicyToRole\", \"ram:CreatePolicyVersion\", \"ram:SetDefaultPolicyVersion\", \"ram:PassRole\", \"ram:UpdateRole\", \"ram:UpdateUser\" ], \"Resource\": \"\\" }, { \"Effect\": \"Deny\", \"Action\": [ \"ecs:DeleteInstance\", \"ecs:DeleteInstances\", \"rds:DeleteDBInstance\", \"rds:DestroyDBInstance\", \"oss:DeleteBucket\", \"oss:DeleteObject\", \"oss:PutBucketAcl\", \"oss:PutBucketPolicy\", \"log:DeleteProject\", \"log:DeleteLogStore\", \"dysms:SendSms\", \"dysms:SendBatchSms\" ], \"Resource\": \"\\" } ] }


说明：以上为便于阅读的精简版，只保留高风险动作；完整策略、动作清单和适用条件请以阿里云官方文档为准。策略生效前应确认不会阻断关键业务，且不要用“限权”替代“轮换”。https://help.aliyun.com/zh/ram/user-guide/solution-to-accesskey-leakage

这套顺序的背后是三条原则：身份优先于资源，先让攻击者手里的钥匙失效，再处理被创建或改动的资产；隔离优先于删除，删除会同时销毁攻击者的痕迹；取证优先于清理，日志、快照和进程信息一旦丢失就无法复原。

6.2 黄金 4 小时：把动作装进时间盒

前 4 小时最常见的两种失误：一是只盯着告警的那台主机反复清理，忽略了同一把 AK 在其他产品、其他地域的调用；二是一边删资源一边找证据，等想起复盘时，日志、快照和进程信息都没了。用时间盒推进，每个阶段有明确的完成标志，比凭感觉处置更可靠。

表 6　黄金 4 小时处置时间盒


阶段	时间窗	关键动作	完成标志
确认与止损	T+0～30 分钟	确认告警真实性；禁用（而非删除）泄露 AK；冻结异常身份与登录；收紧安全组和公网入口；暂停可疑的 CI/CD 任务	旧 AK 的调用被拒绝，攻击者高危操作失败
影响面盘点	T+30 分钟～2 小时	导出操作审计全量记录；枚举新增与修改的资源；核对账单；检查数据面访问日志；排查后门身份与信任策略	形成“被创建、被修改、被读取”三张清单
清除与验证	T+2～4 小时	阻断 C2 与矿池地址；隔离或重装被控主机；删除后门用户、角色与策略；轮换同环境全部凭据；观察 24 小时	无新增异常调用，业务恢复，证据完成固化

几个容易做反的动作值得单独提醒。第一，先禁用、后删除：禁用保留审计线索，也方便确认业务依赖；删除后的回收站救不回已经发生的利用窗口。第二，先快照、后清理：被控主机在关机或重装前应打快照，进程、启动项和内存里的临时凭证是定位根因的关键。第三，同环境凭据全部视为已泄露：同一台主机、同一个仓库、同一条流水线上的密钥都要轮换，只换被点名的那一把，是二次失陷的常见原因。第四，客户端泄露要同步处置线上包：小程序、App 里的 AK 换掉后，旧版本仍可能被反编译使用，需要发版、提审甚至强制更新。

6.3 快速定位根因：沿“调用—使用—泄露”三条线倒查

根因定位的难点通常不是日志不够，而是“使用点”和“泄露点”不在同一处。案例 2 里，AK 的使用点在跳板机，攻击链却是从一台公网 Struts 服务器开始：RCE 拿权限、植入后门、内网扫描、SSH 弱口令、翻历史命令找到配置文件。只盯“哪台机器在调用”，永远找不到最初的入口。

第一条线是调用侧。以首次异常调用为锚点，看源 IP、UserAgent、接口类型和调用频率：UserAgent 能区分控制台、SDK、CLI 与第三方工具；源 IP 能区分 IDC、住宅代理和云主机；同一把 AK 突然跨多个产品、在非常用地域出现，通常说明已被接管，而不是业务变更。

第二条线是使用现场。主机上看进程、环境变量、配置文件、Shell 历史、crontab 和启动项；容器里看镜像层、挂载的 Secret 和环境变量。对照进程启动时间与最近变更记录，往往能直接指认“谁把凭据带到了这台机器上”。

第三条线是泄露源头。代码侧用 git log -S 检索密钥字符串和可疑提交，检查 fork、PR 与制品；CI 侧检查工作流变更和运行日志；工具与依赖侧对照 2.3 至 2.5 节的教训，排查仿冒包、异常安装脚本和端点劫持；人和流程侧回看配置中心、工单、Wiki 与聊天记录。

判定根因可以用一个简单方法：取出“谁有权读到这把 AK”的集合，与“首次异常调用的时间”做交集，范围最小的位置通常就是泄露点。找到根因的标志不是“改了配置”，而是能完整回答：攻击者从哪个入口进来、用什么身份、在哪台机器上读到了哪份文件。

表 7　五类事件的第一动作与取证要点


事件类型	第一动作	关键日志	根因线索
挖矿（案例 2）	隔离实例、封禁矿池、禁用 AK	实例创建记录、ECS 登录日志	创建来源 IP、SSH 爆破记录、Shell 历史
数据窃取与勒索	收紧 OSS/RDS 权限、核对备份完整性	OSS 访问日志、RDS 审计、删除类操作	桶策略变更人、首次 GetObject 峰值
CI/CD 投毒（案例 4）	停用 CI secrets、吊销 token	GitHub 审计日志、Actions 运行记录	恶意 workflow 提交者、首次外联 IP
npm 蠕虫（案例 5）	隔离构建机、轮换全部凭据	npm 发布记录、Runner 日志	首次出现的包版本、异常 preinstall 行为
客户端硬编码（案例 1）	下线相关接口、改用临时凭证	网关访问日志、客户端请求审计	包体中的硬编码、异常签名请求

6.4 掌握全过程：日志、时间线与证据链

还原过程的前提是日志源齐备。控制面依赖操作审计：AccessKey 审计可回查 90 天的 API 调用，前提是已开通并保留；建议把事件持续投递到日志服务或对象存储长期保存。数据面依赖各产品自身的日志：OSS 访问日志、RDS 审计、日志库、NAS 审计；网络面依赖 SLB/WAF、VPC 流日志和 DNS 查询日志；主机面依赖登录日志与进程审计；研发面依赖 Git 审计、CI 运行日志与制品仓库记录。缺哪一层，时间线就会断在哪里。

在日志服务中按 AK 检索是还原过程的第一步。下面的查询仅作示例，字段路径以操作审计实际投递格式为准：


event.userIdentity.accessKeyId: \"LTAI5t\\\\\"

拿到调用清单后，按“时间、事件、来源、证据”四列重建时间线：统一使用北京时间，以首次异常调用为锚点向前后各扩 7 天；把云日志、主机日志、CI 日志与人工记录（告警短信、工单、通话）合并到一条轴上；每个节点标注证据编号。时间线的价值在于把零散的告警变成可以被验证的叙事，而不是堆砌截图。

证据固化要与处置同步：日志导出到只读存储并记录哈希，受影响实例先打快照再清理，告警短信、工单与沟通记录一并归档。如果确认发生数据泄露，还要评估法规和合同下的通知义务，区分对内报告和对外报告的口径。

最后是复盘。用连续追问逼近机制而非个人：为什么历史命令里会有明文 AK、为什么跳板机允许弱口令、为什么一台公网服务器能潜伏一个月。案例 2 的结论是三层防御同时失效，而不是“某个人犯了错”。改进项拆成当天、30 天、90 天三类并指定负责人，纳入后续路线图滚动推进。

6.5 何时引入外部力量

出现数据被加密勒索、客户数据确认外泄、攻击者仍在活动，或内部缺乏取证能力时，应尽早引入云厂商应急响应服务、第三方取证机构和法律顾问，同步评估监管报告与客户通知义务。平时建议每半年演练一次：用一把测试 AK 走完本章流程，验证告警能否找到人、处置权限是否就绪、日志是否真的留存。

七、供应链侧：凭据是供应链攻击的“最终奖品”

7.1 为什么供应链盯上 AK/SK

传统供应链攻击的目标通常是代码和构建产物：偷源码、植入后门、污染交付物。云时代，凭据本身成了更直接的商品。代码需要分析、需要寻找落地场景，而一把 AK 可以直接调用 API，几小时内就能变现。供应链又恰好具备三个条件：集中（CI/CD 聚合密钥）、可信（工具和包默认被信任）、放大（一次投毒影响所有下游）。攻击者不需要 0day，只需要一个 install script、一个 workflow 文件，或者一个看起来专业的仿冒仓库。

7.2 三类上游投毒路径

第一类是工具投毒，代表是 accesskey\_tools。这款拥有 500 stars 的工具把后门藏进十六进制字符串、静默安装的依赖和 botocore 端点劫持里，7 个 AWS 脚本无一幸免。攻击者选择 AK 利用工具作为载体，因为使用者天然持有高权限凭据，且往往在“检查安全”的心理下降低警惕。这些手法并不高级，但足够有效。

第二类是依赖投毒，代表是 Shai-Hulud。它通过 preinstall 执行、npm token 滥用、GitHub 分支钩子、AI 工具触发和 OIDC 可信发布，形成自我复制和递归传播。它窃取的不只是云 AK，还包括 npm token、GitHub token、K8s/Vault 凭据和 AI 平台密钥，目标是把开发者的整个身份体系一网打尽。

第三类是构建链投毒，代表是 GhostAction。攻击者先取得 GitHub 账号或仓库写权限，再注入恶意 workflow，读取仓库 secrets 并外传。它的隐蔽性来自“正常功能”：工作流文件看起来像安全扫描，提交信息看起来像日常维护，运行记录还会被删除。

三类路径的共同点是：都在开发者或 CI 的信任域内执行，都绕过了传统的网络边界，都直接针对凭据而不是漏洞。

7.3 下游放大：一把 AK 能穿透几层

云厂商之下是企业云账号，企业云账号之下是业务系统、客户数据和租户。一个运维 AK 如果拥有跨资源组的权限，就可能从测试环境读到生产数据；一个 SaaS 厂商的 AK 如果泄露，可能影响多个租户；一个软件供应商的构建环境如果被投毒，交付物可能带着后门进入客户网络，同时供应商的云凭据也可能被窃，进一步读取客户数据。案例 4 和案例 5 的规模说明，供应链攻击已经不是“单点事件”，而是“批量事件”。

7.4 供应链治理清单

来源治理：只从官方源或内部可信制品库获取工具和依赖；校验签名、哈希；固定版本；禁止 curl | bash 这类“下载即执行”的安装方式。

依赖治理：使用锁文件、SBOM、SCA；对新增依赖做评审；设置版本成熟度门槛；关闭不必要的 install scripts；限制 CI token 的写权限和 2FA 绕过能力。

构建治理：使用隔离、临时的 Runner；用 OIDC 换取短期云凭证；给 GITHUB\_TOKEN 最小权限；第三方 Action 固定到完整 commit SHA；敏感环境设置人工审批；限制 Runner 出网；对 workflow 文件的变更强制审查；保留并集中存储 CI 审计日志。

运行治理：安全工具、枚举工具、第三方脚本在低权限账号和隔离网络中运行；生产凭据不进入开发机；CI 与生产账号分离；对工具的出网行为做监控。

监测与响应：监控云 API 异常调用、CI 日志中的 secret 引用、包发布记录、Runner 异常外联；一旦确认使用过受污染的工具或包，应把主机视为已失陷，轮换所有可能暴露的凭据，清理分支、历史和缓存，重建 Runner，而不是只删掉恶意文件。

合同与准入：对供应商提出安全要求，明确事件通知时限、审计权和数据删除义务；给供应商的 AK 单独开账号、单独授权、单独监控，不使用本企业的管理员凭据。

八、落地路线图：30/60/90 天

表 8　AK/SK 治理的 30/60/90 天路线图


阶段	重点动作	验收标准
0–30 天	盘点 AK 台账；删除主账号 AK；清理 90 天无调用 AK；上线高危 API 告警；开启 secret scanning；CI 日志脱敏	主账号 AK 为 0；台账覆盖率 100%；高危 API 有告警
31–60 天	用 STS/OIDC 替代长期 AK；收敛权限；接入 KMS/Secrets Manager；配置 IP 白名单与 MFA；完成首轮轮换	长期 AK 占比显著下降；高权限 AK 有审批；轮换可回滚
61–90 天	开展泄露演练；建立供应链准入与 SBOM；接入操作审计与数据面日志；完成红蓝对抗复盘	演练 MTTR 可量化；供应链清单可追溯；审计覆盖关键数据面