Amazon SCS-C02: 漏洞、补丁与主机安全 — 学习指南
属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
Amazon Inspector：跨 EC2、Lambda 和 ECR 的增强型扫描
Amazon Inspector 是一项由代理支持的持续性漏洞管理服务，可以发现 EC2 实例、存储在 ECR 中的容器镜像以及 Lambda 函数（包括应用程序代码和依赖项层）中的 CVE。在账户级别启用 Inspector 会自动纳管符合条件的资源——没有按资源选择加入的工作流程——并且发现结果会自动以标准化的 ASFF 格式推送到 AWS Security Hub，当需要一个集中的安全态势仪表板时，这便是正确的集成模式。
对于 EC2，Inspector 使用混合扫描模型。SSM Agent（通过 AWS 提供的关联）收集用于无代理式网络可达性和软件包评估的软件清单，而深度主机评估则需要代理正在运行且实例可通过 SSM 访问。这就是为什么“仅无代理”方法是一个陷阱：如果没有 SSM Agent 路径（或在需要时使用 Inspector 基于代理的深度检查），你只会得到浅层的发现结果——网络暴露和从清单中衍生的 CVE——但会错过运行时库清单、非托管软件包和配置。混合模式是大多数生产环境所需要的。
对于 Lambda，Inspector 执行两种扫描类型：标准扫描（层和函数依赖项中的软件包漏洞）和代码扫描（对函数代码进行静态分析，以发现注入缺陷、硬编码密钥和不安全的 API）。一个关键的资格规则是：Lambda 函数必须在过去 90 天内至少被调用过一次才能被扫描。空闲或已归档的函数会悄无声息地脱离 Inspector 的扫描范围。那些认为“Inspector 已启用，因此每个函数都被覆盖”的团队，在审计人员要求提供关于罕见执行函数的证据时就会吃亏。补救措施是要么通过 EventBridge 按计划调用函数，要么接受这种排除情况并将其记录在案。
对于 ECR，增强型扫描（由 Inspector 提供支持）取代了基于 Clair 的旧版基本扫描。增强型扫描支持对已在注册表中的镜像进行推送时扫描和持续扫描，因此新披露的针对先前推送镜像的 CVE 会生成新的发现结果，而无需重新推送。在注册表级别启用增强型扫描，并配置每个存储库的筛选器（例如，prod/* 持续扫描，sandbox/* 仅推送时扫描）以控制成本。
委托管理与抑制
在多账户的 AWS Organizations 设置中，从管理账户为 Inspector 指定一个委托管理员账户。委托管理员可以查看所有成员账户的聚合发现结果，并控制整个组织的扫描配置。这避免了为检索发现结果而授予跨账户 IAM 角色，并防止了在每个账户中零散启用 Inspector 的反模式。
抑制规则允许安全团队在不删除发现结果的情况下过滤噪音。规则可以匹配资源标签、严重性、CVE ID 或 ECR 存储库等属性。要将开发/测试 Lambda 的发现结果从生产仪表板中排除，可以应用一个基于标签 Environment=dev 的抑制规则——这些发现结果仍然存在于底层数据存储中以供审计，但它们会从默认视图和（如果已配置）Security Hub 中被排除。不要通过为开发账户禁用 Inspector 来实现这一点；这样做会让你失去捕获一个易受攻击的工件从开发环境提升到生产环境的能力。
用于镜像提升的 CI/CD 门控
增强型 ECR 扫描生成的发现结果与镜像摘要（不仅仅是标签）相关联，这是管道必须查询的内容。典型的模式是：构建镜像 → 推送到 ECR（触发推送时扫描）→ 轮询或等待扫描完成 → 如果存在高危或严重发现结果，则构建失败 → 否则更新 ECS/EKS 任务/部署。
buildspec.yml 中一个最小的 CodeBuild 步骤：
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
未能在此阶段进行门控——相信“Inspector 会提醒我们”——是一个典型的错误：警报是异步到达的，并且是在易受攻击的镜像已经在运行之后。门控必须与提升过程同步。同样，仅基于标签而不是摘要进行门控是不安全的，因为标签是可变的；两次使用相同标签的推送会混淆扫描结果。
Patch Manager、补丁基线和补丁组
SSM Patch Manager 基于三个基本要素运作：
补丁基线： 定义自动批准规则、已批准的补丁、已拒绝的补丁，以及按严重性/分类定义的合规级别。
补丁组： 一个键名精确为
Patch Group的标签，其值将实例注册到特定的基线。维护时段：
AWS-RunPatchBaseline执行扫描或安装任务的时间表。
对于一个要求开发环境立即自动批准所有安全补丁，而生产环境仅在 7 天的观察期后自动批准严重/重要补丁并拒绝内核软件包的环境，你需要创建两个基线。开发基线使用一个批准规则，ApproveAfterDays: 0，覆盖所有安全分类。生产基线使用 ApproveAfterDays: 7，ComplianceLevel: CRITICAL，筛选 Classification=Security 和 Severity in [Critical, Important]，并将 kernel* 添加到拒绝补丁列表中，同时设置 BlockAllPatchesFromRejectedList。实例被标记为 Patch Group=Dev 或 Patch Group=Prod，并且每个补丁组都注册到相应的基线。合规性信息通过补丁合规性报告汇总，并可导出到 S3 以进行集中审计。
单个“带有逻辑”的基线无法表达开发环境与生产环境的差异——基线对于每个注册的组都是静态的。不要试图使用不同的维护时段来模拟这种行为；维护时段控制的是补丁操作的运行时间，而不是哪些补丁被批准。
实时通知管道
对于新发现项的 Slack 或 Microsoft Teams 告警，运维高效的链条是：
Inspector 在
aws.inspector2事件源上将发现项（findings）发送到 EventBridge。EventBridge 规则 按严重性（例如
HIGH、CRITICAL）进行筛选，并以一个 SNS 主题为目标。SNS 主题 有一个 AWS Chatbot 订阅，该订阅映射到 Slack 频道或 Teams 工作区。
Chatbot 直接订阅 SNS — 不要在中间放置 Lambda 来重新格式化消息，因为 Chatbot 原生支持渲染 Inspector 的发现项。一个 EventBridge 模式示例：
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
这里有两个要避免的陷阱：通过 Security Hub 路由会增加延迟，并且如果自定义洞察（insight）配置不当，可能会丢失严重性粒度；而使用 SES 或自定义的 webhook Lambda 会增加运维开销，却并未增加 Chatbot 已原生提供的功能。
实践问题：用例场景
场景： Meridian Financial 运营着一个多账户的 AWS Organization，为面向客户的 Web 服务、批量分析和无服务器事件处理器提供支持。他们的 CI/CD 管道将容器镜像推送到 Amazon ECR，他们为遗留工作负载托管 EC2 机群，并为较新的服务使用 Lambda；一个位于安全账户中的中央安全团队必须跨账户管理漏洞可见性和补丁修复。
挑战： 最近，一个包含高严重性库的镜像被部署到了生产环境，因为 CI/CD 中没有强制执行扫描，并且 EC2 实例的补丁修复在不同环境中不一致，这留下了暴露窗口和大量干扰性的发现项，使团队不堪重负。
推荐方法：
- 通过在 AWS Organizations 中配置委托管理员，从安全账户为 EC2、Lambda 和 ECR 启用 Amazon Inspector 增强型扫描，以便可以集中管理扫描、发现项和抑制规则。
- 配置 ECR 镜像推送时扫描，并将扫描门禁集成到 CodePipeline/CodeBuild 中：在 Inspector/ECR 扫描结果满足严重性阈值之前，阻止镜像晋级，并通过构建步骤暴露发现项。
- 实施 AWS Systems Manager Patch Manager，为每个环境定义补丁基线和补丁组，为非生产环境优先的部署安排维护窗口，并使用 SSM Automation 文档自动批准关键 CVE 的修复。
- 使用 Amazon EventBridge 创建一个实时通知管道，以捕获 Inspector 发现项和 SSM 合规性事件，将它们路由到 Amazon SNS 和一个轻量级的 AWS Lambda，该 Lambda 负责丰富信息、去重，并将优先警报发布到 Slack 并创建跟踪工单。
- 自动化遏制和修复：使用由 EventBridge 触发的 SSM Automation 或 Lambda 运行手册来隔离受影响的 EC2/Lambda 版本或触发镜像重新构建，并通过委托管理员账户仅对已跟踪的误报应用 Inspector 抑制规则，以减少干扰。
基本原理： 集中化的 Inspector 管理、CI/CD 门禁、Patch Manager 基线以及由 EventBridge 驱动的管道遵循了 AWS 的最佳实践，通过强制执行自动化预防、一致的补丁修复以及优先且可审计的响应，同时减少了警报疲劳。
使用 Amazon Inspector 进行漏洞发现
Amazon Inspector 是 AWS 上主要的托管式漏洞评估服务，它在与主机安全相关的三个层面上运行：EC2 实例、Amazon ECR 中的容器镜像以及 Lambda 函数。当在账户或 Organizations 级别（通过 Inspector 控制台中的委托管理员）启用时，它会执行持续的、基于无代理或 SSM 的扫描，而不是预定的时间点扫描。这种持续的态势很重要，因为 CVE 源每天都在变化；上周的快照可能已经过时。
对于 EC2，Inspector 依赖 SSM Agent 来枚举已安装的软件包和内核版本，然后将它们与供应商公告和国家漏洞数据库（National Vulnerability Database）进行关联。发现项包括 CVE 标识符、CVSS 分数、受影响的软件包、修复版本以及网络可达性上下文（网络可达性规则识别通过 ENI、安全组、NACL 和路由表暴露到互联网的端口）。由于扫描依赖于 SSM，如果一个 EC2 实例的实例配置文件上缺少 AmazonSSMManagedInstanceCore 托管策略，它将根本不会出现在 Inspector 的结果中——这是一个值得记住的静默失败。
对于 ECR，Inspector 支持两种扫描模式：
基础扫描： 免费，使用开源的 Clair 引擎，仅在推送时或按需运行时运行。
增强型扫描： 由 Inspector 提供支持，在新 CVE 发布时持续重新扫描镜像（包括操作系统包和应用程序语言包，如 Python、Node、Java），即使在推送事件发生很久之后也是如此。
一个常见的陷阱是将 ECR 的推送时扫描（scan-on-push）视为足够的主机安全措施。事实并非如此。推送时扫描在构建时验证镜像，但正在运行的容器继承了该镜像以及任何可能发生的漂移，并且底层的 EC2 或 Fargate 主机有自己的内核和操作系统包，这些都必须独立修补。增强型扫描与 EC2 主机扫描相结合可以弥补这一差距。所有 Inspector 的发现项都应路由到 AWS Security Hub，它会将这些发现项规范化为 ASFF 格式，并通过 EventBridge 实现跨账户聚合、去重和下游自动化。
Patch Manager 与全实例集群修复
AWS Systems Manager Patch Manager 通过实际修复 Inspector 发现的问题来对其进行补充。Inspector 回答的是“哪些 CVE 会影响我？”，而 Patch Manager 回答的则是“缺少哪些补丁，以及如何安全地安装它们？”
Patch Manager 通过补丁基线进行操作——这是一种声明性规则，它根据分类（安全、关键、错误修复）、严重性和自动批准延迟（例如，在安全补丁发布七天后批准，以确保供应商发布的稳定性）来定义批准哪些补丁。AWS 为每个操作系统提供了默认基线（如 AWS-AmazonLinux2DefaultPatchBaseline、AWS-WindowsPredefinedPatchBaseline 等），但生产环境中的实例集群通常使用自定义基线，并通过实例上的 Patch Group 标签与补丁组相关联。
一个典型的扫描和修补工作流使用两种操作：
扫描 (Scan)： 报告合规性状态而不安装任何东西；结果会显示在 Patch Manager 合规性控制面板和 Config 中。
安装 (Install)： 应用已批准的补丁，并且对于许多操作系统，会重新启动。
这些操作通常通过维护时段进行计划，并以 AWS-RunPatchBaseline 文档为目标。对于紧急的零日漏洞场景，Patch Manager 提供了立即修补 (Patch Now) 功能，这是一种按需操作，可以绕过维护时段的计划。推荐的模式是创建一个范围狭窄的补丁基线，仅批准修复该漏洞的特定 KB 或软件包，然后针对受影响的补丁组运行“立即修补”，并将执行输出流式传输到中央 S3 存储桶和 CloudWatch Logs 日志组。这个集中化的日志就成为您的审计工件——为审计员或事件响应提供修复证明。
实践问题：用例场景
场景： Meridian Financial 公司在一个多账户 AWS 环境中运营，拥有数百个 EC2 实例（Windows 和 Amazon Linux）和一个支持面向客户服务的小型 EKS 集群。他们使用 AWS Organizations、AWS Systems Manager 作为运维工具，并在一个共享镜像账户中维护 AMI，但缺乏跨账户的一致性自动化漏洞扫描或协调的补丁发布流程。
挑战： 一个影响 OpenSSL 的公共 CVE 被发布，Amazon Inspector 报告了多个实例存在高危发现，但补丁修复工作参差不齐，一个生产服务因修复延迟而遭受了短暂的攻击。
推荐方法：
- 在所有账户和区域中启用 Amazon Inspector，以执行镜像和运行中实例的漏洞扫描，并将高严重性发现转发到 AWS Security Hub 和一个 EventBridge 自定义事件总线。
- 使用 AWS Systems Manager Inventory 识别受影响的实例，并按关键性对其进行标记；创建一个包含所需 OpenSSL 修复程序的 Patch Manager 基线，并设定针对 Windows/Linux 的规则。
- 创建一个 EventBridge 规则，当 Inspector 的发现达到定义的严重性级别时，触发一个 SSM Automation 文档，将实例 ID 列表传递给一个 Automation Runbook，该 Runbook 调用 Patch Manager 或 Run Command 来应用补丁并在需要时重启。
- 对于有状态或高风险的服务，使用 EC2 Image Builder 制作包含补丁的 AMI 来编排滚动更新，通过受控的蓝/绿部署或滚动部署来更新 Auto Scaling 组或 EKS 节点组，并使用 Route 53/ALB 健康检查来验证服务健康状况。
- 修复后，重新运行 Amazon Inspector 以验证发现是否已解决，更新 SSM Compliance 报告，并通过 SNS 将摘要发送给安全团队；将该 Automation Runbook 保留在 Systems Manager Automation 库中，以便进行可重复的全实例集群响应。
基本原理： 此方法使用 Amazon Inspector 进行持续发现，使用 Systems Manager Patch Manager 和 Automation 进行受控的自动化修复，并使用基于镜像的重建来实现不可变基础设施，这与 AWS 在检测、自动化响应和最小化爆炸半径方面的最佳实践相一致。
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
通过在 Systems Manager Explorer 中配置委托管理员账户并启用资源数据同步，可以将每个账户的补丁合规性状态聚合到单个 S3 存储桶中，从而实现集中式合规管理。之后，可以使用 Athena 查询这些数据或在 QuickSight 中进行可视化。
使用 Session Manager 实现可审计的管理
传统的基于 SSH 的访问有三个结构性弱点：长期有效的密钥材料存放在操作员的笔记本电脑上，端口 22 必须可访问（即使只是通过堡垒机），并且如果没有额外的工具，shell 活动也无法被集中记录。Session Manager 消除了这三个弱点。
Session Manager 通过 SSM Agent 到 SSM 端点的出站 HTTPS 连接来隧道化交互式 shell。没有入站端口，没有 SSH 密钥对，也没有堡垒机。访问权限由 IAM 策略授权（ssm:StartSession 可按实例标签或 ARN 限定范围），并且每个会话都可以记录到 CloudWatch Logs 或 S3，还可以选择使用 KMS 加密。在 Linux 上，会话默认以 ssm-user 用户身份运行；sudo 行为由实例的 sudoers 配置控制，而不是由 IAM 控制。
对于新的实例集群，正确的强化模式是：启动实例时不使用 EC2 密钥对，附加一个带有 AmazonSSMManagedInstanceCore 的实例配置文件，将实例放置在带有 ssm、ssmmessages 和 ec2messages 的 VPC 端点的私有子网中，并在 Session Manager 的首选项级别强制执行会话日志记录。在部署 Session Manager 的同时继续分发 SSH 密钥是一个陷阱：它保留了 Session Manager 本应消除的攻击面，并留下了一个未经记录的访问通道。请从您的 AMI 构建流程中移除 authorized_keys 的配置。
使用 CloudWatch Agent 进行主机遥测
统一的 CloudWatch agent 收集 EC2 hypervisor 无法看到的操作系统级指标（内存、磁盘、各进程的 CPU）和日志文件。它通过一个通常存储在 Parameter Store 中的 JSON 文件进行配置，然后使用 amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux 应用该配置。
该 agent 最常见的操作失败原因是实例配置文件 (instance profile) 缺少 IAM 权限。该 agent 至少需要：
logs:CreateLogGroup（除非日志组已预先创建）
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData（用于自定义指标）
ssm:GetParameter（用于从 Parameter Store 获取配置）
托管策略 CloudWatchAgentServerPolicy 捆绑了这些权限。当权限缺失时，agent 会成功启动并在 systemctl status 中显示为健康，但日志永远不会到达 CloudWatch——失败信息仅在 /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log 中可见。任何假定使用集中式日志的主机安全设计都必须验证日志的交付情况，而不仅仅是 agent 的状态。
融会贯通
这个防御闭环是：Inspector 发现主机和容器镜像上的 CVE，其发现结果流入 Security Hub 进行聚合，Patch Manager 通过计划的维护时段或在紧急情况下使用“立即修补”(Patch Now) 功能进行修复，Session Manager 提供唯一的管理访问路径，而 CloudWatch agent 将补丁证据和运行时日志流式传输到集中的账户。每个控制环节都以前提假设其他环节的存在：没有 Patch Manager 的 Inspector 只会生成无人跟进的报告；没有集中式日志记录的 Patch Manager 无法生成审计追踪；没有适当 IAM 配置的 Session Manager 会导致权限过大或过小；而没有正确日志权限的 CloudWatch agent 则会造成可见性的假象。
← 治理、配置与自动化 · 所有领域 · 容器与 Serverless 安全 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →