Пункт 6.2 приложения 3 к ПТКЗИ: защита виртуальной инфраструктуры от НСД и сетевых атак

Смысл требования

Пункт 6.2 приложения 3 к ПТКЗИ – практический разбор требования «защита виртуальной инфраструктуры». Пункт 6.2 относится к защите виртуальной инфраструктуры как самостоятельного слоя информационной системы. Его смысл состоит в том, что гипервизоры, управляющие серверы, виртуальные сети, хранилища, консоли управления, виртуальные машины и сервисные компоненты виртуализации должны быть защищены от несанкционированного доступа и сетевых атак не только со стороны внешней физической сети, но и со стороны самой виртуальной среды.

Практически это требование закрывает риск, который часто недооценивают. Виртуализация создаёт дополнительную плоскость атаки: администраторская консоль гипервизора, API управления, vSwitch, port group, виртуальные маршрутизаторы, виртуальные межсетевые экраны, интерфейсы миграции, backup-сеть, management-сеть и взаимодействие между виртуальными машинами. Если эти элементы защищены слабо, атакующий может получить доступ не к одной виртуальной машине, а к инфраструктуре, на которой работает вся ИС.

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Дополнительные требования по обеспечению защиты информации в виртуальной инфраструктуре», пункт 6.2: «обеспечение защиты виртуальной инфраструктуры от несанкционированного доступа и сетевых атак из виртуальной и (или) физической сети, а также виртуальных машин».

Обязательность применения

По таблице приложения 3 требование пункта 6.2 является рекомендуемым для классов 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп и обязательным для классов 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Как и другие требования раздела 6, оно применяется при наличии виртуальной инфраструктуры как технологии. Если ИС не использует виртуализацию, контейнеризацию, виртуальные сети или размещение на IaaS-платформе, это должно быть корректно отражено при определении применимости требований.

Если ИС размещена на VMware, Hyper-V, KVM, Proxmox, OpenStack, Kubernetes, облачной IaaS-платформе или иной виртуализированной среде, требование нужно рассматривать обязательно для классов 3-* и как значимую рекомендованную меру для классов 4-*. Отказ от реализации при наличии виртуальной инфраструктуры должен быть не устным, а обоснованным в проектной документации, особенно если управляющие интерфейсы виртуализации доступны из сети или если несколько систем используют общий виртуальный контур.

Практическая трактовка требования

Пункт 6.2 требует защищать виртуальную инфраструктуру как отдельный слой ИС. Установка антивируса внутри гостевых ОС либо межсетевой экран на внешнем периметре не охватывают гипервизоры, управляющие серверы, API, виртуальные коммутаторы, сети хранения, резервного копирования и миграции.

Формулировка прямо учитывает атаки из виртуальной и физической сети, а также воздействие со стороны виртуальных машин. Поэтому модель защиты должна охватывать как north-south-трафик, так и внутренние east-west-связи. Скомпрометированная ВМ не должна иметь доступ к management-сети, интерфейсам хранения, аппаратному управлению или другим ВМ только потому, что находится в том же кластере.

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

Что входит в виртуальную инфраструктуру для целей пункта 6.2

Для правильной реализации сначала нужно определить состав виртуальной инфраструктуры. Если этот состав не описан, невозможно обоснованно показать, что защита от НСД и сетевых атак действительно охватывает нужные компоненты.

• Гипервизоры. Физические хосты виртуализации, на которых выполняются виртуальные машины и сервисные компоненты ИС.
• Серверы управления виртуализацией. vCenter, SCVMM, Proxmox management, OpenStack control plane, Kubernetes control plane и аналогичные управляющие компоненты.
• Виртуальные сети. vSwitch, distributed switch, port groups, VLAN, VXLAN, overlay-сети, виртуальные маршрутизаторы и виртуальные межсетевые экраны.
• Сети управления. Management-сегменты гипервизоров, управляющих серверов, IPMI/iDRAC/iLO, backup-сетей, storage-сетей, миграции и кластерного взаимодействия.
• Системы хранения. SAN, NAS, vSAN, Ceph, iSCSI, NFS, объектные хранилища и другие компоненты, на которых размещены виртуальные диски и данные ИС.
• Виртуальные машины. Гостевые ОС, серверы приложений, базы данных, сервисные ВМ, ВМ СЗИ, jump-host, прокси, шлюзы, контроллеры домена и иные компоненты.
• Образы, шаблоны и снапшоты. Шаблоны ВМ, ISO-образы, snapshots, клоны и репозитории, через которые может распространяться небезопасная конфигурация или вредоносный код.
• API и средства автоматизации. Интерфейсы управления, скрипты, IaC, orchestration-инструменты и сервисные учётные записи, через которые можно изменить виртуальную инфраструктуру.

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

Какие угрозы следует учитывать

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

• Доступ к управляющей консоли. Компрометация учётной записи администратора или доступ к web-консоли управления виртуализацией может дать контроль над виртуальными машинами, сетями и хранилищем.
• Атака из гостевой ВМ. Скомпрометированная виртуальная машина может использоваться для сканирования соседних ВМ, атак на внутренние сервисы и попыток доступа к управляющей сети.
• Ошибочная сетевая связность. ВМ из пользовательского, тестового или DMZ-сегмента может иметь лишний доступ к management-сети, backup-сети, storage-сети или другим чувствительным сегментам.
• Атаки на east-west-трафик. Внутреннее взаимодействие между ВМ часто контролируется слабее, чем входящий трафик с внешнего периметра, хотя именно там может происходить горизонтальное перемещение.
• Подмена или изменение виртуальных сетевых настроек. Ошибочные port group, VLAN, security group, маршруты или правила виртуального firewall могут открыть доступ между сегментами.
• Доступ к хранилищу виртуальных дисков. Несанкционированный доступ к datastore, backup repository или snapshots может привести к копированию, изменению или удалению виртуальных машин.
• Компрометация сервисных учётных записей. Backup, monitoring, orchestration и automation-учётные записи часто имеют широкие права и используются без достаточного контроля.
• Атаки на API управления. API виртуализации и облачной платформы может использоваться для создания ВМ, изменения сети, подключения дисков, выгрузки образов и обхода ручных процедур.

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

Что следует подтвердить при проверке

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

• отражены ли компоненты виртуальной инфраструктуры на структурной и логической схемах ИС;
• определены ли управляющие, пользовательские, серверные, DMZ, storage, backup и migration-сегменты;
• изолирована ли сеть управления виртуальной инфраструктурой от обычной сети передачи данных;
• ограничен ли доступ к гипервизорам, управляющим серверам, API и web-консолям только уполномоченным администраторам;
• используются ли индивидуальные учётные записи, роли, MFA или иные меры усиления для административного доступа;
• есть ли межсетевое экранирование или микросегментация между виртуальными машинами и сегментами;
• контролируются ли сетевые потоки из виртуальных машин к управляющим компонентам, СЗИ, хранилищу и сервисным сетям;
• ведётся ли журналирование административных действий в платформе виртуализации и событий сетевого доступа;
• защищены ли сервисные учётные записи backup, monitoring, orchestration и автоматизации;
• можно ли показать фактические настройки сетей, VLAN, port groups, security groups, firewall rules, ACL, RBAC, журналов и политик доступа.

Слабая реализация – когда management-интерфейсы гипервизоров доступны из общей пользовательской сети, виртуальные машины разных зон находятся в одной плоской L2-сети, доступ между ВМ никак не фильтруется, а действия администраторов в платформе виртуализации не журналируются и не контролируются.

Варианты реализации

Организационный вариант.

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

Сегментация управляющей сети.

Управляющие интерфейсы гипервизоров, vCenter, SCVMM, Proxmox, OpenStack, Kubernetes control plane, storage, backup и аппаратных средств управления должны быть вынесены в отдельные сегменты. Доступ к ним должен предоставляться только с административных рабочих мест, jump-host или защищённых каналов. Это базовая мера для предотвращения НСД из пользовательской и прикладной сети.

Фильтрация и микросегментация east-west-трафика.

Внутренний трафик между виртуальными машинами и сегментами должен контролироваться не хуже, чем внешний периметр. Для этого применяются виртуальные межсетевые экраны, distributed firewall, security groups, network policies, ACL, VLAN, VXLAN и иные механизмы. Цель – не допустить свободного горизонтального перемещения между ВМ и зонами.

Контроль административного доступа.

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

Комбинированный вариант.

Наиболее устойчивый подход. Владелец ИС документально определяет модель управления виртуальной инфраструктурой, технически изолирует управляющие сети, фильтрует east-west-трафик, ограничивает доступ к API и консолям, защищает сервисные учётные записи, ведёт журналирование и контролирует изменения. Для ИС классов 3-* при наличии виртуализации именно такая модель выглядит наиболее обоснованной.

Что целесообразно закрепить в ТЗ, ЛПА и ОРД

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

• перечень гипервизоров, управляющих серверов, виртуальных сетей, хранилищ и сервисных компонентов;
• сегменты management, storage, backup, migration, server, DMZ и иные используемые зоны;
• порядок доступа к консолям, API и аппаратным интерфейсам управления;
• роли администраторов и правила использования сервисных учётных записей;
• правила фильтрации east-west- и north-south-трафика;
• порядок создания и изменения виртуальных сетей, правил и подключений ВМ;
• журналирование, мониторинг и реагирование на НСД и сетевые атаки.

При размещении у провайдера требования, реализуемые в его аттестованной системе, должны быть определены в ТЗ и договоре по пункту 15 Положения. Формулировка «за безопасность отвечает облако» без перечня мер и доказательств недостаточна.

Возможность технической реализации и инструменты

Реализация строится на механизмах платформы виртуализации и сетевой инфраструктуры. Выбор продукта вторичен; проверяется фактическая изоляция и невозможность несанкционированного доступа.

• Изолированная сеть управления. Доступ к гипервизорам, управляющим серверам, storage, backup и аппаратным интерфейсам предоставляется только с административных узлов или через bastion.
• Ролевое управление. Индивидуальные учётные записи, минимальные полномочия, отдельные роли для виртуализации, сети, хранения и аудита.
• Фильтрация внутренних потоков. VLAN, ACL, security groups, виртуальные межсетевые экраны или микросегментация по разрешённым информационным потокам.
• Защита API и автоматизации. Ограничение сетевой доступности, сервисных учётных записей, секретов и журналирование операций.
• Контроль конфигурации и событий. Централизованные журналы, оповещение о входах, изменении виртуальных сетей, ролей и политик.

Решение должно учитывать не только ВМ прикладной системы, но и сервисные компоненты, через которые можно управлять всей виртуальной средой.

Типичные ошибки при реализации

• management-интерфейсы гипервизоров доступны из пользовательской или серверной сети без ограничений;
• виртуальные машины разных зон находятся в одной плоской сети без фильтрации;
• east-west-трафик между ВМ не контролируется, хотя внешний периметр защищён межсетевым экраном;
• администраторы используют общие учётные записи для доступа к платформе виртуализации;
• API управления виртуализацией доступен из лишних сегментов и не журналируется;
• backup, storage и migration-сети не отделены от обычной сети передачи данных;
• сервисные учётные записи виртуализации имеют избыточные права и не пересматриваются;
• создание port groups, VLAN, security groups и firewall rules выполняется без согласования и контроля изменений;
• журналы гипервизора и управляющей платформы не передаются в централизованное хранилище;
• защита реализована только внутри ВМ, но не на уровне виртуальной инфраструктуры;
• при размещении у провайдера отсутствует описание разделения ответственности за защиту виртуальной инфраструктуры.

Вывод

Пункт 6.2 следует рассматривать как требование к защите управляющего и сетевого слоя виртуализации. Его нельзя закрыть только настройками внутри гостевых ОС или обычным периметровым межсетевым экраном. Виртуальная инфраструктура имеет собственные риски: доступ к гипервизору, управляющей консоли, API, виртуальным сетям, хранилищу, snapshots и взаимодействию между ВМ.

Для небольшой виртуальной среды достаточно изолировать management-сеть, ограничить административный доступ, включить встроенный firewall, контролировать VLAN и вести журналы действий. Для ИС классов 3-* и сложных виртуальных платформ нужна более зрелая модель: микросегментация, фильтрация east-west-трафика, защита API, PAM, централизованное журналирование, контроль сервисных учётных записей и регулярная сверка сетевой конфигурации с утверждённой схемой. Требование считается исполненным тогда, когда владелец ИС способен доказать, что виртуальная инфраструктура защищена от НСД и сетевых атак не только извне, но и из самой виртуальной среды.

Связанные материалы

• Защита ресурсов виртуальной инфраструктуры
• Безопасное перемещение виртуальных машин
• Изменение реквизитов доступа по умолчанию

Нормативная основа

• Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 – приложение 3, пункт 6.2; пункт 11 о структурной и логической схемах; пункт 12 о ТЗ; пункт 15 о размещении на базе аттестованной ИС другого собственника. Официальный текст