3. 常见SaaS服务日志源：AWS CloudTrail, Azure Monitor, GCP Logging
大家好，总算讲到这章了。说实话，搞SaaS安全，最关键也是最头疼的就是日志源。
你想想看，现在几乎每个企业都在用云，AWS、Azure、GCP，至少占一个。这些云平台会生成海量的操作日志，但它们各自的格式、采集方式和存储策略，差异不是一般的大。
我个人习惯把这三家叫做“日志三巨头”。今天，咱们就把它们挨个拎出来，看看日志到底从哪儿来，长什么样，怎么拿。
3.1 AWS CloudTrail：云上操作的“黑匣子”
AWS CloudTrail，是AWS自家的审计服务。说白了，它记录的是谁在什么时间，通过什么方式，对AWS资源做了什么操作。
我记得刚接触CloudTrail那会儿，总觉得它就是个开关，打开就完事了。结果项目上线第二天，安全团队问我“昨天凌晨有没有人改了安全组的规则？”我一看，CloudTrail只记录了部分事件，关键的管理事件根本没开。
好，咱们来看它的核心机制。
- 管理事件：创建、删除、修改EC2、S3、IAM等资源的操作。这是默认开启的。
- 数据事件：针对S3对象、Lambda函数的操作，比如GetObject、PutObject。这个默认不开启，需要手动配置，而且会大幅增加日志量。
- Insights事件：检测异常活动，比如突然增加的API调用量。这玩意儿用的不多，但挺贵。
3.2 Azure Monitor：微软家的“大管家”
Azure Monitor，跟CloudTrail不太一样。它是一个全家桶，负责收集、分析、响应整个Azure环境和本地环境的监控数据。
日志只是它的一部分，叫Activity Log（活动日志）和Diagnostic Settings（诊断设置）。
我曾经在Azure上栽过跟头：只配了Activity Log，觉得就齐活了。结果数据库的查询慢日志、错误的网络流量日志，啥也没抓到。后来才发现，Diagnostic Settings 需要逐个资源类型去配置。
说白了，Activity Log只管“谁改了什么”，而Diagnostic Settings记录“资源本身发生了什么”。
下表是Activity Log的分类，得搞清楚。
| 类别 | 说明 | 示例 |
|---|---|---|
| Administrative | 资源管理操作（创建、更新、删除） | 创建虚拟机、修改NSG规则 |
| Service Health | Azure服务本身的状态变化 | 某区域服务中断、维护通知 |
| Alert | 由Azure Monitor告警触发的记录 | CPU超过90%触发的告警 |
| Autoscale | 自动缩放操作 | VMSS实例数从3台变成5台 |
| Recommendation | Azure Advisor给出的建议 | 建议启用备份、建议调整SKU |
3.3 GCP Cloud Logging：简洁但功能强大
GCP Cloud Logging，以前叫Stackdriver Logging。GCP的风格一向是“让开发者爽”，日志也不例外。它默认开启很多审计日志，而且跟其他GCP服务集成得非常好，比如BigQuery、Pub/Sub。
GCP的审计日志分三类：
- Admin Activity audits：管理活动审计，记录配置变更。这是默认开启且免费的。
- Data Access audits：数据访问审计，记录读取或修改用户数据。这玩意默认关闭，而且需要额外付费。
- System Event audits：系统事件审计，记录GCP底层基础设施的操作。这个咱们一般管不了，也不用管。
我曾经有个项目，业务方要求“记录所有对BigQuery数据集的查询”。我啪的一下开了Data Access审计，结果一天之内日志量暴涨了10倍，存储费直接起飞。
后来发现，GCP的Data Access审计是粗粒度的，一旦开启，所有项目成员的所有数据读取操作都会被记录。建议先评估业务影响，再决定开启范围。
嗯，这点很重要：能用过滤器就别开全量。
3.4 三大日志源对比：你不能不知道的差异
咱们来个表格，快速对比一下。这次我真的觉得，没有对比就没有伤害。
| 特性 | AWS CloudTrail | Azure Monitor (Activity Log) | GCP Cloud Logging |
|---|---|---|---|
| 默认启用 | 管理事件（90天保留） | Administrative事件（90天保留） | Admin Activity审计（默认开启） |
| 数据访问日志 | 需手动开启，可精细配置 | 需通过Diagnostic Settings配置 | 需手动开启，粗粒度，需谨慎 |
| 保留周期 | 默认90天，可通过S3延长 | 默认90天，可通过Log Analytics延长 | 默认30天，可通过导出到BigQuery/S3延长 |
| 导出方式 | 自动交付到S3桶 | 可发送到Event Hub或存储账户 | 可导出到Cloud Storage、BigQuery |
| 事件延迟 | 约10-15分钟 | 约5-10分钟 | 约5分钟以内 |
| 成本模型 | 按日志量付费，S3存储另算 | 按日志量+Ingestion收费 | 按日志量+存储天数收费 |
3.5 统一的归集思路：别被三家牵着鼻子走
你会问：这三家日志格式、字段名都不同，难道我写三个不同的解析器？
当然不。我建议你做一个统一的日志语义层。先归一化字段，再统一存储和分析。
下面这张图，就是我个人在项目里沉淀下来的架构。你可以照着画。
把CloudTrail、Azure Monitor、GCP Cloud Logging的日志拉到统一的存储里。
然后，管你 AWS 还是 Azure，在分析层看起来都一样。
你想想，如果在SIEM里还要写三个不同的查询语法，那得多痛苦。
嗯，今天就先到这儿。这三大日志源，是后续所有安全分析的基础。搞不定它们，后面的告警溯源、权限审计，全都没法落地。