OT ortamlarında felaket kurtarma (Disaster Recovery) konuşulunca genelde şu cümleyi duyarsınız: “Yedek alıyoruz.” Oysa DR’nin asıl sorusu şu: Ne kadar sürede, hangi sırayla, hangi doğrulamalarla ayağa kalkacaksın? OT’de “yedek var” demek çoğu zaman yanıltıcıdır; çünkü geri dönüş yalnızca veri değil, prosesin doğru çalışmasıdır.
Korkutucu senaryo: Bir fidye yazılımı, IT tarafında başlar ve DMZ üzerinden OT’ye sızar. HMI’lar açılmaz, historian veritabanı kilitlenir, mühendislik istasyonundaki proje dosyaları şifrelenir. PLC’ler çalışıyor gibi görünür ama operatör ekrandan kontrol edemiyordur. Üretim durur. IT ekibi “backup’tan döneriz” der. Fakat OT’de kritik soru gelir: Hangi HMI imajı? Hangi driver versiyonu? Hangi PLC programı son güncelleme? Hangi SCADA lisansı? Hangi IP planı? Hangi sertifikalar? Bunlar bilinmiyorsa DR, saatler değil günler sürer.
OT DR planı; “yedekleme” + “mimari yedeklilik” + “senaryo bazlı runbook” üçlüsüdür.
1) Altın imaj (golden image) ve konfigürasyon yönetimi
-
HMI/SCADA sunucularının imajları, sürüm bağımlılıkları (driver, runtime, lisans).
-
Mühendislik istasyonlarının proje dosyaları + toolchain sürümleri.
-
PLC/RTU program yedekleri ve değişiklik kontrolü (kim, ne zaman, neden?).
2) Kritiklik ve ayağa kalkma sırası
OT’de her şey aynı anda ayağa kalkmaz. Örnek sıra:
-
Ağ temel servisleri (switch/firewall config’leri, VLAN’lar, routing)
-
Kimlik/erişim (jump server, VPN, MFA, erişim kayıtları)
-
Proses kontrol (PLC/RTU temel fonksiyonları)
-
Operatör görünürlüğü (HMI)
-
Üst seviye izleme (SCADA)
-
Historian/raporlama
-
Entegrasyonlar (MES/ERP)
3) RTO/RPO gerçekçiliği
-
RTO: Ne kadar sürede ayağa kalkacaksın?
-
RPO: Ne kadar veri kaybını tolere edersin?
OT’de RPO sadece veri değil, konfigürasyon drift demektir. PLC programı ile sahadaki gerçek durum uyuşmazsa, tekrar çalışsa bile yanlış çalışabilir.
4) “Offline backup” ve saldırıya dayanıklılık
Fidye yazılımları ağ paylaşımlarını ve online backup depolarını da hedefler. OT için:
-
Immutable backup / WORM
-
Offline kopya
-
Ayrı kimlik alanı / ayrı erişim
-
Periyodik geri yükleme testi
5) Tatbikat (DR drill)
DR planı kağıtta kalınca işe yaramaz. En azından yılda birkaç kez:
-
Bir HMI sunucusunu yedekten kur
-
Bir PLC projesini restore et
-
SCADA lisans/driver uyumluluğunu doğrula
-
Segmentasyon kuralları DR sonrası doğru mu kontrol et
OT DR’nin ikna edici tarafı şudur: DR yoksa, saldırı anında kararlar panikle alınır. O panikte yapılan “hızlı bypass”lar (firewall’ı kapatmak, herkese admin vermek, hızlı RDP açmak) saldırganın işini kolaylaştırır ve ikinci dalgayı getirir. DR planı; sadece kurtarmak değil, kurtarırken güvenliği korumak demektir.
Kurumlar genelde DR’ı “olursa bakarız” diye erteler. Oysa OT’de felaketin maliyeti; günler süren duruş, kalite kaybı, iş güvenliği riski ve itibar kaybıdır. DR, sigorta gibi değil; prosesin devamlılığı için mühendislik zorunluluğudur.


