Amazon SCS-C02: 日志、审计与取证 — 学习指南
属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
Amazon GuardDuty 检测结果与修复
GuardDuty 是一项托管的威胁检测服务，它在后台持续接收三种遥测流：CloudTrail 管理事件（以及可选的 S3 数据事件）、VPC Flow Logs 和 Route 53 DNS 查询日志。您无需为 GuardDuty 单独启用、交付或支付这些日志源的费用——该服务直接读取一个重复的数据流。这就是为什么 GuardDuty 只需一个 API 调用即可开启，并在几分钟内开始生成检测结果，而无需任何日志管道工程。
检测结果的严重性值在 0.1 到 8.9 之间，分别对应低（0.1–3.9）、中（4.0–6.9）和高（7.0–8.9）。典型的可操作检测结果包括 UnauthorizedAccess:EC2/SSHBruteForce、Backdoor:EC2/C&CActivity.B!DNS、CryptoCurrency:EC2/BitcoinTool.B 和 Recon:IAMUser/MaliciousIPCaller。修复模式因检测结果而异：基于 EC2 的入侵通常需要使用隔离安全组来隔离实例，为取证快照卷，然后终止实例；基于 IAM 的检测结果则需要轮换访问密钥并审查该主体近期的 CloudTrail 活动。
对于多账户环境，请通过 AWS Organizations 启用 GuardDuty，并指定一个委派管理员账户（通常是安全工具账户）。委派管理员可以在已开启该服务的每个区域中，为所有现有和新增的成员账户自动启用 GuardDuty。若不进行委派管理员配置，每个账户的 GuardDuty 检测结果将隔离在各自的成员账户中——单独启用检测器并不会将它们集中聚合。
AWS Security Hub 与跨账户聚合
Security Hub 是规范化和聚合层。它接收来自 GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、Config 以及数十个合作伙伴产品的检测结果，并将它们转换为 AWS 安全检测结果格式（ASFF）。它还根据 CIS AWS Foundations、AWS 基础安全最佳实践、PCI DSS 和 NIST 800-53 等标准运行自己的控制项。
跨账户、跨区域的聚合方式与 GuardDuty 相同：将 Security Hub 注册到 Organizations 的委派管理员，然后指定一个聚合区域，以便其他区域的检测结果能复制到这单一窗格中。一个常见的错误是在每个账户中都启用 Security Hub，并期望获得一个整合视图——如果没有委派管理员和聚合区域的配置，每个账户仍然只能看到自己的检测结果。
Security Hub 本身不发送电子邮件。通知和自动化是通过在默认的 EventBridge 总线上匹配 Security Hub 检测结果事件，并将其转发到 SNS、Lambda、Step Functions 或 Systems Manager Automation 文档来构建的。
CloudTrail：管理事件 vs. 数据事件
CloudTrail 记录两类活动，混淆这两者是检测覆盖范围中最常见的单一缺口。
管理事件： 控制平面操作——
RunInstances、CreateBucket、AttachRolePolicy、PutBucketAcl。在任何新跟踪上默认启用。数据事件： 高容量的资源级操作——S3 对象级调用（
GetObject、PutObject、DeleteObject、PutObjectAcl）、LambdaInvoke、DynamoDB 项目级 API 调用。默认禁用，并单独计费。
如果一个安全要求是“检测到有人通过 PutObjectAcl 将 S3 对象公开”，一个普通的管理事件跟踪将无法捕获它，因为对单个对象的 ACL 更改是数据事件。同样，如果没有数据事件，从敏感存储桶中 GetObject 的数据流出也是不可见的。PutBucketAcl（存储桶级别）是一个管理事件，会被记录；PutObjectAcl（对象级别）则不是。
使用在管理账户或委派管理员账户中创建的组织跟踪，这样每个成员账户的事件都会被捕获到单个 S3 存储桶中，并且成员账户中的主体无法禁用它。通过以下方式保护该跟踪：
对目标存储桶使用 SSE-KMS 加密，并配置一个拒绝未经授权解密的 KMS 密钥策略。
配置一个存储桶策略，拒绝没有 CloudTrail 服务主体的
s3:PutObject操作，并拒绝删除操作。启用日志文件完整性验证，该功能会生成每小时使用 SHA-256 签名的摘要文件，以便篡改行为可以被证实。
创建示例：
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name central-ct-logs \
--is-organization-trail \
--is-multi-region-trail \
--enable-log-file-validation \
--kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail put-event-selectors \
--trail-name org-trail \
--event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
"DataResources":[{"Type":"AWS::S3::Object",
"Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'
EventBridge 与 SNS 警报
EventBridge 是连接检测结果与人工和自动响应者的路由结构。每个 GuardDuty 检测结果、每个 Security Hub 检测结果更新以及每个源自 CloudTrail 的事件都会到达默认事件总线。规则使用 JSON 事件模式进行筛选，然后扇出到一个或多个目标（SNS、Lambda、SQS、Kinesis Data Firehose、Step Functions、Systems Manager）。
一个将高严重性 GuardDuty 检测结果同时转发到用于电子邮件的 SNS 主题和用于分析并馈送到 OpenSearch 的 Firehose 交付流的典型模式：
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}
将 Security Hub CRITICAL 级别的检测结果路由到电子邮件：
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": { "Label": ["CRITICAL"] },
"Workflow": { "Status": ["NEW"] }
}
}
}
电子邮件终端节点是一个简单的 SNS 订阅；订阅者必须通过电子邮件中的链接进行确认，交付才会开始。单个规则最多可以有五个目标，因此警报和下游分析不需要重复的规则。
在编写模式时，请记住 CloudTrail 管理事件到达时带有 "detail-type": "AWS API Call via CloudTrail"，而数据事件不会出现在默认总线上，除非您配置一个将日志发布到 CloudWatch Logs 的跟踪，并使用指标筛选器或通过 EventBridge 的 CloudTrail 数据事件集成进行订阅。如果在未启用数据事件的情况下，在默认总线上编写一个匹配 "eventName": "PutObjectAcl" 的 EventBridge 规则，会产生零匹配。
CloudWatch Logs、Insights、指标筛选器和警报
将 CloudTrail（以及 VPC Flow Logs 和应用程序日志）发送到 CloudWatch Logs 可以实现近乎实时的检测。指标筛选器 (Metric filters) 会根据模式扫描每个传入的日志事件，并为一个自定义的 CloudWatch 指标增量；基于该指标的 CloudWatch 警报 (CloudWatch alarm) 会触发 SNS。
示例：针对重复的控制台登录失败设置警报。
aws logs put-metric-filter \
--log-group-name /aws/cloudtrail/org \
--filter-name ConsoleSignInFailures \
--filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
--metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1
CloudWatch Logs Insights 提供使用专用查询语言的即席查询功能，这在警报触发后进行事件响应时非常有用：
fields @timestamp, userIdentity.arn, sourceIPAddress, eventName
常见陷阱
缺少 S3 对象级活动：
PutObjectAcl、GetObject和DeleteObject属于数据事件。默认的跟踪只捕获管理事件；您必须添加数据事件选择器，否则针对这些 API 名称的发现、警报或 EventBridge 规则将静默地永不触发。没有委托管理员的集中可见性： 在每个账户中启用 GuardDuty 或 Security Hub 并不会聚合结果。只有在 AWS Organizations 中注册了委托管理员，并且（对于 Security Hub）选择了聚合区域之后，调查发现才会集中汇集。跨账户邀请适用于小型环境，但无法扩展，并且需要每个账户接受邀请。
筛选器中对管理事件与数据事件的混淆：
PutBucketAcl（存储桶）是管理事件，可在任何标准的 EventBridge 或指标筛选器中工作；而PutObjectAcl（对象）则不行，无论模式设计得多好，除非启用了数据事件并将其传送到相同的管道。
实践问题：用例场景
场景： Meridian Financial 公司运营着一个多账户的 AWS Organization，其中包含一个专用的安全账户和一个集中的日志记录账户。他们的环境中，S3 存储着客户的个人身份信息 (PII)，EC2/Lambda 上运行着事务性 API，并且 CloudTrail 已经将管理事件写入一个中央 S3 存储桶；团队希望实现更快的检测和跨账户的协同响应。
挑战： 安全工程师检测到 S3 GET 操作突然激增，以及相关的 GuardDuty 调查发现表明可能存在数据泄露，但告警信息过多且缺乏关联的 CloudTrail 上下文和跨账户的自动遏制措施。
推荐方法：
- 在每个成员账户中启用 Amazon GuardDuty，并将安全账户指定为 GuardDuty 的委托管理员；启用 S3 数据事件保护，以便调查发现中包含对象级别的访问异常。
- 为每个账户配置 CloudTrail，将管理事件传送到中央 S3 存储桶以供留存，并将选定的高价值数据事件（S3 GetObject/PutObject/DeleteObject 和 Lambda Invoke）转发到安全账户中的 CloudWatch Logs，以进行低延迟检查。
- 在安全账户中开启 AWS Security Hub，并启用与成员账户的跨账户聚合，以便将 GuardDuty 调查发现、源自 CloudTrail 的调查发现以及 Config/Inspector 的结果进行集中和规范化处理。
- 创建 EventBridge 规则，匹配高严重性的 GuardDuty 和 Security Hub 调查发现，并将它们路由到 SNS 以发送告警通知，同时路由到一个修复 Lambda，该 Lambda 利用 CloudTrail 上下文采取遏制措施（撤销 API 密钥、移除 IAM 会话、隔离 EC2 ENI）。
- 添加 CloudWatch Logs 指标筛选器，用于检测按 IAM 主体范围划分的异常
s3:GetObject速率，并设置一个警报来触发相同的 EventBridge/SNS/Lambda 管道；在安全账户中使用 CloudWatch Logs Insights 查询，通过关联的 CloudTrail 事件来丰富告警信息，以进行事件分类。
基本原理： 集中化调查发现（GuardDuty + Security Hub）并将目标 CloudTrail 数据事件发送到 CloudWatch，可以通过 EventBridge/SNS/Lambda 实现低延迟的关联、告警和自动遏制——这与 AWS 在检测、跨账户聚合和自动响应方面的最佳实践相一致。
集中的 CloudTrail 与日志完整性
CloudTrail 是 AWS API 活动的权威记录，任何审计架构的基础都是一个单一的多区域跟踪 (multi-Region trail)，它将日志传送到一个集中的 S3 存储桶，理想情况下该存储桶位于 AWS Organizations 内一个专用的日志归档账户中。多区域跟踪会自动捕获当前每个区域以及 AWS 未来推出的任何新区域中的管理事件——而单区域跟踪一旦有工作负载在其他地方启动，就会产生盲点，这是审计过程中典型的完整性失败。当在组织层面应用时，该跟踪还会捕获每个成员账户的事件，因此新加入组织的账户无需任何单账户配置即可被覆盖。
在跟踪上启用日志文件验证。启用后，CloudTrail 每小时会向同一个 S3 存储桶传送一个签名的摘要文件，其中包含已传送日志文件的 SHA-256 哈希值。aws cloudtrail validate-logs 命令会遍历摘要链并检测篡改、删除或间断。如果没有验证，防御方无法证明日志在事后未被更改，这将使其作为法庭证据失效。
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name corp-audit-logs \
--is-multi-region-trail \
--is-organization-trail \
--enable-log-file-validation \
--kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail
传送失败几乎总是下游的权限问题，而不是 CloudTrail 的缺陷。S3 存储桶必须在创建跟踪之前就存在，其存储桶策略必须授予 cloudtrail.amazonaws.com s3:PutObject 权限，并带有与该跟踪匹配的 aws:SourceArn 条件，并且对象所有者必须是存储桶所有者 (bucket-owner-full-control)。如果跟踪使用 SSE-KMS，CMK 策略必须为 CloudTrail 服务主体允许 kms:GenerateDataKey*，并且每个使用者（Athena、安全工程师、Lambda 解析器）都必须拥有对该密钥的 kms:Decrypt 权限。一个常见的故障模式是：日志传送正常，但 Athena 查询返回 “AccessDenied”，因为查询角色缺少对日志加密 CMK 的 Decrypt 权限。应通过修改密钥策略来修复此问题，而不是禁用加密。
CloudWatch Logs、指标筛选器和实时警报
CloudTrail 以 5 到 15 分钟的批次将日志交付到 S3——这对于回顾性审计来说足够了，但对于实时检测来说太慢。要对敏感事件进行警报，可以将跟踪日志流式传输到 CloudWatch Logs（一个跟踪选项），或通过 EventBridge 路由特定事件。CloudWatch Logs 方法使用指标筛选器 (metric filters)，它通过模式匹配 JSON 事件并递增一个 CloudWatch 指标，该指标进而驱动 CloudWatch 警报和 SNS 通知。典型的例子是根用户控制台登录：
{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }
对于范围狭窄、众所周知的事件（如 KMS 密钥禁用、IAM 策略变更），EventBridge 通常是更好的选择，因为其规则可以直接触发 Lambda 或 Step Functions，而不会产生任何 Logs 成本。当您需要聚合计数或仪表板展示时，请使用指标筛选器。
CloudWatch Logs 的保留期默认为永不过期 (Never Expire)，这成本高昂且很少是正确的选择。应根据合规性制度为每个日志组设置明确的保留策略（aws logs put-retention-policy）——通常是在 CloudWatch 中保留 90 天热数据，并通过订阅筛选器或 Kinesis Data Firehose 在 S3 中进行长期归档。
为了保障敏感数据的卫生，应在账户级别应用 CloudWatch Logs 数据保护策略。这些策略使用托管数据标识符（如信用卡号、AWS 密钥、SSN）在摄取时屏蔽匹配的字符串。至关重要的是，取消屏蔽需要 logs:Unmask 权限；仅应将此权限授予“紧急破窗”角色。能够读取日志组但缺少 Unmask 权限的用户只能看到星号。账户范围的策略适用于所有当前和未来的日志组，这是正确的控制方式——随着新服务创建新组，按组设置的策略会产生偏差。
大规模日志查询：Insights 和 Athena
两种查询引擎针对不同层级的数据。
CloudWatch Logs Insights 使用一种专用的查询语言来查询已存在于 CloudWatch Logs 中的数据。它非常适合查询近期的操作数据（如 Lambda 日志、在 Logs 中的 VPC Flow Logs、应用程序日志）。其优点是速度快，无需设置 schema，但受 CloudWatch 保留期和每 GB 扫描成本的限制。
Amazon Athena 在 S3 中的数据上运行 Presto/Trino SQL。它非常适合对 CloudTrail、ALB 访问日志、存储在 S3 中的 VPC Flow Logs 以及 CloudFront 日志进行大规模的取证查询。其成本为每 TB 扫描 5 美元；使用分区投影 (partition projection) 或基于日期/区域的 Glue 分区可以大幅削减扫描成本。
一个典型的取证用例是：识别谁禁用了某个 KMS 密钥。由于 CloudTrail JSON 是嵌套的，由 CloudTrail 创建的 Athena 表将 userIdentity 公开为一个结构体 (struct)：
SELECT eventTime,
userIdentity.arn AS principal,
userIdentity.sessionContext.sessionIssuer.arn AS assumed_role,
userIdentity.sessionContext.attributes.mfaAuthenticated AS mfa,
sourceIPAddress,
requestParameters
FROM cloudtrail_logs
WHERE eventName = 'DisableKey'
AND eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';
对于 ALB 机器人分析，可以启用 ALB 访问日志到 S3，在日志前缀上定义一个 Athena 表，然后与一个已知恶意 IP 的表进行连接，并在 QuickSight 中可视化聚合结果。QuickSight 从 Athena 读取数据，因此这个管道是：ALB → S3 → Athena → QuickSight。将 ALB 日志发送到 CloudWatch Logs Insights 不是一个受支持的原生路径——ALB 日志只能发送到 S3。
VPC Flow Logs 可以发送到任一目的地：对于 filter dstPort=3389 and action="REJECT" 这类战术性调查，选择 Logs；对于月度规模的趋势查询，选择 S3（使用 Parquet 格式并分区）。
Audit Manager 证据收集
AWS Audit Manager 自动化了持续的证据收集过程，并将其映射到 PCI DSS、HIPAA、SOC 2 和 CIS 等框架。它从 Config 规则、Security Hub 发现结果、CloudTrail 事件和资源清单中提取证据，并将其打包到控制评估中。在 Organizations 管理账户或委托管理员账户中启用时，它会跨所有成员账户收集证据，并生成一份评估报告——一个包含清单的证据压缩包——审计员会接受它来代替手动截图。当场景要求持续、多账户、与框架对齐的证据时，这便是正确答案：单独使用 Config 只能提供资源合规性，但没有框架映射；Security Hub 提供发现结果，但没有评估打包功能；自制的 Athena 报告不是持续性的。
易错点回顾
日志丢失通常不应归咎于 CloudTrail：可能是存储桶不存在，存储桶策略拒绝了 CloudTrail 主体，或者对象所有权配置错误。应首先检查 S3。
单区域跟踪看起来更便宜，但会产生不完整的审计历史；对于组织范围的覆盖，多区域是默认的正确答案。
经 SSE-KMS 加密的日志对 Athena、Lambda 解析器或工程师是不可见的，除非 CMK 策略向这些主体授予
kms:Decrypt权限——禁用加密不是解决方案；修正密钥策略才是。
实践问题：用例场景
场景： Meridian Financial 公司运行一个多账户的 AWS Organization，其中包含生产、预发布和一个专用的日志记录账户。他们的环境托管了面向客户的 API、分析系统以及由 IAM 管理的密钥，并且他们需要集中化、防篡改的日志记录以及快速调查工具，以支持事件响应和合规性请求。
挑战： 最近一系列可疑的控制台登录和 IAM 策略变更在数小时内未被发现，并且有人担心日志完整性和及时告警不足以支持取证重建和 Audit Manager 的证据收集。
推荐方法：
- 在所有区域启用 AWS Organizations CloudTrail（组织跟踪），开启 CloudTrail 日志文件完整性验证，将日志和摘要文件交付到集中的 S3 存储桶，该存储桶使用 KMS CMK 加密，其密钥策略将解密权限限制给一个小的安全团队，并启用 S3 访问日志记录和版本控制。
- 配置 CloudTrail 将管理事件和选定的数据事件流式传输到 CloudWatch Logs，然后为高风险模式（例如来自新 IP 的控制台登录失败、CreateUser、PutRolePolicy）创建 CloudWatch Logs 指标筛选器，并将 CloudWatch Alarms 附加到 SNS 主题，用于发送告警通知和触发自动化的 Lambda playbook。
- 部署 CloudWatch Logs Insights 控制面板，用于对近期事件进行交互式调查，并在日志记录账户中设置保留和生命周期规则，以根据策略保留证据。
- 使用 AWS Glue 对 CloudTrail S3 对象进行编目，并运行 Athena 查询（按区域/日期/服务分区）以进行大规模的回溯性分析，并为调查人员生成 CSV 格式的证据导出文件。
- 创建一个 AWS Audit Manager 评估，自动将 CloudTrail、AWS Config 和 IAM 的证据收集到一个证据文件夹中，并为合规审查员安排定期导出。
基本原理： 集中化和验证 CloudTrail，流式传输到 CloudWatch 以实现实时指标筛选和告警，以及使用 Athena/Logs Insights 进行可扩展查询，这些都遵循了 AWS 在检测、不可变日志记录和取证准备方面的最佳实践，而 Audit Manager 则为审计自动化了证据收集过程。
← 威胁检测与告警 · 所有领域 · 加密、KMS 与密钥 →
练习这些题目 → · 在 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.
通过考试 →