直接回答：最小权限的落地方程式：用角色承载权限（人通过 SSO/联邦扮演角色，服务通过实例角色/workload identity 获取凭证），权限策略只允许具体动作加具体资源 ARN，杜绝 Action: * 和 Resource: * 的组合；长期 Access Key 原则上清零，必须存在的纳入轮换。常见失控场景：开发期图省事给 AdminAccess 一路带到生产、一个角色被几十种服务混用、离职/转岗未回收、Access Key 提交进 git 被扫走。

展开解析：工程化手段：权限边界（permission boundary）给团队自治设上限——你可以授权但永远越不过边界；SCP（组织级策略）在账号层面禁用高危动作（关日志、改账单）；用云商的 access analyzer 类工具基于实际访问日志收敛权限——"90 天没用过的权限删掉"是最有效的瘦身；敏感动作（删除、导出）强制 MFA 或审批流的即时提权（JIT）而非常驻授权。审计面：CloudTrail 类日志必须集中收集且防篡改（独立审计账号、对象锁）。文化上把 IAM 策略纳入代码评审，与基础设施同仓库管理——权限变更也是变更，走同样的 pipeline。

追问方向：role chaining 为何被多数云商限制？instance profile 与 access key 的安全性差异？如何发现僵尸权限？

（约 440 字）