加密技术在审计日志中的角色：机密性、完整性与不可否认性

聊到审计日志加密，很多人第一反应就是“把日志锁起来”。但锁的方式不同，达到的效果也完全不同。我个人习惯把这三个核心目标拆开来看——机密性、完整性、不可否认性。你想想看，它们其实对应了三个完全不同的攻击场景。

机密性：防止日志内容泄露

这是最直观的需求。审计日志里往往包含敏感信息，比如用户IP、操作细节、甚至部分业务数据。如果日志以明文存储或传输，一旦被窃取，等于把公司内部的操作细节拱手送人。

我在项目中遇到过不少团队，只关注日志收集的效率，完全没考虑传输过程中的加密。结果呢？日志在网络上裸奔，中间人攻击就能抓到完整的数据流。

常用手段

• 对称加密（AES-256）：适合批量日志的存储加密，性能开销小，吞吐量高。我自己习惯用AES-256-GCM模式，既加密又带认证标签，省掉单独的MAC计算。
• 非对称加密（RSA/ECC）：适合日志传输场景的密钥协商，或者小体积日志的端到端加密。但注意，非对称加密性能开销大，不适合大流量日志逐条加密。
• 混合加密：实际项目里我最常用的方案——用非对称加密传递对称密钥，再用对称密钥加密日志内容。两边兼顾。

完整性：防止日志被篡改

机密性保证别人看不到，完整性保证别人改不了——或者说，改了你能发现。这其实是审计日志最核心的诉求之一。你想想看，攻击者渗透进系统后，第一件事往往是“擦脚印”，篡改或删除日志。

我以前在做一个金融审计系统时，就专门针对这个问题设计过方案。光靠加密是不够的，因为加密只保护传输和存储的“内容”，如果攻击者有密钥（比如拿到了服务器最高权限），他可以直接解密、篡改、再加密，你完全察觉不到。

常用手段

• HMAC（哈希消息认证码）：用共享密钥对日志条目计算MAC值。篡改后MAC不匹配，能发现。但缺点是对称密钥一旦泄露，攻击者可以重新计算MAC。
• 数字签名：用私钥对日志哈希值签名。私钥只有签名方持有，其他人无法伪造。我最推荐的方式。
• 哈希链：每一条日志包含上一条日志的哈希值。篡改任意一条，后续所有链都会断掉。这招在现场审计中特别实用。

不可否认性：防止抵赖操作

说白了，就是让操作者无法抵赖——“这个操作不是我做的，是别人冒用的”。审计日志里的不可否认性，通常通过数字签名和时间戳共同实现。

我遇到过一个案例：某公司内部审计发现一笔异常转账记录，日志显示是某位运维人员操作的。对方否认，说账号密码被窃。但因为日志记录了完整的操作上下文，并且每条操作都附带了该用户的数字签名（私钥只在用户持有的硬件里），最终审计结论支持了“非抵赖”。

实现要点

1. 签名密钥与用户强绑定：私钥必须由用户持有，服务器或者管理员拿不到。用硬件安全模块(HSM)或TPM存储。
2. 可信时间戳服务：操作发生时，从NIST或内部授时服务器获取可信时间戳，一起签名。
3. 日志签名独立于用户密钥：审计日志系统的签名密钥与用户操作密钥分开，避免单点失效。

三者之间的关系

机密性、完整性、不可否认性不是孤立的。它们之间相互支撑，但也存在冲突。举个例子：

• 如果你只加密不签名，攻击者拿到密钥后可以篡改内容，机密性变成了“被篡改内容的保密存储”，毫无意义。
• 如果你只签名不加密，日志内容还是明文，攻击者可以看到机密信息。
• 如果时间戳不可信，签名再强也没法证明操作发生在真实时间点，不可否认性打折扣。

我个人习惯在做审计日志安全设计时，先画一个威胁树，把每种威胁对应的加密/签名手段列出来，然后逐一检查有没有遗漏。嗯，这一步很繁琐，但能省下上线后无数的补丁工作。

下面这张图概括了这三个目标在审计日志中的定位和实现方式。我自己习惯把它挂在团队的技术方案文档里，每次评审时对照着过一遍，基本不会漏项。

你看，这三个目标就像审计日志的三道防线。缺少任何一个，其他两个的安全性都会大打折扣。我每次做安全审计时，都会先问自己三个问题：日志存了谁看不到？日志改了能否发现？操作了谁能否抵赖？嗯，问清楚了，方案基本不会跑偏。