安全审批和日志审计不是两个孤立模块。审批解决事前授权 ，日志审计解决事中留痕、事后追溯 。真正有效的体系要能回答四个问题：谁发起、谁批准、谁执行、执行结果如何。
一、先划清审批范围
安全审批应覆盖高风险、高影响、高权限变更，而不是所有日常操作都走审批。
| 审批类型 | 典型场景 | 重点留痕内容 |
|---|---|---|
| 权限审批 | 账号开通、提权、角色变更、API 密钥申请 | 申请人、审批人、权限范围、有效期 |
| 变更审批 | 生产配置修改、数据库结构变更、防火墙规则调整 | 变更内容、回退方案、影响范围 |
| 数据审批 | 敏感数据导出、批量下载、外发、解密 | 数据字段、数量、用途、接收方 |
| 运维审批 | 远程登录、高危命令执行、临时访问 | 操作窗口、目标系统、操作理由 |
| 安全作业审批 | 动火、有限空间、高危设备检修 | 作业票、监护人、检测记录、应急措施 |
审批流程本身也要标准化：申请 → 风险评估 → 分级审批 → 执行 → 验证 → 归档。高风险操作建议加入"多人审批"或"双人复核"，避免单点授权失控。
二、日志审计要覆盖"三层"
日志审计不能只查登录记录。更完整的框架通常分为三层：
- 设备层：记录网络、主机、数据库、应用发生了什么。
- 身份层：把操作关联到具体账号、人员、设备。
- 行为层：判断行为是否异常，例如非工作时间批量导出、突然提权、访问从未接触过的系统。
三、审计日志必须包含哪些字段
一条合格的审计记录至少应包含：
- 时间：精确到秒，必要时到毫秒，所有系统需 NTP 时间同步。
- 主体：账号、人员、设备、IP、终端信息。
- 对象：被访问或修改的资源，如数据库表、文件、接口、配置项。
- 动作：登录、查询、导出、修改、删除、审批、执行。
- 结果：成功、失败、拒绝、部分成功。
- 上下文：关联审批单号、TraceID、会话 ID、变更前后值。
其中，"变更前后值"和"审批链路 ID"非常关键。没有它们，日志只能证明"有人做过"，但很难证明"他改了什么、依据是什么"。
四、日志留存与防篡改
合规上，日志通常要求集中存储、不可随意删除、留存不少于 6 个月；关键信息基础设施、金融、医疗等行业可能需要更长期限。
落地时要做到：
- 日志从源系统实时或准实时同步到独立审计平台。
- 审计平台与业务系统权限隔离，业务系统只能上报，不能删除。
- 启用访问控制、加密存储、哈希校验或 WORM 机制。
- 日志查询、导出、删除本身也要记录，形成"审计的审计"。
五、审批与日志如何串起来
理想链路是：
用户发起申请 → 生成 TraceID → 审批流流转 → 审批结果回写 → 执行动作携带 TraceID → 日志上报 → 审计平台关联还原。
例如敏感数据导出：
- 用户在数据平台发起导出申请，填写字段、数量、用途。
- 系统生成唯一 TraceID，触发部门负责人、安全或合规审批。
- 审批通过后，导出任务执行，文件加密、加水印。
- 下载、预览、外发行为继续上报日志。
- 审计人员可通过 TraceID 一键还原"申请---审批---执行---下载"全链路。
六、常见坑
- 审批在 OA，执行在业务系统，两边日志没有关联 ID，事后无法闭环。
- 只记录登录日志，不记录表单修改、附件替换、权限变更。
- 日志存在本地，管理员可直接删除或篡改。
- 共享账号未关联真实操作人，出问题无法定责。
- 审批通过但执行越权，缺少执行前校验和执行后复核。
七、落地路线
- 第 1 步：梳理关键系统、敏感数据、高危操作清单。
- 第 2 步：统一身份认证，清理共享账号和幽灵账号。
- 第 3 步：把审批阈值、临时提权、双人复核写进流程引擎。
- 第 4 步：集中采集日志，覆盖网络、主机、数据库、应用、终端。
- 第 5 步：建立异常告警，如非工作时间登录、批量导出、权限突增。
- 第 6 步：定期审计，形成"发现问题---处置---整改---复核"的闭环。
一句话概括：审批决定能不能做，日志证明实际做了什么，关联 ID 把它们串成同一条证据链。