Что делать в первые 24 часа, если утекла база клиентов

У вас есть 24 часа, чтобы уведомить Роскомнадзор, и отсчет может начаться раньше, чем вы узнали об утечке. На примере «Додо Пиццы» собрал порядок первых суток: что закрыть и сохранить на сайте, что написать регулятору и клиентам, какие штрафы грозят и чем нельзя ухудшать ситуацию.

28 сентября «Додо Пицца» написала клиентам в своем Telegram-канале, что пережила кибератаку и что злоумышленники могли получить имена, адреса, email, телефоны, даты рождения и составы заказов части клиентов. В том же сообщении: доступ атакующим заблокирован, Роскомнадзор уведомлен, проверка идет, платежные данные компания не хранит, а некоторых пользователей может принудительно разлогинить из аккаунтов.

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

Короткий ответ. За первые 24 часа нужно: закрыть канал утечки и сменить все доступы, сохранить логи и копии для расследования, понять, какие данные и сколько записей могли уйти, уведомить Роскомнадзор и предупредить клиентов о мошенниках. В течение 72 часов в Роскомнадзор уходят результаты внутреннего расследования. Отсчет идет не с момента, когда вы решили, что утечка была, а с момента, когда ее выявили вы, регулятор или кто-то третий. Вторая половина статьи о том, как не оказаться в этой ситуации снова: какие меры реально перекрывают путь к базе, а какие только выглядят защитой.

Что требует закон: 24 и 72 часа

Обязанность уведомлять об утечке установлена частью 3.1 статьи 21 закона № 152-ФЗ «О персональных данных». Если персональные данные неправомерно или случайно переданы, распространены или к ним получен доступ, и это нарушило права людей, оператор уведомляет Роскомнадзор в 2 этапа.

Уведомление подается через форму на Портале персональных данных, порядок взаимодействия с ведомством описан в приказе Роскомнадзора от 14.11.2022 № 187. Первое уведомление по определению будет неполным: за сутки никто не знает точного объема и причины. Закон это учитывает, поэтому и говорит о «предполагаемых» причинах и вреде. Ждать полной картины, чтобы «не писать ерунду», нельзя.

Главная ловушка в формулировке закона — момент начала отсчета. 24 часа считаются с момента выявления инцидента оператором, Роскомнадзором или иным заинтересованным лицом. Если вашу базу выложили в Telegram-канале, а вы узнали об этом через 2 дня от журналиста, часы могли пойти раньше, чем вы о них узнали. Поэтому уведомлять нужно сразу, как только появились признаки утечки, а уточнять — во втором уведомлении.

Кроме Роскомнадзора, есть порядок информирования ФСБ через ГосСОПКА о компьютерных инцидентах с персональными данными. Его устанавливает приказ ФСБ России от 13.02.2023 № 77. Как именно ваша компания выполняет эту обязанность, стоит выяснить у юриста заранее, а не в день инцидента.

Какие штрафы грозят

Штрафы за утечки с 30 мая 2025 года установлены статьей 13.11 КоАП и зависят от числа людей, чьи данные утекли. Для юридических лиц:

• Неуведомление об инциденте. От 1 до 3 млн руб. (часть 11).
• Утечка данных от 1 до 10 тыс. человек. От 3 до 5 млн руб. (часть 12).
• От 10 до 100 тыс. человек. От 5 до 10 млн руб. (часть 13).
• Больше 100 тыс. человек. От 10 до 15 млн руб. (часть 14).
• Повторная утечка. Оборотный штраф от 1 до 3% годовой выручки, но не меньше 20 млн и не больше 500 млн руб. (часть 15).

Отдельные, более высокие суммы установлены за утечку специальных категорий данных (часть 16) и биометрии (часть 17). Для обычного интернет-магазина это редкий случай, но если вы собираете сведения о здоровье или сканы лиц, читайте эти части отдельно.

Из этого списка видно, почему неуведомление — худшее решение. Штраф за утечку компания может получить в любом случае, а молчание добавляет к нему отдельный состав, размер которого не зависит от числа записей, и выглядит как попытка скрыть инцидент. Я считаю, что быстрое и честное уведомление — единственная стратегия, которая в этой ситуации работает на бизнес.

Первые часы: что сделать на сайте и в системах

Техническая часть идет параллельно с юридической. Если сайт, CRM или база ведутся подрядчиком, звоните ему сразу (звонок быстрее письма) и назначьте одного человека, который собирает информацию и принимает решения.

1. Закрыть канал. Отключить скомпрометированные учетные записи, заблокировать подозрительные IP, закрыть открытый наружу раздел или выгрузку, если она нашлась. Не удалять, а именно закрывать: удаленный файл или пользователь — это потерянная улика.
2. Сменить все доступы. Пароли администраторов сайта, хостинга, базы данных, почты, FTP и SSH. Ключи API: обмен с 1С, платежный шлюз, SMS-сервис, CRM. Если ключ лежал в коде или в конфиге, считайте его скомпрометированным.
3. Сбросить сессии. Именно это сделала «Додо Пицца», когда предупредила о принудительном выходе из аккаунтов. Если у злоумышленника остался токен авторизации, смена пароля его не остановит.
4. Сохранить следы. Скопировать логи веб-сервера, логи базы, журнал событий админки и снимок сервера до того, как их перезапишет ротация. Переустановка сервера «с нуля» в первый же час уничтожает все, что понадобится для отчета за 72 часа.
5. Оценить объем. Какие таблицы и поля были доступны, сколько в них записей, есть ли среди данных паспортные, медицинские или платежные сведения. От числа людей зависит и часть статьи КоАП.

На сайте на 1С-Битрикс принудительный выход можно сделать, очистив таблицу сохраненных авторизаций «Запомнить меня», а список администраторов проверить одним запросом. Перед любыми изменениями снимите копию таблиц:

-- кто состоит в группе администраторов (ID группы 1) и когда появился
SELECT u.ID, u.LOGIN, u.EMAIL, u.DATE_REGISTER, u.LAST_LOGIN
FROM b_user u
JOIN b_user_group g ON g.USER_ID = u.ID
WHERE g.GROUP_ID = 1
ORDER BY u.DATE_REGISTER DESC;

-- сброс сохраненных авторизаций: все пользователи войдут заново
CREATE TABLE b_user_stored_auth_bak AS SELECT * FROM b_user_stored_auth;
DELETE FROM b_user_stored_auth;

Администратор, которого никто не помнит, с датой регистрации за последние недели — первый кандидат на канал утечки. Второй источник фактов — логи веб-сервера: массовые выгрузки видны по объему ответов. В стандартном формате логов nginx объем ответа стоит в 10-м поле:

# сохранить логи до ротации
mkdir -p /root/incident-2026-09 && cp /var/log/nginx/access.log* /root/incident-2026-09/

# запросы, отдавшие больше 5 МБ, по IP и адресу
awk '$10 > 5000000 {print $1, $7, $10}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Пути к логам на вашем хостинге могут отличаться, и это не полный анализ: утечка через украденный пароль администратора в логах выглядит как обычная работа. Но за 10 минут такой поиск часто показывает, была ли массовая выгрузка через сайт и с каких адресов.

Отдельно о бэкапах. Восстановить сайт из резервной копии — нормальный шаг, если сайт поврежден. Но копия, снятая после проникновения, может содержать ту же закладку, а копия, снятая до него, не закрывает уязвимость, через которую зашли. Сначала найдите причину, потом восстанавливайте.

Что сказать клиентам

Закон о персональных данных не требует рассылать уведомление каждому клиенту. Но после утечки клиентам почти сразу начинают звонить и писать мошенники от имени пострадавшей компании: у них есть имя, телефон и история заказов, поэтому сообщение выглядит достоверно. Этот риск после инцидента с «Додо Пиццей» отдельно отмечал «Коммерсантъ». Короткое честное сообщение от вас снижает и ущерб людям, и ущерб репутации.

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

72 часа: что должно быть в итогах расследования

Второе уведомление в Роскомнадзор — это не формальность. По нему регулятор оценивает, понимает ли компания, что произошло. К концу третьих суток должны быть ответы на 4 вопроса: через что именно ушли данные, какие данные и сколько записей затронуто, почему это стало возможным и что сделано, чтобы не повторилось.

Если ответа на какой-то вопрос пока нет, так и пишите, с планом, когда он появится. Внутреннее расследование не обязано быть идеальным за 72 часа. Оно обязано быть честным и опираться на факты: логи, журналы доступа, результаты проверки кода и серверов.

Хорошая практика — вести с первой минуты хронологию в одном документе: время, что обнаружили, кто что сделал. Через 3 дня по памяти ее уже не восстановить, а для отчета она нужна почти целиком.

Что делает ситуацию хуже

Ошибки после утечки повторяются, и почти все они совершаются из лучших побуждений.

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

Ждать, пока «все выяснится». Сутки проходят быстро. Уведомление, поданное на 3-й день с идеально точными цифрами, все равно подано с нарушением срока.

Сменить пароль одному пользователю. Если зашли через учетную запись одного сотрудника, это не значит, что злоумышленник не создал себе другие. Меняются все доступы, проверяется список администраторов, сбрасываются сессии.

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

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

Что реально защищает базу, а что только выглядит защитой

После инцидента первый вопрос обычно звучит как «усилить защиту сайта». Защита у большинства сайтов уже есть: сертификат стоит, хостинг сканирует файлы, пароли сложные. И тем не менее, по оценке F6, которую приводят «Ведомости», за полтора года в открытом доступе оказались 326 баз российских компаний, около 1,175 млрд строк. Привычные меры закрывают взлом сайта, а база уходит другими путями.

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

Ниже меры, которые чаще всего называют в ответ на вопрос «что у вас защищает сайт». Третья колонка отвечает на единственный вопрос, который имеет значение после утечки.

Половина привычного набора к утечке базы отношения не имеет. Отказываться от этих мер не нужно, SSL и защита от перегрузки решают свои задачи. Но если весь ответ на вопрос о защите данных состоит из сертификата и антивируса хостера, защиты данных у вас нет.

5 путей, по которым база уходит с обычного сайта

Забытый доступ. Бывший сотрудник, подрядчик, который делал сайт 3 года назад, стажер с правами администратора «на пару дней». У каждого рабочая учетная запись и штатная кнопка «Экспорт в Excel», взлом не нужен. Это самый частый путь и самый дешевый в устранении. Его разновидность: общая учетная запись на всех, по которой невозможно понять, кто именно выгрузил базу.

Открытая копия сайта или бэкап. Тестовая версия на поддомене без пароля, дамп базы в корне сайта, архив старой версии, который забыли удалить. Имена у таких файлов предсказуемые: dump.sql, backup.zip, site_old, и сканеры находят их за часы.

Уязвимость в стороннем модуле. Ядро CMS обновляют почти все, модули из маркетплейса почти никто. Инъекция в 1 платном модуле отдает содержимое таблицы целиком, а сайт продолжает работать как обычно.

Интеграция без ограничений. Вебхук или ключ API, выданный «чтобы работало», с полными правами и без ограничения по адресам. Такой ключ живет в коде фронтенда, в мобильном приложении, в репозитории или в чате с подрядчиком. Если данные хранятся в CRM, это касается и вас: утечка через ключ интеграции — рабочий сценарий, при котором сам сайт чист.

Данные за пределами сайта. Выгрузка заказов на личном ноутбуке, почтовый ящик, куда падают все заявки с формы, переписка с клиентом в мессенджере. Формально сайт защищен, а копия базы лежит в 4 местах, и все они вне вашего контроля.

Проверка за вечер и что повторять по расписанию

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

Пункт 1. Кто имеет доступ. Откройте список пользователей админки и посмотрите дату последнего входа. Всех, кто не заходил дольше 3 месяцев, отключайте. Для Битрикса подойдет запрос из раздела про первые часы. В проектах, которые приходят к нам на поддержку, такими оказываются от трети до половины администраторов, и у части из них полные права. Отключение занимает 10 минут и закрывает самый ходовой путь утечки.

Пункт 2. Что лежит в корне сайта. Проверьте, отдаются ли наружу типовые имена архивов и дампов. Нужен только 404. Ответ 200 или 403 с размером файла означает, что идти на сервер нужно сейчас.

for f in dump.sql backup.zip db.sql.gz site.tar.gz .env .git/config \
         bitrix/backup/ old/ test/ phpmyadmin/; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.ru/$f")
  echo "$code  $f"
done

Пункт 3. Тестовые копии. Вспомните все поддомены: dev, test, new, old, копия у подрядчика. На каждой обычно живет полная база клиентов и почти никогда нет пароля на вход. Проверьте, закрыты ли они хотя бы базовой авторизацией и закрыты ли от индексации.

Пункт 4. Вторая проверка при входе. Есть ли двухфакторная аутентификация у администраторов. Если нет, включите сегодня: из всех мер в этой статье у нее лучшее соотношение усилий и результата.

Пункт 5. Ключи и вебхуки. Соберите список всех выданных ключей API и вебхуков: кому, когда, с какими правами. Те, чье назначение никто не помнит, отзываются. Ключ, который умеет читать всю базу, должен уметь ровно то, что нужно конкретной интеграции.

Пункт 6. Где еще лежат те же данные. Выпишите все копии клиентской базы за пределами сайта: выгрузки в таблицах, почтовый ящик с заявками, экспорт для рассылки, файл у бухгалтера. Большинство компаний на этом пункте находит 3–5 копий, о которых не помнили.

Что сделать разово, а что повторять по расписанию

Половина мер выше — разовая работа на несколько часов, и ее результат не портится. Вторая половина без расписания устаревает за квартал.

Разовую колонку реально закрыть за 1 рабочий день, и начинать стоит с нее: она дает основной эффект. Регулярная часть подключается потом, когда понятно, кто за нее отвечает.

Как заметить следующую утечку раньше клиентов

Прямых признаков мало: выгрузка базы не ломает сайт и не оставляет следов на страницах. Смотреть стоит на 5 вещей.

• Клиенты жалуются на спам и звонки. Несколько обращений подряд от людей, которые покупали у вас недавно, надежнее любого сканера.
• Всплеск исходящего трафика ночью. Видно в статистике хостинга: база на 50 тыс. записей весит десятки мегабайт и уходит одним куском.
• Странные записи в журнале входов. Успешный вход администратора в 4 утра или из региона, где у вас никого нет.
• Нетипичные запросы к экспорту. Десятки обращений к странице выгрузки заказов за минуту в логах веб-сервера.
• Ваши данные всплыли в чужом объявлении. О публикации базы компании нередко узнают от клиентов или из СМИ последними.

Если сработал хотя бы 1 признак, часы из первого раздела уже пошли.

Что подготовить до утечки

Утечка базы клиентов — не тот момент, когда стоит впервые искать пароль от хостинга и выяснять, кто разрабатывал сайт. Подготовиться можно за 1 рабочий день: составить список мест, где лежат персональные данные, назначить ответственного за общение с Роскомнадзором, записать контакты подрядчика и хостинга, проверить, что логи хранятся хотя бы 30 дней, и написать черновик уведомления клиентам. Проверку самого сайта можно начать с нашей инструкции как проверить сайт на безопасность своими силами. В Design Lab такую подготовку мы делаем в рамках технической поддержки сайта: список хранилищ данных и доступов обновляется при каждом изменении сайта.