Архітектура мережевої безпеки для критичної інфраструктури України: що мати в 2026

З 2022 року українські оператори критичної інфраструктури — енергетика, телеком, водопостачання, транспорт, державні підприємства — стали постійними мішенями. Атаки більше не поодинокі: це систематичні кампанії з розвідкою, закріпленням в мережі і тривалою присутністю до моменту активної фази. CERT-UA фіксує десятки задокументованих інцидентів на рік лише з публічно відомих.

Архітектура мережевої безпеки в цьому контексті — не питання відповідності документам. Це питання здатності продовжувати роботу під час атаки і відновлюватися після неї.

Ця стаття розбирає, що зараз є стандартом для UA операторів критичної інфраструктури: що вимагає законодавство, де найбільші архітектурні прогалини на практиці, і як OT/IT конвергенція змінює картину ризиків для енергетики.

Реальність 2026: що відбувається з українськими операторами

Атаки на UA критичну інфраструктуру мають кілька стабільних патернів, задокументованих CERT-UA і Держспецзв'язку:

Ціль — доступність, не тільки дані. На відміну від комерційних атак, де основна мета — дані або вимагання, атаки на критінфру в Україні цілеспрямовано б'ють по операційній безперервності. Виведення з ладу диспетчерських систем або систем обліку — не побічний ефект, а пряма мета.

Тривала прихована присутність. Зафіксовані випадки, коли зловмисники перебували в мережі тижні або місяці до активної фази. Це означає, що периметральна безпека сама по собі недостатня — потрібна детекція аномалій всередині мережі.

OT як вектор. Енергетичні підприємства з підключеними SCADA і ICS-системами стикаються зі спробами впливу на технологічні процеси через IT-периметр. Модель "OT відокремлено і тому захищено" більше не відповідає реальній архітектурі більшості підприємств.

Постачальники і підрядники — слабка ланка. Кілька задокументованих інцидентів почалися через компрометацію облікових даних зовнішнього підрядника або через інструменти віддаленого доступу, встановлені для сервісного обслуговування.

Що вимагає українське законодавство

Закон "Про основні засади забезпечення кібербезпеки України"

Закон (№ 2163-VIII, 2017) встановлює базові обов'язки для операторів критичної інформаційної інфраструктури (КІІ): проведення аудитів кібербезпеки, впровадження систем захисту, взаємодія з CERT-UA, реагування на кіберінциденти. Перелік об'єктів КІІ затверджується Кабінетом Міністрів — підприємства енергетики, телекому, водопостачання, транспорту, фінансового сектору потрапляють туди в першу чергу.

Закон про критичну інфраструктуру

Закон № 1882-IX (2021) з'ясував категорії критичної інфраструктури і розподіл відповідальності між секторальними регуляторами та Держспецзв'язку. Для операторів цей закон означає: обов'язковий облік об'єктів критичної інфраструктури, оцінка ризиків, плани захисту. Вимоги щодо кібербезпеки конкретного об'єкта формуються в координації з профільним CSIRT і секторальним регулятором.

НД ТЗІ — технічний захист інформації

Нормативні документи з технічного захисту інформації, розроблені ДССТЗІ (Держспецзв'язку), регулюють технічні вимоги до захисту інформації на об'єктах КІІ. Це включає вимоги до побудови захищених комплексів (ССЗІ — система стандартизованого захисту інформації), атестацію об'єктів інформатизації, вимоги до криптографічного захисту для систем, що обробляють інформацію з обмеженим доступом.

Практичний наслідок НД ТЗІ для мережевої архітектури: вимоги до фізичної і логічної сегментації, контролю доступу, аудиту подій — не рекомендації, а обов'язкові параметри для атестованих об'єктів. Для систем, що обробляють службову або конфіденційну інформацію, атестація об'єкта інформатизації є нормативною вимогою, а не внутрішнім рішенням організації.

Сегментація мереж: від вимоги до архітектурного рішення

Сегментація — базовий принцип і обов'язок одночасно. Для операторів КІІ плоска мережа, де компрометація однієї точки дозволяє рух до критичних систем, є архітектурним ризиком і невідповідністю нормативним вимогам.

Мінімальна структура сегментації для оператора критінфри:

• Відокремлення корпоративної IT від OT-мережі (технологічного сегменту)

• Відокремлення DMZ (зовнішньодоступних систем) від внутрішньої мережі

• Сегментація управлінських систем SCADA/DCS від загальної OT-мережі

• Окремий сегмент для привілейованого доступу (jump servers, PAM)

Мікросегментація — визначення дозволених потоків на рівні застосунку або навантаження — знижує поверхню атаки всередині вже скомпрометованого периметру. Для великих підприємств з розподіленою інфраструктурою (кілька майданчиків, підстанцій, об'єктів) це стає практичним стандартом, а не опцією.

ССЗІ та роль ДССТЗІ. Підприємства, що проходять атестацію об'єктів інформатизації відповідно до НД ТЗІ, будують ССЗІ — комплекс засобів захисту. Технічна документація ССЗІ включає схему захищеної мережі з описом сегментації, переліком засобів захисту, моделлю загроз і політиками доступу. ДССТЗІ і акредитовані організації виконують технічну експертизу відповідності вимогам.

OT/IT конвергенція: де найбільший ризик для UA енергетики

Більшість великих українських енергетичних підприємств перейшли від повністю ізольованих OT-мереж до частково або повністю підключених середовищ. Це сталося поступово: спочатку дистанційний моніторинг, потім інтеграція з ERP і системами обліку, потім підключення підрядників. Результат — технологічна мережа, яка вже не є повітряно-ізольованою, але і не захищена як IT-мережа.

Специфічні виклики UA OT-середовищ:

Застарілі системи без підтримки. Значна частина промислового обладнання, встановленого 15-25 років тому, працює на операційних системах без актуальних патчів і без можливості оновлення без зупинки виробництва. Компенсаційні засоби — мережева ізоляція, application whitelisting, моніторинг трафіку — в таких випадках замінюють патчування, але вимагають документального обгрунтування.

Доступність важливіша за конфіденційність. В IT-моделі тріада CIA (Confidentiality, Integrity, Availability) орієнтована рівномірно або з акцентом на конфіденційність. В OT-середовищах дозволи на технологічний процес, відключення електроенергії, зупинка водопостачання — це негайні наслідки. Архітектура безпеки має бути розроблена з урахуванням цього: засоби захисту, що перевантажують канал або вводять затримки в комунікацію між компонентами SCADA, неприйнятні.

OT-протоколи не розуміють стандартні IT-інструменти. Modbus, DNP3, IEC 61850, PROFINET не аналізуються стандартними IT-SIEM. Моніторинг OT-трафіку вимагає рішень, що розуміють ці протоколи і можуть відрізнити аномальну команду від штатного трафіку. Пасивне прослуховування (без активних запитів) є стандартом — активні зонди можуть порушити роботу промислових систем.

Точка конвергенції — найбільш атакована межа. З'єднання між корпоративною IT-мережею і OT-сегментом — зона максимального ризику. Стандарт для критінфри: однонаправлені шлюзи безпеки (дата-діоди) для захисту OT від IT, або промислові firewall з розумінням OT-протоколів і суворим allowlisting трафіку на цій межі.

ZTNA і привілейований доступ: від VPN до контрольованого підключення

Стандартна VPN, що дає мережевий доступ до внутрішніх ресурсів, — модель, яка не відповідає сучасному ландшафту загроз для критінфри. Особливо коли мова йде про доступ підрядників до OT-систем.

ZTNA-підхід для оператора критичної інфраструктури:

• Перевірка ідентичності і стану пристрою до надання доступу

• Доступ до конкретних систем, а не до всього мережевого сегменту

• Обмеження в часі — сесія відкрита на конкретну задачу, а не постійна

• MFA для кожного сеансу без винятків

• Запис сесій для аудиту і розслідування інцидентів

Управління привілейованим доступом (PAM) — це практичний каркас для реалізації ZTNA для адміністративних і сервісних облікових записів. Just-in-time видача прав, автоматична ротація паролів сервісних акаунтів, workflow затвердження для чутливих операцій, централізований аудитний журнал — кожен з цих елементів і закриває реальний вектор атаки, і дає доказову базу для перевіряючих органів.

Криптографія: ДСТУ і міжнародні стандарти — як вибирати

Для систем, що обробляють інформацію з обмеженим доступом відповідно до НД ТЗІ і вимог ДССТЗІ, криптографічний захист повинен базуватися на ДСТУ-сертифікованих алгоритмах. ДСТУ 4145-2002 (ECDSA на основі скручених кривих) і ДСТУ 7624:2014 (Калина — блоковий шифр) — стандарти, що діють для державних і критичних систем.

Практичний поділ для архітектора:

• Системи, що обробляють службову інформацію або підключені до державних систем: ДСТУ-криптографія, сертифіковані засоби захисту

• Корпоративні IT-системи, що не обробляють обмежену інформацію: TLS 1.2/1.3 за міжнародними стандартами прийнятний

• Застарілі протоколи (SSL 3.0, TLS 1.0, TLS 1.1, DES, 3DES): вимкнути по всьому середовищу — без винятків

• OT-зв'язок між компонентами: якщо протокол підтримує шифрування (IEC 61850 GOOSE/SV підтримує) — використовувати; якщо ні — компенсувати на рівні мережі

Управління сертифікатами і ключами — окрема операційна задача. Прострочений сертифікат на системі моніторингу або диспетчерській системі — і аудиторська знахідка, і потенційна точка входу. Автоматизований облік і нагадування про поновлення — мінімум.

Threat detection: що шукати в рішеннях для SIEM і EDR

Виявлення загроз — функціональна вимога: підприємство, що не може виявити присутність зловмисника, не може адекватно реагувати і звітувати. Це і нормативна вимога (Закон про КІІ передбачає взаємодію з CERT-UA і надання інформації про інциденти), і практична необхідність.

SIEM для критінфри — на що дивитися:

• Підтримка UA-специфічних джерел логів (AD, NTA, журнали подій Windows/Linux, OT-засоби моніторингу)

• Корреляційні правила під відомі тактики атак на критінфру (MITRE ATT&CK for ICS)

• Можливість ізольованого розгортання on-premise — для систем без права на хмарну обробку

• Швидкість пошуку по великих обсягах логів — часові вікна інцидент-репортингу стислі

EDR для OT-середовищ:

• Пасивний режим моніторингу — без агресивних агентів, що споживають ресурси

• Підтримка застарілих ОС (Windows XP/7 все ще є в частині OT-систем)

• Інтеграція з OT-специфічними рішеннями моніторингу (Claroty, Dragos, Nozomi і аналоги)

Ключова точка: детекція без реагування не є управлінням інцидентами. Черга алертів без процесу тріажу і відповідального — це не система безпеки, а ілюзія безпеки.

Інцидент-репортинг: зобов'язання за українським законодавством

Оператори КІІ мають чіткі зобов'язання щодо повідомлення про кіберінциденти. Основний канал — CERT-UA (Урядова команда реагування на кіберінциденти, діє при ДССТЗІ).

Що підлягає повідомленню: кіберінциденти, що вплинули або могли вплинути на функціонування об'єктів критичної інформаційної інфраструктури. Поріг для повідомлення свідомо встановлений низьким — краще надіслати повідомлення і отримати підтримку CERT-UA, ніж приховати інцидент і втратити можливість скористатися ресурсами реагування.

Практичне значення для архітектури:

• Системи детекції мають давати достатньо інформації для первинної класифікації інциденту протягом кількох годин, а не діб

• Процедури реагування мають включати призначену особу, відповідальну за зв'язок з CERT-UA

• Форензік-докази (логи, PCAP, знімки стану систем) мають зберігатися достатньо довго для розслідування — типовий термін зберігання логів для критінфри не менше 12 місяців

CERT-UA також надає технічну підтримку при реагуванні на інциденти і публікує IOC (Indicators of Compromise) для відомих кампаній — підключення до цих фідів і перевірка власної мережі на наявність відомих IOC є базовим заходом.

Якщо у вас є EU операції або клієнти: NIS 2 Article 21 і 23

Для операторів, що мають операції або клієнтів у ЄС, або постачають послуги EU-суб'єктам, NIS 2 (Директива ЄС 2022/2555) може застосовуватися безпосередньо або через вимоги контрагентів.

NIS 2 Article 21 визначає десять категорій обов'язкових заходів безпеки: аналіз ризиків, управління інцидентами, безперервність бізнесу, безпека ланцюга постачання, управління вразливостями, оцінка ефективності засобів захисту, кібергігієна і навчання, криптографічна політика, контроль доступу і управління активами, MFA. Це reference framework, що збігається з українськими вимогами по суті, хоч і виходить з іншої нормативної бази.

NIS 2 Article 23 встановлює строки інцидент-репортингу для EU-суб'єктів: раннє повідомлення — 24 години з моменту виявлення, повне повідомлення — 72 години, фінальний звіт — 1 місяць. Ці строки більш стислі, ніж звичайна практика — і вимагають, щоб системи детекції і тріажу забезпечували результат в межах кількох годин, а не днів.

Якщо ваша організація потенційно підпадає під NIS 2, варто провести попередню оцінку обсягу до того, як EU-регулятор ініціює запит.

Що перевірять при аудиті

Перевіряючі органи — ДССТЗІ, секторальні регулятори, а також зовнішні аудитори при ISO 27001 або галузевій сертифікації — звертають увагу на одні й ті ж речі:

1. Задокументована методологія оцінки ризиків і її результати

2. Схеми мережевої архітектури — поточний стан, включаючи OT/IT межі

3. Реалізована сегментація з доказами (конфігурації, тести)

4. Процедури управління привілейованим доступом і документальні докази їх виконання

5. Процедури виявлення інцидентів і реагування, включаючи канали зв'язку з CERT-UA

6. Криптографічна політика з переліком застосовуваних алгоритмів і засобів

7. Результати останніх тестувань — пентест, оцінка вразливостей

8. Наявність і тестування планів безперервності для критичних функцій

Прогалини, виявлені при перевірці, як правило, дають строковий припис на усунення. Системні порушення можуть означати обмеження діяльності або санкції відповідно до профільного законодавства.

З практики: анонімний кейс

Один з українських операторів у секторі енергетики виявив після аудиту, що технологічна мережа і корпоративна IT фактично об'єднані на рівні комутатора 3-5 років тому — під час розгортання нової системи обліку — і ніхто не задокументував і не обмежив цей зв'язок. Окремо: підрядник з обслуговування SCADA мав постійно активний VPN-доступ до OT-сегменту з використанням облікових даних, виданих 7 років тому і ніколи не змінених.

Жодне з цих двох питань не вимагало складних технічних рішень. Перше — перегляд топології і VLAN-сегментація. Друге — вимога до підрядника перейти на PAM зі сесійними обліковими даними. Складним було виявити і задокументувати поточний стан до того, як прийшов аудитор або зловмисник.

Якщо ваша організація — оператор критичної інфраструктури в Україні і вам потрібна технічна оцінка поточного стану архітектури мережевої безпеки або підготовка до перевірки ДССТЗІ — ми проводимо gap-аналіз з прив'язкою до вимог українського законодавства і НД ТЗІ. Розкажіть про вашу ситуацію.