Сучасний телеком-сектор активно впроваджує інтелектуальних агентів для оптимізації радіомереж та автоматизації BSS/OSS. Проте цей технологічний стрибок супроводжується критичним зростанням кіберризиків. За даними звіту ENISA Threat Landscape 2025, на цифрову інфраструктуру та сервіси припало 27.7% усіх витоків даних серед 4 875 інцидентів, проаналізованих за період з липня 2024 по червень 2025 року. Це вказує на безпрецедентну вразливість сучасних цифрових ланцюгів постачання.
Для операторів зв'язку ситуація ускладнюється жорстким регуляторним тиском. Директива NIS2 вимагає від суб'єктів критичної інфраструктури безкомпромісного контролю безпеки постачальників програмного забезпечення. Інтеграція сторонніх AI-компонентів без архітектурної ізоляції стає головною загрозою для комплаєнсу та цілісності даних.
AI-агенти як «чорна скринька»: чому периметровий захист більше не працює
Традиційна модель кібербезпеки роками будувалася навколо концепції захищеного периметра. Вважалося, що якщо критичні системи — сигнальне ядро чи білінг — ізольовані у внутрішніх контурах, загрозу мінімізовано. Проте впровадження сторонніх AI-модулів руйнує цю парадигму. AI-агенти за своєю природою є «чорними скриньками»: оператор отримує готове рішення, алгоритми прийняття рішень якого є непрозорими.
Коли такий сторонній модуль інтегрується в ядро мережі або BSS/OSS, йому потрібен доступ до реальних даних. Без суворого контролю скомпрометований AI-компонент стає ідеальним вектором для атак на ланцюг постачання (supply chain). Традиційні брандмауери не здатні розпізнати шкідливу активність усередині легітимного API-трафіку від авторизованого AI-модуля.
Фінансові наслідки таких уразливостей масштабні. За даними CFCA Global Fraud Loss Survey, глобальні втрати від телеком-шахрайства у 2025 році оцінено приблизно у 41.82 мільярда доларів (проти 38.95 мільярда у 2023 році). Впровадження алгоритмів без належної ізоляції дозволяє зловмисникам маніпулювати тарифікацією, обходити фрод-моніторинг або викрадати персональні дані.
Вимоги NIS2: регуляторний тиск на ланцюг постачання
Директива NIS2 перетворює безпеку ланцюга постачання (Supply Chain Security) з рекомендації на сувору юридичну вимогу. Оператори зобов'язані оцінювати рівень кібербезпеки всіх постачальників ПЗ. У контексті AI це означає, що телеком-компанія має технічно довести регулятору наявність повного контролю над обробкою даних сторонніми моделями.
Декларативних гарантій від вендора більше недостатньо. Потрібен інструментарій, який дозволяє в реальному часі проводити аудит дій AI-компонентів, лімітувати їхні права доступу та блокувати нетипові запити.
Архітектурна ізоляція за принципами TM Forum ODA
Для вирішення проблеми інтеграції індустрія використовує методологію Open Digital Architecture (ODA) від TM Forum. ODA замінює монолітні BSS/OSS на компонентовану, API-first архітектуру. Паралельно архітектура 5G core (service-based), визначена стандартами 3GPP, наближає телеком до cloud-native принципів.
Головний принцип інтеграції AI в рамках ODA — відмова від довіри за замовчуванням (Zero Trust). Будь-який сторонній AI-модуль розглядається як потенційно небезпечний. Архітектори зосереджуються на мікросегментації та захисті окремих API-ендпоінтів. Проте важливо розуміти: сама по собі архітектура ODA автоматично не гарантує безпеки без додаткових налаштувань контролю доступу (ACL) та шифрування.
Практичні механізми захисту: шлюзи, контейнери та RLS
Для забезпечення комплаєнсу з NIS2 технічні команди впроваджують три ешелони захисту:
- API-шлюзи для валідації запитів: Усі запити між ядром мережі та стороннім AI-модулем проходять через API Gateway. Шлюз перевіряє відповідність запитів жорстким схемам даних, лімітує частоту (Rate Limiting) та блокує несанкціоновані звернення.
- Контейнеризація з обмеженням привілеїв (ACL): AI-модулі розгортаються в ізольованих середовищах із мінімальними мережевими правами. Це звужує поверхню атаки, хоча контейнеризація не робить AI-агенти повністю безпечними від загроз на рівні прикладного коду.
- Row-Level Security (RLS) та маскування даних: Замість прямого доступу до баз даних впроваджується політика RLS на рівні платформи або СКБД. AI-модуль отримує доступ лише до тих рядків даних, які необхідні для його конкретної задачі, у знеособленому вигляді.
Побудова безпечного інтеграційного контуру на практиці
Реалізація архітектури з нульовою довірою вимагає використання платформ, що підтримують Security by Design. Для побудови високопродуктивних інтеграційних шлюзів та проміжного ПЗ (middleware) може використовуватися low-code платформа UnityBase (спільна розробка компаній консорціуму Intecracy Group, де InBase є ключовим розробником).
Завдяки єдиній Domain metadata-моделі платформа дозволяє гнучко налаштовувати політики доступу. Для телеком-проектів із високими навантаженнями офіційна документація UnityBase рекомендує комерційні редакції Enterprise (EE) або Defence (DE). Вони забезпечують вбудований контроль доступу на рівні записів (RLS) та атрибутів (ACL), а також детальний аудит транзакцій (Audit Trail), що є прямою вимогою для звітності за NIS2.
Прикладом телеком-рішення у портфелі Intecracy Group, яке поєднує softswitch та білінг реального часу, є операторська VoIP-платформа DooxSwitch. Інтеграція сторонніх модулів оптимізації маршрутизації (LCR) чи виявлення фроду до таких систем потребує суворих API-шлюзів для мінімізації ризиків компрометації тарифікаційного ядра.
Окрім того, інтеграція AI вимагає зрілого управління життєвим циклом моделей. Компанія Softengi (також учасник альянсу) має міжнародну сертифікацію управління штучним інтелектом ISO/IEC 42001:2023. Це дозволяє проектувати кастомні AI-рішення та проводити консалтинг з урахуванням суворих вимог до безпеки та прозорості моделей, що є критично важливим для європейських операторів.
Матриця архітектурного контролю сторонніх AI-модулів у телеком-мережі
| Рівень інтеграції | Ризик без контролю | Метод ізоляції та контролю (ODA / NIS2) |
|---|---|---|
| BSS / Клієнтські дані | Несанкціонований доступ до персональних даних та витік платіжної інформації. | Впровадження Row-Level Security (RLS) та динамічне маскування даних на рівні інтеграційної платформи/шлюзу. |
| OSS / Моніторинг мережі | Витік топології мережі та даних про вразливості інфраструктури. | Контейнеризація AI-агентів з суворим NetworkPolicies та списками доступу (ACL). |
| Ядро мережі (5G Core) | Порушення маршрутизації або відмова в обслуговуванні через некоректні AI-команди. | Асинхронна взаємодія через захищені черги повідомлень з обов'язковою валідацією схем даних. |
Поширені питання
Як вимоги директиви NIS2 впливають на інтеграцію сторонніх AI-сервісів у телекомі?
Директива NIS2 вимагає від телеком-операторів забезпечення безпеки всього ланцюга постачання (Supply Chain Security). Це означає, що оператор несе відповідальність за ризики, пов'язані з використанням стороннього AI-коду, і повинен впровадити технічні засоби для контролю доступу та аудиту.
Як Open Digital Architecture (ODA) допомагає захистити телеком-інфраструктуру від вразливого ПЗ?
ODA від TM Forum замінює монолітні системи на компонентовану, API-first архітектуру. Вона дозволяє ізолювати сторонні AI-модулі від критичних процесів, обмежуючи їхню взаємодію з ядром мережі виключно через суворо контрольовані API-шлюзи.
Що таке Row-Level Security (RLS) і навіщо це потрібно для AI-модулів?
Row-Level Security — це механізм обмеження доступу на рівні окремих записів у базі даних (наприклад, реалізований в UnityBase EE). Він гарантує, що сторонній AI-алгоритм отримує доступ тільки до знеособлених даних, які безпосередньо стосуються його поточної задачі, запобігаючи масовому витоку.