用最小权限管好云上 AK/SK：从创建、使用到轮换的工程实践

为什么 AK/SK 治理不能只靠“不要泄露”

Access Key ID 与 Secret Access Key 常用于命令行工具、CI/CD、自动化脚本和第三方系统访问云 API。它们没有交互式登录过程，只要请求签名正确，就会被平台视为对应身份发起的操作。因此，风险并不只来自把密钥提交到公开仓库：聊天记录、构建日志、镜像层、备份文件、共享目录和离职员工的旧设备，都可能留下可用副本。

更稳妥的思路是承认密钥可能在某个环节暴露，并通过权限范围、有效时间、存储方式、审计能力和快速撤销机制，把一次泄露能够造成的影响限制在最小范围内。

一、把人员身份与程序身份分开

不要让自动化任务长期使用管理员或个人账号的 AK/SK。应为不同应用、环境和流水线建立独立身份，例如生产发布、测试部署、日志分析分别使用不同 IAM 用户或委托。这样做有三个直接收益：权限可以单独收敛，审计记录可以明确归属，某个密钥需要停用时不会让所有系统同时中断。

命名也应能够表达用途，例如 ci-prod-deploy、ops-readonly-audit。身份说明中记录负责人、使用系统、允许区域和预计下线时间，后续盘点时就不必依赖口头确认。

二、从真实 API 调用反推最小权限

最小权限不是简单地选择一个“只读”角色。自动化流程往往需要多个服务的少量动作：读取制品、更新某个部署任务、查询实例状态，却不需要创建网络、删除资源或管理 IAM。

落地时可先在测试环境记录流程实际调用的 API，再按服务、资源和动作组合自定义策略。对于支持资源级授权的服务，应把范围限制到指定项目、仓库、桶或实例；无法资源级限定的动作，则通过独立账号、独立项目和流程审批补充隔离。

权限调整后要执行正向和反向验证：确认正常流程能够完成，同时验证删除、授权、创建公网资源等越权动作确实被拒绝。只验证“能运行”而不验证“不能越权”，仍然无法证明最小权限已经生效。

三、密钥只进入专用秘密存储

AK/SK 不应写入源码、配置模板、Dockerfile、镜像环境变量默认值或 Wiki。开发机可使用系统钥匙串或受控凭据文件，并限制文件权限；流水线应使用平台的加密变量或云秘密管理服务，在任务运行时短暂注入。

还要注意日志泄露。调试代码不要打印完整请求头、签名参数和环境变量。错误上报与流水线归档前应执行脱敏，只保留 Access Key ID 的少量前后缀用于定位，Secret Access Key 永远不输出。即便日志平台本身有访问控制，也不应把它当作密码库。

四、优先采用临时凭证并建立轮换窗口

能够使用委托或临时安全凭证的场景，应优先避免长期 AK/SK。临时凭证自带到期时间，泄露后的可利用窗口更短，也更适合容器、弹性任务和跨服务调用。

确实需要长期密钥时，应建立可回滚的双密钥轮换流程：先创建新密钥，将使用方切换并验证；观察一段时间确认没有旧密钥调用，再停用旧密钥；最后删除并记录变更。不要先删除旧密钥再修改所有系统，否则任何遗漏都会直接造成业务中断。

轮换周期应由风险决定，而不是机械地设定同一个天数。生产写权限、跨账号访问和外部系统使用的密钥应更短；长期未使用的密钥应直接停用，而不是等待下一个轮换日。

五、用审计回答“谁在什么地方做了什么”

为密钥对应的 API 调用保留云审计记录，并关注异常来源、异常时间和高风险动作。常见告警包括：从未见过的地区或网络发起调用、短时间大量鉴权失败、突然访问新服务、创建新密钥、修改权限以及关闭审计能力。

审计信息需要与身份台账关联。看到一个 Access Key ID 时，值班人员应能快速找到所属应用、负责人、允许动作和处置联系人。只有日志而没有责任映射，紧急情况下仍会浪费大量时间。

六、预先写好泄露处置剧本

发现密钥出现在公开仓库、聊天截图或日志中时，不要只删除泄露内容。正确顺序通常是立即停用或删除密钥，检查相关身份近期操作，撤销异常创建的资源或权限，生成新凭证并更新合法使用方，最后分析泄露路径并补充扫描规则。

对于可能影响生产的密钥，可以先停用并观察告警与业务指标，但不能为了“避免中断”而长期保持可用。处置过程中应保存审计证据，并确认攻击者没有创建新的持久化入口，例如额外访问密钥、委托、策略或公网入口。

一份可执行的检查清单

团队可以每月执行一次轻量盘点：列出所有 AK/SK 及最后使用时间；确认每个身份都有负责人和业务用途；检查是否存在管理员级密钥；验证密钥未出现在代码和日志；复核轮换日期；抽查高风险 API 的审计与告警；停用无负责人、无调用或已下线系统的凭证。

结语

AK/SK 安全不是一次性的配置工作，而是一条覆盖创建、授权、存储、使用、轮换、审计和撤销的生命周期。真正有效的治理并不要求所有系统立即重构，而是从身份拆分和最小权限开始，让每把密钥都有明确用途、有限能力、可见调用和可控寿命。这样即使某个环节发生泄露，也能把影响限制在可发现、可撤销和可恢复的范围内。