З набранням чинності суворими вимогами директиви NIS2 відповідність стандартам кібербезпеки перестала бути паперовою формальністю. Для телекомунікаційної галузі, яка належить до критично важливої інфраструктури, це перетворилося на жорсткий архітектурний мандат. Згідно з даними звіту ENISA Threat Landscape 2025, суб'єкти цифрової інфраструктури та послуг становлять приблизно 27.7% від усіх постраждалих від витоків даних організацій. Важливі інституції (Essential entities) за класифікацією NIS2 складають 53.7% від усіх уражених кібератаками компаній. Загалом за період з 1 липня 2024 року до 30 червня 2025 року ENISA проаналізувала 4 875 інцидентів, що підтверджує стрімке зростання інтенсивності атак на критичні вузли.
Найбільш вразливою зоною сучасних телеком-операторів є застарілі системи підтримки операцій та бізнесу (OSS/BSS). Монолітна архітектура цих рішень створює масивну площу для атак. Компрометація одного публічного інтерфейсу часто відкриває зловмисникам шлях до білінгу та сигнального ядра мережі. У цій статті ми розглянемо, як розірвати моноліт, ізолювати критичні процеси та забезпечити комплаєнс без зупинки базових операцій.
Чому NIS2 змінює правила гри для OSS/BSS: аналіз загроз ENISA 2025
Телеком-оператори історично будували ІТ-ландшафти за принципом внутрішнього периметра безпеки: вважалося, що все, що знаходиться всередині мережі, є довіреним. Статистика ENISA спростовує цей підхід: фішинг залишається провідним вектором для отримання початкового доступу до систем. Це означає, що зловмисник може легко обійти периметральний захист через скомпрометований обліковий запис співробітника.
Коли загроза проникає всередину монолітної системи OSS/BSS, відсутність внутрішніх бар'єрів дозволяє здійснювати горизонтальне переміщення (lateral movement). Зловмисники отримують доступ до конфіденційних даних або управління мережевими ресурсами. Окрім витоку даних, критичною загрозою є фрод. За даними CFCA Global Fraud Loss Survey 2025, глобальні збитки від телеком-шахрайства у 2025 році оцінюються приблизно в 41.82 мільярда доларів. Значна частина цих втрат пов'язана з несанкційнованим доступом до білінгових систем.
Анатомія вразливості: як монолітна архітектура legacy-ядра множить ризики
Головна проблема legacy-архітектури OSS/BSS — відсутність розмежування рівнів доступу (decoupling) та детального аудиту дій. У класичному моноліті білінгові модулі, бази даних абонентів і системи управління мережевим обладнанням (provisioning) тісно пов'язані між собою. Це створює низку критичних вразливостей:
- Надмірна площа атаки: Інтеграція з зовнішніми партнерами чи CRM зазвичай реалізується через прямі запити до бази даних або пропрієтарні інтерфейси без належної авторизації на рівні транзакцій.
- Відсутність ізоляції: Якщо скомпрометовано веб-інтерфейс партнерського порталу, зловмисник може отримати можливість надсилати команди безпосередньо в опорну мережу.
- Слабкий аудит: Логування ведеться на рівні загальних подій. З'ясувати, хто саме з користувачів змінив статус послуги чи конфігурацію в базі даних, практично неможливо, що прямо порушує вимоги NIS2 щодо підзвітності.
Стратегія Decoupling: розділення білінгу, CRM та провіжінгу за принципами TM Forum ODA
Радикальна заміна ядра мережі та всіх систем BSS за принципом «rip-and-replace» є ризикованою для великих операторів, оскільки застарілі системи часто акумулюють більшість технічного боргу. Натомість світова практика пропонує еволюційний багаторічний шлях поетапної міграції.
Ініціатива TM Forum Open Digital Architecture (ODA) пропонує замінити монолітні BSS/OSS на компонентовану, API-first архітектуру для забезпечення автономності операцій. Важливо зазначити: міграція на ODA або cloud-native технології не гарантує значна частина відповідності NIS2 автоматично. Ці фреймворки створюють технічну основу (enablers), яка робить виконання вимог можливим.
Ключовий принцип модернізації — це розмежування критичних шарів:
- Ізоляція білінгових модулів від сигналізації опорної мережі для запобігання горизонтальному переміщенню у разі зламу.
- Впровадження API-first шлюзів для заміни пропрієтарних інтерфейсів між CRM та системами мережевого провіжінгу.
- Застосування рольового доступу (RBAC) та централізованого логування на рівні прикладного ПЗ.
Ця стратегія узгоджується з еволюцією стандартів 3GPP, де релізи визначають функціональність 5G Standalone та перехід до хмарно-орієнтованих сервісних архітектур.
Безпека ланцюга постачань (Supply Chain): захист API-інтеграцій
Відповідно до NIS2, оператори зобов'язані контролювати ризики, пов'язані з ланцюгом постачань. У телекомі це вимагає жорсткого контролю над інтеграціями: будь-який партнерський сервіс, що взаємодіє з OSS/BSS, має проходити через захищений шлюз із моделлю Security by Design.
Прикладом технологічної основи для побудови такого ізолюючого шару є використання платформи UnityBase (спільної розробки компаній консорціуму Intecracy Group). Платформа дозволяє розгорнути інтеграційний API-шлюз, який відділяє legacy-компоненти від зовнішнього світу. Завдяки єдиній Domain metadata-моделі платформа поєднує опис даних, інтерфейсів та політик безпеки. Для критичної інфраструктури офіційно рекомендуються комерційні редакції Enterprise (EE) або Defence (DE), які забезпечують:
- Суворий контроль доступу: Механізми RBAC та безпека на рівні рядків (RLS) гарантують, що партнерська система отримує доступ лише до дозволеного сегмента даних.
- Наскрізний аудит: Модуль DataHistory створює детальний audit trail, фіксуючи кожну дію користувача або скрипта, що задовольняє вимоги NIS2 щодо розслідування інцидентів.
- Захист API: Автоматично згенеровані REST API проходять сувору автентифікацію (з підтримкою OpenID Connect/OAuth2 та одноразових паролів у комерційних версіях).
У телеком-портфелі технологічного альянсу також наявна операторська VoIP-платформа DooxSwitch, яка забезпечує ізольовану маршрутизацію та real-time білінг голосового і IoT/M2M-трафіку. Інтеграція таких вузькоспеціалізованих BSS-модулів із захищеним шаром на базі UnityBase дозволяє операторам модернізувати тарифікацію та запобігти фроду без втручання в застаріле ядро мережі.
Практичний roadmap: поетапна ізоляція legacy-компонентів
Перехід до захищеної архітектури мінімізує вплив на операційну діяльність, якщо відбувається ітеративно. Типовий roadmap включає:
- Аудит: Визначення точок взаємодії legacy-моноліту із зовнішнім середовищем.
- Створення інтеграційного шлюзу (Decoupling Layer): Розгортання захищеної платформи як посередника, що перевіряє права доступу.
- Міграція модулів: Поступове винесення функцій (наприклад, IoT-білінгу) в окремі сервіси.
- Моніторинг: Інтеграція логів аудиту додатків із централізованою SIEM-системою.
| Рівень відповідності | Опис архітектури |
|---|---|
| Рівень 0 (Legacy-моноліт) | Спільна база даних для білінгу та провіжінгу, відсутність ізоляції, прямий доступ партнерських систем до ядра. |
| Рівень 1 (Периметральний захист) | Моноліт закритий фаєрволами, але всередині мережі панує повна довіра; API не стандартизовані. |
| Рівень 2 (Гібридний Decoupling) | Критичні модулі (білінг, CRM) винесені в окремі контури, взаємодія через захищені API-шлюзи з RBAC. |
| Рівень 3 (Компонована ODA / NIS2-compliant) | Повна ізоляція шарів, нульова довіра на рівні транзакцій, наскрізне логування кожної дії. |
Модернізація OSS/BSS під вимоги NIS2 — це питання стійкості бізнесу в умовах зростання кіберзагроз. Архітектурне розмежування із застосуванням надійних платформних інструментів дозволяє здійснити цей перехід плавно, захистивши критичну інфраструктуру без зупинки сервісів.
Поширені питання
Як виконати вимоги NIS2 щодо безпеки ланцюга постачань (supply chain) у телекомі?
Необхідно виключити прямий доступ партнерських систем до баз даних OSS/BSS. Взаємодія має відбуватися через захищені API-шлюзи з автентифікацією, шифруванням трафіку та застосуванням рольового доступу (RBAC) і безпеки на рівні рядків (RLS).
Чи обов'язково повністю замінювати (rip-and-replace) legacy BSS для відповідності NIS2?
Ні, повна заміна несе високі операційні ризики. Ефективною альтернативою є стратегія декупажу (decoupling) — побудова проміжного інтеграційного шару, який ізолює legacy-ядро від зовнішніх систем та забезпечує контроль і аудит на рівні API.
Які вимоги NIS2 висуває до логування та аудиту дій користувачів у білінгових системах?
NIS2 вимагає повної підзвітності для розслідування інцидентів. Система повинна вести наскрізний аудит (audit trail) транзакцій, фіксуючи кожну зміну в профілях користувачів, тарифах чи налаштуваннях мережевого провіжінгу.