Может ли объект КИИ содержать открытый код

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

Федеральный закон 187-ФЗ и Приказ ФСТЭК России от 25 декабря 2017 г. 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры» однозначно определяют требования к программным продуктам, используемым на объектах КИИ: сертифицированные средства защиты, использование решений из реестра отечественного ПО.

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

Пограничные контроллеры сессий (SBC, Session Border Controller) выполняют функции «периметра» для корпоративной телефонии. Они фильтруют SIP-сигнализацию и RTP-потоки медиа, обеспечивают скрытие внутренней структуры сети (Topology Hiding), защищают от DDoS-атак и сигнальных флудов. По данным «Лаборатории Касперского», в 2025 году 68% атак на телеком-операторов реализовывались через VoIP-вектор, включая мошенничества с междугородними звонками с ущербом до $2,5 млрд ежегодно. Если пограничный контроллер сессий не справляется с задачами защиты сигнального и медиа-трафика, сложной маршрутизации и выполнения требований непрерывной работы систем в условиях повышенных нагрузок — уязвимость может затронуть не один узел, а всю цепочку связи.

Проблема усугубляется открытым исходным кодом (OSS/FOSS). Популярные платформы SBC содержат десятки тысяч строк непроверенного кода. Даже «российские форки» с проприетарными надстройками наследуют базовые уязвимости. Для объектов КИИ 1–2 уровня это недопустимо.

Новые нормативные требования не оставляют пространства для спорного толкования стандартов безопасности тех или иных объектов КИИ: категоризация с 1 сентября 2026 (Распоряжение Правительства Российской Федерации от 26.02.2026 360-р устанавливает типовой перечень отраслевых элементов КИИ).

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

Где возникает риск

Пограничный контроллер сессий, или SBC, выполняет роль фильтра и защитного периметра для корпоративной телефонии. Он обрабатывает SIP-сигнализацию и RTP-потоки, скрывает внутреннюю структуру сети, помогает защищаться от перегрузок и атак, связанных с голосовым трафиком. Именно поэтому SBC часто становится одной из ключевых точек, через которые оценивают устойчивость всей коммуникационной системы.

Если критические компоненты такого решения завязаны на открытые библиотеки и внешние программные зависимости, растет вероятность появления цепочки уязвимостей. В обычной корпоративной среде это уже проблема, а на объекте КИИ — фактор, который может повлиять на устойчивость инфраструктуры в целом.

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

Какой подход работает

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

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

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

Что меняется для рынка

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

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

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

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

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