Сучасне промислове підприємство потребує даних для оптимізації витрат та впровадження предиктивного обслуговування. Це зумовлює необхідність передавати телеметрію з технологічного контуру (OT) до сервісів хмарної аналітики. Проте пряме з'єднання промислового обладнання із зовнішніми мережами створює критичні ризики для безперервності фізичних процесів.
Згідно зі звітом ENISA Threat Landscape 2025, протягом звітного періоду (з 1 липня 2024 року по 30 червня 2025 року) було проаналізовано 4 875 інцидентів. Статистика свідчить, що 53.7% постраждалих організацій належали до категорії критично важливих (essential entities) за директивою NIS2. Це підкреслює, що зловмисники фокусуються на інфраструктурі, де кібератака може призвести до зупинки виробництва. Перед технічними директорами та CISO постає завдання: інтегрувати хмарну аналітику, не експонуючи промислові контролери (PLC) у зовнішнє середовище.
Пастка прямої інтеграції: чому хмара не повинна бачити PLC
Базовою архітектурною помилкою є створення прямого мережевого маршруту від PLC до хмарного сховища. Промислові протоколи (наприклад, Modbus TCP чи базові версії OPC UA) розроблялися для ізольованих середовищ і часто позбавлені надійних механізмів автентифікації та шифрування.
Підключення контролера до хмари, навіть із використанням VPN, створює загрозу. У разі компрометації хмарного середовища або облікових записів IT-персоналу зловмисник отримує можливість надсилати керуючі команди безпосередньо на PLC. Оскільки хмарній аналітиці потрібна виключно історична телеметрія, прямий зв'язок є невиправданим нівелюванням фізичного периметра безпеки.
Архітектурна ізоляція замість класичних фаєрволів
Масштабне дослідження Cisco Cybersecurity Readiness Index 2025, що охопило 8 000 бізнес-лідерів у 30 країнах, демонструє необхідність перегляду підходів до захисту. Встановлення класичного міжмережевого екрана (Firewall) між корпоративною мережею та виробництвом вже не забезпечує достатньої сегментації.
Відповідно до сучасних настанов щодо захисту критичної інфраструктури (зокрема принципів архітектурної ізоляції, співзвучних із CISA CPG), необхідно реалізувати розірвання сесій на межі сегментів:
- Повна заборона прямої IP-маршрутизації між OT-сегментом та будь-якою зовнішньою мережею.
- Обов'язкова зміна протоколу: дані передаються через проміжні вузли (шлюзи).
- Відсутність технічної можливості ініціювати з'єднання ззовні всередину промислової мережі.
Односпрямований шлюз (Data Diode) та протокольна ізоляція на практиці
Найбільш надійним патерном для експорту промислових даних є застосування односпрямованих шлюзів (data diodes). Це дозволяє фізично або програмно унеможливити проходження пакетів у зворотному напрямку — до контролерів.
Типовий процес безпечної передачі виглядає так:
- Локальний промисловий шлюз в OT-мережі збирає телеметрію з PLC за внутрішніми протоколами. Шлюз не має зовнішньої IP-адреси.
- Протокол перетворюється: дані конвертуються у безпечний структурований формат (наприклад, JSON). Промисловий протокол не залишає межі цеху.
- Сформований пакет передається через односпрямований інтерфейс (апаратний чи строгий програмний дата-діод), який блокує будь-який вхідний трафік.
- Зовнішній брокер в IT-сегменті приймає дані та відправляє їх у хмару через MQTT або HTTPS.
Роль проміжної платформи: фільтрація, аудит та контроль доступу
Для керування такою інфраструктурою потрібен надійний програмний шар на межі мереж. Збір, нормалізацію та первинну обробку промислових даних зсередини OT-контуру зазвичай реалізують через кіберфізичні системи, такі як AZIOT Platform.
Зі свого боку, для створення захищених шлюзів аудиту та керування доступом на стику IT та OT доцільно використовувати платформу UnityBase. UnityBase — це full-stack JavaScript low-code платформа, яка є спільною розробкою компаній Intecracy Group (де InBase виступає ключовим розробником). Завдяки механізмам Domain metadata, платформа дозволяє налаштувати ізольований шар управління транзакціями.
Використання механізмів платформи UnityBase забезпечує:
- Реалізацію рольової моделі (RBAC) для суворого розмежування прав доступу до налаштувань інтеграційних шлюзів.
- Ведення незмінного журналу транзакцій (audit trail), що критично важливо для відповідності вимогам NIS2 та проведення розслідувань кіберінцидентів.
- Можливість розгортання on-premises для повного збереження контролю над периметром.
Для проєктів критичної інфраструктури з підвищеними вимогами до безпеки офіційна документація платформи рекомендує використання комерційних редакцій Enterprise (EE) або Defence (DE), які надають розширені можливості автентифікації та контролю цілісності.
Як побудувати безпечний міст між OT та хмарою
При плануванні архітектури слід враховувати принципи оптимізації витрат. Як зазначається у рекомендаціях Microsoft Azure Well-Architected (розділ Cost Optimization), моделювання витрат та безпеки на етапі дизайну є значно ефективнішим, ніж спроби оптимізувати систему постфактум. Додавання шарів безпеки до вже працюючої небезпечної архітектури призводить до надмірних капітальних витрат.
Також варто інтегрувати підхід FinOps Framework, який робить управління хмарною інфраструктурою спільною відповідальністю команд інженерів, безпеки та фінансів. Це гарантує, що витрати на транспортування телеметрії через захищені шлюзи залишатимуться економічно виправданими.
Матриця архітектурного захисту IT/OT при хмарній інтеграції
| Рівень архітектури | Основна вимога безпеки | Технічна реалізація |
|---|---|---|
| Рівень OT (PLC/SCADA) | Пряме підключення заборонено | Збір даних локальним шлюзом без зовнішньої IP-адреси. |
| Рівень шлюзу (Gateway) | Протокольна ізоляція | Конвертація Modbus/OPC UA у JSON з фільтрацією полів. |
| Транспортний рівень | Односпрямована передача | Блокування зворотного трафіку до OT (Data Diode). |
| Рівень аудиту (UnityBase) | Контроль доступу та логування | Застосування RBAC та незмінного журналу аудиту (audit trail) для конфігурацій. |
| Хмарний рівень | Обмеження повноважень | Отримання лише деперсоналізованої телеметрії без прав керування. |
Архітектурна ізоляція дозволяє промисловим компаніям користуватися всіма перевагами хмарних технологій, зберігаючи впевненість у тому, що фізичні активи повністю ізольовані від зовнішніх кіберзагроз.
Поширені питання
Як забезпечити передачу даних у хмару, якщо промислові протоколи (OPC UA, Modbus) не мають вбудованого захисту?
Для цього застосовується метод протокольної ізоляції. Локальний шлюз всередині OT-мережі зчитує дані з PLC і перетворює їх на безпечний формат (наприклад, JSON). Промисловий протокол не маршрутизується у зовнішню мережу, що виключає можливість його прямої експлуатації з боку хмари.
Чи можна використовувати звичайний міжмережевий екран (Firewall) замість апаратного дата-діода для сегментації IT/OT?
Класичний Firewall створює логічний бар'єр, який може бути подоланий у разі помилки конфігурації або виявлення вразливості в самому ПЗ екрана. Використання апаратного або суворого програмного дата-діода (Data Diode) фізично чи на рівні драйверів унеможливлює передачу трафіку у зворотному напрямку, кардинально знижуючи ризики.
Як організувати зворотний зв'язок (наприклад, оновлення установок) з хмари в OT без створення дірок у безпеці?
Зворотний зв'язок ніколи не реалізується як пряме з'єднання. Оновлення завантажуються на проміжний сервер у демілітаризованій зоні (DMZ). Локальний шлюз зсередини OT періодично ініціює запит на наявність підписаних оновлень, перевіряє їхній цифровий підпис і лише після цього застосовує зміни у промисловій мережі.