Безопасность в среде виртуализации: защита гипервизора и виртуальных машин

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

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

Гипервизор - царь горы, которого нужно охранять

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

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

Отсюда следует одна неочевидная вещь. Антивирус внутри гостевых ОС не защищает гипервизор. Он вообще не видит уровень, на котором произошёл взлом. Средства мониторинга, которые живут внутри виртуальных машин, при компрометации хоста замолкают первыми - и молчание в мониторинге само по себе становится симптомом.

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

Многослойная защита: строим оборону правильно

Безопасность виртуализации складывается из нескольких рубежей обороны, и большинство инцидентов случается на самых базовых. Не из-за сложных эксплойтов - из-за учётной записи, которую забыли отозвать, и порта управления, который смотрит в интернет.

Аутентификация и доступ

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

Многофакторная аутентификация на вход в панель управления нужна обязательно. Причём не SMS - коды перехватывают через подмену SIM. Аппаратные токены или приложения-аутентификаторы. Да, это неудобно, и админы поворчат. Один раз.

Принцип наименьших привилегий работает и здесь. Инженеру, который смотрит на графики загрузки, не нужны права на удаление виртуальных машин. Разграничение по ролям (RBAC) есть во всех платформах - в vSphere, в Hyper-V через делегирование, в Proxmox VE через пулы и роли, в zVirt. Его просто редко настраивают дальше значений по умолчанию.

И почти всегда забывают про контроллер управления сервером. Заводской пароль на IPMI, iDRAC или iLO - это доступ к консоли хоста в обход всех паролей гипервизора. У Supermicro с ноября 2019 года пароль BMC уникальный, напечатан на наклейке (платы X10, X11, H11, H12 и новее), до этого был ADMIN/ADMIN. У Dell уникальный пароль iDRAC указан на выдвижной сервисной бирке, но легаси-вариант root/calvin до сих пор доступен как опция при заказе. У HPE на бирке iLO печатают случайную восьмисимвольную строку, логин Administrator. Проверьте свои - особенно на серверах старше 2019 года.

Изоляция и сегментация сети

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

Возьмём типичную для небольшой компании картину: веб-сервер, база 1С, файловое хранилище и контроллер домена - всё на одном хосте. Веб-серверу незачем ходить напрямую в файловое хранилище. Если он туда ходит, то при его компрометации шифровальщик доберётся до документов за минуты.

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

VM Escape и другие страшилки, которые иногда случаются

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

Свежий и хорошо задокументированный пример - три уязвимости VMware, закрытые в марте 2025 года. CVE-2025-22224 (оценка 9,3 по CVSS) позволяет пользователю с правами администратора внутри виртуальной машины выполнить код в процессе VMX уже на хосте. CVE-2025-22225 даёт запись в произвольную область и выход из песочницы. CVE-2025-22226 сливает содержимое памяти процесса VMX. По отдельности каждая требует условий, но в цепочке они дают полный путь: из гостевой ОС в гипервизор, оттуда в сеть управления кластером. Все три эксплуатировались до выхода патчей, а по CVE-2025-22225 американское агентство CISA подтвердило использование группами шифровальщиков.

Второй пример интереснее, потому что дыра там не в коде. CVE-2024-37085: хост ESXi, включённый в домен Active Directory, не проверяет, существует ли группа ESX Admins. По умолчанию такой группы в AD нет. Но если атакующий уже получил права в домене и создал группу с этим именем, все её участники автоматически становятся полноправными администраторами хоста. Через эту особенность работали как минимум полдесятка группировок - Storm-0506, Storm-1175, Manatee Tempest, Octo Tempest - и заканчивалось всё шифрованием виртуальных дисков целиком.

Защита от побега строится на трёх вещах. Обновления - критические патчи гипервизора ставятся быстро, а не в следующее окно обслуживания через квартал (для государственных систем это теперь и формальное требование, см. ниже). Минимальная конфигурация машин - отключённые проброс USB, общие папки, буфер обмена между гостем и хостом, лишние виртуальные устройства. И честная оценка: если гипервизор не обновлялся два года, никакие наложенные средства защиты этого не компенсируют.

Безопасна ли сама виртуальная машина

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

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

Вторая: побег из ВМ существует, что видно по CVE выше. Вероятность нарваться на такой эксплойт в случайном файле мизерная, но она не ноль.

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

Криптоджекинг - тихий вор ресурсов

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

Ищут их по аномалиям: рост загрузки CPU в нерабочее время, исходящие соединения к пулам, непонятная активность там, где её быть не должно. Если CRM внезапно потребляет 80 % процессора в три часа ночи - повод посмотреть внимательнее.

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

Практические шаги к безопасной виртуализации

Если из всего текста делать один список дел, он выглядит так. Порядок - от того, что даёт больше всего при наименьших затратах.

Первая неделя.

1. Вынести сеть управления гипервизором и BMC в отдельный VLAN без выхода в интернет. Затем проверить с внешнего адреса, что снаружи не отвечают ни панель управления гипервизором (443 и 902 у ESXi, 8006 у Proxmox VE), ни веб-интерфейс iDRAC, iLO или IPMI, ни порт 623/UDP. Проброс на них с пограничного маршрутизатора надо снять, доступ оставить через VPN.
2. Сменить заводские пароли контроллеров управления на всех серверах. Начать с тех, что старше 2019 года.
3. Включить многофакторную аутентификацию на панель управления виртуализацией.
4. Проверить, какие учётные записи имеют административные права на хосте, и удалить оставшиеся от уволившихся и от подрядчиков.
5. Для ESXi в домене - закрыть сценарий с группой ESX Admins.

Первый месяц.

6. Поставить накопившиеся патчи гипервизора. Сначала на тестовый хост, потом на продуктив по одному, с эвакуацией машин живой миграцией.
7. Развести хранилище и продуктивную сеть по разным сегментам.
8. Настроить централизованный сбор логов - события входа в панель управления, изменения конфигурации хостов, создание и удаление машин, подключение к консолям. Куда их складывать и как разбирать, разобрано в материале про мониторинг безопасности серверов.
9. Проверить схему резервного копирования на устойчивость к шифровальщику: есть ли копия вне кластера, может ли учётная запись бэкапа удалять старые копии, восстанавливались ли вы из этих копий хоть раз.
10. Убедиться, что снапшоты не используются вместо бэкапа. Это не одно и то же: снапшот не спасает при отказе хранилища.

Дальше, регулярно.

11. Шифровать данные в состоянии покоя и при передаче там, где этого требует ваш класс системы. Нагрузка на процессор от этого вырастет, при планировании ресурсов это учитывают заранее.
12. Раз в полгода проверять, кто имеет доступ и зачем.
13. Отрабатывать восстановление. Бэкап, который ни разу не разворачивали, - это гипотеза о бэкапе.

Наложенные СЗИ или сертифицированная платформа: что чем закрывается

Здесь путаница возникает чаще всего, и стоит она дорого - на этапе закупки.

Средства защиты в виртуальной среде бывают двух типов, и закрывают они совершенно разное.

Сертифицированное средство виртуализации - это сама платформа, прошедшая испытания и получившая сертификат ФСТЭК. Требования к таким продуктам заданы приказом ФСТЭК России № 187 от 27 октября 2022 года (зарегистрирован в Минюсте 22 декабря 2022 года, № 71774). Документ вводит три класса защиты - шестой, пятый и четвёртый, где четвёртый самый строгий. Каждому классу соответствует одноимённый уровень доверия: средство виртуализации 4 класса защиты должно соответствовать 4 уровню доверия, и так далее. Требования охватывают доверенную загрузку виртуальных машин, контроль целостности, регистрацию событий, управление доступом и потоками информации, а также хостовую операционную систему.

Наложенное средство защиты - это отдельный продукт, который ставится поверх чужого гипервизора и добавляет ему то, чего в нём нет. Самый известный на российском рынке - vGate от «Кода Безопасности»: работает с VMware vSphere и Microsoft Hyper-V, входит в реестр отечественного ПО, сертифицирован ФСТЭК (сертификат на vGate R2 продлён до 2030 года). Наложенные средства закрывают контроль привилегированных администраторов, мандатное разграничение доступа к виртуальным машинам, контроль целостности конфигураций и доверенную загрузку там, где платформа этого не умеет.

И ещё одно, что регулярно путают при закупках. Реестр отечественного ПО Минцифры, реестр радиоэлектронной продукции Минпромторга и сертификат ФСТЭК - три независимых вещи. Наличие продукта в реестре ПО не означает, что у него есть сертификат ФСТЭК, и наоборот. В требования тендера они попадают по отдельности, проверяются по отдельности.

Регуляторные требования - то, что нельзя игнорировать

Если вы работаете только с внутренними данными компании и никаких персональных данных не обрабатываете, этот раздел вас почти не касается. Как только появляются персональные данные, государственная информационная система или объект КИИ - появляются и формальные требования к среде виртуализации.

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

Класс средства виртуализации берётся не с потолка: он вытекает из класса или уровня защищённости вашей системы, а тот определяется при её классификации. Считать наоборот - «купим сертифицированное, разберёмся потом» - выходит дороже.

Сроки устранения уязвимостей из приказа № 117 полезны, даже если вы не госорган. 24 часа на критическую и 7 дней на высокую - разумный ориентир для любой коммерческой инфраструктуры. Если ваше окно обслуживания наступает раз в квартал, вы живёте с открытыми дырами по три месяца. Как подготовиться к проверке и что смотрят раньше всего, разобрано в материале про подготовку серверной инфраструктуры к ИБ-аудиту.

Миграция на отечественные решения: подводные камни безопасности

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

Разные модели безопасности. Права и роли в vSphere и в платформе на базе oVirt устроены по-разному. Роль, которая в vSphere была узкой, в новой платформе может оказаться широкой. Матрицу доступа надо собирать заново, а не переносить.

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

Незнание особенностей платформы. Администратор с десятилетним опытом vSphere в первые месяцы на новой системе делает ошибки уровня новичка. Это нормально и проходит, но окно уязвимости приходится на самый неудачный момент.

Разночтения в сертификатах. Тут стоит смотреть внимательно, потому что формулировки у вендоров отличаются, и проверяющий смотрит именно на них. У zVirt Max сертифицировано само средство виртуализации: сертификат ФСТЭК № 4780 от 19 февраля 2024 года, действует до 19 февраля 2029 года, 4 уровень доверия, редакция построена на РЕД ОС и допускается в КИИ первой категории, ГИС и ИСПДн. У «Альт Виртуализации» от «Базальт СПО» ситуация иная: сертифицирована операционная система «Альт СП» с правом виртуализации (сертификат № 3866), сам гипервизор отдельного сертификата средства виртуализации не имеет. У ROSA Virtualization - сертификаты № 4610 и № 4861, а версия 4.0, вышедшая 29 декабря 2025 года, добавила ГОСТ-алгоритмы в основных компонентах и встроенный аварийный переезд между площадками. Что из этого подойдёт под ваши требования, зависит от формулировки в вашем техзадании. Подробнее платформы разобраны в обзоре zVirt, ROSA и «Альт».

Отдельно про тех, кто решил остаться на VMware. После покупки Broadcom вечные лицензии отменены, бесплатный ESXi сначала свернули в 2024 году, потом вернули в 2025 как непроизводственную редакцию без поддержки, а для России продукт официально недоступен. Практический смысл для безопасности прямой: без действующей подписки вы не получаете патчи. Что происходит с продуктом дальше, разобрано в статье про виртуализацию на базе VMware.

Zero Trust в виртуальной среде: что это значит для админа

Zero Trust («нулевое доверие») - подход, при котором внутренняя сеть перестаёт считаться доверенной. Раньше периметр делил мир надвое: снаружи чужие, внутри свои. В виртуальной среде это деление рассыпается, потому что двадцать машин с разным уровнем риска сидят на одном хосте и в одной подсети.

Формулировок вокруг Zero Trust много, поэтому переведём на конкретные действия. Для виртуальной инфраструктуры подход означает четыре вещи:

• Аутентификация на каждом соединении. Одного входа в сеть мало: виртуальная машина в вашей подсети не получает доступ к базе просто потому, что она в вашей подсети.
• Явно разрешённый трафик. Правило по умолчанию - запрет; разрешается то, что нужно конкретной паре сервисов. Для небольшой компании это реализуется на уровне сегментов и правил межсетевого экрана, полноценная микросегментация нужна не всем.
• Права на время задачи. Административный доступ выдаётся под работу и отзывается после неё, а не живёт годами в учётной записи подрядчика.
• Проверка состояния, а не факта подключения. Хост с непоставленными критическими патчами не должен считаться доверенным только потому, что он ваш.

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

И последнее. Безопасность виртуальной среды - процесс, который живёт вместе с инфраструктурой. Угрозы меняются, платформы обновляются, требования переписываются - приказ № 117 заменил приказ, проработавший больше десяти лет. Настроить один раз и забыть не выйдет.

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

По теме: как спланировать ресурсы для виртуальных машин · сравнение гипервизоров 2026