使用审计日志

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

#记录了什么

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

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

改版后的审计日志正在逐步上线，它会用文字描述每一项更改，并能导出你当前查看的内容。在它向你的组织开放之前，该页面显示的是本文所述的请求日志。

#它真正的用途

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

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

#筛选

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

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

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

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

#调查员自行作出的决定归属于调查员

当调查员在你授予的自主权限内自行作出决定时，该条目显示的是调查员，而不是某个人或某个密钥。这涵盖它作出的每一项决定：批准或拒绝会话、要求用户重新提交、设置交易状态，以及解决案件、升级处理案件或就案件请求信息。每一条这样的条目都链接到该决定背后的调查员报告，让你看到它发现了什么、应用了你政策中的哪条规则。

当某个人就调查员报告作出决定，即接受其建议或改判时，该条目归属于这个人，就像他所做的其他任何更改一样。调查员的完整记录，包括它的报告、问题和安全规则，仍保存在它自己的活动日志中。参见控制和监督调查员。

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

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

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

#谁能看到它

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

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

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

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

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

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