团队里几个人共用一个主账号，出了问题常常查不到是谁做的。主账号密码和AccessKey在多人手里来回传，谁改了哪台机器的配置，没人说得清。阿里云的子用户（也就是RAM用户）就是为这个场景设计的。下面结合一个十人电商团队的实际调整，说明子用户怎么建、权限怎么给、日常怎么管。
一、为什么不能所有人共用主账号
主账号对全部资源有完全控制权，费用、账单和账号安全设置都在它手里。如果每个人都直接用主账号，问题通常会按这个顺序出现：
- 责任说不清：误删一台ECS，无法确定是谁操作的。
- 权限过大：实习生和资深运维拥有同样的删除权限，手一滑就可能出事。
- 离职牵连广：有人离开，密码和密钥都要整体更换，还在用的人都得跟着改。
子用户的做法是给每个人、每个程序一个独立身份，只授予完成工作所需的权限。主账号则退到后面，只负责账号管理，日常操作不再使用。
二、案例：十人电商团队怎么分角色
这家小型电商团队有十人，分为运营、开发、运维和财务四个角色。调整前大家共用一个主账号，财务人员在控制台里就能修改ECS规格，这没有任何必要。调整后的划分如下：
- 财务组：只给账单查询和费用明细导出权限，不能访问任何云资源。
- 开发组：测试环境的ECS、RDS可读写，生产环境只给只读权限。
- 运维组：拥有生产环境管理权限，删除类操作要求配合MFA验证。
- 运营组：只能查看OSS中的图片，无法修改存储配置。
落地顺序是先在RAM控制台创建用户组，再把子用户加入对应的组。权限绑定在组上，新人入职只需加入组，不用逐个配置。人员一多，这个差别会越来越明显。
三、三步配好子用户
第一步：创建用户，分开设置两种访问方式
在RAM控制台新建用户时，可以同时勾选两种访问方式：
- 控制台访问：设置登录密码，给需要进入控制台操作的人。
- OpenAPI访问：创建AccessKey，给脚本、程序或自动化工具使用。
建议两种方式分开给。同一个人既有密码又有密钥，一旦其中一个泄露，另一个也会跟着失控。给每个控制台用户开启MFA，账号被盗后的损失也会小很多。
第二步：用策略控制授权范围
权限由策略（Policy）定义。阿里云提供了大量系统策略，比如只读类策略，可以直接绑定到用户组。系统策略覆盖不了需求时，再编写自定义策略。一条自定义策略主要由四部分组成：效力（Allow或Deny）、操作（Action，例如ecs:DescribeInstances）、资源（Resource，可以精确到某台实例，或某个前缀的OSS路径）、条件（Condition，例如限定来源IP段）。写之前先想清楚这四项分别填什么，比先写一堆通配符再回头收紧更稳妥。
以财务组为例，只挂费用相关的操作，不附加任何资源管理权限。这样即使密码泄露，攻击者也改不了资源，影响范围被限制在费用查看这一层。
第三步：把日常管理固定下来
配置完成不等于结束。团队定了几条规矩，照做即可：
- 每季度检查一次用户组成员和权限，收回已经用不到的授权。
- 员工离职当天，先禁用控制台登录和AccessKey，确认没有异常后再删除用户。先禁用、后删除，万一有遗漏的服务还在使用，还能回退。
- 定期轮换AccessKey。每个用户最多可以创建两个AccessKey，所以顺序是先创建新密钥，替换应用中的配置，确认业务正常后再禁用旧密钥。顺序反过来，业务很容易中断。
- 开启操作审计（ActionTrail），子用户的操作记录都可以追溯。
四、几个常见误区
第一，只是给每个人发一个账号，就以为完事了，权限范围没人管。第二，把AccessKey直接写进代码仓库，这是泄露的高发场景，应改用环境变量或凭据管理工具保存。第三，图省事给子用户绑定AdministratorAccess，等于又回到了共用主账号的老问题，只是换了个名字。
案例团队改造后的第一个月，就通过审计日志发现了一把长期未使用的测试密钥。及时禁用后，这个潜在风险就被堵住了。权限梳理不是一次性任务，定期翻一翻审计日志，常能发现当初没有想到的问题。
五、小结
先按角色划分用户组，再用策略把权限压到最小，最后靠定期轮换和审计维持安全状态。人数不多的团队，投入不大，却能明显减少误操作。
