CloudTrail 与日志记录归纳总结

好，前面我们拆解了桶策略的每一个字段，也看了 KMS 加密和 SSE-S3 的不同场景。这一章我把 CloudTrail 日志记录和桶策略之间的关键联系做个系统梳理。说白了，就是给你一张“检查清单”，以后配置的时候对着看就行。

CloudTrail 日志投递的核心链路

CloudTrail 把审计日志写到 S3 桶里，这过程涉及三个角色：CloudTrail 服务、目标 S3 桶、以及可选的 KMS 密钥。

• 日志来源：CloudTrail 服务代表你的 AWS 账户，向 S3 发起 PutObject 请求。
• 目标桶：预先指定的 S3 桶，必须允许 CloudTrail 写入。
• 加密层：要么用 SSE-S3（AWS 管理密钥），要么用 SSE-KMS（客户自主管理）。

关键点：桶策略必须显式允许 CloudTrail 服务主体 cloudtrail.amazonaws.com 的 s3:PutObject 操作。我在项目里见过有人只配了 Bucket Policy 允许自己的 IAM 用户上传，却忘了给 CloudTrail 服务授权，结果日志一条都进不来。

加密日志场景下的特殊策略检查项

当启用了 SSE-KMS 加密，桶策略之外还要多操心两件事：

1. KMS 密钥策略：必须给 CloudTrail 服务主体授予 kms:GenerateDataKey 和 kms:Decrypt 权限。
2. 桶策略中的条件键：如果你在桶策略里加了 s3:x-amz-server-side-encryption 或者 kms:EncryptionContext 条件，这些条件会直接影响日志写入。

日志失败排查的常见陷阱

我自己踩过的一个坑：配好了所有桶策略，日志依然报“Access Denied”。查了半天发现是 KMS 密钥策略没写 kms:GenerateDataKey。CloudTrail 先调用 KMS 生成数据密钥，失败后直接放弃写入，连错误日志都不往桶里写——你想想看，日志丢失的罪魁祸首竟然是密钥策略。

另外，桶的权限还受 S3 块公有访问设置的影响。如果你开了“阻止所有公有访问”，但桶策略里意外给了一个 NotPrincipal 的显式 Deny，也可能误伤 CloudTrail。嗯，这里要注意：aws:SourceArn 和 aws:SourceAccount 是推荐使用的条件键，可以防止混淆代理攻击。

最佳实践总结表

日志记录流程的可视化

下面这张图概括了加密日志从触发到落盘的全流程，以及策略检查点在哪。你可以把它贴在墙上当作检查清单。

桶策略配置的黄金法则

我把这几章的内容浓缩成三点：

• 最小权限原则：只给 CloudTrail 需要的 s3:PutObject 和 s3:GetBucketAcl（后者用于确认桶归属），不要给 s3:DeleteObject 或 s3:ListBucket。
• 条件锁死：用 aws:SourceArn 限定只能由特定 Trail 写入，防止其他服务误写。
• 加密需联动：用了 KMS 就别只用桶策略，KMS 密钥策略必须跟着改。