日志采集方式：SDK接入、API调用、控制台操作、CloudTrail集成
我做了这么多年的KMS审计，发现大部分人一上来就是「日志怎么抓」的问题。其实说白了，先搞清楚日志从哪来，比怎么解析重要得多。KMS的审计日志采集路径，归纳起来就是四种：SDK接入、API调用、控制台操作、CloudTrail集成。
每种方式的触发时机、日志格式、覆盖范围都不一样。你想想看，如果分不清这些，后面写巡检脚本的时候肯定会漏东西。
核心结论：这四种方式不是互斥的，而是一个互补的金字塔。SDK覆盖应用层，API覆盖管理面，控制台覆盖手工操作，CloudTrail覆盖全局基线。
1. SDK接入：应用层的「第一手」日志
SDK接入是KMS审计日志的最源头。应用调用KMS SDK执行加解密、签名验签、生成数据密钥等操作，都会留下日志。嗯，这里要注意：SDK日志记录的是「操作请求」，不一定是「操作结果」。
我在项目里遇到过，开发团队把SDK的`encrypt`调用日志全关了，理由是「日志太多占存储」。结果出了安全问题，根本没法追溯是谁在何时加密了哪些数据。后来我帮他们设计了一套分级采集策略——关键操作全采，高频操作采样，才把这个问题解决掉。
个人建议：SDK日志中，GenerateDataKey和Decrypt是必采项。前者涉及数据密钥的创建，后者涉及密钥的使用。这两条日志能帮你画出完整的数据流向。
SDK接入的典型日志字段包括：
- action：操作类型（Encrypt、Decrypt、GenerateDataKey等）
- keyId：操作目标密钥的ID
- callerPrincipal：调用者身份
- clientRequestId：客户端请求ID，用于关联上下游
- responseStatus：调用结果（成功/失败）
我曾经踩过的坑：SDK日志里的keyId可能不是完整的ARN，而是别名（Alias）。如果你直接拿别名去检索密钥信息，查不到。记得先解析别名到CMK ID，再建立索引。不然你的巡检脚本匹配不上，白白浪费时间。
2. API调用：管理面的「全量」审计
API调用走的是KMS的管理接口，比如CreateKey、DisableKey、ScheduleKeyDeletion、PutKeyPolicy等。这些操作直接影响密钥的生命周期和权限配置。
我个人的习惯是：API调用的日志必须开启「完整记录」，不能采样。为什么？因为密钥的管理操作频率本身不高，但一旦出错，后果很严重。少一条日志，你就少一条取证线索。
典型的API调用审计日志长这样（伪代码）：
{
"eventSource": "kms.amazonaws.com",
"eventName": "ScheduleKeyDeletion",
"requestParameters": {
"keyId": "arn:aws:kms:us-east-1:123456789012:key/abc123",
"pendingWindowInDays": 7
},
"userIdentity": {
"type": "IAMUser",
"arn": "arn:aws:iam::123456789012:user/admin"
},
"sourceIPAddress": "203.0.113.45",
"eventTime": "2024-09-20T14:23:10Z"
}重点巡检项：API调用日志中的ScheduleKeyDeletion必须触发告警。我曾遇到一个案例，有人误操作把生产环境的CMK设置了7天删除，幸亏日志告警及时，管理员3小时内撤销了操作。
| API操作 | 风险等级 | 巡检建议 |
|---|---|---|
| CreateKey | 中 | 检查创建者身份和密钥用途 |
| DisableKey | 高 | 确认是否计划内操作，记录原因 |
| ScheduleKeyDeletion | 严重 | 必须人工审批，日志不可覆盖 |
| PutKeyPolicy | 高 | 对比变更前后策略，防止提权 |
| EnableKeyRotation | 低 | 确认旋转周期配置正确 |
3. 控制台操作：人肉操作的「盲区」
控制台操作经常被忽略，但其实它是最容易出问题的地方。为什么？因为开发人员和运维人员习惯通过Web界面操作，而控制台操作不会自动记录详细的「操作人意图」。
举个例子：一个人通过控制台删除了一个密钥别名，日志里只显示DeleteAlias，但不知道他为什么删。你能做的，就是确保控制台操作也走了CloudTrail，这样至少记录下操作时间和来源IP。
我个人排查问题的习惯是这样的：先看CloudTrail日志里控制台操作的eventName，然后拿sessionIssuer字段反查IAM用户。这样能把「谁在什么时间做了什么」串起来。
控制台操作和API调用的日志结构差不多，但有一个关键字段不同：
- API调用：
userIdentity.type通常是IAMUser或AssumedRole - 控制台操作：
userIdentity.type是Root或IAMUser，并且会带webIdFederationData字段
注意：控制台操作如果是通过联合身份认证（比如SAML SSO），日志里userIdentity.arn会显示联邦用户的ARN，而不是实际的企业AD用户。这种情况下，你需要额外关联身份映射表，否则查不到「最终责任人」。
4. CloudTrail集成：所有日志的「统一出口」
终于到了CloudTrail了。说白了，上面讲的SDK、API、控制台三种方式产生的日志，最终都会通过CloudTrail汇集到一起。CloudTrail就是那个「把所有审计日志收拢到一根管道」的服务。
我遇到过一个团队，SDK日志存在S3，API日志存在CloudWatch，控制台日志存在本地文件……三套日志格式不一样，时间戳不一致，根本没法关联分析。后来我把他们拉到CloudTrail这张大网里，所有日志统一格式、统一时间戳、统一存储，巡检脚本瞬间从「三天写一个」变成了「半天写一套」。
最佳实践：不管你是用SDK、API还是控制台，最终都要确保日志投递到CloudTrail。CloudTrail支持多Region聚合和多账户聚合，你只需要在一个地方配置，就能收到所有KMS操作日志。
CloudTrail日志的典型结构如下：
| 日志层级 | 字段示例 | 说明 |
|---|---|---|
| 事件头部 | eventVersion, userIdentity, eventTime | 通用审计信息 |
| 服务信息 | eventSource: kms.amazonaws.com | 标识来源服务 |
| 操作详情 | eventName, requestParameters | 具体操作及参数 |
| 响应内容 | responseElements | 操作返回结果（部分脱敏） |
| 资源信息 | resources, requestID | 操作的资源列表 |
CloudTrail集成有几个关键点要记住：
- 管理事件必开：包含所有KMS管理操作（CreateKey、DeleteKey等）
- 数据事件可选：包含加解密等数据面操作，打开后日志量会大增
- 日志完整性校验：开启后CloudTrail会为日志文件生成哈希，防止篡改
我个人推荐的方法是：数据事件按需开启。对生产环境的核心CMK，开启数据事件；对测试密钥，关闭数据事件。这样既控制了成本，又覆盖了高风险场景。
最后给个总结性建议：不要只依赖某一种采集方式。SDK接入能帮你看到「应用在做什么」，API调用能帮你看到「管理员在做什么」，控制台操作能帮你看到「人在Web上做了什么」，CloudTrail集成能帮你把所有碎片拼起来。四者缺一不可。
一条硬规则：任何KMS密钥的创建、删除、禁用、启用、策略变更，必须同时保留API调用日志和CloudTrail日志。这是审计合规的底线，也是你巡检脚本的第一优先级检查项。