审计日志是什么？
记录关键行为的主体、时间、对象、动作和结果，支持事件还原与责任追踪。字段必须有明确的业务语义。[1]
004 / 安全运营 / Audit Log
谁把数据带走了？
审计日志 · Audit Log
凌晨，一份客户目录被导出。别急着猜答案。拆开日志、找齐线索，再做判断。今天学会用证据还原一次操作。
开始探索 ↓8–12 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
把散落的记录，整理成一条有依据的故事。
本课任务 / 审计日志
把“谁、何时、做了什么、结果如何”连成一条可核查的线索。
- 读懂六组审计字段及其边界
- 区分请求受理与实际完成
- 随着新证据调整调查判断
亲手探索 / 不同条件，不同结果
把日志变成可以核查的证据。
从字段、记录到情境判断，完成三段调查。所有人物与数据均为虚构教学示例。
所有记录均为虚构教学数据。进度仅保留在当前页面，刷新后重新开始。
任务 01 / 拆开一条记录
日志里的每个字段，都有工作。
点选六个问题，查看对应字段和容易误判的边界。示例中会标出正在检查的部分。
已探索 0 / 6 个问题
从一个问题开始
别只看“成功”两个字。
点击上方问题，找出能够支持判断的字段。好日志的目标是准确、可关联和可调查，不是把所有信息都收进来。
判断边界：所有字段都需有约定的业务语义，同名字段在不同系统里也可能含义不同。
把记录拆成问题。主体、时间、动作、结果、授权和关联标识，合起来才有调查价值。
audit-event.json · 已完成的导出事件
{
"event_id": "evt_demo_005",
"event_time": "2026-10-08T02:17:09.324Z",
"observed_time": "2026-10-08T02:17:09.611Z",
"service": "customer-api",
"actor": {
"id": "usr_0841", "type": "user"
},
"action": "customer.export.completed",
"target": "customer_directory",
"outcome": "success",
"records_count": 12500,
"source_ip": "192.0.2.44",
"authn_method": "password+mfa",
"authorization": {
"decision": "allow",
"policy": "customer-export:v3"
},
"interaction_id": "req_7d91"
}时间使用 UTC；192.0.2.44 属于文档示例地址段。真实日志只采集必要信息，避免记录密码、令牌或完整敏感正文。
任务 02 / 从日志里找证据
六条记录，哪些能接上故事？
筛选日志、打开详情，再勾选支持“身份 → 授权变化 → 完成结果”的三条关键记录。筛选不会清除已选线索。
按顺序整理事件，也要留意日志采集链路的缺口。
案件卡 / 虚构教学场景
02:17，客户目录被导出。
账号 usr_0841 导出了 12,500 条记录。事情发生在凌晨，但调查不能停留在“看着可疑”。先把前因后果补齐。
以下所有时间均为 UTC。
先打开一条记录。
点击任意记录右侧的“详情”， 检查具体动作、对象和结果。
提示：请求受理与业务完成是两个阶段。运行日志也不一定能回答“谁做了什么”。
已选 0 条 · 目标 3 条关键记录
没有找到日志，不能直接推断操作没发生。还需要排查事件覆盖范围、生成、缓冲、传输、索引、查询权限与时间范围。
任务 03 / 根据证据改变判断
线索变了，结论也要跟着变。
切换不同情境，再选择下一步。每个选择都会说明依据；你可以反复尝试，不必靠猜答案过关。
当前情况
线索还不完整
你已看到登录、授权变更与导出成功。操作发生在凌晨，MFA 也通过了。但审批是否有效、是否在业务计划内，还没核对。
调查判断有边界：一条记录不能证明全部事实，一次正常操作也不能证明账号永远安全。
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
日志也需要被保护。读取、修改、删除权限，以及副本与完整性验证，都影响它的证据价值。
01 / 实用细节
关键事件，成功与拒绝都要考虑
按风险覆盖登录、权限变更、敏感数据操作和关键配置变更。业务记录、应用日志和审计日志可以共享事件，但用途、字段和权限应明确。[1]
02 / 实用细节
时间、请求与事件标识要一致
同步时钟、明确时区，区分发生与观察时间。考虑重试、异步任务和延迟投递；同一请求可产生多条合法事件，不宜按关联 ID 直接去重。[3][1]
03 / 实用细节
限制谁能改，验证是否被改
适当分离业务与日志管理权限；保护传输和副本。按风险采用追加写、不可变存储或密码学校验。加密保密不等于防篡改，校验也不证明所有事件都被采集。[4][2]
04 / 实用细节
留下证据，排除秘密
不直接记录密码、访问令牌、原始会话凭据和私钥。个人信息按需要最小化或去标识化；对不可信输入做安全编码与长度限制，避免日志注入。[1]
05 / 实用细节
保存多久，要有依据
依据适用要求、组织政策和调查需要制定保留、归档与删除策略，覆盖副本与备份，并验证归档能恢复查询。不存在所有系统通用的固定保存天数。[2]
06 / 实用细节
让采集失败也有人发现
测试断连、磁盘满、格式变更、权限错误与采集停止。明确告警责任人和缓冲、恢复方式；日志失败时是否影响业务，要事先按风险约定。[1][2]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
要追查是谁导出了客户数据，哪类记录最有用？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- OWASP · Logging Cheat Sheet ↗
事件选择、字段、排除数据与故障验证
- NIST SP 800-92 · 日志管理 ↗
日志基础设施、保护、管理与保留；基础资料发布于 2006 年
- OpenTelemetry · Logs Data Model ↗
事件发生时间与观察时间
- AWS CloudTrail · 日志完整性验证 ↗
特定产品的完整性验证示例，不代表全量采集证明
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。