📚 课程目录第2章身份与访问管理（IAM）

身份与访问管理（IAM）：从概念到实战

身份与访问管理，圈里人常叫 IAM。说白了，就是解决「你是谁、你能干什么、你干了什么」这三个问题。我见过太多公司，安全架构看着挺唬人，结果 IAM 一塌糊涂——权限乱飞，账号共享，审计日志形同虚设。嗯，这章咱们就把 IAM 的核心掰开揉碎，讲清楚。

IAM 核心四要素：用户、组、角色、策略

这四个概念，是 IAM 的基石。你想想看，一个系统有成百上千个访问主体，如果每个都单独配权限，那运维同学得疯。所以，我们需要抽象和分层。

用户（User）

用户是最小的身份单元。可以是人，也可以是服务账号。我个人习惯，把用户分为三类：

人类用户：员工、外包、合作伙伴。每个真实的人对应一个唯一 ID。
机器用户：应用程序、微服务、CI/CD 流水线。它们也需要身份，但不需要密码登录。
临时用户：审计、应急响应。用完即销毁，生命周期很短。

注意： 千万不要共享账号！我在项目中遇到过，一个团队共用一个 root 账号，出了问题根本查不到是谁操作的。这是 IAM 的大忌。

组（Group）

组是用户的集合。把权限赋给组，再把用户加到组里。这样管理起来就轻松多了。

举个例子：

# 创建开发组
group: developers
members: alice, bob, charlie

# 创建运维组
group: operators
members: dave, eve

# 权限直接绑在组上
policy: allow-read-logs
  attach-to: operators

这样做的好处是，人员变动时，只需要调整组成员关系，不用改策略。我曾经见过一个公司，每个新员工入职都要手动配十几个权限，离职时又漏删，结果权限越积越多。用组之后，这个问题就解决了。

角色（Role）

角色和组有点像，但更灵活。角色可以跨账号、跨服务使用。在云环境里，角色特别重要。

我习惯这么理解：

组：把人分组，权限跟着组走。
角色：定义一组权限，谁需要谁「扮演」。

比如，一个临时审计员，不需要给他创建永久账号。他只需要临时扮演一个「Auditor」角色，审计完角色就失效。干净利落。

策略（Policy）

策略就是权限规则。它定义了「谁在什么条件下可以对什么资源做什么操作」。策略通常用 JSON 或 YAML 写。

来看一个 AWS IAM 策略的例子：

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

这个策略的意思是：允许来自内网 IP 段的用户，读取 my-bucket 里的所有对象。你看，策略可以很精细，连来源 IP 都能限制。

  核心原则： 策略应该遵循最小权限原则。只给完成工作所需的最小权限。多一个权限都不要给。

IAM 最佳实践：我踩过的坑和总结的经验

这部分是我最想分享的。理论谁都会说，但实战中的坑，只有踩过才知道。

1. 最小权限原则

这个原则听起来简单，做起来难。我见过很多团队，图省事直接给「管理员」权限。结果呢？一个不小心，整个数据库被删了。

我的建议是：

从零开始，只给明确需要的权限。
定期审查权限，回收不再需要的。
使用「拒绝」策略兜底。比如，默认拒绝所有删除操作，只有特定角色才能执行。

2. 使用临时凭证，而不是长期密钥

长期密钥（比如密码、API Key）一旦泄露，危害很大。临时凭证（比如 STS Token）有过期时间，就算泄露，影响也有限。

我曾经在项目里发现，有人把 AWS Access Key 硬编码在代码里，还提交到了 GitHub。幸好发现得早，不然整个云账号都可能被攻破。从那以后，我强制团队使用临时凭证。

3. 启用多因素认证（MFA）

密码太容易被破解了。加上 MFA，安全性提升一个量级。尤其是管理员账号，必须绑定 MFA。

我建议：

所有人类用户启用 MFA。
敏感操作（如删除资源、修改策略）强制 MFA。
使用硬件 MFA 设备，比手机 App 更安全。

4. 权限分离

不要把鸡蛋放在一个篮子里。开发、测试、生产环境的权限要分开。不同团队的权限也要分开。

举个例子：

角色	开发环境	生产环境
开发者	读写权限	只读日志
运维	只读	完全控制
审计	只读	只读

这样就算开发环境被攻破，攻击者也拿不到生产环境的权限。

5. 定期审计和轮换

权限不是一劳永逸的。人员变动、业务调整，权限都需要跟着变。

我建议每季度做一次权限审计：

检查是否有僵尸账号（长期未登录）。
检查是否有过度授权的策略。
轮换所有密钥和证书。

小技巧： 可以用自动化工具来做审计。比如 AWS 的 IAM Access Analyzer，能自动发现哪些权限是「未使用」的。省时省力。

IAM 在云环境中的应用

云环境下的 IAM，和传统 IDC 有很大不同。云厂商提供了丰富的 IAM 服务，但用不好反而会引入新风险。

云 IAM 的核心模型

我画了一张图，帮你理解云 IAM 的整体架构：

你看，整个流程是：用户（人或机器）加入组或扮演角色，组和角色绑定策略，策略控制对资源的访问。所有操作都会被审计日志记录下来。

云 IAM 的常见场景

我挑三个最典型的场景说说：

场景一：跨账号访问

大公司通常有多个云账号（开发、测试、生产）。怎么让运维人员用一个账号访问所有环境？答案是角色。

具体做法：

在中心账号创建用户。
在目标账号创建角色，并信任中心账号。
用户通过切换角色，访问目标账号的资源。

这样，用户只需要记住一个密码，权限由角色控制，审计日志也能追溯到具体用户。

场景二：微服务间认证

微服务之间需要互相调用。怎么保证调用是合法的？

我建议用 Service Account（服务账号）。每个微服务有自己的身份，通过 JWT 或 mTLS 进行认证。云厂商也提供了类似的服务，比如 AWS 的 IAM Roles for Service Accounts（IRSA）。

场景三：临时授权

有时候，需要给外部合作伙伴临时访问权限。比如，让安全团队做渗透测试。

我的做法是：

创建一个临时角色，权限只限于测试范围。
设置角色有效期（比如 7 天）。
测试结束后，立即删除角色。

这样既满足了需求，又控制了风险。

避坑指南： 我曾经在云环境里犯过一个错——给角色绑定了「管理员」策略，想着「反正只是临时用一下」。结果这个角色的密钥泄露了，攻击者用它在云上挖矿，账单多了好几万。从那以后，我坚持「临时角色也要最小权限」。

总结一下

IAM 是安全的基础。用户、组、角色、策略这四个概念，一定要吃透。最佳实践方面，最小权限、临时凭证、MFA、权限分离、定期审计，这五点做到位，基本不会出大问题。云环境下的 IAM，核心是角色和策略的灵活运用。

嗯，这章就到这里。记住，权限管控不是一锤子买卖，而是一个持续优化的过程。