Amazon SCS-C02: 威胁检测与告警 — 学习指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

在整个组织中集中管理 GuardDuty

Amazon GuardDuty 是一项持续性威胁检测服务，可分析 CloudTrail 管理事件和数据事件、VPC Flow Logs、DNS 查询日志、EKS 审计日志、RDS 登录活动以及运行时遥测数据。它会生成按威胁目的（Backdoor、CryptoCurrency、Recon、UnauthorizedAccess、PenTest、Policy、Stealth、Trojan、Impact）和资源类型（EC2、IAMUser、S3、Kubernetes、RDS、Lambda、Runtime）分类的调查发现。

逐个账户地操作 GuardDuty 无法扩展。在 AWS Organizations 环境中，正确的架构是使用 Organizations 管理账户指定一个委托管理员——通常是专用的安全或审计账户。通过该委托管理员，您可以在整个组织范围内启用 GuardDuty，并开启自动启用功能，这样新成员账户和新区域在创建时就会自动受到保护。如果没有自动启用，新创建的账户在操作员手动启用检测之前会一直处于盲区，而这正是攻击者在账户初始配置期间利用的漏洞。

实际问题：用例场景

场景： Meridian Financial 在一个多账户 AWS 环境中运行，该环境包含 28 个用于生产、开发和共享服务的账户。他们的管理账户通过 AWS Organizations 治理这些账户，并实现了集中的 CloudTrail 和 S3 日志记录，但安全警报和调查数据分散在各个成员账户中，导致事件分类缓慢且不一致。

挑战： 最近在一个账户中检测到的横向移动产生了 GuardDuty 调查发现，但这些调查发现未能足够快地被中央 SOC 工具看到，从而延迟了遏制和取证调查。

推荐方法：

1. 在管理账户中指定一个 GuardDuty 委托管理员，并通过 AWS Organizations 在整个组织范围内启用 GuardDuty，以便所有成员账户都将调查发现转发到一个中央检测器。
2. 在管理账户中开启集中的 AWS Security Hub 作为聚合器，并为所有账户和区域启用 Security Hub，以将 GuardDuty 调查发现与其他安全标准一起进行规范化。
3. 在管理账户中配置 Amazon EventBridge 规则，以捕获 GuardDuty 和 Security Hub 的调查发现，并将其路由到集中式目标，例如用于发送告警通知的 Amazon SNS、用于归档到 S3 的 Amazon Kinesis Data Firehose，或直接交付给您的 SIEM。
4. 部署由 EventBridge 触发的 Lambda 响应程序，以执行自动化的遏制操作（例如，通过 EC2 API 隔离一个 EC2 实例并创建一个 AWS Systems Manager 事件），并为调查发现添加标签以供调查。
5. 集成 Amazon Detective 进行集中式调查，并将 S3 中归档的调查发现转发到您的分析/SIEM 系统，以进行长期关联和报告。

基本原理： 根据 AWS 的最佳实践，使用 GuardDuty 委托管理员结合 Security Hub 和 EventBridge，可以集中化检测、规范化警报，并实现自动化、可审计的响应，从而实现全组织的威胁检测和及时的事件响应。

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty 是区域性服务，因此必须在您运营的每个区域中建立委托管理员关系并配置自动启用设置。这是一个常见的盲点来源——团队在 us-east-1 中启用了 GuardDuty，就以为获得了全球覆盖。

特定于服务的保护

基础的 GuardDuty 覆盖了基本的数据源，但有几个保护计划必须明确启用，因为它们会增加成本和额外的遥测数据摄取：

• RDS Protection： 分析 Aurora MySQL/PostgreSQL 和 RDS 引擎的登录活动，在未知用户向数据库端点进行身份验证时生成诸如 CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin 之类的调查发现。这是检测可疑数据库登录的正确来源——当 RDS Protection 已经能够原生发出调查发现时，不要在数据库审计日志上构建自定义的 CloudWatch 指标筛选器。

• EKS Protection： 摄取 Kubernetes 审计日志，以检测异常的 API 访问、特权 Pod 创建以及对暴露仪表板的使用。

• Runtime Monitoring： 在 EC2、ECS/Fargate 或 EKS 上部署一个基于 eBPF 的轻量级代理，以发现进程、文件和网络事件——这是在运行时检测无文件恶意软件或反向 Shell 所必需的。

• Malware Protection： 对被其他调查发现标记的实例所附加的 EBS 卷进行快照扫描，或在 S3 对象上传时对其进行按需扫描。

• Lambda Protection 和 S3 Protection： 分别覆盖函数调用模式和 S3 数据平面的访问。

只启用基础服务并期望数据库登录异常会出现是一种常见的错误配置——在相应的功能开启之前，这些类型的调查发现根本不会产生。

Security Hub 作为聚合层

Security Hub 摄取来自 GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、Config、Health 以及第三方 ISV 产品的发现结果，并将它们规范化为 AWS 安全发现结果格式 (ASFF)。它还运行自己的合规性标准（AWS 基础安全最佳实践、CIS、PCI DSS、NIST 800-53）。

要在整个 Organization 中实现集中化：

• 在 Organizations 中启用 Security Hub 作为一项服务，并指定一个委托管理员（通常与 GuardDuty 使用同一个安全账户）。

• 打开自动为新账户启用功能，以便成员账户能被自动纳入。

• 配置一个发现结果聚合区域（也称为主区域），并将所有其他区域链接到该区域。如果没有跨区域聚合，每个区域都会维护一个独立的 Security Hub 实例，分析师必须在不同控制台之间切换。

因此，全局组织性部署的模式需要两个协同设置：聚合区域链接和组织范围的自动启用开关。只启用其中一个会导致新账户未被覆盖或新区域被孤立。

一个重要的限制：Security Hub 聚合和确定优先级，但不进行修复。将其视为一个修复平台是一个概念性错误——修复是通过下游的 EventBridge 实现的。

EventBridge 作为自动化结构

GuardDuty 和 Security Hub 都会将发现结果发布到默认事件总线。aws.guardduty 发出 GuardDuty Finding 事件，而 aws.securityhub 发出 Security Hub Findings - Imported（由 Hub 创建/更新）和 Security Hub Findings - Custom Action（由操作员触发）事件。

过于宽泛的规则，如 {"source": ["aws.securityhub"]}，会在每次来自任何提供商的发现结果更新时都调用目标，这会迅速用信息噪音淹没 SNS 主题并向待命工程师发送分页警报。正确的做法是根据 severity.Label、ProductArn、Types 或特定的 Title 值进行筛选：

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

对于一个以 Security Hub 为中心的模式，该模式仅针对高严重性的 GuardDuty 发现结果触发，同时忽略嘈杂的第三方 ISV 产品：

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

常见的目标包括用于电子邮件/短信/Slack 通知的 SNS 主题、通过更换其安全组来隔离实例的 Lambda 函数、SSM Automation 运行手册，或用于编排多步响应的 Step Functions 状态机。对于 Aurora 登录异常用例，最小工作量的路径是 GuardDuty RDS Protection → 根据 RDS 发现结果类型筛选的 EventBridge 规则 → 带有电子邮件订阅的 SNS 主题。无需自定义轮询，无需 Lambda，也无需第三方 SIEM。

Security Hub 自定义操作

自定义操作是由操作员驱动的触发器。在 Security Hub 控制台中，分析师选择一个或多个发现结果，并选择一个自定义操作（例如，“隔离 EC2”）。Security Hub 会发出一个 Security Hub Findings - Custom Action 事件，其中包含所选发现结果的 ARN；EventBridge 规则会匹配该自定义操作的 ARN 并调用一个执行响应的 Lambda。这为您提供了一个“人在回路中”的按钮，而无需构建定制的 UI：

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

生成的 ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) 成为 EventBridge 规则 resources 字段中的匹配值。

抑制与信号管理

噪音管理是一门需要持续进行的工作，而不是一次性的过滤设置。使用 Security Hub 自动化规则或 GuardDuty 抑制规则来自动归档已知的良性发现结果（例如，渗透测试工具预期的 Recon:EC2/Portscan 发现结果）。通过 ProductArn 筛选 EventBridge 规则，可以在不完全禁用的情况下静默一个话多的第三方集成。将 Severity.Label 与 Workflow.Status = NEW 结合使用，这样重新打开或已通知的发现结果就不会再次触发分页警报。目标是让每一个到达人工的警报都代表一个可操作、高置信度的事件——任何其他情况都会削弱响应准备度。

调查枢纽

当一个高严重性的发现结果触发时——例如 Backdoor:EC2/C&CActivity.B!DNS——最快的调查路径不是手动编写针对 CloudTrail 和 Flow Logs 的 Athena 查询。Amazon Detective 在与 GuardDuty 一同启用时，会根据 CloudTrail、VPC Flow Logs 和 GuardDuty 的发现结果预先构建实体图谱。从发现结果直接切换到 Detective 中的 IAM 角色或 EC2 实例配置文件，可以展示出相关时间窗口内的 API 活动、网络对等方以及成功与失败的连接计数，而无需任何自定义查询工作。

← 身份与访问管理 · 所有领域 · 日志、审计与取证 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →