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

​
Зачем нужны журналы аудита?

​
Доступ к журналам аудита

Откройте Settings > Organization > Audit log в Консоли Didit. Интерфейс отображает хронологический список всех запросов API, сделанных в вашей организации. Каждая запись журнала содержит:

​
Решения, принятые Расследователем

Каждое решение, которое Расследователь принимает самостоятельно, записывается под The Investigator, а не под участником или API-ключом. Сюда относятся одобрение или отклонение сессии, запрос на повторную отправку, установка статуса транзакции, а также закрытие кейса, его эскалация или запрос информации по нему. Запись ссылается на отчёт Расследователя, на основании которого было принято решение. Если человек принимает рекомендацию Расследователя или переопределяет её, запись фиксируется за этим человеком.

​
Фильтрация и поиск

Интерфейс журналов аудита предоставляет мощные возможности фильтрации, которые помогают найти именно то, что вам нужно.

​
Умный поиск

Строка поиска автоматически определяет, что вы ищете:

​
Доступные фильтры

​
Хранение данных

Ваш тариф определяет, насколько далеко назад вы можете читать журнал аудита и можно ли его экспортировать: Экспорт на тарифе, где он не предусмотрен, возвращает 403 с "code": "plan_limit_exceeded".

​
Безопасность и конфиденциальность

​
Что записывается

Журналы аудита фиксируют метаданные запросов API:
  • Метка времени запроса и его длительность
  • Личность пользователя (email, ID пользователя) или API-ключ, который выполнил запрос (его название и первые символы секрета, но никогда не полный секрет)
  • Путь запроса и параметры запроса
  • Коды статуса ответов
  • Адрес клиента и агент пользователя

​
Тела запросов и ответов вызовов с API-ключом

Для вызова, сделанного с помощью API-ключа, журнал аудита также хранит очищенную копию JSON-тела запроса для операции записи, а также ответ на операцию записи или на ошибку, чтобы вы могли понять, почему вызов не сработал. Ответ на успешную операцию чтения не сохраняется. Очистка построена по принципу «по умолчанию запрещено»:
  • Структура сохраняется: имена полей, вложенность, типы значений, длины массивов и длины строк.
  • Значение сохраняется только тогда, когда оно является собственным идентификатором, статусом, кодом, счётчиком или меткой времени Didit, в поле, которое определяет Didit, и в том формате, который ожидает это поле.
  • Логическое значение сохраняется только в поле, которое определяет Didit.
  • Любое другое значение заменяется маркером с указанием его типа и длины, например [redacted:string:12], [redacted:number:5] или [redacted:boolean], а null остаётся null.
  • Имя поля, которое не является простым идентификатором, например email или номер телефона, использованный как ключ, заменяется на [redacted:key:23].
  • Тело, которое не является JSON, например форма или загрузка файла, заменяется примечанием о том, что это было.
  • Итоговый результат обрезается до 4096 символов.
Параметры запроса проходят ту же очистку. Сохраняются только стандартные заголовки, такие как content-type, user-agent и заголовки лимитов запросов; все остальные заголовки удаляются вместе со своими значениями. Значение, которое передаёт ваша собственная система, например в metadata или vendor_data, никогда не сохраняется, даже если его поле назван так же, как одно из полей Didit.

​
Что НЕ записывается

Для защиты конфиденциальных данных автоматически исключаются:
  • Токены аутентификации и учётные данные
  • Пароли и секреты
  • Персональные данные из сессий верификации

​
Контроль доступа

Для просмотра журнала аудита нужны разрешения audit-logs на чтение и просмотр списка. Роли Reader, Compliance Officer, Developer, Admin и Owner имеют оба разрешения, а пользовательская роль получает их, если выбрать Audit logs в редакторе ролей.

​
Типичные сценарии использования

Покажите аудиторам, что у вас есть полный обзор того, кто получал доступ к данным верификации:
  1. Отфильтруйте записи по диапазону дат, соответствующему проверяемому периоду
  2. При необходимости отфильтруйте записи по конкретным приложениям или пользователям
  3. Экспортируйте результаты или сделайте снимок экрана с ними для документации
Если вы подозреваете несанкционированный доступ:
  1. Найдите адрес электронной почты затронутого пользователя или подозрительные адреса IP
  2. Отфильтруйте записи по диапазону дат, в который, по вашим предположениям, произошел инцидент
  3. Обратите внимание на необычные признаки: неудачные попытки аутентификации, неожиданные endpoint’ы, нетипичное время активности
При устранении неполадок в интеграции API:
  1. Найдите путь конкретного endpoint’а
  2. Отфильтруйте записи по кодам статуса 4xx или 5xx, чтобы найти ошибки
  3. Запишите временные метки, чтобы сопоставить их с логами вашего приложения
Отслеживайте, как ваша команда использует платформу:
  1. Отфильтруйте записи по адресам электронной почты конкретных участников команды
  2. Проверьте, к каким сессиям и функциям они обращались
  3. Убедитесь, что участники команды следуют принятым процедурам

​
Рекомендации

  1. Регулярные проверки. Периодически просматривайте журналы аудита, чтобы своевременно выявлять аномалии.
  2. Сужайте поиск. Используйте конкретные фильтры, чтобы сократить количество лишних записей и быстрее находить нужные.
  3. Диапазоны дат. Всегда указывайте диапазон дат, чтобы поиск по большим объемам данных работал быстрее.
  4. Закладки для поиска. Сохраняйте часто используемые комбинации фильтров как закладки браузера для быстрого доступа.
Последнее изменение 7 ноября 2026 г.