AWS Inspector V2 Agent-based 扫描权限控制机制分析与建议

前言

AWS Inspector V2 是 Amazon 提供的自动化安全评估服务,能够持续扫描 AWS 工作负载以识别软件漏洞和意外的网络暴露。该服务支持 Amazon EC2 实例、Amazon ECR 容器镜像和 AWS Lambda 函数的安全扫描,为用户提供统一的漏洞管理视图。

Inspector V2 提供了两种模式对 EC2 实例进行扫描:Agent-based 扫描(基于 AWS Systems Manager Agent)和 Agentless 扫描(基于 EBS 快照)。Agent-based 扫描能够提供实时的漏洞检测和深度检查功能,但需要实例注册到 AWS Systems Manager (SSM) 服务。

在实施 Inspector V2 Agent-based 扫描时,通过对其权限控制机制实测发现了 AWS SSSM 服务在权限评估方面的一些有趣的设计特点,这些发现对于正确理解和配置 Inspector V2 具有重要的参考价值。

测试背景和环境

测试目标

通过 IAM 策略实现对 Inspector V2 Agent-based 扫描的精确权限控制,确保只有必要的 SSM 功能(如 执行 Inspector 扫描所需的文档/脚本)能够被执行,其它远程访问能力被禁止。

测试环境

  • 主测试区域: ap-northeast-1 (东京)
  • 跨区域验证: us-west-2 (俄勒冈)
  • 测试实例: 6 个 EC2 实例,配置不同的 IAM 策略
区域 策略类型 Instance Profile SSM 注册状态
ap-northeast-1 第一次测试 (含 SourceInstanceARN) InspectorTestInstanceProfile ❌ 未注册
ap-northeast-1 Condition 限制 InspectorV2TestInstanceProfile ✅ 已注册
ap-northeast-1 Resource 级别限制 InspectorResourceLevelInstanceProfile ✅ 已注册
ap-northeast-1 第一次测试复现 InspectorFirstTestReplicaInstanceProfile ❌ 未注册
us-west-2 Condition 限制 InspectorV2TestInstanceProfile ✅ 已注册
us-west-2 Resource 级别限制 InspectorResourceLevelInstanceProfile ✅ 已注册

Inspector V2 扫描模式对比

在讨论权限控制机制之前,让我们先了解 Inspector V2 提供的两种扫描模式的详细差异:

Agent-based vs Agentless 扫描对比

对比维度 Agent-based 扫描 Agentless 扫描
工作原理 使用 SSM Agent 收集软件清单 使用 EBS 快照收集软件清单
前置要求 • 实例必须注册到 SSM
• 需要 SSM Agent 运行
• 需要适当的 IAM 权限
• 实例必须基于 EBS
• 支持的文件系统 (ext3/ext4/xfs)
• 卷数量 < 8,总大小 ≤ 1200GB
扫描频率 • 持续扫描
• 新实例启动时
• 安装新软件时
• 新 CVE 添加时
• 每 24 小时一次
• 新符合条件实例每小时检测
扫描范围 • 操作系统包
• 编程语言包 (通过深度检查)
• 可配置自定义路径
• 操作系统包
• 编程语言包 (所有可用路径)
• 无需配置路径
深度检查 ✅ 支持 Linux 深度检查
• 默认路径: /usr/lib, /usr/lib64, /usr/local/lib, /usr/local/lib64
• 可配置最多 5 个自定义路径
• 每 6 小时收集一次应用清单
✅ 自动扫描所有可用路径
• 无需配置
• 可能发现更多编程语言包漏洞
支持的操作系统 • Linux (完整支持)
• Windows (操作系统包)
• macOS (操作系统包)
• Linux (完整支持)
• Windows (操作系统包)
• macOS (操作系统包)
网络要求 • 需要 SSM 端点连接
• 可使用 VPC 端点
• 需要 EBS 直接 API 访问
权限控制 • 依赖 SSM 权限模型
存在文档级别限制失效问题
• 基于 EBS 快照权限
• 更简单的权限模型
实时性 ✅ 实时响应变化
• 软件安装后立即扫描
• 新 CVE 发布后立即评估
❌ 延迟响应
• 最多 24 小时延迟
资源消耗 • 实例上运行 SSM Agent
• 定期执行 SSM 命令
• 创建临时 EBS 快照
• 快照存储成本 (短期)
适用场景 • 需要实时监控的生产环境
• 频繁变更的开发环境
• 需要深度检查配置的环境
• 高安全隔离要求环境
• 无法安装 Agent 的环境
• 静态或变更较少的环境
成本模型 按实例覆盖小时数计费 按实例覆盖小时数计费

扫描模式配置选项

Inspector V2 提供三种扫描模式配置:

  1. Agent-based 扫描模式 (默认)

    • 仅使用 Agent-based 方法
    • 只扫描 SSM 管理的实例
    • 提供持续扫描和深度检查
  2. 混合扫描模式 (Hybrid)

    • 同时使用两种扫描方法
    • SSM 管理的实例使用 Agent-based
    • 未管理的实例使用 Agentless
    • 最大化覆盖范围
  3. 仅 Agentless 扫描模式

    • 仅使用 Agentless 方法
    • 适合高安全要求环境
    • 避免 SSM 权限复杂性

SSM 权限评估的运行机制

主要发现

通过系统性的测试发现 AWS SSM 服务的权限评估采用了一种两阶段的处理机制:

  1. 实例注册阶段:IAM 策略严格控制实例是否能够注册到 SSM 服务
  2. 命令执行阶段:一旦实例成功注册,SSM 服务对文档级别的 IAM 策略限制采用了不同的处理方式

权限评估机制对比

阶段 IAM 策略控制效果 实际表现
实例注册 严格遵循 IAM 策略 可以精确控制实例是否注册到 SSM
文档执行 文档级别限制的处理方式不同 已注册实例的文档执行权限控制表现与预期不同

技术验证过程

测试的 IAM 策略配置

测试了3种不同的权限控制策略:

策略 1: 包含 SourceInstanceARN 条件的严格策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:UpdateInstanceInformation",
                "ssm:GetInventory",
                "ssm:PutInventory"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ssm:SourceInstanceARN": "arn:aws:ec2:*:*:instance/*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": ["ssm:SendCommand"],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ssm:DocumentName": [
                        "AWS-GatherSoftwareInventory",
                        "InvokeInspectorLinuxSsmPlugin-do-not-delete"
                    ]
                }
            }
        }
    ]
}

策略 2: DocumentName 条件限制策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["ssm:SendCommand"],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ssm:DocumentName": [
                        "AWS-GatherSoftwareInventory",
                        "InvokeInspectorLinuxSsmPlugin-do-not-delete"
                    ]
                }
            }
        }
    ]
}

策略 3: Resource 级别限制策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["ssm:SendCommand"],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*",
                "arn:aws:ssm:*::document/AWS-GatherSoftwareInventory",
                "arn:aws:ssm:*::document/InvokeInspectorLinuxSsmPlugin-do-not-delete"
            ]
        }
    ]
}

IAM Policy Simulator 测试结果

使用 IAM Policy Simulator 的测试结果都符合预期:

测试项目 预期结果 Simulator 结果
AWS-GatherSoftwareInventory Allow ✅ allowed
AWS-RunShellScript Deny ✅ implicitDeny
AWS-RunPowerShellScript Deny ✅ implicitDeny

实际服务行为测试

策略 1 的测试结果

使用包含严格 SourceInstanceARN 条件的策略时:

# 检查实例状态
aws inspector2 batch-get-account-status --account-ids <ACCOUNT-ID>

# 结果显示实例未能注册到 SSM
{
    "resourceId": "i-xxxxxxxxxxxxxxxxx",
    "scanStatus": {
        "reason": "UNMANAGED_EC2_INSTANCE",
        "statusCode": "INACTIVE"
    }
}

结果: 实例无法注册到 SSM,因此无法执行任何 SSM 命令,包括被限制的命令。

策略 2 和 3 的测试结果

当实例成功注册到 SSM 后:

# 尝试执行策略中未明确允许的文档
aws ssm send-command --document-name "AWS-RunShellScript" \
    --parameters 'commands=["echo This is a test command"]' \
    --instance-ids i-xxxxxxxxxxxxxxxxx

# 实际结果:命令成功执行
{
    "Command": {
        "CommandId": "12345678-1234-1234-1234-123456789012",
        "Status": "Success",
        "StandardOutputContent": "This is a test command\n"
    }
}

结果: 已注册到 SSM 的实例能够执行策略中未明确允许的文档。

跨区域一致性验证

我们在 us-west-2 区域进行了相同的测试,结果表现一致,说明这是 SSM 服务的统一运行机制。

技术分析和理解

SSM 服务的设计考虑

基于测试结果,我们可以理解 SSM 服务可能基于以下设计考虑:

  1. 服务可用性优先: 一旦实例注册成功,优先保证服务的可用性
  2. 简化权限模型: 在执行阶段采用相对简化的权限检查机制
  3. 性能考虑: 避免在每次命令执行时进行复杂的权限计算

IAM Policy Simulator 与实际服务的差异

AWS 官方文档中提到:

"The policy simulator results can differ from your live AWS environment. We recommend that you check your policies against your live AWS environment after testing using the policy simulator to confirm that you have the desired results."

这说明策略模拟器与实际服务可能存在差异,建议用户在实际环境中进行验证。

对 Inspector V2 使用的影响

Agent-based 扫描的权限控制挑战

基于我们的测试发现,Inspector V2 Agent-based 扫描面临以下权限控制挑战:

  1. 实例注册控制有效,文档执行控制失效

    • 可以通过 IAM 策略控制哪些实例注册到 SSM
    • 无法通过 IAM 策略限制已注册实例的文档执行权限
  2. 安全隔离要求的根本冲突

    • Agent-based 扫描需要实例注册到 SSM
    • 一旦注册,就失去了文档级别的精确权限控制
    • 这与严格的安全隔离要求存在根本性矛盾

针对不同环境的扫描模式选择建议

高安全要求环境 (推荐:Agentless 或混合模式)

推荐配置:

# 配置为仅 Agentless 扫描模式
aws inspector2 update-configuration \
    --ec2-configuration scanMode=AGENTLESS

# 或者配置为混合模式,但严格控制 SSM 注册
aws inspector2 update-configuration \
    --ec2-configuration scanMode=HYBRID

优势:

  • 避免 SSM 权限控制问题
  • 保持严格的安全隔离
  • 仍能获得全面的漏洞扫描覆盖

考虑因素:

  • 扫描频率降低至每 24 小时
  • 无法获得实时的漏洞响应
  • 需要确保 EBS 快照权限配置正确

标准企业环境 (推荐:混合模式 + 监控)

推荐配置:

# 使用混合扫描模式
aws inspector2 update-configuration \
    --ec2-configuration scanMode=HYBRID

# 启用深度检查
aws inspector2 update-ec2-deep-inspection-configuration \
    --activate true

配套安全措施:

  1. 网络级别控制

    # 创建 VPC 端点限制 SSM 访问
    aws ec2 create-vpc-endpoint \
        --vpc-id vpc-xxxxxxxxx \
        --service-name com.amazonaws.region.ssm \
        --policy-document file://ssm-endpoint-policy.json
    
  2. 加强监控和审计

    # 启用 SSM 会话日志记录
    aws logs create-log-group --log-group-name /aws/ssm/session-logs
    
    # 配置 CloudTrail 记录 SSM API 调用
    aws cloudtrail create-trail --name ssm-audit-trail \
        --s3-bucket-name <your-audit-bucket>
    
  3. 实施分层安全控制

    • 网络层:VPC 配置和安全组
    • 实例层:操作系统级别的安全配置
    • 应用层:应用程序级别的访问控制

开发测试环境 (可选:Agent-based 模式)

推荐配置:

# 使用 Agent-based 扫描获得最佳实时性
aws inspector2 update-configuration \
    --ec2-configuration scanMode=AGENT_BASED

# 配置深度检查自定义路径
aws inspector2 update-ec2-deep-inspection-configuration \
    --activate true \
    --package-paths /opt/myapp,/usr/local/myapp

适用场景:

  • 需要实时漏洞检测的开发环境
  • 频繁部署和更新的测试环境
  • 与生产环境适当隔离的环境

配置最佳实践

扫描模式选择决策树

针对不同安全要求的配置建议:

是否有严格的安全隔离要求?
├─ 是 → 使用 Agentless 扫描模式
│   ├─ 优点:避免 SSM 权限问题,保持安全隔离
│   └─ 缺点:扫描频率较低 (24小时),无实时响应
│
└─ 否 → 是否需要实时漏洞检测?
    ├─ 是 → 使用混合扫描模式 + 严格监控
    │   ├─ 优点:最大覆盖范围,实时响应
    │   └─ 缺点:需要接受 SSM 权限控制限制
    │
    └─ 否 → 使用 Agentless 扫描模式
        ├─ 优点:简化权限管理,降低复杂性
        └─ 缺点:无深度检查自定义配置

基于实测的关键建议

1. 高安全要求环境

# 推荐:使用 Agentless 扫描模式
aws inspector2 update-configuration \
    --ec2-configuration scanMode=AGENTLESS

理由: 完全避免 SSM 权限控制问题,保持严格的安全隔离。

2. 标准企业环境

# 推荐:混合扫描模式 + 加强监控
aws inspector2 update-configuration \
    --ec2-configuration scanMode=HYBRID

# 关键:监控异常 SSM 命令执行
aws events put-rule --name "SSM-Command-Monitoring" \
    --event-pattern '{"source":["aws.ssm"],"detail-type":["SSM Command Status-change Notification"]}'

理由: 在功能性和安全性之间取得平衡,但必须接受 IAM 策略限制失效的现实。

3. 开发测试环境

# 可选:Agent-based 扫描
aws inspector2 update-configuration \
    --ec2-configuration scanMode=AGENT_BASED

理由: 可以接受权限控制限制,获得最佳的实时性和深度检查功能。

权限控制的现实考虑

基于我们的测试发现,在配置 Inspector V2 时需要认识到:

  1. IAM 策略的文档级别限制在 SSM 执行阶段不会生效
  2. IAM Policy Simulator 的结果与实际服务行为存在差异
  3. 实际的权限控制需要依赖网络层面和监控审计

因此,选择扫描模式时应该基于对这些限制的清晰理解,而不是依赖可能失效的 IAM 策略控制。

复现测试要点

如果您希望在自己的环境中验证这些发现,建议关注以下要点:

  1. 对比测试方法

    • 先使用 IAM Policy Simulator 测试策略效果
    • 再在实际环境中测试相同的权限配置
    • 对比两者的结果差异
  2. 关键测试场景

    • 测试实例是否能成功注册到 SSM
    • 测试已注册实例是否能执行策略中未明确允许的文档
    • 验证跨区域的一致性
  3. 安全注意事项

    • 在隔离的测试环境中进行验证
    • 使用测试专用的 IAM 角色和实例
    • 及时清理测试资源

结语

通过实际技术验证,我们发现了 AWS SSM 服务权限评估的两阶段机制:注册阶段严格遵循 IAM 策略,而执行阶段对文档级别限制的处理方式有所不同。这一发现解释了为什么 IAM Policy Simulator 的结果与实际服务行为存在差异。

对于 Inspector V2 的使用,建议用户:

  • 高安全要求环境:优先考虑 Agentless 扫描
  • 标准企业环境:可使用 Agent-based 扫描,但需配合网络控制和监控
  • 所有环境:在实际环境中验证权限配置,不要仅依赖策略模拟器

这些发现帮助我们更好地理解 AWS SSM 和 Inspector V2 服务的实际运行机制,制定更合适的安全配置策略。希望这些经验能够帮助其他用户更好地使用这些服务。


注意: 本文基于特定时间点的测试结果,AWS 服务可能会持续更新和改进。建议读者在自己的环境中进行验证,并关注 AWS 官方文档的最新更新。

Next Post Previous Post
No Comment
Add Comment
comment url