Bu makalede6 bölüm
- Teknoloji
- ISO/IEC 27001 Ek A, TISAX, IATF
- Konu
- Yedekleme kanıtı
- Seviye
- Başlangıç
Denetimlerde “yedek alıyor musunuz?” sorusuna verilen “evet” cevabı artık yeterli değil. ISO 27001, TISAX ve IATF 16949 denetçileri, yedeklerin politikaya uygun alındığını ve geri yüklemenin düzenli olarak test edildiğini gösteren kanıt ister. Yedekleme yazılımının yeşil raporu, verinin gerçekten kullanılabilir şekilde geri gelebileceğini kanıtlamaz. Bu rehber, denetimde sunulabilir yedekleme kanıtlarının nasıl hazırlanacağını anlatır.
Kanıt zinciri: politika → iş → test → aksiyon
| Halka | Kanıt | Denetçinin sorusu |
|---|---|---|
| Politika | Sistem bazında sıklık, saklama süresi, konum, sorumlu | Neyi, ne sıklıkla yedeklemeyi taahhüt ediyorsunuz? |
| Kapsam | Envanter–yedek mutabakatı | Tüm kritik sistemler yedekleniyor mu? |
| İş izleme | Günlük/haftalık iş raporları, başarısız işlerin kapanışı | Başarısız yedekler fark ediliyor ve düzeltiliyor mu? |
| Geri yükleme testi | Tarihli test kayıtları | Veriyi gerçekten geri getirebildiniz mi, ne kadar sürede? |
| Aksiyon | Testte bulunan sorunların düzeltme kaydı | Test sonuçlarından ne öğrendiniz? |
İyi bir geri yükleme test kaydı
- Tarih ve test eden kişi.
- Sistem ve veri: Ör. “ERP veritabanı, üretim şirketi kodu”.
- Test türü: Dosya, sanal makine, veritabanı veya uygulama düzeyinde.
- Kullanılan yedek: Tarih ve kopya (yerel, site dışı, değiştirilemez).
- Süre: Başlangıç–bitiş; RTO hedefiyle karşılaştırma.
- Veri güncelliği: Geri gelen son işlem zamanı; RPO hedefiyle karşılaştırma.
- Doğrulama: Uygulama sahibinin “veri kullanılabilir” onayı (ör. örnek sipariş açıldı, rapor üretildi).
- Sonuç ve aksiyon.
Ne sıklıkla test etmeli?
Standartlar belirli bir sıklık vermez; politikada riskle gerekçelendirilir. Yaygın uygulama: kritik sistemler için üç ayda bir, diğerleri için yılda bir, ayrıca büyük değişikliklerden (sürüm yükseltmesi, depolama değişikliği) sonra. Testler bir takvime bağlanmalı ve her test bir öncekinden farklı sistemi kapsayacak şekilde dönüşümlü planlanabilir.
Fidye yazılımı dönemi için ek kanıtlar
Saldırganlar artık önce yedekleri hedef alıyor. Bu nedenle denetimlerde şu sorular da gündeme geliyor:
- En az bir yedek kopyası değiştirilemez veya çevrimdışı mı?
- Yedek sistemi, etki alanı yönetici hesaplarından bağımsız kimlik bilgileriyle mi yönetiliyor?
- Yedek konsoluna erişimde MFA var mı?
- Kimlik altyapısı (AD) kaybedildiğinde yedekten geri dönüş mümkün mü?
Yaygın 3-2-1-1-0 yaklaşımı (üç kopya, iki farklı ortam, bir site dışı, bir değiştirilemez/çevrimdışı, sıfır hatalı doğrulama) bu sorulara pratik bir çerçeve sunar.
Üç çerçevede aynı kanıt
| Çerçeve | İlgili gereklilik (özet) |
|---|---|
| ISO/IEC 27001:2022 | Ek A bilgi yedekleme ve iş sürekliliği için BİT hazırlığı kontrolleri |
| TISAX (VDA ISA) | Yedekleme ve kurtarma ile iş sürekliliği kontrolleri |
| IATF 16949 | Kayıtların saklanması ve 6.1.2.3 acil durum planlarının etkinlik testleri |
Kanıtları kontrol bazlı bir kanıt kütüphanesinde tutmak, aynı test kaydının üç denetimde de kolayca bulunmasını sağlar.
Sık sorulan sorular
Microsoft 365 verisi yedeklenmeli mi?
Microsoft’un saklama ve geri dönüşüm özellikleri her senaryoyu karşılamayabilir. Yasal saklama, yanlışlıkla silme ve fidye yazılımı senaryoları değerlendirilerek karar verilmelidir.
Test ortamımız yok; geri yükleme nasıl test edilir?
İzole bir ağ segmentinde geçici sanal makine, alternatif konuma dosya geri yükleme veya bakım penceresinde kontrollü test seçenekleri değerlendirilebilir.
Başarısız bir test denetimde olumsuz mu görünür?
Hayır; başarısız testin kaydedilmesi, kök nedeninin bulunması ve düzeltilmesi kontrolün çalıştığını gösterir. Olumsuz olan, testin hiç yapılmamasıdır.
Yedekleme politikanızı, test programınızı ve kanıtlarınızı değerlendirmek için Yedekleme ve Geri Yükleme Denetimi hizmetimizi inceleyebilirsiniz. Yedekleme altyapısının kurulumu ve işletimi için Eretek Sistem Destek ekibimizle çalışabilirsiniz.
- Teknoloji
- ISO/IEC 27001 Ek A, TISAX, IATF
- Konu
- Yedekleme kanıtı
- Seviye
- Başlangıç
Denetim ve Kanıt
- Yedekleme Politikası, Geri Yükleme Testleri ve Kanıt YönetimiYedeğin varlığını değil, kurtarılabilirliğini kanıtlayan süreçler oluşturun. Kapsam ve teslimatlar için teklif alın.
- Felaket Kurtarma Planı (DRP) ve Geri Dönüş ProsedürleriSistemlerin geri dönüşünü kişi bağımlılığından çıkaran, test edilebilir bir kurtarma planı kurun. Kapsam ve teslimatlar için teklif alın.
- IATF 16949 BT Gereklilikleri ve Denetim HazırlığıOtomotiv kalite yönetim sistemindeki BT bağımlılıklarını, siber olay sürekliliğini ve üretim sistemlerini denetime hazırlayın.