阿里云授权对象怎么选？RAM用户、角色和跨账号场景怎么配

给阿里云做权限管理，第一步是想清楚权限该给谁。这里说的授权对象，就是可以被赋予访问权限、并真正发起操作的主体。授权对象选对了，后面的策略设计、安全审计和成本控制才有依据。不少团队的麻烦出在权限分错了人：策略本身可能没问题，但从一开始就落到了不该拿到它的人或程序手里。

先分清三类授权对象

在阿里云资源访问管理（RAM）里，常用的授权对象有三类，分别是RAM用户、RAM用户组和RAM角色。权限策略挂在这些对象上，再由它们去访问ECS实例、OSS存储桶、RDS数据库等云资源。

RAM用户一般对应一个具体的人，或一个长期运行的应用，有自己的登录凭证或访问密钥。如果某个人会长期固定使用阿里云，给他一个独立的RAM用户最直接。
RAM用户组把职责相同的RAM用户放进同一个组，统一附加策略。人员调岗时只改所在的组，不用逐个修改权限，也不容易漏掉。
RAM角色没有固定的长期凭证，由可信实体临时扮演，拿到的是有时效的安全令牌。跨账号访问、服务之间相互调用，以及临时给外部人员开放权限，通常都适合用角色。

主账号权限最大，也最危险。日常操作尽量不要直接用主账号登录，而是为每个人、每个系统分别建立合适的授权对象。主账号可以留给少数必须用到它的场景，并且妥善保管其凭证。

某电商企业起初只有一个主账号，开发、运维和财务人员共用同一套AccessKey。直到一次误删测试库的事故，团队才意识到问题：出了事查不到是谁操作的，也分不清每个人本该有多大的权限。

整改时，他们按职能划分了三个RAM用户组。开发组只读测试环境的ECS和日志，同时拥有部分资源的启停权限。运维组管理生产环境，但删除类操作需要二次确认。财务组只能查看账单和费用中心。每个员工改用独立的RAM用户登录，开启多因素认证，并定期轮换访问密钥。

半年后，审计日志可以精确追溯到具体人员的每一次操作，权限方面的问题也基本消失。这件事说明，授权对象的划分越贴近真实的职责边界，后续维护就越省心。把人按职能归组，比事后逐条去改个人权限轻松得多。

另一类常见需求是跨账号访问。比如合作服务商需要读取客户OSS里的日志文件，但双方都不希望把账号密钥交给对方。

比较稳妥的做法是，客户在自己的账号里创建一个RAM角色，在信任策略中指定服务商的阿里云账号ID作为可信实体，并且只附加读取指定存储桶的权限。服务商调用STS的AssumeRole接口获取临时凭证，用完即失效。整个过程中，客户没有交出任何长期密钥，之后也能随时收回这个角色的信任关系。

这里有个容易忽略的地方，信任策略决定谁能扮演角色，权限策略决定角色能做什么，两者要分开检查。只写了其中一个，角色要么无法被扮演，要么权限过大。

很多人以为，给授权对象附加了某个策略，它就一定能访问对应的资源。实际情况要复杂一些。资源本身的限制、条件键（比如来源IP、MFA状态），以及策略里是否存在显式拒绝语句，都会影响最终结果。一条允许语句被另一条拒绝覆盖，排查起来常常要花不少时间。

所以策略写完，最好先用策略模拟工具验证，再在小范围内实际测试，确认没问题后再推广到正式环境。直接上线、出了问题再回头查，成本通常更高。

另外，控制台的菜单名称和可用选项会随产品版本调整。具体操作步骤，请以阿里云官方文档和你当前看到的控制台为准。

授权对象选得好不好，直接决定权限能不能被说清楚、管得住。先想明白谁需要做什么，再决定用用户、用户组还是角色来承载，权限体系通常会稳定很多。