📚 课程目录第4章日志采集方式

第4章：日志采集方式——从云平台启用和获取KMS审计日志

日志拿不到，分析就是空谈。这一章我们聊聊怎么把三大云厂商的KMS审计日志真正“拉”出来。

我个人习惯先把日志的“源头”搞清楚，再动手配置。说白了，每个云平台的日志服务名字不一样，但核心逻辑差不多——都是先打开开关，然后把日志往一个存储桶或日志服务里送。你想想看，如果连开关都没开，后面再怎么折腾也白搭。

4.1 AWS CloudTrail —— 最成熟的审计日志服务

AWS的KMS操作会自动记录到CloudTrail里，但有个前提：你得先启用CloudTrail。嗯，这里要注意——默认只记录管理事件（Management Events），数据事件（Data Events）需要单独勾选。

小提示：KMS的密钥管理操作（CreateKey、ScheduleKeyDeletion等）属于管理事件，但用密钥加解密（Encrypt、Decrypt）属于数据事件。如果你只关心密钥生命周期，管理事件就够了；如果要追踪谁用了哪个密钥，必须开启数据事件。

启用步骤（一句话版）

进入CloudTrail控制台 → 创建或选择Trail
在“事件类型”里勾选“管理事件”和“数据事件”
数据事件中，选择“KMS”作为数据源，范围可选“所有密钥”或“特定密钥”
指定存储位置（S3桶）和日志文件前缀
（可选）启用CloudWatch Logs集成，方便实时告警

# 也可以用AWS CLI一次性搞定
aws cloudtrail create-trail \
  --name kms-audit-trail \
  --s3-bucket-name my-kms-logs \
  --include-global-service-events \
  --is-multi-region-trail \
  --enable-log-file-validation

避坑：我曾经踩过一个坑——多区域Trail只记录它所在区域的事件，如果KMS操作跨区域（比如复制密钥），必须启用“全局服务事件”才能捕获。后来我全部换成多区域Trail，省心多了。

4.2 Azure Monitor —— 结合诊断设置与Log Analytics

Azure的KMS叫Key Vault。它的审计日志通过“诊断设置”拉出来，送到Log Analytics工作区或者存储账户。

我开始做Azure项目时，第一反应是去Key Vault的“活动日志”里找，但发现只能看最后90天。后来才明白——活动日志是Azure平台的，不是Key Vault自己的。要拿到完整的“密钥操作日志”，得走诊断设置。

配置步骤

打开Key Vault → 点击“诊断设置”
选择“+ 添加诊断设置”
勾选以下类别：
- AuditEvent（所有Key Vault操作，必须选）
- KeyVaultKeys（密钥特定操作，如果只需密钥审计可选这个细粒度类别）
目标：选择“发送到Log Analytics工作区”或“存档到存储账户”
（推荐）同时勾选“流式发送到事件中心”，便于实时消费

  我建议：生产环境一定要把日志送到Log Analytics工作区，因为可以写KQL查询。我之前帮客户做排查，直接KQL一把梭，几分钟就定位到谁在半夜删了密钥。

Azure CLI 快速启用

az monitor diagnostic-settings create \
  --name kvaudit \
  --resource /subscriptions/xxx/resourceGroups/myRG/providers/Microsoft.KeyVault/vaults/myKV \
  --logs '[{"category":"AuditEvent","enabled":true,"retention-policy":{"days":365,"enabled":true}}]' \
  --workspace /subscriptions/xxx/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/myLA

4.3 GCP Audit Logs —— 默认开启但需导出

GCP相对省心——Cloud KMS的审计日志默认就写入了Cloud Audit Logs，属于“管理员活动”（Admin Activity）类型。但它默认只保留400天，并且不长期保存，需要你主动导出到Cloud Storage或BigQuery。

两种数据访问日志

日志类型	记录内容	默认状态
Admin Activity	元数据创建、修改、删除（CreateKeyRing、CreateCryptoKey、DisableCryptoKeyVersion等）	始终启用
Data Access	密钥的实际加解密调用（Encrypt、Decrypt、AsymmetricSign）	默认关闭，需要显式开启

你想想看，如果你只关心“谁创建了密钥”，Admin Activity就够了。但如果要审计“谁调用了加密操作”，必须手动打开Data Access日志。我记得一次合规审计中，对方要求提供过去一年所有密钥的使用记录，我们才发现Data Access没开……后来连夜补开，但之前的数据已经没了。

警示：Data Access日志会影响性能（因为每个API调用都会产生日志），建议只在特定密钥上开启，或者通过排除过滤器减少日志量。

配置导出到Cloud Storage

# 1. 创建存储桶
gsutil mb gs://my-kms-audit-logs/

# 2. 创建日志导出接收器（Sink）
gcloud logging sinks create kms-audit-sink \
  gs://my-kms-audit-logs/ \
  --log-filter='resource.type="kms_crypto_key" AND (severity>=NOTICE)'

4.4 三大平台对比与选择建议

做了几个跨云项目后，我整理了一个对比表，方便你按场景选方案。

维度	AWS CloudTrail	Azure Monitor (Diagnostic Settings)	GCP Cloud Logging + Sink
默认开启程度	仅管理事件默认；数据事件需手动	完全手动	Admin Activity默认；Data Access手动
日志保留时间	取决于存储桶策略，可自定义	Log Analytics 默认90天，可延长	默认400天，导出后不限
实时告警能力	CloudWatch Logs + EventBridge	Log Analytics Alert	基于日志的指标 + 通知
查询复杂度	中（Athena查询S3或CloudWatch Logs Insights）	高（KQL功能强但学习曲线陡）	中（Logging查询语言较简单）
成本考虑	S3存储成本低，但API调用日志量大会增加成本	Log Analytics ingest和存储均收费	Logging ingest收费，Cloud Storage便宜

个人经验：小团队建议先选一个平台熟悉起来。我当年就是先啃透CloudTrail，然后迁移到Azure时发现套路类似，只不过服务名换了。跨云后多看文档，别凭印象乱配，很容易漏日志。

本章知识体系

下面这张图帮你理清三大平台日志采集的完整链路。看完了应该能明白一件事：不管云厂商怎么包装，核心无非三步——开启、配置输出位置、开始消费。

这段配置过程看起来步骤不少，但走一遍之后你会发现，其实每个平台的套路都类似。我在实际项目中，通常会先在一台测试密钥上开启完整日志，确认能收到数据后再推广到生产。别一上来就给所有密钥开全量日志，小心账单爆炸——尤其是Azure的Log Analytics ingest费用可不低。