mrk336/Breaking-AWS-IAM-Trust-Boundaries
GitHub: mrk336/Breaking-AWS-IAM-Trust-Boundaries
该研究报告分析了 AWS IAM 信任策略条件评估缺陷导致的隐蔽权限提升风险，并提供检测策略与加固方案。
Stars: 0 | Forks: 0
# 突破 AWS IAM 信任边界
### 信任策略条件设计中的安全风险
**作者：** Mark Mallia
**关注领域：** AWS IAM · 信任策略 · 跨账号访问 · 检测工程 · CI/CD 防护栏
## 执行摘要
AWS Identity and Access Management (IAM) 信任策略定义了谁可以跨账号和服务担任角色。在成熟的多账号 AWS 环境中，这些策略实际上成为了真正的访问控制平面。
一个反复出现的问题不是 AWS 配置错误，而是对 IAM 信任策略条件在实际中如何运作的误解——尤其是在以下几个方面：
- `StringEqualsIfExists`
- `aws:SourceIdentity`
- `aws:PrincipalOrgID`
- 宽泛的 Principal，例如 `:root`
这些模式在设计审查期间通常看起来很安全，但在 IAM 评估语义下的行为却截然不同，从而导致意外的信任暴露和横向移动机会。
本文探讨了：
- 常见的信任策略设计弱点
- 攻击者如何滥用脆弱的信任假设
- 使用 CloudTrail 和 SIEM 工具的检测策略
- 使用 policy-as-code 的 CI/CD 防护栏
# 1. 为什么 IAM 信任策略很重要
在 AWS 中，很少直接授予访问权限。相反，访问权限是通过以下方式调解的：
- `sts:AssumeRole`
- 跨账号角色链
- 联合身份提供商 (SAML/OIDC)
- CI/CD 服务角色
- 服务到服务的信任关系
随着环境规模的扩大，信任策略定义了谁甚至被允许进入特权执行上下文。
单个薄弱的信任关系就可以绕过原本设计良好的最小权限原则。
# 2. 常见信任策略弱点
## 2.1 滥用 `IfExists` 条件
示例：
```
{
"Condition": {
"StringEqualsIfExists": {
"aws:SourceIdentity": "approved-session"
}
}
}
```
### 为什么这很危险
`IfExists` 意味着只有在键存在时才会评估该条件。
如果键不存在，强制执行可能不会按预期进行，从而在预期的安全设计和 IAM 评估行为之间造成差距。
### 更安全的替代方案
```
{
"Condition": {
"StringEquals": {
"aws:SourceIdentity": "approved-session"
}
}
}
```
## 2.2 宽泛的 Principal 信任 (`:root`)
示例：
```
{
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
}
}
```
### 为什么这很危险
这会信任账号中的**每一个身份**，包括：
- IAM 用户
- IAM 角色
- 联合身份
实际上，信任决策被完全委托给了另一个 AWS 账号。
### 更安全的替代方案
```
{
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/DeployRole",
"arn:aws:iam::987654321098:role/CICDRole"
]
}
}
```
## 2.3 过度依赖 `aws:PrincipalOrgID`
示例：
```
{
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-abc123"
}
}
}
```
### 为什么这不够充分
虽然很有用，但它**不能**：
- 验证组织内部的身份完整性
- 防止被盗账号的滥用
- 替代显式的角色级信任设计
# 3. 薄弱信任策略示例
```
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEqualsIfExists": {
"aws:SourceIdentity": "approved-session"
}
}
}
```
### 关键问题
- 信任整个 AWS 账号
- 使用可选的条件强制执行
- 薄弱的信任边界定义
- 如果账号被盗用，会引发横向移动
# 4. 强化信任策略示例
```
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/DeployRole",
"arn:aws:iam::987654321098:role/CICDRole"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-abc123",
"aws:SourceIdentity": "approved-session"
}
}
}
```
### 改进之处
- 用显式的角色级信任代替全账号范围的信任
- 强制条件评估
- 减少横向移动攻击面
- 更强的角色担任可审计性
# 5. 攻击路径示例
1. 在低信任 AWS 账号中发生初始入侵
2. 攻击者枚举 IAM 角色和信任关系
3. 识别出跨账号角色
4. 针对特权角色使用 `sts:AssumeRole`
5. 薄弱的信任策略允许提权
6. 攻击者扩展到生产环境
由于 `AssumeRole` 是原生的 AWS API，此活动通常会混入正常的操作行为中。
# 6. 检测机会
## 6.1 CloudTrail 监控信号
关键指标：
- 首次角色担任
- 跨账号 `AssumeRole`
- 缺失或异常的 `aws:SourceIdentity`
- 异常的会话频率或持续时间
- 新的账号间信任模式
## 6.2 检测查询示例 (Athena)
```
SELECT
eventTime,
userIdentity.arn AS assumer,
requestParameters.roleArn,
sourceIPAddress
FROM cloudtrail_logs
WHERE eventName = 'AssumeRole'
AND requestParameters.roleArn LIKE '%DeployRole%'
AND userIdentity.accountId != '123456789012';
```
## 6.3 首次角色担任检测
```
SELECT *
FROM cloudtrail_logs t1
WHERE eventName = 'AssumeRole'
AND NOT EXISTS (
SELECT 1
FROM cloudtrail_logs t2
WHERE t2.userIdentity.arn = t1.userIdentity.arn
AND t2.requestParameters.roleArn = t1.requestParameters.roleArn
AND t2.eventTime < t1.eventTime
);
```
# 7. CI/CD 防护栏 (Policy-as-Code)
IAM 信任策略应该在**部署之前**进行验证，而不是在事件发生之后。
### GitHub Actions 示例
```
name: iam-trust-policy-check
on:
pull_request:
jobs:
validate:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Validate IAM Trust Policies
run: |
./scripts/validate_trust_policies.sh
```
# 8. 具体控制措施映射 (DORA · PSD2 · ISO 27001)
薄弱或评估不当的 IAM 信任策略直接破坏了金融和云安全框架中几项强制性的控制措施：
DORA (数字运营韧性法案)
第 9(2)(d) 条 – 要求强大的访问控制和身份治理；宽泛的 Principal 和可选的条件违反了最小权限原则的期望。
第 10(4) 条 – 要求受控和经过验证的变更；CI/CD 信任策略防护栏直接支持了这一要求。
第 15(1) 条 – 要求全面的日志记录和监控；基于 CloudTrail 的跨账号角色担任检测与此相符。
第 17(1) 条 – 第三方风险管理；信任整个 AWS 账号 (:root) 违反了要求的信任边界控制。
PSD2 (支付服务指令 2)
SCA (RTS 第 4-5 条) – 强客户认证依赖于身份完整性；评估不当的信任条件会削弱身份保证。
RTS 第 22 条 – 要求安全的通信和会话完整性；隐式的跨账号信任破坏了通道隔离。
第 95(1) 条 – 运营和安全管理风险；最小权限 IAM 和显式 Principal 是必需的安全保障措施。
ISO/IEC 27001:2022
A.5.15 – 访问控制 – 显式 Principal 和强制性条件强制执行最小权限原则并防止未经授权的角色担任。
A.5.23 – 云服务中的信息安全 – 信任边界设计是核心的云控制措施；宽泛的 Principal 违反了这一要求。
A.8.16 – 监控活动 – CloudTrail 检测满足了持续监控的义务。
A.8.28 – 安全编码 – CI/CD 中的 policy-as-code 验证符合安全开发生命周期的期望。
# 结论
AWS IAM 中最大的风险通常不是软件漏洞，而是对信任关系在实际中如何运作的误解。
定期审查信任策略、验证假设并监控角色担任活动的组织，在防止权限提升和跨账号滥用方面处于更有利的位置。
身份仍然是云的控制平面。
每一个信任关系都应得到与其所保护的资源相同程度的审查。
## 道德使用提醒
本研究**仅出于防御性安全、教育和授权测试目的**提供。
在未经明确书面许可的情况下，**不要**将这些技术用于任何系统或环境。
未经授权访问计算机系统是非法且不道德的。
标签：AWS IAM, C语言, 协议分析, 多线程, 权限提升, 漏洞分析, 路径探测