Клиентоориентированная безопасность: как вендор помогает защищать виртуальную инфраструктуру
Изображение: OpenAI
В июле 2026 года найдена Januscape — уязвимость в KVM, которая около 16 лет пролежала в ядре Linux. Она позволяет атаковать сервер виртуализации прямо из гостевой виртуальной машины (ВМ). Средства защиты внутри ВМ от такой атаки не спасут: они контролируют гостевую ОС и приложения, а атака направлена на уровень ниже — на гипервизор. Уязвимость гипервизора или системы управления ставит под угрозу сразу все информационные системы, работающие на платформе.
И таких находок будет больше. Языковые модели уже находят уязвимости, которые годами оставались незамеченными, и пишут для них эксплойты — в том числе по опубликованным исправлениям. Если ещё в 2018–2019 годах от раскрытия уязвимости до её эксплуатации проходило в среднем 63 дня, в 2023-м — уже пять, то сегодня ИИ превращает опубликованное исправление в рабочий эксплойт за часы.
Поэтому обеспечение безопасности виртуальной инфраструктуры требует комплексного подхода. Недостаточно использовать наложенные средства защиты — безопасность должна закладываться в архитектуру самой платформы и поддерживаться производителем на протяжении всего её жизненного цикла. При этом платформа должна интегрироваться с существующей ИБ-инфраструктурой и учитывать практические задачи заказчика, включая обеспечение соответствия нормативным требованиям и последующую эксплуатацию защищённых информационных систем. В «Шаркс ДЦ» этот подход называют клиентоориентированной безопасностью: чем больше вопросов безопасности производитель решает на своей стороне, тем меньше рисков, трудозатрат и расходов остаётся у заказчика.
Принципы, определяющие разработку
В основе используемого нами подхода «клиентоориентированной безопасности» — семь принципов, охватывающих весь жизненный цикл платформы виртуализации: от проектирования архитектуры до сопровождения в промышленной эксплуатации.
- Secure by Design. Механизмы защиты проектируются вместе с функциями платформы и не конфликтуют её работой.
- Контроль кодовой базы. Исходный код всех компонентов, включая заимствованные, хранится у разработчика ПО, продукт собирается самостоятельно — обновления не зависят от внешних поставщиков.
- Минимизация поверхности атаки. Из сборки исключено всё, что не нужно для работы платформы виртуализации: меньше кода — меньше уязвимостей и обновлений.
- Безопасная разработка. Состав продукта фиксируется в SBOM, код проверяется анализаторами и фаззингом до выпуска.
- Непрерывное управление уязвимостями. Новые уязвимости отслеживаются ежедневно, заказчик получает оценку применимости и рекомендации.
- Ориентация на задачи заказчика. При разработке учитываются не только требования ФСТЭК России к средствам виртуализации, но и задачи, которые предстоит решать заказчику при реализации мер защиты и аттестации информационной системы.
- Интеграция с существующей ИБ-инфраструктурой. Платформа совместима с корпоративными средствами защиты, SIEM и каталогами пользователей — инвестиции заказчика в ИБ сохраняются.
Все эти принципы объединяет одна цель: сократить риски, трудозатраты и стоимость обеспечения безопасности виртуальной инфраструктуры для заказчика.
Secure by Design: безопасность начинается с архитектуры
Secure by Design — подход, при котором механизмы безопасности проектируются одновременно с основными функциями платформы. Это позволяет заранее учитывать их влияние на производительность, работу виртуальных машин, сетей и хранилищ данных, избегая конфликтов между защитными механизмами и функциональностью продукта.
Мы пошли по пути поставки системы виртуализации в виде программно-аппаратного комплекса. Решение Sharx Base представляет собой гипервизор первого типа. Платформа строится на базе минимизированного ядра Linux собственной сборки и устанавливается непосредственно на серверное оборудование, без необходимости развёртывания ОС общего назначения, баз данных и другого программного обеспечения среды функционирования. Наш проектный опыт доказывает, что когда все компоненты платформы виртуализации представляют собой единый протестированный стек, без «серых зон» на стыках между аппаратной платформой, хостовой ОС, гипервизором, подсистемой управления и встроенными механизмами защиты, то заказчик получает одного ответственного вместо нескольких вендоров, один согласованный канал обновлений и меньше компонентов, которые нужно учитывать при аттестации. Это снимает нагрузку с ИТ-отдела конечного пользователя инфраструктурой.
Когда при сборке ядра задействуются встроенные механизмы защиты, а неиспользуемые функции и модули отключаются, то это позволяет контролировать конфигурацию системных компонентов, сокращать поверхность атаки и оценивать влияние защитных механизмов на функциональность платформы ещё на этапе разработки.
Таким образом, заказчик получает готовую к эксплуатации платформу с интегрированными механизмами безопасности уровня ядра, что сокращает объём работ по харденингу и вводу платформы в эксплуатацию.
Контроль кодовой базы и безопасная разработка
Любая современная платформа виртуализации представляет собой комплекс, включающий как собственный код производителя, так и множество заимствованных компонентов и их зависимостей. Использование таких компонентов существенно ускоряет разработку, но создаёт дополнительные риски, связанные как с наличием уязвимостей, так и с безопасностью цепочки поставок программного обеспечения. К ним относятся атаки на цепочку поставок ПО (Supply Chain Attacks), политически мотивированные вредоносные изменения (protestware), а также санкционные ограничения, способные привести к прекращению поддержки или недоступности обновлений.
Для снижения этих рисков вендор должен хранить в своих репозиториях полный исходный код собственных и заимствованных компонентов (включая зависимости) и самостоятельно собирать программный продукт. Это позволяет контролировать состав продукта, исключать избыточную функциональность и при необходимости самостоятельно вносить исправления.
Контроль кодовой базы дополняют практики безопасной разработки: проверки безопасности переносятся на ранние этапы создания ПО (подход Shift Left). Это позволяет выявлять и устранять уязвимости до релиза, когда их исправление требует меньше времени и ресурсов. Для контроля состава формируется перечень программных компонентов (SBOM), содержащий информацию об используемых библиотеках, их версиях и зависимостях. На его основе проводится анализ известных уязвимостей, в том числе в транзитивных зависимостях.
Для выявления ошибок в программном коде применяются статический и динамический анализ, а также фаззинг — автоматизированное тестирование с использованием разнообразных, в том числе некорректных, входных данных.
Эти меры снижают вероятность попадания уязвимостей в готовый продукт, однако не гарантируют их полного отсутствия. Поэтому контроль безопасности должен продолжаться на протяжении всего жизненного цикла платформы виртуализации, включая период её промышленной эксплуатации.
Непрерывное управление уязвимостями
Одна из важнейших задач производителя, заинтересованного в безопасности своего ПО — своевременно выявлять новые угрозы и оперативно реагировать на обнаруженные уязвимости. Отсутствие известных уязвимостей на момент выпуска продукта не означает, что их нет в коде. Даже широко используемые и многократно проверенные программные компоненты могут годами содержать критические ошибки.
Показательный пример — Januscape (CVE-2026-53359), о которой шла речь в начале статьи. При определённых условиях, в том числе при вложенной виртуализации, она позволяла из гостевой ВМ нарушать работу ядра хоста, а исследователь сообщал и об эксплойте, дающем права суперпользователя на хосте.
Ещё один пример —XSA-523 (CVE-2026-102703 и CVE-2026-102704), уязвимости гипервизора Xen, найденные ИИ в ноябре 2026 года. Они позволяют атакующему из гостевой виртуальной машины читать и изменять память других виртуальных машин, включая управляющий домен хоста. Ошибки появились после изменения кода механизма Grant Copy в январе 2015 года и оставались незамеченными более 11 лет.
И это не только теоретические угрозы. В октябре 2026 года злоумышленники использовали уязвимость популярной системы управления виртуализацией для атак на хостинг-провайдеров. У одного из них атакующие получили административный доступ к системе управления и запустили на узлах виртуализации программу, которая подключала диски клиентских виртуальных машин и копировала интересующие злоумышленников файлы, включая пароли, ключи доступа и конфигурационные данные. При этом вся активность происходила на уровне хоста, без запуска вредоносного ПО внутри гостевых операционных систем, поэтому средства защиты в них не могли её увидеть.
Эти примеры демонстрируют масштаб потенциальных последствий компрометации инфраструктурного ПО и необходимость постоянного контроля его безопасности даже после выпуска продукта.
Мы в «Шаркс ДЦ» ежедневно анализируем информацию о новых уязвимостях компонентов Sharx Base, включая заимствованное ПО и его зависимости. Для этого разработан специальный регламент: при обнаружении потенциальной угрозы специалисты проверяют применимость уязвимости к используемой версии и возможность её эксплуатации в конкретной конфигурации продукта. Это важно для специализированной программной среды: уязвимость компонента может оказаться неприменимой, если уязвимая функция исключена при сборке или недоступна для эксплуатации. По результатам анализа заказчикам предлагаются программные исправления, рекомендации по настройке механизмов защиты или временные компенсирующие меры. Такой подход позволяет сократить время между обнаружением уязвимости и принятием мер защиты, снижая риск инцидентов и нагрузку на специалистов по ИБ эксплуатирующих организаций.
От сертификации продукта к аттестации информационной системы
Многие системы виртуализации, включая нашу, сертифицированы ФСТЭК России и включены в реестр российского ПО. Однако для организаций, которые эксплуатируют государственные информационные системы, информационные системы персональных данных или объекты КИИ, сертифицированное ПО — лишь одна из составляющих обеспечения соответствия. Сертификат на продукт не освобождает оператора от обязанности выполнять требования безопасности на уровне всей информационной системы, а в предусмотренных случаях — проходить её аттестацию.
Использование накопленного опыта построения комплексных информационных систем, в том числе предназначенных для последующей аттестации, позволяет предусмотреть механизмы, необходимые не только для сертификации продукта, но и для реализации требуемых при аттестации мер защиты в инфраструктуре заказчика.
Интеграция в существующую инфраструктуру ИБ
Клиентоориентированность также предполагает сохранение инвестиций заказчика в уже используемые средства защиты и сложившиеся процессы управления ИБ.
Для этого имеет смысл предусмотреть интеграцию с уже имеющимися у заказчика корпоративными решениями, в том числе Kaspersky Security для виртуальных сред Легкий агент. Поддержка Syslog обеспечивает передачу событий в корпоративные системы мониторинга и SIEM, а интеграция с LDAP позволяет использовать существующие каталоги пользователей и механизмы централизованной аутентификации.
В результате заказчику не потребуется полностью перестраивать действующую систему защиты при переходе на новую платформу виртуализации. Наличие встроенных механизмов дополняет используемые средства ИБ, образуя эшелонированную защиту виртуальной инфраструктуры.
Безопасность как ответственность производителя
Таким образом, клиентоориентированная безопасность — это не обещание программного продукта без уязвимостей, а системный подход к управлению рисками на протяжении всего его жизненного цикла.
Применение вендором клиентоориентированной безопасности позволяет решать задачи ещё на этапе разработки платформы, поддерживать её защищённость после выпуска и учитывает требования, с которыми заказчики сталкиваются при построении и эксплуатации информационных систем, когда эксплойт может появиться через несколько часов после исправления. Именно работа на стороне производителя определяет: успеет ли заказчик защититься.
