好的，这是《国密审计日志设计指南》课程的第4章正文内容。

第4章：审计日志基本概念与作用

咱们直接切入正题。很多人觉得审计日志就是个记录文件，出事了才翻出来看看。这种想法，说实在的，挺危险的。

我在项目里见过不少“裸奔”的系统，连个像样的日志都没有。出了安全问题，第一反应是“谁动了我的数据？”，结果翻遍服务器，啥也找不到。最后只能重装系统，数据丢了，责任也追查不了。嗯，这其实就是忽略了最基础的安全防线。

什么是审计日志

审计日志，不是普通的应用日志。它不是给程序员调试代码用的，也不是给运维看系统负载用的。

审计日志，是一份不可篡改的、按时间顺序排列的事件记录。它的核心目的是回答三个问题：谁？在什么时候？做了什么？

你想想看，普通的日志里，可能混杂着大量的 debug 信息、状态轮询记录。这些对排查 bug 有用，但对安全审计来说，都是噪音。审计日志记录的，只应该是那些对系统安全有重大影响的操作。

举个例子，用户登录失败了一次，这件事本身可能不算什么。但如果同一个账户在1分钟内登录失败了100次，那这就是一个典型的暴力破解信号，必须被审计日志记录并告警。

日志到底要记什么

问题来了：总不能啥都记吧？全量记录，存储成本受不了，查询效率也撑不住。我建议记住以下几个核心要素，少了哪个都不行。

要素	详细说明
事件时间	精确到毫秒的UTC时间。别用本地时间，不同服务器时区不同，排查起来就是灾难。我踩过这个坑。
主体信息	谁发起的操作？用户ID、会话ID、IP地址、设备指纹。别只记个账号，被盗号后根本查不了。
客体信息	对什么对象操作？数据表名、文件路径、API端点。要精确到这个级别。
操作类型	增删改查？登录？授权？导出？每种操作的安全风险等级不一样。
操作结果	成功还是失败？失败原因是什么？失败的攻击尝试往往比成功的更有价值。
原始请求	原始的HTTP请求头、请求体（脱敏后）、SQL语句等。这是事后分析最有力的证据。
数字签名	用国密算法对日志内容签名，保证日志本身的完整性和不可否认性。这是合规要求的核心。

看到那个“数字签名”了吗？这是关键。没有签名，审计日志就是一堆可以随意篡改的文本，没有任何法律效力。国密算法在这里发挥了巨大的作用。

为什么需要安全审计

说了这么多概念，我们来聊聊价值。安全审计到底能给我们带来什么？我把它总结为四个层面。

• 责任追溯：出了事能找到责任人。没有审计日志，你连谁删了数据库都不知道。
• 风险发现：通过分析异常模式，提前发现潜在攻击。比如前面说的暴力破解。
• 合规要求：在金融、政务等领域，国密审计日志是硬性规定。没有它，产品拿不到销售许可证。
• 系统优化：审计日志还能反哺业务。比如通过审计用户的操作路径，发现流程上的短板。

说白了，审计日志就像飞机的黑匣子。平时你可能感觉不到它的存在，但真遇到事故，它是唯一能还原真相的东西。

为什么我要强调国密？因为普通哈希（比如 SHA256）在电子取证时，如果你的日志存放服务器被攻破，攻击者完全有能力篡改日志后再重新计算哈希，你根本无法证明日志是否被修改过。

而国密算法，特别是 SM2 或 SM3 结合 SM4 的方案，提供了强不可否认性。一旦攻击者篡改了日志，数字签名校验失败，系统立刻就能发现。

核心逻辑图

下面这张图，是审计日志从生成到分析的完整生命周期。我希望你能记住这个闭环。

审计日志 vs. 普通日志

很多初学者会把它们混为一谈。我整理了一个对比，一看就明白了。

维度	审计日志	普通日志
目的	安全审计、合规审查、责任追究	调试排错、性能监控、运行状态记录
记录粒度	细粒度，只记录敏感操作	粗粒度，可能包含大量噪音
时效性	永久保留，法律要求	滚动删除，保留最近一段时间
完整性保障	必须使用数字签名或哈希链	通常不校验，允许丢失
查询场景	事后调查、统计报表、异常告警	实时排错、性能分析、调试跟踪

看到区别了吗？审计日志的设计理念从一开始就是“防篡改、可追溯”。我在做国密改造时，发现很多系统直接把普通日志拿来用，然后说“我们做了审计”。这其实是不够的，标准必须要高一些。