📚 课程目录第3章启用KMS审计日志

启用KMS审计日志：CloudTrail配置详解

好，进入实战环节。你手上有KMS，但怎么知道谁在用、什么时候用、用来干嘛？

答案就是CloudTrail。说白了，CloudTrail就是AWS的"监控摄像头"，把所有API调用都录下来。而我们要做的，就是确保它把KMS相关的操作也拍清楚。

CloudTrail能记录什么？

CloudTrail记录两类事件，我习惯这么区分：

管理事件：谁创建、删除了密钥？谁修改了密钥策略？这类"动配置"的操作。
数据事件：谁用密钥做了加解密？谁用密钥做了签名？这类"动数据"的操作。

很多团队只开了管理事件，数据事件压根没开。你想想看，攻击者可能不删除你的密钥，他只是偷偷用你的密钥加密数据，然后勒索你。管理事件查不出来，数据事件才有记录。

关键点：管理事件默认开启，数据事件必须手动开启。

管理事件：默认就有，但要注意

创建CloudTrail追踪时，管理事件默认就是"已启用"。但这里面有坑。

云上所有的管理事件会写入同一个S3桶。我曾经排查过一个案例，客户说KMS密钥被删了，要查谁干的。结果CloudTrail日志里记录了五百多个账号的管理事件，光筛选KMS相关的就花了两小时。

所以我个人建议：

如果你有多个账号，每个账号单独建一个追踪
或者用组织追踪(Organization Trail)，但一定要加上KMS的过滤条件
把管理事件写入独立的S3前缀，比如AWSLogs/管理事件/

小技巧：管理事件不需要额外付费，放心开。

数据事件：必须手动开

数据事件才是关键。默认情况下，CloudTrail不记录数据事件。你需要在创建或更新追踪时，明确告诉它："我要记录KMS的加解密操作。"

怎么配置？两种方式：

记录所有KMS密钥——简单粗暴，但日志量巨大
记录指定KMS密钥——只记录你关心的密钥，日志更精准

我会优先用第二种。比如生产环境的密钥和测试环境的密钥分开管，我只记录生产环境的。

实操：用控制台配置数据事件

嗯，这里要注意，配置步骤不算多，但容易漏。我习惯用AWS CLI做，但控制台更直观，适合教学。

控制台操作步骤：

打开CloudTrail控制台，找到你已有的追踪，或创建新追踪
在"数据事件"部分，点击"配置"
选择"选择事件类型" → "KMS"
在"资源类型"下拉选"所有KMS密钥"或"特定KMS密钥"
如果选"特定KMS密钥"，填入ARN。可以填多个，用逗号隔开
点击"保存"

完事后，你就能在CloudTrail里看到类似这样的记录：

{
    "eventVersion": "1.08",
    "eventID": "xxxx-xxxx-xxxx",
    "eventTime": "2024-03-15T10:00:00Z",
    "eventName": "Decrypt",
    "eventSource": "kms.amazonaws.com",
    "awsRegion": "us-east-1",
    "userIdentity": {
        "arn": "arn:aws:iam::123456789012:user/alice",
        "principalId": "AIDA..."
    },
    "requestParameters": {
        "keyId": "arn:aws:kms:us-east-1:123456789012:key/xxxxx",
        "encryptionAlgorithm": "SYMMETRIC_DEFAULT"
    },
    "responseElements": null
}

警告：数据事件会产生大量日志，可能导致S3存储成本和CloudTrail费用飙升。我建议先开几小时，观察日志量，再做调整。

用CLI批量配置

如果你需要管理多个账号或区域，控制台就不是最佳选择了。用AWS CLI更高效。

创建追踪并开启KMS数据事件：

aws cloudtrail create-trail \
    --name kms-audit-trail \
    --s3-bucket-name my-audit-bucket \
    --is-multi-region-trail \
    --enable-log-file-validation

aws cloudtrail put-event-selectors \
    --trail-name kms-audit-trail \
    --event-selectors '[{
        "ReadWriteType": "All",
        "IncludeManagementEvents": true,
        "DataResources": [
            {
                "Type": "AWS::KMS::Key",
                "Values": ["arn:aws:kms:us-east-1:123456789012:key/xxxxx"]
            }
        ]
    }]'

这个DataResources的Values数组里，你可以放多个KMS密钥ARN，也可以用通配符arn:aws:kms:*:*:key/*来匹配所有密钥。

提示：通配符虽然方便，但会让数据事件日志量暴增。我个人只在应急排查时临时用一下。

管理事件 vs. 数据事件：区别一目了然

对比维度	管理事件	数据事件
包含内容	CreateKey, DeleteKey, PutKeyPolicy, TagResource, EnableKey...	Encrypt, Decrypt, GenerateDataKey, Sign, Verify, ReEncrypt...
默认开启	是	否
日志频率	低	很高（取决于调用量）
成本	低	高
审计价值	查密钥生命周期管理	查密钥使用情况和异常调用
常见查询场景	谁删了密钥？谁改了策略？	哪个服务器在大量解密？谁在凌晨调用了密钥？

说白了，管理事件帮你回答"密钥怎么了"，数据事件帮你回答"密钥被谁用了"。两个都开，才能覆盖完整的审计链路。

存储策略：日志要存多久？

CloudTrail日志默认永久存储在S3桶里。但你真需要存十年吗？审计要求一般也就三年到五年。

我建议配置生命周期策略：

前30天：标准存储，方便快速检索
30天到1年：低频存储或Glacier即时检索，节省成本
1年以上：Glacier Deep Archive，几乎不花钱
超过合规保留期：自动删除

别让日志无限制积累。我曾经帮客户查过，一个桶里堆了三年份的CloudTrail日志，光列出文件列表就要等十分钟...排查效率极低。

记住：日志的价值在于"可查"，而不在于"可存"。

别忘了跨区域和跨账号

KMS是区域服务，CloudTrail可以配置为多区域追踪，这样所有区域的操作都会落入同一个日志桶。我强烈建议开启多区域，不然你每个区域得单独建一个桶，查起来会很痛苦。

跨账号的话，用CloudTrail的组织追踪功能，或者把多个账号的日志集中发到同一个S3桶，再用IAM策略隔离访问。

一张图看清整体架构

说个小提醒

配置好之后，别忘了验证。我见过太多人配完了就说"行了"，结果一查日志，空的。

验证方法很简单：手动调用一次KMS操作，比如用AWS CLI执行一次加密：

aws kms encrypt --key-id alias/my-key --plaintext "hello-world"

等一两分钟，去CloudTrail控制台搜索刚才的调用。如果看到了"Encrypt"事件，说明配置成功了。没看到？大概率是事件选择器没配对，或者密钥ARN写错了。

注意：CloudTrail日志有约15分钟的延迟，别刚调完就去查。喝杯咖啡再回来。

配置好CloudTrail日志，只是第一步。下一阶段我们要聊的是：拿到日志之后，怎么从海量数据里快速找到KMS相关的异常行为。但那个，我们之后再细说。