killvxk 保护 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。
方法：
- 启用 IAM Access Analyzer，根据每个角色 90 天的 CloudTrail 数据生成策略建议
- 创建仅允许访问各团队实际使用的特定 S3 存储桶、Lambda 函数和 DynamoDB 表的范围化策略
- 附加拒绝 IAM、Organizations 和计费操作的权限边界
- 在并行角色中部署新策略并通过 CloudTrail 监控后，再替换原始角色
- 移除 AdministratorAccess 并轮换所有访问密钥
常见陷阱：未经并行测试阶段直接替换策略会导致服务中断。忘记将 Lambda:InvokeFunction 限定到特定函数 ARN 会留下横向移动路径。
场景：跨多个服务轮换受损访问密钥
场景背景：在公开 GitHub 仓库中发现一个访问密钥。该密钥属于在三个 AWS 账户中具有 S3 和 EC2 权限的 IAM 用户。
方法：
- 立即使用
aws iam update-access-key --status Inactive停用受损密钥 - 检查 CloudTrail 日志，审查过去 30 天内使用受损密钥进行的所有 API 调用
- 为用户创建新访问密钥，并更新所有依赖的服务和 CI/CD 流水线
- 确认所有服务使用新凭据后，删除受损密钥
- 将工作负载迁移到使用 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）