管理员要管的东西不少，账号、权限、密钥、费用、日志，哪一块出问题都可能很快变成麻烦。资源被误删、账单突然变高、密钥被别人拿去用，这些事多半是某个配置当时图省事留下的口子。下面按实际操作的先后顺序，说说管理员最该先处理的五件事。
先别用主账号干活
阿里云主账号对所有资源都有完整的操作权限。如果日常运维也直接用它登录，密码或访问凭证一旦外泄，对方拿到的就是整个账号。更稳妥的做法是把主账号收起来，只在处理账单、实名信息这类少数事项时使用，其余工作交给 RAM（访问控制）子账号。
第一步：按职责给 RAM 子账号分权限
在 RAM 控制台建子账号时，先想清楚这个人要做什么，再决定给什么权限。开发同学通常只需要 ECS 和 OSS 的读写，财务同学看费用中心就够了。策略能用系统预设的就先用预设的，实在不合适再按最小范围自定义。AdministratorAccess 这种全局权限，除非确实有必要，否则不要随手授予。
子账号建好也不是一劳永逸。人员调岗后，原来的权限要及时收回；项目结束，相关子账号也要停用。权限给得越多，出了问题就越难说清是谁的责任。
案例：某电商团队原来让 5 名运维人员共用一个拥有全部权限的账号。一名实习生误删了测试环境的数据库实例，恢复花了两天。后来改成每人一个子账号，只授予各自需要的权限，同类误操作在之后三个月里没有再出现。
第二步：管好 AccessKey 的数量和寿命
AccessKey 是程序调用阿里云 API 时使用的凭证，泄露风险最高，也最容易被忽视。具体可以这样做：
- 不为主账号创建 AccessKey，只为子账号创建。
- 每个子账号最多保留两个 AccessKey。切换时先启用新的，等业务跑稳了再处理旧的，这样换钥匙时不会把服务断掉。
- 每 90 天轮换一次。旧密钥先禁用观察一段时间，确认没有任何程序还在用，再删除。
代码里不要写明文密钥，也不要放进会提交到仓库的配置文件。应用更适合从环境变量或 Secrets Manager 读取凭证，密钥变更时只改一处，维护起来也省心。
第三步：给登录加上多因素认证
在安全中心，为主账号和所有有控制台权限的子账号绑定 MFA 设备。密码只能挡住一部分人，撞库得来的密码如果没有第二道验证，风险基本就敞开了。
RAM 里还可以设置登录策略，比如密码最短长度、定期更换周期，以及连续失败多少次后锁定。设置完成后，建议用一个测试子账号完整登录一次，确认验证流程正常。这一步看着多余，但真到紧急时刻发现验证环节出了问题，人就被挡在系统外面了。
第四步：用操作审计盯住关键变更
操作审计（ActionTrail）会记录账号在控制台和 API 上做过的操作。日志要投递到单独的 OSS Bucket，并设好保留期限，别和业务数据混在一起，也别让它随着 Bucket 的清理一起消失。
日常检查不必逐条翻看，盯住几类高风险事件就够了：删除实例、修改安全组、创建 AccessKey、修改 RAM 策略。最好每周抽一次时间过一遍这些事件，发现异常比出事后再回头翻记录快得多。
案例：某公司发现一台 ECS 的安全组突然开放了 0.0.0.0/0 的 22 端口。通过操作审计，团队十分钟内就查到是哪个子账号、从哪个 IP 地址做的修改。确认是某员工的账号遭到撞库后，团队立即禁用该账号，撤销异常的 AccessKey，并恢复了安全组规则。如果没有审计记录，这类问题很难定位。
第五步：设预算，让花费变化及时被看见
在费用中心创建月度预算，阈值设为 50%、80%、100%，告警同时发给管理员和财务负责人。预算金额可以参考历史账单来定，比凭感觉拍一个数字靠谱。这样即使没人天天盯账单，花费超线时也会有人知道。
按量付费的资源还要定期清理。压测用的实例、没挂载的云盘、早就用不到的快照，最容易在不知不觉中一直计费。
案例：某团队压测结束后忘了释放一组按量付费的 GPU 实例，一周内多出了数千元费用。后来设了预算告警，80% 的通知在第三天就触发了，团队及时释放了资源。
常见误区
- 觉得子账号权限给宽一点省事，结果出了问题，谁的操作都说不清。
- 把 AccessKey 提交到代码仓库，被公开爬取后产生了挖矿费用。
- 日志开了却从不看，出事后才发现日志缺失，或者根本没有保存。
- 离职员工的子账号没有及时禁用，访问凭证依然可用。
人员会调动，项目也会上下线，所以这五项最好定期过一遍。把权限、密钥、日志和费用都放在看得见、查得到的状态下，大部分常见风险都能控制住。
