📚 课程目录第1章 IAM概述

1. IAM 概述：什么是 IAM，核心概念

说实话，刚入行那会儿，我对 IAM 的理解特别狭隘——不就是管个密码、加个权限吗？后来在一次云上事故里，一个同事不小心把生产库的删除权限绑给了全体开发者，一上午数据丢了三回……嗯，从那以后我才真正明白：IAM 是整个云安全的门锁，锁芯没配好，墙再厚也没用。

IAM，全称是 Identity and Access Management，说白了就是谁能以什么方式访问哪些资源。在云环境里，它不只是一个功能模块，而是安全的基础设施。我通常把它拆成两个层面：身份层（你是谁）和权限层（你能干什么）。

1.1 四个核心概念

我们先从最基础的说起。IAM 的精髓其实是四个零件：用户、组、角色、策略。很多人一听就晕，觉得差不多。我当年也一样，直到自己画了张关系图才理清。

1.2 用户（User）

用户就是一个人或者一个应用的身份。在云平台里，每个用户都有一个唯一的 ARN（Amazon Resource Name）来标识。我个人习惯把用户分成两类：人肉用户和机器用户。人肉用户就是你团队里的开发、运维、测试；机器用户则是服务账号、CI/CD 系统里的角色。

关键区别：人肉用户通常需要密码和多因素认证，机器用户则用访问密钥（Access Key + Secret Key）或临时凭证。

举个例子，我在一个项目中给后端服务创建了一个叫 backend-svc 的用户，只给它分配了写 S3 桶的权限。结果过了一个月，有人发现这个用户的密钥被提交到了 GitHub。还好我们当时用了最小权限策略，它只能写日志桶，没什么大损失。打那以后，我遇到机器用户必加 密钥轮换 和 使用期限。

1.3 组（Group）

组就是用户的集合。为什么要用组？你想想看，如果你有 20 个开发者，每个人都单独绑定策略，哪天需要加一条新权限，你得改 20 次。把策略绑到组上，一个人进组就自动拥有权限，出组就自动收回。我强烈建议：永远不要给单个用户直接绑策略，除非你有极其特殊的临时需求。

管理方式	直接绑用户	通过组绑定
维护成本	高，每个用户单独管理	低，一条策略管一组人
权限泄漏风险	容易遗漏或误绑	集中管理，审计清楚
可扩展性	差，人数一多就乱	好，按职能分组即可

1.4 角色（Role）

角色和用户不一样。用户是持久的身份，角色是临时借用的身份。你可以理解成“切换身份”的通行证。为什么需要角色？最常见的场景是：一个 EC2 实例要访问 S3，你不想把访问密钥硬编码在代码里，那就给实例绑定一个 IAM 角色，自动获取临时凭证。我之前遇到过一位同事，他把 AWS 的 Secret Key 直接写在了 Python 脚本里，结果被黑客扫到了……后来全部换成角色 + 临时凭证，再没出过问题。

小技巧：角色的信任策略（Trust Policy）决定了谁可以“扮演”这个角色。务必把信任范围缩到最小，比如只允许特定账号或特定服务。

1.5 策略（Policy）

策略就是权限的说明书。它告诉系统：允许谁做什么。策略分为两种：托管策略（由云厂商或你自己定义好的，可复用）和内联策略（直接嵌在用户/组/角色上，不可复用）。我个人的做法是：公共权限用托管策略，特殊权限用内联策略，并且定期清理。

来看一个最基础的示例策略 JSON：

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

这个策略的意思是：允许对 my-bucket 下的所有对象执行 GetObject 操作。注意，Effect 只有两个值：Allow 和 Deny。Deny 优先级高于 Allow，这是一个安全底座。我在生产环境中就利用过 Deny 来强制阻断高危操作，比如禁止删除日志桶。

1.6 综合实战：一次授权排查

说个真实的案例。有一次我们接到告警，说一个开发者的密钥在海外 IP 上被使用了。我当时的排查步骤是这样的：

查到该用户绑定了哪些组和策略（用 IAM 控制台的 Access Advisor 功能）。
发现它属于 developers 组，该组有一条策略允许 s3:* 对所有桶的操作。
立刻撤销该用户的密钥并禁用该组策略，替换为只允许特定桶的读写操作。
后续改进：所有组策略都加上 Condition，比如 IpAddress 限制只能从公司 VPN 访问。

警告：千万不要为了方便而允许 "Action": "*" 或 "Resource": "*"。这等于把家门钥匙挂在门口。我曾经见过一个团队给测试环境开了 "*"，结果测试脚本误删了整个数据库——还好是测试库，但恢复也花了半天。

总结一下，IAM 的四个核心概念不是孤立的。用户是主体，组简化管理，角色提供临时身份，策略定义权限边界。理解它们的关系后，再去做权限设计就会清晰很多。