AveA Otomasyon

SCADA Yedekleme ve Felaket Kurtarma: Kritik Sistemleri Koruma Rehberi

Endüstriyel tesislerde SCADA sistemleri, üretimin beyni konumundadır. Bir SCADA sunucusunun çökmesi, veritabanının bozulması veya bir siber saldırı sonucu sistemin kilitlenmesi, dakikalar içinde yüz binlerce liralık üretim kaybına yol açabilir. Buna rağmen birçok tesis, SCADA yedekleme ve felaket kurtarma planlamasını ya hiç yapmamış ya da yetersiz düzeyde bırakmıştır.

Bu rehberde SCADA sistemleri için yedekleme stratejilerini, yedekli sunucu mimarilerini, veritabanı ve PLC program yedeklemenin önemini, felaket kurtarma planı oluşturmayı, RTO/RPO kavramlarını, bulut ve yerel yedekleme karşılaştırmasını ve fidye yazılımlarına karşı koruma yöntemlerini kapsamlı şekilde ele alıyoruz. SCADA sistemlerinin temel yapısı hakkında bilgi edinmek için SCADA Sistemleri Nedir? yazımızı inceleyebilirsiniz.

SCADA Sistemlerinde Yedekleme Neden Kritiktir?

SCADA sistemleri; HMI ekranları, alarm yapılandırmaları, trend verileri, tarihsel veritabanları, kullanıcı yetkilendirmeleri, iletişim ayarları ve PLC bağlantı konfigürasyonları gibi onlarca bileşenden oluşur. Bu bileşenlerden herhangi birinin kaybı, tesisin işleyişini doğrudan etkiler.

Veri Kaybı Senaryoları

  • Donanım arızası: Sunucu disk bozulması, RAID kontrolcü hatası, anakart arızası
  • Yazılım hatası: İşletim sistemi çökmesi, SCADA yazılımı güncelleme hatası, veritabanı bozulması
  • Siber saldırı: Fidye yazılımı (ransomware), hedefli saldırılar, içeriden tehditler
  • Doğal afet: Yangın, su baskını, deprem, elektrik kesintisi
  • İnsan hatası: Yanlış konfigürasyon değişikliği, kazara silme, yetkisiz müdahale

Türkiye’de özellikle son yıllarda endüstriyel tesislere yönelik fidye yazılımı saldırıları artış göstermiştir. Bir üretim tesisinin SCADA sistemi şifrelenerek kilitlendiğinde, yedek yoksa tesisin günlerce hatta haftalarca durması kaçınılmazdır.

RTO ve RPO Kavramları: Felaket Kurtarmanın Temeli

Felaket kurtarma planlamasının iki temel metriği vardır:

RPO (Recovery Point Objective) — Kurtarma Noktası Hedefi

RPO, bir felaket durumunda kabul edilebilir maksimum veri kaybı süresini ifade eder. Örneğin RPO = 1 saat ise, en fazla son 1 saatlik veri kaybedilebilir demektir. Bu, yedekleme sıklığını belirler.

  • RPO = 0: Gerçek zamanlı replikasyon gerektirir (senkron yedekleme)
  • RPO = 1 saat: Saatlik artımlı yedekleme yeterlidir
  • RPO = 24 saat: Günlük tam yedekleme yeterlidir

RTO (Recovery Time Objective) — Kurtarma Süresi Hedefi

RTO, sistemin felaket sonrası ne kadar sürede tekrar çalışır duruma gelmesi gerektiğini tanımlar.

  • RTO = 0: Kesintisiz çalışma; aktif-aktif yedekli sunucu mimarisi gerektirir
  • RTO = 1 saat: Sıcak yedek (hot standby) sunucu ile sağlanabilir
  • RTO = 4–8 saat: Soğuk yedek (cold standby) sunucu veya hızlı geri yükleme ile karşılanabilir
  • RTO = 24+ saat: Manuel kurulum ve yapılandırma ile kurtarma

Kritik altyapı tesislerinde (enerji, su arıtma, petrokimya) RTO ve RPO değerleri sıfıra yakın tutulmalıdır. Genel üretim tesislerinde ise RTO = 2–4 saat, RPO = 1 saat makul hedeflerdir.

SCADA Yedekleme Stratejileri

1. SCADA Proje ve Konfigürasyon Yedeklemesi

SCADA yazılımının proje dosyaları (ekranlar, alarmlar, taglar, scriptler) düzenli olarak yedeklenmelidir. Bu yedekleme, versiyon kontrol sistemi (Git, SVN) ile yapılmalıdır.

  • Her değişiklik sonrası proje dosyası dışa aktarılmalı ve versiyonlanmalıdır
  • Değişiklik açıklaması (commit message) ile birlikte saklanmalıdır
  • En az 3 farklı ortamda (sunucu, NAS, bulut) kopyası bulunmalıdır

2. Veritabanı Yedeklemesi (SQL Server / PostgreSQL / Historian)

SCADA tarihsel verileri genellikle SQL Server, PostgreSQL veya özel historian veritabanlarında saklanır.

SQL Server için yedekleme planı:
– Tam yedekleme (Full Backup): Haftada bir, hafta sonu mesai dışı saatlerde
– Diferansiyel yedekleme (Differential): Her gün gece yarısı
– İşlem günlüğü yedeklemesi (Transaction Log): Her 15–30 dakikada bir

-- Örnek SQL Server yedekleme komutu
BACKUP DATABASE [SCADA_Historian]
TO DISK = 'D:\Backup\SCADA_Historian_Full.bak'
WITH COMPRESSION, CHECKSUM, INIT;

Yedeklerin bütünlüğü düzenli olarak RESTORE VERIFYONLY komutuyla doğrulanmalıdır.

3. PLC Program Yedeklemesi

PLC programları, üretim sürecinin kalbidir. Bir PLC’nin arızalanması durumunda, yedek program olmadan yeni PLC’ye yükleme yapılamaz ve üretim durur.

PLC yedekleme kuralları:
– Her PLC programı, son çalışan sürümüyle birlikte yedeklenmelidir
– Online değişiklikler (online change) mutlaka proje dosyasına yansıtılmalıdır
– Yedekler; PLC markası, model, firmware sürümü ve proje yazılımı sürümü bilgileriyle birlikte saklanmalıdır
– Siemens TIA Portal, Mitsubishi GX Works, Allen-Bradley Studio 5000 gibi yazılımların proje dosyaları ayrı ayrı yedeklenmelidir
– Yedekleme tarihi ve değişiklik açıklaması mutlaka kaydedilmelidir

4. HMI ve Operatör Panel Yedeklemesi

HMI panellerin proje dosyaları, runtime lisansları ve konfigürasyonları da yedekleme kapsamına alınmalıdır. Özellikle Siemens Comfort Panel, Weintek ve Proface gibi panellerde proje dosyasının kaybı, ekranların sıfırdan tasarlanmasını gerektirir.

Yedekli Sunucu Mimarileri

Aktif-Pasif (Hot Standby)

Birincil SCADA sunucusu çalışırken, ikincil sunucu sürekli olarak senkronize edilir. Birincil sunucu arızalandığında, ikincil sunucu otomatik olarak devreye girer. Geçiş süresi tipik olarak 10–60 saniye arasındadır.

Avantajları: Düşük RTO, otomatik geçiş, veri kaybı minimum
Dezavantajları: İkinci sunucu maliyeti, lisans maliyeti (bazı SCADA yazılımlarında)

Aktif-Aktif (Redundant)

Her iki sunucu da aynı anda çalışır ve yük paylaşımı yapar. Bir sunucu arızalandığında diğeri tüm yükü üstlenir. RTO pratik olarak sıfırdır.

Avantajları: Kesintisiz çalışma, yük dengeleme, en yüksek kullanılabilirlik
Dezavantajları: Yüksek maliyet, karmaşık konfigürasyon, çift lisans gereksinimi

Sanallaştırma ve Yüksek Kullanılabilirlik

VMware vSphere HA veya Microsoft Hyper-V Failover Cluster kullanılarak SCADA sunucuları sanal makineler üzerinde çalıştırılabilir. Fiziksel sunucu arızasında sanal makine otomatik olarak başka bir fiziksel sunucuya taşınır. IT-OT yakınsaması ve konteyner teknolojileri hakkında detaylı bilgi için IT/OT Konverjansı ve Docker yazımıza göz atabilirsiniz.

Bulut vs Yerel Yedekleme

Yerel Yedekleme (On-Premise)

  • NAS (Network Attached Storage) veya SAN üzerine yedekleme
  • Hızlı geri yükleme süresi
  • İnternet bağlantısına bağımlılık yok
  • Fiziksel risklere (yangın, su baskını) açık

Bulut Yedekleme (Cloud Backup)

  • Coğrafi olarak farklı lokasyonda saklama
  • Doğal afetlere karşı koruma
  • Ölçeklenebilir depolama kapasitesi
  • İnternet bant genişliğine bağımlılık
  • Veri egemenliği ve KVKK uyumluluğu değerlendirilmeli

Önerilen Hibrit Yaklaşım: 3-2-1 Kuralı

  • 3 kopya veri tutun (1 orijinal + 2 yedek)
  • 2 farklı ortamda saklayın (disk + bulut veya disk + teyp)
  • 1 kopyayı tesis dışında (offsite) bulundurun

Fidye Yazılımlarına (Ransomware) Karşı Koruma

Endüstriyel tesislere yönelik fidye yazılımı saldırıları, son yıllarda küresel ölçekte ciddi bir tehdit haline gelmiştir. SCADA sistemlerini korumak için alınması gereken önlemler şunlardır:

Ağ Segmentasyonu

OT ağı, IT ağından fiziksel veya mantıksal olarak ayrılmalıdır. Endüstriyel DMZ (Demilitarized Zone) oluşturulmalı ve OT ağına doğrudan internet erişimi engellenmelidir. Bu konuda IEC 62443 Siber Güvenlik standardı kapsamlı bir çerçeve sunmaktadır.

Yedeklerin Korunması

  • Yedekler, üretim ağından izole bir ortamda saklanmalıdır
  • Air-gapped backup: En az bir yedek kopya, ağ bağlantısı olmayan bir ortamda tutulmalıdır
  • Yedekleme hesapları, ayrı kimlik doğrulama sistemi kullanmalıdır
  • Yedek dosyaları değiştirilemez (immutable) formatta saklanmalıdır

Erişim Kontrolü

  • En az yetki prensibi (Principle of Least Privilege) uygulanmalıdır
  • Çok faktörlü kimlik doğrulama (MFA) kullanılmalıdır
  • Uzaktan erişim VPN ve jump server üzerinden sağlanmalıdır
  • Tüm erişimler loglanmalı ve izlenmelidir

Güncelleme ve Yama Yönetimi

  • İşletim sistemi ve SCADA yazılımı güvenlik yamaları düzenli olarak uygulanmalıdır
  • Yamalar, test ortamında doğrulandıktan sonra üretim sistemine aktarılmalıdır
  • Desteklenmeyen (End of Life) işletim sistemleri mümkün olan en kısa sürede yükseltilmelidir

Felaket Kurtarma Planı (DRP) Oluşturma

Etkili bir felaket kurtarma planı şu bileşenleri içermelidir:

1. Risk Değerlendirmesi

Olası felaket senaryolarını ve her birinin olasılığını ve etkisini belirleyin. Kritiklik sıralaması yapın.

2. Kurtarma Prosedürleri

Her senaryo için adım adım kurtarma prosedürü yazın. Prosedürler, teknik bilgisi orta düzeyde bir personelin uygulayabileceği detayda olmalıdır.

3. Sorumluluk Matrisi

Felaket durumunda kimin ne yapacağını, iletişim zincirini ve eskalasyon prosedürünü tanımlayın.

4. Düzenli Test ve Tatbikat

  • Yedeklerden geri yükleme testleri en az 3 ayda bir yapılmalıdır
  • Yılda en az bir kez tam felaket kurtarma tatbikatı gerçekleştirilmelidir
  • Test sonuçları dokümante edilmeli ve plan güncellenmelidir

5. Dokümantasyon

Tüm sistem konfigürasyonları, ağ şemaları, IP adresleri, lisans anahtarları, iletişim bilgileri ve prosedürler güncel tutulmalı ve hem dijital hem basılı olarak saklanmalıdır.

Avea Otomasyon’un Yedekleme ve Felaket Kurtarma Çözümleri

Avea Otomasyon olarak, endüstriyel tesislerin SCADA yedekleme ve felaket kurtarma ihtiyaçlarına yönelik kapsamlı hizmetler sunuyoruz:

  • SCADA yedekleme denetimi: Mevcut yedekleme altyapınızı değerlendiriyor, eksiklikleri tespit ediyor ve iyileştirme önerileri sunuyoruz.
  • Yedekli sunucu mimarisi tasarımı: Tesisinizin RTO/RPO hedeflerine uygun aktif-pasif veya aktif-aktif sunucu mimarisi kuruyoruz.
  • Otomatik yedekleme sistemi kurulumu: SCADA projeleri, veritabanları ve PLC programları için otomatik yedekleme altyapısı oluşturuyoruz.
  • Felaket kurtarma planı hazırlama: Tesisinize özel DRP dokümanı hazırlıyor ve personel eğitimi veriyoruz.
  • Siber güvenlik danışmanlığı: IEC 62443 çerçevesinde OT ağ güvenliği değerlendirmesi ve iyileştirme hizmetleri sunuyoruz.

Sonuç

SCADA yedekleme ve felaket kurtarma, bir lüks değil zorunluluktur. Veri kaybı ve sistem kesintisi riskini minimize etmek için proaktif bir yaklaşım benimsenmeli, 3-2-1 yedekleme kuralı uygulanmalı ve felaket kurtarma planı düzenli olarak test edilmelidir. Unutmayın: yedeklemenin değeri, geri yükleme yapmanız gereken gün anlaşılır.

Sıkça Sorulan Sorular (SSS)

S1: SCADA yedeklemesi ne sıklıkla yapılmalıdır?
Yedekleme sıklığı, tesisin RPO hedefine bağlıdır. Kritik altyapı tesislerinde (enerji, su) gerçek zamanlı replikasyon veya 15 dakikalık aralıklarla yedekleme önerilir. Genel üretim tesislerinde veritabanı için saatlik artımlı yedekleme, SCADA proje dosyaları için her değişiklik sonrası yedekleme ve PLC programları için aylık tam yedekleme minimum standart olarak kabul edilir.

S2: PLC programlarını yedeklememek ne gibi risklere yol açar?
PLC programı yedeklenmemişse, PLC donanım arızası durumunda yeni PLC’ye program yüklenemez ve üretim hattı tamamen durur. Programın sıfırdan yazılması haftalar sürebilir ve bu süre zarfında üretim kaybı yüz binlerce lirayı bulabilir. Ayrıca orijinal programcının artık erişilebilir olmaması durumunda, proses bilgisinin yeniden oluşturulması çok daha uzun sürer.

S3: Bulut yedekleme endüstriyel sistemler için güvenli midir?
Bulut yedekleme, doğru yapılandırıldığında endüstriyel sistemler için güvenli ve etkili bir çözümdür. Ancak dikkat edilmesi gereken noktalar vardır: veriler şifreli olarak aktarılmalı ve saklanmalı (AES-256), KVKK kapsamında verilerin Türkiye sınırları içinde barındırılması tercih edilmeli, bulut erişim hesapları çok faktörlü kimlik doğrulama ile korunmalı ve bulut yedekleme tek başına yeterli görülmeyip yerel yedekleme ile birlikte hibrit bir yaklaşım benimsenmelidir.

Bizi Takip Edin

📷 Instagram: avea.otomasyon
📘 Facebook: Avea Otomasyon
💼 LinkedIn: Avea Otomasyon
📍 Google Maps: Yol Tarifi Alın
📍 Hızlı Ulaşım: g.page/AveAOtomasyon

, , , , , , , , ,
1