使用审计日志

你所在组织的每一次 API 请求都会被记录，并保留 365 天 - 谁、做了什么、何时、从哪里发起、属于哪个应用。这是你了解发生了什么的第一站。

Didit 支持团队撰写 · 更新于 2026年8月19日

#记录了什么

1234

1. 按成员、路径、方法或日期筛选，用来回答“是谁改的这个”。
2. Method 和 Status 可以区分一次读取和一次真正生效的变更。
3. 发起该次调用的成员。
4. 请求的来源 - 正是这一项细节，让日志真正成为证据。

组织内向 Didit 平台发起的每一次请求，无论由什么发起。每条记录包含：

日志保留 365 天，之后自动删除。

#它真正的用途

以下四种情况是使用它的正确场景：

• "这个工作流是谁改的？" 某个流程的行为与昨天不同，背后通常有一次编辑操作，日志会记录是谁做的。
• 调查事故。 精确追溯谁在什么时间、从哪个地址、按什么顺序访问了什么内容。
• 调试集成。 查看你自己的代码实际发出了哪些请求，而不是你以为它发出了哪些 - 包括那些返回 4xx 的请求。
• 证明访问控制的有效性。 向审计人员证明对核验数据的访问都有明确归属且可被复核。

#筛选

按用户、接口或日期范围筛选，缩小一份很长的列表。当你在排查某个具体问题时，从时间戳出发向外扩展 - 一次请求很少是孤立发生的，它附近的调用通常能说明来龙去脉。

#API 密钥发起的请求归属于应用，而非某个人

API 密钥发起的请求没有可归属的用户，因此会显示归属于该应用。这才是真实的情况 - 平台确实无法得知这次调用具体来自你哪一个服务或哪一位工程师。

由此带来的实际后果是：多个服务共用同一个密钥，会让事故排查明显更困难。如果归属关系对你很重要，请为每个调用方配置各自独立的应用和密钥。

#日志里有什么，没有什么

日志记录的是活动 - 谁调用了什么、何时、从哪里，以及返回了什么状态。它是一份元数据轨迹，不是核验数据本身的副本。

如果你需要确认客户的个人数据是否会出现在这些记录中 - 这是数据保护审查中经常出现的问题 - 请向你的 Didit 联系人获取答案并留存记录，而不要靠这篇帮助文章自行推断。这正是你自己的 DPIA 需要拿出证据支持的那类陈述。

#谁能看到它

审计日志的访问权限取决于角色。Compliance Officer 包含该权限；Reader 不具备完整访问权限。Owner 可以将该权限授予自定义角色。参见邀请团队成员并设置角色。

移除某位同事，并不会移除他们在日志中留下的历史记录 - 这正是它的意义所在。一份可以被修改的记录，就不是真正的记录。

#导出和报告同样会被记录

生成一份会话 PDF 或导出一份 CSV 本身就是一次 API 调用，因此也会出现在这里，并记录是谁执行的。当你需要证明对核验证据的访问是受控的而非开放的时，这一点很有用。参见下载核验报告。

#如果你需要超过 365 天的保留期

保留期固定为 365 天。如果你的义务要求更长的保留期，请按计划导出所需数据，并保存在你自己的系统中 - 这和你自行保留会话证据是同样的做法。所需保留期限是你团队要做出的合规决策，不要凭假设去设计方案。