Каждый API-запрос организации фиксируется 365 дней: кто, что, когда, откуда и в каком приложении. Это первое место, где искать причину неожиданного изменения.
Каждый 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-ключами.
#Собственные решения Расследователя приписываются Расследователю
Когда Расследователь решает сам, в пределах автономности, которую вы ему дали, в записи указан Расследователь, а не человек и не ключ. Это касается каждого решения, которое он принимает: одобрить или отклонить сессию либо попросить пользователя отправить её повторно, задать статус транзакции, а также закрыть дело, передать его на следующий уровень или запросить по нему информацию. Каждая такая запись ведёт на отчёт Расследователя, на котором основано решение, чтобы вы видели, что он обнаружил и какое правило вашей политики применил.
Когда решение по отчёту Расследователя принимает человек, соглашаясь с его рекомендацией или изменяя её, запись приписывается этому человеку, как и любое другое его изменение. Полный след Расследователя, с его отчётами, вопросами и защитными правилами, остаётся в его собственном журнале Активность. См. Контроль и надзор за Расследователем.
#Что есть в логе, а чего нет
Лог фиксирует активность - кто что вызвал, когда, откуда и какой статус вернулся. Это след метаданных, а не копия данных верификации.
Если вам нужно знать, встречаются ли в этих записях персональные данные клиентов - вопрос, который часто возникает при проверках защиты данных, - получите ответ у вашего контакта в Didit и зафиксируйте его, а не делайте вывод по странице помощи. Это именно тот вид утверждения, который ваша собственная DPIA должна будет подтвердить.
#Кто это видит
Доступ к журналам аудита определяется ролью. Compliance Officer включает его; у Reader нет широкого доступа. Владельцы могут предоставить его кастомной роли. См. приглашение участников команды и назначение ролей.
Удаление коллеги из команды не удаляет его историю из лога - в этом и смысл. След, который можно редактировать, - не след.
#Экспорты и отчеты тоже логируются
Формирование PDF по сессии или CSV-экспорта - это вызов API, поэтому он тоже попадает сюда вместе с тем, кто его сделал. Это полезно, когда нужно показать, что доступ к доказательствам верификации контролируется, а не открыт. См. скачивание отчета о верификации.
#Если вам нужно больше 365 дней
Срок хранения фиксирован на уровне 365 дней. Если ваше обязательство требует большего срока, экспортируйте нужные данные по расписанию и храните их в своей системе - тот же принцип, что и при самостоятельном хранении доказательств по сессии. Определение необходимого срока - решение по комплаенсу для вашей команды; не стройте процесс на предположении.
Срок хранения журналов аудита и срок хранения данных верификации - это отдельные настройки. Настройка короткого окна хранения для данных сессии не сокращает журнал аудита, и наоборот. См. как Didit защищает данные ваших пользователей.
Не нашли ответ? Поговорите с человеком.
Укажите ID организации и ID сессии, о которой спрашиваете.