Anasayfa›Hizmetler›Bilgi Güvenliği ve Sağlık›ISO 27001 İş Sürekliliği ve Yedekleme: Felaket Anında Veri Nasıl Kurtarılır?
Felaket anında veriler nasıl kurtarılır?
ISO 27001’de iş sürekliliği ve yedekleme iki ayrı kontroldür: yedekleme (A.8.13) verinin kopyasını üretir, iş sürekliliği (A.5.29–A.5.30) ise kesinti anında hangi sürecin ne kadar sürede ayağa kalkacağını taahhüt eder. Test edilmemiş yedek, yedek değildir; geri dönüş tatbikatı yapılmadan bu kontroller kanıtlanamaz.
Fidye yazılımı vakalarının çoğunda şirketlerin yed^ği vardır. Sorun yedeğin varlığı değil, geri yüklemenin hiç denenmemiş olmasıdır. Kurtarma başladığında ortaya çıkan tablo hep aynıdır: yedek dosyası bozuk, şifreleme anahtarı aynı sunucuda, son başarılı yedek on bir gün önce alınmış ve kimse fark etmemiştir. ISO 27001 bu üç hatayı tek tek kapatmak üzere kurgulanmıştır.
Standart; yedeklenecek bilginin kapsamını, yedekleme sıklığını, saklama süresini, yedeğin şifrelenmesini, fiziksel/mantıksal olarak ayrı bir konumda tutulmasını ve düzenli geri yükleme testini ister. Yedekleme politikası bu unsurların tamamını içermeli, kayıtlar da politikanın uygulandığını göstermelidir.
Uygulamada en çok atlanan madde ayrıştırmadır. Yedek, kaynak sistemle aynı ağda ve aynı kimlik doğrulama alanında duruyorsa, kaynak sistemi ele geçiren saldırgan yedeği de ele geçirir. Bu nedenle 3-2-1 kuralı (üç kopya, iki farklı ortam, bir kopya dış konumda) ve mümkünse değiştirilemez (immutable) yedek alanı, denetçinin duymak istediği tasarım tercihleridir.
RTO (Kurtarma Süresi Hedefi) bir sürecin kesintiden sonra en geç ne kadar sürede çalışır hâle gelmesi gerektiğini, RPO (Kurtarma Noktası Hedefi) ise en fazla ne kadarlık veri kayıbının kabul edilebilir olduğunu gösterir. İkisi de iş etki analiziyle (BIA) belirlenir, teknik ekibin tahminiyle değil.
Basit bir karar kuralı işi hızlandırır: RPO’nuz yedekleme sıklığınızdan küçük olamaz. Günde bir kez yedek alıp “en fazla 1 saat veri kaybederiz” yazan bir plan, ilk denetimde kendi kendini çürütür. Aynı şekilde RTO’su 4 saat olan bir sistemin geri yükleme testi 9 saat sürüyorsa, ya altyapı ya da hedef değişmelidir.
Kritik sistemler için yılda en az bir kez tam geri yükleme, daha sık aralıklarla ise örnekleme yoluyla dosya/veritabanı geri dönüş testi beklenir. Test; tarih, katılımcı, geri yüklenen sistem, süre, karşılaşılan sorun ve düzeltici faaliyet alanlarını içeren bir kayda bağlanmalıdır.
Testi izole bir ortamda yapmak şarttır; canlıya geri yazan bir tatbikat, riski azaltmak yerine üretir. Test kaydında en değerli satır “sorunsuz tamamlandı” değil, “şu adımda takıldık ve şunu düzelttik” satırıdır. Denetçi, öğrenme izini arar.
Hayır. Felaket kurtarma planı teknolojiye odaklanır: sunucu, veri, ağ nasıl ayağa kaldırılır. İş sürekliliği planı ise sürece odaklanır: sistemler yokken iş nasıl yürütülür, kim kimi arar, müşteriye ne söylenir, manuel alternatif nedir. ISO 27001 ikisini de kapsar.
Bilgi güvenliği ekipleri genelde birincisini yazar, ikincisini unutur. Oysa kesintinin ilk saatinde en çok ihtiyaç duyulan şey, telefon numaralarının ve karar yetkisinin kimde olduğunun yazılı olduğu tek sayfalık bir kartlıktır.
Durumunuzu birkaç dakikada konuşalım; size özel süre ve yol haritası çıkaralım.
Evet. Paylaşılan sorumluluk modelinde sağlayıcı altyapının sürekliliğinden, veriden ve yapılandırmadan siz sorumlusunuz. SaaS uygulamalarında silinen veriyi geri getirme süresi genelde sınırlıdır; bağımsız bir yedek katmanı denetimde de beklenir.
Yedek, üretim verisinin birebir kopyasıdır; sınıflandırması da aynıdır. Gizli veri içeren yedeğin hem aktarımda hem depoda şifrelenmesi, anahtarın da yedekten ayrı yönetilmesi gerekir.
Önerilmez. İzole bir test ortamı kullanın. Üretime geri yazan test, veri kaybı riskini bizzat yaratır ve denetçi tarafından kontrol zayıflığı olarak değerlendirilebilir.
Standart doküman adı dayatmaz, ancak RTO ve RPO değerlerinin nasıl belirlendiğini kanıtlamanız gerekir. BIA bu gerekçeyi üretmenin en yaygın yoludur.
Vardır. Kişisel verinin erişilebilirliğinin korunması da bir güvenlik tedbiridir; veri kaybına yol açan bir olay ihlal bildirimi gerektirebilir. Yedekleme ve sürekliliği KVKK envanterinizle birlikte ele almak faydalıdır.