如何给IAM用户授权，用户权限设置方法有哪些

给IAM用户授权的核心在于通过系统策略或自定义策略，将操作权限精确绑定到用户或用户组，确保最小权限原则落地。

为什么需要给IAM用户授权？从团队协作场景说起

当你所在团队开始使用云资源时,一个主账号多人共享的做法很快会暴露出问题，操作日志无法追踪到具体人员，一旦误删或配置泄露，是谁的锅根本说不清，更麻烦的是，主账号拥有最高权限，任何成员的误操作都可能整垮整个业务环境。给IAM用户授权（即创建子账号并分配权限）就是为了解决这个治理困境，它让每个成员只拿到自己工作所需的权限，既不影响协作效率，又守住安全底线，行业共识认为，超过九成的云安全事件都与权限配置不当有关，而合理授权是成本最低的防护手段。

如何给IAM用户授权？两种策略方式对比

授权的核心是“策略”，它定义了允许或拒绝执行哪些操作、针对哪些资源，主流云厂商（阿里云RAM、AWS IAM、酷盾安全CAM）都提供两种策略类型，你可以根据业务复杂度选择。

系统策略：快速上手，适合标准场景

系统策略由云厂商预定义,覆盖常见运维角色，比如管理员、只读用户、数据库运维等，你只需在用户或用户组下“挂载”一条策略，无需编写JSON，这对刚接触子账号权限管理的团队非常友好，几分钟就能完成基础分发，但缺点是粒度粗，无法满足细粒度控制需求，让你只允许某个用户操作特定地域的ECS实例，系统策略就做不到。

自定义策略：灵活控制，适合复杂权限

当你有更精细的限制需求时,就得自己写策略，自定义策略用JSON格式描述，可以精确到“允许用户A在华东1区创建按量付费的ECS，但不允许删除”，这种IAM授权策略怎么写的问题，核心是理解三个要素：Effect（允许/拒绝）、Action（服务名+操作名）、Resource（资源ARN），建议先在测试环境验证，再应用到生产环境，下表对比了两种策略在实际场景中的差异：

实操：阿里云RAM用户授权步骤

以国内使用最广泛的阿里云为例,如何给IAM用户授权的完整流程如下，这里强调一个原则：不要直接给用户授权，先创建用户组，再授权组，然后把人加进去，这样团队人员变动时，只需调整组关系，无需修改策略本身。

第一步：创建RAM用户

登录阿里云控制台,进入“访问控制”服务，在左侧“身份管理”中选择“用户”，点击“创建用户”，输入登录名称和显示名称，勾选“控制台密码登录”或“编程访问”，根据实际情况选择验证方式，建议开启“启用多因素认证（MFA）”，保护高风险账号。

第二步：创建用户组并授权

在“身份管理”中选择“用户组”，点击“创建用户组”，给组起一个清晰的名字，开发只读组”，创建后，进入该组，点击“授权”，你会看到策略列表，先搜索“ReadOnly”系统策略，挂载给组，如果还需要更细的权限，可以切换到“自定义策略”页，创建一个允许访问OSS某个Bucket的策略。阿里云子账号授权步骤的关键就在这里：组授权后，所有组成员自动继承权限。

第三步：将用户加入组

回到用户列表,点击刚创建的用户，选择“编辑基本信息”，在“用户组”中勾选你创建的组，保存后，用户就拥有了组权限，注意，如果一个用户属于多个组，权限是“并集”关系，如果需要排除某些权限，需要使用“显式拒绝”策略，写拒绝语句。

第四步：验证权限是否生效

用终端用户身份登录子账号,尝试执行预计拥有的操作，比如查看ECS实例列表，如果提示“无权限”，检查策略中Action和Resource是否写对，建议使用RAM用户模拟器工具（各厂商控制台都有）来测试策略效果，避免直接碰生产环境。

子账号权限管理中的常见雷区

即使你按照上述步骤操作,在实际使用中依然会遇到问题，下面几个坑是团队最容易踩的。

权限过大：给子账号授予了“AdministratorAccess”

为了省事,先给所有用户绑上管理员策略，以后再说，这种做法的危险在于，子账号一旦泄露，攻击者可以删库跑路。给IAM用户授权时，务必遵循“最小权限”原则：只给当前明确需要的权限，哪怕后续需要再加，如果业务确实需要临时提升权限，可以申请角色扮演（STS），配置临时凭证。

未回收冗余权限：员工离职后权限还在

人员调整时,往往只记着回收主账号，忽略子账号，据统计，相当一部分云资源泄露事件是离职员工账号仍在线导致的，你应该建立自动化流程：定期扫描活跃用户，结合身份治理系统，在用户离职时直接停用RAM用户，也可以为每个用户设置“登录绑定”和“操作绑定”，强制要求MFA。

忽略权限边界：用“权限边界”兜底

权限边界（Permission Boundary）是云厂商提供的一种安全防护机制，你可以为用户设置一个上限，只能操作华东1区域的资源”，即使该用户被误绑了管理员策略，也无法突破边界，建议在创建用户时，就绑定一个权限边界，这相当于给授权上了一道保险。

关于IAM用户授权的两个高频问题

IAM用户授权后无法访问某资源，可能是什么原因？

排查步骤很明确：第一，确认用户是否在正确的用户组中，策略是否已经挂载；第二，检查策略语法，看Action和Resource是否匹配实际请求；第三，查看是否有其他策略显式拒绝了该操作（显式拒绝优先级高于允许）；第四，如果使用了权限边界，边界策略是否包含了该操作，部分云服务（如KMS、SLB）有独立的资源级授权，需要额外配置，如果以上都正常，在控制台审计日志里拉取“未经授权”记录，查看具体错误信息。

如何给跨账号的IAM用户授权？

跨账号授权通常使用“角色扮演”机制，在你的账号中创建一个RAM角色，在角色信任策略里指定允许哪个账号的哪个用户来扮演，对方账号的用户在控制台切换角色，或通过API获取STS临时凭证，即可操作你的资源，这种方式不需要暴露长期密钥，安全等级更高。子账号权限管理中，跨账号场景建议优先使用角色，而不是直接复制长期密钥给对方。