Блог · 21 мая 2026 г.

Создание журнала аудита, соответствующего DORA, с помощью веб-хуков Didit (RU)

DORA требует от финансовых компаний подтверждения произошедших событий, их времени и участников по всем их ИКТ-системам. Вот как создать защищенный от подделок журнал аудита на основе веб-хуков верификации Didit — с подробным.

Автор: Didit21 мая 2026 г.Обновлено 21 мая 2026 г.

Закон о цифровой операционной устойчивости (DORA) задает финансовым организациям обманчиво сложный вопрос: можете ли вы доказать, что произошло? Когда надзорный орган расследует инцидент, когда аудитор проверяет ваши контроли или когда клиент оспаривает решение о регистрации, вам нужна запись — полная, с отметкой времени и защищенная от подделок — каждого события в ваших информационно-коммуникационных технологиях (ИКТ). Проверка личности является одной из таких систем, и она генерирует именно те события, которые вам необходимо фиксировать.

Этот пост является практическим: как превратить веб-хуки верификации и транзакций Didit в журнал аудита, соответствующий DORA, что хранить и как обеспечить его устойчивость к проверкам. В него включен рабочий пример веб-хука, который вы можете использовать уже сегодня.

Ключевые выводы

DORA требует доказательств — надежной записи событий ИКТ для реагирования на инциденты, тестирования устойчивости и надзорного контроля.
Didit отправляет события веб-хуков при каждом значимом изменении состояния: status.updated, data.updated, transaction.status.updated и business.status.updated.
Каждое событие — это дискретный, временной факт, который вы добавляете в неизменяемый журнал — строительный блок журнала аудита.
Проверяйте подпись каждого веб-хука, сохраняйте исходную полезную нагрузку и никогда не изменяйте записанную запись — правило «только добавление».
Собственные контроли Didit подтверждают надежность: SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (сертификат № ES144068) и iBeta Level 1 PAD — гарантия на уровне поставщика для вашего реестра ИКТ-сторонних поставщиков.
Результат удовлетворяет как записи что произошло, которую хочет DORA, так и доказательству кто это, которое лежит в основе контроля доступа.

Что требует стандарт

DORA строится на пяти столпах: управление ИКТ-рисками, отчетность об инцидентах, тестирование цифровой операционной устойчивости, обмен информацией и управление рисками ИКТ-сторонних поставщиков. Журнал аудита является связующим звеном между ними. В частности, финансовые организации должны:

Обнаруживать, регистрировать и сообщать об инцидентах, связанных с ИКТ — что предполагает достаточно детализированную запись для восстановления произошедшего.
Тестировать устойчивость, включая возможность отслеживать транзакции и события в системе.
Управлять рисками сторонних поставщиков, включая записи, поступающие от поставщика, такого как поставщик услуг по проверке личности.
Хранить записи в форме, которую надзорные органы могут запрашивать и на которую могут полагаться.

Из этого следуют неявные требования к пригодному для использования журналу аудита: события должны быть полными (без скрытых пробелов), точными (соответствующими тому, что произошло), упорядоченными по времени (с надежными временными метками), атрибутируемыми (связанными с субъектом и исполнителем) и защищенными от подделок (вы можете показать, что запись не была изменена после факта).

Почему это важно

Когда происходит инцидент — подозрение на захват учетной записи, оспариваемая верификация, помеченная транзакция — разница между локализованным событием и регуляторной проблемой часто заключается в качестве ваших записей. Полный журнал позволяет восстановить последовательность, доказать, что ваши контроли сработали как задумано, и продемонстрировать надзорному органу, что вы справились с ситуацией должным образом. Неполный журнал заставляет вас гадать и оставляет надзорный орган неубежденным.

События, связанные с идентификацией, здесь очень ценны, потому что они находятся на границе системы: момент, когда человек верифицируется, повторно верифицируется или его статус меняется, — это именно тот момент, который вы больше всего хотите зафиксировать. Захват этих событий по мере их возникновения — а не их последующее восстановление из журналов приложений — превращает «мы думаем, что это произошло» в «вот что произошло».

Как помогает Didit

Didit отправляет веб-хук для каждого перехода состояния в сеансе верификации, транзакции или бизнеса. Вы не опрашиваете; вы получаете подписанное событие в тот момент, когда что-то меняется.

Событие	Срабатывает, когда	Аудиторская ценность
`status.updated`	Статус сеанса верификации меняется (например, на `Approved`, `Declined`, `In Review`)	Записывает решение и его время
`data.updated`	Проверенные данные в сеансе меняются	Записывает, что было захвачено/изменено
`transaction.status.updated`	Статус отслеживаемой транзакции меняется	Записывает решения по мониторингу и разрешения аналитиков
`business.status.updated`	Статус бизнес-сущности KYB меняется (`ACTIVE`/`FLAGGED`/`BLOCKED`)	Записывает результаты регистрации бизнеса

Каждое событие является самодостаточным фактом. Ваша задача — проверить его, сохранить в исходном виде и никогда не изменять. Вместе эти события образуют журнал только для добавления всего, что Didit сделал от вашего имени — журнал аудита, который DORA требует для части ИКТ, связанной с проверкой личности.

И поскольку сам Didit аттестован — SOC 2 Type 1 (ATOM, по состоянию на 09.04.2026), ISO/IEC 27001:2022 (Bureau Veritas, сертификат № ES144068, действует до 03.06.2027) и iBeta Level 1 PAD — поставщик, стоящий за этими событиями, предоставляет свои собственные доказательства для вашего реестра сторонних поставщиков ИКТ DORA.

Подробный обзор: превращение веб-хука в аудиторскую запись

Вот веб-хук status.updated для сеанса верификации, который только что был разрешен как 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, сделайте четыре вещи при получении:

Проверьте подпись. Пересчитайте HMAC по необработанному телу запроса, используя секрет подписи вашей конечной точки, и сравните его с заголовком signature, прежде чем доверять полезной нагрузке. Отклоняйте все, что не прошло проверку — непроверенное событие не имеет доказательной ценности.
Сохраните необработанную полезную нагрузку дословно. Сохраните точные полученные байты вместе с вашей собственной временной меткой приема. Не нормализуйте и не изменяйте форму перед хранением; необработанное событие является доказательством.
Добавляйте, никогда не обновляйте. Записывайте в хранилище только для добавления (или в таблицу без прав UPDATE/DELETE для роли приложения). Если более позднее событие заменяет более раннее, запишите новую строку, ссылающуюся на старый session_id — никогда не перезаписывайте.
Сделайте его защищенным от подделок. Хэшируйте каждую запись и связывайте хэш со следующей (каждая строка хранит хэш предыдущей строки) или записывайте в хранилище однократной записи. Теперь вы можете доказать, что журнал не был изменен после факта.

Результатом является хронологический, атрибутируемый, защищенный от подделок журнал: для любого session_id вы можете воспроизвести каждое изменение состояния, увидеть, какие проверки прошли, и точно показать, когда было принято решение — и доказать, что запись с тех пор не была изменена. Это стандарт, который ищут надзорный орган или аудитор, и это тот же шаблон, который вы применили бы к transaction.status.updated для решений по мониторингу и business.status.updated для результатов KYB.

Сценарии использования

Банки и ЭМИ, создающие журнал событий ИКТ, соответствующий DORA, который включает решения по идентификации.
Крипто-VASP, которые должны подтверждать решения по регистрации и мониторингу транзакций надзорным органам.
Команды по соблюдению нормативных требований, готовящиеся к тестированию устойчивости, которое отслеживает события от начала до конца.
Инженерные команды, заменяющие хрупкий опрос подписанным приемом событий только для добавления.

Часто задаваемые вопросы

Какие события веб-хуков мне следует фиксировать для журнала аудита?

Как минимум status.updated и data.updated для верификаций; добавьте transaction.status.updated для мониторинга транзакций и business.status.updated для KYB. Фиксируйте каждое событие — полнота является ключевым моментом.

Нужно ли мне проверять подписи веб-хуков?

Да. Непроверенный веб-хук может быть подделан и не имеет доказательной силы. Пересчитайте подпись по необработанному телу и отклоните несоответствия перед записью в журнал.

Почему только добавление? Разве я не могу просто обновить запись при изменении статуса?

DORA ценит защищенность от подделок. Если вы перезаписываете записи, вы не можете доказать, что история не была изменена. Добавление нового события для каждого изменения сохраняет полную, доказуемую последовательность.

Удовлетворяет ли фиксация событий Didit всем требованиям DORA?

Нет — DORA является широким понятием. События Didit охватывают часть ИКТ, связанную с проверкой личности и мониторингом. Вы объедините их с журналами из остальных ваших систем для полного журнала.

Есть ли у Didit собственные аттестации для реестра сторонних поставщиков DORA?

Да — SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (сертификат № ES144068, действует до 03.06.2027) и iBeta Level 1 PAD, все доступно для поддержки вашей должной осмотрительности поставщика.

Готовы начать?

Ознакомьтесь с аттестациями Didit на центре доверия, прочтите подробности интеграции веб-хуков в документации и ознакомьтесь с прозрачными ценами на странице цен. Когда будете готовы, начните бесплатно — 500 бесплатных KYC-проверок каждый месяц, с базовым потоком верификации от 0,33 доллара США.