Yedek aldığınızı değil, geri dönebildiğinizi doğrulayın

Örnek bir iş senaryosu

Bir işletme her gece veritabanını kopyalıyor fakat müşteri eklerini yedeklemiyor olsun. Arıza sonrası kayıt listesi geri gelirken belgeler kaybolur. Başka bir durumda çalışan SQLite dosyasını yalnızca dosya kopyasıyla almak tutarsız sonuç yaratabilir; veritabanına uygun yedek yöntemi kullanılmalıdır. Deneme geri yüklemesi ayrı bir ortamda yapılmalı ve gerçek işlemler bu ortamdan dış sistemlere gönderilmemelidir.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Geri dönüş tatbikatında yalnızca uygulamanın açıldığını görmekle yetinmeyin. Yakın tarihli birkaç kayıt, eski bir kayıt, ilişkilendirilmiş dosya ve yetki davranışını kontrol edin. Yedekten dönen sistemin e-posta, SMS veya dış entegrasyonları yanlışlıkla gerçek alıcılara işlem göndermemesi için test ortamı ayrılmalıdır. Kurtarma adımlarını uygulamayı geliştiren kişi dışında bir ekip üyesinin de anlayabilmesi önemlidir. Parola veya anahtar gereksinimleri güvenli bir süreçle karşılanmalı; yedek dosyasının yanına düz metin sırlar bırakılmamalıdır. Tatbikatta karşılaşılan eksikleri belgeleyip sonraki denemede kapandıklarını doğrulayın. Geri dönüş süresi ölçülmeden verilen süre taahhütleri varsayım olarak kalır.

Kontrolü kanıtla kapatma

Güvenlik ve yayın kontrolünde her madde için gözlenebilir bir sonuç belirleyin. “Giriş güvenli” demek yerine yetkisiz isteğin reddedildiğini, çıkış sonrası oturumun çalışmadığını veya çok büyük form gövdesinin kabul edilmediğini test edin. Sonuçları kullanılan sürüm ve tarih bilgisiyle kaydedin. Böylece daha sonraki değişikliklerde aynı davranış yeniden kontrol edilebilir. Test verileri gerçek müşteri verisinden ayrılmalıdır. Kayıt oluşturan testler sonrasında yalnızca test kayıtlarının temizlendiği doğrulanmalıdır. Başarılı kontrolün kapsamını açık tutun; birkaç test bütün sistemin kusursuz olduğunu göstermez.

Uygulama ile sunucu sorumluluklarını ayırın. Kod alan doğrulamasını yapabilir fakat dosya izinleri, sertifika bağlaması ve yedek erişimi sunucu düzeyinde doğru kurulmalıdır. Bir katmanın varlığı diğerini gereksiz hale getirmez. Kaynak dosyaları, yapılandırma sırları ve veritabanı herkese açık web klasörüne konulmamalıdır. Kullanıcıya gösterilen hata mesajı teknik ayrıntı veya gizli bilgi içermemeli; sunucu tarafındaki kayıt tanı koymaya yetecek kadar bilgi taşımalıdır. Yeni bir bileşen eklendiğinde saldırı yüzeyi ve bakım sorumluluğu da değerlendirilmelidir. Gereksiz özellikleri açık bırakmak sonraki kontrol yükünü artırır.

Kontrolleri tek seferlik teslim maddesi olarak görmeyin. Yeni sürüm, yeni entegrasyon veya yetki değişikliği bazı varsayımları geçersiz kılabilir. Düzenli bağımlılık taraması, erişim gözden geçirmesi ve geri dönüş denemesi planlayın. Otomatik taramanın bulgu vermemesi bütün açıkların bulunmuş olduğu anlamına gelmez. Kritik uygulamalarda kapsamlı bağımsız güvenlik değerlendirmesi ayrıca düşünülmelidir. Küçük bir işletme için başlangıçta en değerli adım çoğu zaman sorumlulukları ve kontrol takvimini netleştirmektir. Sertifika, yedek ve yönetici hesabı gibi temel bileşenlerin sahibi belli olduğunda sorunlar kişisel hafızaya daha az bağımlı kalır.

Ekibinize sorabileceğiniz sorular

• Belgeler de geri geliyor mu?
• Son geri dönüş denemesi ne zaman yapıldı?
• Sunucu kaybında ayrı kopya erişilebilir mi?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.