К 2026 году дискуссия «уходить ли с зарубежных платформ виртуализации» закрыта — на повестке другой вопрос: как переехать без простоя и гарантированно пройти проверку регулятора. Для значимых объектов критической информационной инфраструктуры (КИИ), государственных информационных систем (ГИС) и банковского сектора ориентиром стал приказ ФСТЭК № 117, регламентирующий безопасность процессов разработки и эксплуатации информационных систем. Разберём, какие требования 117 приказ ФСТЭК предъявляет к платформе виртуализации и как закрыть их не «костылями» и наложенными средствами защиты, а архитектурой самого ядра.
Важно: материал носит обзорный характер. Перечень конкретных мер защиты и категорию значимости вашего объекта определяйте вместе со своей службой ИБ и профильным интегратором — итоговый набор требований зависит от типа системы и модели угроз.
Что такое приказ ФСТЭК № 117 и кого он касается
Требования 117 приказа ФСТЭК адресованы организациям, которые эксплуатируют информационные системы с повышенными требованиями к защите: операторам КИИ, владельцам ГИС, финансовому сектору. Чем выше категория значимости объекта, тем строже набор мер, которые нужно реализовать и документально подтвердить при аттестации.
Для платформы виртуализации это означает простую вещь: гипервизор и слой управления перестают быть «просто инфраструктурой» и сами становятся объектом проверки. Несоответствие требованиям регулятора грозит не абстрактным штрафом, а реальными последствиями — от предписаний до приостановки эксплуатации ИТ-систем. Поэтому выбор платформы сегодня — это в том числе вопрос комплаенса, а не только производительности и цены.
Безопасность в архитектурном ДНК, а не наложенными средствами
Ключевое отличие зрелой отечественной платформы от привычной схемы «западный гипервизор плюс набор наложенных СЗИ» — в том, где живёт безопасность. Когда защита реализована сторонними средствами поверх чужого ядра, каждый такой «костыль» — это отдельная точка отказа и отдельная статья в смете на аттестацию.
Наш подход обратный: платформа создаётся по стандартам жизненного цикла безопасной разработки (DevSecOps). Это автоматический статический и динамический анализ кода (SAST/DAST), регулярный поиск уязвимостей и контроль за отсутствием недокументированных возможностей. Наличие выстроенного процесса безопасной разработки — одно из ключевых ожиданий ФСТЭК при сертификации ПО для применения в ГИС и на объектах КИИ.
Гранулярная ролевая модель и графы привилегий
Классический подход «администратор имеет доступ ко всему» аудит информационной безопасности больше не проходит. В платформу интегрирована продвинутая ролевая модель доступа, позволяющая построить строгий гранулированный граф привилегий.
Например: один инженер имеет право только создавать снимки (снэпшоты), второй — исключительно распределять сетевые VLAN, третий — мониторить нагрузку без права менять конфигурации. Такое разделение полномочий снижает внутренние угрозы и риски, связанные с компрометацией учётных записей, и напрямую отвечает требованиям к разграничению доступа.
Изоляция управляющего API на уровне портов и встроенный NGFW
Самая мощная архитектурная мера защиты — глубокая изоляция управляющего интерфейса (API). Платформа оснащена встроенным межсетевым экраном нового поколения (Next-Generation Firewall), жёстко привязанным к ролевой модели.
Служебные порты API, через которые хосты общаются между собой и с панелью управления, полностью изолированы от общей корпоративной сети. Даже если злоумышленник или вредоносное ПО проникнет внутрь одной из пользовательских виртуальных машин, дотянуться до портов управления гипервизором он физически не сможет. Это резко повышает устойчивость к стандартным сетевым пентестам и горизонтальному продвижению атакующих (Lateral Movement).
Технический переезд: миграция без боли
Соответствие требованиям бессмысленно, если на платформу невозможно безопасно переехать. Главный страх администратора при миграции — вручную переносить терабайты данных, конвертировать форматы дисков сторонними утилитами и поочерёдно гасить критические сервисы. Поэтому инструменты миграции заложены прямо в логику платформы.
- Встроенный кросс-платформенный импорт. Собственные модули автоматической конвертации дисков «из коробки» забирают виртуальные машины из VMware vSphere (VMDK), Microsoft Hyper-V (VHDX), zVirt и локальных сред вроде VirtualBox. Конвертация формата и адаптация драйверов гостевой ОС происходят автоматически.
- Стратегия «матрёшки» для крупной инфраструктуры. Там, где одномоментный перенос невозможен, community-версию старой платформы можно развернуть внутри логического контура как временную гостевую среду и переносить ВМ отдел за отделом по утверждённому графику. Бизнес продолжает работать, миграция идёт планово.
Итог: зрелый Enterprise готов к требованиям регулятора
Импортозамещение виртуализации в 2026 году — это не компромисс и не откат к «серым» open-source сборкам. Когда безопасность заложена в архитектуру (безопасная разработка, гранулярная ролевая модель, изоляция API и встроенный NGFW), прохождение требований 117 приказа ФСТЭК перестаёт быть гонкой за наложенными СЗИ и становится штатным свойством платформы.
Переезд возможен, безопасен и экономически оправдан. Хотите оценить, как платформа закрывает требования регулятора в вашей конфигурации, — оставьте заявку, и мы подготовим разбор под вашу категорию значимости и модель угроз.
