📚 课程目录第3章 CloudTrail控制台入门

CloudTrail 控制台入门：创建第一个追踪

说实话，很多刚接触 AWS 的朋友一上来就写 CLI 或 Terraform，结果连日志往哪儿发都搞不清楚。我自己的习惯是先到控制台里点一遍，把概念摸透了再自动化。这一章我们就从 CloudTrail 控制台 入手，创建一个最简单的追踪，同时把存储位置——S3 桶——配明白。

为什么先拿控制台开刀？

两个原因：
第一，控制台把 CloudTrail 的核心配置选项都摊开了，你一看就知道“追踪”是什么、日志存哪儿、要不要加密；第二，我在项目里见过有人直接复制网上的 Terraform 代码，结果忘了配 S3 桶策略，日志一条都没写进去……嗯，控制台能帮你先理解这些依赖关系。

追踪（Trail）到底是什么？

我习惯把它理解成一个 “日志路由器”。你创建一个追踪，就等于告诉 CloudTrail：“从现在开始，把特定区域（或全区域）的管理事件、数据事件、洞察事件，统统发到这个 S3 桶里。” 你想想看，没有追踪，CloudTrail 虽然也会默认保存 90 天的事件，但那只是在 CloudTrail 事件历史里，没法长期归档、没法跨账号投递。

    一句话记住： 追踪 = 日志采集规则 + 存储目的地。创建追踪是长期审计的第一步。

创建第一个追踪：分步走

下面我带你走一遍标准流程。我用的是 AWS 管理控制台（us-east-1 区域）。

进入 CloudTrail 控制台 – 搜索 “CloudTrail”，点击 “Create trail”。
填追踪名称 – 我给个建议：my-audit-trail，简单直白。
选择存储位置 – 默认 “Create new S3 bucket”，CloudTrail 会自动帮你建一个桶，名字像 aws-cloudtrail-logs-123456789012-abc123。我个人习惯改成有意义的名称，比如 my-company-cloudtrail-logs，但注意桶名必须全局唯一。
日志文件前缀（可选） – 我通常会填 CloudTrail/ 或 audit/，这样后面在 S3 里好按前缀做生命周期策略。
开启日志文件 SSE-S3 加密 – CloudTrail 默认用 SSE-S3 加密日志。你如果合规要求高，可以选 SSE-KMS，但需要额外配 KMS 策略。这次我们先用默认。
勾选事件类型 – 默认只记录 “Management events”（管理事件）。要审计 IAM Changes 或 VPC 改动，这个就够了。要记录 S3 GetObject 这种数据事件，需要额外勾选，但会产生大量日志。
应用范围 – 选 “All regions” 还是 “One region”？审计场景强烈建议选 所有区域，不然你换个区域就漏日志了。我吃过这个亏，后来专门写了个脚本检查每个区域是否有全区域追踪。
创建 – 点 “Create trail”，完成。

小技巧： 创建完成后，CloudTrail 会立即把当前区域的最近管理事件写入 S3。等 5 分钟，去 S3 桶里看看 CloudTrail/AWSLogs/123456789012/CloudTrail/us-east-1/YYYY/MM/DD/ 目录下有没有 .json.gz 文件。

配置存储位置：S3 桶的那些门道

日志存进 S3 桶只是第一步。桶的权限、生命周期、跨区域复制这些才是容易踩坑的地方。

配置项	默认值	建议
桶策略（自动生成）	只允许 CloudTrail 服务写入	不要手动修改，除非你知道自己在干什么
日志文件前缀	无	推荐设置，方便后续做生命周期管理和跨账号授权
SSE-S3 加密	开启	最低要求，审计合规一般够用
SSE-KMS 加密	可选	如果组织有 KMS 密钥轮换要求，用这个
日志文件验证	关闭	我建议开启，能保证日志文件的完整性和防篡改

曾经有一家客户，把 CloudTrail S3 桶加了非常严格的 Deny 策略，结果 CloudTrail 没法写入日志，连续三天一条记录都没有。排查了半天才发现是桶策略里写死了 aws:SourceArn 但没加自己的追踪 ARN。嗯，这里要注意：千万不要在桶策略里限制 CloudTrail 服务主体只能写入某个具体的路径，除非你非常清楚 aws:SourceArn 的格式（它其实指向的是追踪的 ARN，不是桶的路径）。

避坑指南（个人经验）

账户 ID 错误 – 如果你用的是跨账号投递，目标桶策略里必须写对源账号的 ID。我曾经写错一位数字，日志全丢了。
区域限制 – 选择“仅单区域”时，如果你在另一个区域做了高危操作，CloudTrail 不会记录。审计审计，审不全等于没审。
数据事件成本 – 开启 S3 或 Lambda 的数据事件后，日志量可能暴增 10 倍。成本控制记得提前算。
日志保留 – 默认 S3 桶没有自动删除策略。如果合规要求保留日志 7 年，记得加生命周期策略，否则存储费用会吓到你。

⚠️ 重要： 日志文件默认存储为 .json.gz，审计工具（如 Athena、Elasticsearch）可以直接读取。但不要擅自解压再存回去——CloudTrail 的日志完整性校验用的是原始文件哈希。

核心流程一览

下图帮你理清创建追踪到日志落盘的全过程：

创建追踪后的验证清单

创建完别急着走，我每次都会做下面这 4 件事：

等 2 分钟，去 S3 桶对应前缀下看看有没有 .json.gz 文件出现。
下载一个日志文件，用 gunzip 解压后确认 JSON 结构完整，包含 eventSource、eventName、userIdentity 等字段。
手动触发一条管理事件（比如创建一个空的 S3 桶），然后去 CloudTrail 事件历史里比对是否出现在 S3 日志里。
检查桶策略 – 在 S3 控制台的 “Permissions” -> “Bucket Policy” 里确认 CloudTrail 服务主体有 s3:PutObject 权限。

    我的个人习惯： 创建完第一个追踪后，立刻在 CloudWatch 里设一个事件告警：如果 1 小时内没有新的日志文件写入 S3，就发 SNS 通知。这样日志一断你马上知道，不用等审计的时候才发现空白期。

好了，这就是创建第一个追踪的全部内容。说白了，CloudTrail 的控制台入口就是让你以最少的配置把日志路径跑通——后面我们可以慢慢引入组织级追踪、日志分析、甚至用 Athena 直接查询，但前提是得先有一个正常工作的追踪。上面的步骤你跟着做一次，就能看到 AWS 账户里的“黑匣子”是怎么转起来的。