留痕要回答的问题
审计留痕的价值在事后：事发时没有人能预知要查什么，所以记录必须覆盖五个要素——操作主体、时间、动作与目标对象、执行结果、依据（工单、审批或策略）。粒度选择是难点：按每个接口都记，日志会被高频只读查询淹没；只记登录与失败，追责时又拿不出关键动作。合理做法是按操作语义划分，优先保证变更类操作完整。
基本信息
| 必备字段 | 主体、时间、动作、对象、结果、来源地址、请求标识 |
|---|---|
| 记录范围 | 配置变更、权限变更、数据导出、审批动作、自动化执行 |
| 粒度选择 | 按操作语义划分，不按接口切分 |
| 内容取舍 | 记录动作与参数摘要，敏感参数脱敏后记录 |
| 留存要求 | 按合规要求设定保存期，集中存储并限制删除 |
典型使用场景
- 变更回溯：确认某次故障前谁改了什么、改动范围多大
- 安全事件调查：还原从登录、提权到数据导出的完整路径
- 合规审计取证：按周期提供可核查的操作记录与审批凭据
- 自动化归属：区分人工操作与平台自动执行，明确责任主体
- 双人复核验证：证明复核人确实在操作执行前完成了确认
操作类型与记录要求
| 操作类型 | 是否必留 | 关键字段 |
|---|---|---|
| 登录与认证 | 是 | 结果、来源地址、认证方式、失败原因 |
| 配置与代码变更 | 是 | 变更前后摘要、执行人、审批凭据 |
| 权限与账号变更 | 是 | 被授权主体、权限范围、有效期、批准人 |
| 数据导出与批量查询 | 是 | 导出范围、条数、用途说明 |
| 自动化与脚本执行 | 是 | 触发人、触发方式、任务标识、影响对象数 |
| 高频只读查询 | 可采样 | 按比例采样记录，避免淹没关键操作 |
| 作业与任务调度调整 | 是 | 变更前后调度参数、影响的任务 |
留痕字段示意
留痕字段示意
{
"ts": "2026-10-17T09:12:31+08:00", // 时间带时区，避免跨区对齐歧义
"actor": "zhangsan", // 主体：自然人账号，不用服务账号替代
"actor_type": "human", // 区分人工与自动化，便于责任归属
"action": "firewall_rule_add", // 动作名稳定，便于检索与聚合
"target": "host-01/sg-web", // 目标对象带定位符，不止写类型
"scope": "3 rules / 2 hosts", // 影响范围，事后判断爆炸半径
"params_digest": "sha256:9f2c...", // 参数摘要，敏感值不落原文
"result": "success",
"ticket": "REQ-20418" // 依据：关联工单或审批单号
}只记「成功/失败」不足以追责。真正需要的是影响范围：改了哪几台、影响多少条记录、波及哪些租户。范围字段决定了事后能否判断是否扩大为事故。
留痕内容本身也是敏感数据。口令、令牌、密钥、个人联系方式不得原文入库；用摘要或哈希保留可核验特征，同时避免把日志变成新的泄露面。