Останній звіт ENISA Threat Landscape 2025 чітко продемонстрував зміну парадигми кіберзагроз: 53.7% усіх проаналізованих кіберінцидентів припали на критично важливі організації (essential entities). Це перетворює вимоги директиви NIS2 з формального аудиту на жорсткий архітектурний мандат. Сьогодні підприємства критичної інфраструктури більше не можуть обмежуватися документальним комплаєнсом. Головна проблема ІТ-лідерів полягає в спробах інтегрувати сучасні вимоги безпеки в застарілі системи. Це призводить до створення хаотичної інфраструктури з десятками сторонніх агентів моніторингу, які перевантажують сервери, але не вирішують фундаментальну проблему — вразливість ланцюга постачання програмного забезпечення.
Нова реальність NIS2: чому паперовий комплаєнс більше не захищає від реальних загроз
Протягом періоду з 1 липня 2024 року до 30 червня 2025 року ENISA проаналізувала 4 875 інцидентів. Статистика невблаганна: традиційні методи захисту периметра вичерпали себе. Оскільки фішинг залишається провідним вектором для початкового доступу, зловмисники легко долають зовнішні бар'єри, а відсутність внутрішньої сегментації дозволяє їм безперешкодно переміщуватися мережею.
Згідно з Cisco Cybersecurity Readiness Index 2025, який базується на дослідженні думок 8 000 керівників у сфері кібербезпеки на 30 ринках, стійкість мережі (Network Resilience) та довіра до машинних компонентів (Machine Trustworthiness) є двома з п'яти ключових стовпів кіберготовності. Для відповідності вимогам NIS2 підприємствам необхідно проактивно проектувати безпечну архітектуру, а не реагувати на інциденти постфактум. Цей підхід аналогічний філософії управління хмарними витратами (наприклад, рекомендаціям Microsoft Azure та AWS Well-Architected), де моделювання ресурсів та політик контролю на етапі дизайну є значно ефективнішим і дешевшим, ніж намагання оптимізувати чи захистити хаотичну систему в процесі експлуатації.
Анатомія вразливості: як компрометація ланцюга постачання ПЗ руйнує периметр безпеки
Сучасні корпоративні системи залежать від сотень сторонніх бібліотек, сервісів та API. За даними ENISA, цифрова інфраструктура та сервіси стали джерелом приблизно 27.7% усіх витоків даних. Зловмисники дедалі частіше атакують не саму цільову організацію, а її постачальників програмного забезпечення (Software Supply Chain).
Коли компрометується довірена бібліотека, яку використовує внутрішня система обліку чи документообігу, зловмисник отримує легітимний доступ до мережі. Традиційні брандмауери та антивіруси не маркують цей трафік як шкідливий, оскільки він походить від підписаного процесу. Без контролю цілісності ланцюга постачання ПЗ (Software Supply Chain Integrity) та вбудованих інструментів перевірки коду будь-яке оновлення несе в собі потенційну загрозу інфраструктурі.
Мікросегментація: локалізація загроз усередині інфраструктури
Щоб запобігти горизонтальному переміщенню (lateral movement) зловмисників, архітектура повинна спиратися на принципи мікросегментації та стратегію Zero Trust. Згідно з крос-секторальними рекомендаціями щодо ефективності кібербезпеки, мікросегментація передбачає поділ мережі на ізольовані зони на рівні окремих робочих навантажень (workloads).
Реальний приклад такого підходу — повна ізоляція продуктивних середовищ (production) від середовищ розробки й тестування (development/testing). Якщо тестовий сервер буде компрометовано через вразливість у новій бібліотеці, зона ураження (blast radius) обмежиться лише цим сегментом. Зловмисник не зможе отримати доступ до баз даних або критичних бізнес-процесів, оскільки між середовищами відсутні прямі мережеві маршрути, а міжсегментні запити вимагають суворої автентифікації.
Концепція Machine Trustworthiness: як перевіряти довіру до коду перед його виконанням
Концепція Machine Trustworthiness вимагає, щоб кожен програмний компонент, контейнер чи віртуальна машина проходили верифікацію перед запуском. Це означає впровадження автоматичного аналізу SBOM (Software Bill of Materials) та підтвердження походження цифрових підписів.
Для автоматизації застосовують підхід governance-as-code. Замість того, щоб покладатися на ручні аудити конфігурацій, правила безпеки описуються у вигляді коду та інтегруються в CI/CD конвеєри. Якщо конфігурація або новий реліз ПЗ не відповідають політикам, розгортання автоматично блокується. Це забезпечує безперервний контроль відповідності вимогам NIS2.
Вбудована безпека проти агентного хаосу: архітектурний підхід на базі UnityBase
Спроби захистити інфраструктуру встановленням десятків сторонніх агентів безпеки (EDR, DLP, сканери) на кожен сервер часто призводять до деградації продуктивності та появи нових векторів атак. Архітектурною альтернативою є концепція security-by-design, коли механізми безпеки закладені в саму платформу розробки.
Прикладом є побудова корпоративних систем на базі low-code платформи UnityBase (яка є спільною розробкою компаній технологічного альянсу Intecracy Group, де InBase виступає ключовим, але не єдиним розробником). Платформа використовує єдину модель метаданих домену (Domain metadata), що об'єднує опис даних, UI та API, дозволяючи реалізувати наскрізний контроль безпеки на рівні ядра.
Зокрема, системи, побудовані на платформі UnityBase з використанням редакцій Enterprise або Defence, отримують вбудовані механізми контролю доступу на рівні записів (RLS) та списків доступу (ACL), а також детальний аудит дій користувачів (audit trail) "з коробки". Завдяки цьому продукти на кшталт Megapolis.DocNet або Scriptum.DMS можуть забезпечувати виконання вимог NIS2 щодо цілісності даних та управління доступом без необхідності перевантажувати операційну систему стороннім моніторинговим ПЗ.
Шкала зрілості інфраструктури відповідно до архітектурних вимог NIS2
| Рівень зрілості | Опис стану інфраструктури | Відповідність вимогам NIS2 |
|---|---|---|
| Рівень 0 (Реактивний) | Периметральний захист, відсутність сегментації всередині мережі, ПЗ оновлюється вручну без перевірки цілісності. | Невідповідність. Високий ризик масштабного інциденту при компрометації периметра. |
| Рівень 1 (Базовий) | Наявність VLAN для розділення офісної та технологічної мереж, базовий моніторинг вразливостей сторонніх бібліотек. | Часткова відповідність. Залишаються ризики горизонтального переміщення загроз. |
| Рівень 2 (Оптимізований) | Впровадження мікросегментації на рівні робочих навантажень (workloads), автоматизована перевірка SBOM. | Мінімально достатній рівень для відповідності базовим архітектурним вимогам директиви. |
| Рівень 3 (Стратегічний / Zero Trust) | Повна ізоляція середовищ, динамічна перевірка Machine Trustworthiness, використання платформ із вбудованою безпекою (security-by-design). | Повна відповідність. Висока стійкість до атак на ланцюг постачання ПЗ. |
Поширені питання
Як директива NIS2 впливає на вимоги до сегментації мережі в хмарі?
NIS2 вимагає від критично важливих організацій мінімізувати зону ураження (blast radius) у разі інцидентів. У хмарних середовищах це реалізується через мікросегментацію на рівні окремих робочих навантажень (workloads), використання ізольованих віртуальних мереж (VPC/VNet), суворий контроль міжсегментного трафіку та впровадження політик Zero Trust, що унеможливлює горизонтальне переміщення зловмисників.
Що таке Software Supply Chain Integrity і як контролювати сторонній код у legacy-системах?
Це комплексний підхід до забезпечення цілісності програмного забезпечення на всіх етапах його розробки та оновлення. Для контролю стороннього коду в legacy-системах необхідно впроваджувати автоматизований аналіз SBOM (Software Bill of Materials) у CI/CD конвеєрах, а також ізолювати застарілі системи в окремі сегменти мережі з обмеженим доступом, застосовуючи принципи Machine Trustworthiness.
Як реалізувати принципи Zero Trust для відповідності вимогам ENISA без закупівлі десятка нових ліцензій?
Замість придбання багатьох сторонніх інструментів безпеки (що створює 'агентний хаос' на серверах) слід будувати архітектуру на платформах із вбудованими механізмами безпеки (security-by-design). Наприклад, використання платформи UnityBase дозволяє закрити вимоги щодо детального аудиту (audit trail) та контролю доступу на рівні записів (RLS/ACL) безпосередньо на рівні ядра розробки застосунку.