CloudTrail 记录的内容

AWS 中的每项操作都是一次 API 调用，无论该调用来自控制台、CLI、SDK 还是其他服务。AWS CloudTrail 会记录这些调用。

它是一份审计记录，能够回答关键的安全问题：谁在何时、从哪里对哪个资源执行了什么操作。这是账户责任追踪的基础。

每个 CloudTrail 事件都会记录丰富的详细信息：发起调用的身份、操作（事件名称）、时间、源 IP、参数以及响应。

这些信息足以准确还原事件期间发生的情况，并将每项更改归因于特定主体。

CloudTrail 会自动在事件历史记录中记录最近 90 天的管理事件活动，无需进行设置。

如需更长的保留时间和完整控制，您可以创建一个跟踪，持续将事件传送到 S3。考试要求您了解默认的 90 天历史记录与已配置跟踪之间的区别。

跟踪会捕获事件并将其传送到 S3 存储桶进行长期存储，也可以选择将其传送到 CloudWatch Logs 进行实时分析。

您通常应创建覆盖多个区域、面向整个组织的跟踪，以确保任何区域中的活动都不会漏记。这是调查事件时使用的持久且可查询记录。

userIdentity 元素会将每次调用关联到一个主体，例如 IAM 用户、担任的角色、根用户或 AWS 服务。

在调查期间，这些信息非常宝贵：即使凭证是通过角色链担任的，您也可以根据它追溯到执行可疑操作的确切凭证和会话。

这两者很容易混淆。CloudTrail 回答的是“谁进行了哪次 API 调用”，也就是操作的审计日志。

CloudWatch 回答的是“我的系统运行状况如何”，也就是有关运行状况的指标、日志和告警。CloudTrail 可以将事件发送到 CloudWatch Logs，但两者的用途不同。

配置错误的单区域跟踪会留下盲区，攻击者可以在未监控的区域中活动并利用这些盲区。

启用多区域跟踪可以确保在一个位置捕获所有区域中的活动。AWS 建议将其作为基线配置，以免任何区域未接受审计。

能够删除日志的攻击者可以隐藏踪迹。请使用日志文件验证保护 CloudTrail（摘要文件可以证明日志未被更改），并通过严格的策略和对象锁定保护 S3 目标位置。

请将日志存储在单独的账户中，以免工作负载遭到入侵后能够访问这些日志。

将跟踪事件传送到 CloudWatch Logs 后，您就可以近乎实时地做出响应：指标筛选器和告警可以针对特定操作触发，例如安全组更改或根用户登录。

这连接了审计日志记录与主动监控，将历史记录转变为实时检测。

跟踪通常会在 API 调用后的约 15 分钟内将事件传送到 S3。它持久且可靠，但不是即时的。

如需更快响应，请将事件流式传送到 CloudWatch Logs，这样告警就能近乎实时地触发。请注意，CloudTrail 首先是一种审计记录，本身并不是毫秒级延迟的告警系统。

CloudTrail 是检测、调查和合规工作的基础。许多 SCS-C02 场景都要求您正确启用它、保护其日志，并查询日志以查明发生了什么。

如果题目询问如何找出是谁删除了资源或更改了策略，CloudTrail 几乎总是答案的一部分。

了解 CloudTrail 的用途。

AWS CloudTrail 是您账户的审计记录，会记录每次 API 调用的调用者身份、操作、时间、源 IP 和参数。默认情况下，它会在事件历史记录中保留 90 天的管理事件；您可以创建多区域跟踪，将日志保存到 S3，以便持久保存和查询。它与 CloudWatch（用于性能监控）不同，CloudTrail 用来回答谁做了什么。您可以通过日志文件验证、对象锁定和单独账户来保护日志，并将日志流式传输到 CloudWatch Logs，以实现实时告警。