Fintech Şirketlerinde Felaket Kurtarma Nasıl Sağlanır?

Felaket kurtarma, beklenmedik bir olayın ardından bilgi sistemlerini ve verileri yeniden kullanılabilir hale getiren süreçlerin bütünüdür. İngilizcede Disaster Recovery, kısaca DR olarak adlandırılır. Fintech şirketiniz için bu süreç; ödeme uygulamasının, işlem kayıtlarını tutan veri tabanının ve hizmetin bağlı olduğu diğer sistemlerin kurtarılmasını kapsar. İş sürekliliği planınız ise personel, müşteri iletişimi ve operasyon gibi daha geniş konuları da içerir.

Bir ödeme hizmetinde kısa süreli kesinti bile çok sayıda işlemi etkileyebilir. Örneğin şirketinizin sanal POS altyapısı çalışmadığında, hizmet verdiğiniz mağazalar da ödeme alamaz. Müşteri destek talepleri birikirken yarıda kalan işlemlerin durumunu araştırmanız gerekir. Önceden hazırlanmış bir kurtarma planı, bu işlerin kim tarafından ve hangi sırayla yürütüleceğini belirler.

Hizmeti yeniden açarken finansal kayıtların tutarlılığını da kontrol etmelisiniz. Kesinti anında banka tarafından onaylanan bir ödeme, uygulamanızda henüz tamamlanmış görünmeyebilir. Aynı işlemi yeniden gönderirseniz mükerrer tahsilat riski doğabilir. Bu yüzden kurtarma sonrasında işlem kimliklerini ve banka yanıtlarını karşılaştırarak eksik ya da tekrarlanan kayıtları tespit edebilmeniz önemlidir.

Fidye yazılımları, verilerinizi şifreleyerek uygulamalarınızı kullanılamaz hale getirebilir. Saldırgan yedekleme hesabına da erişirse geri dönüş için sakladığınız kopyalar zarar görebilir. Bu nedenle üretim ortamıyla yedeklerin erişim yetkilerini ayrı değerlendirmelisiniz. Saldırı sonrasında kullanılacak kurtarma ortamının temiz olduğunu doğrulamak da planınızın bir parçası olmalıdır.

Donanım arızası, elektrik kesintisi, yangın veya deprem gibi olaylar altyapınızı etkileyebilir. İki sunucunuzun aynı binada bulunması, bina kullanılamaz hale geldiğinde yeterli koruma sağlamaz. Yedek ortamın konumunu seçerken elektrik beslemesini, bağlantı hatlarını ve bölgesel afet risklerini birlikte inceleyebilirsiniz. Böylece aynı olayın her iki ortamı da etkileme olasılığını azaltırsınız.

Günlük operasyonlar sırasında yapılan hatalar da ciddi kesintiler yaratabilir. Yanlış bir veri tabanı komutu, hatalı güvenlik duvarı kuralı veya sorunlu yazılım güncellemesi ödeme akışını durdurabilir. Kurtarma senaryolarınızda bu durumlara da yer verin. Bazı olaylarda önceki yazılım sürümüne dönmeniz, bazılarında ise veriyi belirli bir zamana geri yüklemeniz gerekir.

Bankalar, kimlik doğrulama servisleri ve internet sağlayıcılarıyla kurduğunuz bağlantılar da hizmetinizi etkiler. Sizin sunucularınız çalışırken dışarıdaki bir servisin kesilmesi işlemleri durdurabilir. DDoS saldırılarında ise yoğun saldırı trafiği erişimi engelleyebilir. Bu senaryolar için bağlantı alternatiflerini, ağ korumasını ve bekleyen işlemlerin nasıl yönetileceğini ayrıca planlayabilirsiniz.

İlk adım, şirketinizde hangi hizmetin neye bağlı olduğunu çıkarmaktır. Ödeme işlemi için veri tabanı, kimlik doğrulama servisi ve banka bağlantısı birlikte çalışıyor olabilir. Bu bağımlılıkları bir envanterde toplayın. Ardından iş etki analizi yaparak her hizmette yaşanacak kesintinin müşterilerinize ve operasyonunuza etkisini değerlendirin. Ödeme kabulüyle şirket içi raporlama ekranının kurtarma önceliği aynı olmayabilir.

Bu değerlendirmeyi iki ölçülebilir hedefe dönüştürebilirsiniz. RTO, hizmeti en geç ne kadar sürede yeniden çalıştırmayı hedeflediğinizi belirtir. RPO ise geri dönebildiğiniz son veri noktasıyla kesinti anı arasındaki kabul edilebilir zaman aralığıdır. Örneğin 15 dakikalık RPO, son 15 dakikalık verinin kurtarma kapsamı dışında kalabileceği anlamına gelir. Finansal işlemler için böyle bir kaybın kabul edilip edilemeyeceğini ayrıca değerlendirmelisiniz.

Sonraki adım, müdahale sırasını ve sorumluları yazmaktır. Kurtarma planını kimin devreye alacağı, yedek ortama geçişi kimin onaylayacağı ve müşterilere kimin bilgi vereceği belli olmalıdır. Ekiplerin ihtiyaç duyduğu erişim bilgilerini güvenli biçimde saklayın. İlgili kişi ulaşılamadığında görevi devralacak kişiyi de belirleyin.

Planı tamamladığınızda gerçekçi senaryolarla deneyin. Örneğin test sırasında ana veri tabanının kullanılamadığını varsayarak yedek ortamdan bir ödeme akışını çalıştırabilirsiniz. Geçen süreyi, eksik bağlantıları ve manuel müdahaleleri kaydedin. Ana ortama dönüş adımlarını da test edin; yeni bir uygulama veya banka entegrasyonu eklendiğinde planı bu değişikliğe göre güncelleyin.

Önce kurtarma için hangi verilere ihtiyaç duyduğunuzu belirleyin. İşlem kayıtlarının yanında uygulama ayarları, kullanıcı yetkileri ve denetim kayıtları da gerekli olabilir. Şifreli verilere erişmek için kullandığınız anahtarların kurtarma ortamında güvenli biçimde kullanılabilmesini planlayın.

Yedekleme sıklığını verinin değişim hızına ve belirlediğiniz RPO hedefine göre ayarlayabilirsiniz. Tam yedekleme, seçilen verinin tamamını kopyalar. Artımlı yedekleme ise önceki yedekten sonra değişen bölümleri saklar. Veri tabanınız destekliyorsa işlem günlükleriyle belirli bir zamana dönüş de yapabilirsiniz. Örneğin hatalı bir güncellemeden hemen önceki durumu geri yüklemek isteyebilirsiniz. Kullanacağınız yöntem, geri yükleme süresiyle depolama ihtiyacını birlikte etkiler.

Yedeklerinizi üretim sistemindeki bir saldırıya karşı da koruyun. CISA'nın fidye yazılımı rehberi, çevrimdışı ve şifreli yedekler tutulmasını, bu kopyaların düzenli olarak test edilmesini önerir. Değiştirilemez saklama seçenekleri de belirlenen süre boyunca yedeklerin silinmesini veya değiştirilmesini sınırlandırabilir. Erişim yetkilerini daraltarak ve yönetim hesaplarında çok faktörlü kimlik doğrulama kullanarak bu korumayı destekleyebilirsiniz.

Yedekleme ekranında başarılı sonucu görmeniz, uygulamanın geri dönebileceğini tek başına göstermez. Test ortamında geri yükleme yaparak dosyaların açıldığını, veri tabanının çalıştığını ve uygulamanın doğru kayıtlara eriştiğini kontrol edin. Verileri sürekli başka bir ortama çoğaltıyorsanız geçmişe dönük yedekleri de saklayın. Hatalı bir silme işlemi, çoğaltma yoluyla ikinci ortama da taşınabilir.

Bulut tabanlı felaket kurtarmada uygulamalarınızın çalışabileceği alternatif bir ortam hazırlanır. Verileriniz bu ortama yedekleme veya çoğaltma yoluyla aktarılır. Kesinti yaşandığında gerekli kaynaklar devreye alınır ve trafik kurtarma ortamına yönlendirilir. Geçişin otomatik mi yoksa onayla mı yapılacağı, iş yükünüzün ihtiyaçlarına ve olayın türüne göre belirlenir.

Bu ortamı farklı hazırlık seviyelerinde kurabilirsiniz. Yedekten geri yükleme yaklaşımında altyapıyı ve uygulamaları yeniden açmak daha uzun sürebilir. Daha hızlı dönüş gereken hizmetlerde ise sistemin düşük kapasiteli, çalışır bir kopyası hazır tutulabilir. Hazır kapasite arttıkça bekleme maliyeti de artabilir. Seçiminizi kesintinin işletmenize etkisi ve hedeflediğiniz kurtarma süresi üzerinden yapabilirsiniz.

Uygulamanın bulutta açılmasıyla birlikte banka bağlantılarının ve erişim kurallarının da çalışması gerekir. Örneğin bankanızın izin verdiği IP adresleri değişirse ödeme istekleri reddedilebilir. Bu nedenle bağlantıları, sertifikaları ve erişim yetkilerini geçiş öncesinde doğrulayın. Sağlayıcınızla kurtarma kapsamını, kapasiteyi ve görev paylaşımını sözleşmede netleştirmeniz de önemlidir.

DT Cloud olarak felaket kurtarma çözümlerimizde yedekleme, veri çoğaltma ve bulut entegrasyonu seçenekleri sunuyoruz. Türkiye'deki altyapımız üzerinde planlayacağınız kurtarma ortamını, mevcut sistemleriniz ve sektörünüzün gereksinimleriyle birlikte değerlendirebilirsiniz. Şirketinizin ödeme akışlarına uygun yapıyı belirlemek için ekibimizle iletişime geçebilirsiniz.

Fintech şirketinizin tabi olduğu kurallar, sunduğunuz hizmete ve faaliyet izninize göre değişir. Türkiye'de ödeme ve elektronik para kuruluşları için TCMB'nin bilgi sistemlerine ilişkin tebliği, süreklilik planı ve yedek sistemler konusunda yükümlülükler içerir. Tebliğin 14. maddesi, bilgi sistemleri süreklilik planının her yıl en az bir kez test edilmesini öngörür. Test kapsamını da kuruluşunuzun yapısına ve ilgili hükümlere göre belirlemelisiniz.

Veri yerleşimi, sağlayıcı seçiminizi doğrudan etkileyen başka bir konudur. Tebliğin 21. maddesi, kapsamındaki kuruluşların birincil ve ikincil sistemleriyle veri yedekleme merkezleri için yurt içinde bulunma şartı getirir; düzenlemedeki istisnalar ayrıca değerlendirilir. Bulut hizmeti alırken dış hizmet alımı koşullarını da incelemelisiniz. Hizmeti dışarıdan almanız, kuruluşunuzun sorumluluğunu ortadan kaldırmaz.

ISO 22301, iş sürekliliği yönetim sisteminin kurulması ve geliştirilmesi için bir çerçeve sunar. ISO/IEC 27001 ise bilgi güvenliği risklerinin yönetimine odaklanır. Sağlayıcınızın belgelerini incelerken hangi hizmetleri ve lokasyonları kapsadığını kontrol edebilirsiniz. Kendi planınızın işlerliğini de test sonuçları, güncel görev dağılımı ve ölçülen kurtarma süreleri üzerinden takip etmelisiniz.

Felaket kurtarma (Disaster Recovery) nedir?
Felaket kurtarma, kesinti veya veri kaybı sonrasında bilgi sistemlerini ve verileri yeniden kullanılabilir hale getiren süreçlerin bütünüdür. Yedekleme, alternatif ortam, müdahale adımları ve kurtarma testleri bu sürecin parçalarıdır.

Fintech şirketlerinde felaket kurtarma neden önemlidir?
Ödeme ve diğer finansal hizmetlerde yaşanan kesintiler, müşterilerinizin işlemlerini durdurabilir ve kayıt tutarsızlıklarına yol açabilir. Felaket kurtarma hazırlığı, hizmeti kontrollü biçimde yeniden açmanıza yardımcı olur.

Felaket kurtarma planı hangi aşamalardan oluşur?
Plan; risk ve iş etki analizi, kurtarma hedeflerinin belirlenmesi, altyapı seçimi ve sorumlulukların atanmasıyla oluşturulur. Testler ve düzenli güncellemelerle uygulanabilirliği korunur.

Felaket kurtarma ile veri yedekleme arasındaki fark nedir?
Veri yedekleme, bilgilerin geri yüklenebilir kopyalarını oluşturur. Felaket kurtarma ise bu verilerle birlikte uygulamaların, bağlantıların ve gerekli altyapının yeniden çalıştırılmasını kapsar.

Bulut tabanlı felaket kurtarma güvenli midir?
Uygun erişim kontrolleri, şifreleme, korunan yedekler ve düzenli testlerle güvenli bir kurtarma ortamı kurulabilir. Sağlayıcı seçerken veri yerleşimini, hizmet kapsamını ve sorumluluk paylaşımını da değerlendirmelisiniz.

Fintech şirketlerinde felaket kurtarma planı ne sıklıkla test edilmelidir?
TCMB'nin ilgili tebliği kapsamındaki ödeme ve elektronik para kuruluşlarında plan, her yıl en az bir kez test edilmelidir. Kritik sistem değişikliklerinden sonra ve risklerinizin gerektirdiği sıklıkta ek testler planlayabilirsiniz.