阿里云子账户怎么配RAM权限？新手常踩的三个坑

很多团队刚上阿里云的时候，习惯把主账号的AccessKey直接发给开发同事，或者几个人共用一个登录密码。前期确实省事，但用久了问题会一个个冒出来：改了配置没人说得清是谁改的，离职的人手里的凭证迟迟没收回，哪天凭证一泄露，整个云上资源都跟着裸露。子账户（控制台里叫RAM用户）就是为了解决这些事情设计的。

为什么一定要用子账户

主账号对账号下的所有东西都有权限，费用、资源、账单全在里面。如果日常运维都靠主账号完成，凭证一旦外泄，损失基本没有上限。子账户的思路很直接：每个人一个身份，只给他干活需要的权限。好处主要有三点。操作能追到具体的人。权限能收窄，开发不用看账单，财务也不用去改服务器配置。人员变动时，停用或删除一个子账户就够了，其他人不受影响。

一个分工的例子

拿一家做在线教育的中型公司来说。以前技术负责人老张一个人管着阿里云账号，团队七八个人共用同一套凭证。去年一位前端实习生离职，老张后来才发现对方手里还留着能访问对象存储的AccessKey。更麻烦的是，这段时间里存储桶的操作根本没有审计记录，想查也查不出来。

后来老张按职能重新拆了一遍。运维组负责ECS和负载均衡，给对应的管理权限。开发组只能碰测试环境，生产数据删不了。财务同学只开费用中心和账单查看。三类人各建一个用户组，权限绑在组上，新人入职只要加进对应的组就行。调整之后，权限维护轻松了很多，出了问题翻审计日志，也能直接看到是谁做的操作。

创建子账户的基本步骤

用主账号登录RAM访问控制控制台，进入“身份管理”下的用户页面。
点击创建用户，填写登录名称和显示名称。登录名最好和公司的工号或姓名拼音对得上，不然半年后没人记得“zhangsan01”是谁。
选择访问方式。需要登录控制台的人勾选控制台访问；需要调用API或命令行工具的程序，就创建编程访问用的AccessKey。两种可以同时开，但建议只开实际用到的那一种，少留一个口子。
设置初始密码，并勾选首次登录时修改。
把用户加入对应的用户组，或者直接附加权限策略。前者更好维护，后者适合个别特殊情况。

权限怎么给才算合理

阿里云的权限是通过策略（Policy）描述的，本质是一段JSON，写清楚允许或拒绝哪些操作、作用在哪些资源上。系统自带了不少预置策略，比如只读访问、ECS管理，常见场景基本够用。如果预置策略范围偏大，就在它的基础上自定义一条更细的策略，把资源和操作收窄。

给权限的时候，我的经验是先给最少的，真有需要再放开。别一上来就给管理员权限，理由是“以防万一”，这个“万一”往往就是事故的起点。遇到临时任务，比如外包团队要做一次数据迁移，更适合用RAM角色做临时授权。任务结束就收回，不用留着一个长期有效的账号。

安全设置的关键点

主账号和所有有控制台权限的子账户都开启多因素认证（MFA）。密码泄露时，MFA是最后一道挡板，开一下也不费事。
主账号的AccessKey尽量不用，能删的直接删。日常操作统一切到子账户上。
定期轮换AccessKey。轮换顺序是先创建新的，把应用配置切过去，确认没问题再禁用旧的，最后删除。直接删旧的，很容易让线上服务突然断掉。
AccessKey不要写进代码仓库。放到环境变量、密钥管理服务，或者CI平台的加密变量里更稳妥。仓库一旦公开，泄露几乎是必然的。
开启操作审计（ActionTrail），关键操作日志留足保存期限，出了问题才有据可查。
人员离职或岗位调整，第一时间停用子账户，并检查它名下还有哪些AccessKey。只改密码是不够的，AccessKey照样能用。

三个常见的坑

第一个坑是账号分了，权限没分。每人一个子账户，但都挂着管理员策略，形式上做了区分，安全上基本没有收益。第二个坑是图省事多人共用一个子账户。共用之后，审计记录就失去意义了，出了事根本分不清是谁干的。第三个坑是不用用户组，逐个用户单独授权。人少的时候还能应付，人一多，谁有什么权限就说不清了，维护成本会迅速涨上去。

还有一点容易被忽略：权限变更最好留痕。很多团队口头说一声就直接改权限，几个月后没人记得当初为什么放开某个操作。建议在工单或文档里写清楚每次授权的原因和期限，定期回头看一遍，该收的收回来。