多账号云环境的权限分层与审计配置，关键不是给每个账号堆更多规则，而是明确谁能在什么范围内做什么操作，并留下可追溯记录。无论采用 AWS 账号、Azure 订阅还是 Google Cloud 项目，建议先划清环境与职责边界，再设计角色和审计流程。
先按边界分层，不要直接按人员逐个授权
账号或项目通常用于隔离生产、测试、开发等环境；组织级策略负责设定整体底线，账号级权限再落实到团队和任务。这样既能避免测试人员误改生产资源，也便于在人员变动时统一调整授权。
角色访问控制（RBAC）适合职责较稳定、权限边界清楚的团队；临时、特殊任务则可通过按需授权处理。两者都应遵循最小权限：只开放完成工作所需的资源、操作和时段。不要把日常运维权限与账单、身份管理等高影响权限默认合并。
| 角色层级 | 典型职责 | 配置重点 |
|---|---|---|
| 组织管理员 | 管理账号结构和组织策略 | 人数尽量少，使用独立管理身份 |
| 平台运维 | 维护网络、监控和共享服务 | 限制可管理的账号或资源范围 |
| 项目维护者 | 部署和维护项目资源 | 避免授予组织级身份管理权限 |
| 只读审计者 | 查看配置、日志和变更记录 | 与执行变更的角色分离 |
把授权过程做成可检查的步骤
- 盘点身份和资源。列出员工、外包人员、服务身份及其负责的账号、项目和资源。优先通过企业身份提供方进行单点登录，避免共享个人账号。
- 建立角色模板。按职责设置只读、部署、运维和管理等角色，并限定资源范围。云平台提供的预置角色可作为起点，但要核对其实际权限，不要只凭名称判断。
- 设置认证和提权约束。对交互式登录启用多因素认证；高权限操作优先采用限时授权和审批。紧急访问身份应单独保管、限制使用，并在每次启用后复核。
- 验证拒绝场景。用测试身份分别确认允许和禁止的操作，例如项目维护者能否部署资源、是否会意外修改组织成员或关闭审计。检查结果应覆盖生产与非生产环境。
- 定期复核并回收权限。人员离职、转岗、项目结束时及时撤销授权；按团队风险设置复核周期，常见做法是每季度检查一次，高风险角色可更频繁。
审计日志要集中、完整且能调查
启用云平台的身份登录、策略变更、资源管理等控制面审计日志；若需要追查对象读取、数据库访问等行为，还要确认对应服务的数据面日志是否单独开启。AWS CloudTrail、Azure Activity Log 和 Google Cloud Audit Logs 是各自平台的原生审计能力，记录范围和配置方式并不完全相同，应按实际服务核对。
将日志汇集到权限较少的专用日志账号、订阅或项目，避免普通运维人员既能执行敏感操作又能删除证据。限制日志修改与删除权限，配置适合组织要求的保留期限，并监测日志投递中断、策略变更、异常提权和审计功能被关闭等事件。日志保留多久要结合调查需求、法规义务、存储成本和平台能力决定，不宜套用一个固定期限。
用审计记录还原一次变更
调查时按身份、时间、操作、目标资源和来源信息串联记录，并与工单或审批记录核对。审计日志能说明某身份在特定时间执行了什么操作，但未必能单独证明操作目的；因此高风险变更还应保留审批编号、变更说明和结果验证。多账号云环境的权限分层与审计配置只有同时覆盖授权前、执行中和事后复核，才能形成有效闭环。
常见问题
多个账号能否共用一个管理员身份？
不建议。个人身份便于追责；跨账号管理应通过受控角色或委派机制完成，并减少常驻高权限。
只开登录日志够不够？
不够。还需按调查目标启用权限变更、资源操作及必要的数据访问日志，并检查日志是否成功汇集。
小团队也要做权限分层吗？
要。可以从生产与非生产隔离、只读与变更角色分开、启用多因素认证和集中保存审计日志这几项基础措施开始。