3. 加密搜索系统日志架构
好，咱们开始聊日志架构。很多人觉得日志嘛，不就是打几条记录吗？真不是。加密搜索系统的日志，比你想象的要敏感得多。我早年在这上面栽过跟头，后来才明白——日志本身就是一条数据链路，哪一环出问题，审计就两眼一抹黑。
3.1 日志生成源
加密搜索系统里，日志不是只有一种。我习惯按组件切成三类：
- 搜索网关层：接收用户请求，生成接入日志。包括时间戳、来源IP、请求的密文索引标识、响应状态码。这类日志通常明文生成，不涉及密钥材料。
- 生成服务：把用户的明文关键词转成搜索陷门（trapdoor）。这里要格外小心——不能记录明文关键词。我曾经碰到一个项目，开发图方便直接把用户输入的原文打了日志，审计一看，加密等于白做。
- 加密索引引擎：执行密文比对，返回匹配的文档ID。它会生成查询执行日志，记录查询耗时、命中数量等性能指标。
SRC-GW-，服务用 SRC-TK-。一旦排查问题，一眼就能定位源头。
另外，别忘了系统组件自身的运行日志。比如加密密钥的加载/轮换、网络重连、内存警告。这些虽然不直接跟用户请求挂钩，但对安全审计来说，它们能暴露配置上的漏洞。
3.2 传输机制
日志生成之后，怎么送到存储端？这里面门道也不少。我总结过三种常见模式：
| 模式 | 描述 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 同步推（Push） | 应用线程直接写入日志管道，阻塞或非阻塞 | 低延迟要求，审计完整性需高 | 同步阻塞导致搜索响应变慢，后来加了一个内存环形缓冲区才解决 |
| 异步拉（Pull） | 日志代理（如Fluentd、Logstash）主动采集 | 高吞吐、解耦 | 采集代理崩溃，日志丢失一整晚，之后强制加了本地spool文件 |
| 混合模式 | 本地先写文件，再异步转发到中心日志库 | 追求可靠性与性能平衡 | 这法子我目前在用，代价是多了磁盘I/O，但从来不会丢日志 |
传输过程中，加密搜索系统的日志必须做机密性和完整性保护。为什么？因为攻击者如果截获了生成日志，就能推断出用户搜索模式；如果篡改了索引引擎的查询日志，事后审计就全废了。我建议至少用TLS 1.3传输，同时给每条日志附加HMAC签名。
3.3 存储模型
日志落地之后，存储结构直接决定了审计效率。加密搜索系统的日志有三大存储维度：
- 时间维度：按分钟/小时分片，默认保留90天。我习惯用UTC时间戳作为分区键，避免时区混乱。
- 请求ID维度：一条完整搜索请求的日志分散在多个组件中，必须靠全局唯一的请求ID关联。这个ID在网关层生成，透传给服务和索引引擎。
- 审计标签维度：打上安全等级标签，比如
LEVEL_1（正常查询）、LEVEL_2（疑似泄露）、LEVEL_3（故障+告警）。审计巡检时可以按标签快速过滤。
存储引擎方面，我推荐用列式存储或者时序数据库。为什么？因为审计查询通常是大范围时间扫描 + 少量字段聚合，行式数据库在这种场景下IO开销巨大。我在一个项目里把Elasticsearch换成了ClickHouse，同样的查询从30秒降到2秒。
下面这张图概括了整个日志架构的核心流程：
3.4 日志格式与字段设计
有了架构，还得定字段。我推荐所有组件统一使用JSON格式，并且包含以下公共字段：
timestamp：ISO 8601 UTC，精确到毫秒request_id：全局UUID，串联整条请求链component：来源组件名event_type：接入、陷门生成、索引查询、系统运行等security_level：1～3payload：组件特有的结构化数据（比如查询耗时、命中数）
关键点：payload里不能出现任何明文密钥、原始搜索词或解密后的文档内容。加密搜索的日志本身就应该是不加密的（因为要审计），但如果里面混了敏感数据，那等于自爆。我见过一个团队把base64编码的加密文档ID当普通字符串写进日志，虽然ID本身是密文，但结合上下文就能推断出用户兴趣——这种事情审计一查一个准。
3.5 日志的留存与轮转策略
日志不能无限存，也不能存太短。我个人的经验值：
- 热存储（在线可查）：7天，使用快速SSD或内存表
- 温存储（可延迟查询）：90天，慢速HHD或对象存储
- 冷归档（合规保存）：1年以上，压缩后放廉价存储
轮转策略要保证日志完整性不断。我习惯每1小时压缩切分一次文件，文件名带上时间戳和请求ID起始值。这样万一某个文件损坏，只损失最多1小时数据，而且可以用前后两个文件的id区间推导出缺失范围。
logrotate的默认按天轮转。加密搜索系统流量峰值往往在几分钟内，一天一个文件太大了，排查时加载几个GB文件，审计工具直接卡死。按小时切分，每个文件控制在200MB以内，这是我用性能压测压出来的经验值。
好了，这就是加密搜索系统日志架构的三个核心部分：生成源怎么划分、传输怎么保证安全可靠、存储模型怎么选才能又快又好查。下回我们聊如何为这些日志设计专门的审计规则。