Management Platformum Zaten Snapshot Alıyor. Yeterli mi? | BackBox #02

Firewall management platformunuz düzenli snapshot alıyor. Configuration history'niz var. Belki günlük export da yapıyorsunuz. Üstelik yıllardır ciddi bir problem yaşamadınız.

O zaman neden ayrıca bir backup ve recovery çözümüne ihtiyaç duyasınız?

Belki de ihtiyacınız yok.

Ama bunu anlamanın yolu kaç tane snapshot'ınız olduğuna bakmak değil. Şu soruya cevap vermek:

Yarın kritik bir cihazı kaybederseniz, hangi noktaya, ne kadar sürede ve ne kadar güvenle geri dönebilirsiniz?

Çünkü snapshot sahibi olmak ile recovery'ye hazır olmak aynı şey değildir.

Management Platformu Kendi Dünyasını Çok İyi Yönetebilir

Üreticilerin kendi management platformları doğal olarak kendi ekosistemleri için çok değerli yetenekler sunuyor.

Configuration history tutulabilir. Snapshot alınabilir. Değişiklikler izlenebilir. Belirli durumlarda eski configuration'a dönülebilir. Buraya kadar sorun yok.

Ancak gerçek kurumsal network'ler çoğu zaman tek bir üreticinin dünyasından oluşmuyor.

Firewall başka bir üreticiden. Core network başka. Branch cihazları başka. Load balancer başka. Management sistemleri başka.

Farklı modeller, software version'ları, cluster yapıları ve bağımlılıklar aynı operasyonun içerisinde birlikte çalışıyor.

Ve bir kesinti yaşandığında iş birimi size:

"Hangi vendor'da problem oldu?"

diye sormuyor.

"Servis ne zaman geri gelecek?"

diye soruyor.

Her Cihazın Backup'ı Var. Peki Operasyonun Tek Bir Recovery Planı Var mı?

Asıl problem burada başlıyor. Bir cihaz kendi management platformunda korunuyor. Başka bir cihaz için script çalışıyor. Bir diğerinin configuration'ı scheduler ile export ediliyor. Bazı cihazların backup'ı merkezi storage'da. Bazıları vendor management platformunda. Bazıları için ise yıllar önce hazırlanmış bir prosedür var. Tek tek baktığınızda hepsinin bir backup yöntemi olabilir.

Ama kriz anında ihtiyacınız olan şey backup yöntemlerinin listesi değildir.

İhtiyacınız olan: hangi cihazın son başarılı configuration'ının nerede olduğunu, hangi recovery point'in kullanılacağını, hangi sırayla geri dönüleceğini ve bunun ne kadar süreceğini bilmektir.

On farklı backup yöntemi, tek bir recovery stratejisi anlamına gelmez.

Simple Device Diye Bir Şey Kriz Anında Çok Hızlı Complex Hale Gelebilir

Bazı cihazları kritik, bazılarını daha basit olarak sınıflandırmak doğal.

Ama basit görünen bir cihazın üzerinde çalışan servis kritikse, cihazın fiyatının veya configuration'ının büyüklüğünün çok fazla önemi kalmaz.

Bir branch firewall. Bir access switch. Bir edge router. Configuration birkaç yüz satır olabilir.

Ama o cihaz çalışmadığında bir lokasyonun tamamı erişimini kaybediyorsa artık problem "simple device" problemi değildir.

Aynı şekilde datacenter tarafındaki complex bir firewall cluster'ında yanlış recovery point'e dönmek çok daha büyük sonuçlar doğurabilir.

Bu nedenle operasyonel güvence yalnızca en büyük cihazların değil, servis sürekliliğini etkileyebilecek tüm kritik cihazların doğru noktadan geri döndürülebilmesini kapsamalıdır.

Peki Doğru Nokta Hangisi?

İşte snapshot yaklaşımında gözden kaçabilen başka bir konu. Gece 02:00. Snapshot alındı. 09:45. Network üzerinde planlı bir değişiklik yapıldı. 11:30. Başka bir ekip yeni bir configuration ekledi. 14:10. Kritik bir security fix uygulandı. 14:17. Beklenmeyen bir servis problemi başladı. Şimdi geri dönmeniz gerekiyor.

Nereye?

Gece 02:00'ye mi? 09:45 öncesine mi? 14:10'daki security fix öncesine mi? Yoksa yalnızca son yapılan değişikliği mi geri almalısınız? Backup'ın güncel olması önemlidir. Ama bazen bundan daha önemlisi:

kritik değişiklik yapılmadan hemen önce doğru recovery point'in elinizde olmasıdır.

Çünkü bir sorun çıktığında dün geceye değil,

birkaç dakika öncesine dönmek isteyebilirsiniz.

İşte Automation'ın Değeri Burada Değişiyor

Bir scheduler belirli saatte backup alabilir. Bir script configuration export edebilir. Bir management platformu snapshot oluşturabilir.

Ancak gerçek network resilience bundan daha büyük bir operasyon gerektirir.

Kritik bir işlemden önce backup alınması. Backup'ın başarılı olduğunun doğrulanması. Doğru recovery point'in korunması. Configuration değişikliklerinin takip edilmesi. Farklı vendor ve cihazların aynı operasyonel standart altında yönetilmesi. Ve problem oluştuğunda recovery sürecinin mümkün olduğunca hızlı başlatılabilmesi.

BackBox'ın farkı yalnızca backup'ı otomatikleştirmesi değildir.

Asıl değer, backup ve recovery operasyonunu cihazların kendi dünyasından çıkarıp network operasyonunun tamamına yayılan merkezi bir resilience yaklaşımına dönüştürmesidir.

Çünkü Bir Gün Çok Hızlı Hareket Etmeniz Gerekecek

Bu konu bugün daha da önemli. Network ve security ürünlerinde yeni vulnerability'ler ortaya çıkıyor. Vendor'lar fix ve yeni software version'ları yayınlıyor. Kritik bir açık söz konusu olduğunda eskisi gibi haftalarca beklemek her zaman mümkün olmayabiliyor.

Bazen çok hızlı upgrade yapmanız gerekiyor. Ve hız arttıkça başka bir soru ortaya çıkıyor:

Ya geçtiğiniz fix, bilmediğiniz başka kritik bir fonksiyonu etkilerse?

İşte o anda backup artık gece çalışan rutin bir operasyon değildir.

Yapacağınız değişikliğin sigortasıdır.

Upgrade öncesindeki doğru configuration'a güvenle ve hızlı şekilde dönebileceğinizi bilmek, teknik ekibin kritik değişiklikleri çok daha kontrollü gerçekleştirmesini sağlar.

Çünkü risk yalnızca değişikliğin başarısız olması değildir.

Başarısız olduğunda ne kadar süre içerisinde geri dönebileceğinizdir.

Backup Maliyeti Değil, Downtime Maliyeti

BackBox gibi bir çözüm değerlendirilirken yalnızca:

"Bunu mevcut araçlarımızla yapabilir miyiz?"

diye sorulduğunda cevap çoğu zaman evettir. Script yazabilirsiniz. Scheduler oluşturabilirsiniz. Snapshot alabilirsiniz. Prosedür hazırlayabilirsiniz. Asıl soru başka:

"Bir şey ters gittiğinde bütün bunlarla ne kadar hızlı geri dönebiliriz?"

Bir saatlik kritik servis kesintisinin operasyonel maliyetini düşünün. Mühendislerin harcadığı zamanı. İş birimlerinin etkilenmesini. Müşteri tarafındaki kesintiyi. Yönetilen escalation sürecini. Ve bazen kurumun itibarına kadar uzanan etkileri.

Böyle bir durumda recovery süresinden kazanılan dakikalar bile hesaplamayı tamamen değiştirebilir.

Bu nedenle backup ve recovery altyapısı çoğu gün sessizdir. Ama gerçekten ihtiyaç duyduğunuz bir anda kendini çok hızlı amorti edebilir.

Şimdi Snapshot Sayınıza Değil, Recovery Sürenize Bakın

Kendi altyapınız için şu soruları sorun:

Tüm kritik network ve security cihazlarımızın güncel recovery point'i var mı?

Bunların gerçekten kullanılabilir olduğunu biliyor muyuz?

Kritik değişikliklerden hemen önce otomatik recovery point oluşturabiliyor muyuz?

Farklı vendor'larda aynı operasyonel standardı uygulayabiliyor muyuz?

Ve şu anda kritik bir cihazda problem yaşasak, kaç dakika içerisinde geri dönebiliriz?

İlk dört soruya "evet" demek güzel. Ama asıl önemli cevap sonuncusu. Çünkü operasyonun sigortası kaç tane snapshot tuttuğunuz değildir.

Ne kadar hızlı geri dönebildiğinizdir.

Zero Second olarak BackBox ile mevcut backup ve recovery mimarinizi birlikte değerlendirerek, farklı network ve security platformlarınızda bugün gerçekten hangi noktaya ve ne kadar sürede geri dönebileceğinizi ortaya çıkarabiliriz.

Belki mevcut yapınız zaten yeterlidir.

Ama bunu bir kesinti sırasında öğrenmek yerine, önceden bilmek çok daha ucuzdur.

Snapshot'ınız Var.

Peki Recovery Planınız Var mı?

Zero Second | BackBox — Network Cyber Resilience | BackBox Series #02 — Prepared by Zero Second