Конвергенція інформаційних (IT) та операційних (OT) технологій є необхідною умовою для впровадження миттєвої аналітики та предиктивного обслуговування обладнання. Проте зворотним боком цієї інтеграції стало розширення вектора атак на об'єкти критичної інфраструктури. На тлі жорстких вимог директиви NIS2 пряма інтеграція корпоративних та промислових систем перетворилася на критичну вразливість, що вимагає негайної архітектурної перебудови.
Згідно зі звітом ENISA Threat Landscape 2025, на організації, які підпадають під класифікацію критично важливих суб'єктів (essential entities) у рамках NIS2, припало 53.7% від усіх постраждалих організацій, проаналізованих за звітний період. Безпечна інтеграція потребує повної відмови від прямих зв'язків між ERP-системами та SCADA на користь суворої сегментації за стандартом ISA/IEC 62443 через промислову демілітаризовану зону (IDMZ) із використанням API-шлюзів та асинхронних брокерів повідомлень.
Чому пряма інтеграція ERP та SCADA — це архітектурна помилка
Бажання отримати дані про випуск продукції безпосередньо з виробничої лінії часто штовхає розробників на найпростіший шлях: налаштування прямого point-to-point підключення корпоративної бази даних (ERP або BI) до бази даних SCADA чи MES-системи. Такий підхід, хоч і описаний у застарілих патернах системної інтеграції, сьогодні створює дві фундаментальні загрози:
- Порушення периметра безпеки. Пряме з'єднання порушує ізоляцію промислової мережі. У разі компрометації корпоративного IT-сегмента (через фішинг чи вразливості офісних сервісів) зловмисники отримують прямий мережевий шлях до фізичних контролерів, що дозволяє маніпулювати процесами.
- Ризик відмови real-time систем. Системи промислового керування спроєктовані для безперервної роботи в режимі реального часу. Масові аналітичні запити з IT-департаменту можуть перевантажувати SCADA-сервери або блокувати таблиці баз даних, що призводить до затримок у передачі критичних команд керування.
Концепція Zones and Conduits в ISA/IEC 62443: проєктування меж безпеки
Стандарт ISA/IEC 62443 визначає фреймворк безпеки для систем промислової автоматизації через концепцію «Зон та каналів зв'язку» (Zones and Conduits). Архітектура розбивається на логічні зони (рівні за моделлю Purdue) з однаковими вимогами до безпеки.
Промислові мережі (рівні 0-3) ізолюються від корпоративних систем (рівні 4-5). Для легітимного обміну даними проєктується рівень 3.5 — промислова демілітаризована зона (IDMZ). Зв'язок між зонами здійснюється виключно через захищені канали (Conduits). Жоден пакет даних не може проходити транзитом через IDMZ без термінації та інспекції на проміжному шлюзі.
Анатомія інтеграційного шлюзу в IDMZ: API Gateways та брокери
Реалізація каналів зв'язку базується на патернах інтеграції корпоративних систем (Enterprise Integration Patterns). Замість крихких прямих з'єднань використовуються керовані шлюзи.
Розгортання API-шлюзу як проксі-сервера
Для контролю синхронних запитів у DMZ розгортається API Gateway (наприклад, Kong або аналогічні рішення). ERP-система не комунікує безпосередньо з MES; вона надсилає запит на API Gateway. Шлюз централізує автентифікацію, забезпечує термінацію TLS та застосовує обмеження частоти запитів (Rate Limiting). Це гарантує, що надмірний трафік буде відхилено до того, як він досягне вразливих OT-систем.
Забезпечення цілісності: Schema Registry та асинхронна розв'язка
Для передачі масивів телеметрії рекомендовано використовувати асинхронних брокерів повідомлень (наприклад, Apache Kafka). Це створює повну ізоляцію за часом та протоколом. Впровадження технології Change Data Capture (CDC) дозволяє відстежувати зміни у промислових базах даних і передавати їх у вигляді подій без прямого виконання SQL-запитів до SCADA.
Для забезпечення надійності даних застосовується Schema Registry — інструмент контролю контрактів даних. Він гарантує, що лише валідована телеметрія з правильною структурою потраплятиме з OT-сегмента до IT-аналітики, запобігаючи збоям на корпоративному рівні.
Платформний підхід консорціуму Intecracy
Створення надійної архітектури потребує безпечних інструментів як на боці OT, так і на боці IT. Консорціум Intecracy Group пропонує платформний підхід для проєктування такої інфраструктури. Для промислових IoT/SCADA рішень використовується платформа AZIOT, а корпоративні застосунки-споживачі даних будуються на базі платформи UnityBase (спільна розробка компаній консорціуму, де ключовим розробником є InBase).
UnityBase — це low-code платформа, яка дозволяє створювати high-load enterprise-системи із вбудованими механізмами інтеграції зі шлюзами в IDMZ (через автоматично згенеровані REST API). Для проєктів, що підпадають під суворі регуляторні вимоги (такі як NIS2) або потребують розгортання on-premises, офіційна документація платформи рекомендує використовувати комерційні редакції Enterprise або Defence. Вони забезпечують контроль доступу на рівні рядків (RLS), інтеграцію з Active Directory та незмінний аудит дій (audit trail), що є критичним для безпечної обробки технологічної інформації.
Відповідність NIS2: чек-лист для архітектора системної інтеграції
Для проєктування захищеної інтеграційної інфраструктури важливо розуміти різницю в рівнях загроз різних архітектурних патернів.
| Патерн інтеграції | Рівень загрози | Вплив на OT-сегмент | Відповідність ISA/IEC 62443 |
|---|---|---|---|
| Пряме підключення (Direct DB/API) | Критичний | Високий ризик відмови real-time систем | Не відповідає |
| API Gateway у DMZ (Proxy) | Низький | Контрольований (синхронні запити з автентифікацією) | Частково (для контрольованих API) |
| Асинхронний брокер + CDC | Мінімальний | Нульовий (повна ізоляція за часом і протоколом) | Повна (рекомендований патерн) |
Чек-лист архітектора для відповідності вимогам кібербезпеки:
- Ізоляція трафіку: Відмова від прямих point-to-point підключень; термінація всіх з'єднань у демілітаризованій зоні (IDMZ).
- Контроль контрактів даних: Використання Schema Registry для валідації повідомлень, що надходять з OT в IT.
- Захист від перевантажень: Впровадження Rate Limiting на рівні API-шлюзів для захисту контролерів.
- Автентифікація: Централізована перевірка доступів та шифрування на межі сегментів.
Побудова інтеграційних «шлюзів» вимагає фундаментальної зміни архітектури, але це єдиний надійний шлях до безпечної конвергенції IT та OT у сучасному ландшафті загроз.
Поширені питання
Як побудувати безпечний шлюз між IT та OT згідно з вимогами ISA/IEC 62443?
Безпечний шлюз будується на основі концепції Zones and Conduits (Зон та каналів зв'язку). Прямі з'єднання між корпоративною мережею (IT) та технологічною (OT) забороняються. Створюється промислова демілітаризована зона (IDMZ, рівень 3.5 за моделлю Purdue), в якій термінуються всі комунікації з використанням проксі-серверів, API-шлюзів та асинхронних брокерів повідомлень.
Які протоколи (OPC UA, MQTT, HTTPS) використовувати для передачі даних у промислову DMZ?
Усередині промислового сегмента функціонують протоколи на кшталт OPC UA, проте їхня пряма передача до IT не рекомендується. У DMZ інтеграційний шлюз повинен здійснювати трансляцію протоколів, конвертуючи дані у безпечні веб-стандарти (HTTPS, JSON) або публікуючи події через брокери (наприклад, MQTT у поєднанні з Kafka) з контролем автентифікації.
Як забезпечити відповідність вимогам NIS2 при інтеграції SCADA з корпоративними системами?
Для забезпечення відповідності NIS2 необхідно усунути всі прямі підключення (Direct DB/API) до SCADA, ізолювавши процеси через IDMZ. Використовуйте API Gateways для контролю синхронних запитів з обов'язковим Rate Limiting, а також асинхронні брокери із Change Data Capture (CDC) та Schema Registry для безпечної передачі телеметрії без впливу на продуктивність контролерів.