В ночь с 1 на 2 ноября 2026 года инфраструктура Beget подверглась целевой кибератаке: злоумышленники получили доступ к управляющему контуру и запустили скрипты, обнуляющие данные. По сообщению компании, бинарные бэкапы VPS полностью утеряны, в облаке (VPS, S3, Kubernetes) данные утрачены, настройки CDN и IP-адреса также недоступны. Восстановление возможно только из файловых бэкапов, и то не гарантировано. Этот инцидент — не повод искать виноватых, а возможность провести честный postmortem и пересобрать архитектуру резервного копирования и доступа так, чтобы аналогичный сценарий не стал фатальным для вашей компании.

Что именно пошло не так: технический разбор

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

Отдельно стоит отметить потерю настроек CDN и IP-адресов. Даже если данные восстановятся, без этих конфигураций сервис не заработает в прежнем виде. Это типичная ошибка: команды часто резервируют только данные, забывая про инфраструктурные метаданные — конфиги, сертификаты, DNS-записи, правила маршрутизации.

Почему бэкапы не спасли: системные ошибки

Главный урок: бэкап, который доступен из того же управляющего контура, что и основная инфраструктура, не является надёжным. Если злоумышленник получает доступ к панели управления, он видит и может удалить резервные копии. Это не уникальная ошибка Beget — так устроены многие облачные архитектуры по умолчанию. Вот что усугубило ситуацию:

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

Конкретные шаги для защиты вашей инфраструктуры

Чтобы не повторить сценарий, начните с аудита текущей архитектуры резервного копирования. Задайте себе три вопроса: где физически лежат бэкапы, кто имеет к ним доступ и что произойдёт, если управляющий контур будет скомпрометирован. Ответы часто отрезвляют. Ниже — практический план действий.

  • Изолируйте бэкапы от продакшена. Храните резервные копии в отдельном аккаунте или проекте облака, с другими учётными данными и, желательно, у другого провайдера. Доступ к бэкапам не должен наследоваться из основной инфраструктуры.
  • Используйте неизменяемые хранилища. Настройте политику хранения, при которой резервные копии нельзя удалить или изменить в течение определённого срока (например, 30 дней). Это защитит от скриптов обнуления.
  • Регулярно тестируйте восстановление. Раз в квартал проводите учебное восстановление из бэкапа в изолированном окружении. Проверяйте не только данные, но и конфиги, сертификаты, DNS-записи.
  • Разделите права доступа. Введите принцип минимальных привилегий для управляющего контура. Используйте отдельные учётные записи для повседневной работы и для аварийного восстановления. Включите многофакторную аутентификацию везде, где возможно.
  • Резервируйте метаданные. Храните конфигурации CDN, IP-адреса, правила маршрутизации и прочие инфраструктурные настройки в виде кода (IaC) в репозитории, который не связан с продакшеном.

Типичные ошибки и как их избежать

Даже опытные команды допускают ошибки, которые кажутся очевидными только после инцидента. Вот наиболее частые:

  • Надежда на «облако всё сохранит». Провайдер отвечает за доступность сервиса, но не за сохранность ваших данных. Ответственность за бэкапы всегда на вас.
  • Бэкапы только в одном формате. Если вы делаете только бинарные копии VPS, при их потере остаётесь ни с чем. Комбинируйте бинарные и файловые бэкапы, храните их в разных местах.
  • Отсутствие плана восстановления. Когда случается авария, каждая минута на счету. Заранее опишите пошаговый план: кто что делает, где лежат ключи, как поднять сервис с нуля.
  • Игнорирование человеческого фактора. Скрипты обнуления запускаются не только злоумышленниками, но и по ошибке администратора. Защита от случайного удаления так же важна, как и от атаки.

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