Что потерял Beget при кибератаке и как восстановить магазин

Что известно к 01:25 мск 4 ноября

Beget подтвердил утрату рабочих данных в трех облачных сервисах и полную потерю бинарных резервных копий VPS. Сохранились файловые копии виртуальных серверов. Для обычного виртуального хостинга компания дала предварительную оценку. По ней удастся восстановить почти все размещенные там сайты. Это три разных утверждения. Из них нельзя вывести ни судьбу конкретного заказа, ни дату, на которую удастся вернуть конкретную базу. Сводка Beget по сервисам, 3 ноября.

Последнее сообщение провайдера, которое мы нашли к 01:25 мск, вышло в 01:01. Инженеры начали включать серверы виртуального хостинга и серверы под администрированием Beget. Каждую машину проверяли вручную, загружали с отдельного диска, очищали, проверяли целостность данных и работу сайтов. Компания увидела первые работающие сайты. Срок восстановления всей площадки и новый статус S3 в этом сообщении не указаны. Ночная сводка Beget, 4 ноября.

Как развивалась атака

2 ноября, 02:00–04:50 мск. По реконструкции Beget, около 02:00 злоумышленники получили доступ к серверам, через которые управляют инфраструктурой. В 02:30 они запустили программу удаления данных. Компания датирует обнаружение взлома примерно 02:40. В 02:55 серверы отключили от сети, чтобы остановить распространение атаки. С 03:00 шли расследование и восстановительные работы. В 04:50 появилось первое публичное предупреждение. Момент входа и момент обнаружения сам Beget называет предположительными. Хронология на сайте провайдера и первое предупреждение.

2 ноября, день. Около 14:00 вернулись в работу выделенные серверы, которыми управляли сами клиенты. К 17:00, по данным компании, заработали серверы DNS для доменных имен. DNS отвечает, куда направить посетителя. Даже правильный ответ DNS не откроет магазин, если по указанному адресу еще нельзя запустить сайт. В тот же день Beget уведомил клиентов об обстоятельствах, которые компания считает имеющими признаки непреодолимой силы. Это позиция провайдера по договору. Размер ущерба отдельных клиентов в сообщении не приводился. Хронология Beget и уведомление клиентам.

3 ноября, день. К полудню Beget оценивал восстановленную часть почтовой инфраструктуры более чем в 80%. Заработали почтовые протоколы, в 13:30 вернулся веб-интерфейс. В 14:00 компания сообщила о поэтапном восстановлении виртуального хостинга. В 15:15 опубликовала разбивку потерь по услугам и объяснила задержку необходимостью вручную проверить свыше тысячи серверов. Хроника сервисов и разбор последствий.

С вечера 3 ноября до 01:25 мск 4 ноября. В 17:40 Beget объяснил, как менять записи доменов в зонах .ru, .рф и .su через временную страницу. В 22:17 этот способ распространили и на международные домены, обслуживаемые Beget и его партнерами. Для домена с чужими NS-серверами записи меняются у оператора этих серверов. Код для доступа приходил на почту администратора домена. Следующая существенная веха к нашей отсечке — первые запущенные сайты в 01:01. Инструкция в 17:40, обновление в 22:17, статус в 01:01.

Какие данные потеряны и что еще можно вернуть

Виртуальный хостинг. Предварительная оценка Beget о восстановимости почти 100% сайтов относится к этой услуге. Процент касается количества сайтов. По нему нельзя судить, сколько последних записей в каждом магазине сохранилось и на какую дату. Владельцу нужны дата и время восстановленной базы, загруженные файлы и сверка последних операций. Оценка Beget.

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

S3 и Kubernetes. В перечень утраченного Beget включил данные объектного хранилища S3 и среды Kubernetes, в которой запускают приложения. Сообщение о сохраненных копиях VPS не обещает восстановления содержимого каждого S3-бакета или постоянного диска приложения. Для магазина это, например, разница между карточкой товара в базе и лежащим отдельно оригиналом фотографии. Уцелевшая карточка сохранит ссылку на файл. Сам файл по ссылке придется искать у фотографа, в товарном каталоге или в независимом архиве. Состав облачных потерь по данным Beget.

Выделенные серверы, CDN и IP. На машинах под администрированием Beget, по оценке компании, сохранилась большая часть данных. Для самостоятельно администрируемых машин провайдер сообщил о возврате в работу еще 2 ноября. Отдельно он указал на потерю настроек CDN и IP. Эти настройки нужны, чтобы направить трафик на нужную площадку и раздавать содержимое. Конфигурацию стоит хранить вне панели хостера, чтобы при переезде ее можно было воспроизвести. Данные по выделенным серверам и сети.

Что означает «не подлежит восстановлению». Без оговорок Beget сообщил о полной потере бинарных копий VPS. По облаку провайдер признал утрату данных и продолжал искать способы восстановления. В обсуждении на Хабре один из участников описал отсутствие доступа больше суток. Так можно установить длительность простоя. Для вывода о безвозвратной потере конкретной базы нужны результат проверки ее копий у провайдера и сведения о копиях владельца. К 01:25 Beget такого вывода для всех клиентов не публиковал. Заявление Beget, обсуждение на Хабре.

О возможной утечке известно меньше. В сводке 3 ноября Beget сообщил, что на серверах с клиентскими данными не обнаружил признаков попыток их скачивания. Расследование продолжалось. Уничтожение данных и их копирование злоумышленником требуют разных доказательств. Сам провайдер рекомендовал сменить пароли и ключи, которые могли храниться на серверах. Публичного технического заключения о способе первоначального проникновения к отсечке не было. Комментарий Beget о доступах и ходе расследования.

Как простой выглядел со стороны клиента

В BelkaCar клиент мог физически закончить поездку, но не завершить аренду в приложении. Компания просила закрыть машину, зафиксировать время и обещала пересчитать стоимость зависшей аренды. Во второй половине дня 2 ноября каршеринг сообщил о восстановлении доступа после перехода к другому подрядчику. Из этого случая известно, какая операция перестала работать. Сведений о потере истории поездок у нас нет. Сообщение BelkaCar и пояснения компании РБК.

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

Если ваш проект все еще недоступен

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

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

При возврате файлов положите исходную копию отдельно. Систему поднимайте из доверенного дистрибутива в изоляции. Проверьте задания по расписанию, исполняемые файлы, добавленные учетные записи и ключи. Выпустите новые секреты для чистого окружения, согласуйте переключение с CRM и банком, затем отзовите старые. Полный образ диска, если он есть у самого клиента, тоже может содержать следы атаки. Этот порядок помогает сохранить исходные материалы для расследования и вернуть сайт без повторного запуска вредоносного кода. Рекомендация Beget о смене доступов.

Какие меры ограничивают такую атаку

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

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

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

Реплика в соседней зоне помогает пережить отказ оборудования. При корректно выполненной команде удаления она способна повторить удаление. Здесь полезна история версий с запретом менять или удалять старую версию до заданной даты. Например, в Yandex Object Storage для этого нужны версионирование и блокировка версий. Включение функции не защищает ранее загруженные версии автоматически. Удалите текущую версию тестового объекта и попробуйте прочитать сохраненную. Проверьте, может ли ключ рабочего приложения снять защиту. Как устроена блокировка версий в Yandex Cloud.

Что именно копировать интернет-магазину

Начните с базы заказов, строк заказа, скидок, статусов возврата и идентификаторов платежей. Уточните, можно ли привести базу к общему моменту времени. Например, для PostgreSQL есть восстановление из базовой копии с непрерывной цепочкой журналов WAL. Обрыв цепочки ограничивает доступную точку возврата. Копирование каталога работающей базы обычной файловой утилитой без согласованного снимка не дает тех же гарантий. Документация Postgres Professional.

Базу товаров, фотографии, вложения покупателей и документы часто хранят в разных системах. Сделайте опись с указанием, где лежит оригинал каждого вида данных, как он связан с товаром или заказом и чем открывается.

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

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

Как пережить две аварии с интервалом в три недели

У этого сценария есть октябрьский контекст. Яндекс 9 октября сообщил о повреждениях площадок в Сасово и Калуге, а 11 октября добавил сообщение об остановке дата-центра во Владимире. Причиной тогда было физическое повреждение инфраструктуры. Mindbox, работавший на этой инфраструктуре, 19 октября сообщил, что подготовил резервные мощности в трех дата-центрах другого поставщика. Ни одна из этих компаний не называла Beget площадкой переезда в своих сводках. Сообщение Яндекса, разбор Mindbox и октябрьский выпуск FIRSTOV.

Представим условный магазин. Основной сайт работает в Яндекс Облаке, архив лежит у Beget. После аварии у первого провайдера команда разворачивает магазин у второго и три недели принимает там заказы. Затем теряет и вторую площадку. Это учебный сценарий. Он показывает ошибку, которую легко пропустить в день переезда. Резервная площадка стала рабочей. За ее пределами новые заказы никто не копирует.

Копия, сделанная до первой аварии, поможет запустить старую версию. Об истории последних трех недель она ничего не знает. Даже 90 дней хранения не исправят эту дыру. Еще до открытия оплаты на запасной площадке запустите резервирование в место вне ее управления, дождитесь первой успешной копии и убедитесь, что ее можно прочитать с отдельной машины. Если это пока невозможно, зафиксируйте ограничение и выберите временный режим, например прием обращений без онлайн-оплаты.

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

Сигнал о пропущенной копии отправляйте вне основного хостинга. Отслеживайте возраст последней пригодной к чтению копии и непрерывность архивов базы. Иначе ежедневное письмо «задача выполнена» может неделями подтверждать запись пустого файла.

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

Где хранить копии с персональными данными

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

Часть 5 статьи 18 закона № 152-ФЗ ограничивает использование зарубежных баз при сборе персональных данных граждан России, в том числе при сборе через интернет. Ограничение охватывает запись, хранение, обновление и другие перечисленные в норме операции. В законе есть прямо названные исключения. Роскомнадзор отдельно разъяснил, что для последующей трансграничной передачи данных, уже собранных с использованием российских баз, действуют требования статьи 12, включая предварительное уведомление. Российская первичная база сама по себе не дает разрешения выгружать клиентский архив в любое иностранное облако. Часть 5 статьи 18 и письмо Роскомнадзора от 24 марта 2025 года № 08-134789.

Для магазина, который решил хранить клиентские данные только в России, две независимые российские площадки и локальный носитель позволяют выполнить это условие. До договора запросите, где физически лежат рабочая база, резерв и его реплики, кому поручена обработка и как удаляются копии по окончании согласованного срока. Уточните, не выгружает ли подрядчик полный дамп на свой ноутбук за рубежом для тестов. Статья 19 прямо включает восстановление данных, измененных или уничтоженных из-за неправомерного доступа, в перечень мер безопасности. Статья 19 закона № 152-ФЗ.

Как узнать, что магазин действительно восстановится

RPO задает допустимый возраст данных при восстановлении. RTO задает допустимое время до возвращения конкретной функции в работу. Условный магазин принимает 12 заказов в час. За 15 минут при равномерном потоке поступят примерно три заказа, за восемь часов — около 96. Это операции для сверки. Часть можно восстановить из CRM или платежного реестра. Ни 3, ни 96 нельзя автоматически записать в потерянные продажи. Договоритесь отдельно о сроке возвращения каталога, оплаты и отправки на склад.

Разверните магазин с нуля. Дайте дежурному пустой сервер и запретите на время учебной проверки пользоваться основной панелью. Засеките время с объявления аварии. Пусть дежурный найдет копию, получит ключ, восстановит файлы и базу в изолированной сети. Отключите исходящие письма, реальные платежи, кассу и передачу на склад, чтобы учебный заказ не стал настоящим. В журнал занесите дату последней восстановленной операции и время до первого успешного тестового заказа. Сравните оба результата с целями. Время скачивания тоже входит в простой. Условные 500 ГБ при канале 100 Мбит/с передаются чуть больше 11 часов даже без накладных расходов. Если магазин обещает вернуться за четыре часа, такую копию придется заранее доставить на резервную площадку или обеспечить более быстрый путь.

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

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

Словарь статьи

Постоянный диск

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

Платежный шлюз

Сервис, через который сайт отправляет запрос на оплату и получает ее статус. Если доступ к нему потерян, каталог может открываться, а оплата не пройдет.

Секреты доступа

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

VPS

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

Kubernetes

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

S3

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

S3-бакет

Именованный контейнер в объектном хранилище. Например, магазин может сложить фотографии каталога в один бакет и отдельно настроить права на чтение и удаление.

Виртуальный хостинг

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

Выделенный сервер

Отдельная физическая машина для одного клиента. Кто обновляет систему и делает копии, зависит от условий обслуживания.

Файловая копия

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

Бинарная копия VPS

Образ диска виртуального сервера. Позволяет восстановить состояние диска вместе с системой и установленными программами на дату снимка.

CDN

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

IP

Сетевой адрес, по которому компьютеры находят сервер. После переезда он может измениться. Тогда домен и внешние сервисы нужно направить на новый адрес.

DNS

Система доменных имен. Ее записи указывают, на какой адрес направить посетителя сайта и куда доставлять почту для домена.

NS-серверы

Серверы, отвечающие за DNS-записи домена. Если домен зарегистрирован в одном месте, а обслуживают его другие NS-серверы, записи редактируют у оператора этих серверов.

Регистратор домена

Компания, через которую владелец регистрирует и продлевает доменное имя. Она может отличаться от компании, где лежат файлы сайта.

CRM

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

Эквайер

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

PostgreSQL

Система управления базами данных. Она хранит записи, например состав заказов, и следит, чтобы связанные изменения записывались целиком.

WAL

Журнал изменений базы PostgreSQL. Вместе с базовой копией непрерывная цепочка таких журналов позволяет вернуть базу к выбранному моменту.

Реплика

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

Версионирование

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

Блокировка версий

Запрет на удаление или изменение сохраненной версии файла. Срок защиты и права на ее снятие зависят от настроенного режима.

Логи

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

Дамп

Выгрузка базы данных для переноса или восстановления. В полном дампе магазина могут оказаться телефоны, адреса и история заказов.

RPO

Допустимая глубина отката данных. Если цель — 15 минут, после восстановления магазин должен получить данные как минимум на момент за 15 минут до аварии.

RTO

Целевое время возвращения функции после сбоя. Например, четыре часа для оплаты означают, что за этот срок покупатель снова должен суметь оформить и оплатить заказ.

Дата-центр

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

Снимок

Зафиксированное состояние данных на один момент времени. Для базы важно, чтобы связанные файлы можно было восстановить вместе без противоречий.

Дистрибутив

Набор файлов для установки системы или программы. При восстановлении после взлома установщик берут из доверенного источника.

Трансграничная передача

В контексте закона № 152-ФЗ это передача персональных данных на территорию иностранного государства иностранному органу власти, человеку или организации.