Для українських продуктових IT-компаній, які розробляють рішення для телеком-сектору та орієнтуються на ринок Європейського Союзу, кібербезпека остаточно трансформувалася з формального чекліста на архітектурний стандарт. Директива NIS2 змушує європейських телеком-операторів, визнаних критичною інфраструктурою, переглядати надійність своїх ланцюгів постачання (supply chain). Будь-який постачальник програмного забезпечення, чия OSS/BSS система не забезпечує ізоляцію процесів від застарілих legacy-ядер, ризикує втратити доступ до європейських тендерів.
Для власників та CEO українських технологічних бізнесів це означає пряму загрозу експортному виторгу. Модернізація архітектури продукту через розмежування (decoupling) та підхід Security by Design — це необхідна інвестиція у збереження ринкової частки та статусу надійного постачальника для операторів ЄС.
NIS2 як новий бар'єр входу: чому європейський телеком змінює правила гри
Європейські оператори зв'язку функціонують під жорстким наглядом регуляторів. Згідно з критеріями NIS2, вони класифікуються як «essential entities» (критично важливі суб'єкти). Інциденти в їхніх мережах тягнуть за собою не лише операційні збитки, а й суворі штрафи та можливу персональну відповідальність керівництва.
Статистика доводить реальність ризиків. За даними Агентства ЄС з кібербезпеки (ENISA), у звітному періоді 2024-2025 років було проаналізовано 4 875 інцидентів, і 53.7% усіх постраждалих організацій були ідентифіковані саме як «essential entities». Крім того, близько 27.7% усіх зафіксованих витоків даних припало на сектор цифрової інфраструктури та сервісів. За таких умов оператори більше не ризикують інтегрувати зовнішнє програмне забезпечення без глибокого аудиту архітектури.
Анатомія загрози: чому монолітні OSS/BSS більше не проходять комплаєнс
Історично системи підтримки операцій та бізнесу (OSS/BSS) будувалися як моноліти, де клієнтські сервіси, білінгові транзакції та управління мережевими ресурсами були тісно пов'язані. У таких контурах компрометація одного модуля може означати отримання контролю над ядром мережі.
Ця модель стала неприйнятною через низку критичних вразливостей:
- Відсутність ізоляції процесів: атака на менш захищений зовнішній інтерфейс (наприклад, портал самообслуговування) відкриває прямий доступ до бази даних тарифікації.
- Вектор застарілих протоколів: сигнальні інтерфейси SS7 та Diameter у legacy-ядрах, які ENISA постійно визначає як потенційні точки вразливості, залишаються відкритими для неавторизованих внутрішніх запитів із монолітної системи.
- Фінансові збитки: архітектурні недоліки BSS прямо конвертуються у втрати. За оцінками звіту CFCA Global Fraud Loss Survey 2025, глобальні втрати від телеком-шахрайства досягли приблизно 41.82 мільярда доларів.
Стратегія Decoupling: як ізолювати критичні бізнес-процеси від legacy-ядра
Перехід до вимог NIS2 не обов'язково вимагає негайного переписування всього спадкового коду. Ключовим підходом є архітектурне розділення (decoupling) — відокремлення бізнес-логіки та клієнтських модулів від чутливого телеком-ядра для обмеження радіуса ураження у разі інциденту.
На практиці цей процес включає:
- Ізоляцію систем білінгу: розрив прямих підключень до баз даних і перехід на взаємодію через захищені API-шлюзи (API Gateways).
- Впровадження мікросервісного контролю: використання Role-Based Access Control (RBAC) на рівні окремих компонентів, що гарантує доступ процесів лише до необхідного мінімуму даних.
- Аудит та захист сигнального трафіку: заміна неконтрольованих запитів до SS7/Diameter на стандартизовані сервісні виклики із шифруванням.
Security by Design на практиці: роль платформного підходу та стандартів TM Forum ODA
Еталоном для модернізації систем постачальників слугує Open Digital Architecture (ODA) від міжнародної асоціації TM Forum. ODA передбачає заміну монолітних BSS/OSS на компонентовану, API-first архітектуру, яка є сумісною з еволюцією мобільних мереж до 5G Standalone та service-based архітектур (згідно зі стандартами 3GPP).
Проте створення такої безпечної екосистеми з нуля потребує величезних ресурсів. Багато розробників оптимізують цей шлях, переносячи розробку на готові платформні основи, які вже містять архітектурні механізми безпеки.
Прикладом такої основи є платформа UnityBase (спільна розробка компаній Intecracy Group, де InBase виступає ключовим, але не єдиним розробником). Це full-stack JavaScript low-code платформа для enterprise-застосунків, яка завдяки єдиній Domain metadata-моделі дозволяє автоматично генерувати REST API та забезпечувати суворий контроль доступу.
Для телеком-рішень, що мають відповідати NIS2, критичними є можливості комерційних редакцій платформи (Enterprise або Defence):
- Контроль доступу та ізоляція даних: підтримка RBAC та безпеки на рівні рядків (Row-Level Security — RLS), що запобігає горизонтальному розповсюдженню загроз між клієнтськими або операційними сегментами.
- Наскрізний аудит (Audit Trail): детальне фіксування всіх системних процесів та дій користувачів, необхідне для форензики та комплаєнсу.
- Криптографічний захист: інтеграція із центрами сертифікації ключів (CRL/OCSP) та контроль цілісності серверних модулів у Defence-редакції.
На таких технологічних фундаментах створюються спеціалізовані рішення для операторів. Показовим прикладом є операторська VoIP-платформа DooxSwitch (розробка компанії DooxSwitch, що входить до технологічного альянсу Intecracy Group). Платформа об'єднує в собі softswitch, LCR-маршрутизацію та білінг реального часу. Використання безпечної архітектурної основи дозволяє подібним спеціалізованим системам відповідати суворим вимогам операторів до надійності та швидше проходити європейські аудити.
Ризики ланцюга постачання (Supply Chain): що європейський оператор вимагатиме від вашого коду
Окрім чистої архітектури, NIS2 розширює вимоги і до процесу розробки. Щоб залишатися в пулі постачальників, продуктовим компаніям доведеться забезпечити прозорість наступних процесів:
- Software Bill of Materials (SBOM): надання вичерпного переліку всіх бібліотек, open-source залежностей та компонентів продукту з доказом відсутності невідповідних вразливостей.
- Захист CI/CD пайплайнів: автоматизоване тестування на безпеку (SAST/DAST) кожного релізу та ізоляція середовищ збірки коду.
- Управління інцидентами: наявність документальних процедур швидкого виявлення та закриття вразливостей (Vulnerability Disclosure Policy).
Модернізація OSS/BSS до рівня API-first та Security by Design не гарантує автоматичної сертифікації — процесуальний аудит залишається обов'язком оператора. Проте без архітектурної готовності телеком-продукт просто не буде допущений до оцінки. Перехід від моноліту до компонентованої архітектури наразі є єдиною стратегією збереження експансії на європейський ринок.
Рівні готовності телеком-продукту (OSS/BSS) до вимог NIS2
| Рівень готовності | Архітектурні особливості | Вплив на ризики та комплаєнс |
|---|---|---|
| Рівень 0 (Legacy Моноліт) | Прямий доступ модулів до БД, відсутність ізоляції сигнального та бізнес-контурів, високий ризик supply chain атак. | Критична невідповідність. Ризик швидкого виключення з пулу постачальників європейських операторів. |
| Рівень 1 (Гібридний API-first) | Початок впровадження API-шлюзів, базовий RBAC, але критичні процеси (наприклад, білінг) тісно пов'язані з ядром. | Часткове зниження ризиків. Залишається вразливість перед горизонтальним поширенням загроз. |
| Рівень 2 (ODA-aligned) | Компонентована архітектура за стандартами TM Forum ODA, ізоляція мікросервісів, шифрування трафіку. | Суттєве зменшення поверхні атаки. Задовольняє більшість базових архітектурних вимог технічних аудитів. |
| Рівень 3 (NIS2-ready / Security by Design) | Повний decoupling, наскрізний аудит дій, ізоляція даних (RLS) на рівні платформи, автоматизований контроль цілісності коду та SBOM. | Висока готовність. Мінімізація ризиків для оператора, готовність до інтеграції в критичні ланцюги постачання ЄС. |
Поширені питання
Які саме санкції та ризики накладає NIS2 на постачальників програмного забезпечення для європейських операторів?
Прямі штрафні санкції директиви NIS2 спрямовані на самих операторів (критичних суб'єктів). Але для дотримання комплаєнсу оператори вимушені блокувати роботу з вендорами, які не можуть надати докази безпеки архітектури (Security by Design), ізоляції процесів та прозорості компонентів (SBOM), що автоматично позбавляє постачальника ринку збуту.
Як архітектура TM Forum ODA допомагає виконати вимоги щодо ізоляції процесів у телекомі?
Модель ODA концептуально переводить монолітні BSS/OSS на API-first підхід, розбиваючи систему на ізольовані компоненти (мікросервіси). Їхня взаємодія відбувається через стандартизовані відкриті API. Це дозволяє обмежити радіус ураження у разі інциденту, не даючи зловмиснику проникнути з одного модулю в інші критичні підсистеми.
Чи обов'язково повністю переписувати legacy OSS/BSS для отримання сертифікату відповідності в ЄС?
Абсолютне переписування не завжди є необхідним або рентабельним. Більшість компаній застосовують стратегію decoupling — відокремлення критичних процесів, перенесення їх на захищені enterprise-платформи (наприклад, з використанням механізмів UnityBase для RLS та аудиту) та закриття застарілих систем захищеними API-шлюзами.