很多人第一次注册阿里云，目标很简单：开一台服务器，把网站跑起来。账号注册好，邮箱和手机号绑上，项目就上线了。直到账单突然变高，或者网站莫名变慢，才意识到这个账号其实掌握着整个云上资源。
主账号和子账号各管什么
阿里云的账号分两类。主账号权限最大，能开通服务、修改支付方式，也能删除资源。子账号在访问控制 RAM 里叫 RAM 用户，它从主账号派生出来，权限由你按需授予。
实际工作中，主账号最好只用在计费和授权这类少数事情上，开发和运维日常都用子账号登录。好处很直接：某个员工的密码泄露时，攻击者拿到的只是他那部分权限，而不是整个账号。
一个典型的翻车过程
下面是按常见情况整理的一个示例，用来说明问题通常怎么出现。一个五人的小程序团队，有位开发把项目推到了公开的代码仓库，代码里写死了一段 AccessKey。几天后，账单突然暴涨，几台从没人开过的 ECS 实例在后台挖矿，费用远超平时。
回头看，问题有三个：AccessKey 直接写在代码里；这把密钥属于主账号，权限很大；没有设置任何费用告警。补救其实不复杂：删除旧密钥，给需要的人分别创建子账号和新密钥，把密钥挪到环境变量或密钥管理服务里，最后加上预算告警。正常做下来，半天就够了。前提是团队知道该做什么，提前规划总比出事后补救省力。
日常要做好的五件事
- 给主账号开启多因素认证（MFA）。密码之外多一道验证。很多账号被盗，是因为别的网站泄露的密码被重复使用，MFA 能挡住大部分这类尝试。
- 子账号按最小权限授权。运维只给需要的产品权限。AdministratorAccess 用起来省事，但等于把整个账号交出去，除非确实是管理员，否则别直接授予。
- 定期轮换 AccessKey，不用的直接禁用。同一个子账号最多保留两把密钥。轮换时可以先新建，切换完成后再删除旧的，业务不会中断。
- 开启操作审计。通过操作审计（ActionTrail）记录谁、在什么时间、做了什么。出了问题，能顺着记录找到源头，而不是靠猜。
- 设置费用预算告警。账单超过阈值时发短信或邮件。异常消耗不一定能马上止住，但至少不会等到月底才看见账单。
AccessKey 应该放在哪里
AccessKey 是调用阿里云 API 的凭证，性质和密码一样。它不该出现在代码、配置文件的提交记录、聊天记录或截图里。本地开发可以放在环境变量，或者只保存在本机的配置文件中，并确认这个文件不会被提交到仓库。
线上服务更适合使用 ECS 实例角色或 STS 临时凭证。程序拿到的是有时效的凭证，本身不接触长期密钥，即使泄露，影响范围也小得多。
如果怀疑密钥已经泄露，第一件事是立刻在控制台禁用它，然后再慢慢排查。顺序反过来，攻击者可能在排查期间继续使用它。
十分钟自查
登录控制台后，先看三个地方。第一，主账号的安全设置里是否已经绑定 MFA。第二，RAM 用户列表里每个子账号是否还有人在用，权限是否超出了实际工作所需。第三，AccessKey 管理页面里创建超过半年的密钥，能删的先删。
账单页面也值得每周看一次。把费用按产品和资源组拆开看，异常增长通常集中在某一款产品上，比如突然多出来的带宽，或者一批不认识的 GPU 实例。发现异常后，先停掉相关资源，再查清楚是谁、为什么创建的。顺序不要反，否则可能误删正在使用的服务。
人员变动时别漏掉的东西
很多风险出在人员变动上。员工离职后，他创建的子账号、保存过的密钥，还有手机上的 MFA 设备，都需要一并处理。建议每个人使用独立的子账号，不要共用，否则出了问题无从追溯。离职当天，在 RAM 中停用他的账号，再检查他是否自建过 AccessKey。交接时，确认新负责人能拿到需要的权限即可，不要把旧账号的密码直接转过去。
