1. IAM 解决的核心问题

在 AWS 中，所有资源操作最终都会转化为 API 请求。

因此，平台必须回答一个统一的问题：

某一个请求，在当前上下文中，是否被允许执行。

IAM 的职责不是“配置权限”，而是为每一个 API 请求提供一致、可审计、可扩展的授权与鉴权机制。

这也是为什么：

  • 所有服务都会接入 IAM
  • 所有请求都会经过 IAM 鉴权

从工程视角看，IAM 是 AWS 的统一授权与鉴权层。

AWS-IAM 模型

2. Identity 与 Principal 的区分

IAM 中首先需要解决的是： “谁在发起请求”

为此，AWS 明确区分了两个概念：

Identity：可被授权的对象

Identity 是一种静态存在，用于承载权限定义，包括：

  • IAM User
  • IAM Role

Identity 的唯一作用是：

绑定 Permission Policy

Principal：请求的发起者

Principal 是一个运行时概念，代表：

当前 API 请求所处的安全上下文

Principal 可以来自：

  • User 的长期凭据(典型的如持久化AKSK)
  • Role 的临时会话(典型的如临时 AKSK)
  • AWS Service
  • 外部身份系统(典型的如 Apple 账号、Github 账号、Google 账号)

IAM 在评估请求时，实际使用的是 Principal，而不是 Identity 本身。

3. Role 的设计目的

IAM User 是一种*历史兼容设计*，其主要作用是：

  • 人员管理
  • 控制台登录
  • 作为 AssumeRole 的起点

但 Role 才是 AWS 为云环境设计的标准身份模型。

Role 具有以下工程特性：

  • 不包含长期凭据
  • 不能直接使用，必须被 Assume
  • 权限与使用者解耦
  • 生命周期独立于任何实体

Role 的本质是：

一个仅包含授权规则与信任链条的身份容器

4. 为什么不推荐长期凭据

持久化 AKSK 在云环境中存在明显风险：

  • 容易因为硬编码、明文配置而导致泄露
  • 泄露后轮换成本高

因此，AWS 的推荐执行路径是：

1

Identity → AssumeRole → STS → 临时凭据 → API 请求

IAM User 不应该直接持有长期凭据，除非在以下几种特殊场景：

  • 紧急访问手段
  • 人工操作入口
  • 初始运维身份，而非运行时身份
QQ_1768202918951 Clipboard_Screenshot_1768202947 Clipboard_Screenshot_1768202993

5. Policy 是授权规则语言

IAM Policy 并不是配置文件，而是一种声明式授权规则。

每一次请求都会被拆解为四个维度：

  • Principal
  • Action
  • Resource
  • Condition

IAM 的评估逻辑并不关心“意图”，只关心：

在当前上下文下，是否存在明确允许的规则。

6. STS 的作用边界

STS 并不负责授权判断，它的职责是：

基于既有信任关系，签发受限、临时的身份凭据。

STS 解决的工程问题是：

  • 身份的动态生成
  • 跨账号信任
  • 外部身份接入
  • 凭据生命周期控制

STS 的输出不是权限，而是：

可被 IAM 评估的临时 Principal

7. 小结

从工程角度看，AWS IAM 的设计核心可以归纳为：

  1. 统一授权模型
  2. 统一行为鉴权
  3. 身份与凭据解耦
  4. 运行时身份优先于静态身份

Role 和 STS 是这一设计目标的直接产物。