Пункт 7.16 приложения 3 к ПТКЗИ: контроль внешних подключений к информационной системе

Краткое описание требования

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

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

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

Оригинальная формулировка требования

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

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

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

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

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

Что именно проверяет проверяющий

Контроль следует проверять от фактического канала к документу, а не только от документа к выборочному устройству.

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

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

Какие подключения учитывать

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

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

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

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

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

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

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

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

Пример проверки: временный доступ подрядчика

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

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

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

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

В ТЗ и проектной документации определяют разрешённые виды внешнего информационного взаимодействия, границы, точки доступа и технические ограничения. В схемах и реестре фиксируют реальные постоянные и временные связи. В ЛПА и ОРД устанавливают порядок согласования, изменения, пересмотра и закрытия подключений, ответственных лиц и исключения. В эксплуатационных инструкциях описывают применение конкретных настроек и порядок проверки после изменения конфигурации.

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

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

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

Вывод

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

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

• Приказ ОАЦ от 20.02.2020 № 66, действующая редакция — приложение 3 к ПТКЗИ, пункт 7.16 и таблица обязательности.
• Пункт 7.12: межсетевое экранирование — связанная мера контроля сетевых потоков.