# 使用审计日志

Source: https://help.didit.me/zh/account-organization/audit-logs
Updated: 2026-10-29

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

你所在组织的每一次 API 请求都会被自动记录，并保留 **365 天** -
无论来自控制台、你的集成，还是你的同事。可在**设置 → 审计日志**中查看。
调查员自行作出的每一项决定也会记录在这里，操作人显示为**调查员**。

[Video: 审计日志 - Didit Academy](https://www.youtube.com/watch?v=MkULotdgz2o&t=31)

## 记录了什么

![Didit 控制台中的审计日志，展示带时间戳和状态码的 API 活动](https://help.didit.me/screenshots/audit-logs-light.webp)

*组织内的每一次 API 请求，保留 365 天。*

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

| 字段 | 详情 |
|---|---|
| **Timestamp** | 请求发起的时间 |
| **User** | 操作人：发起请求的成员；对于 API 密钥发起的请求，显示该密钥的名称，并带有 **API 密钥**标签；Didit 自行执行的操作显示为 **Didit**；调查员自行作出的决定显示为**调查员** |
| **Method** | GET、POST、PUT、DELETE |
| **Path** | 被调用的接口路径 |
| **Status** | HTTP 响应状态码 |
| **IP address** | 请求的来源地址 |
| **Application** | 请求所属的应用 |

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

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

## 它真正的用途

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

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

## 筛选

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

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

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

由此带来的实际后果是：多个服务共用同一个密钥，会让事故排查明显更困难。如果归属关系对你很重要，请为每个服务配置独立的密钥。参见[管理你的 API 密钥](https://help.didit.me/zh/account-organization/api-keys)。

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

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

当某个人就调查员报告作出决定，即接受其建议或改判时，该条目归属于这个人，就像他所做的其他任何更改一样。调查员的完整记录，包括它的报告、问题和安全规则，仍保存在它自己的**活动**日志中。参见[控制和监督调查员](https://help.didit.me/zh/investigations/investigator-automation-and-oversight)。

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

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

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

## 谁能看到它

审计日志的访问权限取决于角色。**Compliance Officer** 包含该权限；**Reader** 不具备完整访问权限。Owner 可以将该权限授予自定义角色。参见[邀请团队成员并设置角色](https://help.didit.me/zh/account-organization/team-members-and-roles)。

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

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

生成一份会话 PDF 或导出一份 CSV 本身就是一次 API 调用，因此也会出现在这里，并记录是谁执行的。当你需要证明对核验证据的访问是受控的而非开放的时，这一点很有用。参见[下载核验报告](https://help.didit.me/zh/verification-sessions/download-verification-report)。

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

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

> **Note:** 审计日志的保留期与**核验数据**的保留期是两项独立的设置。
> 为会话数据配置较短的保留窗口，并不会缩短审计日志的保留期，反之亦然。参见
> [Didit 如何保护你的用户数据](https://help.didit.me/zh/data-privacy/how-didit-protects-data)。