securing-aws-iam-permissions

保护 AWS IAM 权限

何时使用

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

请勿使用于 Azure AD 或 Google Cloud IAM 配置、应用层授权逻辑或联合身份提供商设置（参见 managing-cloud-identity-with-okta）。

前置条件

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

工作流

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

使用 AWS CLI 和 IAM 凭证报告生成所有 IAM 用户、角色、组和所附加策略的全面清单。识别具有控制台访问权限、编程访问密钥的账户及其上次使用时间戳。

# Generate IAM credential report
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > iam-report.csv

# List all IAM roles and their attached policies
aws iam list-roles --query 'Roles[*].[RoleName,Arn,CreateDate]' --output table

# Find users with access keys older than 90 days
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 活动生成最小权限策略建议。

# Create an Access Analyzer for the account
aws accessanalyzer create-analyzer \
  --analyzer-name account-analyzer \
  --type ACCOUNT

# List active findings for external access
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/account-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

# Generate a policy based on CloudTrail activity for a specific role
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 角色和用户，以定义实体可获得的权限最大范围，即使管理员附加了权限过宽的策略，也能防止权限提升。

# Create a permission boundary policy
aws iam create-policy \
  --policy-name DeveloperPermissionBoundary \
  --policy-document file://developer-boundary.json

# Attach the boundary to an IAM role
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 控制台和命令行的人类用户使用 MFA。通过 STS AssumeRole 将工作负载从 IAM 用户访问密钥迁移到具有临时凭证的 IAM 角色。

# Enforce MFA via SCP at the organization level
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"}
        }
      }
    ]
  }'

# Deactivate unused access keys
aws iam update-access-key --user-name old-user --access-key-id AKIAEXAMPLE --status Inactive

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

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

# Enable AWS Config rule for IAM password policy
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 rule to detect root account usage
aws events put-rule \
  --name DetectRootUsage \
  --event-pattern '{
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "userIdentity": {"type": ["Root"]}
    }
  }'

关键概念

术语	定义
最小权限	仅授予身份执行其职能所需的最低权限
权限边界	一种高级 IAM 功能，用于设定实体可拥有的最大权限，无论附加了何种策略
IAM Access Analyzer	AWS 服务，使用自动推理来识别对外共享的资源，并根据 CloudTrail 活动生成最小权限策略
服务控制策略（SCP）	组织级策略，为 AWS 组织中的所有账户设置权限护栏
Assume Role	STS 操作，返回用于跨账户或服务间访问的临时安全凭证
凭证报告	AWS 生成的 CSV，列出所有 IAM 用户、其访问密钥、MFA 状态和上次活动时间戳
策略条件	IAM 策略中的约束，用于限制权限适用的情况和方式，例如 MFA 要求或 IP 范围
身份联合	允许外部身份提供商授予临时 AWS 访问权限，而无需创建 IAM 用户

工具与系统

• 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 基准控制项

常见场景

场景：开发者角色被过度授予 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 仓库中发现了一个访问密钥。该密钥属于一个 IAM 用户，并在三个 AWS 账户中拥有 S3 和 EC2 权限。

处理方法：

1. 立即使用 aws iam update-access-key --status Inactive 停用已泄露的密钥
2. 查看 CloudTrail 日志，检查过去 30 天内使用该已泄露密钥进行的所有 API 调用
3. 为该用户创建新的访问密钥，并更新所有依赖服务和 CI/CD 管道
4. 确认所有服务都使用新凭证后，删除已泄露的密钥
5. 将工作负载迁移为使用带 STS 临时凭证的 IAM 角色，以防止未来再次发生密钥泄露

陷阱：在停用密钥之前就删除它，会导致无法取证分析哪些服务依赖该密钥。未能检查所有三个账户是否存在未授权活动，会使潜在后门无法被发现。

输出格式

IAM Security Assessment Report
==============================
Account ID: 123456789012
Assessment Date: 2025-02-23
Analyzer: IAM Access Analyzer + Prowler v4.3

CRITICAL FINDINGS:
[C-001] Root account has active access keys
  - Resource: arn:aws:iam::123456789012:root
  - Remediation: Delete root access keys, enable MFA on root
  - CIS Benchmark: 1.4 (Ensure no root account access key exists)

[C-002] IAM user 'deploy-bot' has AdministratorAccess with no MFA
  - Resource: arn:aws:iam::123456789012:user/deploy-bot
  - Last Activity: 2025-02-20
  - Remediation: Replace with IAM role, enforce MFA condition

HIGH FINDINGS:
[H-001] 3 IAM policies use wildcard Resource "*" with sensitive actions
  - Policies: DevPolicy, CIPolicy, LegacyAdminPolicy
  - Remediation: Scope resources to specific ARNs using Access Analyzer

[H-002] 7 access keys older than 90 days detected
  - Users: svc-backup, svc-monitoring, dev-alice, dev-bob, ...
  - Remediation: Rotate keys, migrate to role-based access

SUMMARY:
  Total Findings: 14
  Critical: 2 | High: 4 | Medium: 5 | Low: 3
  Compliance Score: 62% (CIS AWS Foundations Benchmark v3.0)