Пункт 7.11 приложения 3 к ПТКЗИ: управление информационными потоками и маршрутизация

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

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

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

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

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

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

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

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

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

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

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

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

Что означает управление информационными потоками

Информационный поток описывает конкретное взаимодействие: кто инициирует обмен, куда передаёт данные, по какому протоколу и для какой функции.

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

При изменении приложения таблица пересматривается. Новый сервис или интеграция не должны открывать дополнительные направления без согласования.

• Источник и назначение потока.
• Направление, протокол и порты.
• Функциональная цель: доступ к БД, журналирование, резервирование, интеграция.
• Критичность и тип информации.
• Владелец, подтверждающий необходимость.
• Средство контроля: маршрутизатор, МЭ, VPN или облачная политика.

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

Маршрутизация и контроль направлений обмена

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

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

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

• Отдельные подсети для пользовательских, серверных, тестовых и управляющих зон.
• Централизованные точки маршрутизации без обходных соединений.
• Минимальные маршруты вместо широких суммарных сетей.
• VRF или отдельные маршрутизаторы для независимых контуров.
• Контроль динамических протоколов, соседей и аутентификации.
• Резервные пути, сохраняющие те же ограничения.
• Ограниченная маршрутизация VPN и облачных сетей.

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

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

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

• Структурные и логические схемы с сегментами и L3-устройствами;
• Таблицу информационных потоков с владельцами;
• Фактические таблицы маршрутизации;
• Конфигурацию VLAN, VRF, статических и динамических маршрутов;
• Отсутствие обходов через резервные каналы и VPN;
• Историю изменений маршрутов;
• Проверку разрешённой и запрещённой связности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Плоская сеть без межсегментной маршрутизации;
• Маршруты не связаны с документированными потоками;
• Широкие суммарные сети открывают лишние подсети;
• Резервный канал обходит средство контроля;
• VPN выдаёт доступ ко всей сети;
• Динамический протокол принимает любые маршруты;
• Облачные route tables отсутствуют в схемах.

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

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

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

• Пункт 7.9: сегментирование сети управления.
• Пункт 7.12: межсетевое экранирование.
• Пункт 7.16: контроль внешних подключений.

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

Вывод

Пункт 7.11 требует сделать внутренние и внешние сетевые пути управляемыми и документированными.

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

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

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

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

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

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