团队用阿里云用久了，多半会碰到同一个麻烦：大家都拿主账号登录，权限没有边界，出了事也查不清是谁动的。阿里云子账号就是为这个场景设计的。它依托资源访问控制（RAM）体系，让主账号给每位成员、每个系统分配独立身份，再决定这个身份能碰什么。
为什么不能长期共用主账号
主账号对名下所有资源有完全控制权，费用、账单、安全设置都在里面。主账号的AccessKey一旦泄露，影响的是整个云账号。共用登录还有两个老问题：操作日志对不上具体的人；有人离职时，唯一的办法是改密码，而改了密码，其他人也得跟着换。
子账号能把这些风险拆开。每个人用自己的身份登录，权限按工作需要给，人走了禁用对应子账号就行，别人不受影响。
先搞清楚三个概念
后面的操作会顺很多，先记住下面三样东西：
- RAM用户：也就是平时说的子账号。可以用控制台密码登录，也可以持有AccessKey给程序调用。
- 用户组：把一批RAM用户归在一起统一授权，比如开发组、运维组、财务组。
- 权限策略：用JSON描述“对哪些资源允许或拒绝哪些操作”。系统策略够用就直接挂，不够再自定义。
授权时，尽量把策略挂到用户组上，再把人加进组。之后有人调岗，改一下组关系就够了，不用逐个人去改权限。
一个电商团队的拆分过程
某中型电商团队有二十来名技术人员，最开始全员用主账号。后来他们按岗位梳理，分成三个组：
- 开发组：要看ECS实例和日志，但不能删除或释放服务器。
- 运维组：管理ECS、负载均衡和云监控，可以重启实例，不碰计费。
- 财务组：只看账单和消费明细，不接触任何云资源。
开发组绑定的是一条只读策略，大致如下：
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:Describe*",
"log:Get*",
"log:List*"
],
"Resource": "*"
}
]
}策略只放行Describe、Get、List开头的查询操作，开发人员排查问题没问题，误删服务器的可能就没了。一个月后审计时，团队发现一位新人误操作的请求被拒绝了，日志里还清楚记着是哪个子账号发起的。他们觉得这套做法是值得的。
创建子账号的基本步骤
- 用主账号登录RAM控制台，进入“身份管理”下的“用户”页面。
- 点击创建用户，填写登录名称和显示名称，按需勾选控制台访问或编程访问。
- 设置初始密码，并要求首次登录时修改。
- 把用户加入对应的用户组，完成授权。
- 提醒成员开启多因素认证（MFA），运维或高权限账号尤其要开。
控制台的菜单名称会随版本调整，操作前以官方文档和当前页面为准。
几条值得坚持的做法
- 主账号少用：日常工作全部走子账号，主账号开启MFA后收好。
- 先给最小权限：一开始别直接给管理员策略，确实不够用了再逐步放开。
- AccessKey定期换：程序用的AccessKey设好更换周期，闲置的及时禁用或删除。
- 临时任务用RAM角色：通过STS拿临时凭证，跨账号访问或一次性任务比长期持有AccessKey稳妥。
- 定期看审计：用操作审计（ActionTrail）查关键操作记录，异常早发现。
小结
子账号本身的概念不复杂，难的是权限怎么规划。建议先按岗位分组，给每组配最小权限策略，再用审计记录验证效果。这件事做一次，之后的人员变动和合规检查都会轻松不少。
