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 用户、角色、组和附加策略的完整清单。识别具有控制台访问、程序化访问密钥及其最近使用时间戳的账户。

# 生成 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 活动生成最小权限策略建议。

# 为账户创建 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 限制和基于时间的访问窗口。

{
  "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），定义实体可接收的最大权限范围，即使管理员附加了过度宽松的策略，也能防止权限提升。

# 创建权限边界策略
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"

{
  "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 角色。

# 通过 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 访问密钥或修改策略）发出告警。

# 启用 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）