第四章：云日志体系概述 – CloudTrail 与 Azure Monitor 的“家底”
做云安全审计这么多年，我每次拿到新客户的账户，第一件事就是看他们的日志配置。说白了，日志就像黑匣子，没有它，出了事你连怎么查都不知道。AWS 和 Azure 的日志体系看似类似，实则有挺多细节。
我个人习惯把日志体系拆成两层：管控面日志和数据面日志。CloudTrail 和 Azure Monitor 各自管哪一层？它们能覆盖多深？今天咱们就来盘一盘。
1. AWS CloudTrail：谁动了我的 API？
CloudTrail 是 AWS 的审计日志服务。它记录的是谁、在什么时间、从哪个 IP、调用了什么 API。嗯，我遇到过不少架构师以为 CloudTrail 可以记录数据库里的 SQL 语句，其实不是的——它只管管控面。
- Event（事件）：每次 API 调用就是一个事件。比如启动 EC2、修改 S3 桶策略。
- Trail（追踪）：一条 Trail 决定将哪些 Region、哪些服务的事件发送到 S3 或 CloudWatch Logs。
- Management Events（管理事件）：控制台、CLI、SDK 的操作，默认开启。
- Data Events（数据事件）：对 S3 对象、Lambda 函数的操作。你想想看，默认是 不记录 的，得手动开启，而且会烧钱。
- Insights Events（洞察事件）：异常 API 调用的自动检测。我一般建议客户至少开一个 Management Trail 全局抓全。
我记得有一次排查安全事件，客户说“我们在 CloudTrail 里没找到删除记录”，结果一查——他没有开启 Data Events，S3 文件被删根本记不下来。嗯，这是个非常经典的坑。
2. Azure Monitor：日志大熔炉
Azure 这边的日志体系比 AWS 更“糊”。Azure Monitor 是全家桶，里面包了 Activity Log、Diagnostic Settings、Metrics、Log Analytics Workspace 等等。
- Activity Log（活动日志）：相当于 CloudTrail 的 Management Events，记录资源管理操作，保留 90 天。
- Diagnostic Settings（诊断设置）：你要手动给每个资源配诊断设置，才能把 平台日志 和 指标 送到 Log Analytics、Storage Account 或 Event Hub。
- Resource Logs（资源日志）：比如 Key Vault 的审核日志、NSG 流量日志。这就像 CloudTrail 的 Data Events，但资源类型不同，层级也分散。
- Log Analytics Workspace：集中查询和分析的地方，类似 AWS 的 CloudWatch Logs Insights。
说白了，Azure 把“日志”这件事决策权扔给了用户。你如果不配诊断设置，很多关键日志根本不会流出。我见过一个项目，Key Vault 审计日志一直没开，出事后发现 Activity Log 里没有任何细粒度记录——白费功夫。
3. 核心差异对照
| 维度 | AWS CloudTrail | Azure Monitor (Activity Log + Diagnostic) |
|---|---|---|
| 管控面事件 | Management Events（默认开启，全局） | Activity Log（默认开启，90 天保留） |
| 数据面事件 | Data Events（需手动开启，按量计费） | Resource Logs（需手动配置 Diagnostic Settings） |
| 事件存储 | S3（JSON） + CloudWatch Logs（可选） | Log Analytics Workspace / Storage Account / Event Hub |
| 查询方式 | CloudTrail Console（90 天），或 Athena 查 S3 | Log Analytics KQL 查询 |
| 事件保真度 | 每个 API 调用一条记录，字段丰富 | Activity Log 字段较粗，Resource Log 字段因资源而异 |
| 跨区域能力 | 支持多 Region 的 Trail，单 Trail 可覆盖所有 Region | 每个资源的诊断设置各自独立，无全局开关 |
| 成本控制 | Data Events 可能很贵；Management Events 免费 | Activity Log 免费；Resource Log 依据 Workspace 数据引入量收费 |
你看这个表就能发现，AWS 用 Trail 做全局抽象，Azure 则要求你逐个资源去配置。这个差异在跨账号、多云场景下特别折磨人。我曾经帮一个跨国客户做双云日志统一，AWS 几分钟就能配好全局 Trail，Azure 那边光识别哪些资源要开诊断设置就花了两天。
4. 一张图看懂：CloudTrail 与 Azure Monitor 的日志流向
下面这张 SVG 图展示了两个平台的核心日志路径，以及它们之间的对应关系。你可以快速定位每个组件属于管控面还是数据面。
5. 一些避坑经验
我结合这些年踩过的坑，给你列几个关键注意点：
- 不要以为默认就够了。Azure Activity Log 默认只保留 90 天，且不包含数据面。AWS Management Events 虽然保留在 CloudTrail 控制台里能查 90 天，但 S3 里的文件是永久的——前提是你别删。我曾经遇到过客户把 S3 生命周期策略设为 30 天自动过期，结果审计窗口直接归零。
- 数据面日志千万记得开。不管是 AWS 的 Data Events 还是 Azure 的 Diagnostic Settings，默认都是 关闭 的。我曾经帮一个 SaaS 厂商做事故复盘，发现攻击者删了 S3 里的日志文件，但因为没开 Data Events，根本不知道谁删的。嗯，你想想看，一个日志系统连自己的日志被删都记不下来，多尴尬。
- 注意成本和性能。CloudTrail Data Events 是按事件次数计费的，高流量 S3 桶一个月可能多花上千美元。Azure 的 Log Analytics 则是按数据引入量收费，如果你配了 Verbose 级别的资源日志，账单会很刺激。我一般建议先在非生产环境跑一个月，估算后再上线。
- 跨区域策略要提前想好。AWS 一个 Trail 能覆盖所有 Region 和未来新增的 Region，非常省心。Azure 则没这种全局开关——每次新增一个 Region 的资源，你都得手动配诊断设置。如果不用 Azure Policy 或 Terraform 自动化，很容易漏。
6. 小结一下
CloudTrail 和 Azure Monitor 的日志体系，本质上是管控面与数据面的区分。AWS 用 Trail 统一管控，Azure 用 Diagnostic Settings 打补丁。你要根据组织规模、合规要求和预算来判断选哪个模式。我个人倾向于在 AWS 上至少花半小时配好全局 Trail + 组织级日志归档；在 Azure 上则先用 Azure Policy 和 Terraform 把诊断设置模板化，避免人肉配置。