云身份与权限管理：IAM如何成为云安全的第一战场

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

2386 字

7 分钟

云身份与权限管理：IAM如何成为云安全的第一战场

2025-03-08

云安全攻防技术

云安全

/

零信任

/

安全

2023年，某安全团队在AWS环境中审计时发现：一个Lambda函数的执行角色被授予了iam:PassRole + lambda:CreateFunction权限。这两个权限单独看都不危险，但组合在一起，攻击者可以创建一个新Lambda函数并赋予它管理员角色——从低权限提升到集群管理员，只用了两次API调用。

这不是个例。云安全事件统计显示，超过70%的云安全breach与IAM配置错误直接相关——过度宽松的策略、长期有效的访问密钥、未轮换的凭据、特权Service Account。在云环境中，身份就是新的边界（Identity is the new perimeter），而IAM就是这个边界上的城门。

本文将从云IAM的信任模型出发，分析三大云平台的IAM攻击面，解析权限提升的经典路径，并构建云身份的纵深防御体系。

一、前置知识：云身份的信任模型#

1.1 传统网络边界 vs 云身份边界#

graph TB subgraph "传统模型：网络边界" A1["防火墙"] --> B1["VPN接入"] B1 --> C1["内网 = 可信"] C1 --> D1["身份验证仅限登录"] end subgraph "云模型：身份边界" A2["IAM策略"] --> B2["持续验证"] B2 --> C2["每个API调用独立鉴权"] C2 --> D2["身份 = 唯一信任锚点"] end style C1 fill:#FFD700 style D2 fill:#90EE90

传统网络中，进入内网就基本可信。云环境中，每个API调用都需要独立的身份验证和授权——没有”内网”的概念，只有”有权限的API调用”和”无权限的API调用”。

这意味着：

网络边界消失了，但身份边界变得至关重要
IAM配置错误等于城墙开了一个洞
凭据泄露等于城门钥匙被盗

1.2 云IAM的核心概念#

1
cloud_iam_core:
2
  # 身份主体（Who）
3
  principals:
4
    - "用户（User）: 人类操作者"
5
    - "组（Group）: 用户的集合"
6
    - "角色（Role）: 临时身份，可被担任"
7
    - "Service Account: 服务/工作负载的身份"
8

9
  # 权限策略（What）
10
  policies:
11
    - "允许/拒绝（Allow/Deny）"
12
    - "资源范围（Resource ARN）"
13
    - "条件约束（Condition: IP、时间、MFA等）"
14
    - "显式拒绝优先于允许"
15

16
  # 认证方式（How）
17
  authentication:
18
    - "长期凭据: Access Key / Service Account Key"
19
    - "临时凭据: STS AssumeRole / OIDC / SAML"
20
    - "联合身份: IdP → 云IAM"
21
    - "实例元数据: IMDS自动获取临时凭据"

1.3 临时凭据 vs 长期凭据#

这是云IAM安全最重要的区分：

维度	长期凭据	临时凭据
有效期	永不过期（直到手动轮换）	数分钟到数小时自动过期
示例	AWS Access Key、GCP Service Account Key	STS Session Token、OIDC Token
泄露影响	持续有效，攻击者可长期使用	自动失效，窗口有限
管理成本	需要轮换流程	无需手动轮换
推荐程度	避免使用	推荐使用

核心原则：能用临时凭据，就绝不用长期凭据。

1.4 当前态势：IAM配置错误是云安全第一大威胁#

graph TB subgraph "2024-2026年云安全事件根因" A1["IAM配置错误: 72%"] --> A2["过度授权 长期凭据 未轮换密钥"] B1["网络配置错误: 15%"] --> B2["公开S3桶 暴露管理端口"] C1["应用漏洞: 10%"] --> C2["API未认证 注入攻击"] D1["其他: 3%"] --> D2["社工/零日/供应链"] end style A1 fill:#FF6B6B

二、三大云平台IAM攻击面#

2.1 AWS IAM#

AWS IAM是最成熟也最复杂的云身份系统——这种复杂性本身就是攻击面：

1
aws_iam_attack_surface:
2
  # 凭据类型
3
  credentials:
4
    - "Access Key ID + Secret Access Key: 长期，永不过期"
5
    - "STS Session Token: 临时，最长12小时"
6
    - "IAM Role信任策略: 跨账户/跨服务授权"
7
    - "Instance Profile: EC2自动获取Role凭据"
8

9
  # 常见配置错误
10
  common_misconfigurations:
11
    - "Access Key泄露在GitHub/环境变量/日志中"
12
    - "Root账户未启用MFA"
13
    - "IAM策略使用通配符: Resource: '*'"
14
    - "过度授权: 授予不需要的权限"
15
    - "长期Access Key未轮换"
16
    - "S3桶策略允许公开访问"
17
    - "EC2 Instance Role权限过大"

AWS IAM的权限提升路径是最丰富的——Bishop Fox的”Iam Privilege Escalation”研究列举了20+种单步提权路径：

提权手法	所需权限	原理
`iam:CreateAccessKey`	为其他用户创建Access Key	直接获得目标用户的长期凭据
`iam:PassRole` + `lambda:CreateFunction`	传递角色 + 创建Lambda	创建新函数赋予高权限角色
`iam:AttachUserPolicy`	为用户附加策略	给自己附加AdministratorAccess
`sts:AssumeRole`	担任高权限角色	如果角色信任策略允许
`ec2:RunInstances` + `iam:PassRole`	启动EC2 + 传递角色	启动新实例获得高权限角色凭据
`iam:CreateRole` + `iam:AttachRolePolicy`	创建角色 + 附加策略	创建管理员角色并附加
`ssm:StartSession`	SSM Session Manager	连接到EC2实例（无需SSH密钥）

2.2 GCP IAM#

GCP IAM的设计理念与AWS不同——更强调组织层级和继承：

1
gcp_iam_attack_surface:
2
  # 组织层级
3
  hierarchy:
4
    - "Organization → Folder → Project → Resource"
5
    - "策略从上到下继承，IAM绑定可覆盖"
6
    - "Organization Admin = 整个组织的上帝权限"
7

8
  # Service Account
9
  service_accounts:
10
    - "SA Key: 长期JSON密钥文件（危险）"
11
    - "Workload Identity: K8s Pod绑定SA（推荐）"
12
    - "SA Impersonation: 允许其他身份充当SA"
13

14
  # 常见配置错误
15
  common_misconfigurations:
16
    - "SA Key下载到本地且未轮换"
17
    - "项目级Editor/Owner角色过度授权"
18
    - "Compute默认SA权限过大（含storage读写）"
19
    - "Workload Identity绑定范围过宽"
20
    - "Organization策略未设置约束"

GCP特有的攻击路径：

2.3 Azure RBAC + Entra ID#

Azure的身份系统基于Entra ID（原Azure AD），与K8s RBAC结合形成双重授权：

1
azure_iam_attack_surface:
2
  # Entra ID（原Azure AD）
3
  entra_id:
4
    - "用户 + 组 + 应用注册 + Service Principal"
5
    - "条件访问策略（Conditional Access）"
6
    - "Privileged Identity Management（PIM）"
7

8
  # Azure RBAC
9
  rbac:
10
    - "Owner/Contributor/Reader + 自定义角色"
11
    - "范围: 管理组/订阅/资源组/资源"
12
    - "经典管理员 vs RBAC角色"
13

14
  # 常见配置错误
15
  common_misconfigurations:
16
    - "Service Principal密码/证书未轮换"
17
    - "Subscription级Owner/Contributor过度授权"
18
    - "托管身份(Managed Identity)权限过大"
19
    - "条件访问策略未覆盖所有应用"
20
    - "PIM未启用，永久管理员权限"

三、实例元数据服务(IMDS)：从容器到云的桥梁#

3.1 IMDS的工作原理#

实例元数据服务（Instance Metadata Service，IMDS）是云环境中的”特洛伊木马”——EC2/Pod/VM可以通过HTTP请求169.254.169.254自动获取自己的IAM临时凭据：

graph LR A["EC2/VM/Pod"] -->|"GET 169.254.169.254 /latest/meta-data/iam/security-credentials/"| B["IMDS"] B -->|"返回临时Access Key + Session Token"| C["IAM Role凭据"] style A fill:#87CEEB style B fill:#FFD700 style C fill:#FF6B6B

这意味着：任何在EC2/Pod上执行的代码，都可以通过IMDS获取该实例的IAM角色凭据。这包括：

容器逃逸后在宿主机上执行的代码
应用RCE漏洞在Pod内执行的代码
SSRF漏洞发送请求到元数据服务

3.2 SSRF → IMDS → 云接管的攻击链#

graph LR A["Web应用SSRF漏洞"] -->|"请求169.254.169.254"| B["获取IAM临时凭据"] B -->|"使用AWS CLI/GCP API"| C["云资源操作"] C --> D["S3数据窃取"] C --> E["EC2启动新实例"] C --> F["IAM权限提升"] style A fill:#FF6B6B style B fill:#FFA500 style C fill:#FFD700

Capital One 2019年数据泄露事件就是这个攻击链的典型：攻击者利用WAF配置错误的SSRF，通过IMDS获取EC2角色的临时凭据，然后用这些凭据访问了S3中1亿+客户的信用卡数据。

3.3 IMDSv2：纵深防御的进步#

AWS在2019年推出了IMDSv2——要求使用PUT请求+Token获取元数据，而非简单的GET：

1
imds_comparison:
2
  IMDSv1:
3
    method: "GET"
4
    protection: "无"
5
    exploit: "SSRF可直接获取凭据"
6

7
  IMDSv2:
8
    method: "PUT (获取Token) + GET (携带Token)"
9
    protection:
10
      - "Token有效期最长6小时"
11
      - "需要两步请求，SSRF难以利用"
12
      - "跳数限制(Hop Limit)防止容器内访问"
13
    recommendation: "强制所有EC2使用IMDSv2"

1
# IMDSv2获取元数据的两步过程
2
# 第1步: 获取Token
3
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
4

5
# 第2步: 使用Token获取IAM凭据
6
curl -H "X-aws-ec2-metadata-token: $TOKEN" "http://169.254.169.254/latest/meta-data/iam/security-credentials/"

关键：设置HttpTokens=required强制使用IMDSv2，并设置HttpPutResponseHopLimit=1阻止从容器内访问宿主机元数据。

四、权限提升深度分析#

4.1 AWS IAM权限提升矩阵#

Bishop Fox的研究将AWS IAM提权分为三类：

1
privilege_escalation_categories:
2
  # 类别1: 创建新凭据
3
  credential_creation:
4
    - "iam:CreateAccessKey → 为其他用户创建长期凭据"
5
    - "iam:CreateLoginProfile → 为其他用户设置密码"
6
    - "sts:AssumeRole → 担任高权限角色"
7

8
  # 类别2: 修改策略
9
  policy_modification:
10
    - "iam:AttachUserPolicy/AttachRolePolicy → 附加管理员策略"
11
    - "iam:PutUserPolicy/PutRolePolicy → 内联策略写入"
12
    - "iam:CreatePolicy + iam:AttachPolicy → 创建并附加自定义策略"
13

14
  # 类别3: 委托授权（最隐蔽）
15
  delegation:
16
    - "iam:PassRole + lambda:CreateFunction → 创建Lambda使用高权限角色"
17
    - "iam:PassRole + ec2:RunInstances → 启动EC2使用高权限角色"
18
    - "iam:PassRole + cloudformation:CreateStack → 通过Cf使用高权限角色"

4.2 GCP Service Account提权#

GCP的提权路径围绕Service Account展开：

graph TB A["攻击者拥有低权限SA"] --> B{"可用权限"} B -->|"iam.serviceAccounts.actAs"| C["充当高权限SA"] C --> D["使用高权限SA访问资源"] B -->|"compute.instances.create + iam.serviceAccounts.actAs"| E["创建VM使用高权限SA"] E --> F["SSH进VM获取SA Token"] B -->|"cloudfunctions.functions.create + iam.serviceAccounts.actAs"| G["创建函数使用高权限SA"] G --> H["执行函数获取SA权限"] B -->|"iam.serviceAccountKeys.create"| I["为高权限SA创建新Key"] I --> J["下载Key长期使用"]

4.3 跨账户/跨项目攻击#

云环境的另一个独特威胁是跨账户攻击——一个被入侵的账户可以成为攻击其他账户的跳板：

1
cross_account_attack:
2
  # AWS跨账户
3
  aws:
4
    - "角色信任策略过于宽松: 允许整个AWS账户担任"
5
    - "S3桶策略允许其他账户读写"
6
    - "KMS Key策略允许其他账户使用"
7

8
  # GCP跨项目
9
  gcp:
10
    - "SA在多个项目有IAM绑定"
11
    - "共享VPC中SA可跨项目访问"
12
    - "Organization级IAM绑定影响所有项目"
13

14
  # Azure跨租户
15
  azure:
16
    - "多租户应用注册"
17
    - "Guest用户权限"
18
    - "跨订阅管理组继承"

五、纵深防御体系#

5.1 IAM安全框架#

graph TB subgraph "凭据管理" A1["消除长期凭据"] A2["强制临时凭据"] A3["IMDSv2 + Hop Limit"] end subgraph "权限管理" B1["最小权限策略"] B2["权限边界"] B3["条件约束"] B4["定期审计"] end subgraph "监控与检测" C1["CloudTrail/Config"] C2["异常API调用检测"] C3["未授权访问告警"] end subgraph "响应" D1["凭据轮换"] D2["权限撤销"] D3["账户隔离"] end

5.2 凭据安全最佳实践#

1
credential_security:
2
  # AWS
3
  aws:
4
    - "禁用Access Key: 尽可能使用IAM Role代替"
5
    - "必须使用Access Key时: 启用自动轮换"
6
    - "EC2使用IMDSv2: HttpTokens=required, HopLimit=1"
7
    - "Lambda使用执行角色: 避免硬编码Access Key"
8
    - "EKS使用IRSA: IAM Roles for Service Accounts"
9
    - "Root账户: 启用MFA, 禁用Access Key, 创建IAM管理员用户"
10

11
  # GCP
12
  gcp:
13
    - "禁用SA Key下载: 使用Workload Identity代替"
14
    - "Compute使用默认SA + 最小权限: 不使用storage-full"
15
    - "GKE使用Workload Identity: 不挂载默认SA"
16
    - "Organization策略: 禁止SA Key创建"
17
    - "短期Token: 使用STS/Workload Identity自动轮换"
18

19
  # Azure
20
  azure:
21
    - "使用Managed Identity: 代替Service Principal"
22
    - "启用PIM: Just-In-Time特权访问"
23
    - "条件访问策略: 要求MFA/IP限制"
24
    - "AKS使用AAD Pod Identity: 不使用SP Key"
25
    - "定期轮换SP密码/证书"

5.3 最小权限策略#

1
least_privilege:
2
  # 原则
3
  principles:
4
    - "只授予实际需要的权限（而非'可能需要的'）"
5
    - "使用权限边界（Permissions Boundary）限制最大权限"
6
    - "使用条件约束（Condition）限制权限适用范围"
7
    - "定期审计：移除90天未使用的权限"
8

9
  # AWS权限边界
10
  aws_permissions_boundary:
11
    - "为所有IAM用户/角色设置Permissions Boundary"
12
    - "Boundary定义最大权限范围"
13
    - "即使策略授予更多权限，也受Boundary约束"
14
    - "示例: Boundary禁止iam:*和organizations:*操作"
15

16
  # GCP组织策略
17
  gcp_org_policy:
18
    - "constraints/iam.disableServiceAccountKeyCreation"
19
    - "constraints/iam.allowedPolicyMemberDomains"
20
    - "constraints/compute.requireOsLogin"
21
    - "constraints/iam.serviceAccountKeyMaxExpiration"
22

23
  # Azure条件访问
24
  azure_conditional_access:
25
    - "要求MFA: 所有特权角色操作"
26
    - "IP限制: 仅允许企业网络"
27
    - "设备合规: 要求托管设备"
28
    - "会话限制: 缩短特权会话时长"

5.4 IAM审计与权限分析工具#

1
iam_audit_tools:
2
  # AWS
3
  aws:
4
    - name: IAM Access Analyzer
5
      features: ["未使用的权限检测", "跨账户访问分析", "S3桶公开检测"]
6

7
    - name: CloudTrail + Athena
8
      features: ["API调用审计", "异常行为查询", "权限使用分析"]
9

10
    - name: Prowler
11
      features: ["CIS Benchmark检查", "IAM配置审计", "过度授权检测"]
12

13
    - name: pmapper (Principal Mapper)
14
      features: ["IAM权限图构建", "权限提升路径发现", "等价权限分析"]
15

16
  # GCP
17
  gcp:
18
    - name: IAM Recommender
19
      features: ["权限使用分析", "最小权限建议", "自动缩小权限"]
20

21
    - name: Forseti Security
22
      features: ["IAM策略扫描", "组织策略合规", "跨项目权限审计"]
23

24
  # Azure
25
  azure:
26
    - name: Azure AD Access Reviews
27
      features: ["定期权限审查", "组/角色成员清理", "PIM激活审计"]
28

29
    - name: Azure Policy
30
      features: ["自定义策略合规", "RBAC约束", "托管身份限制"]

5.5 防御层对照表#

防御层	针对威胁	实现方式
临时凭据	长期凭据泄露	STS/Workload Identity/Managed Identity
IMDSv2	SSRF→元数据→凭据	强制IMDSv2 + HopLimit=1
权限边界	权限提升	Permissions Boundary/Org Policy
条件约束	凭据滥用	MFA + IP限制 + 时间限制
最小权限	过度授权	Access Analyzer + Recommender
审计日志	未授权操作	CloudTrail + 异常API检测
定期审查	权限腐化	Access Reviews + 90天未使用权限清理

六、我的思考#

6.1 身份是新的边界，但边界比想象中复杂#

“Identity is the new perimeter”这句话已经说了很多年，但实际落地远比口号复杂。云IAM的权限模型是隐式的——一个主体的最终权限是所有附加策略、继承策略、组织策略的并集，减去显式拒绝。没有人能一眼看穿一个IAM主体到底能做什么。

这就是为什么权限分析工具（pmapper、IAM Access Analyzer）如此重要——人工审计IAM策略几乎是不可能的，必须依赖自动化工具构建权限图、发现提升路径。

6.2 长期凭据是云安全的原罪#

Access Key永不过期、Service Account Key永不过期——这些长期凭据是云安全事件的第一大根因。但完全消除长期凭据在2026年仍然困难——CI/CD流水线、遗留系统、第三方集成都需要长期凭据。

折中方案：为长期凭据设置自动轮换（AWS Access Key轮换、GCP SA Key轮换），并监控凭据使用——90天未使用的Access Key应该被禁用，1天未使用的Access Key突然活跃应该触发告警。

6.3 IMDS是容器逃逸到云接管的桥梁#

上一篇分析了容器逃逸，本文分析了IMDS。两者的组合是最致命的攻击链：容器逃逸 → 宿主机 → IMDS → 云凭据 → 云资源接管。

IMDSv2的Hop Limit是关键的防御措施——设置HttpPutResponseHopLimit=1意味着只有宿主机上的进程可以访问IMDS，容器内的请求因为多了一跳而被拒绝。但这个防御可以被绑定了hostNetwork: true的Pod绕过——所以Pod Security Standards禁止hostNetwork同样是必要的。