不少团队用阿里云，习惯直接拿主账号的 AccessKey 或登录密码来操作。图方便是真的，但主账号拥有全部权限，一旦泄露，整个云上资源都可能受影响。阿里云子账号的正式名称是 RAM 用户（资源访问管理用户）。它挂在主账号下面，却有自己的登录方式、访问权限和安全策略，团队协作基本靠它来拆分身份。
子账号解决什么问题
用子账号，主要有三点直接的好处：
- 权限最小化：每人只拿到手头工作需要的权限。人少时可能觉得没必要，但误操作和越权，往往就出在“顺手多给一点”上。
- 操作可追溯：通过操作审计（ActionTrail）能看到哪个子账号在什么时间做了什么。共用账号时，出了问题只能全员排查。
- 人员变动好处理：员工离职或换岗，禁用或调整对应子账号即可，不必为了一个人去动主账号，其他人的工作也不受影响。
创建子账号的基本步骤
下面是常见的操作顺序。控制台界面会随版本调整，以阿里云控制台当前页面为准。
- 进入 RAM 访问控制控制台，在“身份管理”下创建用户。
- 先想清楚这个账号做什么，再选登录方式。需要登录控制台的人开通控制台访问；只做程序调用的账号开通 OpenAPI 访问即可，没必要给它登录能力。
- 凡是能登录控制台的账号，都要开启多因素认证（MFA）。密码被盗之后，它是最后一道屏障。
- 按职能建用户组，比如开发组、运维组、财务组，把用户加进去，再统一授予权限策略。逐人单独配权限，人一多很快就乱。
- 需要程序调用时，为子账号创建 AccessKey，存放在专门的密钥管理位置，不要写进代码仓库。
案例一：电商团队的权限拆分
某中型电商公司有 12 名技术人员，最初全员共用一个主账号。一次测试脚本误删了预发布环境的数据库，排查时无法确定是谁操作的，问题拖了两天才定位。
技术负责人小陈随后做了一次权限重构。他把人员分成三组：开发组只在测试和开发环境有读写权限，对生产环境仅能查看；运维组可以管理生产环境的 ECS 和数据库，但高危操作需要额外审批；数据组只访问数据分析相关的存储和数据库。每个人使用自己的子账号登录，并全部开启 MFA。
调整之后，类似的误操作再没有出现过。出现异常时，操作审计日志能直接定位到具体子账号，排查时间从几天缩短到几十分钟。
案例二：财务人员只看账单
一家做 SaaS 服务的创业公司，财务需要每月核对云资源费用，但不应碰到任何业务资源。最省事的做法，是为财务单独建一个子账号，只授予费用中心的查看权限，不给任何资源管理权限。
这样，财务可以在费用中心下载账单、查看消费明细，却无法创建或删除 ECS 实例。核对完成后，技术负责人还会定期查看该子账号的登录记录，确认没有异常访问。
第三种：只跑脚本的程序账号
定时备份、监控采集这类任务，通常只需要调用接口，不需要人去登录控制台。这类账号只开通 OpenAPI 访问，并且只挂载脚本实际用到的策略。它没有控制台密码，也就不涉及 MFA，但 AccessKey 要比人员账号管得更严。脚本账号的密钥一旦泄露，往往不容易被人察觉。
常见误区
- 多人共用一个子账号：审计就失去了意义。一人一账号，哪怕麻烦一点。
- 直接给子账号 AdministratorAccess：图省事的做法，实际上等于又开了一个主账号。应按工作内容选策略。
- AccessKey 长期不轮换：密钥泄露后，攻击者可以长期使用。建议定期更换，并删除不再用的密钥。
- 把 AccessKey 写进代码或公开文档：这是泄露事故最常见的原因之一。
日常管理
子账号建好之后，还要持续维护。每季度检查一次子账号列表，清理已离职或长期不用的账号。权限策略也要定期复查，看它是否还和当前职责匹配，人员调岗后最容易留下多余权限。生产环境的操作建议开启审计告警，异常操作及时通知负责人，而不是等出了事再回查日志。
归纳起来就是：按人分身份，按岗分权限，操作留痕。前期多花些时间规划，后面的协作和安全管理会省心很多。
