很多人买完阿里云，注册时用的邮箱和密码就成了之后的登录方式，一用就是好几年。图省事没什么大问题，直到账号出了状况，才发现它比想象中关键。下面这些规矩，是团队在一次事故之后慢慢定下来的。
root 账号是什么，为什么要小心
注册阿里云时创建的主账号，通常就叫 root 账号。它对名下所有资源都有完全权限，计费、ECS 实例、数据库、域名都能管，删除资源也在其中。把它比作一把万能钥匙，大致没错。问题在于钥匙一旦丢了，事后很难补救。
一次事故的复盘
某个小团队的项目里，一位开发者为了本地调试方便，把带有 AccessKey 的配置文件推到了公开的代码仓库。这个 AccessKey 绑定的是主账号。不到两个小时，就有人用它在多个地域开了高配 ECS 挖矿。团队发现时，账单已经多出一大截。
回头看，问题不只出在某个人身上。主账号密钥直接放在开发环境里，没有子账号做隔离，也没有费用告警。少了这几层缓冲，一次普通的疏忽就变成了真金白银的损失。事后团队把账号体系重新梳理了一遍。
日常为什么不该用 root
主要有三个问题：
- 权限过大：日常运维只需要管某一类资源，却握着全部权限。一次误删，影响的可能是整个账号。
- 难以审计：多人共用主账号时，操作日志里只有同一个身份。出了问题，很难看清是谁在什么时候做了什么。
- 泄露面广：密码或密钥一旦外泄，攻击者拿到的是整个账号的控制权，而不是某个应用的一部分。
用 RAM 子用户加最小权限
阿里云的 RAM 访问控制，可以为每个人、每个应用创建独立的子用户，再用权限策略限定它能碰的资源。比如开发人员只管理测试环境的 ECS，运维可以看监控但不能删数据库，财务只看账单。权限范围越窄，误操作和泄露的影响就越小。
子用户的权限建议从最小开始，缺什么再补。一开始全部放开，之后再一点点收回来，通常更麻烦。
团队后来的做法大致如下：
- 主账号只用于账单管理和必要的账号设置，日常不登录。
- 为每位成员创建独立子用户，并开启多因素认证。
- 应用程序改用专门的 RAM 角色或子用户密钥，不再直接使用主账号 AccessKey。
- 为费用设置预算告警，出现异常消费时第一时间通知到人。
迁移和日常维护的几个注意点
如果主账号的 AccessKey 还在用，先别急着删。把服务迁移到子用户，在测试环境跑通，确认线上一切正常，再停用旧密钥。顺序反了，很容易造成服务中断。
密钥要定期轮换，存放在密钥管理服务或环境变量里，不要写进代码、配置文件或文档。提交代码前检查一遍，同时确认 .gitignore 已经排除了本地配置文件。
操作审计要打开，重点关注异常登录和不常见地域的资源创建。这类信号通常比账单更早出现，发现得越早，止损越容易。
root 账号本身没有问题，它是阿里云为账号所有者准备的最高权限入口，该留着，但不该天天用。拆分权限、收好密钥、盯紧费用，这些事加起来花不了多少时间。如果还没理过自己的账号体系，从检查 AccessKey 开始就行。
