Коли йдеться про аварійне відновлення (Disaster Recovery) в середовищах OT, зазвичай чуємо: «Ми створюємо резервні копії». Проте головне питання DR інше: За який час, у якій послідовності та з якими перевірками ви відновите роботу? В OT твердження «резервна копія є» часто вводить в оману, адже відновлення — це не лише дані, а й належна робота технологічного процесу.

Тривожний сценарій: атака програми-вимагача починається в IT та через DMZ проникає в OT. HMI не запускаються, база даних архіву технологічних даних блокується, файли проєктів на інженерній станції зашифровані. PLC начебто працюють, але оператор не може керувати процесом з екрана. Виробництво зупиняється. Команда IT каже: «Відновимо з резервної копії». Проте в OT постають критичні питання: який образ HMI? Яка версія драйвера? Яка програма PLC містить останні зміни? Яка ліцензія SCADA? Який план IP-адресації? Які сертифікати? Якщо цього не знати, DR триватиме не години, а дні .

План DR для OT — це поєднання трьох складових: «резервне копіювання» + «архітектурне резервування» + «сценарні інструкції з відновлення».

1) Еталонний образ (golden image) та керування конфігураціями

2) Критичність і послідовність відновлення роботи

В OT не все відновлюється одночасно. Приклад послідовності:

  1. Базові мережеві служби (конфігурації комутаторів/міжмережевих екранів, VLAN, маршрутизація)

  2. Ідентифікація/доступ (сервер проміжного доступу, VPN, MFA, журнали доступу)

  3. Керування технологічним процесом (базові функції PLC/RTU)

  4. Візуалізація для оператора (HMI)

  5. Моніторинг верхнього рівня (SCADA)

  6. Архів технологічних даних/звітність

  7. Інтеграції (MES/ERP)

3) Реалістичність RTO/RPO

  • RTO: За який час ви відновите роботу?

  • RPO: Який обсяг втрати даних для вас допустимий?

    В OT RPO стосується не лише даних, а й дрейфу конфігурації . Якщо програма PLC не відповідає фактичному стану обладнання на об’єкті, навіть після відновлення робота може бути некоректною.

4) «Автономна резервна копія» та стійкість до атак

Програми-вимагачі також атакують спільні мережеві ресурси та мережеві сховища резервних копій. Для OT:

  • Незмінювана резервна копія / WORM

  • Автономна копія

  • Окремий домен ідентифікації / окремий доступ

  • Періодична перевірка відновлення

5) Навчання з аварійного відновлення (DR drill)

План DR не працює, якщо залишається лише на папері. Щонайменше кілька разів на рік:

  • Відновіть сервер HMI з резервної копії

  • Відновіть проєкт PLC

  • Перевірте сумісність ліцензії/драйвера SCADA

  • Перевірте коректність правил сегментації після DR

Переконливий аргумент на користь DR для OT такий: без DR під час атаки рішення ухвалюють у паніці. «Швидкі обходи» захисту в такій ситуації (вимкнення міжмережевого екрана, надання всім прав адміністратора, поспішне відкриття RDP) полегшують роботу зловмисника та призводять до другої хвилі атаки. План DR означає не лише відновлення, а й збереження безпеки під час відновлення .

Організації часто відкладають DR зі словами «якщо щось станеться — тоді й розберемося». Проте в OT ціна аварії — це багатоденний простій, втрата якості, ризики для безпеки праці та репутаційні втрати. DR — це не страховка, а інженерна необхідність для безперервності технологічного процесу.