Європейська директива NIS2 та національні нормативні акти з кібербезпеки критичної інфраструктури висувають жорсткі вимоги до телеком-операторів. Згідно зі звітом ENISA Threat Landscape 2025, на цифрову інфраструктуру та сервіси припадає близько 27.7% усіх витоків даних. Для телеком-галузі це серйозний виклик: більшість операторів досі використовують застарілі (legacy) системи підтримки бізнесу (BSS), які не створювалися з розрахунком на сучасні загрози, але тепер мають інтегруватися з десятками сторонніх сервісів, платіжних шлюзів та ШІ-агентів.
Чому legacy BSS є головною вразливістю телекому в епоху NIS2
Legacy BSS-системи часто функціонують як «чорні скриньки». Вони стабільно тарифікують послуги, але позбавлені сучасних архітектурних засобів безпеки: детального логування, гранулярного контролю доступу (RBAC) та наскрізного шифрування. Через це підключення будь-якого стороннього сервісу стає загрозою для безпеки всього ланцюга постачання (supply chain security).
За вимогами NIS2, оператори як essential entities зобов'язані контролювати ризики, пов'язані з партнерами та постачальниками. Якщо сторонній сервіс буде зламано, зловмисники можуть отримати несанкціонований доступ до ядра білінгу. Ситуація ускладнюється тим, що застарілі системи не дозволяють відстежити, хто саме і коли ініціював запит, оскільки часто використовують один загальний системний обліковий запис для всіх зовнішніх інтеграцій.
Концепція API-фасаду: ізоляція застарілого ядра замість ризикованого рефакторингу
Спроба модифікувати закритий legacy-код монолітної системи — це шлях до високих витрат і технологічних ризиків. Будь-яке втручання в код, написаний багато років тому, загрожує збоями в білінгу, фінансовими втратами та тривалим простоєм сервісів.
Рішення полягає в архітектурній ізоляції застарілого ядра. Замість того, щоб переписувати код, архітектори розгортають захищений API-фасад (API gateway або integration layer). Цей проміжний шар бере на себе завдання з безпеки, автентифікації, авторизації та аудиту, трансформуючи небезпечні прямі запити у контрольовані транзакції. API-фасад не усуває внутрішні вразливості самого legacy-коду (він лише ізолює його), але надійно захищає систему від зовнішнього світу, створюючи єдину точку контролю.
Архітектурні вимоги TM Forum ODA для безпеки ланцюга постачання
Сучасна еволюція телекому базується на стандартах TM Forum Open Digital Architecture (ODA). ODA пропонує заміну монолітних BSS/OSS на компонентовану, API-first архітектуру, де сервіси взаємодіють через стандартизовані Open API. Це наближає телеком до cloud-native операцій, подібно до архітектури 5G core, яка стандартизована 3GPP.
Для забезпечення довіри до ідентифікаторів у мережах використовуються сучасні криптографічні методи. Наприклад, технічні стандарти, такі як STIR/SHAKEN, покладаються на публічні ключі для перевірки ідентифікаторів. У контексті BSS-інтеграцій це означає, що кожен запит від стороннього сервісу має бути автентифікований, авторизований та залогований на рівні API-фасаду перед потраплянням до внутрішньої мережі.
Реалізація контролю доступу та аудиту на рівні інтеграційного шару
Для побудови такого захищеного API-фасаду потрібен продуктивний інструмент, здатний обробляти великі обсяги транзакцій. Прикладом створення такого інтеграційного шару є використання рішень на базі платформи UnityBase (спільна розробка компаній консорціуму Intecracy Group, ключовим розробником якої є InBase).
Платформа UnityBase функціонує як full-stack JavaScript low-code framework. Завдяки концепції Domain metadata, платформа дозволяє швидко генерувати захищені REST API та використовувати вбудовані механізми безпеки, критичні для BSS:
- RBAC та RLS (Row-Level Security): розмежування доступу не лише на рівні методів API, а й на рівні конкретних рядків у базах даних.
- Детальний аудит (Audit Trail): наскрізне логування кожного запиту та спроб доступу, що є ключовою вимогою NIS2 для аудиту та розслідування інцидентів.
- Сучасні протоколи автентифікації: підтримка OpenID Connect, OAuth2, JWT, а в редакції Defence — авторизація за допомогою публічних та приватних ключів.
Цей підхід дозволяє розгорнути захищений шлюз on-premises, інтегрувавши його із застарілими базами даних та сучасними компонентами, такими як операторська VoIP-платформа DooxSwitch (входить до портфеля технологічного альянсу Intecracy Group), яка забезпечує білінг реального часу та маршрутизацію.
Практичні сценарії: безпечне підключення AI-агентів та платіжних шлюзів
Розглянемо три типові сценарії застосування API-фасаду на практиці:
- Примусова автентифікація сторонніх AI-агентів: Телеком-оператори все частіше інтегрують зовнішні AI-сервіси. Замість надання AI прямого доступу до білінгової системи DooxSwitch чи legacy-баз, перед ними розгортається API-шлюз на UnityBase, який здійснює примусову автентифікацію кожного запиту (наприклад, перевіряючи JWT-токен) та обмежує швидкість доступу.
- Логування запитів до legacy-баз без вбудованого аудиту: Застарілі бази даних часто не мають інструментів для детального логування SELECT-запитів. Інтеграційний шар перехоплює всі зовнішні запити, фіксує ідентифікатор користувача, IP-адресу та параметри в захищеному журналі аудиту (Audit Trail), гарантуючи простежуваність дій.
- Розмежування доступів (RBAC) для зовнішніх платіжних шлюзів: При підключенні платіжного партнера йому потрібен доступ лише до конкретних функцій (наприклад, перевірка балансу). Через API-фасад партнер отримує жорстко обмежений доступ. Спроби звернутися до інших функцій автоматично блокуються на рівні шлюзу.
Порівняння підходів до модернізації безпеки BSS
| Критерій порівняння | Пряма модифікація legacy-коду | Впровадження захищеного API-фасаду (UnityBase) |
|---|---|---|
| Швидкість впровадження | Низька (місяці/роки аналізу старого коду) | Висока (тижні, без втручання в ядро) |
| Ризик порушення стабільності білінгу | Критичний (можливі збої транзакцій) | Нульовий (ядро працює у штатному режимі) |
| Відповідність вимогам NIS2 щодо аудиту | Обмежена (складно реалізувати наскрізне логування) | Повна (централізований аудит усіх API-запитів) |
| Гнучкість підключення сторонніх сервісів | Вкрай низька (кожна інтеграція розробляється окремо) | Висока (стандартизовані API-контракти та RBAC) |
Хоча впровадження API-шлюзу не гарантує повної відповідності NIS2 (оскільки директива також вимагає комплексного управління ризиками та організаційних заходів), побудова захищеного API-фасаду є найраціональнішим інженерним кроком для ізоляції вразливих legacy-систем телекому.
Поширені питання
Як забезпечити відповідність NIS2 для телеком-систем без повної заміни legacy BSS?
Найефективнішим інженерним кроком є побудова захищеного API-фасаду (інтеграційного шару) перед застарілою системою. Це дозволяє централізувати автентифікацію, контроль доступу (RBAC) та аудит запитів, не втручаючись у чутливий код білінгу.
Які вимоги висуває директива NIS2 до безпеки API та ланцюга постачання в телекомі?
Директива NIS2 зобов'язує операторів, як essential entities, контролювати кіберризики, пов'язані з партнерами. Це вимагає впровадження суворого контролю доступу та обов'язкового ведення журналів аудиту (Audit Trail) для всіх зовнішніх інтеграцій із критичними системами.
Як побудувати захищений API-фасад перед застарілою білінговою системою?
Для цього використовують спеціалізовані low-code інтеграційні платформи, такі як UnityBase. Це дозволяє описати модель метаданих, автоматично згенерувати захищені REST API та налаштувати гнучкі правила логування й авторизації для ізоляції legacy-ядра від прямих зовнішніх запитів.