«Регуляторные сценарии часто кажутся абстрактными, пока в почте не появляется письмо с требованием объяснить утечку, найденную в открытых источниках. Но самая большая ошибка — попытаться сразу доказывать свою невиновность. Первый шаг — зафиксировать доказательства того, что произошло снаружи, и только потом разбираться, имеет ли это отношение к вам».
Как выглядит инцидент
Не нужно представлять утечку как гигабайты данных. Чаще это несколько строчек в текстовом файле, опубликованном на площадке для обмена кодом. Или скриншот базы данных с адресами клиентов, выложенный в Telegram-канале. Иногда это просто упоминание в обсуждении на специализированном форуме о том, что «у компании X есть проблемы с API». Увидеть это может кто угодно: сотрудник службы безопасности, конкурент, обычный пользователь.
Регулятор получает сигнал из открытых источников и направляет запрос. В нём нет деталей, только обвинение: «По имеющейся информации, в ваш адрес произошла утечка персональных данных, подпадающая под действие 152-ФЗ. Просим предоставить разъяснения и доказательства принятых мер». Ответить нужно в короткий срок, обычно 10–30 дней. Паника — первый враг. Она заставляет удалять всё подряд, что только усугубляет ситуацию.
Первая реакция: не удалять, а фиксировать
Главное правило при обнаружении утечки в открытом доступе — немедленная фиксация обстоятельств. Удаление информации, это уничтожение улик, которое регулятор может расценить как попытку скрыть инцидент. Вместо этого нужно собрать полный пакет доказательств её существования и состояния.
Что нужно собрать сразу
- Скриншоты страниц, где размещены данные. Обязательно с URL, датой и временем в браузере.
- Сохранённые копии файлов. Например, сохранить файл .txt или .sql через «Сохранить как» с сохранением исходной структуры.
- Информацию о разместившем. Логин пользователя, который выложил данные, историю его сообщений, если это возможно. Всё это нужно для построения гипотезы о происхождении утечки.
- Лог действий. Записать время обнаружения, кто обнаружил, какие первые действия были предприняты.
Эти материалы не доказывают вашу невиновность, они доказывают сам факт существования инцидента. С них начинается любое расследование.
Три документа, которые разделяют ответственность
Смысл ответа регулятору не в том, чтобы сказать «это не мы», а в том, чтобы продемонстрировать системную работу по проверке каждого возможного вектора атаки. Ответ строится на трёх документах, которые последовательно закрывают основные гипотезы.
Документ 1: Акт внутреннего расследования
Это основной документ, который описывает, что именно вы делали после получения сигнала. Его структура должна быть чёткой и доказательной:
- Основание для расследования. Копия письма от регулятора или внутренний акт о начале проверки по факту обнаружения данных.
- Хронология событий. Временная шкала: когда и кем обнаружены данные, время фиксации доказательств, обращения к публичной площадке с просьбой удалить информацию (если это было), начало внутренней проверки.
- Анализ опубликованных данных. Здесь вы должны детально разобрать выложенные данные. Какие поля присутствуют? Формат данных (CSV, JSON, SQL-дамп)? Есть ли в них уникальные идентификаторы ваших систем (ID пользователей из вашей БД, внутренние номера закаков)? Совпадает ли структура полей с вашими внутренними таблицами?
- Проверка гипотез об источнике. Это ключевой раздел. Вы последовательно проверяете и опровергаете каждую возможность:
- Прямой взлом ваших систем. Результаты сканирования на уязвимости, анализ логов доступа к базам данных за последние 90–180 дней, отсутствие подозрительных активностей.
- Утечка через сотрудника. Аудит прав доступа к данным, анализ действий учётных записей с высокими привилегиями, отсутствие массовых выгрузок.
- Компрометация стороннего сервиса или подрядчика. Сверка данных с форматами, которые вы передаёте партнёрам.
- Промежуточный вывод. На основании анализа делается вывод, что в ваших системах следов компрометации, соответствующих опубликованным данным, не обнаружено.
Это не просто отписка. Каждый пункт должен быть подкреплён приложениями: выписками из логов (с замазанными чувствительными частями), отчётами сканеров, скриншотами из SIEM-системы.
Документ 2: Заключение по формату и семантике данных
Это технический документ, который часто упускают. Его цель — доказать, что выложенные данные не являются прямым слепком ваших систем. Если акт расследования отвечает на вопрос «не нашли ли мы взлом», то это заключение отвечает на вопрос «а наши ли это данные?».
Что здесь анализируется:
- Несоответствие формата. Ваши системы хранят даты в формате YYYY-MM-DD, а в утечке — DD.MM.YYYY. Ваши телефонные номера в формате +7XXX…, а в утечке — 8XXX… или без кода страны.
- Отсутствующие или лишние поля. В вашей базе есть обязательное поле «статус клиента», которого нет в слитых данных. Или наоборот, в утечке есть поле «реферальный код», которого никогда не было в вашей схеме.
- Семантические нестыковки. В данных указаны почтовые индексы, которые не существуют. Или комбинация региона и города невозможна (например, город Москва в Тульской области).
- Анализ уникальных идентификаторов. Если в данных есть ID, можно проверить, входят ли они в диапазоны, используемые в вашей системе. Часто в сгенерированных или скомпилированных наборах эти диапазоны не соответствуют реальным.
Этот документ переводит спор из плоскости «докажи, что тебя не взломали» в плоскость технической экспертизы, где аргументы гораздо весомее.
Документ 3: Справка об обращении к публичной площадке
Если данные были выложены на ресурс вроде GitHub или форума, важно показать, что вы действовали как добросовестный участник цифрового пространства. Этот документ подтверждает, что вы предприняли меры для устранения вреда, даже если данные, возможно, не ваши.
В справку входят:
- Копия отправленного запроса администрации ресурса на удаление данных (DMCA-жалоба или аналог) с указанием закона 152-ФЗ как основания.
- Подтверждение от площадки о принятии запроса к рассмотрению или об удалении материалов.
- Если ответа нет — скриншот отправленного обращения и статуса.
Это демонстрирует регулятору, что вы не игнорируете факт утечки в интернете, а активно работаете над её минимизацией, что является частью обязанностей оператора.
Сборка ответа и отправка
Три документа собираются в единый пакет ответа. К ним прикладываются первичные доказательства (скриншоты, сохранённые файлы). В сопроводительном письме кратко излагается суть: в связи с вашим запросом проведено внутреннее расследование, технический анализ данных и работа с площадкой размещения. Предварительные выводы указывают на то, что опубликованные данные не являются результатом компрометации наших систем, о чём свидетельствуют приложенные заключения.
Важно не писать категорично «утечка не наша». Лучше использовать формулировки: «в ходе проверки подтверждений компрометации наших информационных систем не обнаружено», «представленные данные имеют существенные различия с форматами хранения информации в нашей организации». Это оставляет пространство для диалога, если у регулятора появятся дополнительные вопросы, но при этом чётко обозначает вашу позицию, подкреплённую документами.
Что происходит после ответа
В большинстве случаев, если пакет документов составлен качественно и технически грамотно, регулятор закрывает запрос. Иногда могут прийти уточняющие вопросы по методике анализа или запрос на предоставление дополнительных выписок из логов. К этому нужно быть готовым — иметь под рукой более детальные отчёты.
Главный итог — вы избежали формального возбуждения дела об административном правонарушении по 152-ФЗ, которое грозит крупными штрафами и пристальным вниманием проверяющих. Вы показали, что контролируете ситуацию, имеете процедуры реагирования и способны проводить глубокий технический анализ. Это часто ценится выше, чем формальное отсутствие инцидентов.