很多团队刚上云时都会碰到同一个问题：一个主账号 AccessKey 被好几个人轮流用，开发、测试、运维共用一套权限。出了问题，很难说清是谁做的。阿里云 RAM（访问控制，Resource Access Management）就是为这个场景准备的。你可以在一个云账号下按人、按角色、按业务分配权限，让“谁能做什么”落在一套能管、能查的规则里。
这篇文章只挑 RAM 里最常用的几样东西，配两个典型案例，再给一段策略示例和落地顺序。控制台界面和功能名称会随版本调整，动手前还是以官方文档为准。
为什么不能都用主账号
阿里云主账号对名下所有资源都有完全控制权，包括计费、删除资源、修改安全配置。如果日常操作都用主账号完成，凭证一旦泄露，损失没有上限。RAM 的做法是把“身份”和“权限”从主账号里拆出来：主账号留着兜底，日常操作交给权限受限的子身份。
拆开之后，好处很直接。每个人只拿到干活需要的那部分权限。每个子身份的操作都能在操作审计里找到记录。人员调动时，停用对应身份就行，不用整套密钥一起换。
四个核心概念
RAM 里最常打交道的是四样东西，弄清它们之间的关系，后面的配置会顺很多。
- RAM 用户：对应一个具体的人，或一个程序身份。可以设登录密码用于控制台登录，也可以创建 AccessKey 用于调用 API。
- 用户组：把若干 RAM 用户放在一起统一授权。新人进了某个团队，把他加入对应用户组即可，不用逐个挂策略。
- RAM 角色：一组权限的集合，本身没有长期凭证。用户、其他云账号或云服务可以临时扮演（assume）它，常用于跨账号访问和服务间授权。
- 权限策略：用 JSON 写的授权规则，说明允许或拒绝哪些操作、作用于哪些资源。可以挂到用户、用户组或角色上。
可以这么理解：策略决定权限的内容，用户组和角色决定权限发给谁，用户则是最后真正执行操作的人或程序。
案例一：电商团队的权限拆分
某电商公司有应用开发、数据分析和运维三个团队。早期大家共用一个 AccessKey，数据分析同学为了查看 OSS 上的日志，误删了一个存储桶的生命周期配置，排查花了大半天。
改造分三步。先给每位员工建独立的 RAM 用户，停用共用的 AccessKey，并为所有用户开启多因素认证（MFA）。再按职能建三个用户组：dev-team、analytics-team、ops-team。最后给每个用户组挂对应的策略。
数据分析组只需要读日志、查数据，策略里只放只读类操作。运维组要管 ECS 实例和网络配置，权限较大，所以用资源范围把它限定在生产环境的资源组里，不碰其他项目。开发组只能操作开发和测试环境的资源。
改完以后，数据分析同学无法再修改存储桶配置了。每次变更也能对应到具体的人，下次出问题，排查时不用挨个问。
案例二：跨账号访问与 AssumeRole
另一种常见情况是跨账号协作。某公司的数据平台部署在账号 A 下，业务数据却存放在账号 B 的 OSS 里，由另一家子公司管理。两边都不想直接交换 AccessKey。
比较合适的做法是：账号 B 创建一个 RAM 角色，例如 data-reader。信任策略里指定账号 A 可以扮演这个角色，权限策略只允许读取指定存储桶的数据。账号 A 的服务或用户通过 AssumeRole 获取临时安全令牌（STS），有效期一般是小时级，过期后自动失效。
这样两边之间就没有长期密钥在流转，权限边界完全由账号 B 掌握，需要收回时改策略或删除信任关系即可。ECS、函数计算这类服务要访问其他资源时，也可以绑定角色来实现，代码和配置文件里就不必再写 AccessKey。
策略怎么写
RAM 策略是 JSON 格式，核心元素有 Effect（允许或拒绝）、Action（操作）、Resource（资源），以及可选的 Condition（条件）。编写时有三点要留意。
第一，别图省事用 “*” 通配所有操作。第二，资源尽量写明确，不要对全部资源开放。第三，遇到敏感操作，可以用 Condition 限制来源 IP，或要求启用 MFA。下面这个策略只允许读取指定的 OSS 存储桶：
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oss:GetObject",
"oss:ListObjects"
],
"Resource": [
"acs:oss:*:*:example-log-bucket",
"acs:oss:*:*:example-log-bucket/*"
],
"Condition": {
"Bool": {
"acs:SecureTransport": "true"
}
}
}
]
}示例里的存储桶名称是占位符，换成你自己的资源再用。策略只放了读对象和列对象的操作，并要求通过 HTTPS 访问。上线前最好先在测试环境验证一遍，确认功能正常后再应用到生产。
落地顺序
权限体系不是一次性建完的，一般按下面的顺序推进。
- 先摸清现状：找出共用的 AccessKey，以及长期没有登录或调用过的 RAM 用户，逐步停用或删除。
- 主账号只做兜底：日常操作全部走 RAM 用户，删除主账号的 AccessKey，并开启 MFA。
- 以用户组为单位授权：不要直接给单个用户挂策略。团队扩张或人员调动时改组即可，省得一个个核对。
- 定期复盘权限：借助访问分析之类的能力，找出长期用不上的权限并收回。
- 开启操作审计：把关键操作日志投递到统一的存储或日志服务中，并设置告警。
AccessKey 还要单独说一下。密钥需要定期轮换，不要写进代码仓库，也不要通过聊天工具来回发送。一旦发现泄露，先停用对应密钥，再排查影响范围。
小结
RAM 的概念本身不复杂，真正费功夫的是把组织里的职责划分准确地对应到权限模型上。建议先选一个小团队或一条业务线试点，把用户、用户组、角色和策略的关系跑通，再推广到整个账号。权限收得越清楚，后面审计、排障和合规的工作就越省事。
