Продолжение расследования «25 минут до уничтожения: как взлом Beget обрушил облачную инфраструктуру».
7 ноября 2026 года | Стеклянный мост | Кибербезопасность
Представь, что ты пять лет строил бизнес.
Создавал интернет-магазин, разрабатывал собственную платформу, собирал клиентскую базу. Ночами исправлял ошибки, платил программистам, покупал серверы, вкладывал деньги в рекламу.
На экране панели управления ежедневно появлялась успокаивающая надпись: BACKUP COMPLETED.
А однажды утром вместо работающего проекта ты обнаруживаешь пустоту.
Сервер уничтожен. База недоступна. Панель не открывается. Резервная копия тоже исчезла.
Ты не забыл пароль. Не пропустил оплату. Не нарушил правила эксплуатации.
Просто инфраструктуру компании, которой ты доверил годы собственной жизни, атаковали злоумышленники.
И теперь твой бизнес зависит от того, смогут ли чужие инженеры собрать уцелевшие данные.
Это не сценарий фантастического триллера.
Это последствия кибератаки на российского хостинг-провайдера Beget.
1. От двадцати пяти минут атаки до потери клиентских данных
В нашем первом расследовании атаки на Beget мы разобрали хронологию произошедшего в ночь на 2 ноября 2026 года.
Согласно официальной хронологии Beget, предполагаемое проникновение в управляющую инфраструктуру началось около 02:00 по московскому времени.
В 02:30 атакующие запустили вредоносное ПО, предназначенное для удаления данных.
В 02:40 специалисты обнаружили признаки несанкционированного доступа.
В 02:55 серверы отключили от сети, пытаясь остановить распространение атаки.
Двадцать пять минут между запуском программы уничтожения и отключением серверов.
Но настоящие масштабы катастрофы стали понятны позднее.
6 ноября Интерфакс сообщил о новой оценке потерь Beget: файловые резервные копии VPS, по прогнозу провайдера, будут доступны примерно половине пользователей.
К тому времени компания восстановила более 60% виртуального хостинга и 40% выделенных серверов, находившихся под её администрированием.
А облачную инфраструктуру пришлось строить заново.
РБК также сообщил о повреждении внутренних данных провайдера: у некоторых пользователей пропали актуальные связи между аккаунтами и услугами.
Это означает, что даже сохранившийся архив не всегда можно немедленно вернуть владельцу.
Сначала его необходимо найти, правильно идентифицировать и сопоставить с конкретным клиентом.
Злоумышленники ударили не только по серверам. Пострадала сама система восстановления.
2. Почему резервные копии не спасли всех
Многие владельцы сайтов уверены: если хостинг предлагает резервное копирование, значит, их информация защищена.
Но между наличием архива и его независимостью существует огромная разница.
Представь промышленное предприятие с тремя резервными генераторами.
Первый установлен в главном цехе. Второй в соседнем корпусе. Третий за пределами основной площадки.
Кажется, система надёжная.
Но все три генератора подключены к одному управляющему контроллеру. И одна неисправность этого контроллера одновременно запрещает запуск всех установок.
Резервирование есть.
Независимости нет.
В серверной инфраструктуре аналогичная проблема возникает, когда рабочие виртуальные машины, хранилища, снапшоты и системы резервного копирования управляются одним административным контуром.
Эта система называется Control Plane, плоскость управления.
Через неё создают виртуальные серверы, подключают диски, изменяют сетевые настройки, управляют ресурсами и удаляют их.
Если злоумышленник получает достаточно высокие полномочия, ему не обязательно взламывать каждый сервер отдельно.
Он способен воздействовать на множество ресурсов централизованно.
Beget подтвердил получение злоумышленниками доступа к управляющему контуру и запуск обнуляющих скриптов в официальном канале компании.
Однако конкретные команды, первоначальная уязвимость и полный механизм разрушения публично не раскрыты.
Поэтому пока нельзя утверждать, какой именно инструмент применили атакующие.
Но основной архитектурный вывод уже очевиден:
Три резервные копии бесполезны против одной украденной учётной записи, если эта запись имеет право удалить все три.
3. Самая дорогая потеря: не сервер, а время
Физический сервер можно заменить.
Новый VPS можно заказать за несколько минут.
Систему можно переустановить.
Но как заменить базу клиентов, которую собирали пять лет? Как восстановить историю заказов, закрытые договоры, фотографии, авторский контент, документы и результаты работы команды?
Особенно тяжёлый удар получают небольшие компании.
У крупной корпорации могут существовать резервные площадки, отдельные команды инфраструктуры и полноценные планы аварийного восстановления.
У малого бизнеса часто есть один сервер, одна база данных и владелец, который одновременно выполняет обязанности директора, маркетолога и системного администратора.
Поэтому последствия различаются.
Один клиент Beget может переключиться на другого провайдера и восстановить деятельность из независимого архива.
Другой будет собирать проект буквально по кускам.
А третий обнаружит, что нужных данных больше нет.
Показателен случай каршеринга BelkaCar. Как сообщил РБК, сбой инфраструктуры Beget затронул работу сервиса, однако компания затем восстановила доступ, переключившись на альтернативного подрядчика.
Разница принципиальная.
Первый бизнес зависит от возвращения старого провайдера. Второй способен продолжить работу без него.
Вот что на практике означает цифровая независимость.
4. Главная инженерная ошибка: все яйца в одной корзине
Распространённая схема небольшого интернет-проекта выглядит так:
- Сайт размещён у одного провайдера.
- База данных находится там же.
- Почта и DNS обслуживаются через ту же инфраструктуру.
- Резервные копии создаются в той же панели.
- Административные доступы сосредоточены в одном аккаунте.
Пока всё работает, такая архитектура кажется удобной.
Один интерфейс. Один счёт. Одна техническая поддержка.
Но удобство превращается в зависимость.
При серьёзном инциденте владелец может одновременно потерять приложение, данные, управление доменом и доступ к архивам.
Причём переход на другой сервер того же поставщика проблему не решает, если оба ресурса управляются общей системой.
Настоящая отказоустойчивость начинается с разделения не только серверов, но и полномочий.
Для этого существует подход Zero Trust: доступ не считается безопасным только потому, что он находится внутри инфраструктуры или принадлежит администратору.
Каждая система получает минимально необходимые права.
Особенно это важно для резервного копирования.
Производственный сервер может создавать новые архивы, но не должен обладать неограниченным правом уничтожать их историю.
5. Архитектура выживания: три независимых контура
Чтобы пережить полное уничтожение основного хостинга, проекту необходима система восстановления, не зависящая от его управляющей панели.
Контур №1. Рабочая инфраструктура
Здесь находятся действующий сайт, API, PostgreSQL, пользовательские файлы, приложения и службы.
Эта площадка обслуживает текущую нагрузку.
Она не должна быть единственным местом хранения критически важных данных.
Контур №2. Независимый архив
Резервные копии передаются другому поставщику с отдельными учётными данными.
Например, для этого подходит объектное хранилище с поддержкой S3 Object Lock.
В режиме Compliance защищённую версию объекта нельзя удалить или перезаписать до окончания установленного срока хранения даже с правами владельца аккаунта.
Эти свойства подробно описаны в официальной документации Amazon Web Services.
Однако защита действует на конкретные версии объектов и требует правильной настройки. Она не заменяет шифрование и проверку восстановления.
Контур №3. Автономная копия и план запуска
Третий уровень - локальный компьютер, отдельное устройство хранения или полностью независимая резервная площадка.
Здесь должны находиться не только файлы сайта, но и необходимые материалы для восстановления:
- согласованные резервные копии баз данных;
- конфигурации серверов и приложений;
- файлы и пользовательские медиа;
- документация по развёртыванию;
- защищённые ключи восстановления;
- проверенные инструкции запуска сервисов.
Чувствительные секреты необходимо хранить отдельно, в зашифрованном виде, с резервированием доступа.
Главная проверка проста.
Если завтра полностью исчезнет основной провайдер, получится ли запустить проект, используя только независимые копии?
Если ответ неизвестен, архитектура восстановления ещё не проверена.
6. Почему даже хороший бэкап иногда бесполезен
Есть ещё одна опасная иллюзия.
Системный администратор видит сообщение BACKUP SUCCESS и считает задачу выполненной.
Но успешное создание архива не означает успешного восстановления.
Например, PostgreSQL может содержать постоянно изменяющиеся транзакционные данные.
Простое копирование файлов работающей базы без соблюдения необходимых процедур не гарантирует получение согласованной копии.
Для восстановления используются корректные логические дампы или физические резервные копии с необходимыми журналами транзакций.
А контейнерное приложение может зависеть от десятков внешних параметров: переменных окружения, ключей, томов данных, конфигурации прокси и версий программного обеспечения.
Поэтому восстановление необходимо проверять на отдельной площадке.
Не раз в день инцидента, когда уже поздно.
А заранее.
У специалистов существуют два основных показателя:
RPO - допустимый объём потери данных во времени.
RTO - допустимое время восстановления сервиса.
Если база копируется только ночью, владелец может потерять почти сутки новых операций.
Если архив существует, но его развёртывание занимает трое суток, бизнес будет простаивать все трое суток.
Оба показателя должны соответствовать реальной экономике проекта.
7. Что делать владельцам российских сайтов прямо сейчас
Не требуется немедленно арендовать несколько дата-центров.
Нужно избавиться от единственной точки катастрофического отказа.
Первое. Проверьте, у кого физически и административно хранятся ваши резервные копии.
Второе. Создайте независимую копию критических данных у другого поставщика или на собственном устройстве.
Третье. Разделите права на создание и удаление архивов. При возможности включите версионирование и неизменяемое хранение.
Четвёртое. Подготовьте резервный способ управления DNS. Регистрация домена, обслуживание DNS и размещение сайта - разные услуги.
Пятое. Проведите учебное восстановление: поднимите проект на чистом сервере и убедитесь, что база, файлы и приложение действительно работают.
Шестое. Сохраните отдельный зашифрованный архив критических конфигураций, а также надёжный доступ к ключам и средствам двухфакторной аутентификации.
Седьмое. Проверяйте восстановление регулярно, особенно после крупных изменений инфраструктуры.
И важнейшее правило: никакая резервная копия не должна считаться единственной, даже если она называется резервной.
8. Что будет с Beget и его клиентами
По состоянию на 7 ноября восстановительные работы продолжаются.
Компания публично сообщает об устранении последствий атаки и реконструкции облачной инфраструктуры. Следить за сообщениями можно через официальный канал Beget.
Но есть существенная разница между восстановлением работы провайдера и восстановлением данных каждого пострадавшего клиента.
Компания может вновь запустить серверные мощности.
Может вернуть доступ к панели управления.
Может восстановить обслуживание доменов и сайтов.
Однако это не означает автоматического возвращения всех уничтоженных пользовательских данных.
Именно поэтому Интерфакс и РБК отдельно отмечают проблему доступности файловых резервных копий VPS.
При этом говорить о банкротстве Beget пока оснований недостаточно. Масштаб аварии подтверждён, но финансовая судьба компании ещё не определена.
Для клиентов гораздо важнее другой вопрос: какие именно данные удастся вернуть и сколько времени потребуется для восстановления их бизнеса.
9. Главный вывод: твой бизнес не должен умирать вместе с хостингом
Кибератака на Beget стала серьёзным предупреждением российскому рынку цифровых услуг.
Провайдер может обладать огромной инфраструктурой, инженерной командой и многолетней репутацией.
Но достаточно одной катастрофической компрометации системы управления, чтобы последствия затронули множество независимых компаний и частных проектов.
Для малого бизнеса это особенно страшно.
За уничтоженным сервером может стоять не абстрактный набор виртуальных дисков.
Там могут находиться годы бессонных ночей, семейные накопления, взятые кредиты, работа сотрудников, доверие клиентов и будущее предпринимателя.
Именно поэтому независимые резервные копии - не техническая прихоть системного администратора.
Это защита результатов человеческого труда.
Ты можешь арендовать сервер.
Можешь арендовать облако.
Можешь доверить провайдеру обслуживание оборудования.
Но нельзя отдавать одной компании исключительную возможность сохранить или уничтожить всё, что ты построил.
Провайдер должен быть заменяемым. Твои данные - нет.
Связанные материалы и первоисточники
Стеклянный мост: 25 минут до уничтожения - первая часть расследования
Beget Official - официальные сообщения о кибератаке и восстановлении
Интерфакс - оценка потерь резервных копий VPS