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

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

Автор: поддержка Didit · Обновлено 19 августа 2026 г.

#Что фиксируется

1234

1. Отфильтруйте по участнику, пути, методу или дате, чтобы ответить на вопрос «кто это изменил».
2. Method и статус позволяют отличить чтение от изменения, которое действительно применилось.
3. Участник, выполнивший вызов.
4. Откуда пришел запрос - деталь, которая превращает лог в доказательство.

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

Логи хранятся 365 дней, а затем удаляются автоматически.

#Для чего это на самом деле нужно

Четыре ситуации, где это подходящий инструмент:

• «Кто изменил этот рабочий процесс?» Если флоу ведет себя иначе, чем вчера, обычно за этим стоит чья-то правка, и лог покажет, кто ее внес.
• Расследование инцидента. Точное отслеживание того, к чему был доступ, кем, с какого адреса и в каком порядке.
• Отладка интеграции. Просмотр запросов, которые ваш код реально сделал, а не тех, которые вы полагаете, что он сделал - включая те, что вернули 4xx.
• Подтверждение контроля доступа. Демонстрация аудитору, что доступ к данным верификации атрибутирован и проверяем.

#Фильтрация

Фильтруйте по пользователю, эндпоинту или диапазону дат, чтобы сузить длинный список. Когда вы расследуете что-то конкретное, начните с временной метки и двигайтесь наружу - запрос редко случается в одиночку, и вызовы непосредственно вокруг него обычно рассказывают всю историю.

#Запросы по API-ключу привязываются к приложению, а не к человеку

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

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

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

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

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

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

Доступ к журналам аудита определяется ролью. Compliance Officer включает его; у Reader нет широкого доступа. Владельцы могут предоставить его кастомной роли. См. приглашение участников команды и назначение ролей.

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

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

Формирование PDF по сессии или CSV-экспорта - это вызов API, поэтому он тоже попадает сюда вместе с тем, кто его сделал. Это полезно, когда нужно показать, что доступ к доказательствам верификации контролируется, а не открыт. См. скачивание отчета о верификации.

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

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