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

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

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

Практически требование направлено на защиту от ситуации, которую часто называют resource abuse или noisy neighbor. Виртуальная машина, контейнер, сервис, пользователь, арендатор или прикладной компонент может начать потреблять чрезмерное количество CPU, RAM, IOPS, сетевой полосы, места в хранилище или ресурсов гипервизора. Если такие действия не ограничены, страдает не только производительность, но и доступность ИС, корректность работы СЗИ, резервное копирование, журналирование и администрирование.

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

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

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

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

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

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

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

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

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

Какие ресурсы нужно учитывать

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

• CPU. Чрезмерная нагрузка одной ВМ или контейнера может привести к росту задержек и деградации соседних систем.
• Оперативная память. Перерасход RAM, ballooning, swapping или неправильное overcommit-планирование могут снижать стабильность всей виртуальной среды.
• Дисковая подсистема. Высокие IOPS, latency, массовые операции записи, резервное копирование или неконтролируемые снимки могут перегрузить систему хранения.
• Сеть. Одна ВМ, контейнер или сервис может занять значительную часть сетевой полосы, создать broadcast/multicast-шум, перегрузить виртуальный коммутатор или uplink.
• Снапшоты и резервные копии. Неконтролируемые snapshots, долгие цепочки снимков и параллельные задания backup могут влиять на производительность ИС.
• Управляющая плоскость. Массовые операции через API, ошибки автоматизации, неправильные скрипты или действия администратора могут перегрузить управляющую платформу виртуализации.
• Лицензии и сервисные компоненты. Некоторые платформы зависят от сервисов управления, лицензирования, DNS, NTP, каталогов и хранилищ образов; их перегрузка также влияет на доступность ИС.

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

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

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

• отражена ли виртуальная инфраструктура на структурной и логической схемах ИС;
• понятно ли, какие гипервизоры, кластеры, хранилища, виртуальные сети и управляющие компоненты обеспечивают функционирование ИС;
• определены ли потребители ресурсов виртуальной инфраструктуры и их зоны ответственности;
• установлены ли правила выделения CPU, RAM, дискового пространства, IOPS, сетевой полосы и иных ресурсов;
• настроены ли лимиты, квоты, reservations, shares, resource pools или аналогичные механизмы, если они поддерживаются платформой;
• исключено ли неконтролируемое создание ВМ, контейнеров, снимков, дисков и ресурсоёмких заданий;
• ведётся ли мониторинг загрузки общих ресурсов и выявление аномального потребления;
• есть ли порядок реагирования на перегрузку: ограничение, миграция, приостановка, масштабирование, уведомление ответственного лица;
• оформлены ли договорные и технические условия с провайдером, если ИС размещена во внешней IaaS или облачной среде;
• можно ли показать настройки платформы, отчёты мониторинга, правила выделения ресурсов, журналы событий и эксплуатационные регламенты.

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

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

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

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

Технический вариант через лимиты и квоты.

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

Технический вариант через мониторинг и реакцию.

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

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

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

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

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

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

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

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

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

• Вычислительные ресурсы. Лимиты, гарантии, доли, resource pools и обоснованные пределы overcommit для CPU и оперативной памяти.
• Хранилище. Квоты по объёму, ограничения IOPS и пропускной способности, контроль snapshots, клонов и временных дисков.
• Сеть. Ограничения полосы и интенсивности, защита от сетевых штормов и контроль ресурсоёмких операций.
• Управляющая плоскость. Ограничение числа объектов, частоты API-запросов и массовых операций автоматизации.
• Мониторинг и реакция. Пороги, оповещение, эскалация, временное ограничение нагрузки, перенос или масштабирование.

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

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

• виртуальная инфраструктура описана в общих словах, но не указаны общие ресурсные пулы и потребители ресурсов;
• ресурсы ВМ выделяются вручную без правил, лимитов и согласования;
• используется чрезмерный overcommit без оценки влияния на ИС и СЗИ;
• нет ограничений на создание snapshots, клонов, временных ВМ и тестовых сред;
• backup-задания перегружают хранилище или сеть в рабочее время;
• одна ВМ или контейнер может занять большую часть IOPS или сетевой полосы;
• мониторинг показывает перегрузку, но нет процедуры реакции и ответственного лица;
• критичные ВМ размещены в общем кластере без гарантий ресурсов и правил приоритета;
• при размещении у провайдера отсутствуют SLA, квоты, описание изоляции и распределения ответственности;
• требование включено в ТЗ, но не связано с конкретными настройками виртуальной платформы;
• потребители услуг могут самостоятельно создавать ресурсоёмкие объекты без контроля администратора или владельца ИС.

Вывод

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

Для небольшой виртуальной среды достаточно реестра ВМ, правил выделения ресурсов, базовых лимитов, контроля snapshots и мониторинга загрузки. Для ИС классов 3-* и многопользовательских платформ требуется более строгая модель: resource pools, quotas, reservations, QoS, мониторинг IOPS и сети, регламент ресурсоёмких операций и договорные гарантии при размещении у провайдера. Требование считается исполненным тогда, когда владелец ИС способен доказать, что агрессивное или ошибочное потребление ресурсов одним потребителем не приводит к неконтролируемой деградации защищаемой информационной системы.

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

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

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

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