阿里云账号体系#

什么是 RAM 用户#

阿里云的”子账号”官方名称是 RAM 用户（Resource Access Management 用户）。它是和主账号隔离的独立身份，用来让人、应用或其他服务以受限权限访问云资源，而不是直接拿主账号 AccessKey 裸奔。

需要先澄清一个最常见的误解：“子账号”和”RAM 用户”指的其实是同一个实体。“子账号”是口语/民间的叫法，对应”主账号”这个根概念——主账号是根，下面分出来的都叫”子”；“RAM 用户”则是阿里云控制台和文档里的正式术语。阿里云并不存在一个叫”子账号”的独立产品，控制台里创建的那个东西就是 RAM 用户。讨论权限策略、提工单、看文档时，一律用”RAM 用户 / RAM 角色 / 用户组”这三个官方词，避免歧义。

为什么需要 RAM 用户#

主账号是”根钥匙”，拥有账号下所有资源的全部权限，且无法被收口限制。一旦主账号 AK 泄露（写进代码、提交到 Git、贴进日志），整个账号的 ECS、RDS、OSS、账单全部失守，而且没法用权限策略补救。所以阿里云官方安全建议第一条就是：日常操作不要用主账号 AK。

RAM 用户的核心价值，在于把一把”根钥匙”拆成一把把”受限钥匙”：

最小权限：只给某个 RAM 用户授某个服务某个实例的权限
可撤销：泄露了直接禁用或删除这个 RAM 用户的 AK，不影响其他身份
审计可追溯：操作日志能定位到具体身份，而不是笼统的”主账号”
隔离：不同业务、团队、应用各用各的 AK，互不污染

三个核心概念别搞混#

RAM 体系里有三个容易混淆的身份对象，理解它们的边界是配权限的前提。

概念	作用	类比
RAM 用户	一个身份（人或应用），有自己的 AK / 密码	一个员工账号
用户组	RAM 用户的集合，统一授权	部门
角色 (Role)	虚拟身份，没有 AK，靠 STS 临时凭证扮演	临时工牌

实践上的选型逻辑：给应用发长期 AK → 用 RAM 用户；给 ECS 上跑的应用要凭证 → 用实例 RAM 角色（更安全，连 AK 都不用管）；跨账号访问 → 用角色 + STS 临时凭证。

真正容易和”RAM 用户”搞混的是 RAM 角色——它是没有 AK、靠 STS 临时凭证扮演的虚拟身份。这才是值得记牢的区分点，而不是”子账号 vs RAM 用户”那对其实等同的叫法。

权限策略（Policy）#

权限通过策略授予，策略是一段 JSON，描述”允许/拒绝谁对哪个资源做什么”：

1
{
2
  "Version": "1",
3
  "Statement": [
4
    {
5
      "Effect": "Allow",
6
      "Action": ["oss:GetObject", "oss:PutObject"],
7
      "Resource": "acs:oss:*:*:my-bucket/*"
8
    }
9
  ]
10
}

Key params:

Effect — Allow 或 Deny，Deny 优先级最高，一旦命中 Deny，再有 Allow 也无效
Action — 服务操作名，格式 <service>:<action>，如 oss:GetObject；oss:* 表示该服务全部操作
Resource — 阿里云统一资源标识 ARN，格式 acs:<service>:<region>:<account>:<resource>
Version — 策略版本号，目前固定写 "1"

策略分两类：

系统策略：阿里云预置，如 AliyunOSSFullAccess、AliyunRDSReadOnlyAccess。方便但粒度粗，适合快速给只读或全量权限。
自定义策略：自己写 JSON，粒度可精确到某个实例的某个操作。生产环境推荐。

粒度从粗到细的层级是：* 全开 → 服务级（oss:*）→ 资源级（oss:* 限定到 my-bucket）→ 操作级（oss:GetObject）。授权可以挂在 RAM 用户上，也可以挂在用户组上——推荐挂组，人进组即得权限，人员变动只动组不动策略。

创建流程（控制台）#

把一个 RAM 用户从无到有配出来，标准步骤如下：

RAM 控制台 → 用户 → 创建用户
勾选 OpenAPI 调用访问（生成 AccessKey）和/或 控制台访问（设密码）
AK 只在创建时显示一次，错过就只能重置，当场保存好
加权限：直接加系统策略，或加进用户组，或挂自定义策略
拿到 AccessKeyId + AccessKeySecret 配到应用里

第 3 步是最容易踩的坑：AccessKeySecret 不可逆，忘了不是”找回”而是”重置”——只能新建一对 AK 替换掉旧的。

最佳实践（踩坑总结）#

主账号 AK 永远是最大风险面，下面几条是把风险面收窄到最小一圈的做法。

主账号 AK 永远不进代码、不进配置文件明文。存到加密的密钥管理里（如 systemd credential、KMS、Vault），运行时解密进环境变量，代码只读 env。
一个应用一个 RAM 用户，别一个 AK 到处用，方便轮换和定位异常来源。
AK 轮换顺序：新建 → 切换应用 → 确认稳定 → 删除旧 AK。别先删旧的，否则切不过去。
绝不授 AdministratorAccess 给子账号，那等于又造了个主账号。
用 MFA 给控制台登录的 RAM 用户加二次验证。
AccessKeySecret 不可逆，忘了只能重置，不是”找回”。
配额/欠费/安全告警走云监控，AK 被盗往往是从异常 API 调用量暴增发现的。

AK 轮换可以用一条最小化的命令串起来，关键是”先建后删、灰度切换”：

1
# 1. 在 RAM 控制台新建一对 AK，配到应用环境变量
2
# 2. 重启应用，观察一段时间确认稳定
3
# 3. 确认无误后再回控制台禁用并删除旧 AK
4
aliyun ram CreateAccessKey --UserName app-bot
5
aliyun ram DeleteAccessKey --UserName app-bot --UserAccessKeyId LTAIOLDxxxxx

Why this way: 先建后删保证任何时刻都有可用凭证，切换出问题能立刻回滚到旧 AK；留足灰度窗口期能覆盖定时任务和长连接，避免轮换瞬间打挂服务。

何时用哪种身份#

落地到真实项目时，判断用哪种身份的依据是”凭证怎么发、风险怎么收”：

长期跑的应用调云服务 API → RAM 用户 + 自定义策略（最小权限），AK 存加密 credential。
ECS 实例里跑的应用 → 实例 RAM 角色，应用代码里连 AK 都不用管，靠元数据拿 STS 临时凭证。
跨账号访问 → 对方账号建角色，本账号 RAM 用户扮演该角色拿临时凭证，不留长期 AK 在两边。
临时外包/第三方 → RAM 角色 + STS，设过期时间，到期自动失效。

举个具体例子：如果项目里用阿里云 Bailian / DashScope 调大模型，key 存在加密 credential 文件里，要确认这把 key 是不是子账号级别的。若是直接从主账号控制台拿的 AK，建议改成在 RAM 里建一个只授 bailian / dashscope 调用权限的子账号。这样即使 credential 文件被翻出来，攻击面也只局限在”调模型”这一个动作上，碰不到账号下的 ECS、OSS、账单——这就是把”最小权限”原则落到一个具体服务上的标准操作。