securing-aws-iam-permissions

# 保护 AWS IAM 权限

## 适用场景

- 接入需要范围化 IAM 策略的新 AWS 账户或工作负载时
- IAM Access Analyzer 报告过度宽松的策略或未使用的权限时
- 准备需要最小权限证据的合规审计（SOC 2、PCI-DSS）时
- 从长期访问密钥迁移到基于角色的短期凭据时
- 修复 AWS Security Hub 中与 IAM 错误配置相关的发现时

**不适用于**：Azure AD 或 Google Cloud IAM 配置、应用层授权逻辑，或联合身份（Federated Identity）提供商设置（参见 managing-cloud-identity-with-okta）。

## 前置条件

- 具有管理员访问权限或 IAM:FullAccess 权限的 AWS 账户
- 已安装 AWS CLI v2 并配置命名配置文件
- 已启用 AWS CloudTrail 并保留至少 90 天的 API 活动历史
- 熟悉基于 JSON 的 IAM 策略语法和 ARN 资源表示法

## 工作流程

### 步骤 1：清点现有 IAM 实体和策略

使用 AWS CLI 和 IAM 凭据报告生成所有 IAM 用户、角色、组和附加策略的完整清单。识别具有控制台访问、程序化访问密钥及其最近使用时间戳的账户。

```bash
# 生成 IAM 凭据报告
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > iam-report.csv

# 列出所有 IAM 角色及其附加的策略
aws iam list-roles --query 'Roles[*].[RoleName,Arn,CreateDate]' --output table

# 查找访问密钥超过 90 天的用户
aws iam list-users --query 'Users[*].UserName' --output text | while read user; do
  aws iam list-access-keys --user-name "$user" \
    --query "AccessKeyMetadata[?CreateDate<='$(date -d '-90 days' +%Y-%m-%d)'].[UserName,AccessKeyId,Status,CreateDate]" \
    --output table
done
```

### 步骤 2：启用并分析 IAM Access Analyzer 发现

在组织或账户级别激活 IAM Access Analyzer，识别外部共享的资源，并根据 CloudTrail 活动生成最小权限策略建议。

```bash
# 为账户创建 Access Analyzer
aws accessanalyzer create-analyzer \
  --analyzer-name account-analyzer \
  --type ACCOUNT

# 列出外部访问的活跃发现
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/account-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

# 根据特定角色的 CloudTrail 活动生成策略
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::123456789012:role/AppRole",
    "cloudTrailDetails": {
      "trailArn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/management-trail",
      "startTime": "2025-01-01T00:00:00Z",
      "endTime": "2025-03-01T00:00:00Z"
    }
  }'
```

### 步骤 3：将策略范围限定到特定资源和条件

将通配符资源 ARN 替换为具体资源标识符。添加 IAM 策略条件，用于 MFA 强制执行、源 IP 限制和基于时间的访问窗口。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::production-data-bucket",
        "arn:aws:s3:::production-data-bucket/*"
      ],
      "Condition": {
        "Bool": {"aws:MultiFactorAuthPresent": "true"},
        "IpAddress": {"aws:SourceIp": "10.0.0.0/8"},
        "DateGreaterThan": {"aws:CurrentTime": "2025-01-01T00:00:00Z"}
      }
    }
  ]
}
```

### 步骤 4：实施权限边界

为 IAM 角色和用户附加权限边界（Permission Boundary），定义实体可接收的最大权限范围，即使管理员附加了过度宽松的策略，也能防止权限提升。

```bash
# 创建权限边界策略
aws iam create-policy \
  --policy-name DeveloperPermissionBoundary \
  --policy-document file://developer-boundary.json

# 将边界附加到 IAM 角色
aws iam put-role-permissions-boundary \
  --role-name DeveloperRole \
  --permissions-boundary "arn:aws:iam::123456789012:policy/DeveloperPermissionBoundary"
```

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCommonServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*",
        "cloudwatch:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyIAMChanges",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}
```

### 步骤 5：强制执行 MFA 并消除长期凭据

要求所有访问 AWS 控制台和 CLI 的人工用户使用 MFA。将工作负载从 IAM 用户访问密钥迁移到通过 STS AssumeRole 获取临时凭据的 IAM 角色。

```bash
# 通过 SCP 在组织级别强制执行 MFA
aws organizations create-policy \
  --name RequireMFA \
  --type SERVICE_CONTROL_POLICY \
  --content '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "DenyAllExceptMFA",
        "Effect": "Deny",
        "NotAction": [
          "iam:CreateVirtualMFADevice",
          "iam:EnableMFADevice",
          "iam:ListMFADevices",
          "iam:ResyncMFADevice",
          "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
          "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
        }
      }
    ]
  }'

# 停用未使用的访问密钥
aws iam update-access-key --user-name old-user --access-key-id AKIAEXAMPLE --status Inactive
```

### 步骤 6：自动化持续 IAM 监控

部署 AWS Config 规则和 Security Hub 控制，持续评估 IAM 安全态势。设置 EventBridge 规则，对高风险 IAM 变更（如创建新的 Root 访问密钥或修改策略）发出告警。

```bash
# 启用 IAM 密码策略的 AWS Config 规则
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "iam-password-policy",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "IAM_PASSWORD_POLICY"
    },
    "InputParameters": "{\"RequireUppercaseCharacters\":\"true\",\"RequireLowercaseCharacters\":\"true\",\"RequireSymbols\":\"true\",\"RequireNumbers\":\"true\",\"MinimumPasswordLength\":\"14\",\"MaxPasswordAge\":\"90\"}"
  }'

# EventBridge 规则检测 Root 账户使用情况
aws events put-rule \
  --name DetectRootUsage \
  --event-pattern '{
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "userIdentity": {"type": ["Root"]}
    }
  }'
```

## 核心概念

| 术语 | 定义 |
|------|------|
| 最小权限（Least Privilege） | 仅授予身份执行其功能所需的最低权限 |
| 权限边界（Permission Boundary） | 高级 IAM 功能，设置实体可拥有的最大权限，不受附加策略影响 |
| IAM Access Analyzer | 使用自动推理识别外部共享资源并根据 CloudTrail 活动生成最小权限策略的 AWS 服务 |
| 服务控制策略（SCP） | 在 AWS Organizations 的所有账户中设置权限护栏的组织级别策略 |
| AssumeRole | STS 操作，返回用于跨账户或服务间访问的临时安全凭据 |
| 凭据报告（Credential Report） | AWS 生成的 CSV 文件，列出所有 IAM 用户、访问密钥、MFA 状态和最近活动时间戳 |
| 策略条件（Policy Condition） | IAM 策略中限制权限适用时间和方式的约束条件，例如 MFA 要求或 IP 范围限制 |
| 联合身份（Identity Federation） | 允许外部身份提供商无需创建 IAM 用户即可授予临时 AWS 访问权限 |

## 工具与系统

- **AWS IAM Access Analyzer**：从 CloudTrail 活动生成最小权限策略，识别与外部实体共享的资源
- **AWS Config**：根据托管和自定义规则持续评估 IAM 配置合规性
- **AWS Security Hub**：将来自 Access Analyzer、Config 和第三方工具的 IAM 安全发现汇总到统一仪表板
- **IAM Policy Simulator**：在部署前通过模拟 API 调用测试 IAM 策略效果
- **Prowler**：开源 AWS 安全评估工具，运行 300+ 项检查，包括 IAM 最佳实践和 CIS Benchmark 控制

## 常见场景

### 场景：开发者角色过度授权了 AdministratorAccess

**场景背景**：初创公司在早期开发阶段为了效率，为所有开发者角色附加了 AWS 管理的 AdministratorAccess 策略。安全审计发现 15 个角色具有完全账户访问权限，而开发者实际只使用 S3、Lambda 和 DynamoDB。

**方法**：
1. 启用 IAM Access Analyzer，根据每个角色 90 天的 CloudTrail 数据生成策略建议
2. 创建仅允许访问各团队实际使用的特定 S3 存储桶、Lambda 函数和 DynamoDB 表的范围化策略
3. 附加拒绝 IAM、Organizations 和计费操作的权限边界
4. 在并行角色中部署新策略并通过 CloudTrail 监控后，再替换原始角色
5. 移除 AdministratorAccess 并轮换所有访问密钥

**常见陷阱**：未经并行测试阶段直接替换策略会导致服务中断。忘记将 Lambda:InvokeFunction 限定到特定函数 ARN 会留下横向移动路径。

### 场景：跨多个服务轮换受损访问密钥

**场景背景**：在公开 GitHub 仓库中发现一个访问密钥。该密钥属于在三个 AWS 账户中具有 S3 和 EC2 权限的 IAM 用户。

**方法**：
1. 立即使用 `aws iam update-access-key --status Inactive` 停用受损密钥
2. 检查 CloudTrail 日志，审查过去 30 天内使用受损密钥进行的所有 API 调用
3. 为用户创建新访问密钥，并更新所有依赖的服务和 CI/CD 流水线
4. 确认所有服务使用新凭据后，删除受损密钥
5. 将工作负载迁移到使用 IAM 角色和 STS 临时凭据，防止未来密钥泄露

**常见陷阱**：在停用密钥前直接删除会阻碍对哪些服务依赖它的取证分析。未检查所有三个账户的未授权活动会留下潜在后门未被发现。

## 输出格式

```
IAM 安全评估报告
==============================
账户 ID: 123456789012
评估日期: 2025-02-23
分析器: IAM Access Analyzer + Prowler v4.3

严重发现:
[C-001] Root 账户有活跃访问密钥
  - 资源: arn:aws:iam::123456789012:root
  - 修复建议: 删除 Root 访问密钥，为 Root 启用 MFA
  - CIS Benchmark: 1.4（确保不存在 Root 账户访问密钥）

[C-002] IAM 用户 'deploy-bot' 具有 AdministratorAccess 且无 MFA
  - 资源: arn:aws:iam::123456789012:user/deploy-bot
  - 最近活动: 2025-02-20
  - 修复建议: 替换为 IAM 角色，强制 MFA 条件

高危发现:
[H-001] 3 条 IAM 策略对敏感操作使用通配符资源 "*"
  - 策略: DevPolicy, CIPolicy, LegacyAdminPolicy
  - 修复建议: 使用 Access Analyzer 将资源限定到特定 ARN

[H-002] 检测到 7 个超过 90 天的访问密钥
  - 用户: svc-backup, svc-monitoring, dev-alice, dev-bob, ...
  - 修复建议: 轮换密钥，迁移到基于角色的访问

摘要:
  总发现数: 14
  严重: 2 | 高危: 4 | 中危: 5 | 低危: 3
  合规分数: 62%（CIS AWS Foundations Benchmark v3.0）
```