4. 主流云平台审计服务：AWS CloudTrail、Azure Monitor 活动日志、GCP Cloud Audit Logs

做云上加密审计，第一步就是把日志搞到手。三大云厂都有自己的审计服务：AWS 的 CloudTrail、Azure 的 Monitor 活动日志、GCP 的 Cloud Audit Logs。名字不同，但干的活差不多——记录谁、在什么时候、通过什么 API、干了什么。但细节上差异不小，我踩过的坑也不少，今天一并讲清楚。

4.1 为什么需要专门学它们的差异？

你可能会想：不都是审计日志吗，统一标准学一个不就行了？

嗯，还真不行。我见过好几个团队，迁移到多云后才发现，三个平台的审计日志格式、存储路径、保留策略完全不一样。结果合规检查时，Azure 那边的日志只保留了 90 天，而法规要求 1 年，直接拉了跨。所以，搞清楚各家差异，是设计跨云加密存储方案的前提。

4.2 AWS CloudTrail

CloudTrail 是 AWS 的审计亲儿子。默认开启，记录最近 90 天的管理事件。但你要做加密归档，就必须创建 Trail（追踪），把日志投递到 S3 存储桶。

核心概念

• Trail：日志投递管道，一个 Trail 可以覆盖多个区域。
• 事件类型：管理事件（CreateVpc、DeleteBucket 等）、数据事件（S3 GetObject、Lambda Invoke 等）、洞察事件（异常活动）。
• 日志文件：Gzip 压缩的 JSON，每小时或每 5 分钟生成一个。
• 加密：直接用 S3 服务端加密（SSE-S3），但我强烈建议改用 KMS 托管密钥（SSE-KMS）。

CloudTrail 的文件路径规则也比较固定：AWSLogs/<account-id>/CloudTrail/<region>/<yyyy>/<MM>/<dd>/。我写自动化脚本时，就按这个路径前缀去扫描新文件，再交给加密管道处理。

典型配置示例（AWS CLI）

aws cloudtrail create-trail \
  --name my-encrypted-trail \
  --s3-bucket-name my-audit-logs \
  --is-multi-region-trail \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/xxxx-xxxx

4.3 Azure Monitor 活动日志

Azure 的活动日志（Activity Log）默认保留 90 天，但不同于 CloudTrail，它不直接投递到文件。你要用诊断设置（Diagnostic Settings）才能把日志送到 Log Analytics 工作区、存储账户或事件中心。

关键差异

• 日志类别：管理事件（Administrative）、服务健康（ServiceHealth）、自动缩放（Autoscale）、安全（Security）、建议（Recommendation）、策略（Policy）。比 CloudTrail 多出好几类。
• 存储格式：投递到存储账户后，文件是 JSON 格式，但路径是 insights-activity-logs/resourceId=.../y=.../m=.../d=.../，和 AWS 结构完全不同。
• 加密：存储账户支持 Azure Storage Service Encryption（SSE），也可以用客户管理密钥（CMK）。

我刚开始搞 Azure 审计时，直接在 Portal 上开启了诊断设置，选了“归档到存储账户”。结果日志文件里混了好多空文件夹和重复记录，后来才知道 Azure 会自动忽略空 Blob，但文件夹目录会留一堆空占位。写扫描脚本时，要过滤掉长度为零的 Blob。

配置步骤（概要）

1. 创建或选择存储账户（建议开启软删除）。
2. 在 Monitor 下配置诊断设置，选择“Activity Log”。
3. 指定目标：存储账户，并勾选“保留天数”（不指定则永久保留）。
4. （可选）启用客户管理密钥：在存储账户的加密设置中指定 Key Vault 密钥。

4.4 GCP Cloud Audit Logs

GCP 的审计日志可以说是最灵活的，也是我最喜欢的。它默认写入 Cloud Logging，并支持三种审计日志：管理活动（Admin Activity）、数据访问（Data Access）、系统事件（System Event）。默认只记录管理活动，数据访问需要显式启用，而且要收费。

存储选择

日志可以路由到 Cloud Storage、BigQuery、Pub/Sub 或 Splunk。路由方式通过日志桶（Log Bucket）和接收器（Sink）实现。注意：GCP 的日志在 Cloud Logging 中保留 30 天（默认）。想长期保存，必须创建接收器发到 Cloud Storage。

加密注意事项

Cloud Storage 对象默认使用 Google 管理的加密（GMEK），但我做合规项目时遇到了问题：客户要求所有审计日志必须用自己的密钥加密。Cloud Storage 支持 CMEK，但需要在创建存储桶时指定密钥。这里有个坑：日志投递到存储桶后，如果密钥被禁用，读取会直接报错。我在生产环境遇到过，因为 Key Rotation 脚本写错了，把旧密钥删了，结果一周的审计日志全废了。

日志格式举例

{
  "protoPayload": {
    "methodName": "google.cloud.storage.v1.Storage.CreateBucket",
    "authenticationInfo": { "principalEmail": "admin@example.com" },
    "requestMetadata": { "callerIp": "203.0.113.5" }
  },
  "resource": { "type": "gcs_bucket", "labels": { "project_id": "my-project" } },
  "timestamp": "2025-03-25T10:00:00Z"
}

4.5 三大平台对比一览

4.6 通用设计原则

不管用哪家，加密审计日志的采集都遵循一个核心框架：采集 → 加密 → 存储 → 保留 → 访问控制。我画了张图，帮你理清概念关系。

图中展示的就是从三大审计服务投递到各自存储，再统一经过加密层，最后落到生命周期管理。实际项目中，你还要考虑跨云统一日志格式的问题，但那是后面章节的话题了。

4.7 我的推荐做法

如果你刚开始构建多云审计系统，我建议先选一个平台练手。比如先搞通 AWS CloudTrail + S3 + SSE-KMS，确保加密和权限控制没问题。然后再用类似的思路去配 Azure 和 GCP。不要试图一次性并行搞三个，否则排错会让人崩溃。