Пункт 6.6 приложения 3 к ПТКЗИ: физическая изоляция сегмента виртуальной инфраструктуры

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

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

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

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

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

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

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

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

Приложение 3 к Положению о порядке технической и криптографической защиты информации, пункт 6.6: «физическая изоляция сегмента виртуальной инфраструктуры (система хранения и обработки информации), предназначенного для обработки информации, распространение и (или) предоставление которой ограничено, не отнесенной к государственным секретам».

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

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

Требование обязательно для классов 4-дсп и 3-дсп. Для классов 4-ин, 4-спец, 4-бг, 4-юл, 3-ин, 3-спец, 3-бг и 3-юл оно является рекомендуемым.

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

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

Что считать физически изолированным сегментом

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

Конкретная технология не предписана. Решение должно соответствовать архитектуре ИС и обеспечивать заявленный результат.

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

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

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

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

Физическая и логическая изоляция

• физическое разделение не отменяет разграничение доступа;
• VLAN на общем оборудовании сам по себе не закрывает пункт;
• выделенные хосты при общем небезопасном хранилище сохраняют общую точку отказа;
• резервные копии и миграция не должны незаметно выводить данные за границы сегмента;
• для внешнего ЦОД выделенность подтверждается договором и техническими материалами.

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

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

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

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

Доказательства должны подтверждать фактическое состояние всей заявленной области, а не единичный пример.

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

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

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

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

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

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

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

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

В документах полезно отдельно описать штатный и аварийный режимы. Штатная схема может соответствовать требованию, но во время восстановления администратор способен временно разместить ВМ на общем оборудовании. Если такой сценарий не разрешён, запрет должен быть обеспечен настройками и понятной процедурой действий.

Типичные ошибки

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

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

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

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

• Пункт 6.2: защита виртуальной инфраструктуры от НСД и сетевых атак.
• Пункт 6.3: безопасное перемещение виртуальных машин.
• Пункт 6.4: резервное копирование виртуальных машин.

Вывод

Пункт 6.6 требует доказуемого физического разделения сегмента хранения и обработки информации. Логическая изоляция необходима, но не заменяет физическую.

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

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

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

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

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 6.6. Официальный источник.
• Положение о порядке технической и криптографической защиты информации – требования к ТЗ, ЛПА и эксплуатации. Официальный источник.

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