Директива NIS2 вимагає від телеком-операторів кардинального переосмислення безпеки ланцюга постачання програмного забезпечення. Захист інтеграцій із зовнішніми підрядниками стає пріоритетом, адже за даними звіту ENISA Threat Landscape 2025, на цифрову інфраструктуру та сервіси припало близько 27.7% усіх зафіксованих витоків даних. За звітний період з 1 липня 2024 року до 30 червня 2025 року ENISA проаналізувала 4 875 інцидентів, що підтверджує системний характер атак на операторів зв'язку та їхніх партнерів.
Для технічних керівників телеком-компаній це створює серйозний виклик. Більшість критичних бізнес-процесів досі зав'язані на застарілі (legacy) системи підтримки бізнесу та операцій (BSS/OSS). Ці монолітні рішення створювалися в епоху, коли загрози ланцюга постачання не вважалися критичними. Сьогодні ж підключення десятків зовнішніх постачальників послуг до legacy-ядра без належної ізоляції створює ризики компрометації всієї мережі.
Чому NIS2 фокусується на ланцюгу постачання: аналіз загроз для телеком-інфраструктури
Телеком-оператори є основою цифрового суспільства. За даними ITU, станом на 2025 рік приблизно дві третини населення світу користуються інтернетом. Будь-який збій у роботі оператора має каскадний ефект для фінансового сектору, логістики та державних сервісів, що пояснює жорсткі вимоги європейських регуляторів.
Окрім загрози доступності послуг, критичним фактором є фінансове шахрайство. Згідно зі звітом CFCA Global Fraud Loss Survey 2025, глобальні втрати від телеком-шахрайства оцінюються приблизно у 41.82 мільярда доларів. Значна частина цих інцидентів пов'язана з компрометацією інтеграційних вузлів BSS/OSS, через які зловмисники отримують несанкціонований доступ до тарифікації або маршрутизації.
Виконання вимог NIS2 щодо безпеки ланцюга постачання (Supply Chain Security) означає, що кожна API-інтеграція чи звернення від стороннього сервісу мають проходити через жорсткі фільтри. Проте застарілі системи архітектурно не здатні забезпечити такий рівень перевірки.
Анатомія вразливості: чому legacy BSS/OSS не готові до прямих інтеграцій
Типова legacy BSS/OSS система — це on-premises моноліт, що використовує спільну базу даних для багатьох модулів. Спроби інтегрувати її із сучасними зовнішніми сервісами стикаються з трьома архітектурними проблемами:
- Відсутність гнучкого розмежування доступу. Зовнішні партнери часто отримують надлишкові права (наприклад, доступ на рівні бази даних) або використовують hardcoded облікові записи, які неможливо оперативно відкликати.
- Слабкі механізми автентифікації. Legacy-компоненти здебільшого не підтримують сучасні стандарти на кшталт OAuth2 чи OpenID Connect (OIDC) для API-запитів.
- Фрагментоване логування (Audit Trail). Журнали подій часто зберігаються у текстових файлах на серверах застосунків, де їх легко модифікувати або видалити, що унеможливлює проведення розслідувань у разі інциденту.
У таких умовах компрометація навіть другорядного партнера (наприклад, сервісу SMS-розсилок) відкриває зловмисникам прямий шлях до білінгової інформації.
Архітектурний шаблон TM Forum ODA як основа ізоляції критичних систем
Щоб уникнути повної заміни ядра, архітектори звертаються до сучасних концепцій модернізації. TM Forum ODA (Open Digital Architecture) пропонує перехід від монолітних BSS/OSS до компонентованої, API-first архітектури. Важливо розуміти, що ODA не є стандартом безпеки — це архітектурна референсна модель. Проте її принципи ідеально підходять для ізоляції вразливих вузлів.
ODA передбачає створення чітко визначених сервісних кордонів. Усі взаємодії відбуваються через стандартизовані Open API. Це дозволяє побудувати безпечний інтеграційний прошарок (Integration Layer), який бере на себе функції захисту та фільтрації трафіку, залишаючи застаріле ядро ізольованим від прямого зовнішнього доступу.
Впровадження безпечного інтеграційного прошарку: ізоляція API та наскрізний Audit Trail
На практиці створення такого прошарку базується на трьох технічних рішеннях:
- Ізоляція API застарілих систем. Зовнішні партнери ніколи не звертаються до legacy-компонентів напряму. Проміжний шар перетворює сучасні виклики (наприклад, REST з JWT) у внутрішні протоколи BSS/OSS.
- Фільтрація запитів через API-шлюз. Шлюз перевіряє структуру запитів на відповідність схемам даних, блокуючи спроби несанкціонованого доступу чи ін'єкцій до того, як вони досягнуть критичних вузлів.
- Централізований audit trail. Проміжний шар реєструє кожен запит до API, фіксуючи, хто, коли, з якої IP-адреси та які саме дані намагався отримати. Логи записуються у захищене від змін сховище (наприклад, DataHistory), що відповідає вимогам NIS2 щодо простежуваності.
Практична реалізація: модернізація телеком-ядра без зупинки процесів
Для побудови захищеного інтеграційного прошарку необхідний відповідний технологічний фундамент. Прикладом інструменту для розгортання таких архітектур є full-stack JavaScript low-code платформа UnityBase (спільна розробка компаній Intecracy Group; InBase виступає ключовим, але не єдиним розробником платформи).
Завдяки концепції Domain metadata, платформа дозволяє спроєктувати доменну модель, на основі якої автоматично генеруються REST API. Для телеком-інфраструктур із високими навантаженнями та жорсткими вимогами до безпеки офіційна документація рекомендує комерційні редакції Enterprise (EE) або Defence (DE). Вони забезпечують критично важливі для NIS2 механізми захисту на рівні прошарку:
- Підтримка сучасних методів автентифікації: OpenID Connect/OAuth2 та одноразові паролі.
- Розмежування доступу на рівні рядків (Row-Level Security — RLS) та списків контролю доступу (ACL), що дозволяє обмежити видимість даних для конкретного партнера-постачальника.
- Вбудований незмінний журнал аудиту (audit trail) усіх транзакцій.
У випадках, коли модернізація потребує оновлення специфічних телеком-модулів (наприклад, маршрутизації чи тарифікації), цей інтеграційний підхід може комбінуватися з операторськими рішеннями, такими як VoIP-платформа DooxSwitch (із вбудованим real-time білінгом і LCR-маршрутизацією). Інтеграція DooxSwitch із захищеним прошарком дозволяє керувати IoT-сервісами чи маршрутизацією трафіку, не створюючи нових вразливостей.
Застереження: використання інтеграційних платформ чи API-шлюзів є необхідним технічним кроком, але воно не робить інфраструктуру оператора автоматично відповідною NIS2. Повна відповідність вимагає комплексного аудиту процесів та регулярного тестування безпеки ланцюга постачання.
| Вимога NIS2 | Legacy-проблема | Архітектурне рішення (Integration Layer) |
|---|---|---|
| Контроль доступу постачальників | Hardcoded облікові записи в legacy, надлишкові привілеї партнерів. | Впровадження API-шлюзу з динамічною автентифікацією (OAuth2/OIDC) та авторизацією на базі RLS/ACL. |
| Простежуваність дій (Audit Trail) | Логи відсутні, є фрагментарними або зберігаються в незахищених текстових файлах. | Централізоване незмінне логування всіх транзакцій та запитів до API на рівні інтеграційного прошарку. |
| Мінімізація поверхні атаки | Прямий доступ партнерів до баз даних та внутрішніх мережевих інтерфейсів. | Повна ізоляція legacy-ядра за допомогою API-first архітектури (згідно з принципами TM Forum ODA). |
Поширені питання
Як виконати вимоги NIS2 щодо безпеки ланцюга постачання без повної заміни legacy BSS/OSS?
Замість заміни ядра розгортається безпечний інтеграційний прошарок (API Gateway). Він бере на себе функції автентифікації, фільтрації запитів та логування, повністю ізолюючи legacy-систему від прямих зовнішніх інтеграцій із підрядниками.
Яка роль TM Forum ODA у забезпеченні безпеки інтеграцій телеком-оператора?
TM Forum ODA — це референсна архітектурна модель, що пропонує перехід до компонентованої архітектури на базі Open API. Її використання дозволяє чітко розмежувати сервісні кордони та контролювати весь зовнішній трафік через єдиний захищений прошарок.
Як організувати надійний audit trail для застарілих систем білінгу?
Надійний аудит реалізується на рівні інтеграційного прошарку, до якого звертаються партнери. Усі вхідні API-запити фіксуються у незмінному захищеному сховищі логів (з деталізацією ініціатора, часу та обсягу даних) до моменту передачі виклику у внутрішній legacy-білінг.