С 1 марта 2026 года действует приказ ФСТЭК России от 11 апреля 2025 года №117. Он заменил приказ №17 и обновил требования к защите государственных информационных систем, а также иных информационных систем государственных органов, государственных унитарных предприятий и государственных учреждений. В апреле ФСТЭК России утвердила методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», который детализирует процессы и содержание мер защиты.
Для виртуальной инфраструктуры ключевое изменение связано с более детальной регламентацией процессов защиты. Меры применялись и раньше, но теперь подробнее описаны управление уязвимостями, обновления, доступ и другие эксплуатационные процессы. Основной акцент смещается на постоянное поддержание защищенности в течение всего жизненного цикла системы, а не только на выполнение требований к моменту аттестации.
Ниже - практический разбор без построчного пересказа нормативных документов: кого касается новая нормативная база, что изменилось по сравнению с приказом № 17, какие задачи возникают в виртуальной инфраструктуре и где в их реализации может использоваться Numa vServer.
Приказ № 117 заменил приказ ФСТЭК № 17, действовавший с 2013 года. Он устанавливает требования к защите информации некриптографическими методами, определяет организацию деятельности по защите и задает обязательные процессы, которые должны выполняться на протяжении жизненного цикла:
Отдельно учтены подрядные организации, которым передается информация, предоставляется доступ к информационным системам или поручаются работы по их созданию, эксплуатации и защите. Требования к таким работам должны быть закреплены документально. Для ИТ-проектов это важно: администрирование, сопровождение и эксплуатация могут быть переданы внешней организации, но ответственность за выполнение требований не исчезает.
Для уже действующих систем есть практический переходный момент: аттестаты соответствия, выданные до вступления приказа № 117 в силу, сохраняют действие. Однако при модернизации, изменении архитектуры и дальнейшей эксплуатации необходимо учитывать уже новые требования.
Сам приказ задает рамку: защита виртуализации и облачных вычислений предусмотрена п.63 приказа №117, а конкретные меры для этого направления определены методическим документом ФСЭК России от 12 апреля 2026 года.
Новый приказ не отменяет привычные задачи (определение класса защищенности, выбор мер, аттестацию и контроль). Основное изменение в детализации процессов и требованиях к их постоянному выполнению.
| Направление | Было | Стало |
|---|---|---|
| Область применения | Основной объект регулирования - ГИС. | Включены также иные ИС государственных органов, ИС ГУП и государственных учреждений. |
| Организация защиты | Процессы защиты были предусмотрены, но менее подробно разложены по этапам и контрольным показателям. | Приказ задает перечень постоянно выполняемых мероприятий; состояние защиты оценивается по отдельным показателям. |
| Управление уязвимостями | Конкретные сроки устранения наиболее опасных уязвимостей в приказе № 17 не устанавливались. | Для критических уязвимостей - не более 24 часов, для высокого уровня опасности - не более 7 календарных дней; для остальных сроки устанавливаются внутренними документами. |
| Обновления | Рассматривались как часть эксплуатации и поддержания защищенности. | Отдельно закреплены получение, анализ, проверка подлинности и целостности, тестирование и разрешение на установку обновлений. |
| Восстановление | Сроки восстановления задавались оператором в документации и проектных решениях. | Для классов К1, К2 и К3 установлены предельные сроки восстановления работоспособности системы. |
| Привилегированный и удаленный доступ | Регулировались общими требованиями к идентификации, аутентификации и доступу. | Требования детализированы, в том числе по усиленной и строгой аутентификации для отдельных сценариев. |
| Технические меры | Меры применялись с учетом приказа №17 и методического документа от 11.02.2024. | Состав мер актуализирован методическим документом 2026 года: уточнены отдельные позиции, появились ссылки на новые ГОСТ и современные направления защиты. |
| Новые технологические направления | В документе 2014 года часть современных технологий не выделялась отдельными направлениями. | Отдельно учитываются, в частности, защиты технологий контейнерных сред и их оркестрации, защита от атак, направленных на отказ в обслуживании, защита веб-технологий. |
Для ИТ- и ИБ-команд вывод простой: защищенность нельзя поддерживать только комплектом настроек, зафиксированных к моменту аттестации. Нужно постоянно контролировать изменения конфигурации, права доступа, уязвимости, обновления, журналы событий и возможность восстановления.
Если информационная система работает на платформе виртуализации, защита строится не только вокруг гостевых ОС. В область контроля попадают гипервизор и управляющие компоненты, виртуальные машины и их образы, хранилища, сети, учетные записи администраторов, операции миграции и резервного копирования.
Методический документ фактически задает несколько вопросов, на которые должна отвечать архитектура виртуальной среды:
| Мера | Что регулируется | Практический вопрос |
|---|---|---|
| ЗСВ.1 | Доверенная загрузка средства виртуализации и ВМ | Можно ли гарантировать, что средство виртуализации и ВМ загружаются в неизменном состоянии? |
| ЗСВ.2 | Контроль целостности | Можно ли обнаружить несанкционированные изменения ВМ, виртуального оборудования и настроек средства виртуализации? |
| ЗСВ.3 | Регистрация событий безопасности | Фиксируются ли значимые действия пользователей и изменения состояния виртуальной инфраструктуры? |
| ЗСВ.4 | Управление доступом | Кто может управлять виртуальной инфраструктурой и какие операции разрешены каждой роли? |
| ЗСВ.5 | Резервное копирование | Можно ли восстановить ВМ и конфигурацию виртуальной инфраструктуры после сбоя? |
| ЗСВ.6 | Ограничение программной среды | Контролируется ли запуск компонентов, не разрешенных для использования в среде виртуализации? |
| ЗСВ.7 | Защита памяти | Изолированы ли области памяти разных ВМ и исключена ли утечка остаточной информации? |
| ЗСВ.8 | Идентификация и аутентификация | Однозначно ли определяется пользователь до получения доступа к управлению средством виртуализации? |
| ЗСВ.9 | Управление виртуальными машинами | Контролируются ли создание, изменение и перемещение ВМ и их образов? |
Все меры защиты в полном объеме не могут быть реализованы одним продуктом: набор мер применяется к информационной системе в целом. Numa vServer закрывает ту часть требований, которая относится непосредственно к средству и среде виртуализации. Для полной реализации применимого набора мер могут потребоваться организационные процедуры и другие СЗИ, взаимодействующие с виртуальной инфраструктурой.
Для Numa vServer подготовлено сопоставление с методическим документом 2026 года. Оно охватывает защиту виртуализации, идентификацию и аутентификацию, управление доступом и регистрацию событий безопасности. В публичной документации для каждого направления приведена привязка к техническим условиям продукта.
Методический документ требует контролировать состояние среды при загрузке и в процессе работы, а также выявлять запуск компонентов, не разрешенных для использования или содержащих несанкционированные изменения.
В Numa vServer контроль целостности был предусмотрен на этапе разработки. Проверяться могут компоненты самой виртуальной инфраструктуры и отдельные компоненты виртуальных машин; при нарушении целостности для предусмотренных сценариев запуск ВМ блокируется. Платформа поставляется как единый образ и предусматривает ограничение запуска компонентов, не входящих в разрешенный состав.
Открытая документация: Numa vServer. Технические вопросы
При этом часть периодических проверок и реакций на выявленные изменения остается процедурой эксплуатации: необходимо определить периодичность контроля, ответственных и порядок реагирования.
Доступ администратора к гипервизору дает возможность менять конфигурацию ВМ, сети и хранилища, запускать миграции и удалять ресурсы. Поэтому новые требования рассматривают управление доступом в виртуальной среде отдельно от прав внутри гостевых ОС.
В Numa vServer используется ролевая модель RBAC. Пользователь получает не полный доступ к платформе, а набор разрешений, соответствующий назначенной роли. Поддерживаются внешние службы аутентификации Active Directory и FreeIPA, а также модуль PAM. Новая учетная запись не получает роль автоматически - полномочия назначаются администратором.
Открытая документация: Администрирование пользователей
На практике это позволяет разделить, например, управление пулом и операции с виртуальными машинами, ограничить права до необходимых функций и вести аудит действий пользователей. Но формирование модели доступа, определение ответственных, пересмотр полномочий и запрет совмещения несовместимых ролей остаются организационной задачей.
Нормативная база требует регистрировать события безопасности в среде виртуализации: входы пользователей, создание и удаление ВМ, запуск и остановку, изменение ролей и конфигурации, нарушения целостности, перемещение виртуальных машин и другие действия.
Numa vServer ведет журнал аудита. В нем фиксируются попытки аутентификации, операции с ВМ, изменения ролей, миграции и факты контроля целостности; записи содержат временные метки. События можно передавать по syslog во внешний контур мониторинга.
Открытая документация: Журнал аудита
Это закрывает регистрацию событий на уровне платформы, но не заменяет SIEM и процессы SOC. Централизованный сбор от разных источников, корреляция, анализ событий, хранение копий в обособленном хранилище и реагирование на инциденты должны проектироваться отдельно.
Numa vServer обеспечивает изоляцию памяти и защиту от утечки остаточной информации за счёт нескольких механизмов. Виртуальные блочные устройства (VBD) предоставляют каждой ВМ изолированный доступ к собственному образу диска (VDI) с использованием механизма copy-on-write, что предотвращает несанкционированный доступ к данным других виртуальных машин.
Для освобождения пространства после удаления снимков в Numa vServer используется механизм онлайн-слияния цепочек виртуальных дисков. В частности, online coalesce позволяет объединять данные без остановки виртуальной машины и удалять ставшие ненужными промежуточные образы. Это помогает корректно освобождать занятое пространство в процессе эксплуатации виртуальной инфраструктуры.
Открытая документация: Администрирование системы хранения
Методический документ требует обеспечить возможность восстановления виртуальной среды. На уровне платформы это означает как минимум резервное копирование выбранных образов ВМ и параметров настройки средства виртуализации.
Numa vServer предоставляет комплексную систему резервного копирования и защиты данных ВМ: платформа поддерживает моментальные снимки виртуальных машин (в том числе с памятью), полные и инкрементальные резервные копии на удалённые хранилища NFS, SMB, S3 и iSCSI (с версии NC1.4), непрерывную репликацию с дельта-копиями и сценарии аварийного восстановления между хранилищами. Все операции настраиваются через встроенный модуль резервного копирования в веб-интерфейсе Numa Collider, а для интеграции со сторонними СРК предусмотрен API резервного копирования и восстановления, что позволяет выполнять действия по резервному копированию с использованием внешних решений.
Открытая документация: Резервное копирование
В новой нормативной базе отдельно учитывается жизненный цикл ВМ: перемещение образов между хранилищами, работающих ВМ между серверами, а также контроль вывода ВМ и данных за пределы установленного сегмента или инфраструктуры.
Numa vServer поддерживает полный цикл управления перемещением виртуальных машин и данных: холодную и живую миграцию образов виртуальных дисков (VDI) между хранилищами (offline-миграция), живую миграцию исполняемых виртуальных машин между серверами виртуализации в рамках пула ресурсов. В Numa Collider также доступна тёплая миграция. Numa vServer обеспечивает контроль за перемещением ВМ через централизованное управление пулом ресурсов, где общее хранилище доступно всем серверам пула, а миграция ВМ отслеживается через объекты VBD и PBD, что позволяет контролировать выход виртуальных машин за пределы сегмента ИС или информационно-телекоммуникационной инфраструктуры. Операции перемещения и изменения состояния ВМ регистрируются в журнале аудита. Права на такие действия разграничиваются ролями.
Открытая документация: Команды управления Numa vServer
Приказ № 117 устанавливает конкретные сроки для наиболее опасных уязвимостей: критические должны быть устранены либо закрыты компенсирующими мерами не более чем за 24 часа, уязвимости высокого уровня - не более чем за 7 календарных дней. Одновременно обновления должны быть проверены до установки: оцениваются их подлинность и целостность, совместимость и влияние на систему.
Для платформы виртуализации обновление гипервизора становится частью процесса управления уязвимостями. Перед установкой нужен тестовый сценарий, понятный порядок обслуживания узлов и возможность переноса рабочих ВМ при выводе сервера из эксплуатации.
Компания НумаТех ведет мониторинг уязвимостей продукта и выпускает обновления для их устранения. Обновления распространяются из официального источника разработчика в подписанном виде, что позволяет пользователю проверить их подлинность и целостность перед установкой. Порядок установки и обслуживания узлов определяется эксплуатационным регламентом конкретной инфраструктуры.
Открытая документация: Инструкция по обновлению
Открытая документация: Пулы
| Задача | Что дает Numa vServer | Что нужно предусмотреть дополнительно |
|---|---|---|
| Контроль состояния платформы | Встроенный контроль целостности, контроль разрешенного состава ПО, реакция на нарушение в предусмотренных сценариях. | Периодичность проверок, ответственные, процедуры реагирования; отдельные усиления - организационные/внешние меры. |
| Доступ администраторов | RBAC, внешняя аутентификация через AD/FreeIPA/PAM, аудит действий. | Формальная модель доступа, пересмотр прав, разделение обязанностей; MFA/строгая аутентификация - по применимости. |
| События безопасности | Журнал аудита, временные метки, контроль целостности журнала, syslog. | SIEM, корреляция, SOC-процессы, сроки хранения и обособленное хранилище. |
| Изоляция ресурсов | Изоляция памяти ВМ, управление доступом к виртуальным ресурсам, стирание остаточной информации. | Настройки конкретной архитектуры и контроль их соответствия проекту. |
| Резервирование | Резервные копии ВМ и конфигурации, снимки, экспорт, восстановление. | RPO/RTO, политика хранения, внешнее/резервное хранилище, тесты восстановления. |
| Управление ВМ | Централизованные операции, миграция, разграничение прав, аудит. | Правила допустимого перемещения, change management, контроль экспорта. |
| Уязвимости и обновления | Средства обслуживания платформы, миграции и поузлового обновления. | Vulnerability management, тестирование обновлений, компенсирующие меры и соблюдение сроков. |
Numa vServer реализует механизмы безопасности уровня виртуализации, но приказ № 117 относится к информационной системе в целом. Поэтому платформа не заменяет остальные компоненты системы защиты.
В зависимости от класса защищенности, архитектуры и актуальных угроз отдельно могут потребоваться:
Приказ № 117 и методдокумент 2026 года делают уровень виртуализации частью системы защиты. Контролировать нужно не только гостевые ОС, но и состояние платформы, административный доступ, события безопасности, изоляцию памяти, резервные копии и жизненный цикл виртуальных машин.
Numa vServer позволяет реализовать значительную часть этих задач непосредственно на уровне платформы, так как изначально продукт был разработан с учетом требований безопасности информации. Продукт реализует собственными средствами все девять базовых мер защиты виртуальной среды, предусмотренных методическим документом ФСТЭК. Для отдельных усилений и требований, относящихся уже к информационной системе в целом, дополнительно могут потребоваться организационные меры и другие СЗИ.
Это позволяет использовать Numa vServer как основу защищенной виртуальной инфраструктуры при построении и модернизации ГИС. Официальные партнеры «НумаТех» помогут определить применимый набор требований, спроектировать архитектуру и подобрать дополнительные средства защиты там, где возможностей самой платформы недостаточно.
