平台操作审计日志至少要回答五个问题：谁、何时、在哪里、做了什么、影响了什么。落到字段上，就是账号与来源、时间戳与时区、平台模块与对象标识、操作类型与结果状态、变更前后值与关联审批单。字段并非越多越好，先按操作风险分级确定记录深度和保留期限，再补齐会话标识、敏感动作标记和日志自身的完整性信息，才能既追得到责任，也还原得了现场。
要点总览（TL;DR）
- 审计日志至少保留五类信息：账号与来源、时间与时区、平台模块与对象标识、操作类型与结果、变更前后值与关联审批单。
- 字段按操作风险分级：登录、权限变更、批量导出删除等高风险操作记完整前后值与审批关联，日常读写记摘要。
- 保留期限取内部制度、合同监管要求与排障需要中较严者作为下限，例外延长或提前清理需明确审批人。
- 落地按六步推进：梳理操作清单、定义字段字典、确认采集方式、确定存储与保护、建立检索导出、设定保留清理。
- 验收看四点：敏感操作能否快速定位、变更能否还原、日志能否防篡改、访问与清理是否有记录。
审计日志字段清单：五类必留信息与扩展项
字段设计可以先立三个目标：可追责，能定位到具体账号和来源；可还原，能重建操作前后的状态；可检索，能按人、按对象、按时间段快速查到记录。三个目标对应到字段上，就形成下面的清单。必留项是任何一条审计记录都应具备的最小集合，扩展项按平台规模和操作风险选择性启用。
| 字段名 | 含义 | 是否必留 | 示例值 | 采集来源 |
|---|---|---|---|---|
| account_id | 操作账号的唯一标识 | 必留 | u_10237 | 平台账号体系 |
| account_name | 账号显示名或姓名 | 必留 | 张明 | 账号目录 |
| role | 操作时所持角色或权限集 | 必留 | 项目管理员 | 权限系统 |
| source_ip | 发起操作的来源IP | 必留 | 10.12.3.45 | 网关或应用层 |
| client_info | 终端或客户端标识 | 必留 | Web/Chrome 126 | 请求头 |
| event_time | 操作发生时间 | 必留 | 2025-03-11 14:22:07 | 应用层 |
| time_zone | 时间戳所属时区 | 必留 | UTC+8 | 平台配置 |
| write_time | 日志写入存储的时间 | 必留 | 2025-03-11 14:22:09 | 日志服务 |
| platform_module | 所属平台与功能模块 | 必留 | 项目设置/成员管理 | 应用层 |
| object_type | 被操作对象类型 | 必留 | 项目成员 | 应用层 |
| object_id | 被操作对象唯一标识 | 必留 | proj_8821/member_4471 | 应用层 |
| action_type | 操作类型 | 必留 | 角色变更 | 应用层 |
| request_method | 请求方式或操作入口 | 必留 | PUT /api/members/4471 | 应用层 |
| result_status | 成功或失败 | 必留 | 成功 | 应用层 |
| fail_reason | 失败原因码或说明 | 必留（失败时） | 403 权限不足 | 应用层 |
| before_value | 变更前值或状态摘要 | 必留（变更类） | 角色=项目管理员 | 应用层 |
| after_value | 变更后值或状态摘要 | 必留（变更类） | 角色=普通成员 | 应用层 |
| related_ticket | 关联审批单或工单号 | 必留（有审批时） | APR-2025-0311-07 | 审批系统 |
| session_id | 会话标识 | 扩展 | sess_9f3a… | 应用层 |
| request_id | 单次请求标识，便于跨系统串联 | 扩展 | req_7c21… | 网关 |
| sensitive_flag | 敏感动作标记，如导出、批量删除、权限变更 | 扩展 | export_bulk | 规则引擎 |
| storage_location | 日志存储位置 | 扩展 | 审计库/分区2025Q1 | 日志服务 |
| integrity_status | 是否被修改、校验值 | 扩展 | 哈希校验通过 | 日志服务 |
| retention_tag | 留存周期标记 | 扩展 | 保留365天 | 日志服务 |
必留项与扩展项的界线可以这样把握：缺少必留项，日志无法支撑追责或还原；扩展项用于提升检索效率和证据可信度，在日志量可控、存储成本可接受时逐步补齐。会话ID和请求ID在多系统串联排查时价值明显，敏感动作标记则让后续检索不必逐条翻查。
从操作风险出发确定记录深度与保留期限
把所有操作都记成完整前后值，日志量会迅速膨胀，检索和存储成本随之上升；只记操作人和时间，又会在关键事件上丢失还原能力。可行的做法是按操作风险分级，高风险操作记录完整前后值与审批关联，低风险操作记录摘要，再为每级设定对应的保留期限。
| 风险级别 | 典型操作 | 记录深度 | 保留期限建议 | 例外审批人 |
|---|---|---|---|---|
| 高 | 登录与身份认证、权限与角色变更、批量导出、批量删除、密钥或集成配置变更 | 完整字段，含前后值、审批单、会话与请求标识、敏感动作标记 | 不少于12个月，按制度或合同要求可延长 | 安全或合规负责人 |
| 中 | 项目配置变更、工作流与字段调整、成员增删 | 完整主体与对象字段，变更内容记差异摘要 | 6至12个月 | 平台管理员负责人 |
| 低 | 日常读写、评论、状态流转 | 主体、时间、对象、动作与结果，变更内容记摘要或不记 | 3至6个月，按排障需要调整 | 平台管理员 |
保留期限的确定依据主要有三类：内部制度对审计留痕的要求、合同与监管对数据留存的规定、排障与复盘的实际需要。三者取较严者作为下限，再结合存储成本决定是否延长。期限一旦确定，应写成配置而不是口头约定，并明确谁有权批准例外延长或提前清理。清理动作本身也要留记录，否则无法证明日志是按规则到期删除，而非被有意抹除。
落地步骤：从字段定义到日志可用
字段和分级确定后，落地可以按六步推进。每一步都应有明确输入、动作、输出和完成标志，避免停留在方案文档层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 梳理操作清单 | 平台功能清单、权限模型 | 列出需要审计的操作与对象范围，标注风险级别 | 操作清单与风险标注表 | 高风险操作无遗漏，经安全负责人确认 |
| 2. 定义字段字典 | 操作清单、字段清单表 | 确定字段名、类型、必填选填、命名规范 | 字段字典文档 | 开发与审计使用方对字段含义理解一致 |
| 3. 确认采集方式 | 平台架构、现有日志能力 | 在平台自带审计、接口拉取、网关或代理层记录之间选择并组合 | 采集方案说明 | 高风险操作全部有采集路径，覆盖范围可验证 |
| 4. 确定存储与保护 | 日志量估算、合规要求 | 设定存储位置、访问权限、防篡改措施 | 存储与权限配置 | 普通账号无法修改或删除审计日志 |
| 5. 建立检索与导出 | 字段字典、典型查询场景 | 配置按人、按对象、按时间段的查询与导出流程 | 检索操作说明 | 能在约定时间内查出指定敏感操作的完整记录 |
| 6. 设定保留与清理 | 分级保留期限表 | 配置到期清理规则，记录清理动作 | 保留策略配置与清理日志 | 到期清理按规则执行且可追溯 |
采集方式的选择需要权衡覆盖范围与维护成本。平台自带审计覆盖面广、接入快，但字段可能受产品设计限制；网关或代理层记录能捕获请求级信息，对未内置审计的模块形成补充，代价是需要额外维护解析规则。两者组合时，应以请求ID或会话ID把不同来源的记录关联起来，避免形成互不相通的数据孤岛。
在研发协作平台中，权限变更、工作项状态流转、文档发布等动作往往分散在多个模块。ONES 支持多团队组织架构管理，团队间数据隔离，并可通过 LDAP、Microsoft AD 同步组织架构与验证登录，支持 CAS、SAML 等单点登录方式，这些身份与组织信息可以作为审计日志中主体字段的来源。日志的存储与保护则可依托平台的数据安全措施，包括 HTTPS 与 TLS 1.2 传输加密、敏感数据加密存储、数据备份以及数据存储组件的实时监控告警。审计字段的具体覆盖范围与保留策略，仍需结合平台实际配置向厂商核验后确定。
角色分工与交付物
审计日志无人维护，通常源于职责没有落到具体角色。字段定义、采集配置、期限审批、检索取证分别由不同角色承担，交接节点写清楚，机制才能持续运转。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 平台管理员 | 梳理操作清单、维护字段字典、配置采集 | 操作清单、字段字典、采集配置说明 | 向安全负责人提交分级方案；向研发运维移交采集需求 |
| 安全或合规负责人 | 确定保留期限、审批访问权限与例外 | 保留期限表、权限审批记录、例外审批单 | 向平台管理员反馈审批结论；定期复核权限 |
| 研发与运维团队 | 日志接入、存储容量规划、告警规则配置 | 接入方案、容量评估、告警规则 | 向审计使用方交付检索入口；向平台管理员反馈采集异常 |
| 审计使用方 | 提出检索需求、执行取证、输出报告 | 检索需求清单、取证记录、审计报告 | 向安全负责人提交报告；向平台管理员反馈字段缺口 |
交接的关键在于把口头约定变成可核对的产物。例如平台管理员交付字段字典时，应同时说明每个字段的采集来源和缺失时的处理方式；审计使用方反馈字段缺口时，应给出具体查询场景，便于判断是字段缺失还是检索方式不当。
示例：一次权限变更操作应记录的完整日志
以某成员被从项目管理员调整为普通成员为例，一条合格的日志大致如下（示例数据，仅用于说明字段填写方式）：
| 字段 | 示例值 | 用途 |
|---|---|---|
| account_id / account_name | u_10237 / 张明 | 追责：定位操作人 |
| role | 项目管理员 | 追责：确认操作时所持权限 |
| event_time / time_zone | 2025-03-11 14:22:07 / UTC+8 | 检索：按时间段定位 |
| source_ip / client_info | 10.12.3.45 / Web-Chrome 126 | 追责：判断来源是否异常 |
| platform_module | 项目设置/成员管理 | 检索：按模块筛选 |
| object_type / object_id | 项目成员 / proj_8821/member_4471 | 检索与还原：定位被操作对象 |
| action_type / request_method | 角色变更 / PUT /api/members/4471 | 还原：确认操作性质 |
| before_value / after_value | 角色=项目管理员 / 角色=普通成员 | 还原：重建变更前后状态 |
| related_ticket | APR-2025-0311-07 | 追责：关联审批依据 |
| result_status | 成功 | 还原：确认变更已生效 |
| session_id / request_id | sess_9f3a… / req_7c21… | 检索：跨系统串联同一操作 |
这条记录中，账号、来源IP、角色和审批单支撑追责；对象标识、前后值和结果状态支撑还原；时间、模块、对象和请求标识支撑检索。常见缺失有两类：只记操作人不记对象，事后无法确认改的是哪个成员；只记结果不记前后值，无法判断变更幅度，也难以在误操作后恢复原状。设计字段时可以用这条示例逐项对照，检查自己的日志是否覆盖了这三类用途。
完成检查：审计日志是否可用的验收项
字段设计和落地配置完成后，用下面的清单逐项核对。每项都给出通过标准和证据要求，避免验收停留在“看起来配了”的层面。
| 检查项 | 通过标准 | 证据要求 |
|---|---|---|
| 敏感操作可定位 | 能在约定时间内查出某次权限变更或批量导出的完整记录 | 一次实际检索的截图或查询记录 |
| 变更可还原 | 记录中包含变更前后值，可重建操作前状态 | 抽样若干条变更日志的字段核对结果 |
| 日志完整性受保护 | 具备防篡改措施或完整性校验，普通账号无法修改删除 | 权限配置说明、校验机制说明 |
| 保留与清理已生效 | 保留期限按分级配置，到期清理有记录 | 保留策略配置、清理日志样本 |
| 日志访问受控 | 查看和导出日志的权限受控，访问行为本身被记录 | 权限清单、日志访问记录 |
| 失败与异常被记录 | 失败操作、异常登录有记录且含原因码 | 失败操作日志样本、异常登录告警记录 |
验收中发现缺口时，回到字段字典和采集方案定位原因：是字段未定义、采集未覆盖，还是检索方式不当。把缺口和整改结论记录下来，作为下一轮复核的输入，审计日志机制才能随平台功能变化持续保持可用。
常见问题
平台已经自带操作日志，还需要额外建设审计日志吗？
先核对平台自带日志是否覆盖必留字段，尤其是变更前后值、对象唯一标识和失败原因码。自带日志通常覆盖主体、时间、动作与结果，但变更内容可能只记摘要，或缺少跨模块的统一对象标识。若关键字段缺失，可在网关或代理层补充请求级记录，并用请求ID或会话ID与平台日志关联，形成完整链路。补充采集前先确认平台日志的导出与接口能力，避免重复建设。
日志保留期限定多长比较合适，超过期限的日志能不能直接删除？
保留期限取内部制度、合同与监管要求、排障需要三者中较严者作为下限，高风险操作通常不少于12个月。到期清理应按预先配置的规则自动执行，并保留清理动作本身的记录，包括清理时间、范围、执行人和规则版本。若业务方提出延长或提前清理，应走例外审批并留存审批单，避免出现无法解释的日志缺失。
审计日志本身被有权限的人修改或删除，怎么防范？
从三方面控制：存储上把审计日志与业务数据分离，普通账号无写入和删除权限；机制上启用完整性校验，例如对每条记录计算校验值或按批次生成摘要，定期比对；流程上把日志的查看、导出、清理都作为敏感操作记录在案，形成对审计日志的二次审计。权限清单和校验机制说明应作为验收证据留存。
研发团队规模不大，字段和分级能不能简化？
可以简化扩展项，必留字段建议保留。小团队可先不启用会话ID、请求ID等扩展字段，把账号、时间、来源IP、对象标识、操作类型、结果状态和变更前后值配齐，高风险操作单独标注。风险分级可先分两级：权限与数据导出删除类为高，其余为低。随着团队和系统数量增加，再补充跨系统串联字段和更细的分级。
审计日志和过程合规审计的证据是一回事吗？
两者相关但范围不同。平台操作审计日志记录的是平台内的操作行为，用于追责、还原和异常排查；过程合规审计关注研发过程是否按流程执行，证据包括评审记录、审批流转和交付物状态。审计日志可以作为过程合规的证据来源之一，但流程合规还需要结合工作项流转记录、评审结论等材料。设计时把日志字段与流程节点标识关联，能减少后续取证时的重复工作。
