İzole Kurtarma Ortamı (Clean Room) Nasıl Tasarlanır?

Fidye saldırısından sonra yedekten dönen bir sunucuyu doğrudan üretim ağına bağlarsanız, saldırganın bıraktığı arka kapıyı da geri getirebilirsiniz. Hâlâ açık duran erişimini de. İzole kurtarma ortamı (clean room), geri yüklenen sistemlerin üretimden ayrı bir ağda, ayrı kimliklerle açılıp incelendiği ve temiz olduğu doğrulandıktan sonra kontrollü şekilde üretime alındığı ortamdır. Aşağıda bu ortamın ağ, kimlik, araç ve kapasite tasarımını ve içinde yapılacak doğrulama sırasını anlatıyoruz.

Neden doğrudan üretime geri yüklenmez

Fidye olayında şifreleme son perdedir. Öncesinde saldırgan ağa girmiş, yetki yükseltmiş, kalıcılık kurmuş ve yedekleri hedef almıştır. Bu da geri yüklemeyi üç açıdan riskli yapar:

• Kalıcılık mekanizması yedekte olabilir: Saldırganın kurduğu servis, zamanlanmış görev veya web kabuğu, şifrelemeden haftalar önce alınmış yedeklerde de durabilir.
• Saldırgan hâlâ ortamda olabilir: Ele geçirilmiş hesaplar, VPN erişimi veya komuta kontrol bağlantısı kapatılmadıysa geri yüklenen sistem anında yeniden hedef olur.
• İlk erişim açığı kapanmamış olabilir: Saldırının başladığı zafiyet yamanmadan dönen sistem aynı yoldan yeniden ele geçirilir.

İzole ortam, bu üç belirsizliği üretimi riske atmadan çözmek için bir ara duraktır. Hangi yedeğin kullanılacağı ayrı bir karar; onu temiz kurtarma noktası seçimi yazısında ele alıyoruz. Burada konu, o yedeğin güvenle açılacağı yer.

İzole ortamın bileşenleri

Olay anında ortamı sıfırdan kurmaya kalkmak kurtarmayı günlerce uzatır. O gece kimse kablo çekmek istemez. Bu yüzden kurumsal siber güvenlik planında bileşenlerin önceden hazır, belgelenmiş ve test edilmiş olması gerekir.

Bileşen	Amaç	Tasarım notu
Hesaplama kaynağı	Geri yüklenen sistemleri çalıştırmak	Üretimden ayrı yönetilen host veya bulut aboneliği
Depolama	Geri yükleme ve ani başlatma	Ani başlatma için yedek deposunun okuma hızı test edilmeli
Ağ	Sistemleri birbirine ve araçlara bağlamak	Üretime yönlendirme yok; çıkış varsayılan olarak kapalı
Kimlik	Ortamı yönetmek	Üretim AD’sinden bağımsız yerel veya ayrı hesaplar, MFA
Altyapı servisleri	DNS, NTP, güncelleme deposu	Ortamın içinde, üretimden bağımsız
Araç seti	İnceleme ve tarama	EDR, tarayıcılar, adli araçlar; çevrimdışı imzalarla güncel
Atlama noktası	Ekibin ortama erişimi	Temiz iş istasyonu; üretim domain’ine üye değil

En hassas bileşen kimliktir. İzole ortamı üretim Active Directory’siyle yönetmek, ele geçirilmiş kimlikleri bu ortama da taşımak demektir. Ortamın kendi yönetim hesapları, MFA’sı ve parola kasası olmalı. Aynı mantık yedek altyapısı için de geçerli; ayrıntılar yedek altyapısında kimlik izolasyonu yazısında.

Ağ izolasyonu ve kontrollü çıkış

İzole ortamın ağını üç bölge halinde kurmak işi sadeleştirir:

1. Karantina bölgesi: Geri yüklenen sistemlerin ilk açıldığı yer. Sistemler birbirleriyle ve araç sunucularıyla konuşur; dışarıya hiçbir çıkış yoktur.
2. Araç bölgesi: Tarama, EDR yönetim sunucusu, log toplayıcı ve atlama noktası. Karantinaya erişebilir; karantina bu bölgeye yalnızca tanımlı portlardan ulaşır.
3. Doğrulanmış bölge: İncelemeyi geçen sistemlerin uygulama testi için taşındığı yer. Gerekiyorsa sınırlı ve kayıtlı bir çıkışı olabilir.

İnternete çıkış gerekiyorsa (güvenlik yamaları veya EDR imza güncellemesi için), izin listesi tabanlı bir proxy veya güvenlik duvarı üzerinden, yalnızca belirli hedeflere ve tüm trafik kayıt altında olacak şekilde açın. Karantinadaki sistemlerin DNS sorgularını kaydetmek, hâlâ komuta kontrol sunucusunu arayan bir zararlıyı yakalamanın en ucuz yoludur. Ortam içindeki DNS sunucusunu, bilinmeyen alan adlarına gelen sorguları çözmeden kaydedecek şekilde yapılandırabilirsiniz. Konsolda ilk bakılacak yer çoğu zaman bu loglardır.

Geri yüklenen sistemler üretimdekiyle aynı IP adreslerini ve makine adlarını taşır. Bu yüzden izole ortamla üretim arasında yönlendirme olmaması yalnızca güvenlik değil, adres çakışmasını önlemek için de şarttır. İçeriden erişim gerekiyorsa adres dönüşümü kullanılır; Veeam’in sanal laboratuvarı (virtual lab) bu sorunu proxy cihazı ve maskeleme adresleriyle çözer.

Şirket içi, bulut ve hibrit seçenekler

Seçenek	Güçlü yanı	Dikkat edilecek nokta
Şirket içi ayrı hostlar	Yedek deposuna yakın; hızlı geri yükleme ve ani başlatma	Atıl donanım maliyeti; üretimden gerçekten ayrı yönetilmeli
Bulut aboneliği	Kullanıldığı kadar ödeme; üretimden fiziksel ayrım	Veri aktarım süresi, çıkış maliyeti, ayrı hesap ve kimlik zorunlu
Hibrit	Kimlik ve kritik çekirdek yerelde, ölçek bulutta	İki ortamın birlikte tatbikatı gerekir; karmaşıklık artar

Şirket içi seçenekte sahada en sık gördüğümüz hata, üretim kümesinden birkaç hostu ayırıp aynı vCenter veya aynı Hyper-V yönetim altyapısıyla yönetmektir. Üretim yönetim düzlemi düştüyse izole ortam da düşmüştür. Ayrı hostlar ayrı yönetim arayüzüyle, ayrı kimlikle ve mümkünse ayrı ağ donanımıyla kurulmalı. Atıl kapasite maliyeti kabul edilemiyorsa bu hostlar test veya geliştirme için kullanılabilir; ama olay anında dakikalar içinde boşaltılabilecek şekilde planlanmalı.

Bulut seçeneğinde kurtarma süresini, yedeklerin buluta önceden kopyalanmış olup olmadığı belirler. Yalnızca şirket içinde duran yedekler olay anında buluta yüklenecekse aktarım süresi doğrudan bant genişliğine bağlıdır. Bu süre tatbikatta ölçülmeden RTO taahhüdü vermeyin. Ölçülmemiş RTO, tahmindir.

Ortamda doğrulama adımları

Geri yüklenen her sistem aşağıdaki sırayla incelenir. Kritik sistemlerde adımların hepsi, düşük öncelikli sistemlerde risk temelli kısaltılmış hali uygulanabilir.

1. Ağsız ilk açılış: Sistem önce ağ kartı bağlantısız açılır, açılış ve servis durumları kontrol edilir.
2. Zararlı taraması: Güncel imzalı EDR veya antivirüsle tam tarama yapılır; olaydan çıkarılan IOC listesiyle (dosya hash değerleri, dosya adları, alan adları) arama yapılır.
3. Kalıcılık kontrolü: Servisler, zamanlanmış görevler, otomatik başlatma kayıt defteri anahtarları, WMI olay abonelikleri, başlangıç klasörleri, yerel yönetici grubu üyeleri ve Linux’ta cron ile systemd birimleri incelenir.
4. Hesap ve yetki kontrolü: Olay zaman çizelgesinde oluşturulmuş veya yetkisi değiştirilmiş hesaplar belirlenir.
5. Zafiyet kapatma: İlk erişimde kullanılan açık ve kritik güvenlik güncellemeleri uygulanır.
6. Kimlik bilgisi yenileme: Sistemdeki servis hesapları, yerel yönetici parolaları ve uygulama sırları değiştirilir.
7. Uygulama testi: İş birimi temsilcisiyle birlikte uygulamanın işlevsel olarak çalıştığı doğrulanır.
8. Kayıt: Kullanılan kurtarma noktası, yapılan kontroller ve sonuçları sisteme özel bir kayıtta tutulur.

Windows’ta kalıcılık kontrolünün bir kısmını PowerShell ile hızlıca toplayabilirsiniz. Aşağıdaki komutlar bir başlangıç listesi üretir; çıktıyı bilinen iyi bir temel yapılandırmayla karşılaştırın, tek başına okumak yanıltır:

Get-ScheduledTask | Where-Object State -ne 'Disabled' |
  Select-Object TaskPath, TaskName, @{n='Action';e={$_.Actions.Execute}}

Get-CimInstance Win32_Service |
  Select-Object Name, StartMode, StartName, PathName

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run',
                 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce'

Get-CimInstance -Namespace root\subscription -ClassName __EventConsumer
Get-CimInstance -Namespace root\subscription -ClassName __FilterToConsumerBinding

# Yerel Administrators grubu (SID ile; Türkçe sistemde grup adı farklıdır)
Get-LocalGroupMember -SID 'S-1-5-32-544'

Temiz sistemlerin üretime alınması

İzole ortamda doğrulanan sistemi üretime almak, üretim ağının da temizlendiği varsayımına dayanır. Bu varsayım doğrulanmadan yapılan taşıma, izole ortamın verdiği bütün güvenceyi boşa çıkarır. Üretime almadan önce şu koşulları sağlayın:

• Saldırganın bilinen erişim yolları (VPN hesapları, uzak erişim araçları, açık servisler) kapatıldı.
• Ayrıcalıklı hesapların parolaları değiştirildi, KRBTGT parolası replikasyon tamamlandıktan sonra iki kez sıfırlandı ve kimlik altyapısı yeniden güvenilir hale getirildi.
• Hedef ağ segmenti yeni kurallarla oluşturuldu; ele geçirilmiş sistemler bu segmente erişemiyor.
• EDR ve merkezi log toplama, taşınan sistemlerde ilk andan itibaren açık.
• Taşınan sistemler için artırılmış izleme süresi ve sorumlu kişi belli.

Taşıma dalgalar halinde yapılır: önce kimlik ve altyapı servisleri, sonra bunlara bağımlı uygulamalar. Her dalgadan sonra kısa bir gözlem süresi bırakmak, yeniden enfeksiyon belirtisini erken yakalatır. İzole ortamı olay kapanana kadar sökmeyin. Yeniden enfeksiyon olursa aynı süreç baştan işletilecek.

İzole ortamın tasarımı ancak tatbikatla doğrulanır; kapasite, aktarım süresi ve doğrulama adımlarının gerçek süreleri ölçülmeden RTO tahminleri varsayım olarak kalır. Ortamın tasarımı ve tatbikatı siber olay müdahale hazırlığı ve tatbikat, yedek tarafındaki bileşenler ise yedekleme güvenliği ve fidye yazılımına hazırlık kapsamında birlikte ele alınabilir. Kurtarma sürecinin genel çerçevesi için birincil kaynak NIST’in SP 800-184 siber olaydan kurtarma rehberi.

Sık sorulan sorular

İzole kurtarma ortamı ile SureBackup sanal laboratuvarı aynı şey mi?

Mantıkları benzer, amaçları farklı. Sanal laboratuvar, yedeklerin açılabildiğini rutin olarak test etmek için yedek sunucusunun yönettiği izole bir ağ kurar. Siber olay sonrasındaki izole kurtarma ortamı ise yedek altyapısının da ele geçirilmiş olabileceği varsayımıyla ayrı kimlik, ayrı araçlar ve kontrollü çıkışla tasarlanır. Sanal laboratuvar bu ortamın bir bileşeni olarak kullanılabilir.

İzole ortam için ne kadar kapasite ayırmak gerekir?

Tüm üretimi değil, ilk dalgada ayağa kalkacak sistemleri taşıyacak kadar. Genellikle kimlik altyapısı, DNS, yönetim araçları ve en kritik birkaç iş uygulaması bu kapsama girer. İşlemci, bellek ve depolama ihtiyacını bu sistemlerin envanterinden hesaplayın; ani başlatma kullanılacaksa yedek deposunun okuma performansını ayrıca test edin.

Bulutta izole kurtarma ortamı kurmak güvenli mi?

Doğru tasarlanırsa evet. Ortam üretim bulut aboneliğinden ve üretim kimlik sağlayıcısından ayrı bir hesapta veya abonelikte kurulmalı, ağ bağlantısı varsayılan olarak kapalı olmalı, yönetim erişimi ayrı ve MFA korumalı hesaplarla yapılmalı. Veri aktarım süresini ve çıkış maliyetini tatbikatta ölçün.

Temiz olduğu doğrulanan sistem doğrudan üretim ağına bağlanabilir mi?

Üretim ağı temizlenmeden bağlanmamalı. Aksi halde hâlâ aktif bir saldırgan ya da kalıcılık mekanizması geri yüklenen sistemi yeniden ele geçirebilir. Önce temiz bir ağ segmenti ve yeni kimlik bilgileri hazırlanır, sistemler artırılmış izleme altında dalgalar halinde bu segmente taşınır.