Пункт 7.9 приложения 3 к ПТКЗИ: сегментирование сети управления активами ИС и СЗИ

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

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

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

Сегментирование создаёт отдельный доверенный путь: администратор подключается к контролируемому рабочему месту или jump-host и только затем обращается к управляющим адресам.

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

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

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

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

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

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

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

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

Как разделить сеть управления и сеть передачи данных

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

Для небольших систем допустима отдельная VLAN с фильтрацией на МЭ. Для крупных и критичных сред полезен выделенный управляющий контур и out-of-band доступ.

Необходимо учитывать IPv4, IPv6, виртуальные сети, облачные security groups и беспроводные подключения. Ограничение только в одном сетевом стеке оставляет обход.

• Выделенная VLAN или VRF для управляющих адресов.
• Отдельные физические интерфейсы критичных узлов.
• Jump-host или bastion как контролируемая точка.
• Административные АРМ без почты и произвольного web-доступа.
• Межсетевое экранирование по адресам и протоколам.
• MFA и отдельный VPN для удалённого администрирования.
• Журналирование входов, подключений и изменений.

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

Допустимые взаимодействия между сегментами

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

Предпочтительнее конкретные источники, назначения и порты, а не широкие подсети. Временные правила удаляются после завершения работ.

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

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

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

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

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

• Структурные и логические схемы с отдельным управляющим контуром;
• Перечень управляющих адресов по выборке активов;
• Правила межсетевого экрана и маршрутизации;
• Настройки jump-host, VPN и административных АРМ;
• Отсутствие обходных путей через резервные и облачные сети;
• Журналы административных входов и отклонённых соединений;
• Проверку связности из пользовательского и административного сегментов.

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

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

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

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

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

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

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

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

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

• Назначение управляющего контура и перечень активов;
• Сегменты, адресацию и доверенные точки доступа;
• Разрешённые протоколы управления;
• Роли администраторов и минимальные полномочия;
• Порядок временных подключений и аварийного доступа;
• Мониторинг административных соединений;
• Периодическую проверку изоляции и ревизию правил.

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

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

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

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

• VLAN создана, но маршрутизация и фильтрация разрешают полный доступ;
• Управление доступно через пользовательский IP;
• Jump-host подключён ко всем сетям без ограничений;
• Административный АРМ используется для почты и интернета;
• Временные правила не удаляются;
• IPv6 и облачные сети не включены в анализ;
• Средства управления используют общие учётные записи.

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

Отсутствие выявленных отклонений в течение длительного времени не всегда означает идеальный порядок. Иногда это признак того, что контроль не выполняется или охватывает не всю систему.

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

• Пункт 3.1: разграничение доступа.
• Пункт 7.11: управление информационными потоками.
• Пункт 7.12: межсетевое экранирование.

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

Вывод

Пункт 7.9 отделяет высокопривилегированный административный контур от обычной передачи данных.

Качественная реализация использует отдельные сегменты, jump-host, административные АРМ, MFA, фильтрацию и журналирование.

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

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

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

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.9. Официальный источник.
• Приказ ОАЦ № 98 от 27.05.2026 изменил отдельные положения приказа № 66, но не изменил строки 7.7–7.13 приложения 3. Официальный источник.

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