📚 课程目录第3章 AWS IAM深度解析

3、AWS IAM深度解析：用户、组、角色与策略、IAM Policy语法与评估逻辑、跨账户访问与SCP

说到多云身份治理，AWS IAM 是绕不开的第一道坎。很多人在云上出了安全问题，十有八九是 IAM 没搞明白。我见过不少团队，策略写得像天书，权限放得比谁都宽。今天咱们就把 IAM 的核心拆开揉碎，从基础概念到策略评估逻辑，再到跨账户访问和 SCP，一次性讲透。

3.1 IAM 四大核心对象：用户、组、角色与策略

AWS IAM 其实就管四样东西：用户、组、角色、策略。理解它们的关系，你就掌握了 IAM 的骨架。

对象	本质	典型场景
用户（User）	代表一个人或服务账号	开发人员登录 AWS 控制台
组（Group）	用户的集合，简化权限管理	将“开发者”组统一赋予 S3 读写权限
角色（Role）	临时身份，不绑定长期凭证	EC2 实例访问 S3、跨账户访问
策略（Policy）	权限定义的文档（JSON）	允许或拒绝某 API 操作

我个人习惯把角色看作“临时工牌”。用户是长期员工，有固定的工牌（长期密钥）。角色则是访客牌，用完就失效。你想想看，EC2 实例要访问 S3，难道把 Access Key 写死在代码里？那太危险了。给实例挂一个角色，临时凭证自动轮转，这才是正道。

避坑指南： 我曾经遇到一个团队，给每个开发人员都创建了独立的 IAM 用户，然后直接给用户挂策略。结果人员一多，权限管理直接失控。正确的做法是：用组来管理权限，把用户加到组里。这样人员变动时，只需要调整组成员关系，不用改策略。

3.2 IAM Policy 语法与评估逻辑

策略是 IAM 的灵魂。写策略就像写法律条文，一个字都不能错。IAM 策略本质上是一个 JSON 文档，核心结构如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*"
        }
    ]
}

这里面有几个关键字段：

Effect：Allow 或 Deny。说白了就是“允许”还是“拒绝”。
Action：要控制的 API 操作。可以用通配符 *，但我建议尽量精确。
Resource：操作的资源 ARN。这是最容易出错的地方。
Condition：可选，增加额外的限制条件，比如来源 IP、MFA 状态等。

嗯，这里要注意：策略评估逻辑并不是简单的“允许优先”。AWS 的评估规则是：显式拒绝优先于一切允许。如果同时有 Allow 和 Deny，Deny 胜出。如果没有任何显式允许，默认隐式拒绝。

    核心原则： 默认隐式拒绝 + 显式允许 + 显式拒绝（最高优先级）。说白了，没有明确说“可以”，就是“不可以”。但一旦说了“不可以”，就算其他地方写了“可以”，也不行。

为什么会这样设计？我猜是为了安全。你想想看，如果 Allow 优先，那一个宽泛的 Allow 策略就可能覆盖掉你精心设置的 Deny。AWS 把 Deny 设为最高优先级，就是为了让你能“一刀切”地封死某些危险操作。

我在项目中遇到过这样一个坑：给一个角色挂了一个 Allow 所有 S3 操作的策略，然后又挂了一个 Deny 删除特定桶的策略。结果 Deny 生效了，但 Allow 里的 ListBucket 也受到了影响——因为 Deny 策略的 Resource 写错了，导致所有桶的删除操作都被拒绝。嗯，策略的 Resource 一定要精确匹配。

3.3 跨账户访问

多云环境下，跨账户访问是家常便饭。比如，你的开发账号需要读取生产账号的 S3 数据。怎么做？

核心思路是：生产账号创建一个角色，开发账号的用户可以切换到那个角色。具体分三步：

在生产账号中创建 IAM 角色，并设置信任策略（Trust Policy），允许开发账号的某个用户或角色来“扮演”它。
给这个角色挂载权限策略，定义它能做什么。
在开发账号中，给用户或角色授予 sts:AssumeRole 的权限，指向生产账号的角色 ARN。

说白了，就是“借身份”。开发账号的用户通过 STS（Security Service）拿到生产账号角色的临时凭证，然后用这个凭证去操作资源。

注意： 跨账户访问时，信任策略和权限策略是分开的。信任策略决定“谁能来”，权限策略决定“来了能干什么”。我曾经见过有人把信任策略写成了权限策略，结果角色根本没法用。这两个东西千万别搞混。

3.4 SCP：组织层面的权限边界

SCP（Service Control Policy）是 AWS Organizations 里的一个高级功能。它不直接给用户授权，而是划定一个权限边界。你可以把它理解成“最高指示”：组织内的所有账号，都不能越过 SCP 划定的红线。

举个例子：你可以在 SCP 里禁止所有账号删除 S3 桶。那么就算某个账号的 IAM 策略写了 Allow s3:DeleteBucket，实际操作时也会被 SCP 拒绝。SCP 的优先级高于账号内的 IAM 策略。

对比项	IAM 策略	SCP
作用范围	单个用户、组或角色	整个 OU 或账号
是否直接授权	是	否，只设边界
优先级	受 SCP 限制	高于 IAM 策略
典型用途	细粒度权限控制	全局安全基线

我个人习惯在组织根 OU 上挂一个“禁止删除日志”的 SCP，这样所有子账号都无法删除 CloudTrail 日志。你想想看，如果攻击者拿到了某个账号的 Admin 权限，第一件事就是删日志灭迹。有了 SCP，就算 Admin 也删不了，日志安全就有了底线。

避坑指南： SCP 默认是 Allow 全部，然后你通过 Deny 来限制。但如果你把 SCP 设为“只允许某些服务”，那其他所有服务都会被隐式拒绝。我曾经有个客户，在 SCP 里只 Allow 了 EC2 和 S3，结果整个账号的 CloudWatch 都挂了，监控全黑。嗯，SCP 的“白名单模式”要慎用。

3.5 本章知识体系总览

下面这张图把 AWS IAM 的核心逻辑串起来了。从用户、组、角色到策略，再到跨账户访问和 SCP，你可以看到它们之间的关系和层级。

这张图把 IAM 的核心脉络理清了。用户和组是“谁”，角色是“临时身份”，策略是“权限定义”，SCP 是“组织级边界”。跨账户访问则是通过角色扮演实现的。你想想看，掌握了这些，AWS 的权限管理基本就通了。