Инциденты виртуализации 2023–2026, которые стоили бизнесу данных и миллионов рублей

«У нас виртуализация отказоустойчивая — данные в безопасности». Эта фраза дорого стоила многим компаниям.

На практике часто бывает так: подняли кластер, раскидали ВМ, включили снапшоты, подключили бэкапы, сделали красивый дашборд — и возникает ощущение, что риски под контролем. А потом случается авария и выясняется, что отказоустойчивость — это не то же самое, что восстановление, а снапшот — не резервная копия. Данные теряются, бизнес терпит убытки.

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

Цифры и тренды: какие риски усилились с 2023 года

Число подтверждённых инцидентов информационной безопасности в 2025 году превысило 33 тысячи — против 31,5 тысячи в 2024-м. В структуре инцидентов заметно выросла доля изменений инфраструктуры: до 11% в общем числе и до 22% среди критичных. Это важный сигнал: атакующие всё чаще целятся в точки управления всей ИТ-средой.

При этом 90% компаний воспроизводят одни и те же критические ошибки, а 95% атак с шифрованием начинаются со скомпрометированных привилегированных учётных данных. То есть чаще всего инцидент начинается не с уникальной zero-day-уязвимости, а с простых вещей: сети, доменной учетной записи, избыточных прав и незащищённого доступа к ESXi. 

Отдельно отметим специфические риски для российских компаний после 2022 года. До ухода VMware занимал около 95% российского рынка виртуализации. К февралю 2026 года примерно 61% хостов — около 80 тысяч из 130 тысяч — всё ещё работали на VMware. Значительная часть из них — на версиях, поддержка для которых завершилась ещё осенью 2025 года.

Параллельно 78% российских организаций выбрали и тестируют отечественные платформы виртуализации, но пока не переводят на них основную работу. Это самая опасная фаза перехода: старый стек уже стал рискованным, новый ещё не везде доведён до зрелой эксплуатации.

Поверх технических рисков — регуляторный. Указ Президента №166 и последующие отраслевые разъяснения зафиксировали запрет на использование иностранного ПО на значимых объектах КИИ с 1 января 2025 года, с тех пор требования только ужесточаются.

Поэтому старый VMware в российском энтерпрайзе сегодня — это одновременно технический долг, киберриск и регуляторные запреты.

Семь российских историй

MTS Cloud, март 2024
Инцидент затронул три дата-центра — в Москве, Петербурге и Казахстане. Пострадала SAN: виртуальные машины и резервные копии в затронутых сегментах оказались недоступны одновременно.

Yandex Cloud, июнь 2024
Сетевые проблемы в зоне доступности ru-central1-d повлияли на виртуальные машины и кластеры. Параллельно возникли проблемы с питанием, которые затронули Compute Cloud. 

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

Yandex Cloud, март 2025
Зона ru-central1-b была полностью недоступна по питанию с 30 марта 12:25 до 31 марта 00:00. Compute, Instance Groups и Kubernetes встали на почти двенадцать часов.

Вопрос, который всплывает у бизнеса после таких кейсов, всегда один: «Наши критичные ВМ — в мультизонной архитектуре или в одной удобной зоне, потому что так было быстрее настроить?»

Yandex Cloud, ноябрь 2025
После инцидента в зоне ru-central1-b часть сетевых дисков оказалась в рассогласованном состоянии. На фоне этого наблюдалась частичная недоступность ресурсов и баз данных.

Это уже нарушение согласованности слоя хранения — когда к проблеме доступности добавляется риск некорректного состояния данных.

Selectel, апрель 2026
За один день — два инцидента с доступом к VDS в московском пуле. Первый длился около получаса, второй — несколько часов. Параллельно шли работы на инфраструктуре резервного копирования. 

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

Атака группировки Muliaka, январь 2024
У российской компании зашифровали Windows-системы и VMware ESXi одновременно. До финального удара злоумышленники провели в инфраструктуре около двух недель: использовали VPN компании, WinRM, а перед шифрованием — остановили службы баз данных и резервного копирования, удалили точки восстановления и теневые копии. То есть, атакующие последовательно выключили всё, что может помочь восстановиться.

Целенаправленные кибератаки Shadow/Twelve, 2023–2024
По данным F.A.C.C.T., с февраля 2023 по июль 2024 года синдикат атаковал не менее 50 российских организаций. Использовались утёкшие билдеры LockBit 3 и Babuk для ESXi. Часть операций Twelve была ориентирована не на вымогательство, а на полное уничтожение ИТ-инфраструктуры.
Схожую тактику применяли группы Masque и Warlock — последние, по данным расследований 2025 года, от первоначального доступа до шифрования систем виртуализации тратили от двух до четырёх дней. Слой виртуализации превратился в самый короткий путь к массовому разрушению.

Причём здесь управленческая логика

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

Под удар попадает зона, где одним действием можно затронуть максимум систем. Для облаков это часто storage или зона доступности. Для on-prem и гибрида — ESXi, vCenter, доменная интеграция, сервер резервного копирования. А уже потом выясняется, что план аварийного восстановления не тестировали и все «документы по DR» были в лучшем случае архитектурной фантазией. 

Три типовые ошибки:

• Открытый доступ к системам управления. Свободный доступ к ESXi, контроллерам домена и системам защиты создаёт условия для шифрования сразу на двух уровнях: ОС и виртуализации.
• Недооценка защиты резервного копирования. Если бэкап-серверы находятся в общей сети, подключены к домену или доступны по тем же учётным данным — после атаки выяснится, что копии зашифрованы, доступ потерян, или что их целостность давно никто не проверял.
• Иллюзия, что импортозамещение равно «перенесли ВМ на российскую платформу». На практике важны другие вещи: живая миграция, аналоги DRS, поддержка внешних хранилищ, интеграция резервного копирования, импорт ВМ из VMware, 2FA, максимальный размер кластера, поведение под нагрузкой, зрелость документации, скорость реакции вендора на баги. Там открывается много непредсказуемого. 

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

Что сделать прямо сейчас

Разделить управление, продуктив и резервное копирование. Бэкап-серверы — вне домена, с отдельными учётными записями. Хотя бы одна копия — вне основной площадки или в изолированном облачном контуре по принципу 3–2–1.

Закрыть доступ к ESXi и системам управления. Никаких прямых заходов с рабочих станций администраторов и доменных учёток «для скорости». MFA, отдельные привилегированные учётные записи, логирование в SIEM. Отдельно — проверить механику групп и все автоматические привязки прав.

Прекратить считать неподдерживаемый VMware рабочим. Уязвимости 2025 года Broadcom помечал как активно эксплуатируемые. Держать старый контур в статусе «мигрируем когда-нибудь» — это бомба замедленного действия.

Тестировать отказ сценария — «отвалилась зона», «сломалась сеть», «нужно восстановить пять критичных ВМ без доступа к домену». 

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

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

«Помогите не потерять данные и не встать после переезда» — вот правильная постановка вопроса.

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