使用 Didit Webhook 构建符合 DORA 要求的审计追踪 (ZH-1)

《数字运营韧性法案》（DORA）向金融实体提出了一个看似简单实则棘手的问题：你能证明发生了什么吗？当监管机构调查事件、审计师抽查控制措施或客户对入职决定提出异议时，您需要一份完整、带时间戳且防篡改的记录，记录您信息和通信技术 (ICT) 系统中的每一个事件。身份验证就是其中一个系统，它会生成您需要捕获的精确事件。

本文是实操指南：如何将 Didit 的验证和交易 Webhook 转换为符合 DORA 要求的审计追踪，存储什么，以及如何使其经受住审查。它包含一个您可以立即开始构建的 Webhook 示例。

主要收获

• DORA 期望证据 — 用于事件响应、韧性测试和监管审查的可靠 ICT 事件记录。
• Didit 在每个重要的状态变更时发出 Webhook 事件：status.updated、data.updated、transaction.status.updated 和 business.status.updated。
• 每个事件都是一个独立的、带时间戳的事实，您将其附加到不可变日志中 — 这是审计追踪的构建块。
• 验证每个 Webhook 的签名，存储原始负载，并且绝不修改已记录的记录 — 仅追加是规则。
• Didit 自身的控制措施支持该追踪：SOC 2 Type 1 (ATOM)、ISO/IEC 27001:2022 (证书编号 ES144068) 和 iBeta Level 1 PAD — 为您的 ICT 第三方注册提供供应商级别的保证。
• 结果既满足了 DORA 所要求的“发生了什么”的记录，也满足了支撑访问控制的“这是谁”的证明。

标准要求什么

DORA 基于五个支柱：ICT 风险管理、事件报告、数字运营韧性测试、信息共享和 ICT 第三方风险管理。审计追踪是它们之间的连接组织。具体来说，金融实体需要：

• 检测、记录和报告 ICT 相关事件 — 这预设了足够精细的记录，以便重构所发生的一切。
• 测试韧性，包括通过系统追踪交易和事件的能力。
• 管理第三方风险，包括来自身份验证供应商等提供商的记录。
• 保留记录，以便监管机构可以请求和依赖。

可用审计追踪的隐性要求由此而来：事件必须完整（无静默空白）、准确（忠实于所发生的一切）、按时间排序（具有可靠的时间戳）、可归因（与主体和执行者相关联）且防篡改（您可以证明记录事后未被更改）。

为什么这很重要

当事件发生时——例如可疑的账户盗用、有争议的验证或被标记的交易——事件的受控与否以及是否会引发监管问题，往往取决于您的记录质量。一份完整的追踪记录能让您重构事件序列，证明您的控制措施按设计运行，并向监管机构证明您已妥善处理。而一份残缺不全的记录则会让您摸不着头脑，也无法说服监管机构。

身份事件在这里具有高价值，因为它们处于系统的边界：个人被验证、重新验证或其状态发生变化的时刻，正是您最希望被记录的时刻。在事件发生时捕获它们——而不是稍后从应用程序日志中重建——正是将“我们认为发生了什么”转变为“这就是发生了什么”的关键。

Didit 如何提供帮助

Didit 会为验证、交易或业务会话中的每次状态转换发出一个 Webhook。您无需轮询；一旦发生变化，您就会收到一个已签名的事件。

事件	触发时机	审计价值
status.updated	验证会话状态发生变化时（例如变为 Approved、Declined、In Review）	记录决策及其时间
data.updated	会话上的已验证数据发生变化时	记录捕获/更改的内容
transaction.status.updated	受监控交易的状态发生变化时	记录监控决策和分析师解决方案
business.status.updated	KYB 业务实体状态发生变化时（ACTIVE/FLAGGED/BLOCKED）	记录业务入职结果

每个事件都是一个自包含的事实。您的任务是验证它、按原样存储它，并且永不更改它。这些事件共同构成了一个仅追加的分类账，记录了 Didit 代表您所做的一切——这是 DORA 为您的 ICT 资产中身份验证部分所要求的审计追踪。

而且由于 Didit 本身经过认证——SOC 2 Type 1 (ATOM，截至 2026 年 4 月 9 日)、ISO/IEC 27001:2022 (必维国际检验集团，证书编号 ES144068，有效期至 2027 年 6 月 3 日) 和 iBeta Level 1 PAD——这些事件背后的提供商为您的 DORA ICT 第三方注册提供了自身的证据。

深入探讨：将 Webhook 转换为审计记录

这是一个 status.updated Webhook，用于一个刚刚解析为 Approved 的验证会话：

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

要将其转换为符合 DORA 要求的审计记录，请在收到时执行四项操作：

1. 验证签名。使用您端点的签名密钥重新计算原始请求正文的 HMAC，并将其与 signature 标头进行比较，然后再信任负载。拒绝任何失败的事件——未经验证的事件没有证据价值。
2. 按原样存储原始负载。持久化您收到的确切字节，以及您自己的摄入时间戳。在存储之前不要进行规范化或重塑；原始事件就是证据。
3. 仅追加，永不更新。写入仅追加存储（或应用程序角色没有 UPDATE/DELETE 权限的表）。如果后续事件取代了先前的事件，则写入一个引用旧 session_id 的新行——绝不覆盖。
4. 使其防篡改。对每条记录进行哈希处理，并将哈希链接到下一条记录（每行存储前一行的哈希），或写入一次性存储。现在您可以证明日志事后未被更改。

结果是一个按时间顺序排列、可归因、防篡改的分类账：对于任何 session_id，您可以重播每次状态更改，查看通过了哪些检查，并准确显示何时做出决策——并证明记录此后未被触碰。这是监管机构或审计师正在寻找的标准，它与您将应用于 transaction.status.updated 以进行监控决策和 business.status.updated 以获取 KYB 结果的模式相同。

用例

• 银行和电子货币机构 (EMI) 正在构建包含身份决策的符合 DORA 的 ICT 事件日志。
• 加密资产服务提供商 (VASP) 必须向监管机构提供入职和交易监控决策的证据。
• 合规团队 正在为端到端追踪事件的韧性测试做准备。
• 工程团队 正在用已签名、仅追加的事件摄取取代脆弱的轮询。

常见问题

我应该捕获哪些 Webhook 事件用于审计追踪？

至少是用于验证的 status.updated 和 data.updated；为交易监控添加 transaction.status.updated，为 KYB 添加 business.status.updated。捕获每个事件——完整性是关键。

我需要验证 Webhook 签名吗？

是的。未经核实的 Webhook 可能是伪造的，并且没有证据效力。重新计算原始正文的签名，并在记录之前拒绝不匹配的项。

为什么只追加？我不能在状态更改时更新记录吗？

DORA 重视防篡改。如果您覆盖记录，则无法证明历史记录未被更改。为每个更改追加新事件可以保留完整、可证明的序列。

捕获 Didit 的事件是否满足 DORA 的所有要求？

不——DORA 的范围很广。Didit 的事件涵盖您 ICT 资产中的身份验证和监控部分。您需要将它们与您其他系统的日志结合起来，以获得完整的追踪记录。

Didit 是否拥有 DORA 第三方注册所需的自身认证？

是的——SOC 2 Type 1 (ATOM)、ISO/IEC 27001:2022 (证书编号 ES144068，有效期至 2027 年 6 月 3 日) 和 iBeta Level 1 PAD，所有这些都可用于支持您的供应商尽职调查。

准备好开始了吗？

请在信任中心查看 Didit 的认证，在文档中阅读 Webhook 集成详情，并在定价页面查看透明定价。准备就绪后，免费开始——每月 500 次免费 KYC 检查，核心验证流程起价为 0.33 美元。