第3章 巡检概念与目的
说实话，干了这么多年数据库安全运维，我最大的感受就是——**别等出事了再救火**。巡检这个概念，说白了就是主动去找问题，而不是等故障报警响了才手忙脚乱。
我刚入行那会，公司还没建立巡检制度，数据库加密审计日志全凭感觉看。有次一个加密密钥轮转失败，我愣是两个月后才发现。嗯，从那以后，我再也不敢把巡检当形式了。
3.1 巡检的定义
数据库加密审计日志巡检，简单讲就是：按照预设的周期和标准，对加密审计日志的完整性、一致性、合规性和安全性进行系统性检查。它不是查一次就完事，而是一个持续性的闭环过程。
核心要素
- 周期性：日检、周检、月检、季度检……频率由业务风险定。
- 标准化：检查项必须有明确基线，不能凭感觉。
- 可追溯：每次巡检记录都要留存，方便事后审计。
- 闭环性：发现问题 → 跟踪整改 → 验证关闭。
我个人习惯把巡检定义为“体检”——不是等疼了才去医院，而是定期做各项指标化验。加密审计日志就像病历本，巡检就是翻病历找异常。
3.2 巡检流程
我在项目中总结了一套标准巡检流程，拿过来就能用。一共6步，少了哪步都可能漏事。
- 制定计划：明确巡检范围（哪些库、哪些日志）、检查项（密钥是否过期、日志是否被篡改）、时间窗口。
- 采集数据：从数据库加密模块、审计系统、日志平台拉取原始数据。
- 执行检查：逐项比对预设基线。比如检查加密算法是否被降级、日志签名是否有效。
- 分析异常：对不符合项的根因分析，区分是配置错误、人为误操作还是攻击行为。
- 整改闭环：修复问题并验证，更新巡检记录。
- 生成报告：输出巡检结论、风险等级、改进建议，存档备查。
举个例子，检查日志完整性最常用的SQL片段：
-- 检视最近24小时内加密审计日志写入是否连续
SELECT date_trunc('hour', log_time) AS hour_slot,
COUNT(*) AS record_count
FROM encrypted_audit_log
WHERE log_time >= now() - interval '24 hours'
GROUP BY hour_slot
HAVING COUNT(*) < 100; -- 阈值根据业务量调整
嗯，注意这条SQL返回的行数如果大于0，说明某小时日志量异常偏低，可能是采集链路中断或加密模块罢工了。
个人技巧：每次巡检前先检查“上次巡检到下本次巡检之间的日志”是否存在断层。我遇到过多次因为日志轮转配置错误导致几小时的审计数据丢失，而在事后根本补不回来。
3.3 巡检 vs 监控：别再搞混了
很多人把巡检和监控当作一回事，其实差别很大。我画了个表格，你一看就明白。
| 维度 | 巡检 | 监控 |
|---|---|---|
| 触发方式 | 定时人工/自动化（周期驱动） | 实时持续（事件驱动） |
| 检查深度 | 全面体检（包含历史数据、完整性校验） | 指标级告警（如CPU、QPS、错误数） |
| 输出结果 | 详细报告、风险列表、改进建议 | 实时告警、仪表盘 |
| 闭环能力 | 自带跟踪整改流程 | 仅通知，需人工介入整改 |
| 典型场景 | 密钥到期检查、日志合规审计 | 数据库连接数突增、慢查询 |
| 覆盖范围 | 全量交叉比对 | 典型指标采样 |
注意：不要用监控替代巡检。监控告诉你“现在出问题了”，但巡检能告诉你“过去一个月有没有隐性风险”。两者是互补关系，不是替代关系。
3.4 本章知识体系
下面这张图把巡检的定义、流程、以及与监控的关系串了起来。你把它记在脑子里，写巡检方案就不会漏要素了。
你仔细看这个图，左边是巡检流程的五个步骤，可以反向循环形成闭环；右边把巡检和监控并列对比，突出它们的不同定位。
3.5 一点个人感悟
交代一个我踩过的坑：**不要只在出事后才想起巡检**。有次客户数据库被勒索，我们发现半年前的审计日志居然有篡改痕迹，但因为没做周期巡检，等发现时密钥已经泄露了三个月。后来我们强制加了“日检+周检+月检”三层体系，再没出过类似问题。
所以，巡检不是形式，是防守的最后一道保险。把这个道理跟你的开发负责人讲清楚，比写十页文档都管用。