Üretim ve Sanayi Veri Kurtarma: SCADA, MES, PLC ve ERP Sistemleri

Üretim sektörü, son on yılda dijital dönüşümün belki de en derinden hissedildiği alan oldu. Eskiden fabrika sahasında çalışan PLC'ler, HMI panelleri ve ofis tarafındaki ERP sistemleri birbirinden tamamen ayrı dünyalardı. Bugün ise SCADA historian veritabanı bulutla konuşuyor, MES sistemi ERP'ye gerçek zamanlı sipariş gönderiyor, bakım ekibi tablette PLC parametresine bakıyor. Bu yakınlaşma verimliliği artırdı ama aynı zamanda yepyeni bir saldırı yüzeyi ve veri kaybı senaryosu yarattı. Bir sanayi şirketinde tek bir disk arızası ya da fidye yazılım vakası, sadece dosya kaybı değil tüm üretim hattının durması anlamına gelebiliyor.

DSET olarak Hacettepe Üniversitesi Teknokent Ankara laboratuvarımızda, Bursa, Kayseri ve Kocaeli sanayi bölgelerinden gelen vakalarda gördüğümüz en kritik nokta şudur: üretim verisi tek başına bir veri kümesi değildir, fabrikanın hafızasıdır. Bu yazıda SCADA, MES, PLC ve ERP katmanlarındaki tipik veri kaybı senaryolarını, dünyadan örnek vakaları ve kurtarma yaklaşımını anlatacağız.

BT ve OT Ayrımı: Neden Bu Kadar Önemli

Üretim ortamında veri iki büyük dünyada yaşar. BT (Bilgi Teknolojileri) tarafı ofis bilgisayarları, e-posta, dosya sunucuları ve ERP gibi klasik kurumsal sistemleri kapsar. OT (Operasyonel Teknoloji) tarafı ise sahadaki PLC, HMI, SCADA, MES ve historian gibi üretimi doğrudan kontrol eden sistemlerdir.

NIST SP 800-82 Revision 3 (csrc.nist.gov/pubs/sp/800/82/r3/final), ICS (Industrial Control Systems) güvenliği için referans dokümandır ve BT/OT ayrımının neden korunması gerektiğini detaylıca açıklar. IEC 62443 standart serisi (iec.ch/cyber-security) ise endüstriyel otomasyon ve kontrol sistemleri için kapsamlı güvenlik çerçevesi sunar. Bu standartlar sadece güvenlik için değil, veri kurtarılabilirlik için de kritik referanslardır çünkü her iki dünyada yedekleme stratejisi, depolama mimarisi ve felaket kurtarma yaklaşımı tamamen farklıdır.

ISA-95 standardı (isa.org) ise işletme ve kontrol sistemleri arasındaki entegrasyonu tanımlar. Bu modeldeki Level 0 (saha cihazları), Level 1 (PLC), Level 2 (SCADA/HMI), Level 3 (MES) ve Level 4 (ERP) ayrımı, veri kurtarma planlaması için de kullandığımız çerçevedir. Her seviyenin veri kaybı sonuçları farklıdır ve müdahale yaklaşımı da farklıdır.

SCADA Sistemleri: Historian Verisinin Önemi

SCADA (Supervisory Control and Data Acquisition) sistemleri, sahadaki binlerce sensörden saniyede onlarca veri noktası toplar. Bu veriler historian veritabanlarında (OSIsoft PI System, GE Proficy, AVEVA Wonderware Historian) saklanır. Bir kimya tesisinde sıcaklık, basınç ve akış verileri yıllarca saklanır; çünkü hem süreç optimizasyonu, hem ürün izlenebilirliği, hem de regülatif uyum için gereklidir.

En sık karşılaştığımız SCADA veri kaybı senaryoları şunlardır:

Historian disk dolu kalır ve veritabanı bozulur. OSIsoft PI veya Wonderware Historian arka uçta SQL Server ya da özel zaman serisi veritabanı kullanır. Diskin %100 dolduğu anda yazma işlemleri yarıda kalır, bazı sayfa yapıları bozulur. Sonraki yeniden başlatmada veritabanı açılmaz ya da kısmi veriyle açılır.

Siemens WinCC veritabanı çöker. WinCC, MS SQL Server Express tabanlıdır ve 10 GB sınırına dayandığında veritabanı genişlemeyi durdurur. Bu sınır farkına varılmadığında alarmlar ve trend kayıtları sessizce kaybolur.

Rockwell FactoryTalk projeleri bozulur. .ACD ve .APA proje dosyaları, versiyon yönetimi olmadan tutulduğunda yanlış kaydetme tek bir fabrikada haftalarca üretim takibi kaybetmeye yol açabilir.

Bu senaryolarda DSET laboratuvarında yaptığımız iş, önce diskin bit seviyesinde imajını almak, sonra SQL Server tabanlı historian veritabanını sayfa onarımı, DBCC CHECKDB ve ham kayıt ayıklama yöntemleriyle açmaya çalışmaktır. Tam yedekleme stratejisi yoksa kayıp bir bölümün kabullenilmesi gerekebilir ama büyük çoğunluk genellikle kurtarılır. Konuyu daha geniş çerçevede veri kurtarma rehberi 2026 Türkiye yazımızda ele aldık.

PLC Programları: Yedek Yoksa Kurtarma Yok

PLC (Programmable Logic Controller) dünyasında en acı senaryo, programın sahada kaybolmasıdır. Siemens S7-1200/1500 serisi, Allen-Bradley ControlLogix, Mitsubishi MELSEC, Omron CJ/NJ gibi cihazlar üretim hattını kontrol eden mantığı barındırır.

Gördüğümüz tipik vaka şudur: 10 yıllık bir hatta çalışan PLC arızalanır. Yedek program ne mühendislik istasyonunda, ne bakım dolabındaki USB'de, ne de eski makinede bulunur. Bazı durumlarda PLC'den online upload mümkündür ama yorum satırları, sembolik isimler ve programcının notları kaybolmuş olur. Bazı durumlarda parola korumalı olduğu için upload mümkün değildir ve PLC fabrika tabelasından yeniden yazılmak zorunda kalınır.

Bu sebeple endüstriyel otomasyon dünyasında "PLC backup yok kayboldu" durumu, sabit disk arızasından çok daha tehlikelidir. PLC verisi disk üzerinde durmaz, donanımın içinde durur. Veri kurtarma laboratuvarı bu durumda PLC chip seviyesinde NAND okuma yapabilir ama bu çok sınırlı bir alandır ve cihaz fiziksel olarak işlevsiz değilse genelde yedekleme stratejisinin yeniden kurulması daha doğrudur.

MITRE ATT&CK for ICS (attack.mitre.org/matrices/ics), PLC ve SCADA üzerinde gerçekleşen saldırı tekniklerini kataloglar. Burada görülen "Modify Program" ve "Block Reporting Message" gibi teknikler, sadece güvenlik değil veri bütünlüğü açısından da bilinmesi gereken risklerdir.

MES Veritabanları: Üretim Hafızasının Kalbi

MES (Manufacturing Execution System) sistemleri, üretim emri, parti takibi, kalite kayıtları, vardiya verisi, OEE (Overall Equipment Effectiveness) metrikleri gibi operasyonel verileri tutar. Çoğu MES çözümü (Siemens Opcenter, Rockwell FactoryTalk ProductionCentre, GE Proficy Plant Applications, yerli AVEVA ve Türk MES çözümleri) arka uçta SQL Server ya da Oracle veritabanı kullanır.

MES veritabanı bozulduğunda, son birkaç haftanın parti izlenebilirliği, kalite ölçümleri ve makine duruş kayıtları risk altına girer. İlaç ve gıda sektöründe bu kayıplar regülatif sorun da yaratır çünkü izlenebilirlik (traceability) yasal zorunluluktur.

SQL Server tarafında veritabanı bozulduğunda DBCC CHECKDB, sayfa düzeyinde onarım, transaction log replay ve hatta ham .MDF dosyasından kayıt ayıklama yöntemleriyle veri kurtarma mümkündür. Bu konuyu daha detaylı RAID 5 çöktü kurtarma süreci ve maliyet yazımızda ele aldık; çünkü MES sunucuları büyük çoğunlukla RAID 5 ya da RAID 10 yapılandırmasında çalışır ve disk arızası ile veritabanı bozulması iç içe gelir.

ERP Sistemleri: SAP, Oracle, Logo Tiger

ERP (Enterprise Resource Planning) sistemleri (SAP S/4HANA, Oracle E-Business Suite, Logo Tiger, Mikro Run, IFS) artık üretim şirketleri için omurga sistemdir. Stok, üretim emri, maliyet, fatura, müşteri ve tedarikçi verisi burada birleşir.

ERP veri kaybı vakalarında üç tipik senaryo görüyoruz. Birincisi, Oracle veya HANA veritabanı dosyalarının bulunduğu RAID dizisinin çökmesi. İkincisi, ERP sunucusunun fidye yazılım ile şifrelenmesi; bu durumda fidye yazılım sonrası ilk 24 saat acil müdahale prosedürünü devreye sokmak gerekir. Üçüncüsü ise yanlış güncelleme veya migrasyon sırasında veritabanının bozulmasıdır.

Logo Tiger ve Mikro tarafında ise SQL Server tabanlı yapıların yanlış kapatma, disk arızası veya yazılım hatası sonucu bozulması yaygın bir vaka. Burada da temel yaklaşım önce ham diskin imajlanması, sonra .MDF/.LDF dosyaları üzerinde sayfa onarımı ve gerekirse parça parça veri çıkarmadır.

Dünyadan Üç Kritik Vaka

Üretim sektöründe yedekleme stratejisinin neden hayati olduğunu anlamak için kamuya açık üç vakaya bakmak yeterlidir.

Maersk NotPetya saldırısı, 2017. Dünya çapındaki lojistik devi Maersk, NotPetya kötü amaçlı yazılımı sonucu küresel BT altyapısının büyük bölümünü kaybetti. Şirket açıklamasına göre toplam maliyet yaklaşık 300 milyon USD oldu. Maersk, Aktif Dizin altyapısını sadece tek bir Gana ofisindeki bir sunucunun fiziksel uzakta olması sayesinde yeniden kurabildi. Bu vaka, coğrafi olarak ayrı yedeklemenin teorik bir kavram değil hayat kurtaran bir uygulama olduğunu gösterdi.

Norsk Hydro LockerGoga saldırısı, 2019. Norveçli alüminyum üreticisi LockerGoga fidye yazılımı saldırısına uğradı. Şirket, fidye ödememe kararı aldı ve kamuoyu ile şeffaf iletişim kurdu. Tahmini maliyet 75 milyon USD civarıydı. Bu vakanın öne çıkan tarafı, şirketin yedeklerden geri dönebilmesi ve üretim süreçlerini manuel modlara düşürerek tamamen durdurmamayı başarmasıdır. Olay sonrası yapılan analizlerde, OT tarafının BT'den net ayrılmış olmasının ve fabrikaların kısmen manuel çalışabilir tasarımının kurtarıcı olduğu görüldü.

Honda fabrika durması, 2020. Japon otomotiv devi Honda, küresel BT altyapısına yapılan saldırı sonucu birkaç fabrikasında üretimi durdurmak zorunda kaldı. Üretim hatlarına bağlı sistemlerin bütünleşik mimarisi, BT tarafındaki bir vakanın doğrudan OT tarafını etkilediğini gösterdi.

Bu üç vakanın ortak dersi nettir: yedekleme stratejisi olmadan, ne kadar büyük olursanız olun kurtarma imkansıza yakındır. CISA ICS Advisories (cisa.gov/news-events/cybersecurity-advisories), endüstriyel kontrol sistemleri için sürekli güncellenen güvenlik bildirimleri yayınlar ve her ay yeni zafiyetler eklenir.

Yedek Stratejisi: 3-2-1-1-0 Kuralı

Üretim sektöründe önerdiğimiz yedekleme stratejisi 3-2-1-1-0 modelidir. Üç kopya, iki farklı medya, bir kopya offline, bir kopya immutable (değiştirilemez) ve doğrulamada sıfır hata. Bu modelde:

  • SCADA historian günlük tam yedek + saatlik artımlı yedek
  • PLC programları her değişiklikte mühendislik istasyonu ve merkezi repository'ye otomatik yüklenir
  • MES veritabanı transaction log seviyesinde sürekli yedek + offline kopya
  • ERP veritabanı immutable storage (S3 Object Lock benzeri) + soğuk depolama
  • Yedeklerin geri yükleme testi en az çeyrekte bir yapılır, sadece kopya almak yeterli değildir

Air-gap (hava boşluğu) kavramı burada kritiktir. Bir yedeğin gerçek anlamda hava boşluğunda olması demek, hiçbir ağ bağlantısı üzerinden erişilemez olması demektir. NotPetya vakasında bunun ne kadar önemli olduğu açıkça görüldü. Yine de "air-gap kırıldı" tipik bir senaryodur. Mühendisin USB ile yedek kopyalaması, geçici ağ köprüsü kurulması ya da güncelleme sırasında bağlantı açılması gibi durumlarda hava boşluğu fiilen yok olur.

Immutable yedek konusu son yıllarda öne çıkan bir başlıktır. Fidye yazılım grupları artık ilk hedef olarak yedek sunuculara odaklanıyor; çünkü yedekleri silebilirlerse fidye ödeme baskısı artıyor. Veeam, Commvault, Rubrik gibi kurumsal yedekleme platformları, immutability ve worm (write once read many) özellikleri ile bu saldırı yüzeyini kapatmaya çalışır. Üretim ortamında SCADA ve MES gibi kritik sistemler için bu özellikler artık opsiyonel değil zorunludur.

Cold storage (soğuk depolama) ise tape (LTO-8/LTO-9) veya offline disk gibi medyalarda tutulan, kasada veya fiziksel olarak ayrı bir lokasyonda saklanan yedeklerdir. Bursa, Kayseri ve Kocaeli sanayi bölgelerinde gördüğümüz pek çok fabrika, yıllık arşiv yedeklerini hâlâ tape üzerinde tutar ve bu, NotPetya benzeri bir vakada şirketi ayakta tutan unsur olabilir.

Olay Müdahale ve KVKK Uyumu

Bir üretim şirketinde veri kaybı olayı yaşandığında, sadece teknik kurtarma değil olay müdahale prosedürü de işletilmelidir. NIST SP 800-61 referansıyla hazırladığımız siber olay müdahale IR Playbook yazımız, üretim ortamına da uygulanabilen detaylı bir çerçeve sunar.

KVKK (kvkk.gov.tr) kapsamında, eğer veri kaybı kişisel veri içeren bir sisteme dokunduysa (örneğin personel takibi MES'e entegre olduysa, müşteri verisi ERP'de varsa) 72 saat içinde Kurul'a bildirim yapılması gerekir. AB'de NIS2 direktifi, kritik altyapı operatörleri için benzer ama daha katı yükümlülükler getirir ve Türkiye'de faaliyet gösteren ihracatçı sanayi şirketleri de AB pazarına ürün gönderdikleri sürece bu uyumdan etkilenebilirler.

ISO/IEC 27037 standardı (iso.org/standard/44381.html) ise dijital delillerin tanımlanması, toplanması, edinilmesi ve korunması konusunda rehberlik eder. DSET laboratuvarımızda olay müdahale içeren her vakada bu standartlara uygun chain of custody (delil zinciri) belgelemesi yapıyoruz.

Üretim Vakalarında Karşılaşılan Zorluklar

Üretim ortamında veri kurtarmanın ofis vakalarından farklı yanları vardır. Birincisi zaman baskısı çok yüksektir. Bir otomotiv yan sanayi fabrikasında saatte yüz binlerce TL ciro üretilir ve duruş her dakika maliyettir. İkincisi sistem mimarisi karmaşıktır; SCADA, MES, ERP ve PLC katmanları birbirine bağlıdır ve bir katmandaki bozulma diğerlerini de etkiler. Üçüncüsü dokümantasyon genellikle eksiktir; PLC programı sahaya 15 yıl önce yüklenmiştir, o günden bu yana 3 mühendis değişmiştir ve yorum satırları olmayan kod kalmıştır.

DSET olarak bu zorlukların farkında olarak hareket ediyoruz. Bursa, Kayseri, Kocaeli, Gaziantep, Eskişehir gibi sanayi merkezlerinden gelen vakalar için sigortalı kargo süreci ve aciliyet durumunda kurye ile aynı gün laboratuvara teslim seçeneği sunuyoruz. Sahaya teknisyen gönderme talepleri de mümkündür ancak veri kurtarma laboratuvar koşullarında daha güvenli ve başarı oranı daha yüksek bir süreçtir.

DSET Yaklaşımı

Hacettepe Üniversitesi Teknokent Ankara'daki ISO 14644 Class 100 temiz oda laboratuvarımızda, üretim ve sanayi vakalarında izlediğimiz yol şudur:

  1. Saha ekibinden veya kargo yoluyla gelen donanımın bit seviyesinde imajı alınır
  2. Orijinal medya asla doğrudan çalıştırılmaz, tüm çalışma kopyalar üzerinden yürütülür
  3. SCADA historian, MES veritabanı veya ERP yapısı için uygun veritabanı motoru üzerinde sayfa düzeyinde analiz yapılır
  4. PLC vakalarında, mühendislik istasyonu yedeklerinin kalıntıları ve dosya sistemi metadata'sı taranır
  5. Sonuç raporu KVKK ve ISO/IEC 27037'ye uygun şekilde belgelenir

Bursa, Kayseri, Kocaeli ve diğer sanayi bölgelerinden gelen vakalar için sigortalı kargo süreci işletiyoruz. Bursa veri kurtarma ve Kayseri veri kurtarma yazılarımızda bölgeye özel detayları paylaştık.

Sonuç

Üretim sektöründe veri kurtarma, sadece bir disk operasyonu değildir. SCADA historian'dan PLC programına, MES kayıtlarından ERP veritabanına kadar uzanan geniş bir yelpazede, doğru yedekleme stratejisi olmadan kurtarma şansı dramatik olarak azalır. Maersk, Norsk Hydro ve Honda vakaları bize, hazırlığın saldırı anında değil yıllar öncesinden yapılması gereken bir disiplin olduğunu gösteriyor.

Eğer fabrikanızda SCADA, MES, PLC ya da ERP tarafında bir veri kaybı yaşadıysanız, sistemi yeniden başlatmadan önce DSET ile iletişime geçin. Çalışan bir sistemi yeniden başlatmak çoğu zaman kurtarılabilir verinin üzerine yazılması anlamına gelir. Hacettepe Teknokent Ankara laboratuvarımıza Bursa, Kayseri, Kocaeli ve tüm sanayi bölgelerinden sigortalı kargo ile gönderim mümkündür.

İletişim: +90 536 662 38 09 numarasından 7/24 acil destek hattımıza ulaşabilir, ilk teknik değerlendirme için bilgi alabilirsiniz. Üretim verisi, fabrikanın hafızasıdır; bu hafıza kaybedildiğinde yeniden inşa etmek aylar sürer. Doğru zamanda doğru ekiple çalışmak, bu süreyi günlere indirebilir.