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

1. IAM 基础概念：定义、核心组件与常见策略结构

各位好，我是老轨。咱们这门课叫「IAM 策略滥用检测实战指南」，第一步当然得把地基打牢。IAM 听起来高大上，说白了就是一把「云上权限锁」。你给谁开了什么门，门后面能拿什么东西，都得用它来管。

  一句话定义：IAM（Identity and Access Management）是云平台中管理用户身份与访问权限的体系，核心目标是「谁（身份）能对什么（资源）做什么（操作），在什么条件下（环境）允许或拒绝」。

1.1 为什么我非要搞明白 IAM？

我记得刚做云安全那年，客户一个 S3 存储桶突然被删了，数据全丢。排查下来发现是某位离职员工的子账号居然还有 AdministratorAccess 策略。你想想看，这种「权限裸奔」的问题，根源就是对 IAM 的理解不够深。所以我个人习惯，每接触一个新账号，第一件事就是摸清它的 IAM 配置，比看啥日志都实在。

1.2 核心组件拆解

IAM 体系里到底有哪些东西？我通常把它分成五块，就像一辆车的五大系统——缺一个就开不动。

组件	英文	人话解释
主体	Principal	谁在发起请求。用户、角色、服务账号、联合身份都算。
资源	Resource	要动什么东西。比如 EC2 实例、RDS 数据库、S3 存储桶都是资源。
动作	Action	执行什么操作。例如 s3:PutObject、ec2:RunInstances。
环境条件	Condition	在什么额外限制下允许操作。比如来源 IP、时间、MFA 状态。
效果	Effect	是 Allow 还是 Deny。Deny 的优先级永远高于 Allow。

这里有个坑我必须提一句：我曾经碰到一个策略，Effect 写了 Allow，但 Condition 里忘了限制 VPC 端点，结果公网上的攻击者也能通过某种方式绕过防火墙。嗯，条件字段非常容易被忽视，但恰恰是策略滥用检测中最值得抠细节的地方。

1.3 常见策略结构长什么样

主流云厂商（AWS、阿里云、华为云、GCP）的策略语法大同小异，基本都是 JSON 格式。我以 AWS IAM 策略为例，给你看一个标准结构：

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

为什么这么写？因为每个 Statement 就是一个「权限声明」。你想想看，如果我把 Action 写成 "Action": "*"，Resource 写成 "Resource": "*"，那这个策略就等于给主体开了超级管理员——这正是策略滥用的典型。

注意：Effect 只有两种值 Allow 和 Deny。Deny 会覆盖所有 Allow，哪怕别的策略明确说 Allow，只要匹配了一条 Deny，请求就会被拒绝。这是 IAM 中「显式拒绝优先」原则，实战中经常用来做安全兜底。

1.4 一张图看懂 IAM 策略核心关系

说了这么多，不如画张图直观点。下面的 SVG 把主体、资源、动作、条件、效果之间的关系串起来了——这张图我平时做安全审计时必用，看一眼就知道策略有没有「超范围」风险。

1.5 策略语句的「骨架」——Version 与 Statement

咱们再看一眼 JSON 结构里最外层的两个字段。Version 一般固定为 "2012-10-17"（AWS 标准），别的云也有自己的版本号，但本质一样。Statement 是个数组，你可以写多个权限声明。

为什么要用数组？我举个例子：你需要让运维人员能启动 EC2（ec2:StartInstances），但不能让他关机（ec2:StopInstances）。那你得写两条 Statement：一条 Allow start，一条 Deny stop。Deny 那条记得把 Resource 写得具体点，别误伤别的操作。

实战技巧：我写策略时，习惯把「最小权限原则」可视化。先写一个 Deny 白名单兜底，再写几个具体的 Allow。这样就算后面 Allow 写漏了，Deny 这个「安」也能兜住。

1.6 条件（Condition）里藏着的猫腻

条件字段是策略中最灵活也最容易被滥用的一环。常见的条件包括：

来源 IP：aws:SourceIp，限制只能从公司 IP 段访问。
请求时间：aws:CurrentTime，限制只能在业务时间操作。
是否启用 MFA：aws:MultiFactorAuthPresent，要求两步验证。
VPC 端点：aws:SourceVpc，防止公网 API 调用。

我遇到过一个诡异的案例——某策略允许 s3:PutObject 到所有桶，但加了一个条件 StringLike 判断用户 IP。结果用户用了一个云上跳板机，IP 正好在允许范围内，攻击者通过这个跳板机上传了恶意脚本。事后分析发现条件里没限制跳板机本身的策略范围。所以，条件不是万能的，必须配合资源边界和角色信任策略一起用。

1.7 资源（Resource）的「通配陷阱」

Resource 字段最常见的写法是 ARN（Amazon Resource Name）或者直接用 "*"。很多团队图省事，上来就给 "Resource": "*"。你想想看，这意味着主体可以对所有资源执行动作——这不就回到「裸奔」状态了吗？

我曾经帮一个客户做策略审计，发现他们一个 Jenkins 角色的策略里 Action 只写了 "ec2:Describe*"，看着很安全。但 Resource 是 "*"，同时另一个 Statement 里写了 "Action": "ec2:RunInstances" 却没有指定标签过滤。结果 Jenkins 被打回后，运维人员直接用它创建了 100 台挖矿实例。说白了，就算 Action 写得再窄，Resource 一放开就可能出大事。

1.8 一张表分清三大常见策略类型

策略类型	绑定对象	典型用途	滥用风险
基于身份的策略	用户、组、角色	给具体人员分配权限	权限过大、离职未回收
基于资源的策略	资源本身（如 S3 桶策略）	控制谁能访问该资源	通配符 *、公开写权限
权限边界	作为角色的最大权限上限	限制角色能获得的最大权限	边界本身太宽丧失效果

这里我补充一句：实战中检测策略滥用，最先看的就是基于资源的策略，因为很多攻击者会利用 S3 桶策略中的 "Principal": "*" 把数据公开出去。嗯，以后咱们讲到具体检测手段时会详细拆解。

1.9 本章核心要点

IAM = 身份 + 访问 + 管理，五组件环环相扣。
策略 JSON 结构：Version、Statement（Effect / Action / Resource / Condition）。
Deny 永远优先于 Allow，这是 IAM 的第一法则。
资源通配符和条件缺失是策略滥用的两个主要入口。