很多人第一次用云服务，都是从买一台阿里云服务器开始的。机器能跑起来当然要紧，但账号往往是最后才想起来管的东西。账号理得清，团队协作不乱，费用也好盯。账号随手设、随手共用，一个泄露的密码就可能让整台服务器落到别人手里。
主账号和子账号，先分清谁是谁
阿里云的账号分两类：主账号和子账号（RAM用户）。主账号拥有全部权限，包括费用、合同和所有资源，相当于整个云环境的根。子账号由主账号创建，按需授权，供团队成员日常使用。
实际操作中，主账号的登录凭证最好只在需要时才用，比如开通新服务、处理账单、修改关键配置。平时的运维、开发和监控查看，交给子账号去做。每个人只拿到完成手头工作所需的权限，这就是常说的最小权限原则。听起来抽象，落到实处其实就是少给一条没必要的权限。
案例：五人小团队的权限拆分
杭州一家做电商数据分析的小团队，最初只有一个阿里云服务器账号，五个人共用同一组登录信息。开发小王离职时，大家才发现他手里仍然掌握着生产服务器的访问凭证，而团队没办法单独把他的权限收回来。
之后他们改了做法。主账号只交给负责人保管，并开启多因素认证；每位成员各建一个子账号。开发人员只能管理测试环境的ECS实例，运维人员可以查看监控但不能删除数据库，财务只保留账单查看权限。半年后再有人员变动，账号回收一次就完成了，业务没有受影响。
RAM权限策略怎么写
权限主要通过RAM（资源访问管理）的权限策略来控制。策略用JSON描述，写清楚允许或拒绝哪些操作，作用在哪些资源上。比如只允许某个子账号查看某个地域的ECS实例，同时禁止停止或释放实例，用精确的Action和Resource限定就能写出来。
刚上手时，可以先从系统预置的策略开始，它们覆盖了常见角色，比从空白写起省事。用起来以后，再按实际需要收窄。策略不必一次写到完美，但每次新增授权都值得多问一句：这个人真的用得上这项权限吗？权限往往只增不减，人员调岗或项目结束后，记得回头清理用不到的授权。
安全设置：几个必做的基础动作
- 开启多因素认证（MFA）：主账号和所有子账号都开。登录时多一道验证，能挡住大部分撞库和密码外泄带来的风险。
- 密码不复用：云账号的密码不要和其他网站或邮箱共用，并定期更换。
- AccessKey 不进代码仓库，也不进聊天群：它是程序访问云资源的钥匙。写进代码或发到群里，等于交给了所有能看到它的人。
- 用不到的AccessKey及时禁用或删除：长期使用的密钥，给它定一个轮换周期，到期就换。
- 打开操作审计（ActionTrail）：出了异常，能查到是哪个账号在什么时间做了什么，排查会快很多。
案例：一次AccessKey泄露的教训
一位独立开发者曾把带有AccessKey的配置文件误传到公开的代码仓库。两个小时内，账号下的服务器就被陌生IP登录，并创建了多台计算实例用于挖矿。账单几天后才被发现，金额远超预期。
事后他总结了三点。第一，发现泄露后先禁用对应的AccessKey，再排查影响范围，顺序不能反。第二，凭证改用环境变量或密钥管理服务存放，不再硬编码在文件里。第三，给账号设置费用预警，超出阈值时第一时间收到通知。他说，这次之后才真正意识到，安全和费用是同一件事的两面。账号被盗，最后往往是账单先出问题。
账单与费用管理
账号管理也包括费用。建议在费用中心设置预算告警，并定期查看按资源分组的消费明细，发现异常增长要马上查原因。测试用的ECS实例用完就释放，闲置的机器会在不知不觉中持续计费。如果几个子账号共用一个主账号付费，可以用成本分配标签区分项目或成员，月底对账时就不用猜钱花在哪里了。
写在最后
阿里云服务器账号看上去只是一个登录入口，背后连着权限、安全和成本。从一开始把主子账号分清、权限收紧、安全措施落实，比出了事再补救轻松得多。即使只是一台个人服务器，也值得花半小时把这套基础框架搭起来。
