📚 课程目录第4章日志数据收集

4、日志数据收集：Secrets访问日志的来源与格式标准化

聊到 Secrets 访问频率异常检测，第一步不是写检测算法，而是搞清楚日志从哪来、长什么样。我见过不少团队，一上来就调模型，结果日志字段对不上，时间戳飘忽不定，白白浪费两周。说白了，日志源和格式是地基，地基不稳，上面盖什么都白搭。

这一节，咱们就掰扯清楚 Secrets 访问日志的两个主要来源——云服务与自建保险库，以及怎么把它们揉成一套统一的格式。我个人习惯先画一张整体图，再分头细说。

4.1 云服务 Secrets 访问日志

三大主流云商——AWS、Azure、GCP——都提供了托管 Secrets 服务，日志天然集成到各自审计/监控体系中。我去年帮一家电商迁移 Secrets 时，就是靠云日志直接喂的检测管道，省了不少力气。

AWS Secrets Manager：通过 CloudTrail 记录所有 API 调用，事件类型包括 GetSecretValue、RotateSecret、PutSecretValue 等。重点关注 GetSecretValue 频率。
Azure Key Vault：日志发送到 Azure Monitor / Log Analytics，密钥操作有 SecretGet、SecretSet、SecretDelete。Azure 的日志里会带 CallerIPAddress 和 Identity。
GCP Secret Manager：审计日志在 Cloud Logging 中，操作名如 google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion。GCP 日志结构相对扁平，解析起来比较顺手。
阿里云KMS / 腾讯云凭据管理：国内云厂商也类似，日志在各自的操作审计产品里，字段大同小异。

小经验：云日志最大的优点是省心，但要注意配额和延迟。CloudTrail 通常有15分钟左右的交付延迟，实时性要求高的场景需要配合实时事件流（如 EventBridge）来弥补。

4.2 自建保险库的访问日志

自建保险库这条线，水就深一些。我遇到过不少企业，用 HashiCorp Vault 或者自己搞了一套 Secrets 存储，日志格式那是五花八门。我记得有一次帮客户排查误报，发现是 Vault 的审计日志里时间戳格式不统一，有的竟然用的毫秒级Unix时间戳，有的却是ISO 8601。

HashiCorp Vault：审计日志写在 /vault/logs/audit.log（默认JSON格式），每个请求包含 time、type、auth、request、response 等。我最常关注 request.path 和 request.operation（比如 read、list、create）。
CyberArk Conjur：日志格式较特殊，有自己定义的字段如 action、resource、user。可以通过 syslog 或者企业级日志平台接入。
开源Vault / 自研引擎：这类日志更自由，我曾经见过业务方直接打印 [INFO] User xxx fetches secret yyy 就完事了。这种非结构化日志，需要额外写解析规则。

我曾经踩过的坑：自建保险库的审计日志默认可能不记录请求来源 IP，尤其 Vault 在集群内部署时，负载均衡会替换源IP。建议在 Vault 配置中开启 X-Forwarded-For 透传，或者通过 envoy 侧记录真实客户端IP。

4.3 日志格式标准化 —— 把“方言”转成“普通话”

你看，日志来源这么多，字段名、时间格式、枚举值都不一样。异常检测算法只认一套 schema，所以必须做标准化。说白了，就是把各种 “方言” 转成 “普通话”。

我个人习惯采用 JSON 作为统一格式，原因有三：解析容易、嵌套灵活、和告警系统配合好。下面是我常定义的标准字段表：

标准字段名	类型	说明	对应云服务字段示例	对应Vault字段示例
`timestamp`	ISO8601字符串	事件发生时间，标准化为 UTC	`eventTime`	`time`（需格式转换）
`secret_name`	字符串	被访问的Secret标识	`requestParameters.secretId`	`request.path`
`source_ip`	字符串	发起请求的客户端IP	`sourceIPAddress`	需从 `request.headers` 提取
`operation`	枚举	`read` / `write` / `list` / `delete`	`eventName`（如 GetSecretValue）	`request.operation`
`identity`	字符串	调用者身份（IAM角色/用户/服务账户）	`userIdentity.arn`	`auth.client_` 或 `auth.display_name`
`status`	字符串	操作结果：`success` / `denied` / `error`	`errorCode`（为空即成功）	`response.data` 或 `errors`

重点：标准化不只是字段重命名。时间戳统一到ISO 8601并且全部转 UTC，否则跨时区分析会乱。操作枚举也要归一，比如 AWS 的 GetSecretValue、Azure 的 SecretGet、Vault 的 read 都映射为 read。

标准化管道我一般用 Fluentd 或 Logstash，写一段 grok 或者 filter 搞定。下面是一个简化的 Fluentd 配置片段，用来把 Vault 审计日志转成标准格式：

# Fluentd config snippet: Vault audit log -> standardized JSON
<source>
  @type tail
  path /vault/logs/audit.log
  format json
  tag vault.audit
</source>

<filter vault.audit>
  @type record_transformer
  <record>
    timestamp ${record["time"]}
    secret_name ${record["request"]["path"]}
    source_ip ${record["request"]["headers"]["X-Forwarded-For"] || record["request"]["client_ip"]}
    operation ${record["request"]["operation"]}
    identity ${record["auth"]["display_name"]}
    status ${record["response"]["data"] ? "success" : "denied"}
  </record>
</filter>

你想想看，这段配置干的事其实很简单：读行、解析JSON、提取需要的字段并重命名。但正是这一步，让后续的异常检测算法不必再操心数据源头。嗯，这里要注意的是处理缺失值——比如没有 X-Forwarded-For 时，回退到原始 client_ip。

4.4 实践中容易翻车的几个细节

时间对齐：云日志自带 UTC，但自建 Vault 可能使用本地时间。标准化时统一 +0 时区，并记录原始时区到 _raw_timezone 备用。
容量规划： Secrets 访问量大的时候，日志量可能突增。我曾经处理过一个事故，Vault 的审计日志每秒产生几千条，导致 Logstash 直接 OOM。建议加缓冲队列（例如 Kafka 中间层）。
敏感信息脱敏：审计日志里可能包含 Secret 值本身（极少数情况下）。一定要在收集阶段做正则替换，把 "secret_data":".*" 换成 "secret_data":"[REDACTED]"。合规审计会追究这一点。
结构化与非结构化混用：有些老系统还在用 syslog 打印明文。这类日志建议先用 grok 提取关键字段，再写进标准化管道。

推荐做法：给每个标准化后的日志打上 source_type 标签（如 AWS_SM、AZURE_KV、VAULT），方便后续按来源做差异化策略分析。

日志收集这块，看起来是脏活累活，但确实决定了异常检测的天花板。我自己带团队时，一定会花至少 30% 的时间打磨日志标准化这步——后面的分析反而水到渠成。把云服务和自建保险库的日志管好，你的检测模型才有资格谈“通用”。好，这一章就聊到这儿。