Если из CRM, личного кабинета или другого сервиса массово выгрузили данные, одного графика запросов недостаточно, чтобы установить утечку. Компьютерно-техническая экспертиза помогает выяснить, какие обращения поступали к API, под какой учётной записью, какие операции выполнила система и что сохранилось об их результате.
API — это интерфейс, через который программы обмениваются данными. Например, сайт передаёт заказ в CRM, мобильное приложение получает сведения о клиенте, а партнёрская система запрашивает каталог. Доступ к таким операциям часто предоставляют с помощью специального ключа или токена. При его компрометации обращения могут выглядеть как обычная работа разрешённой интеграции.
Когда стоит проверить обращения к API
Поводом для исследования могут стать неожиданный рост выгрузок, обращения после отключения сотрудника, операции с незнакомых адресов или появление закрытой информации у третьих лиц. Каждый из этих признаков требует проверки: массовые запросы также возникают при резервном копировании, повторной синхронизации и ошибках интеграции.
Полезно сразу сформулировать проверяемую версию: «В период с 3 по 5 сентября через интеграцию выгружались карточки клиентов, к которым у неё не должно было быть доступа». Такая постановка задаёт период, источник и предмет исследования.
Какие материалы сохранить
| Источник | Что искать | Для чего нужен |
|---|---|---|
| Шлюз API, прокси и веб-сервер | Время, маршрут, метод, код ответа, объём ответа, идентификатор запроса | Восстановить последовательность обращений |
| Журнал приложения | Пользователь, операция, объект, результат проверки доступа | Связать технический запрос с действием в сервисе |
| Система управления доступом | Создание, изменение прав и отзыв ключей, события входа | Проверить, какие разрешения действовали в нужный момент |
| Аудит базы данных | Доступные записи о чтении, изменении и экспорте | Уточнить объекты обработки, если аудит был включён |
| Настройки и версия программы | Правила доступа, ограничения выдачи, версия API, конфигурация журналирования | Объяснить поведение системы на дату события |
| Штатные интеграции | Расписания, задания, журналы обмена, заявки на выгрузку | Проверить альтернативное объяснение активности |
Сохраняйте исходные выгрузки вместе с параметрами отбора, временем получения и сведениями об источнике. Обработанную таблицу для анализа следует хранить отдельно. Если в сервисе есть ограниченный срок хранения журналов, запросите нужный период до его истечения.
Как действовать при продолжающемся инциденте
Сдерживание утечки и сохранение следов необходимо согласовать с ответственным за безопасность. Если доступ нужно срочно прекратить, зафиксируйте время блокировки и выполненные действия. Не откладывайте необходимый отзыв ключа ради полного сбора материалов.
До изменения настроек, если это возможно без задержки реагирования, сохраните сведения о правах интеграции и идентификаторе ключа. Сам действующий секрет не нужно вставлять в переписку или рабочую таблицу. Отдельно запишите, какие журналы доступны, кто их выгрузил и в какой временной зоне они ведутся.
В рекомендациях OWASP по журналированию подчёркивается значение журналов приложения, идентификаторов взаимодействия и согласованного времени. Там же рекомендовано исключать из обычных логов пароли, токены доступа и другие секреты. Включать запись всех тел запросов после инцидента без оценки содержимого опасно: журнал может стать ещё одним местом хранения конфиденциальных данных.
Как эксперт связывает события
Сначала исследователь проверяет полноту периода и настройки журналирования. Затем сопоставляет записи разных систем: вход, использование ключа, обращение к конкретному методу, проверку прав и результат операции. Если запрос проходит через несколько компонентов, полезен сквозной идентификатор — request ID.
Время приводят к единой шкале с учётом часовых поясов и возможного расхождения часов. Отдельно отмечают пробелы, перезапуски, смену версии и действия администраторов. Для полученных файлов рассчитывают контрольные суммы: они помогают проверить неизменность материалов после фиксации, но сами по себе не подтверждают достоверность исходных записей.
Почему успешный ответ ещё не доказывает утечку
Представим условную ситуацию: ключ партнёрской интеграции сделал несколько тысяч обращений к методу получения клиентов. В журнале шлюза у запросов указан код 200. Это подтверждает зарегистрированные успешные ответы на уровне протокола, но не устанавливает автоматически состав переданных сведений. Приложение могло вернуть пустой список, ограниченный набор полей или сообщение о результате обработки.
Для уточнения исследуют поведение соответствующей версии API, параметры запросов и доступные записи приложения. Объём ответа также требует интерпретации: на него влияют сжатие, формат и технические данные. Количество запросов нельзя без проверки приравнивать к количеству похищенных записей.
Можно ли установить, кто использовал ключ
Идентификатор ключа связывает операцию со средством доступа. Для вывода о конкретном человеке нужны дополнительные материалы: сведения о выдаче ключа, журналы входов, данные устройства, настройки интеграции и другие независимые следы. Общий ключ могли использовать несколько сотрудников или автоматических процессов.
IP-адрес тоже не равен личности: запрос мог пройти через корпоративный шлюз, облачный сервер или прокси. Эксперт должен описать установленную связь и её ограничения, а не подменять недостающие данные предположением.
Какие вопросы поставить перед экспертом
- Какие обращения к указанным методам API зарегистрированы в исследуемый период?
- С какими учётными записями и идентификаторами ключей они связаны?
- Какие права доступа действовали и имеются ли признаки их изменения?
- Можно ли определить состав и объём возвращённых данных по представленным материалам?
- Соответствует ли активность настройкам и расписанию штатной интеграции?
- Есть ли пробелы или противоречия в журналах, ограничивающие выводы?
Что подготовить для обращения
Опишите сервис, предполагаемый период события и сведения, доступ к которым вызывает вопросы. Приложите перечень имеющихся журналов, описание интеграций и хронологию уже выполненных действий. Передачу самих материалов с персональными данными и секретами согласуйте отдельно.
Компьютерно-техническая экспертиза и анализ цифровых данных позволяют проверить версии инцидента. Объём возможных выводов зависит от того, какие следы действительно сохранились.
Опишите ситуацию и доступные журналы, чтобы определить состав материалов для исследования.