审计日志证据链

大理论

审计日志不是普通 timeline。安全、合规和支持团队需要用它还原事件：权限变更、成员加入、token 创建、产品设置修改、导出动作、失败请求、第三方 app 行为。界面必须让用户从大量事件中缩小范围、打开详情、复制结构化数据、导出筛选结果，并理解日志延迟、保留期和权限边界。

小知识点

1. 搜索和过滤维度至少包含 actor、target/user、action/category、resource、repo/project/site、date range、IP/location、result 和 source app。
2. 详情面板展示 human summary 和 raw JSON；复制/导出应保留查询条件、时间范围和导出时间。
3. 时间统一说明时区，安全调查默认显示绝对时间而不是只显示相对时间。
4. 新事件可能有延迟；界面要说明 last updated、retention、plan/permission 限制和导出上限。
5. 风险事件需要高亮并可串联上下文，例如权限变更后导出、token 创建后 API 调用、组成员变更后访问敏感项目。
6. 空状态也要解释是没有事件、没有权限、筛选太窄、日志尚未到达，还是超出保留期。

设计判断

如果调查者能从一条异常进入相关事件链，并导出可复查的数据，审计界面是有效的；如果只能滚动不可筛选的活动列表，它无法支持取证和合规。

实现建议

建立 audit event schema：id、timestamp、actor、actorType、action、category、target、resource、resourceScope、result、ip、userAgent、sourceApp、requestId、metadata、rawJson、retentionUntil、exportBatchId。前端采用 filter bar + result table + detail side panel + export flow；导出按钮要显示当前筛选范围和预计限制。为敏感事件提供相关事件建议和 copy JSON 动作。

反例/风险

只用相对时间、没有时区、搜索只能全文匹配、详情没有 raw payload、导出不带筛选说明、权限不足时显示空白、日志延迟被误解为没有发生、风险事件只靠红色。

案例分析

Atlassian 的 audit log 文档说明可按用户、邮箱、活动名、站点和日期搜索，并在详细侧栏查看活动和 JSON；GitHub 组织审计日志支持按 action、actor、user、org、repo、created 等 qualifier 搜索并导出 JSON/CSV；Microsoft Purview audit search 强调日期范围、活动、用户和权限角色。可学习点是：审计日志 UI 要围绕调查查询、结构化详情和可导出证据设计，而不是围绕漂亮时间线。

来源链接

Atlassian audit activities in Jira: https://support.atlassian.com/jira-cloud-administration/docs/audit-activities-in-jira-applications/ Atlassian view audit log activities: https://support.atlassian.com/security-and-access-policies/docs/view-audit-log-activities/ Atlassian export audit logs: https://support.atlassian.com/security-and-access-policies/docs/export-audit-logs/ GitHub reviewing audit log: https://docs.github.com/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization Microsoft Purview audit search: https://learn.microsoft.com/en-us/purview/audit-search