很多人第一次开通阿里云时，用的就是 root 账号。注册、充值、建实例、买域名，一路顺畅，很少有人想过换个身份来操作。但 root 账号持有云上资源的全部权限，一旦泄露，损失通常比一台服务器大得多。
root 账号的边界
阿里云的 root 账号也叫主账号，是注册时绑定的最高身份。它可以创建和释放任何资源，修改计费信息，管理所有子用户，甚至能发起账号注销。所以它更适合承担账单归属和最终兜底的角色，日常运维应该交给别的身份。
一个常见的失守过程
有个开发同学为了让本地脚本快速调用 OpenAPI，直接把 root 账号的 AccessKey 写进了代码，又把代码推到了公开仓库。几天后账单出现异常，控制台里多出十几台位于陌生地区的实例，全部在跑高负载任务。
复盘时问题并不复杂。AccessKey 的作用和密码差不多，而 root 的 AccessKey 没有任何权限限制。公开仓库里的密钥很快会被自动化工具扫到，攻击者几分钟内就能开通实例、写入资源、消耗余额。更麻烦的是，团队平时没有留意操作记录，连第一次异常登录发生在什么时间都很难还原。
这个例子说明，root 账号的问题不只是“有可能被盗”，而是一旦被拿到，中间没有任何缓冲。
把 root 账号收起来的五个步骤
第一步：给 root 账号开启多因素认证
在账号安全设置里绑定 MFA 设备，手机验证器或硬件令牌都可以。登录时多一道验证，密码泄露后攻击者也不能直接进入控制台。这一步几乎没有成本，建议当天就做。
第二步：删除 root 账号的 AccessKey
如果 root 账号下还留着 AccessKey，优先考虑删除。程序调用应该交给 RAM 用户。删除前先到操作审计里按 AccessKey ID 查一下最近的调用记录，确认没有正在运行的服务依赖它，避免删完之后业务突然断掉。
第三步：用 RAM 用户替代日常操作
阿里云访问控制（RAM）可以为每位成员单独创建子用户，并按需授权。比如开发只需要 ECS 的查看和重启权限，财务只需要账单读取权限。这样即使某个子账号泄露，影响范围也有限。
- 按职能建用户组，把权限授予用户组，而不是逐个人手动配置。成员调岗时只需要换组。
- 优先使用系统策略。系统策略不够用时，再写自定义策略，并且只放开实际需要的操作和资源。
- 每个季度查一次长期未登录的用户和长期未轮换的 AccessKey，离职人员当天清理。
第四步：程序访问改用临时凭证
应用需要访问云资源时，尽量使用 STS 临时凭证，而不是长期有效的 AccessKey。临时凭证有明确的过期时间，即使被截获，可利用的窗口也很短。如果应用运行在 ECS 上，可以给实例绑定 RAM 角色，让代码里不再保存任何密钥。这一步做完，代码仓库里就不容易再出现密钥。
第五步：开启操作审计并设置告警
在操作审计（ActionTrail）中开启记录，并对 root 账号登录、AccessKey 创建、高风险资源变更等事件配置告警。出现异常时，能第一时间收到通知，事后也能按时间线查清楚发生了什么。审计日志要定期检查，光开着没人看，作用也有限。
日常使用的小习惯
root 账号平时最好不登录。新资源、新用户、新策略都通过 RAM 完成。确实需要 root 权限的操作，比如修改账号基本信息或处理实名认证问题，可以先在团队里留个记录，操作完成后立即退出。
另外，建议每个季度做一次账号检查，主要看三件事：RAM 用户列表里有没有已经离职的人，MFA 绑定是否还在，操作审计里有没有不认识的登录或调用。检查本身不复杂，但能及时发现很多小问题。
小结
root 账号是整个云环境的根钥匙。平时把它收好，日常交给 RAM 用户，程序使用临时凭证，再加上 MFA 和审计告警，大多数常见风险就能挡住。安全不需要复杂的架构，关键是从第一天起养成正确的习惯。
