Кибератака на Beget: почему данные в облаке могут исчезнуть и как их защитить

В ночь на 2 ноября 2026 года один из крупнейших российских хостинг-провайдеров Beget, обслуживающий более 200 тысяч клиентов, подвергся целенаправленной кибератаке. Злоумышленники получили доступ к управляющим серверам инфраструктуры и запустили вредоносное ПО, предназначенное для массового удаления данных. Специалисты компании обнаружили вторжение через 10 минут и к 02:55 отключили оборудование от сети, однако к этому моменту облачная инфраструктура — включая VPS, хранилища S3 и платформу Kubernetes — была практически полностью уничтожена. Погибли не только основные данные, но и бинарные бэкапы виртуальных серверов, что сделало невозможным восстановление «как было» для большинства пользователей.

Хронология инцидента: от взлома админки к потере облака

Атака началась около 02:30. Хакеры скомпрометировали центральную систему управления, через которую провайдер контролирует всю серверную ферму. Это позволило им выполнить команду на удаление данных сразу на производственных мощностях и в системах резервного копирования. Восстановление началось в тот же день: к вечеру 2 ноября были возвращены в работу выделенные серверы (управляемые клиентами самостоятельно) и DNS-серверы, обеспечивающие доступ к доменам. Сами доменные имена не пострадали.

С облачными сервисами ситуация оказалась сложнее. 3 ноября компания сообщила о сохранности файловых резервных копий VPS на отдельных серверах в другом дата-центре, однако после детальной проверки уцелевших хранилищ 6 ноября признала, что такие бэкапы смогут получить только около половины пользователей. Кроме того, была утрачена часть записей во внутренней учетной системе. К 7 ноября частично заработала панель управления, началась передача оставшихся копий клиентам и восстановление сайтов на виртуальном хостинге. Параллельно с 3 ноября была временно приостановлена аккредитация Beget как регистратора доменов .RU и.РФ — компания не может регистрировать новые имена и принимать их на перевод, но ранее зарегистрированные домены продолжают обслуживаться.

Почему резервные копии провайдера не спасли данные

До инцидента Beget использовал схему с физическим разделением: файловые бэкапы VPS хранились на отдельных серверах в другом дата-центре. Такой подход защищает от отказа оборудования, пожара или аварии на основной площадке, но беспомощен при компрометации административной консоли. Если у злоумышленников есть доступ к единой панели управления, они могут удалить и основные данные, и бэкапы, даже если те лежат в другом здании. Избежать этого помогает логическая изоляция — создание отдельных учетных записей и хранилищ с политикой WORM (Write Once, Read Many), где уже созданные копии нельзя изменить или стереть из основной админки. Как именно были уничтожены бэкапы Beget, публично не раскрывается, но сам факт потери копий на удаленной площадке подтверждает: физическое разделение без независимости управления не гарантирует сохранность.

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

Как защитить данные от сбоев и атак на провайдера: правило 3-2-1-1

Владелец сайта не может контролировать безопасность инфраструктуры хостера, но может подготовиться к полной потере доступа к ней. Эксперты «Лаборатории Касперского» рекомендуют стратегию резервного копирования 3-2-1-1: хранить три экземпляра данных на двух типах носителей, одну копию держать за пределами основной площадки (в другом облаке или дата-центре), а еще одну — в изолированном от сети хранилище (offline/air-gapped). Например: рабочий VPS, ежедневный бэкап в независимом облачном хранилище (Selectel, Yandex Cloud, S3-совместимое) и недельная полная копия на внешнем диске, который физически отключается после записи.

Практический чек-лист подготовки

• Архивируйте всё, а не только файлы сайта. В бэкап должны попадать базы данных, конфигурации веб-сервера (nginx, apache), системные настройки, SSL-сертификаты, крон-задания и скрипты деплоя. Для интернет-магазина с ежедневными заказами еженедельного бэкапа недостаточно — нужен интервал в часы.
• Проверяйте восстановление регулярно. Раз в месяц разворачивайте тестовый стенд на чистом сервере (можно дешевом VPS у другого провайдера) и убеждайтесь, что сайт открывается, база поднимается, платежи проходят. Только так вы узнаете, что копия рабочая, а инструкция восстановления актуальна.
• Готовьтесь к миграции заранее. Храните доступ к управлению DNS-записями домена независимо от хостинга (панель регистратора или внешний DNS-провайдер вроде Cloudflare). Сохраните файл зоны и инструкцию по смене A/AAAA-записей. Если основной хостинг упадет, вы перенаправите трафик на резервный сервер за минуты, а не за дни.
• Защитите учетные записи. После крупных инцидентов срочно меняйте пароли и API-ключи от панели хостинга, регистратора домена, хранилищ бэкапов и серверов мониторинга. Используйте уникальные пароли и обязательно двухфакторную аутентификацию. Для генерации и хранения сложных секретов удобны менеджеры паролей вроде Kaspersky Password Manager с шифрованием AES-256.
• Защитите рабочую станцию администратора. Учетные данные часто утекают через фишинг и вредоносное ПО на компьютере сотрудника. Решения класса Kaspersky Premium блокируют опасные сайты и находят трояны-крады паролей, снижая риск компрометации точки входа в вашу инфраструктуру.

Вопросы и ответы

Что именно потеряли клиенты Beget при атаке 2 ноября 2026 года?

Полностью уничтожена облачная инфраструктура: VPS, хранилища S3, платформа Kubernetes. Погибли бинарные бэкапы VPS (полные образы серверов). Файловые резервные копии уцелели только у примерно половины пользователей. Также повреждена внутренняя учетная система, что затруднило идентификацию владельцев оставшихших архивов.

Почему бэкапы в другом дата-центре не помогли?

Физическое разделение серверов не защищает, если единая административная панель управляет и производством, и резервным копированием. Получив доступ к админке, хакеры могут удалить данные везде, где есть права у скомпрометированной учетной записи. Надежная защита требует логической изоляции: отдельных аккаунтов для бэкапов, хранилищ с запретом на удаление (WORM) и автономных копий вне досягаемости управления провайдера.

Как быстро восстановить сайт, если хостинг-провайдер недоступен надолго?

Нужно заранее иметь: (1) актуальный автономный бэкап по схеме 3-2-1-1, (2) проверенную инструкцию развертывания на чистом сервере, (3) независимый доступ к DNS-управлению доменом. Тогда вы арендуете VPS у другого провайдера, разворачиваете сайт из бэкапа и меняете A-запись домена — посетители попадут на новый сервер за время распространения DNS (обычно минуты-часы). Без своих бэкапов и доступа к DNS вы полностью зависите от сроков восстановления провайдера.