1. CloudTrail 概述：审计的起点

好，咱们直接进入正题。聊 AWS 审计，CloudTrail 是绕不开的第一个坎。

我刚开始接触 AWS 安全审计那会儿，说实话，面对一堆服务日志挺懵的。但摸爬滚打下来发现——CloudTrail 就是 AWS 审计的数据主干。说白了，没有它，你的审计报告就是空中楼阁。

什么是 CloudTrail？

CloudTrail 是 AWS 提供的一项托管服务。它专门用来记录你 AWS 账户下的所有 API 调用活动。你想想看——在 AWS 里，任何操作，不管是点控制台、跑 CLI 命令、还是 SDK 自动调用，本质上都是一次 API 请求。CloudTrail 就负责把这些请求全记下来。

它会记录谁（IAM 用户/角色）、在什么时候、通过什么方式、对哪个资源、做了什么事。这套日志就是我们常说的审计日志（Audit Log）或活动轨迹。

核心功能拆解

CloudTrail 的核心能力，我归纳为四个字：全、准、久、通。

功能模块	说明	我的经验值
全量记录	记录管理事件（Management Events），包括控制台、CLI、SDK、第三方工具发起的 API 调用。默认涵盖绝大多数 AWS 服务。	我曾遇到一个客户声称「没人动过 S3 权限」，结果 CloudTrail 一查，是某条自动化脚本误刷了策略。没有全量记录，这种锅甩都甩不干净。
精准溯源	每条日志都包含调用者身份（ARN）、源 IP、用户代理、请求参数、响应码等关键信息。	有一次线上故障排查，就是靠「源 IP」字段揪出了一个恶意的外部访问请求。精准溯源在安全事件中特别管用。
长期存储	通过创建 Trail 将日志持续写入 S3，支持不限期保存。可配合生命周期策略自动归档到 Glacier。	合规审计通常要求保留日志 1-7 年。CloudTrail + S3 + 生命周期策略，是成本最优的标准方案。
无缝集成	日志可自动送达 CloudWatch Logs（实时监控/告警）、S3（长期存储/分析）、Athena（SQL 查询分析）和 EventBridge（事件驱动自动化）。	我现在几乎每个项目都会配一条流到 CloudWatch 的日志组，配合 Metric Filter 做关键操作告警，效果很好。

CloudTrail 与 AWS 审计的关系

这个点很重要，我多说两句。

AWS 审计，本质上回答三个问题：谁？做了什么？什么时候做的？CloudTrail 就是回答这三个问题的数据源头。

你可以把 CloudTrail 想象成一个数字监控摄像头——它架在你 AWS 账户的「大门口」，拍下每一个进出的人和他们的一举一动。而审计，就是回放这些录像，检查有没有「不该做的事」或者「该做却没做的事」。

我个人习惯用这个简单的映射关系来理解：

• CloudTrail 提供「事件日志」 —— 记录操作行为本身
• 审计是「规则判断」 —— 对比日志检查是否合规
• 存储方案是「证据保全」 —— 让日志不被篡改且可长期查询

这三个环节，环环相扣。CloudTrail 是基础，存储方案是保障，审计才是目的。

一张图看懂整体逻辑

好了，咱们用一张 SVG 结构图，把 CloudTrail 在整个审计体系中的位置和核心流程串一遍。

嗯，这张图你看明白了吗？从左侧的多个操作入口，统一汇入 CloudTrail 服务，再分发到不同的下游目的地，最终支撑起安全审计与合规这个终极目标。这条路，就是咱们这门课要一步步搭建的核心架构。

避坑环节：刚开始容易犯的错

最后，分享几个我踩过的坑。

• 千万别以为默认开启就够了。默认的 Event History 只保留 90 天，一旦超过就自动丢弃。合规审计要求至少保留 1 年甚至更久。所以——第一件事就是创建一条 Trail，指向 S3。
• 别把所有日志都放在一个 S3 桶里。多账户架构下，我建议用组织级 Trail（Organization Trail），统一投递到中央审计账户。不然等审计师找你要日志，一个一个账户去翻，你会崩溃。
• 注意「数据事件」的额外费用。CloudTrail 默认只记录管理事件（免费）。如果你要审计 S3 对象级别的 GET/PUT，或者 Lambda 的调用记录，那是要付费的——而且量很大。我建议只开启关键桶的 Data Event，别一股脑全开。