云上凭证安全：临时访问凭据（STS）与最小权限原则实践指南

一句话结论：把长期 AK/SK 换成"按需申请、短期有效、权限最小"的临时凭据，是云上应用安全收益最高、改动最小的一步。

一、为什么长期 AK/SK 是最大的隐患

很多团队会图方便，在代码、配置文件、CI 变量甚至镜像里写死一对 Access Key（AK）和 Secret Key（SK）。这种做法的问题不在于"能不能用"，而在于它把一枚永久有效的"万能钥匙"散落在了很多地方：

• 永久有效：长期密钥通常没有过期时间，一旦泄露，攻击者可以长期使用，直到你主动发现并轮换。
• 容易外泄：随代码进 Git 历史、被打进日志、写进 Docker 镜像、传到聊天工具——每多一个副本，就多一个泄露面。
• 权限往往过大：为了方便，很多长期密钥被授予了接近管理员的全量权限，一个泄露点就等于全盘失守。
• 轮换成本高：因为牵连面广，现实中"说好每 90 天轮换一次"往往最后变成永不轮换。

一句话：长期密钥把"身份"和"权限"这两件本该分离的事揉成了一团，且没有时间边界。

二、什么是临时访问凭据（STS）

STS 是 Security Token Service 的缩写，即安全令牌服务。它签发的不是一对永久密钥，而是一组短期凭据：临时 Access Key、临时 Secret Key，以及一个 Security Token。三者必须一起使用，缺一不可。

它和长期密钥的核心区别：

• 有明确有效期：通常从几分钟到数小时，到期自动失效，天然带"时间边界"。
• 绑定权限范围：申请时就要声明"我要扮演哪个角色、需要哪些权限"，从源头限制了能力上限。
• 可审计：由可信签发方颁发，谁在什么时候换了什么权限的凭据，都留有记录。

三、临时凭据的典型生命周期

1. 应用或使用者先持有一个"长期身份"，或通过联合身份（企业 IdP、单点登录）完成认证。
2. 向 STS 发起"扮演角色（AssumeRole）"的请求，声明所需角色、权限范围与会话时长。
3. STS 校验通过后，返回一组临时凭据（临时 AK / SK / Token）。
4. 应用用这组临时凭据调用云服务 API。
5. 临近过期时续期或重新申请；一旦过期，凭据立即失效。

关键设计思想：长期身份只用来"换取临时凭据"，绝不直接用来调用业务 API。这样即便业务侧运行时被攻破，泄露的也只是一段很快过期的临时凭据。

四、最小权限原则如何落地

临时凭据只是"限时"，权限还得"限量"。最小权限原则（Principle of Least Privilege）建议：

• 按角色授权，而不是按人或按长期密钥授权；一个角色对应一类职责。
• 只给必要的操作和资源：明确列出允许的 action 清单和 resource 范围，宁可细碎，不要一把梭。
• 用条件收紧：可结合来源 IP、VPC、时间窗、是否经过 MFA 等条件，进一步限制"谁、在哪、何时"能用。
• 职责分离：读角色、写角色、管理角色分开，避免一个角色既能改数据又能改权限。
• 定期审计清理：用访问分析找出长期未使用的权限并回收。

五、常见误区

• 误区一：用了临时凭据就一定安全。 如果角色权限过大、会话时长过长，风险依旧很大。临时凭据解决的是"时间边界"，不是"权限边界"。
• 误区二：临时凭据可以随便写日志。 Token 同样是敏感信息，泄露后在其有效期内一样能被滥用。
• 误区三：只有生产要管，测试和 CI 用长期密钥无所谓。 恰恰相反，CI/CD 环境往往凭据暴露面更大，是最该改造的环节。
• 误区四：会话时长越长越省事。 越长意味着泄露窗口越大，应按业务实际需要设置。

六、落地自查清单

• [ ] 代码库、镜像、日志中不存在长期 AK/SK
• [ ] 业务侧对云服务的调用全部走临时凭据
• [ ] 每个角色权限最小化，并配有条件约束
• [ ] 临时凭据有效期按业务合理设置（如 15 分钟至 1 小时）
• [ ] 有凭据泄露时的应急轮换预案
• [ ] 开启操作审计，异常调用可追溯、可告警

小结

云上凭证安全没有银弹，但方向很明确：用短期凭据替代长期密钥，用最小权限替代大而全的授权。 这两步改动通常不大，却能显著缩小攻击面。把"身份认证"和"权限授予"拆开、把"时间边界"和"权限边界"同时收紧，是从第一行代码就该建立的肌肉记忆。

（说明：本文为概念与实践方法梳理，示例要点为通用做法，落地时请结合你所使用云平台的具体 API 与策略语法调整。）