Пункт 6.3 приложения 3 к ПТКЗИ: безопасное перемещение виртуальных машин

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

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

Виртуальная машина – это не просто файл на хранилище. Обычно она включает конфигурацию, виртуальные диски, сетевые интерфейсы, snapshots, состояние памяти при live migration, привязки к хранилищу, правила резервного копирования, политики безопасности и сетевую принадлежность. При её перемещении фактически перемещается часть информационной системы и обрабатываемая на ней информация. Поэтому такая операция должна выполняться по установленному порядку и с учётом требований защиты информации.

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

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

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

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

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

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

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

Требование относится именно к виртуальным машинам и обрабатываемой на них информации. Контейнеры, оркестрация workloads и другие переносимые объекты могут создавать сходные риски и должны учитываться в общей модели защиты, но их нельзя автоматически выдавать за буквальное выполнение пункта 6.3.

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

Что именно нужно защищать при перемещении

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

• Виртуальные диски. Содержат операционную систему, приложение, базы данных, файлы, временные данные, журналы и иные информационные ресурсы ИС.
• Конфигурация виртуальной машины. Включает параметры CPU, RAM, сетевых интерфейсов, дисков, boot-порядка, подключённых ISO, USB, passthrough-устройств и иных настроек.
• Оперативная память при live migration. Может содержать фрагменты обрабатываемой информации, ключи, сессии, токены, пароли, данные приложений и временные объекты.
• Сетевые привязки. После перемещения ВМ должна остаться в правильном сегменте, VLAN, port group, security group или overlay-сети.
• Snapshots и клоны. Могут содержать состояние данных на определённый момент времени и использоваться для обхода штатного контроля изменений.
• Резервные копии и реплики. При восстановлении или репликации ВМ фактически создаётся новое место размещения защищаемой информации.
• Политики безопасности. Включают firewall rules, антивирусные исключения, backup-политики, мониторинг, журналирование, теги, affinity rules и иные настройки, которые должны сохраняться после переноса.
• Журналы операций перемещения. Необходимы для подтверждения того, кто, когда, какую ВМ и куда переместил, а также по какому основанию.

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

Типовые сценарии перемещения

В регламенте целесообразно разделить сценарии по риску и требуемому согласованию.

• Live migration между узлами одного кластера. Передаётся состояние памяти; критичны изоляция миграционной сети, права и корректность назначения.
• Cold migration и перенос виртуальных дисков. Контролируются доступ к файлам ВМ, целостность, новое хранилище и сетевые привязки.
• Перемещение между кластерами или площадками. Проверяются канал, границы ИС, соответствие площадки требованиям защиты и договорная ответственность.
• Экспорт, импорт и клонирование. Это не всегда миграция в узком смысле, но операции создают переносимую копию ВМ и должны регулироваться не менее строго.
• Восстановление из резервной копии на другом узле. Контролируется место восстановления, подключение к сети и предотвращение появления неучтённой продуктивной копии.

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

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

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

• отражены ли виртуальные машины, хосты, кластеры, хранилища и площадки на структурной и логической схемах ИС;
• определены ли допустимые места размещения виртуальных машин ИС;
• установлен ли порядок перемещения ВМ между хостами, кластерами, хранилищами и площадками;
• ограничены ли права на live migration, storage migration, export, clone, restore и изменение сетевых привязок;
• ведётся ли журналирование операций перемещения, экспорта, импорта, клонирования и восстановления ВМ;
• проверяется ли сохранение сетевой сегментации, firewall rules, backup-политик, мониторинга и журналирования после переноса;
• защищён ли канал или сеть миграции, если при перемещении передаются виртуальные диски, состояние памяти или иная информация;
• оформляются ли изменения, если перемещение ВМ влияет на физические или логические границы ИС;
• исключено ли несанкционированное создание копий ВМ, snapshots, шаблонов и экспортных файлов;
• можно ли показать фактические настройки платформы, роли, журналы операций, правила размещения и регламент перемещения.

Слабая реализация – когда администратор виртуализации может без согласования экспортировать ВМ, перенести её в тестовый кластер, подключить к другой port group, восстановить копию на другой площадке или создать clone с продуктивными данными. Даже если сама платформа виртуализации промышленная, такая эксплуатационная модель не является безопасной.

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

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

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

Технический вариант через роли и ограничения операций.

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

Технический вариант через правила размещения и защищённую миграционную сеть.

Для ВМ ИС задаются допустимые хосты, кластеры, storage policies, anti-affinity/affinity rules, теги, resource pools и сетевые привязки. Миграционный трафик выносится в отдельную сеть, доступ к которой ограничен. Если миграция выполняется между площадками или через открытые каналы, требуется отдельная оценка защищённости канала и применимости криптографических мер.

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

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

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

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

• перечень виртуальных машин, относящихся к ИС;
• перечень допустимых хостов, кластеров, хранилищ, площадок и сетевых зон для размещения ВМ;
• порядок live migration, cold migration, storage migration, репликации и восстановления ВМ;
• порядок экспорта, импорта, клонирования и создания шаблонов ВМ;
• операции, запрещённые без отдельного согласования;
• роли и лица, имеющие право выполнять перемещение ВМ;
• порядок защиты миграционного трафика и сетей миграции;
• порядок проверки сохранения сетевой сегментации и политик безопасности после перемещения;
• порядок журналирования операций перемещения, экспорта, импорта, клонирования и восстановления;
• порядок актуализации структурной и логической схем при изменении размещения ВМ;
• порядок действий при ошибочном перемещении ВМ в недопустимую зону или выявлении неучтённой копии.

В ТЗ желательно отдельно указать, что перемещение ВМ с защищаемой информацией допускается только в пределах утверждённых физических и логических границ ИС либо по согласованной процедуре изменения этих границ. Это особенно важно для ЦОД, облаков, IaaS-платформ, двухплощадочных архитектур и сред с несколькими арендаторами.

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

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

• Роли и разрешения. Права на migration, export, clone, restore, изменение хранилища и сетевой группы выдаются отдельно.
• Правила размещения. Кластеры, теги, группы узлов, affinity/anti-affinity и политики хранения ограничивают допустимое назначение.
• Выделенная миграционная сеть. Доступ ограничивается узлами инфраструктуры; при передаче через недоверенную среду применяются меры защиты канала, соответствующие ТЗ.
• Контроль сетевой принадлежности. После переноса проверяются VLAN, security groups, виртуальный firewall, маршруты и доступ к СЗИ.
• Журналирование и контроль изменений. Фиксируются инициатор, объект, источник, назначение, время, результат и последующая проверка.

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

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

• перемещение ВМ выполняется администраторами без заявки, согласования и журналируемого основания;
• не определены допустимые хосты, кластеры, хранилища и сетевые зоны для ВМ ИС;
• ВМ с защищаемой информацией можно перенести в тестовый или общий кластер;
• экспорт ВМ и копирование виртуальных дисков не ограничены;
• клонирование продуктивной ВМ создаёт неучтённую копию с реальными данными;
• после миграции ВМ оказывается подключённой к неверной port group, VLAN или security group;
• миграционный трафик проходит по общей сети без ограничения доступа и без оценки защищённости;
• операции live migration, clone, export, restore и storage migration не передаются в централизованные журналы;
• после переноса не проверяется сохранение backup-политик, monitoring-агентов, firewall rules и средств защиты;
• структурная и логическая схемы не актуализируются после изменения фактического размещения ВМ;
• при размещении у провайдера отсутствует описание того, кто имеет право перемещать ВМ и в каких пределах.

Вывод

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

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

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

• Защита ресурсов виртуальной инфраструктуры
• Защита виртуальной инфраструктуры от НСД
• Резервное копирование виртуальных машин

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

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