Пункт 5.1 приложения 3 к ПТКЗИ: защита информации при передаче по открытым каналам

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

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

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

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

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

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

По таблице приложения 3 требование пункта 5.1 имеет рекомендательный статус для классов 4-ин, 4-спец, 4-бг, 4-юл и 4-дсп и обязательный статус для классов 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп. Такая структура связана с тем, что классы 3-* предполагают подключение к сетям электросвязи общего пользования – открытым каналам передачи данных.

Для классов 4-* применение меры также должно оцениваться по фактическим информационным потокам. Если система всё же использует внешний обмен через открытый канал, решение о криптографической защите нельзя принимать только по названию класса: ТЗ формируется с учётом используемых технологий и целей защиты.

Что считается открытым каналом передачи данных

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

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

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

Линейное и предварительное шифрование

Формулировка пункта 5.1 указывает два возможных подхода: средства линейного шифрования и средства предварительного шифрования. Это не одно и то же, и для проекта СЗИ важно не смешивать эти варианты.

• Линейное шифрование. Защита информации непосредственно в канале передачи данных. Обычно реализуется криптографическими шлюзами, VPN-средствами, шифраторами каналов, средствами защиты межплощадочного или удалённого взаимодействия. Пользователь или приложение может работать с данными в обычном режиме, а защита выполняется на уровне канала.
• Предварительное шифрование. Защита информации до её передачи по открытому каналу. В этом варианте данные шифруются заранее: файл, сообщение, контейнер, архив, объект обмена или иной информационный пакет передаётся уже в защищённом виде. Такой подход уместен, когда невозможно или нецелесообразно строить защищённый канал для всего взаимодействия.
• Комбинированный подход. В отдельных случаях применяются оба механизма: например, данные передаются через защищённый канал, а особо чувствительные объекты дополнительно шифруются до передачи. Такой вариант может быть оправдан при высоких рисках, межорганизационном обмене или особом режиме обработки информации.

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

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

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

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

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

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

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

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

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

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

Технический вариант с предварительным шифрованием.

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

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

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

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

ТЗ должно содержать требования к СКЗИ на основе государственных стандартов, взаимосвязанных с ТР 2013/027/BY. Поэтому любой VPN или функция TLS не должны автоматически объявляться выполнением пункта 5.1 без проверки допустимости применяемого средства и соответствия проектной модели.

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

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

На логической схеме ИС желательно явно показывать внешние потоки, защищённые каналы, точки криптографической защиты и взаимодействующие стороны. На структурной схеме следует отражать физическое размещение криптографических средств, если они входят в состав СЗИ и представлены отдельными устройствами или программно-аппаратными компонентами.

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

Выбор средства определяется архитектурой обмена и требованиями к СКЗИ. В статье нельзя подменять это требование перечнем обычных сетевых протоколов или продуктов.

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

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

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

• на логической схеме есть внешний обмен, но не указано, каким образом обеспечивается конфиденциальность и целостность передаваемой информации;
• VPN заявлен в документах, но не определены защищаемые потоки и границы защищённого канала;
• удалённое администрирование выполняется через открытый канал без достаточного криптографического механизма защиты;
• передача файлов, выгрузок или резервных копий выполняется через внешние сервисы без предварительного шифрования;
• используются разные решения для разных каналов, но нет единого перечня и порядка эксплуатации;
• не описан порядок управления ключами, сертификатами, токенами и действиями при их компрометации;
• канал связи считается “выделенным” без договорного и технического подтверждения зоны ответственности и характера среды передачи;
• обычный TLS или web-защита приложения автоматически считается достаточной без анализа конкретного потока и требований к СКЗИ;
• средства криптографической защиты внедрены, но не отражены в ТЗ, структурной и логической схемах, эксплуатационных регламентах;
• нет подтверждающих материалов: конфигураций, схем, журналов установления соединений, сведений о ключах, сертификатах и ответственных лицах.

Вывод

Пункт 5.1 следует рассматривать как требование к защите конкретных информационных потоков, а не как формальную установку VPN “где-нибудь на периметре”. Владелец ИС должен определить, какие данные передаются через открытые каналы, какие риски возникают при такой передаче и каким способом обеспечиваются конфиденциальность и контроль целостности.

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

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

• Криптографическая защита информации при хранении
• Защита личных ключей ЭЦП
• Многофакторная и многоэтапная аутентификация

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

• Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 – приложение 3, пункт 5.1; определение защищённого канала; пункт 12 о требованиях к СКЗИ; пункт 20 о прекращении использования СКЗИ при компрометации ключей. Официальный текст