日志审计目标：合规性、异常检测、事件溯源

做KMS日志审计这么多年，我越来越觉得，搞清楚「为什么审」比「怎么审」更重要。很多人一上来就盯着日志格式、解析规则，结果方向偏了，审计价值大打折扣。

说白了，KMS日志审计就三个核心目标：合规性检查、异常行为检测、安全事件溯源。这三个目标像三角形，互相支撑，但各自关注的点和手法完全不同。

合规性检查：审「对不对」

合规性是最基础也最容易被低估的目标。我见过不少团队，上来就追求高深的行为分析，结果监管一问「你们密钥轮转记录保存了吗？」拿不出来，直接扣分。

合规性审计说白了就是回答：操作是否遵循了既定的策略和法规。比如ISO 27001、PCI DSS、GDPR中对密钥管理都有明确要求。

异常检测：审「怪不怪」

异常检测的目标是发现偏离正常基线的行为。这里需要强调「基线」的概念。没有基线，就没有异常。我个人习惯先采集至少30天的正常日志，建立用户、角色、操作频率、访问时间等维度的画像。

举个例子，某个开发者平时每天调用Encrypt不到100次，某天突然凌晨3点跑了5000次加密操作。如果不做异常检测，这种横向移动的前兆很容易被淹没在海量日志里。

# 规则1：高频解密操作告警（可能的数据外泄）
条件：eventName = 'Decrypt' 且 count > 阈值（如100次/分钟）
动作：触发工单 + 临时吊销IAM权限

# 规则2：非工作时间的管理操作
条件：eventSource = 'kms.amazonaws.com' 
      且 userIdentity.type = 'IAMUser' 
      且 time NOT IN (09:00-18:00, 工作日)
动作：发送Slack告警给安全组

# 规则3：从未见过的调用来源IP
条件：sourceIPAddress NOT IN 已白名单IP列表
动作：标记为可疑，进入人工review队列

事件溯源：审「为什么会这样」

事件溯源是审计的终极目标——当安全事件已经发生，我们需要通过日志还原整个过程。说白了就是：「谁，在什么时间，通过什么方式，对哪个密钥，做了什么事情，导致了什么后果」。

我自己的经验是，事件溯源特别依赖日志的完整性和时间精度。如果KMS日志和上层应用的日志时间戳不同步，溯源就变成了拼图游戏，永远缺一块。

溯源的关键步骤我整理了一个清单：

1. 确定起点：从告警事件或数据泄漏点反向查找第一个异常操作。
2. 构建操作链：按时间顺序把目标密钥相关的CreateKey、Encrypt、Decrypt、Grant、Revoke等操作串联起来。
3. 关联上下文：通过调用链ID或请求ID，把KMS日志跟应用日志、数据库日志做关联。
4. 分析影响面：确定哪些密钥被访问，哪些数据可能已被加密/解密。
5. root cause：找到权限配置缺陷或凭证泄漏点。

三个目标怎么在一个审计体系中共存？

你想想看，一个企业级KMS每天可能产生几十万条操作日志。如果每一条都用三个目标去对标，效率和成本都会爆炸。

我的做法是：分层审计——把日志处理分为三个管道。

第一层跑慢点没关系，但规则必须精准，确保不出合规漏洞。第二层要尽量快，规则要不断调优，避免告警疲劳。第三层不需要长期运行，但需要强大的搜索和关联能力——能在分钟级内从海量日志中捞出目标密钥的完整生命线。