3. 国家密码管理局标准法规解读：GB/T 39786、GM/T 等标准对审计日志的要求
做国密合规的审计日志，光懂技术是不够的。
你手底下的设计，最后都得拿到标准这把尺子上去量。
这一章，我们就来聊聊几份必须吃透的标准文件。
先列个我的个人清单。
这些年不管做什么项目，这三份标准我一定是放在案头的：
| 标准编号 | 全称 | 我的定位 |
|---|---|---|
| GB/T 39786-2021 | 信息安全技术 信息系统密码应用基本要求 | 纲领性文件，顶层设计 |
| GM/T 0054 | 信息系统密码应用测评要求 | 测评依据，验收标准 |
| GM/T 0015 | 数字证书认证系统密码协议规范 | 协议层面的补充 |
说白了，第一份告诉你该做什么，第二份告诉你你做得对不对，第三份则是一些更细的协议要求。
咱们今天重点看 GB/T 39786，因为它是审计日志设计的源头。
我记得第一次接触这个标准时，心里挺发怵的。
通篇的法律术语，看了两遍都没抓住重点。后来我发现，得带着问题去读：
- 它到底要求我们记录哪些事？
- 这些记录必须满足什么安全属性？
- 记录本身谁来保护？
答案其实很集中。
标准里反复强调的是 “不可抵赖性” 和 “可追溯性”。
为了实现这两点，审计日志就成了唯一抓手。
一句话总结GB/T 39786的核心态度：
所有涉及密码设备操作、密钥生命周期、人员权限变更的行为，都必须有不可篡改的审计记录。
3.1 标准到底划了哪些红线？
我把 GB/T 39786 里跟审计日志相关的条款梳理了一下。
不扯太多原文，我直接用大白话翻译成“必须做”和“不能做”。
- 必须记录的操作：
- 密码设备的启停、配置变更、灾备切换
- 密钥的生成、分发、备份、归档、销毁
- 用户身份认证（成功和失败的都得记）
- 权限授予、撤销、修改
- 日志系统自身的配置变更
- 必须保证的属性：
- 真实性：不能由非授权用户伪造日志
- 完整性：写入后就不能被篡改
- 不可抵赖性：操作者无法否认自己做过
- 必须满足的存储要求：
- 日志本身要加密存储（推荐使用国密SM4）
- 日志数据要有备份，至少保留6个月或更久（按行业要求定）
- 存储介质不能是普通硬盘，建议使用只写一次（WORM）的设备
个人经验：
有一次项目上，客户问“日志里的敏感信息要不要脱敏？”
说实话，标准没有强约束。但我建议你这么做。原因很简单——审计员可能没权限看明文密码，但你有义务记录操作行为。把密码本身从日志里摘掉，记录一个“用户A于某时重置了密码B”就够了。
3.2 GM/T 0054：测评视角下的审计检查点
如果说GB/T 39786是设计蓝图，那GM/T 0054就是验房清单。
测评机构会拿这个标准逐条检查你的审计系统。
我经历过一次密码测评，印象很深。
负责检查的小哥拿出一张表，逐项核对：
- 日志是否使用SM3做了完整性校验？
- 密钥销毁时是否生成了审计事件？
- 审计员和管理员是否是同一个人？（这条绝不能是同类）
- 日志存储是否有防篡改机制？
直接说结论吧。
GM/T 0054 把审计日志的检查分成了 三个维度：
| 维度 | 检查项举例 | 常见雷区 |
|---|---|---|
| 功能合规 | 事件类型是否全覆盖、字段是否完整 | 漏记“会话超时”事件 |
| 安全合规 | 日志传输是否加密、存储是否防篡改 | 使用MD5代替SM3 |
| 管理合规 | 日志管理员、审计员是否分岗 | 一人兼两岗 |
避坑指南：
我曾经遇到过一家厂商，日志系统功能齐全，但日志管理员的账号密码跟普通管理员是同一个LDAP组。这直接导致审计日志里，管理员自己改自己权限的记录出现“自我审计”的问题。
测评一票否决。
记住：审计日志的管理员和日常运维管理员，必须物理隔离或严格权限分离。
3.3 国密算法在审计日志中的落地要求
标准不只是管你“记什么”，还管你“怎么记”。
既然叫国密审计日志，那里面用到的密码技术必须合规。
我整理了一张对照表，写项目方案时可以直接参考：
| 审计日志环节 | 推荐算法 | 标准编号 |
|---|---|---|
| 日志完整性校验 | SM3 | GM/T 0004 |
| 日志加密存储 | SM4 (CBC模式) | GM/T 0002 |
| 日志传输加密 | SM4 或 SM2握手 | GM/T 0003 / 0002 |
| 数字签名（不可抵赖） | SM2 | GM/T 0003 |
| 密钥封装 | SM2 | GM/T 0003 |
你可能会问：“我能不能日志用AES，只在密钥协商时用SM2？”
答案是不行。
标准要求的是全链路国密，不只是某个环节换成国密就完事了。日志从产生、传输、存储到审计，整个链条都得用国密套件。
3.4 这些标准背后的设计哲学
理解了标准的具体条款，还得理解它为什么这么定。
说白了，国密标准对审计日志的执念来自于一个朴素逻辑：
密码设备是数字世界的“公章”。
谁用了这个公章、拿去盖了什么、什么时候盖的，必须一清二楚。
如果审计日志本身可以被篡改，那整个密码体系的信任基础就崩溃了。
这就是为什么标准要求对日志本身也要做完整性保护（SM3链式校验），而且日志管理员不能又是操作员。
一个负责生产，一个负责监督，这是最基础的“职责分离”。
核心观点：
审计日志不是事后追责的备用工具，它是密码系统运行的安全基石。没有可靠的审计日志，你没法证明这套系统是合法合规的。
3.5 实战中的标准融合策略
好了，理论说完了，聊聊怎么用。
做设计时，我习惯把标准要求分解成几个可执行的 “设计约束”：
- 事件分类模型：直接对标GB/T 39786附录A的事件类型，不要自己发明轮子。
- 日志链结构：参考GM/T 0054对完整性保护的要求，设计一个SM3链式结构，保证每一条日志都能向前验证。
- 权限模型：严格执行三权分立——系统管理员、安全管理员、审计管理员，三套账号、三套权限、三套日志。
- 存储模型：使用支持WORM特性的存储设备，加上SM4加密，双重保护。
实操技巧：
我刚做第一个国密项目时，设计了三权分立的模型，但没想清楚日志管理员怎么查看日志。后来发现，如果审计员也要登录系统查看加密日志，那他的登录行为也应该被记录下来。
于是我加了一条规则：审计管理员的所有操作，也要落日志，而且日志的加密密钥不由他自己保管。
这听起来有点绕，但这是标准的本意——没有任何人能够单方面篡改审计数据。
这张图展示了我上面说的整个融合逻辑。
顶层是三个标准，中间层是四大设计约束，最终落地成一个可测评的审计系统。
设计时，拿着这个图逐层检验，基本不会跑偏。