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

启用KMS审计日志：控制台操作与CLI配置

审计日志这东西，说白了就是给KMS装了个黑匣子。每次谁调了密钥、什么时候调的、返回了什么结果，全都一笔笔记下来。我见过不少团队，密钥管理做得挺漂亮，但审计日志没开，等安全合规检查的时候直接傻眼。嗯，今天我们就把它搞定。

审计日志到底在记录什么？

很多人把审计日志和操作日志搞混。操作日志记的是「你点了什么按钮」，审计日志记的是「密钥被谁、在什么时候、以什么方式使用了」。两者维度完全不同。

对比维度	操作日志	审计日志
记录主体	管理员操作行为	密钥使用行为
典型内容	创建密钥、禁用密钥、更新别名	加密、解密、签名、验证
留存目的	运维排障、操作回溯	安全审计、合规取证
数据来源	KMS管理面API	KMS数据面API

你在项目里只要做一次合规审计，就知道审计日志有多重要了。我之前帮一家金融客户做架构 review，发现他们审计日志没开，结果花了整整两周补数据。这事儿一次就够你长记性的。

控制台操作：图形化配置

控制台操作适合单次配置或小规模验证。我个人习惯先走一遍控制台看看选项，再上 CLI 批量部署。这样心里有底。

登录KMS控制台，找到左侧导航栏的「审计日志」入口。
开启审计日志开关。默认是关闭的，你需要手动启用。
选择日志存储位置。一般支持对象存储（OSS）或日志服务（SLS）。我个人建议用 SLS，检索起来方便。
配置日志保留周期。合规要求通常是180天或更长，看你所在行业的监管标准。
点击「确认启用」，等待状态变成「运行中」。

小提示：控制台操作完成后，建议立刻生成一条测试日志——随便做个加密操作，然后去日志存储位置看看有没有记录。别等到第二天才发现没配好。

CLI配置：脚本化部署

生产环境里，你不可能手点几十个账号的控制台。CLI 才是正经做法。下面这套流程我一般在 Terraform 或运维脚本里用，跑一遍就完事。

# 第一步：查看当前审计日志状态
aliyun kms DescribeAuditLogStatus --region cn-hangzhou

# 第二步：开启审计日志
aliyun kms EnableAuditLog \
    --region cn-hangzhou \
    --StorageType sls \
    --ProjectName kms-audit-prod \
    --LogStore kms-audit-logstore

# 第三步：配置审计日志规则
aliyun kms SetAuditLogRule \
    --region cn-hangzhou \
    --IncludeApiNames Encrypt,Decrypt,Sign,Verify \
    --KeyIds "key-hzz12345,key-hzz67890"

# 第四步：验证配置是否生效
aliyun kms GetAuditLogStatus --region cn-hangzhou

这里要注意几个点。第一，StorageType 选 sls 还是 oss，取决于你后续要不要做实时告警。第二，IncludeApiNames 我建议默认全开，别在审计范围上省成本——少记一条关键日志，可能让你在追溯时多花三天。

我曾经在一个多 Region 的项目里，漏配了新加坡 Region 的审计规则。结果那边出了密钥泄露事件，日志完全空白。嗯，从那以后我每次加 Region，第一件事就是配审计日志。

警告：CLI 配置时，请确保当前身份具备 kms:EnableAuditLog 和 kms:SetAuditLogRule 权限。建议使用 RAM 角色而非长期 AccessKey，避免凭证泄露风险。

验证审计日志是否生效

配置完不等于生效。我的标准验证流程分三步：

生成测试事件：用 CLI 或 SDK 调用一次加密操作，比如 aliyun kms Encrypt --KeyId key-hzz12345 --Plaintext "hello"。
查询审计日志：去 SLS 或 OSS 里检索刚才那条记录。如果 5 分钟内看不到数据，说明配置有问题。
检查日志完整性：确认日志里有 UserId、ApiName、SourceIp、RequestId 四个核心字段。缺任何一个，后续审计都可能被卡住。

你想想看，如果日志记录不完整，合规检查时对方要求提供「某次解密的调用来源」，你拿不出来，那就是事故。

核心字段清单：

UserId — 调用者的云账号ID
ApiName — 调用的KMS API名称
SourceIp — 调用来源IP地址
RequestId — 请求唯一标识，用于追溯全链路
KeyId — 被操作的密钥ID
Timestamp — 精确到毫秒的操作时间

整体流程速览

下面这张图浓缩了从决策到验证的完整链路。两条路径——控制台和CLI——最终都在「验证审计日志」汇合。我个人建议小规模用控制台探路，大规模用 CLI 统一部署。

控制台 vs CLI：怎么选

我做个小总结，两种方式不是二选一的关系，而是互补的。

场景	推荐方式	原因
首次尝试，不熟悉选项	控制台	可视化，降低误操作风险
单账号单Region	控制台或CLI	差别不大，看个人习惯
多账号多Region	CLI + 脚本	一致性高，可重复执行
CI/CD集成	CLI + Terraform	基础设施即代码，变更可追溯

我个人习惯是：新功能先用控制台走一遍，熟悉参数和边界条件。然后在代码仓库里维护一套CLI脚本，所有环境统一调用。这样既不会漏配，也不会配错。

避坑提醒：我曾经在一个生产账号上直接用 CLI 配置审计日志，结果因为 RAM 权限漏了 kms:SetAuditLogRule，命令报错后我没仔细看输出就走了。直到三天后安全团队问为什么没有日志，我才发现问题。嗯，从那以后我每次配完都会跑一遍验证脚本——花五分钟，省五小时。

审计日志一旦跑起来，你就能在安全事件发生时快速回溯。不管是密钥泄露还是异常调用，日志就是你的第一道防线。这一章的内容到这儿，配置方法已经很清楚了对吧？接下来就是把它落地到你自己的环境里。