📚 课程目录第2章 IAM基础概念

2. IAM 基础概念：用户、组、角色、策略的定义与关系

聊到云安全，第一个绕不开的就是 IAM。说白了，IAM 就是云上的 "门禁系统" 加 "权限管理"。你想想看，公司里谁可以进哪间办公室，谁能用哪台打印机，总得有个规矩。云上也是一样，只不过管的是 API 调用、资源读写这些事。

我个人习惯把 IAM 拆成四个核心零件：用户、组、角色和策略。搞清楚了它们，后面设计权限模型时你就不会手忙脚乱。

2.1 用户（User）—— 你是谁

用户，就是某个操作者的身份标识。可以是真人，比如开发小哥张三；也可以是机器，比如 CI/CD 流水线里跑的 Service Account。你给它一个名字，它就代表一个 "主体"。

这里有个容易搞混的点：IAM 用户和登录账号是两码事。登录账号是 "谁付钱"，IAM 用户是 "谁干活"。我曾经见过有人把老板的 root 账号直接给开发用——嗯，后来出了事，权限大到能删库。

我的建议：每个真实的人或机器服务都建独立的 IAM 用户。别共享账号。别偷懒。共享账号一多，审计日志就像一锅粥，根本查不出是谁动了手。

2.2 组（Group）—— 你属于哪个团队

组就是用户的集合。把张三、李四、王五放进 "开发组"，给这个组分配权限，那组里所有人都自动拿到这些权限。省事，也规范。

没有组会怎样？你想想看：公司来了一批新实习生，你得一个一个给他们加权限；有人离职，你得一个一个查他加过哪些策略。累不累？

// 伪代码：组与用户的关系
Group: "dev-team"
  Members: [user-zhangsan, user-lisi, user-wangwu]
  AttachedPolicies: [policy-developer-access]

// 张三能做什么？
// -> 继承了 dev-team 的所有权限

我在项目中遇到过很坑的场景：某团队没有用组，直接把策略贴到每个用户上。后来来了个安全审计，要批量修改权限，改到凌晨三点。何必呢？

2.3 角色（Role）—— 你暂时能做什么

角色和用户有点像，但有一个关键区别：角色没有长期凭证。它是一套 "临时工牌"。谁需要用，谁就 "扮演" 它，拿到一组临时凭证，用完就失效。

这玩意儿在跨账号授权时特别好使。比如你想让生产账号的某个服务访问测试账号的数据库，就不用建用户、不用交换密钥，直接给生产服务分配一个角色就够了。

避坑指南：我曾经看过有人把角色当用户来用——长期 "扮演" 同一个角色不切换，还让它跑定时任务。角色是有会话时效的，最长一般 12 小时或 1 小时（各家云不一样）。一旦过期，任务就断了。所以，长时间运行的工作负载，能用用户就别用角色；跨账号短期访问，用角色就对了。

2.4 策略（Policy）—— 你能做什么，不能做什么

策略，就是权限规则本身。说白了，它是一段 JSON 或 YAML，里面写清楚了 "谁可以对什么资源做什么操作"。

典型的策略包含几个要素：

Effect：Allow 或 Deny。Allow 放行，Deny 拒绝。
Action：具体操作，比如 kms:Decrypt、s3:GetObject。
Resource：针对哪些资源生效，比如某个 KMS 密钥或 S3 桶。
Condition：可选条件，比如 "只允许在办公时间操作" 或 "必须来自公司内网 IP"。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws:kms:cn-north-1:123456789012:key/abc-123",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        }
      }
    }
  ]
}

你想想看，这种规则写清楚后，连机器都能直接执行。不用人工审批，不用口头传达，多清爽。

2.5 它们的关系 —— 一张图说清楚

这四个东西怎么搭在一起？我画了一张结构图，你看一眼就明白了。

2.6 核心区别与选择建议

搞清楚了概念，接下来就是 "什么时候用什么"。我直接给你一张对比表，照着选就行：

维度	用户	组	角色	策略
本质	身份	身份集合	临时身份	权限规则
有无凭证	有（长期）	无	有（临时）	无
典型用途	个人 / 服务账号	团队管理	跨账号 / 服务扮演	定义权限
生命周期	长期	长期	会话级	长期 / 可更新
风险级别	高（泄露即出事）	中	中（需要信任策略）	核心（写错全崩）

我的实战经验：

人员管理：优先用组。别一个个用户绑策略。
机器互访：优先用角色。别浪费时间去管密钥轮换。
写策略时：默认 Deny，只开最小权限。你永远不知道哪天加了个 "s3:ListAllMyBuckets" 会不会被人用来枚举数据。

2.7 一个容易忽略的点：策略的评估逻辑

很多人以为 "策略加得越多权限越大"，其实不是。策略的评估逻辑是：Deny 永远优先。哪怕你同时有一个 Allow 和一个 Deny 在同一条语句里，Deny 会赢。

我之前就踩过坑：给一个用户加了 "允许访问所有 S3 桶" 的宽策略，后来又加了一条 "禁止访问某个敏感桶" 的细策略。结果发现用户还是能访问那个敏感桶——因为我忘了 Deny 优先于 Allow，而且我把两条策略的顺序搞反了。嗯，后来花了一下午查日志才定位到问题。

所以写策略时，记住一句话：先阻塞，再放行。安全策略永远是 "禁止优先"。

2.8 小结一下

用户、组、角色、策略，这四个东西组合起来，就能搭出很灵活又很安全的权限模型。你想想看：用人时用组管，机器交互用角色，所有权限都靠策略定义。这样一来，不管是业务扩张还是安全审计，你都有章可循。

下一部分我们会聊怎么把这些人、组、角色串起来，搭出一个完整的权限模型框架。别急，先把这四个零件的概念锤实了，后面的事就水到渠成。