Bulut yedekte kopyanın durması tek başına bir kontrol değildir. Asıl soru kimin o kopyayı görebileceği, kimin geri yükleyebileceği ve kimin silebileceğidir. Saklama süresi bu üç yetkiden ayrı yazılırsa politika kâğıtta kalır. Üretim yöneticisi yedek deposunu da yönetiyorsa, tek bir ele geçirilmiş hesap hem sistemi hem kopyayı etkiler.
Bu yazı yedekleme bulutu ürün sayfasını destekler. Paket satmaz, saklama, sakınçalı veri ve erişim rollerini nasıl bağlayacağınızı anlatır. Hesap ve hata alanı ayrımını 3-2-1 yedekleme kuralı ve bulut katmanı yazısında ele aldık.
Hızlı Özet
Yedek, üretimdeki verinin bir kopyasıdır. Kaynakta sakınçalı olan kayıt yedekte de sakınçalıdır. Bu yüzden yedek deposu üretim dizininden daha gevşek yönetilmemelidir.
Saklama süresi iş ihtiyacına ve yazılı politikaya göre belirlenir. Süreyi ürünün varsayılan ayarına bırakmak, hem fazla kopya hem de erken silme riski doğurur.
Geri yükleme ve silme yetkisi üretim yöneticisinden ayrı tutulur. Kim hangi kopyayı ne zaman açtı, bu kayıt tutulur ve gözden geçirilir.
Leon-X altyapı sahibi değildir. Saklama ve erişim politikasını iş birimleriyle birlikte yazar, yedekleme düzenini buna göre kurgular.
İçindekiler
- Yedek Neden Ayrı Bir Erişim Alanıdır
- Saklama Süresini Kim Belirler
- Sakınçalı Veri Yedekte Kaybolmaz
- Geri Yükleme ve Silme Rolleri
- İzleme ve Gözden Geçirme
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, yan yana çalışan iki yazılım uzmanı.
Yedek Neden Ayrı Bir Erişim Alanıdır
Üretim sunucusuna giren her kişi yedek deposuna da girmemelidir. Yedek, geçmiş halin tamamını taşır. Silinmiş bir dosya, eski bir müşteri listesi veya kaldırılmış bir yetki kaydı yedekte duruyor olabilir.
Bu yüzden yedek hesabı üretim hesabından ayrılır. Aynı yönetici kimliğiyle hem sunucuyu hem yedeği silmek, tek bir olayın iki kopyayı birden etkilemesine yol açar. Hizmet olarak yedeklemede bu ayrımın kimin sorumluluğunda olduğunu BaaS kapsam ve sınırlar yazısında anlattık.
Ayrım yalnızca hesap adı değildir. Yedek deposunun yönetim paneli, üretim yönetim panelinden ayrı tutulur. Şifreleme anahtarı sağlayıcıda değil, kurumun kontrolünde kalır. Anahtar üretim yöneticileriyle paylaşılmaz.
Saklama Süresini Kim Belirler
Saklama süresi teknik bir varsayılan değildir. İş birimi, verinin ne kadar süre geri getirilebilir kalacağını söyler. Muhasebe kayıtları ile geçici proje dosyaları aynı süreyi istemez.
Süre kısa tutulursa eski bir hal geri getirilemez. Süre uzun tutulursa yedek deposu şişer ve sakınçalı veri gereğinden uzun kalır. İkisi de yazılı bir karardır. Karar yedekleme yazılımının varsayılan değerine bırakılmamalıdır.
Sınıf bazında süre yazmak işi kolaylaştırır. Sürekli değişen iş verisi, paylaşılan belgeler ve arşiv ayrı süre alır. Hedef süre ile yedek sıklığının nasıl bağlanacağını offsite kopya ve veri kaybı hedefi yazısında ele aldık.
Saklama süresi dolan kopyanın silinmesi de bir kontroldür. Silme otomatik çalışıyorsa kimin onayladığı ve hangi sınıfa uygulandığı belgelenir. Silme durdurulacak bir durum varsa, örneğin bir inceleme, bu durum politikada ayrıca yazılır. İnceleme bitince süre kaldığı yerden devam eder.
Sakınçalı Veri Yedekte Kaybolmaz
Kaynak sistemde kimlik, sağlık, finans veya müşteri kaydı varsa yedekte de vardır. Dosyayı üretimden silmek, yedekteki kopyayı silmez. Bu yüzden yedek deposu üretim dizininden daha açık tutulamaz.
Yedekleme yazılımı çoğu zaman kaynak klasörü olduğu gibi alır. Ayrı bir gizlilik katmanı eklemez. Bu yüzden kaynakta sınıflandırılmamış veri, yedekte de sınıflandırılmamış kalır. Önce kaynak envanteri, sonra yedek kapsamı gelir.
Şifreleme aktarımda ve depoda açık olmalıdır. Anahtar kurumda kalır. Anahtar yedek deposuyla aynı yerde duruyorsa şifreleme tek başına yetmez.
Yedekten tek dosya çıkarma özelliği varsa bu da bir erişim yoludur. İmajın içinden dosya almak, sunucuyu ayağa kaldırmadan sakınçalı kayda ulaşmak demektir. Bu özelliği kimlerin kullanacağı ayrıca sınırlanır. Depolama türünün yedek ve arşiv işindeki yerini object storage nedir yazısında anlattık.
Geri Yükleme ve Silme Rolleri
Üç ayrı rol çoğu ortamda yeter.
Yedek operatörü yedek işlerini izler, başarısız işleri düzeltir, raporu okur. Geri yükleme yapmaz, kopya silmez.
Geri yükleme yetkilisi belirli bir sınıf için geri yükleme açar. Bu kişi üretim yöneticisi olmak zorunda değildir. Talebi, kapsamı ve sonucu kaydeder.
Saklama yöneticisi süreleri ve silme işlemini değiştirir. Bu yetki dar tutulur. Üretim krizinde aceleyle süre kısaltmak, ihtiyacınız olan kopyayı yok eder.
Taleple yetki ayrılır. Bir kullanıcı “şu dosyayı dünkü haline getir” dediğinde operatör talebi alır, geri yükleme yetkilisi işi yapar, sonuç talep sahibine döner. Yetkili kendi isteğiyle geniş bir geri yükleme açmaz.
Farklı donanıma veya farklı sanal ortama geri yükleme, üretimle aynı yetki modelini taşımaz. Test ortamına alınan kopya da sakınçalıdır. Test bitince kopya silinir.
İzleme ve Gözden Geçirme
Kontrol, kayıt tutulunca işler. Hangi hesap hangi kopyayı ne zaman açtı, hangi dosya nereye döndü, hangi süre değişti, bunlar tutulur.
Kayıt yalnızca yedekleme yazılımının günlük dosyası değildir. Talebin kimden geldiği, hangi onayın verildiği ve işin kimin tarafından bittiği aynı yerde durmalıdır. Aksi halde yazılım günlüğü teknik bir iz, iş kararı ise sohbet geçmişinde kalır.
Gözden geçirme periyodik yapılır. Kullanılmayan yetkiler kapatılır. Ayrılan kişilerin yedek hesabı üretim hesabıyla birlikte kapatılır. ISO 27001 çerçevesinde bu tür kayıtların politikaya nasıl bağlanacağını ISO 27001 yedekleme politikaları yazısında ele aldık.
Geri yükleme tatbikatı da bir erişim denemesidir. Tatbikatta kimlerin iş yaptığı, hangi kopyanın açıldığı ve kopyanın sonra silinip silinmediği rapora yazılır.
Yaygın Hatalar
Üretim yöneticisine yedek deposunun tam yetkisini vermek en sık görülen hatadır.
Saklama süresini ürün varsayılanına bırakmak, bazı sınıfları erken siler, bazılarını gereksiz uzun tutar.
Kaynakta sınıflandırılmamış veriyi yedekte ayrıca korumaya çalışmak işe yaramaz. Sınıflandırma kaynakta başlar.
Geri yükleme kaydı tutmamak, kimin hangi müşteri listesini çıkardığını sonradan göstermeyi imkânsız kılar.
Ayrılan çalışanın yedek hesabını açık bırakmak, üretim hesabını kapatmış olmayı boşa çıkarır.
Kontrol Listesi
- Yedek hesabı üretim hesabından ayrı.
- Şifreleme anahtarı kurumda ve üretim yöneticilerinden ayrı duruyor.
- Veri sınıfları ve her sınıfın saklama süresi yazılı.
- Süre dolunca silme kimin onayladığı belgelendi.
- Sakınçalı veri yedek kapsamında ayrıca işaretlendi.
- Geri yükleme, izleme ve silme rolleri birbirinden ayrıldı.
- Yedekten tek dosya çıkarma yetkisi sınırlandı.
- Geri yükleme ve süre değişimi kaydı tutuluyor ve gözden geçiriliyor.
- İhtiyaçlar doğrultusunda yedekleme bulutu çözümü incelendi.
Leon-X ile Sonraki Adım
Leon-X yedek deposundaki rolleri, saklama sürelerini ve sakınçalı veri kapsamını sizinle birlikte çıkarır. Üretim yetkisinden ayrı bir erişim modeli yazar, kayıt ve gözden geçirmeyi politika haline getirir. Leon-X altyapı sahibi değildir, doğru bulut teknolojilerini kurumunuz için entegre eder. Başlamak için iletişime geçin.
Sık Sorulan Sorular
Üretim yöneticisi yedeği de yönetebilir mi?
Yönetmemelidir. Aynı kimlik hem sistemi hem kopyayı etkiler. Yedek için ayrı hesap ve ayrı panel kullanılır.
Saklama süresini yedekleme yazılımı kendisi seçer mi?
Seçmemelidir. Süreyi iş birimi ve yazılı politika belirler. Yazılım bu süreyi uygular.
Üretimden sildiğim kayıt yedekten de silinir mi?
Kendiliğinden silinmez. Yedek, silinmeden önceki hali taşır. Sakınçalı kaydı yedekten çıkarmak ayrı bir işlemdir ve yetki ister.
Geri yükleme kaydı neden gerekir?
Kayıt, kimin hangi kopyayı açtığını sonradan göstermenin tek yoludur. Talep, onay ve sonuç aynı yerde durmazsa kontrol işlemez.
Sonuç
Bulut yedekte kontrol, kopyanın varlığından çok kimin o kopyaya dokunduğuyla ölçülür. Saklama süresi, sakınçalı veri ve erişim rolleri aynı politikada durmalıdır. Üretim yetkisini yedek deposuna taşımak bu üçünü birden bozar. Ortamınıza uygun düzeni görmek için yedekleme bulutu sayfasına göz atabilirsiniz.
