У 2026 році відповідність вимогам європейської директиви NIS2 стала суворою реальністю для операторів критичних послуг (essential entities). Головний виклик, з яким стикаються ІТ-директори (CIO) та керівники з інформаційної безпеки (CISO), полягає не в номінальному декларуванні політик, а в реальному захисті систем від складних цілеспрямованих атак без створення операційних вузьких місць для бізнесу.
Згідно з даними звіту ENISA Threat Landscape 2025, на суб'єкти критичної інфраструктури припало 53.7% усіх проаналізованих кіберінцидентів у період з липня 2024 по червень 2025 року (загалом було проаналізовано 4 875 інцидентів). Це наочно демонструє, що підприємства енергетики, транспорту, охорони здоров'я та фінансового сектору є першочерговою мішенню зловмисників. Традиційний підхід, заснований виключно на захисті мережевого периметра, більше не здатний гарантувати стійкість таких інфраструктур.
Чому мережева сегментація більше не захищає критичну інфраструктуру самостійно
Класична сегментація на рівні мережевих портів та IP-адрес (L3/L4) створює ілюзію безпеки. Практика розділення мережі на зони за допомогою міжмережевих екранів (firewalls) та організації доступу через VPN-тунелі має критичну ваду: вона не захищає від внутрішнього переміщення зловмисників (lateral movement) після того, як вони подолали зовнішній бар'єр.
Якщо атакуючий отримує доступ до певного мережевого сегмента, він зазвичай отримує і пряму видимість усіх баз даних, API-інтерфейсів та сервісів, розташованих у ньому. Спроби вирішити цю проблему шляхом ще жорсткішої ізоляції на рівні маршрутизації призводять до виникнення операційних простоїв, порушення роботи інтеграційних шин та ускладнення адміністрування, що прямо суперечить базовим вимогам щодо безперервності бізнес-процесів критичної інфраструктури.
Вимоги NIS2 та CISA CPG: перехід від периметра до нульової довіри (Zero Trust)
Директива NIS2 та настанови CISA CPG (Cross-Sector Cybersecurity Performance Goals) вимагають від організацій кардинальної зміни підходів. Нова редакція NIST Cybersecurity Framework (CSF) 2.0 вводить функцію «Govern» (Управління), яка наголошує на кіберризиках як на невіддільній частині загального корпоративного управління. Безпека більше не може бути локалізована виключно на рівні мережевої інфраструктури.
Згідно з концепцією Zero Trust від Microsoft, саме ідентичність користувача та контекст його запиту стають новим периметром безпеки. Замість того, щоб довіряти сесії лише на основі факту підключення через VPN, система повинна безперервно перевіряти повноваження при кожному зверненні до конкретного об'єкта даних.
Сегментація на рівні додатків: як працюють RBAC та Row-Level Security (RLS)
Реальна практика експлуатації критичних систем доводить небезпеку надмірної довіри до мережевих з'єднань. Фахівці CERT-UA, аналізуючи інциденти угруповання UAC-0145, детально описують сценарії компрометації VPN-доступу через соціальну інженерію у процесі працевлаштування. Отримавши легітимні облікові дані, атакуючий без перешкод долає мережеві бар'єри та починає збір конфіденційної інформації.
Для запобігання таким загрозам безпека має бути вбудована в архітектуру додатків (рівень L7) через два ключові механізми:
- Role-Based Access Control (RBAC): Рольова модель жорстко визначає, які дії дозволені конкретному користувачу чи системному інтерфейсу. Навіть якщо зловмисник отримав доступ до мережі, його дії будуть обмежені правами скомпрометованого облікового запису.
- Row-Level Security (RLS): Безпека на рівні рядків бази даних забезпечує контекстну фільтрацію. Якщо обліковий запис належить оператору певної зони, RLS гарантує, що він бачитиме лише записи (рядки таблиці), які безпосередньо стосуються його ділянки. Спроба звернутися до сусідніх записів блокується на рівні ORM-шару додатку, навіть якщо мережевий доступ до СКБД є повністю відкритим.
Така сегментація на рівні даних робить lateral movement практично неможливим без повторної авторизації та ескалації привілеїв, що негайно фіксується системою аудиту.
Забезпечення безперервності бізнес-процесів при ізоляції критичних систем
Найбільшим бар'єром для впровадження суворих вимог безпеки є ризик зупинки операцій. ERP має обмінюватися даними з реєстрами, а системи електронного документообігу (DMS) — інтегруватися із зовнішніми кабінетами клієнтів. Блокування цих зв'язків на рівні портів паралізує роботу компанії.
Вихід полягає у логічній ізоляції процесів за допомогою детального аудиту (audit trail) замість фізичного блокування трафіку. Логування на рівні додатків фіксує семантику бізнес-операції: який документ відкрито, які зміни внесено, хто ініціював процес. Це дозволяє команді Security Operations Center миттєво виявляти аномалії, не порушуючи доступність сервісів для легітимних системних процесів.
Архітектурний підхід: побудова захищених систем на базі UnityBase без операційних простоїв
Щоб реалізувати вимоги NIS2 щодо контролю доступу без створення простоїв, необхідна гнучка технологічна основа. Одним із прикладів інструментів, що забезпечують таку архітектурну стійкість, є високопродуктивна full-stack low-code платформа UnityBase (спільна розробка компаній технологічного альянсу Intecracy Group, де InBase виступає ключовим, але не єдиним розробником).
UnityBase не є коробковою програмою, яка автоматично гарантує значна частина комплаєнс без налаштування внутрішніх процесів організації, проте вона надає архітекторам потужні вбудовані (built-in) інструменти для реалізації принципів Zero Trust:
- Domain metadata: Єдина модель метаданих домену об'єднує опис структури даних, інтерфейсу та API, дозволяючи централізовано визначати правила безпеки на найвищому рівні абстракції.
- Вбудовані RBAC та RLS: Механізми розмежування доступу інтегровані безпосередньо в ORM-шар платформи. Вони працюють незалежно від обраної СКБД, гарантуючи, що жоден запит не омине перевірку прав.
- Детальний аудит (audit trail): Платформа автоматично веде журнал безпеки та історію змін даних (DataHistory), відстежуючи життєвий цикл кожного запису.
На базі UnityBase вже працюють такі enterprise-рішення, як система електронного документообігу Megapolis.DocNet та Scriptum.DMS. Для high-load систем або інфраструктур із підвищеними вимогами до безпеки офіційна сторінка платформи рекомендує використовувати комерційні редакції Enterprise (EE) або Defence (DE). Вони підтримують розширені методи автентифікації (зокрема роботу з КЕП та інтеграцію з Active Directory) та додатковий контроль цілісності серверних модулів.
Завдяки поєднанню базової мережевої гігієни з глибокою сегментацією на рівні додатків (L7) підприємства критичної інфраструктури можуть побудувати стійку архітектуру, яка відповідає жорстким стандартам NIS2, зберігаючи при цьому безперервність виконання бізнес-операцій.
Порівняння підходів до сегментації критичних систем
| Параметр порівняння | Мережева сегментація (L3/L4) | Архітектурна сегментація додатків (L7 / Zero Trust) |
|---|---|---|
| Точка контролю доступу | IP-адреси, порти, підмережі, VPN-тунелі | Ідентичність користувача, контекст запиту, конкретні об'єкти даних |
| Стійкість до компрометації облікових даних | Низька (зловмисник у VPN отримує доступ до всього сегмента) | Висока (доступ обмежується на рівні окремих записів через RLS) |
| Вплив на бізнес-процеси | Високий ризик простоїв при зміні мережевих правил | Нульовий вплив на доступність (зміни вносяться на рівні політик додатку) |
| Деталізація аудиту | Лише мережеві транзакції (хто куди підключився) | Повний контекст операції (яку саме дію з якими даними виконано) |
Поширені питання
Як виконати вимоги NIS2 щодо сегментації без зупинки критичних бізнес-процесів?
Замість жорсткої фізичної ізоляції мереж слід впроваджувати логічну сегментацію на рівні додатків (L7) за допомогою інструментів RBAC та RLS. Це дозволяє контролювати доступ до даних на рівні окремих записів без зміни мережевих конфігурацій та зупинки інтеграцій.
Чому традиційні VPN та фаєрволи не забезпечують достатній рівень безпеки за стандартами CISA CPG?
Традиційні засоби захисту периметра безсилі перед компрометацією облікових даних (наприклад, через соціальну інженерію, як у кампаніях UAC-0145). Якщо зловмисник отримує доступ до VPN, він може вільно переміщуватися всередині мережевого сегмента (lateral movement).
Яка роль Row-Level Security (RLS) у захисті баз даних критичної інфраструктури?
RLS обмежує доступ користувачів до конкретних рядків у таблицях бази даних на основі їхнього контексту та ідентичності. Навіть за умови компрометації облікового запису, атакуючий не зможе отримати доступ до всієї бази даних, а лише до дозволеного вузького сегмента інформації.