# Использование журналов аудита

Source: https://help.didit.me/ru/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/ru/account-organization/api-keys).

## Собственные решения Расследователя приписываются Расследователю

Когда Расследователь решает сам, в пределах автономности, которую вы ему дали, в записи указан **Расследователь**, а не человек и не ключ. Это касается каждого решения, которое он принимает: одобрить или отклонить сессию либо попросить пользователя отправить её повторно, задать статус транзакции, а также закрыть дело, передать его на следующий уровень или запросить по нему информацию. Каждая такая запись ведёт на отчёт Расследователя, на котором основано решение, чтобы вы видели, что он обнаружил и какое правило вашей политики применил.

Когда решение по отчёту Расследователя принимает человек, соглашаясь с его рекомендацией или изменяя её, запись приписывается этому человеку, как и любое другое его изменение. Полный след Расследователя, с его отчётами, вопросами и защитными правилами, остаётся в его собственном журнале **Активность**. См. [Контроль и надзор за Расследователем](https://help.didit.me/ru/investigations/investigator-automation-and-oversight).

## Что есть в логе, а чего нет

Лог фиксирует **активность** - кто что вызвал, когда, откуда и какой статус вернулся. Это след метаданных, а не копия данных верификации.

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

## Кто это видит

Доступ к журналам аудита определяется ролью. **Compliance Officer** включает его; у **Reader** нет широкого доступа. Владельцы могут предоставить его кастомной роли. См. [приглашение участников команды и назначение ролей](https://help.didit.me/ru/account-organization/team-members-and-roles).

Удаление коллеги из команды не удаляет его историю из лога - в этом и смысл. След, который можно редактировать, - не след.

## Экспорты и отчеты тоже логируются

Формирование PDF по сессии или CSV-экспорта - это вызов API, поэтому он тоже попадает сюда вместе с тем, кто его сделал. Это полезно, когда нужно показать, что доступ к доказательствам верификации контролируется, а не открыт. См. [скачивание отчета о верификации](https://help.didit.me/ru/verification-sessions/download-verification-report).

## Если вам нужно больше 365 дней

Срок хранения фиксирован на уровне 365 дней. Если ваше обязательство требует большего срока, экспортируйте нужные данные по расписанию и храните их в своей системе - тот же принцип, что и при самостоятельном хранении доказательств по сессии. Определение необходимого срока - решение по комплаенсу для вашей команды; не стройте процесс на предположении.

> **Note:** Срок хранения журналов аудита и срок хранения **данных верификации** - это
> отдельные настройки. Настройка короткого окна хранения для данных сессии не
> сокращает журнал аудита, и наоборот. См.
> [как Didit защищает данные ваших пользователей](https://help.didit.me/ru/data-privacy/how-didit-protects-data).