В понедельник утром владелица небольшого интернет-магазина товаров для дома получила письмо с темой «Ваша база в продаже». Внутри был фрагмент таблицы: имена, телефоны, адреса доставки и комментарии к заказам — всё настоящее. Отправитель предлагал «обсудить условия», а в конце добавлял, что через неделю цена вырастет. Первая мысль была самой естественной: сайт же работал, заказы приходили, никто не жаловался.
Эта история собирательная: компании, люди и числа вымышлены. Но последовательность событий типовая, и в ней нет ни одного редкого элемента — ни экзотической уязвимости, ни гениального злоумышленника, ни рокового совпадения. Именно поэтому она стоит разбора: узнаваемость здесь важнее деталей.
Утечка — это не один взлом, а цепочка забытых решений. Каждое из них по отдельности выглядело разумным компромиссом: обновить потом, пароль один, чтобы не путаться, логи не нужны, данные пусть лежат. В понедельник эти решения сошлись в одной точке — в таблице, которая лежала на общем диске и была доступна всем, кому она была нужна.
Что случилось
Магазин работал на популярной системе управления контентом, которую несколько лет назад собрал подрядчик. На сайте была форма заявки — имя, телефон, комментарий — и плагин для загрузки фотографий, без которого карточки товаров выглядели бы пусто. Подрядчик сдал проект, получил оплату и исчез из переписки, а внутри компании не появилось человека, который следит за версиями.
Данные из формы попадали в базу, а раз в неделю менеджер выгружал их в таблицу «клиенты_итог» на общем диске. Таблица была удобной: в ней можно было фильтровать, сортировать и дописывать комментарии, не заходя в административную панель. Доступ к ней был у владелицы, у менеджера и у подрядчика, который иногда помогал с настройками. За пять лет в таблице накопилось больше двадцати двух тысяч строк — вместе с теми, кто заказал один раз и больше не вернулся.
Таблица появилась не из злого умысла, а из удобства. Административная панель казалась менеджеру медленной, а выгрузка в знакомый файл — быстрой и понятной: там можно было сразу отметить, кто уже оплатил, а кто просил перезвонить. Заодно копии таблицы разошлись по почте и рабочим ноутбукам, и никто уже не мог сказать, сколько их и где они лежат. Так рабочая необходимость превратилась в ещё одно хранилище данных, о защите которого никто не думал.
В понедельник выяснилось, что таблица утекла. Фрагмент, присланный в письме, совпадал с реальными строками — включая пометки менеджера вроде «не звонить после семи» и «просил другой цвет». Это означало, что в руках злоумышленника не просто список телефонов, а рабочая база со всей историей заказов и внутренними комментариями, которых клиенты не видели никогда.
Первые часы ушли не на действия, а на разговоры. Владелица звонила подрядчику, тот не брал трубку; менеджер предлагал «переустановить сайт и забыть»; знакомый программист советовал «поменять пароли и подождать». Никто не знал, сколько записей пропало, когда произошёл доступ и нужно ли кому-то сообщать. К вечеру выяснилось ещё одно неприятное обстоятельство: журналы веб-сервера хранились сутки, и следов вторжения почти не осталось.
Если смотреть только на понедельник, кажется, что виноват старый плагин. Но плагин — это последнее звено, а не причина, и чтобы увидеть причину, нужно вернуться на два года назад. Тогда станет понятно, что взлом был не началом, а моментом, когда цепочка замкнулась.
Как это обычно происходит
Злоумышленники почти никогда не выбирают компанию заранее. Они сканируют диапазоны адресов и ищут сайты, которые отвечают определённым образом: версия системы видна в ответе сервера, версия плагина — в путях к файлам, а информация об уязвимости давно опубликована. Дальше остаётся сверить одно с другим и понять, стоит ли тратить время.
Устаревший плагин удобен для атаки именно своей предсказуемостью. Исправление вышло давно, описание уязвимости лежит в открытых базах, а на форумах обсуждают, как её использовать. Для магазина это означает простую вещь: дверь не взламывали, её просто не закрыли, и ключ был известен всем.
Сама атака занимает минуты. Сканер находит форму загрузки, пробует отправить файл и проверяет, выполнился ли он. Если да, через него читаются файлы настроек, а в них лежит доступ к базе. База выгружается, и дальше её судьба уже не зависит от магазина: её копируют, продают, показывают фрагменты покупателям.
Магазин не был целью — его нашли. В этом и заключается неприятная часть: вопрос «кому мы нужны» не работает, потому что выбирают не по значимости, а по доступности. Маленький размер компании влияет на масштаб последствий, но не на вероятность того, что её заметят.
Украденная база живёт долго и продаётся по частям. Её используют для звонков от «службы безопасности банка», для рассылок и для сервисов, где по номеру телефона ищут остальное. Поэтому утечка не заканчивается письмом в понедельник: через месяц она может вернуться к клиентам в виде звонка, и они вспомнят, где оставляли номер.
Та же цепочка иногда обходится без взлома: сотрудник увольняется и забирает таблицу с собой, потому что доступ был у всех и никто не считал это проблемой. Вывод от этого не меняется — данные утекают не в момент кражи, а в момент, когда их оставили в месте, где одна ошибка решает всё. Разница только в том, кто забирает данные: внешний человек или свой.
Пять решений, которые откладывали
Если пройти по времени назад, взлом окажется последним звеном. До него были решения, каждое из которых принимали не злодеи, а обычные люди, у которых не было времени, денег и ясного ответа на вопрос «кто за это отвечает». Именно поэтому разбор полезнее начинать не с уязвимости, а с людей и их компромиссов.
Самое старое решение касалось обновлений. Когда подрядчик сдал сайт, обновление стало восприниматься как риск: вдруг после него что-то сломается, а чинить некому. Сначала откладывали до конца сезона, потом до отпуска, потом до «пока не трогаем — работает же». За два года система отстала на несколько версий, а плагин загрузки фотографий не обновлялся дольше всех. В итоге никто в компании не мог сказать, какая версия стоит и какие исправления в ней отсутствуют. Обновления не любят ещё и потому, что они невидимы: пока всё работает, кажется, что работает и так.
Другое решение было про доступ. У базы был один общий пароль, и знали его все, кто когда-либо работал с сайтом: он лежал в файле настроек, в переписке и в блокноте менеджера. После увольнения сотрудника пароль не меняли, потому что «он же ничего плохого не сделал». Личных учётных записей не было, поэтому даже при желании никто не смог бы сказать, кто и когда заходил в базу. Общий пароль стирает и границы ответственности: непонятно, кто виноват, а значит, не отвечает никто.
Дальше — журналы. Аудита базы не было вовсе, а выгрузка таблицы нигде не фиксировалась, поэтому к моменту разбора журналы веб-сервера уже были перезаписаны: они хранились сутки. Нельзя было понять ни время доступа, ни то, какие ещё файлы читали. Без журналов инцидент перестаёт быть историей и превращается в догадку. А без истории нельзя ни оценить масштаб, ни честно ответить клиентам.
Ещё одна привычка касалась срока хранения. В таблице лежали заказы за пять лет, включая тех, кто купил один раз и больше не появлялся. Никто не решал, сколько хранить, поэтому хранили всё: «а вдруг пригодится для рассылки». Чем больше данных, тем больше ущерб от утечки и тем больше требований к их защите, но в момент накопления об этом никто не думает. Удаление казалось рискованным: а вдруг клиент вернётся и попросит восстановить историю заказов.
Плана на случай инцидента не было ни в каком виде: ни списка контактов, ни распределения ролей, ни решения о том, кто говорит с клиентами. Первые часы ушли на споры, 24 часа на уведомление регулятора истекли, а результаты внутреннего расследования пришлось отправлять с опозданием. Хуже того, кто-то успел переустановить сайт «для чистоты», и вместе с уязвимым плагином исчезли следы, которые могли бы показать масштаб. План — единственная вещь в этой истории, которую нельзя купить: она стоит только времени, которого в понедельник как раз не будет.
Ни одно из этих решений не выглядело ошибкой. Каждое экономило время сейчас и переносило риск на потом, а «потом» казалось далёким. В понедельник оно наступило сразу и целиком, и оказалось, что откладывали не задачу, а ответственность.
Первые часы: что делать, когда уже поздно
Первое правило звучит непривычно: сначала зафиксировать, потом чистить. Нужно сохранить копии журналов, файлов настроек, таблиц и переписки, а в идеале — снять образ диска до того, как на сервере что-то поменяют. Переустановка и «уборка» уничтожают доказательства, а без них невозможно понять, что именно утекло и сколько людей затронуто. Злоумышленник при этом может остаться с доступом, который вы сами ему оставили.
Дальше нужно остановить распространение. Сменяются все пароли, которые могли быть в конфигурации: от базы, административной панели, хостинга и почты, — а не только пароль от сайта. Уязвимый плагин отключается, лишние сессии разрываются, доступы подрядчиков пересматриваются. Если пароль был общим, исходить стоит из того, что он уже известен всем, кто его когда-либо видел.
Затем наступает очередь уведомления. С 2022 года оператор обязан сообщить в Роскомнадзор об утечке в течение 24 часов, а через 72 часа передать результаты внутреннего расследования. Уведомление — это не признание вины и не публичное покаяние, а обязанность, у которой есть срок. Пропустить его — отдельное нарушение, и штраф за молчание в некоторых случаях оказывается ощутимее, чем последствия честного разговора.
Важно. Уведомление регулятора не отменяет внутреннего разбора и не заменяет его. Сначала факты, потом выводы — иначе отчёт превратится в пересказ версий. И ещё: сообщить нужно в течение 24 часов, даже если полной картины к этому моменту ещё нет.
Параллельно идёт расследование. Нужно понять, к каким системам был доступ, какие данные могли уйти, сколько людей затронуто и что ещё связано с уязвимым компонентом. Для этого поднимаются журналы хостинга, письма подрядчика, история изменений файлов и записи о выгрузках. Отчёт должен опираться на факты, а не на предположения, поэтому даты и версии лучше фиксировать письменно по ходу разбора.
И отдельно — коммуникация. Клиенты всё равно узнают об утечке: из письма продавца базы, из новостей или от знакомых. Вопрос лишь в том, услышат они это от компании, которая объяснит, что произошло и что делать, или от того, кто эту базу продаёт. Партнёрам и руководству нужен короткий и честный ответ, а не обещание «всё под контролем».
После того как дыра закрыта, работу нельзя считать законченной. Нужно проверить, что исправление действительно установлено, что старые пароли больше нигде не действуют и что доступы подрядчиков пересмотрены. Полезно провести разбор без поиска виноватых: цель — не наказать менеджера, а понять, какое решение привело к инциденту и как изменить процесс. Иначе через полгода история повторится с другим плагином.
Ответственность в такой истории наступает не за взлом. Претензии возникают к тому, что не было сделано: за нарушение правил обработки организация платит от 150 до 300 тысяч рублей, за утечку данных от тысячи человек — от трёх до пяти миллионов, за повторную — оборотный штраф до 3% выручки. За скупку и распространение украденных баз предусмотрена уголовная ответственность по статье 272.1 УК. Штрафы обновлены законом 2024 года и действуют с 30 мая 2025-го, так что надеяться на старые суммы не стоит.
Урок, который дороже плагина
Пять решений — это на самом деле одно: у данных не было хозяина. Плагин не обновлял никто, потому что сайт «делал подрядчик»; таблица была доступна всем, потому что «так удобнее»; журналы не хранились, потому что о них никто не просил. У общей вещи не появляется ответственный сама собой, и в момент инцидента выясняется, что спросить некого.
Что можно было сделать иначе, не покупая дорогих систем? Завести перечень программ и версий, назначить человека, который отвечает за обновления, и поставить их в календарь — это закрывает половину истории. Дальше раздать личные учётные записи и оставить каждому минимум прав, включить журналирование и хранить записи достаточно долго, чтобы разобрать инцидент. И наконец — определить срок хранения данных, удалять то, что больше не нужно, и написать план на первые сутки, который хотя бы раз проговорили вслух.
Отдельно стоит вспомнить про подрядчика. Он не главный виновник в этой истории, хотя именно его часто назначают виноватым. Если в договоре не сказано, кто отвечает за обновления, какие версии допустимы и что происходит при инциденте, подрядчик искренне считает, что его работа закончилась на сдаче сайта. Требования к нему — такая же часть защиты, как календарь обновлений.
Возражение «нас это не касается, мы маленькие» здесь не работает. Атакующие не проверяют размер компании, а обязанности оператора не зависят от количества сотрудников: 24 часа и 72 часа одинаковы для магазина на десять человек и для сети на тысячу. Размер влияет на масштаб последствий, но не на правила игры. Базовые меры — обновления, личные аккаунты, журналы, срок хранения, план — стоят недорого и закрывают большинство типовых сценариев.
И ещё одна вещь, которую трудно принять: защита — это не продукт, а режим. Суперсредство не заменит человека, который отвечает за обновления, и не отменит привычку проверять, кто имеет доступ к таблице. В истории магазина не было ничего технически сложного — были забытые решения, каждое из которых чинится за один вечер.
Главная мысль
Утечка начинается не в понедельник, когда приходит письмо, а задолго до него. Она начинается с фразы «обновим потом», с общего пароля, который «все и так знают», с таблицы на общем диске и с плана, который собирались написать после квартального отчёта. Взлом лишь проявляет то, что уже было устроено неправильно.
Каждое звено этой цепочки чинится скучно: календарь обновлений, личные аккаунты, журналы, срок хранения, репетиция плана. Ни одно из этих действий не выглядит героическим, и именно поэтому их откладывают. Но цена забытого решения измеряется не только штрафом: клиенты уходят, партнёры задают неудобные вопросы, а доверие возвращается дольше, чем закрывается дыра.
Если хочется разобраться в теме глубже, начните с закона о персональных данных: там про уведомления, сроки и ответственность. Потом посмотрите про пароли и фишинг и резервные копии, а если непонятно, как читать требования, — разбор про чтение закона. Этого набора достаточно, чтобы следующий понедельник не начинался с вопроса «что теперь делать».