Как найти утечку персональных данных через формы и журналы сайта

Утечка через сайт не всегда выглядит как взлом базы. Телефон может попасть в адресную строку после отправки формы, email — в журнал веб-сервера, а комментарий клиента — в систему мониторинга ошибок или сторонний счётчик. Поэтому проверять нужно не только таблицу с заявками, но весь маршрут данных: браузер, сервер, приложение, аналитические скрипты, интеграции, резервные копии и интерфейсы сотрудников.

Задача расследования — установить, какие данные вышли за предусмотренный контур, каким путём, за какой период и кто мог получить к ним доступ. Ниже — практический порядок, который помогает отделить подтверждённый факт от предположения и после исправления доказать, что канал закрыт.

Где формы чаще всего оставляют персональные данные

URL и история браузера

Если форма отправляется методом GET, значения полей добавляются к URL. Такой адрес может сохраниться в истории, закладке, журнале прокси, отчёте аналитики и заголовке Referer при переходе на другой ресурс. Сам по себе переход на POST не решает всю задачу, но данные из формы не должны находиться в query-параметрах. Особенно опасны параметры вроде phone, email, name, token и текст обращения.

Журналы веб-сервера и приложения

Стандартный access-log обычно фиксирует путь запроса, код ответа, источник перехода и user agent. Приложение дополнительно может записывать тело запроса, параметры, идентификатор пользователя и диагностический контекст. Режим отладки, включённый в рабочей среде, нередко делает запись избыточной. Отдельно проверьте error-log: исключение может сохранить весь объект запроса вместе с заполненной формой.

Мониторинг, аналитика и внешние запросы

Системы аналитики, записи сессий, менеджеры тегов, онлайн-чаты, антиспам, коллтрекинг и мониторинг ошибок получают данные через браузер или сервер. Нужно смотреть фактические сетевые запросы, а не только перечень сервисов в документах. Неверно настроенная цель, пользовательский параметр или JavaScript-событие может отправлять введённое значение ещё до нажатия кнопки.

CRM, почта, вебхуки и копии

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

Что сделать сразу после обнаружения

1. Зафиксировать наблюдение. Сохраните время, URL, снимок экрана, идентификатор тестовой заявки, фрагмент журнала и версию приложения. Не пересылайте реальные данные в общий чат.
2. Ограничить канал. Отключите проблемную форму или конкретную интеграцию, закройте публичный доступ к журналам, сузьте права и при необходимости замените раскрытые ключи или токены.
3. Сохранить доказательства. Не очищайте все журналы до определения масштаба. Сделайте контролируемую копию нужного фрагмента, ограничьте доступ и зафиксируйте, кто её получил.
4. Назначить владельца инцидента. Техническая команда устанавливает маршрут, а ответственный за обработку персональных данных оценивает правовые последствия и уведомления.

Статья 21 закона № 152-ФЗ предусматривает уведомление Роскомнадзора при инциденте, связанном с неправомерной или случайной передачей либо доступом, которые повлекли нарушение прав субъектов: первичное уведомление — в течение 24 часов с момента выявления, результаты внутреннего расследования — в течение 72 часов. Применимость нормы определяют по фактам конкретного случая; техническая находка сама по себе не заменяет такую оценку.

Практика: пройти путь контрольной заявки

1. Составьте карту точек сбора

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

2. Используйте синтетические маркеры

Не проверяйте утечку реальными данными клиента. Создайте уникальные тестовые значения, по которым легко искать след: например, адрес в разрешённом тестовом домене и строку CASE-192-20260814. До запуска убедитесь, что уведомления не уйдут реальному сотруднику или внешнему подрядчику без необходимости.

3. Снимите сетевой маршрут

Откройте инструменты разработчика браузера, очистите журнал Network и отправьте форму один раз. Сохраните HAR в защищённом рабочем каталоге. Проверьте URL, метод, тело запроса, редиректы, заголовки, ответы и все запросы к сторонним доменам. HAR также может содержать чувствительные значения, поэтому его нельзя публиковать или прикладывать к открытой задаче.

4. Найдите маркер на всех слоях

Ищите точное тестовое значение в access- и error-логах, логах приложения, APM, очередях, CRM, почтовом шлюзе, вебхуках, аналитике и хранилищах резервных копий. Сведите результат в таблицу «поле → запрос → место хранения → получатель → срок → основание → доступ». Отсутствие маркера в одном журнале не доказывает отсутствие передачи на следующем участке.

5. Определите масштаб

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

Как закрыть канал утечки

Исправление должно действовать системно, а не только для одного URL. Переведите передачу формы в тело POST-запроса по HTTPS, исключите персональные значения из адресов и редиректов. В слое журналирования используйте разрешающий список безопасных полей: метод, шаблон маршрута, код ответа, длительность и технический correlation ID. Пароли, токены, cookie, идентификаторы сессий, платёжные реквизиты и полные контактные данные в журналы не записывают. Если идентификатор нужен для диагностики, применяют согласованное маскирование или псевдонимизацию.

Настройте единое правило очистки для приложения, веб-сервера, прокси и мониторинга ошибок. Ограничьте доступ к журналам по ролям, задайте срок хранения, защитите передачу и целостность, включите учёт обращений. Для браузера проверьте политику Referrer-Policy и исключите персональные параметры из адресной строки. Уберите лишние поля формы и передачи, которые не нужны заявленной цели.

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

Как подтвердить результат

• повторите отправку с новым уникальным маркером в каждом типе формы;
• убедитесь, что значение не появляется в URL, истории, Referer и внешних сетевых запросах;
• проверьте все журналы и мониторинг: остаются только разрешённые технические поля;
• подтвердите, что заявка попала только в согласованные системы и доступна только нужным ролям;
• проверьте срок хранения и удаление на тестовой записи;
• сохраните протокол «до/после», HAR, выдержки конфигурации и результаты поиска маркера без раскрытия чужих данных.

Критерий завершения — не отсутствие ошибки на экране, а воспроизводимый контрольный тест по всей цепочке. Для независимой проверки маршрутов можно использовать услугу поиска персональных данных в Метрике, URL и логах.

Источники

1. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
2. Статья 21 № 152-ФЗ: действия оператора при выявлении неправомерной обработки.
3. Статья 19 № 152-ФЗ: меры по обеспечению безопасности персональных данных.
4. OWASP Logging Cheat Sheet.
5. MDN: Sending form data.
6. MDN: Referrer-Policy.
7. NGINX: ngx_http_log_module.