Yedekleme ve izleme: sisteminizin canlıya geçişten sonra ihtiyacı olanlar

Canlıya geçiş günü herkes projenin bittiğini hisseder. Oysa o andan itibaren siparişler, faturalar ve depo hareketleri her gün sistemden geçmeye başlar ve sistemin durması, işin kendisinin durması anlamına gelir.

Verileri kimin koruduğu ve sistemi kimin izlediği net değilse, ilk büyük arıza bu soruların ilk gerçek sınavı olur. Bu makalede sisteminizin operasyon döneminde neye ihtiyaç duyduğunu anlatıyoruz: güvenebileceğiniz yedekler, sorunu erkenden fark eden izleme, belirli bir kişiye ulaşan uyarılar ve arıza anında neler olacağını belirleyen yazılı bir plan.

Geri yüklemesi test edilmemiş bir yedek güvence değildir

Yedek almak, o yedeğin geri yüklenebilir olduğu anlamına gelmez. Sorun, yedeğe ihtiyaç duyduğunuzda ortaya çıkar: eksik bir dosya, açılmayan bir yedek ya da işin kaldırabileceğinden çok daha uzun süren bir geri yükleme.

Bu nedenle ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), fidye yazılımlarına karşı hazırladığı rehberde yedeklerin erişilebilirliğinin ve bütünlüğünün bir felaket kurtarma senaryosunda düzenli olarak test edilmesini önerir. Pratikte bu, tam bir yedeği ayrı bir ortama geri yüklemeniz, sistemin bu yedek üzerinde çalıştığından ve son işlemlerin yedekte yer aldığından emin olmanız demektir.

Bir de yalnızca teknik ekibin değil, işletme sahibinin verdiği kararlar vardır:

• Yedek ne sıklıkla alınacak? Bu sorunun ardındaki asıl soru şudur: Sistem şu anda arızalansa, ne kadarlık bir işi kaybedip sisteme yeniden girmeyi kabul edebilirsiniz?
• Yedekler ne kadar süre saklanacak? Bu, muhasebe ve yasal yükümlülüklerinizle ve verilerdeki bir hatanın fark edilmeden geçebileceği süreyle bağlantılıdır.
• Sistemin yeniden devreye girmesi için kabul edilebilir süre ne kadar? Satış sezonundaki bir e-ticaret sitesi ile aylık raporlama sistemi aynı değildir.

Bu kararlar için genel rakamlar vermiyoruz, çünkü şirketten şirkete değişirler. Ancak yazılı hâle getirilmelerini ve onaylanmalarını, yedeklemenin de bunlara göre tasarlanmasını istiyoruz.

Bir çalışanın yanlışlıkla bir grup ürün kaydını sildiğini ve bunun ancak iki hafta sonra fark edildiğini varsayalım. Yedekler yalnızca birkaç gün saklanıyorsa, hatadan öncesine ait bir yedek bulamazsınız. Bu yüzden saklama süresi yalnızca depolama alanıyla değil, işinizdeki hataların ne kadar hızlı fark edildiğiyle de bağlantılıdır.

Birden fazla konum, ayrı erişim

Sunucunun kendisinde saklanan bir yedek, disk arızalanırsa ya da sunucuya sızılırsa sunucuyla birlikte kaybolur. Bu nedenle yedekler birden fazla yerde saklanır; bunlardan biri sistemin bulunduğu yerin dışında, başka bir veri merkezinde ya da bağımsız bir depolama sağlayıcısında tutulur.

CISA rehberi, birçok fidye yazılımının silmek ya da şifrelemek için erişilebilir yedekleri aradığını belirtir; çevrim dışı ve şifrelemeyle korunan yedekler tutulmasını ve depolama birimlerinde silme korumasının etkinleştirilmesini önerir. Bunun pratik sonucu şudur: Sistemi yöneten hesap, yedekleri silebilecek durumda olmamalıdır.

Yedekleme ile yetkiler burada kesişir. “Kullanıcı yetkileri ve denetim kaydı: her yönetim sisteminde güvenin temeli” başlıklı makalede, tek bir hesabın sistemi tek başına kötüye kullanmaya yetecek yetkiye neden sahip olmaması gerektiğini anlatmıştık. Aynı kural burada da geçerlidir: Sistemi günlük olarak işleten kişi ile yedekleri silme yetkisine sahip kişi farklıdır.

Sunucu yöneticisi hesabının parolasının çalındığını varsayalım. Yedekler aynı hesabın altındaysa, sistemle birlikte aynı saat içinde silinebilir. Ayrı bir erişimle saklanıyor ve silmeye karşı korunuyorsa, geri dönüş noktası sağlam kalır.

Neleri izlemelisiniz?

İzleme, bir müşteri ya da çalışan arayıp haber vermeden önce ekibinizin sorundan haberdar olması demektir. Her şeyi izlemenize gerek yoktur; izlemeniz gereken, genellikle bir kesintiden önce beliren göstergelerdir:

• Erişilebilirlik: Sistem ve API’ler iç ağın dışından yanıt veriyor mu?
• Hatalar: başarısız sonuçlanan isteklerde ani bir artış.
• Yavaş işlemler: açılması alışılmadık derecede uzun sürmeye başlayan bir rapor ya da ekran.
• Disk alanı: Veri tabanı, dosyalar ve log kayıtları, disk dolana kadar her gün büyür.
• Arka plan işleri: muhasebe kayıtlarının deftere işlenmesi, şube senkronizasyonu ya da rapor hazırlama gibi işlerin sessizce başarısız olması.
• Sertifikaların süresinin dolması: sitenin ya da API’lerin güvenlik sertifikasının bitiş tarihinin yaklaşması.

Şubeler arasındaki gece senkronizasyon işinin durduğunu varsayalım. Ekranlarda hiçbir şey görünmez, ama depodaki stok bakiyeleri gün geçtikçe gerçeklikten uzaklaşır. İlk başarısızlıkta uyaran bir izleme, sorunu stok sayımına kalmadan, ortaya çıktığı gün yakalar.

Log kayıtları

Bir arıza olduğunda, ne olduğunu anlamanın temel kaynağı log kayıtlarıdır. OWASP yönergeleri, uygulamanın her olay için ne zaman ve nerede gerçekleştiğini, kimin yaptığını ve ne olduğunu kaydetmesini, log kayıtlarının da kurcalanmaya karşı korunmasını önerir. Biz buna, log kayıtlarının onları üreten sunucunun dışına kopyalanmasını da ekliyoruz; böylece sunucu arızalansa bile erişilebilir kalırlar.

Log kayıtları, çalışandan yaptıklarını adım adım tekrarlamasını istemeden, bir ödemenin neden başarısız olduğu ya da bir raporun neden geciktiği gibi günlük sorularda da yardımcı olur.

Adı belli bir kişiye ulaşan uyarı, arızalar için bir kılavuz

Kimsenin okumadığı genel bir e-posta adresine gönderilen uyarı, hiç uyarı olmamasından pek farklı değildir. Her uyarı türü için adı belli bir sorumlu, o yokken yerine bakacak bir vekil ve bu kişinin gerçekten baktığı bir kanal belirlenir; örneğin WhatsApp ya da cep telefonundaki bir uyarı uygulaması.

Uyarılar çoğaldıkça değerleri azalır. Ekip her gün hiçbir şey yapılmasını gerektirmeyen çok sayıda uyarı alıyorsa, önemli olan uyarıyı da görmezden gelecektir. Bu nedenle uyarılar canlıya geçişten sonra gözden geçirilir ve gerçek bir müdahale gerektirmeyenler kaldırılır.

Uyarının kendisi de tıpkı yedek gibi test edilir: Test ortamında bilerek basit bir arıza oluşturulur, mesajın doğru kişiye ulaştığı ve bu kişinin ne yapacağını bildiği doğrulanır.

CISA rehberi ayrıca bir olay müdahale planı hazırlanmasını, bu planın güncel tutulmasını ve düzenli olarak tatbikatının yapılmasını önerir. Yönetim sistemlerinde başlangıç için, belirli sorulara yanıt veren basit ve yazılı bir operasyon kılavuzu yeterlidir:

1. Bir arıza olduğunu nasıl anlarız ve bunu kim doğrular?
2. Şirket içinde kime haber verilir, şubelere ve müşterilere ne söylenir?
3. Bilinen her arıza türünde ilk adımlar nelerdir?
4. Yedekten geri yüklemeye ne zaman karar veririz ve bu karar kimin yetkisindedir?
5. Arıza giderildikten sonra olanları nasıl belgeleriz ve tekrarlanmaması için neyi değiştiririz?

Canlıya geçişten sonra sistemin sahibi kim?

Canlıya geçiş ile operasyonu birbirinden ayırıyoruz. Canlıya geçiş, tarihi belli bir olaydır; operasyon ise sürekli bir iştir: güvenlik güncellemeleri, yedeklerin gözden geçirilmesi, uyarıların takibi ve planlanmış yükseltmeler. Canlıya geçişten sonra sistemlere zarar veren şey çoğu zaman, her tarafın bu işlerin diğer tarafta olduğunu düşünmesidir.

Bu yüzden operasyonu kimin üstleneceği canlıya geçişten önce netleştirilir: kendi iç ekibiniz, tedarikçi ya da ikisi arasında net bir iş bölümü. Sorumluluklar herkesin bildiği tek bir belgeye yazılır: yedekleri kimin gözden geçireceği, uyarıları kimin alacağı, güncellemeleri kimin onaylayacağı ve sunuculara kimin erişimi olduğu.

Operasyonu tedarikçi üstleniyorsa, yedeklerin şirketinize ait bir hesapta tutulmasını talep edin; geri yükleme testlerinin sonuçlarını ve tetiklenen uyarıları içeren düzenli bir rapor da isteyin. Veriler sizin verilerinizdir; sistemi yöneten taraf değişse bile onlara erişebilmeniz gerekir.

Operasyonunu kimsenin üstlenmediği bir sistem ilk arızaya kadar çalışır; sonra iş dururken sorumlu aranmaya başlanır.

Canlıya geçiş sonrası kontrol listesi

• Tam bir yedeğin ayrı bir ortama geri yüklenerek test edilmesi; test düzenli olarak tekrarlanır.
• Yedekleme sıklığı, saklama süresi ve sistemin yeniden devreye girmesi için kabul edilebilir süre hakkında yazılı bir karar.
• Sistemin bulunduğu yerin dışında, ayrı erişimli ve silmeye karşı korumalı bir yedek.
• Erişilebilirlik, hatalar, yavaşlık, disk alanı, arka plan işleri ve sertifika sürelerinin izlenmesi.
• Her uyarı için adı belli bir sorumlu ve bir vekil.
• Sunucu dışında saklanan ve değiştirilmeye karşı korunan log kayıtları.
• Arızalar için yazılı ve ekibin üzerinde tatbikat yaptığı bir operasyon kılavuzu.
• Operasyondan ve güncellemelerle yükseltmelerin onaylanmasından sorumlu, kim olduğu bilinen bir kişi.

Bu maddeler karmaşık araçlardan çok net kararlar ve kim olduğu bilinen sorumlular gerektirir. Backend servislerini ve API’leri geliştirirken yedeklemeyi, izlemeyi ve log kayıtlarını canlıya geçişten sonra değil, onlarla birlikte tasarlıyoruz.

Sisteminiz bugün test edilmiş yedekler ya da net bir izleme olmadan çalışıyorsa veya yeni bir sistemin canlıya geçişine hazırlanıyorsanız, durumunuzu ITS ekibiyle görüşebilirsiniz; operasyon planınızı ilk arıza sınamadan önce birlikte gözden geçirelim.