审计日志基础模型：字段定义与不可否认性设计
加密审计日志的核心在于不可否认性与检索效率之间的平衡。本章定义日志的基础数据结构，字段必须同时满足安全审计、快速查询与合规取证需求。
日志结构设计原则
- 最小冗余：每行日志携带的字段仅覆盖审计必要信息，避免存储膨胀影响写入吞吐。
- 链式哈希：每条日志需包含前一条日志的哈希摘要，形成防篡改链条。
- 字段级加密：敏感数据（用户身份、操作对象）采用对称加密存储，非敏感字段明文存储以支持索引。
- 时戳精度：使用毫秒级时间戳（Unix ms）或网络时间协议(NTP)同步后的微秒级时间戳。
核心字段定义
| 字段名 | 类型 | 长度 | 说明 | 加密/明文 |
|---|---|---|---|---|
LOG_ID | BIGINT | 8B | 自增主键或UUID | 明文 |
TIMESTAMP | BIGINT | 8B | Unix毫秒时间戳 | 明文 |
USER_ID | VARCHAR(64) | ~64B | 操作用户唯一标识 | 加密（AES-256-GCM） |
OP_TYPE | TINYINT | 1B | 操作类型枚举（0=查询,1=修改,2=删除...） | 明文 |
SENSITIVE_DATA | BLOB | 可变 | 加密后的敏感操作内容（如修改的字段值） | 加密 |
SOURCE_IP | VARCHAR(39) | ~39B | 客户端IP（IPv6兼容） | 明文 |
PREV_HASH | CHAR(64) | 64B | 上一条日志SHA-256摘要 | 明文 |
CURR_HASH | CHAR(64) | 64B | 本条日志（加密字段取密文后）的SHA-256摘要 | 明文 |
SIGNATURE | BLOB | ~512B | 使用系统私钥对CURR_HASH的RSA签名 | 明文 |
设计要点：
PREV_HASH 和 SIGNATURE 联合构成不可否认性基础；字段 OP_TYPE 用 TINYINT 枚举可使索引更紧凑；加密字段的索引通过冗余的明文哈希列实现（后续章节详述）。
不可否认性机制
不可否认性依赖链式哈希 + 数字签名的双重保证：
- 前向链：新日志的
PREV_HASH取自上一条日志的CURR_HASH，任何中间修改都会破坏后续链条。 - 后端签名：系统对
CURR_HASH用私钥签名，验证方使用公钥即可确认日志生成者的身份。 - 时间锚点：定期（如每分钟）将当前链的末尾哈希写入外部不可篡改存储（如区块链或WORM介质），防止整条链被替换。
常见误区：仅依赖链式哈希不足以防篡改——攻击者可重算全部链条。必须配合外部哈希锚定或系统级数字签名。
日志记录结构图
索引设计前置思考
由于敏感字段加密后不可直接作为B-tree索引列，需要在日志表中增加冗余的明文哈希索引（如 USER_ID_HASH）来支撑等值查询。具体实现将在第4章《索引策略实战》中展开，但基础模型阶段已预留该设计空间：
USER_ID_HASH：SHA-256(USER_ID)后截取前16字节，作为查找匹配的确定性指纹。OP_TYPE_TIME：联合索引 (OP_TYPE, TIMESTAMP) 提升操作类型时间范围扫描性能。PREV_HASH_INDEX：对链式字段建立唯一索引，加速反查验证。
性能基线数据：在典型SSD磁盘上，上述基础模型（含链式哈希及签名字段）的单条日志写入耗时约 120μs（无加密字段）至 280μs（含AES-256加密字段），写入吞吐量可达 3500~8000 QPS 单机。后续章节将介绍如何通过批量提交、缓冲池与索引剪枝进一步提升至 5万QPS以上。