权限：人员和程序要有不同身份最小权限不是把所有策略都改成只读，也不是为每次访问增加审批。它要求每个身份仅拥有完成明确任务所需的操作、资源和时段，并且能追溯授权责任。人员登录控制台和应用工作负载访问云服务，是两种不同的风险：前者关联岗位与临时运维，后者关联服务代码、运行环境和凭据生命周期。混用身份会让审计记录失去区分能力，也让一个泄露凭据可能同时影响开发和生产。
先建立身份清单，至少记录身份所有者、组织、用途、认证方式、权限来源和复核日期。人员尽量通过组织身份或联合登录进入云平台，日常身份不持有长期访问密钥。按实际任务设计角色：开发人员可在开发环境部署并查看服务日志，值班人员可读取生产观测数据，变更网络、安全策略或身份目录则由更窄的管理角色承担。管理权限应单独授予，使用时说明工单或事件编号，并设置有效期。
角色名称不能代替权限审查。要展开角色实际包含的动作，检查是否有创建新身份、传递角色、修改审计、读取密钥或删除资源等高影响能力。常见陷阱是把“只读”当成绝对安全：读取快照、配置或日志也可能暴露敏感信息。权限边界应同时体现环境和数据敏感等级。
每个服务、自动化任务或部署流水线都应有可识别的工作负载身份，不要复用员工账号，也不要让多个应用共享一个宽泛角色。把权限约束到具体资源，例如某个队列、存储前缀或数据库代理，并为不同环境配置不同身份。若平台支持临时凭据或工作负载身份绑定，优先采用这类方式，避免在镜像、启动脚本和仓库中存放长期密钥。
用调用审计和策略模拟识别真实使用的操作。分析窗口要覆盖完整业务周期，包含月末结算、备份恢复和故障演练；仅凭过去几天没有调用就删权限，容易造成低频任务中断。对确实不用的权限，先在预发布环境移除，再验证正常任务、重试和恢复流程。
排查授权失败时，结合AccessDenied、主体标识、目标资源、操作名称和时间戳定位。不要看到拒绝就直接授予通配权限；先确认请求来自预期服务、资源名称正确、条件策略与环境标签相符。对权限使用情况，也要区分“没有发生调用”和“审计未覆盖该区域或服务”。
验收至少包含三类结果：正常业务操作成功；对未授权资源或管理动作的负向请求被拒绝；离岗、角色停用或工作负载退役后，访问确实失效。检查审计记录能否回答谁在何时对哪个资源执行了什么操作，并确认告警会覆盖新建高权限身份、策略扩大和审计配置变更。紧急身份要独立保护、触发告警并定期演练，避免成为团队日常通道。
最终以负责人复核、权限边界测试和撤权验证形成证据。最小权限是持续维护的过程：岗位改变、应用新增资源、业务周期变化时，都应重新评估授权，而不是把第一次配置当成永久答案。✅
