Привет! Я Саша Епихин, CTO zVirt. В прошлой моей статье речь шла о том, как oVirt стала самым зрелым Open Source ПО для виртуализации и о том, почему мы в Orion soft выбрали разработку на базе этого решения, а не пошли другим путем. Я упоминал, что мы давно ушли от модели форка: oVirt — это только проверенное ядро, а всю дополнительную функциональность мы разрабатываем «поверх» него сами. Можно сказать, мы не просто натянули новые обои, а сделали капитальную пристройку с ремонтом. Это позволяет и получать обновления сообщества, и отправлять в него багфиксы, и развивать свое комьюнити.

Важно понимать контекст: в 2024 году oVirt официально осталась без поддержки разработчика Red Hat, который перестал выпускать для нее обновления безопасности. Любой продукт, оставшийся без техподдержки, опасен для бизнеса. Но zVirt — это не просто локализованная версия oVirt. Это эволюция платформы, которая не только добавляет новые функции, но и решает проблемы безопасности и стабильности исходного кода.

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

О том, как именно мы составили методику для приоритизации разработки фич, можно говорить отдельно, я планирую рассказать об этом в одной из следующих статей. А пока начну рассказ о том, что именно мы сделали такого, чего нет в oVirt. В разработке zVirt мы внутри команды определили три основных трека развития: стабильность, безопасность, простота. И еще одно направление, не всегда напрямую связанное с разработкой, но неизбежное — глубокие интеграции с продуктами производителей смежного с виртуализацией ПО и железа. Логика простая: например, если заказчик привык пользоваться связкой виртуализация VMware + бэкап Veem, то ему надо обеспечить альтернативу всей связки, работу продуктов друг с другом. И так не только с бэкапом. 

В этой статье я начну с доработок по стабильности и безопасности.

Стабильность

Мы улучшаем стабильность в каждом релизе. Например, исправили дефект работы с ошибочным переводом хостов виртуализации в статус Non-Operational и присвоением статуса «Недоступен» домену хранения. Реализовали удаление устаревших LUN на хостах. Исправили проблему пустого или неполного списка при импорте доменов хранения, которая возникала в случае, когда открепляется и прикрепляется много доменов хранения. Это, конечно, не самые масштабные доработки, о них ниже.

Переход на ядро ИСП РАН

В oVirt используется ядро Linux 4.18. До мая 2024 года Red Hat бэкпортил исправления уязвимостей из ядра 4.19, у которого, в свою очередь, закончилась поддержка в декабре 2024 года. В zVirt мы используем отечественное ядро 6.1, поддерживаемое технологическим центром исследования безопасности ядра Linux (НИИ ИСП РАН). Это ведущий российский научно-исследовательский центр. Ядро ИСП РАН базируется на проверенной основе стандартного ядра Linux и проходит тщательное тестирование. Это актуальное ядро обеспечивает более высокий уровень безопасности и производительности системы.

Поддержка отечественных ОС

Очевидно, что oVirt не поддерживает отечественные ОС. Для российской же виртуализации это обязательное условие зрелости. zVirt сейчас поддерживает Astra Linux, Alt Linux, РЕД ОС, РОСА, МСВСфера, ОСнова. Полный список можно увидеть в нашей матрице совместимости.

Инструмент «Кластеры хранилищ»

Этой функциональности нет в oVirt, она есть в VMware и известна как Storage DRS. Она предназначена для того, чтобы предотвратить переполнение доменов хранения. Наши «Кластеры хранилищ» — это ее аналог. На основе собранных данных о доступном пространстве балансировщик создает рекомендации по переносу дисков между доменами хранения для перераспределения загруженности. 

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

SDS

Мы какое-то время думали, какое решение можно взять как основу для гиперконвергентного решения для небольших инсталляций от 3 до 10 хостов. В первую очередь смотрели на Ceph и Gluster как решения, наиболее часто встречающиеся в продуктовых средах. Но тесты и опыт эксплуатации показали, что они недостаточно быстрые. Ceph — более стабильный, но при этом более сложный в эксплуатации и требующий минимум 4 хоста, а лучше 6. Gluster — более простой в настройке и эксплуатации, чуть быстрее при определенных нагрузках, но имеющий известные проблемы со стабильностью.

Мы посмотрели на эти проблемы и поняли, что исправить их не так уж и сложно. В итоге Gluster в oVirt есть, но мы не рекомендуем его использовать, так как в нем сохранились проблемы. Например, когда перезагружаются 2 из 3 хостов, то оставшийся работает некорректно. Он держит связь с соседями, но не с собой. Из-за этого постоянно возникают файлы, требующие heal.

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

Также была исправлена ошибка некорректного подсчета актуального занятого места на диске, которая выражалась в том, что размер qcow (тонких дисков) показывался в разы больше, чем был на самом деле.

Инструменты для обеспечения катастрофоустойчивости

Наш блок дополнительной функциональности по катастрофоустойчивости включает репликацию на уровне гипервизора, автоматизацию планов восстановления (DR-планы), управление репликацией на уровне СХД. 

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

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

Сейчас поддерживается 2 СХД — Yadro Tatlin Unified и Huawei Dorado, но мы сделали универсальный модуль, который можно интегрировать с любой СХД, где есть репликация. Архитектуру этого модуля и процесс его настройки мы показывали в отдельной статье. 

Безопасность

Безопасная разработка как процесс

В 2022 году безопасность стала одним из главных драйверов развития zVirt. Уже тогда, до выхода нового ГОСТ по безопасной разработке, мы поняли, как двигаться в эту сторону, и перенесли нашу сборку в локальные репозитории, чтобы никак не зависеть от Open Source компонентов и вообще наличия интернета. Мы ввели обязательный статический и динамический анализ кода в пайплайнах, добавили регулярные сканирования на уязвимости. В соответствии с результатами сканирований мы делаем исправления в коде и конфигурациях. 

Чтобы упростить процесс аудита безопасности и соответствовать корпоративным стандартам ИБ, нормативным требованиям и требованиям регуляторов, мы также используем Software Bill of Materials (SBOM). Это подробный список всех программных компонентов, которые используются в разработке zVirt, с указанием их версий и типов лицензий. Он позволяет нам следить за безопасностью на уровне всей цепочки поставок. Если в каком-то из Open Source компонентов найдут уязвимость, мы увидим это, сможем отследить, насколько она опасна для продукта, и принять решение по замене компонента.

Сертифицированная версия

Существует редакция zVirt Max, сертифицированная ФСТЭК (сертификат № 4780 от 19 февраля 2024 года), которая подходит для КИИ и других проектов, требующих соблюдения требований регуляторов. 

Наличие сертификата ФСТЭК гарантирует применение в продукте принципов безопасной разработки: весь исходный код хранится и поддерживается Orion soft, компоненты проходят статический анализ, реализованы все функциональные меры по обеспечению безопасности в соответствии с требованиями ФСТЭК, компоненты поверхности атаки проходят динамический анализ и фаззинг-тестирование, проводится регулярный поиск уязвимостей.

Системные компоненты

Ключевые системные компоненты виртуализации — libvirt, qemu, openssh, libvirt, python, java, glibc, kernel и многие другие — устаревают. В zVirt мы обновляем их, обеспечиваем совместимость и вносим патчи. То же происходит и с Менеджером управления. Мы разбиваем его на подкомпоненты и независимо от oVirt обеспечиваем их обновление. Например, мы самостоятельно обновляем postgresql, java, keycloak.

Сборочный процесс

Весь пайплайн сборки zVirt происходит в изолированном контуре без доступа в сеть. Это гарантирует, что в исходный код не попадают бэкдоры и недекларированные возможности, нарушающие безопасность конечного продукта.

Чтобы избежать возникновения уязвимостей, мы выстроили процесс работы с безопасностью на основе best practices DevSecOps: на этапе разработки коммиты проверяются статическими анализаторами SVACE и SonarQube, что исключает ошибки в коде; постоянный аудит через SCA-анализ обеспечивает полную прозрачность и позволяет мгновенно реагировать на уязвимости в сторонних библиотеках.

Ключевое преимущество нашей платформы — это полный цикл поддержки с гарантией своевременного устранения угроз. Мы регулярно мониторим критические компоненты системы и закрываем уязвимости в каждом релизе. За последние три года мы выпустили 4 патча по информационной безопасности для zVirt.

Профили безопасности под требования регуляторов и регламентов заказчиков

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

Шифрование паролей системных учетных записей

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

Начиная с версии 4.0, в zVirt реализовано шифрование данных. Все пароли хранятся в конфигурационных файлах в зашифрованном виде.

Расширенное логирование действий пользователей

Мы внедрили расширенное логирование, которое фиксирует не только действия пользователей, но и их контекст — кто, что, когда и с какими параметрами сделал. Это повышает безопасность, упрощает расследование инцидентов и позволяет легко интегрировать логи в сторонние SIEM-системы.

Многофакторная аутентификация и интеграция с Keycloak

Keycloak в oVirt не работает, так как прикручен только к UI. Пользователь не может попасть в портал администрирования во время развертывания или воспользоваться штатной функциональностью смены FQDN Менеджера управления. 

Keycloak также не работает через REST API, c Grafana и в других местах, про это честно пишут в заметках к oVirt. Более того, он сделан как плагин к WildFly, а сам Keycloak, начиная с 19 версии, перестал поддерживать такой режим работы. В oVirt используется и вовсе 15 версия, в ней нет многих нужных фич.

В zVirt для интеграции с Keycloak мы сделали следующее:

• Выпилили Keycloak из WildFly и сделали отдельным сервисом, тем самым перейдя на свежую 26 версию;

• Починили Keycloak везде, где нашли проблемы. В zVirt работает REST API, Grafana и внешние утилиты. Также исправлены баги, которые были в самом UI;

• Добавили функциональность для повышения уровня ИБ — вывод информации о количестве неуспешных попыток логина, блокировка неактивных пользователей, выпилили «недружественные» социальные сети, поддержали отечественные MFA. А также русифицировали и стилизовали под zVirt.

SDN c микросегментацией

SDN как технология на самом деле примерно на 70% про ИБ. Она сильно повышает прозрачность работы с политиками доступа. Когда нужно провести какую-то массовую операцию, например, раздать или отозвать доступы, все можно сделать с одной консоли, а не заходить на разное оборудование. Логирование всех действий, которые совершались в рамках SDN, тоже сосредоточено в одном месте.

В zVirt отказоустойчивый SDN с управлением из портала администрирования и публичным API включает в себя микросегментацию, зеркалирование, безопасность порта и групповое управление коммутаторами.

Мы базируемся на тандеме OVN/OVS. OVN мы используем как базовое решение для SDN, а непосредственные вычисления на местах выполняют инстансы OVS. Формально все ВМ, развернутые в SDN, подключаются к OVS на хосте виртуализации, на одном хосте один switch. И уже внутри OVS заказчик получает разграничения, логические сети, трансляцию адресов, микросегментацию и так далее.

Подробнее про наш подход к SDN можно прочитать в статьях Механизм, а не политика: как мы внедряли SDN в нашу систему, и От идеи до продакшена: как мы строили SDN-слой для zVirt из которых видно, что SDN в zVirt — это мощный и удобный инструмент для решения широкого спектра задач сетевого управления, подобного в oVirt нет.

Харденинг вместе с нашим партнером Positive Technologies

В партнерстве с Positive Technologies мы разработали харденинг для минимизации рисков хакерских атак, в котором описано, как усилить защищенность системы виртуализации zVirt на примере типовой установки.

По сути, это руководство по изменению настроек zVirt таким образом, чтобы создать максимальное количество препятствий для взломщиков. 

Можно банально установить последние обновления zVirt, настроить многофакторную аутентификацию, усилить парольную политику для учетных записей. Но не все и всегда задумываются, например, что стоит ограничить длительность сессии SSH до гипервизора или сервера управления виртуализацией до бездействия пользователя, или выделить для работы ВМ с HostedEngine отдельный кластер и отдельный LUN или диск СХД, доступный только на гипервизорах этого кластера. В руководстве мы рассказываем, как сделать все это и не только.

Эксперты Positive Technologies выявили более 140 техник, которые хакеры могут применить в атаках на типовую инсталляцию zVirt 4.2, и разработали 17 защитных мер. C полным руководством можно познакомиться на сайте коллег.

Bug Bounty

В ноябре 2024 года мы вышли на платформу StandOff Bug Bounty от Positive Technologies и начали тестировать на ней zVirt. Пока что тестирование проходит в закрытом контуре, но уже есть первые результаты.

В фокусе тестирования были уязвимости, позволяющие злоумышленникам:

• Получить права root или повысить учетную запись простого пользователя до прав уровня root или других привилегированных групп пользователей на виртуальных машинах и хостах;

• Получить доступ к хостам zVirt Node либо к менеджеру управления виртуализацией Hosted Engine, обладая изначально только учетной записью postech на jump_vm.

Мы разделили потенциальные уязвимости на четыре уровня:

• Критический — удаленное исполнение кода (RCE), полное получение root-доступа, обход аутентификации администратора, манипуляции с виртуальными машинами;

• Высокий — проблемы контроля доступа, локальные привилегированные команды, доступ к конфиденциальным данным через уязвимости бизнес-логики; 

• Средний — IDOR (несанкционированный доступ к данным), XSS в админ-интерфейсе;

• Низкий — прочие XSS, CSRF, деградация функциональности. 

С ноября 2024 года было сдано 24 отчета об уязвимостях, 10 из них было принято. Среди обнаруженных уязвимостей не было критических и были только две высокого уровня. На данный момент мы уже исправили такие уязвимости, как Self-XSS, Open Redirect в параметре redirect_uri, Blind XSS, доступ к чтению информации о внутреннем устройстве хостов для обычного пользователя без привилегий, blind-SSRF + подмена хоста бэкапов через IDOR. Сейчас идет работа над оставшимися.

zVirt обеспечивает безопасность на уровне цепочки поставок (Software Supply Chain). Все дистрибутивные пакеты (RPM) подписываются нашей собственной подписью. Также используются свои доверенные репозитории. Это дает гарантию подлинности, защиту от несанкционированного обновления, а также является признаком зрелости продукта.

Еще подробнее все доработки, процессы и технологии в части безопасности мы разбирали в отдельной статье. В этом направлении мы уходим от oVirt особенно заметно, так как безопасность критична для заказчиков и в связи с требованиями регуляторов, и в связи со скорым end of life VMware vSphere версии 7.0, после которого виртуализация останется без обновлений. 

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