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

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

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

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

Мера применяется и к внешнему периметру, и к внутреннему сегментированию. После проникновения злоумышленник часто перемещается внутри сети, поэтому одного пограничного МЭ недостаточно.

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

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

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

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

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

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

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

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

Где требуется межсетевое экранирование

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

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

Для критичных серверов локальный МЭ создаёт дополнительную границу даже при ошибке в сетевой конфигурации.

• Внешний периметр и сети общего пользования.
• DMZ между публичными сервисами и внутренними системами.
• Пользовательские и серверные сети.
• Сеть управления и административные интерфейсы.
• Тестовая и продуктивная среды.
• Удалённый доступ, филиалы и партнёры.
• Облачные security groups и network ACL.

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

Правила межсетевого экрана

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

Понятные объектные группы и описания повышают качество. Правило APP-SERVERS → DB-PROD TCP/5432 легче проверить, чем набор неподписанных адресов.

Изменение правила сопровождается тестом до и после: нужный сервис должен заработать, а лишние порты не должны стать доступными.

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

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

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

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

• Схемы со всеми значимыми точками экранирования;
• Соответствие набора правил таблице потоков;
• Наличие запрета по умолчанию;
• Обоснование широких и временных разрешений;
• Журналы изменений и сетевых событий;
• Результаты последней ревизии правил;
• Фактический тест разрешённых и запрещённых соединений;
• Актуальность конфигурации резервного узла.

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

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

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

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

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

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

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

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

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

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

• Внешние и внутренние границы экранирования;
• Базовую политику запрета по умолчанию;
• Процесс заявки, согласования, тестирования и удаления правил;
• Владельцев информационных потоков;
• Максимальный срок временного доступа;
• Журналирование и сроки хранения событий;
• Периодическую ревизию и требования к резервированию;
• Ответственность за облачные security groups.

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

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

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

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

• Правила any-any между сегментами;
• Отсутствие владельцев и назначения старых правил;
• Временные разрешения остаются бессрочно;
• Широкое правило перекрывает точечные запреты;
• Локальные МЭ отключены без обоснования;
• Облачные правила не входят в общий процесс;
• Журналы собираются, но не анализируются.

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

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

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

• Пункт 7.11: управление информационными потоками.
• Пункт 7.9: сегментирование сети управления.
• Пункт 7.13: обнаружение и предотвращение вторжений.

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

Вывод

Пункт 7.12 требует фильтровать внутренний и внешний сетевой обмен на управляемых границах.

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

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

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

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

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

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