Bir fidye yazılımı saldırısı, tatil gününde mağazayı çevrim dışı bırakıyor. Yedekler var; ancak tek hosting hesabı ulaşılamayan kurucuya ait, DNS kurtarma adımları yazılmamış ve en yeni paketin temiz olup olmadığı bilinmiyor. Ele geçirilmiş hesaba hemen geri yükleme yapmak kanıtları yok edip saldırıyı yeniden başlatabilir.
Tek başına yedek, olayın nasıl yönetileceğini belirlemez. Felaket kurtarma planı; yetkiyi, güvenilir erişimi, temiz altyapıyı, kurtarma noktalarını, dış bağımlılıkları, iletişimi ve iş birimi onayını bir araya getirir.
Bu konu ne anlama gelir?
WordPress felaket kurtarma planı; ağır kesinti, saldırı veya veri kaybından sonra kabul edilebilir hizmeti geri getirmek için kullanılan güncel runbook’tur. Olayı kimin ilan edeceğini, hangi kurtarma hedeflerinin geçerli olduğunu, erişim bilgileriyle yedeklere nasıl ulaşılacağını ve sistemi kimin onaylayacağını belirler.
Yedek bu planın yalnız bir parçasıdır. Olayın yayılmasını sınırlama, etkilenen sistemleri izole etme, alan adı ve DNS kontrolü, hosting ve bulut hesapları, dış hizmetler, kanıtların korunması, müşteri iletişimi ve kurtarma noktasından sonraki geçerli işlemlerin eşleştirilmesi de plana dahildir.
Gerçekçi bir WordPress örneği
Fidye yazılımı olayında ekip önce etkilenen sistemleri korumaya alıyor, güvenilir iletişim kanalına geçiyor ve alan adı kayıt kuruluşu ile hosting için alternatif erişimi doğruluyor. Saldırıdan önce alındığı bilinen daha eski bir yedek, yalıtılmış temiz altyapıya geri yükleniyor.
Güvenlik ve iş birimi; giriş, ödeme, veri bütünlüğü ve daha sonraki siparişlerin planını onaylayana kadar e-posta, ödeme ve webhook bağlantıları kapalı kalıyor. DNS ancak bu onaydan sonra taşınıyor.
Neden önemlidir ve ne zaman kullanılır?
Kaybı müşterileri, geliri, işletimi, uyumluluğu veya itibarı önemli ölçüde etkileyecek her canlı site sınanmış plana ihtiyaç duyar. Planı olay sırasında yazmak zaman kaybettirir ve tehlikeli kestirme yollara iter.
RPO ve RTO hedeflerini yalnız teknik ekiple değil, iş birimleriyle belirleyin. Asıl ve yedek sorumluları atayın; WordPress, şirket e-postası, kimlik sağlayıcı veya ana hosting hesabı kapalıyken de runbook’a ulaşılabilmesini sağlayın.
Yeni başlayanlar için anlaşılır yol
- Sağlayıcı kaybı, zararlı yazılım, yanlışlıkla silme, hesap ele geçirme, DNS veya sertifika hatası ve bölgesel kesinti senaryolarını listeleyin.
- Olay yöneticisini, iş birimi onayını, teknik sorumluları, yedek kişileri ve iletişim sorumlusunu belirleyin.
- Alan adı kayıt kuruluşu, DNS, hosting, bulut depolama, şifreleme anahtarları, yedek kataloğu ve kritik hizmetlere bağımsız erişimi belgeleyin.
- Her senaryo için sınırlama, kurtarma noktası seçimi, temiz geri yükleme, dış hizmetlerin kapatılması, kabul testleri ve trafik geçişini tanımlayın.
- Masa başı ve teknik geri yükleme tatbikatı yapın. Süreleri, eksik erişimleri, doğaçlama kararları ve runbook düzeltmelerini kaydedin.
İleri teknik yol
Bağımsız acil durum hesapları, korunan loglar, bağımlılık haritaları, temiz sistem imajları, bütünlük referansları ve kurtarma noktasından sonraki işlemler için kayıt kullanın. Tatbikatta ana kimlik sağlayıcısının veya hosting hizmetinin çalışmadığını varsayın.
Karar ve iletişim sürelerini geri yükleme süresinden ayrı ölçün: olayın ilanı, yetkinin doğrulanması, güvenilir erişimin alınması, kurtarma noktasının seçimi, ilk güvenli müşteri akışı, durum duyurusu ve veri eşleştirmesinin başlaması.
Riskler, sık hatalar, yedekleme ve geri alma
Yalnız WordPress içinde duran runbook, ortak yönetici parolaları, sınanmamış acil erişim ve şüpheli altyapıya geri yükleme olayı büyütebilir. Tatbikat sırasında gerçek e-posta, ödeme veya canlı webhook trafiği oluşmamalıdır.
Yetki belirsizse, güvenilir iletişim yoksa, paket doğrulanamıyorsa, temiz altyapı yalıtılmamışsa, kanıt gereksinimleri planlanan işlemle çelişiyorsa veya müşteriler onaylanmamış sisteme yönlenecekse durun.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, felaket kurtarma planının kullanacağı desteklenen WordPress yedek işlerini ve kurtarma dosyalarını yönetebilir. Dosya ve veritabanı kapsamını, hedefi, zamanlamayı, saklama politikasını, şifreleme gereksinimini ve sorumlu kişiyi belirleyin. Yedek kataloğuna etkilenen siteden bağımsız erişilebilmelidir.
Runbook, tatbikat veya olay için hangi AIOWS kurtarma noktasının kullanılacağını ve bütünlüğüyle geri yükleme yolunun nasıl doğrulanacağını açıklamalıdır. Yalnız yalıtılmış altyapıya geri yükleyin, dış bağlantıları kapalı tutun ve trafiği yönlendirmeden önce öncelikli iş akışlarını sınayın.
Yedekleme Yöneticisi olay yöneticisinin, alternatif alan adı erişiminin, ele geçirilmiş hesabı temizlemenin, adli kararların veya iş birimi onayının yerini alamaz. Kullanılan dosyayı, zamanları, geri yükleme sonucunu, ulaşılan RPO ve RTO değerlerini, sonraki veri eşleştirmesini ve yeni tatbikat tarihini kaydedin.
AIOWS Yedekleme Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Yedekleme, Geri Yükleme ve Site Taşıma Rehberi
- Site Dışı WordPress Yedeği Nasıl Güvenle Oluşturulur?
- WordPress Yedek Saklama Politikasını Güvenli Katmanlarla Kurma
Sonuç ve önerilen yol
Çevrim dışıyken de erişilebilen runbook’ta yetkileri, alternatif hesapları, sınanmış kurtarma noktalarını, temiz altyapıyı ve senaryoya özgü kararları açıkça belirtin. Ana hesapların kaybını prova edin ve planı ölçülen eksiklere göre güncelleyin.
