ERP İş Sürekliliği Planı: Yedekleme, RPO/RTO ve Fidye Yazılımı

Bir üretim işletmesinin ERP’si Cuma akşamı kilitlendiğinde sorun yalnızca “sistem kapalı” değildir. Sevkiyat irsaliyeleri kesilemez, depo mal kabul yapamaz, muhasebe e-fatura gönderemez, satış ekibi açık siparişleri göremez. Her saat, ölçülebilir bir kayıptır: durmuş üretim hattı, gecikmiş tahsilat, müşteriye verilemeyen söz. ERP bir işletmenin merkezî sinir sistemiyse, o sistemin ne kadar süreyle ve ne kadar veri kaybıyla durabileceği bir tercih değil, önceden kararlaştırılması gereken bir mühendislik problemidir.

İş sürekliliği planı tam olarak bunu yapar: bir aksaklık (donanım arızası, fidye yazılımı, veri merkezi kesintisi, insan hatası) gerçekleştiğinde işletmenin nasıl ayakta kalacağını ve sistemi ne kadar sürede geri getireceğini önceden tanımlar. Bu yazı, ERP özelinde bu planın bileşenlerini ve KVKK tarafındaki yükümlülükleri pratik bir çerçeveye oturtuyor.

ERP durduğunda gerçek maliyet

Kesintinin maliyetini hesaplamadan plan yapmak havada kalır. Basit bir çerçeve, kararı somutlaştırır:

• Doğrudan kayıp: Üretimin durması, sevkiyatın gecikmesi, satış noktasının işlem yapamaması.
• Dolaylı kayıp: Gecikmiş tahsilat ve nakit akışı baskısı, sonradan elle telafi edilen mutabakatlar, fazla mesai.
• İtibar ve uyum: Müşteriye verilen sözün tutulamaması; kişisel veri sızması durumunda KVKK idari para cezası riski.

Bir işletme “ERP’miz bir gün dursa ne olur?” sorusunu ciro, sipariş hacmi ve günlük işlem sayısıyla çarptığında, çoğu zaman yedekleme ve felaket kurtarmaya ayrılacak bütçenin neden makul olduğunu kendiliğinden görür.

İş sürekliliğinin iki sayısı: RPO ve RTO

Bir iş sürekliliği planının kalbinde iki hedef vardır. Sözleşmede ve teknik tasarımda bu iki sayı netleşmeden geri kalan her şey tahmindir.

RPO (Recovery Point Objective) — kabul edilebilir veri kaybı. Bir aksaklık anında “en fazla ne kadarlık veriyi kaybetmeyi göze alabiliriz?” sorusunun cevabıdır. Gece bir kez yedek alan bir sistemde RPO 24 saattir; yani en kötü senaryoda bir günlük işlem kaybolur. Saatlik yedekleme RPO’yu 1 saate, sürekli replikasyon ise dakikalar düzeyine indirir.

RTO (Recovery Time Objective) — kabul edilebilir kesinti süresi. “Sistemi ne kadar sürede yeniden çalışır hâle getirmemiz gerekiyor?” sorusunun cevabıdır. RTO 4 saat ise, planın bu süre içinde ERP’yi ayağa kaldıracak şekilde tasarlanması gerekir.

Bu iki sayı maliyetle doğru orantılıdır: RPO’yu sıfıra ve RTO’yu dakikalara çekmek mümkündür ama pahalıdır. Doğru yaklaşım, her modül için ayrı ayrı düşünmektir. Muhasebe ve sipariş verisi için sıkı bir RPO gerekirken, arşiv niteliğindeki bir rapor klasörü için gevşek bir hedef yeterli olabilir.

3-2-1 kuralı: neden hâlâ geçerli

Yedekleme dünyasında uzun süredir tekrarlanan bir kural var ve sebepsiz değil: 3-2-1. Verinin 3 kopyası bulunsun; bunlar 2 farklı ortamda (örneğin disk ve bulut) tutulsun; en az 1 kopya işletmenin fiziksel olarak dışında saklansın.

Mantığı basit. Tek bir yedek, o yedeği barındıran cihaz da bozulursa işe yaramaz. Aynı binadaki iki yedek, yangın ya da su baskınında birlikte gider. Tek bir bulut hesabındaki kopyalar, hesap ele geçirilirse hep birlikte risk altındadır. Kopyaları çoğaltmak ve coğrafi olarak ayırmak, “tek bir olayın tüm yedekleri yok etmesini” engeller.

Modern bir ekleme daha gerekir: değiştirilemez (immutable) yedek. Belirli bir süre boyunca silinemeyen ve üzerine yazılamayan yedekler, bir sonraki bölümün konusu olan fidye yazılımına karşı en güçlü savunmadır. Çünkü saldırganların ilk hedeflerinden biri, kurbanın geri dönmesini engellemek için yedekleri de şifrelemek ya da silmektir.

Fidye yazılımı senaryosu ve yedeğin rolü

Fidye yazılımı saldırıları son yıllarda “çifte şantaj” (double extortion) modeline evrildi. Saldırgan artık yalnızca verinizi şifrelemiyor; şifrelemeden önce bir kopyasını dışarı sızdırıyor ve “ödemezsen veriyi şifreli bırakırım, üstüne sızdırdıklarımı yayınlarım” diyor. Bu, yedeklemenin tek başına yetmediği anlamına gelir.

İki ayrı savunma katmanı gerekir:

1. Geri dönüş için sağlam, izole ve değiştirilemez yedek. Sistem şifrelense bile temiz bir noktadan geri dönülebiliyorsa, ilk şantaj kolu (şifreleme) etkisiz kalır. Yedeğin ana sistemden ağ olarak ayrı ya da değiştirilemez tutulması kritiktir.
2. Veri sızmasını önleyen erişim ve şifreleme. Verinin durağan hâlde ve aktarımda şifrelenmesi, sızsa bile okunmasını zorlaştırır. En az yetki ilkesi, ele geçirilen tek bir hesabın tüm verilere ulaşmasını engeller.

Yedekleme stratejisinin gerçek testi, “yedek alıyor muyuz?” değil “yedekten dönebiliyor muyuz?” sorusudur. Hiç denenmemiş bir yedek, var olduğu varsayılan ama çalışıp çalışmadığı bilinmeyen bir sigortadır. Düzenli geri yükleme tatbikatı, planın kâğıt üzerinde kalmamasını sağlar.

Erişim kontrolü: ilk savunma hattı

İş sürekliliğinin çoğu, olay gerçekleşmeden önce başlar. Yetkilendirme tarafındaki üç ilke, hem dış saldırı hem iç hata riskini azaltır:

• En az yetki ilkesi: Her kullanıcı yalnızca işini yapmak için ihtiyaç duyduğu modül ve işleme erişir. Depo personelinin muhasebe fişi silebilmesi için bir sebep yoktur.
• Çok faktörlü kimlik doğrulama (MFA): Parola tek başına yeterli değildir; ikinci bir doğrulama katmanı, çalınmış parolayla girişi büyük ölçüde engeller.
• İz kaydı (audit log): Kim, ne zaman, hangi kaydı değiştirdi bilgisi hem güvenlik hem de KVKK uyumu için gereklidir.

Bu konuyu daha ayrıntılı ele alan bir yazı için ERP’de güvenlik, yedekleme ve erişim kontrolü neden kritiktir ve bulut ERP’de yetkilendirme ve kullanıcı rolleri yazılarına bakılabilir.

KVKK veri ihlali: 72 saatlik müdahale

Bir güvenlik olayı kişisel veriyi etkilediğinde, mesele teknik olmaktan çıkıp hukuki bir yükümlülüğe dönüşür. Kişisel Verileri Koruma Kurulu’nun 24.01.2019 tarihli ve 2019/10 sayılı kararına göre, veri sorumlusu bir ihlali öğrendiği andan itibaren en kısa sürede ve makul gecikme olmaksızın en geç 72 saat içinde Kurul’a bildirmekle yükümlüdür. Bildirim, KVKK’nın internet sitesindeki Veri İhlali Bildirim Formu üzerinden yapılır. Sürenin başlangıcı ihlalin tespit edildiği andır; haklı bir gerekçe olmadan 72 saatin aşılması, gecikmenin gerekçelendirilmesini gerektirir.

İhlal müdahale planının kuru bir hatırlatma listesi olmaktan çıkıp gerçekten işe yaraması için olay anında izlenecek adımların önceden belli olması gerekir:

KVKK idari para cezaları her yıl yeniden değerleme oranıyla güncellenir; veri güvenliği yükümlülüklerinin ihlalinde tutarlar milyonlarca lirayı bulabilir. Güncel tavan rakamlar için KVKK’nın resmi cezalar tarifesini ya da mali/hukuk danışmanınızı esas alın. ERP tarafındaki şifreleme ve veri lokasyonu önlemlerinin ayrıntısı için Qera’nın KVKK, şifreleme ve bulut veri lokasyonu yaklaşımı yazısına göz atılabilir.

Bulut ERP’de iş sürekliliği: altyapının payı

İş sürekliliğinin önemli bir kısmı, ERP’nin nerede ve hangi altyapıda çalıştığıyla belirlenir. Kendi sunucusunu işletmesinde tutan bir işletme; yedekleme, yedeklilik, fiziksel güvenlik ve felaket kurtarmayı baştan sona kendi kurar ve sürdürür. Bulut tarafında bu sorumluluğun bir bölümü altyapı sağlayıcısına geçer.

Qera ERP bulut sürümü Microsoft Azure altyapısında barındırılır. Bu, Azure’ın veri merkezi düzeyindeki yedeklilik ve yedekleme olanaklarından yararlanmak anlamına gelir; donanım bakımı, fiziksel güvenlik ve altyapı yedekliliği işletmenin sırtından kalkar. Qera anahtar teslim sunulduğu için kurulum, bakım ve güncelleme tek elden yürür; sürpriz altyapı kalemleriyle karşılaşılmaz ve 100 kullanıcıya kadar ek kullanıcı maliyeti çıkmaz.

Bu noktada bir uyarı yerinde olur: “bulutta, demek ki yedeklidir” varsayımı eksiktir. İşletmenin kendi RPO ve RTO hedeflerini netleştirmesi, yedekleme sıklığını ve saklama süresini sözleşmede yazılı hâle getirmesi gerekir. Altyapı yedekliliği ile işletmeye özel yedekleme politikası farklı şeylerdir; ikisi birlikte tanımlanmalıdır.

Kurumsal değerlendirme kontrol listesi

Bir ERP’nin iş sürekliliği olgunluğunu ölçmek için satın alma ve BT ekiplerinin sorması gereken sorular:

• Yedekler hangi sıklıkla alınıyor; sistem hangi RPO ve RTO hedefini taahhüt ediyor?
• Yedekler coğrafi olarak ayrı bir konumda ve değiştirilemez biçimde tutuluyor mu?
• Son geri yükleme tatbikatı ne zaman yapıldı; geri dönüş süresi ölçüldü mü?
• Erişim yetkileri rol bazlı mı; MFA ve iz kaydı devrede mi?
• Veri ihlali durumunda KVKK bildirim akışı belge hâlinde tanımlı mı?
• Verinin durağan ve aktarım hâlinde şifrelenmesi sağlanıyor mu?

Bu kriterler üzerinden kurumunuza özel bir tablo isteyen ekipler, iletişim formundan 30 dakikalık bir teknik değerlendirme görüşmesi talep edebilir.

Sıkça Sorulan Sorular

RPO ve RTO arasındaki fark nedir?

RPO kabul edilebilir veri kaybını ölçer (aksaklık anında en fazla ne kadarlık veri kaybedilebilir), RTO ise kabul edilebilir kesinti süresini ölçer (sistem ne kadar sürede ayağa kaldırılmalı). RPO yedekleme sıklığını, RTO ise geri dönüş tasarımını belirler.

Bulutta çalışan bir ERP’de ayrıca yedekleme gerekir mi?

Altyapı yedekliliği ile işletmeye özel yedekleme politikası farklı şeylerdir. Bulut sağlayıcısı veri merkezi düzeyinde yedeklilik sunsa da, işletmenin kendi RPO/RTO hedeflerini, yedekleme sıklığını ve saklama süresini sözleşmede netleştirmesi gerekir. İnsan hatasıyla silinen bir kaydı geri getirmek için noktasal geri yükleme yeteneği önemlidir.

Fidye yazılımına karşı en etkili önlem nedir?

Tek bir önlem yeterli değildir. Değiştirilemez ve izole yedekler şifreleme şantajını etkisiz kılar; en az yetki ilkesi, MFA ve veri şifreleme ise sızmayı zorlaştırır. En kritik adım, yedekten gerçekten dönülebildiğinin düzenli tatbikatla doğrulanmasıdır.

Veri ihlalini KVKK’ya ne zaman bildirmem gerekir?

Kişisel Verileri Koruma Kurulu’nun 2019/10 sayılı kararına göre, ihlali öğrendiğiniz andan itibaren en kısa sürede ve en geç 72 saat içinde Kurul’a bildirim yapmanız beklenir. Bildirim KVKK’nın Veri İhlali Bildirim Formu üzerinden yapılır. Güncel usul ve süreler için KVKK’nın resmi duyurularını esas alın.

Yedeğimin çalıştığını nasıl anlarım?

Yalnızca yedek almak yeterli değildir; düzenli geri yükleme tatbikatı yapılmalıdır. Test sürecinde yedekten dönüş süresi ölçülür ve RTO hedefiyle karşılaştırılır. Hiç denenmemiş bir yedek, çalışıp çalışmadığı bilinmeyen bir sigortadır.

Değerlendirme sürecinin sonraki adımları

İş sürekliliği, ERP seçiminin sonradan eklenen bir maddesi değil, karar kriterlerinin parçasıdır. Mevcut sistemini değerlendiren bir işletme önce RPO/RTO hedeflerini ve son geri yükleme tatbikatının tarihini sorgulayabilir; yeni bir sisteme geçmeyi planlayan bir ekip ise yedekleme, erişim kontrolü ve KVKK müdahale akışını seçim listesine baştan koyabilir.

Qera’nın bulut altyapısını, yetkilendirme modelini ve veri güvenliği yaklaşımını canlı görmek isteyen ekipler ücretsiz demo talebinde bulunabilir. Teknik değerlendirme görüşmeleri için bir ön taahhüt gerekmez.

Kaynaklar:

• Kişisel Verileri Koruma Kurumu — Veri İhlali Bildirimi (2019/10 sayılı Kurul kararı)
• Kişisel Verileri Koruma Kurumu — Kişisel Veri Güvenliği İhlalinin Geç Bildirimi