Зростання кількості кіберінцидентів у критичній інфраструктурі вимагає кардинального перегляду архітектурних підходів. Згідно зі звітом ENISA Threat Landscape 2025, організації категорії essential entities за директивою NIS2 склали 53.7% усіх постраждалих від кібератак суб'єктів у період з липня 2024 по червень 2025 року. Ця статистика наочно демонструє, що пряме об'єднання корпоративних IT-систем та технологічних мереж (Operational Technology, OT) є неприпустимим ризиком. Бізнес об'єктивно потребує даних у реальному часі для аналітики, але досягати цього шляхом руйнування периметра безпеки не можна. Безпечна конвергенція IT та OT вимагає повної відмови від прямих з'єднань на користь суворої сегментації за стандартом ISA/IEC 62443 через промислові DMZ та шлюзи.
Чому пряма інтеграція ERP та SCADA — це архітектурна помилка високого ризику
Під тиском вимог щодо наскрізної аналітики розробники часто обирають найпростіший шлях — синхронну інтеграцію Point-to-point. Пряме підключення ERP-системи до баз даних SCADA або безпосередній запит до промислових контролерів (PLC) створює наскрізний вектор для транзитних атак. Якщо зловмисник компрометує робочу станцію в корпоративній мережі, він отримує можливість прямого втручання в технологічні процеси. Такі з'єднання ігнорують концепцію ізоляції рівнів (Purdue Model), перетворюючи будь-яку вразливість у бізнес-мережі на загрозу фізичної зупинки виробництва.
Концепція Zones and Conduits в ISA/IEC 62443: ізоляція критичних процесів
Стандарт ISA/IEC 62443, який охоплює понад 20 галузей промислової автоматизації, пропонує фундаментальний підхід до захисту — концепцію Zones and Conduits (Зони та Канали). Інфраструктура поділяється на логічні або фізичні зони активів із загальними вимогами до безпеки. Наприклад, рівень PLC та рівень SCADA формують окремі довірені зони.
Канал (Conduit) — це єдиний авторизований шлях обміну даними між зонами. Будь-який міжзонний трафік має проходити виключно через такий канал із застосуванням фільтрації та контролю доступу. Прямий транзит пакетів між несуміжними зонами суворо заборонений, що дозволяє мінімізувати blast radius (зону ураження) у разі компрометації одного з вузлів.
Проєктування Industrial DMZ (IDMZ): демілітаризована зона для обміну даними
Для безпечної передачі інформації між IT та OT створюється Industrial DMZ (IDMZ). Її головне правило: жоден мережевий пакет не повинен проходити безпосередньо з корпоративної мережі в технологічну через обидва периметри. Розглянемо приклад реалізації:
- OT-система (наприклад, Historian) реплікує накопичені дані на проміжний сервер всередині IDMZ.
- З'єднання ініціюється виключно зсередини захищеної зони (OT) у напрямку до IDMZ.
- Корпоративна ERP звертається лише до сервера в IDMZ для отримання необхідної аналітики.
- Міжмережеві екрани гарантують розрив сесій, повністю блокуючи наскрізний транзит пакетів.
Шлюзи повідомлень та API Gateways: як безпечно передавати телеметрію на IT-рівень
Для уникнення хаосу синхронних point-to-point з'єднань використовується інтеграція на основі патернів асинхронного обміну повідомленнями (Message-based integration). OT-системи публікують телеметрію в брокер повідомлень (MQTT або AMQP), розташований у IDMZ, а IT-системи підписуються на неї, не маючи доступу до контролерів. Проте самі по собі транспортні протоколи, такі як Kafka або MQTT, не гарантують безпеки; їх надійність цілком залежить від налаштувань TLS, автентифікації та сегментації.
Для обробки запитів, що надходять з корпоративної мережі до промислових сервісів, застосовується API-шлюз. Він дозволяє централізувати автентифікацію, перевірку цілісності даних, забезпечити спостережуваність та обмежити швидкість запитів (rate limiting), що критично важливо для захисту OT-рівня від DoS-перевантажень.
Контроль цілісності та аудит транзакцій на межі IT/OT сегментів
На межі розподілу мереж необхідний надійний програмний шар, здатний валідувати структуру даних і забезпечувати строгий контроль доступу. Як технологічний фундамент для побудови таких шлюзів часто застосовуються спеціалізовані інтеграційні платформи. Прикладом є low-code платформа UnityBase (спільна розробка компаній Intecracy Group, де ключовим розробником виступає InBase). Завдяки єдиній моделі метаданих (Domain metadata), платформа дозволяє швидко розгортати інтеграційні сервіси зі згенерованими REST API.
UnityBase здатна виступати безпечним посередником: вона приймає телеметрію, валідує її та надає контрольований доступ для корпоративних систем через механізми управління ролями (RBAC) та безпеку на рівні записів (RLS). Для систем критичної інфраструктури офіційна сторінка платформи рекомендує використовувати Enterprise або Defence редакції, оскільки вони підтримують розширений аудит дій (audit trail) та строгу автентифікацію для кожної транзакції. Фахівці Intecracy Group спираються на цей фундамент під час проєктування інтеграційних шарів, що ізолюють процеси керування від бізнес-додатків.
Важливо усвідомлювати: жоден API-шлюз чи брокер повідомлень не робить систему автоматично відповідною вимогам NIS2. Відповідність — це комплексний процес управління ризиками, аудиту та навчання персоналу, а не результат встановлення єдиного інструменту.
Матриця безпечного обміну даними між IT та OT сегментами
| Спосіб інтеграції | Рівень ризику | Застосування за ISA/IEC 62443 |
|---|---|---|
| Пряме з'єднання (Point-to-Point) | Максимальний (транзитні атаки на PLC) | Заборонено стандартом для критичних систем |
| Промислова DMZ (IDMZ) | Низький (повне розділення сесій) | Обов'язково для передачі файлів та реплікації Historian |
| Асинхронний брокер (MQTT/AMQP) | Мінімальний (ініціація тільки з OT) | Передача телеметрії та подій у реальному часі |
| Захищений API-шлюз | Низький (автентифікація та Rate Limiting) | Контрольований доступ IT-систем до сервісів OT-сегменту |
Поширені питання
Як реалізувати вимоги ISA/IEC 62443 щодо сегментації без зупинки існуючих процесів SCADA?
Впровадження зазвичай починають із пасивного збору даних через дзеркалювання портів (SPAN) та встановлення односпрямованих шлюзів. Це дозволяє налагодити реплікацію даних в IDMZ без втручання в активний технологічний процес. Поступово старі синхронні з'єднання виводяться з експлуатації та замінюються асинхронними каналами.
Які протоколи безпечні для передачі даних з OT в IT через DMZ?
Жоден протокол не є безпечним за замовчуванням. Безпеку забезпечує комбінація транспортного шифрування (TLS) та автентифікації. Архітектурне правило ISA/IEC 62443 вимагає, щоб ініціатором мережевої сесії завжди виступав клієнт із більш захищеної зони (OT) у напрямку до менш захищеної (DMZ).
Як налаштувати односпрямовану передачу даних за допомогою брокерів повідомлень?
Для реалізації паттерну data diode на рівні брокерів створюється міст (bridge). Брокер у сегменті OT налаштовується виключно на публікацію топіків у канал, тоді як брокер у DMZ працює на їх отримання без прав ініціації зворотних керуючих команд чи підтверджень доступу.