Yedek Altyapısında Kimlik İzolasyonu: Yedek Sunucusunu Domain’den Ayırmak

Fidye saldırısında yedeklerin silinmesi çoğu zaman karmaşık bir istismar gerektirmez. Saldırgan domain admin olur, domain’e üye yedek sunucusunda oturum açar, konsoldan işleri ve kurtarma noktalarını siler. Beş dakikalık iş. Bu yazı yedek altyapısını üretim kimliklerinden ayırmanın yollarını anlatıyor: workgroup, ayrı yönetim forest’ı ve yerel hesap modelleri, konsol MFA’sı, rol ayrımı, hipervizör ve depolama kimlik bilgilerinin ayrılması ve yönetim ağı tasarımı. Hedef okur, yedek mimarisinden ve Active Directory’den sorumlu sistem ve güvenlik ekipleridir.

Yedek altyapısı neden hedef alınır

Saldırgan ödeme almak ister; kurumun yedekten dönebilmesi bu planı boşa çıkarır. Bu yüzden şifreleme aşamasından önce yedek altyapısı keşfedilir ve etkisiz hale getirilir. Tipik hareketler bellidir: yedek işlerini devre dışı bırakmak, saklama süresini kısaltıp eski kurtarma noktalarının temizlenmesini tetiklemek, depoları konsoldan kaldırmak, şifreleme parolasını değiştirmek ve yedek sunucusunda saklanan kimlik bilgilerini çalmak. Yedek sunucusu hipervizörlere, depolamaya ve sanal makinelerin içine erişen kimlik bilgilerini de barındırır. Yani yalnızca hedef değil, yanal hareket için sıçrama tahtasıdır.

Kimlik tasarımı iki soruya cevap vermeli: Üretimi ele geçiren biri yedeklere nasıl ulaşır? Yedek altyapısını ele geçiren biri üretime nasıl ulaşır? Doğru tasarımda iki yol da ayrı kimlik ve ayrı ağ sınırlarından geçmek zorundadır.

Domain üyeliğinin riski

Yedek sunucusu üretim domain’ine üyeyse aşağıdaki gruplar ve mekanizmalar sunucu üzerinde fiilen yöneticidir:

• Domain Admins grubu, sunucu domain’e katıldığında yerel Administrators grubuna otomatik eklenir; Enterprise Admins da forest genelindeki yetkisiyle aynı noktaya ulaşır.
• Sunucunun bulunduğu OU’ya grup ilkesi bağlayabilen herkes, başlangıç betiği veya zamanlanmış görevle kod çalıştırabilir.
• Yazılım dağıtım ve uç nokta yönetim araçlarının servis hesapları sunucuda komut çalıştırabilir.
• Konsol erişimi domain hesabıyla verilmişse, o hesabın parolasını sıfırlayabilen her yönetici konsola da girer.

Domain’e üye bir yedek sunucusu, domain’in en zayıf yönetici hesabı kadar korunur. Active Directory düştüyse yedek sunucusu da düşmüş sayılmalıdır. Sahada en sık gördüğümüz gerekçe “yönetimi kolay olsun” diye yedek sunucusunun domain’e alınmasıdır; o kolaylık saldırgan için de geçerlidir. Active Directory’deki yönetici katmanlama yaklaşımı Active Directory tier modeli yazısında anlatılıyor; bu modelde yedek sunucusu domain denetleyicileriyle aynı, en kritik katmanda yer alır.

Kimlik modelleri: workgroup, ayrı forest, yerel hesap

Yedek altyapısını üretim kimliğinden ayırmanın üç yaygın yolu var. Hangisinin uyduğu altyapının büyüklüğüne ve ekibin yönetim kapasitesine bağlı.

Model	Uygun olduğu ortam	Avantaj	Sınırlama
Workgroup + yerel hesap	Tek yedek sunucusu, az sayıda bileşen	Basit; domain ele geçirilse de doğrudan etkilenmez	Grup ilkesi yok; güncelleme ve hesap yönetimi elle
Ayrı yönetim forest’ı (güven ilişkisi yok)	Çok sayıda proxy, depo ve yönetici	Merkezi hesap, ilke ve denetim; MFA entegrasyonu kolaylaşır	Ek DC’ler, ayrı yama ve izleme süreci gerekir
Üretim domain’i + ayrı OU ve hesaplar	Geçiş dönemi	Kurulumu kolay	Domain admin’e karşı koruma sağlamaz

Ayrı yönetim forest’ı kuruyorsanız üretim forest’ıyla güven ilişkisi kurmayın. Güven ilişkisi şart görünüyorsa yönü, üretimin yönetim forest’ına güvenmesi şeklinde olmalı; tersi, üretimdeki kimliklerin yedek altyapısına erişebilmesi demektir. Yedekleme için genellikle hiçbir güven ilişkisi gerekmez, çünkü yedek yazılımı korunan sistemlere kendi kayıtlı kimlik bilgileriyle bağlanır.

Workgroup modeli disiplin ister. Her yönetici için ayrı yerel hesap açın, ortak “admin” hesabı kullanmayın, yerleşik Administrator hesabının parolasını kasaya kaldırıp günlük kullanımdan çıkarın. Parola, hesap kilitleme ve denetim ilkelerini belgelenmiş bir temel yapılandırmayla uygulayın ve değişiklikleri kayda alın. Grup ilkesi yoksa kayıt sizsiniz.

Yedek konsolunda MFA ve rol ayrımı

Sunucuyu domain’den ayırmak ilk adım; konsolun kendisi de ayrıca korunmalı. Veeam Backup & Replication örneğinden gidersek, sürüm 12 ile konsol kullanıcıları için zaman tabanlı tek kullanımlık parolayla (TOTP) MFA, sürüm 12.1 ile de kritik işlemler için dört göz onayı (four-eyes authorization) geldi. Kullandığınız sürümde bu özelliklerin kapsamını ve sınırlamalarını (örneğin grup hesaplarında MFA desteği) üretici dokümantasyonundan doğrulayın; başka yedek ürünlerinde benzer kontrollerin karşılığını arayın.

Kontrol	Önerilen ayar	Kapattığı risk
Konsol MFA	Tüm kullanıcılar için zorunlu	Çalınan parola ile konsola giriş
Rol ayrımı	Yönetici, operatör, geri yükleme operatörü ayrı	Günlük işlerde tam yetkinin gereksiz kullanımı
Dört göz onayı	Yedek, depo ve kullanıcı silme işlemlerinde açık	Tek hesapla toplu silme
Oturum zaman aşımı	Kısa süre, otomatik kilit	Açık bırakılan konsol oturumu
Yerel yönetici sayısı	En az; adlandırılmış hesaplar	Paylaşılan hesapla izsiz işlem

Rol ayrımında kural basit: günlük işleri izleyen ve yeniden başlatan kişiye tam yönetici rolü verilmez. Geri yükleme taleplerinin çoğu geri yükleme operatörü rolüyle karşılanır. Tam yönetici rolündeki hesap sayısı iki-üç ile sınırlı kalmalı, bu hesaplar günlük oturumda kullanılmamalı. Dört göz onayını açtığınızda onay verecek ikinci yöneticinin her zaman ulaşılabilir olduğundan emin olun. Yoksa acil işlem tıkanır.

Hipervizör ve depolama kimlik bilgilerinin ayrımı

Yedek sunucusu korunan sistemlere bağlanmak için kimlik bilgileri saklar. Bu bilgilerin kapsamı, sunucu düştüğünde saldırganın ne kadar ileri gideceğini belirler.

• vCenter: Domain hesabı yerine vCenter’ın yerel SSO etki alanında (örneğin vsphere.local) ayrı bir hesap açın ve yalnızca yedek ürününün dokümante ettiği ayrıcalıkları içeren özel bir rol atayın. Administrator rolü vermeyin; sahada en sık bulduğumuz yetki fazlası budur.
• Hyper-V: Hostlar üretim domain’ine üyeyse yedekleme hesabı da genellikle domain hesabıdır; bu hesabın yalnızca Hyper-V hostlarında yerel yönetici olmasını ve etkileşimli oturum açma yetkisinin kısıtlanmasını sağlayın. Hostların kendisi en kritik katmanda yönetilmeli.
• Misafir işletim sistemi işleme: Uygulama farkındalıklı yedekleme, sanal makinelerin içinde yönetici yetkisi ister. Sunucu grupları için ayrı hesaplar kullanın; domain denetleyicileri için kullanılan hesap domain düzeyinde yetkili olacağından yalnızca DC’lere tanımlı olduğundan emin olun.
• Depolama dizisi ve nesne depolama: Snapshot entegrasyonu ve nesne depolama için kullanılan hesapların silme yetkisi en aza inmeli; değiştirilemezlik ayarını değiştirebilen yönetici hesapları yedek sunucusunda hiç saklanmamalı.
• Sertleştirilmiş depo: Yedek sunucusunda kalıcı kimlik bilgisi tutulmaz; kurulum ayrıntıları Veeam hardened repository kurulumu yazısında.

Her kimlik bilgisi için şu soruyu yazılı cevaplayın: Bu hesap ele geçirilirse hangi sistemlerde ne yapılabilir? Cevabı “tüm domain” veya “tüm depolama” olan hesaplar en kritik varlıklar listesine girer; rotasyon, izleme ve kasada saklama kurallarına tabi olur. Ayrıcalıklı hesapları kasada saklamak ve oturumları kayda almak için ayrıcalıklı erişim yönetimi (PAM) yaklaşımı kullanılabilir.

Yönetim ağı ve erişim yolu

Kurumsal siber güvenlik tarafında kimlik ayrımı, ağ ayrımı olmadan yarım kalır. Domain’den ayrılmış ama kullanıcı ağından RDP ile erişilen bir yedek sunucusu, çalınan yerel parolayla yine ele geçirilir. Önerdiğimiz yapı:

1. Yedek sunucusu, proxy’ler ve depolar ayrı bir yönetim VLAN’ında veya segmentinde.
2. Bu segmente yönetim erişimi yalnızca ayrıcalıklı erişim iş istasyonlarından veya bu iş için ayrılmış atlama sunucusundan; kullanıcı ağından RDP, SMB ve konsol portlarına erişim engelli.
3. Yedek trafiği için gereken portlar kaynak ve hedef bazında açık; “yönetim ağından her yere izin” kuralı yok.
4. Yedek sunucusunun internete doğrudan çıkışı kapalı; güncelleme ve lisans doğrulaması için gerekli adresler tanımlı.
5. Uzak yönetim kartları ayrı bir bant dışı yönetim ağında.

Atlama sunucusu da üretim domain’ine üyeyse aynı risk arka kapıdan geri gelir. Atlama noktası yönetim forest’ına üye ya da workgroup’ta olmalı ve MFA ile korunmalı. Ayrıcalıklı erişim iş istasyonu kavramı için birincil kaynak Microsoft’un ayrıcalıklı erişim stratejisi dokümantasyonu.

Uygulama kontrol listesi

Liste, mevcut bir ortamı izole yapıya geçirirken sırayla ilerlemek için hazırlandı. Geçişte yedek işleri kesilmesin diye her adımdan sonra bir test işi çalıştırın. Geçiş sırasında atlanan bir yedek gecesi, en kötü gecede karşınıza çıkar.

• Yedek sunucusu, proxy’ler ve depoların hangi domain hesaplarına ve gruplara bağlı olduğu envanteri çıkarıldı.
• Yedek yapılandırmasının yedeği alındı; şifreleme parolası domain dışında, kasada.
• Yeni kimlik modeli seçildi (workgroup veya ayrı yönetim forest’ı); üretimle güven ilişkisi yok.
• Konsol kullanıcıları yerel veya yönetim forest’ı hesaplarına taşındı; domain hesaplarının konsol erişimi kaldırıldı.
• Konsol MFA’sı tüm kullanıcılar için açık; tam yönetici sayısı en az düzeyde.
• Silme ve depo değişikliği işlemleri için dört göz onayı etkin.
• vCenter, Hyper-V, misafir işletim sistemi ve depolama hesapları gözden geçirildi; her biri en az ayrıcalıkla sınırlandı.
• Yedek bileşenleri yönetim segmentinde; kullanıcı ağından erişim engelli.
• Yedek sunucusundaki olaylar (oturum açma, iş silme, ayar değişikliği) merkezi log sistemine akıyor.
• En az bir değiştirilemez veya çevrimdışı kopya, yedek konsolundan bağımsız kimlikle korunuyor.

İzolasyon saldırıyı zorlaştırır, tespitin yerini tutmaz. Konsoldaki şüpheli işlemlerin nasıl izleneceği yedek altyapısına yönelik saldırı belirtileri yazısında. Kimlik ayrımını mevcut mimarinize uyarlamak, yedekleme güvenliği ve fidye yazılımına hazırlık çalışmamızın ana başlıklarından biridir.

Sık sorulan sorular

Yedek sunucusu domain’e üye olmazsa yedekleme çalışmaz mı?

Çalışır. Yedek yazılımı hipervizöre, depolamaya ve sanal makinelerin içine kendi kayıtlı kimlik bilgileriyle bağlanır; sunucunun domain üyesi olması gerekmez. Değişen şey yönetim yöntemidir: güncelleme, yerel hesaplar ve güvenlik ayarları grup ilkesi yerine ayrı bir süreçle yönetilir.

Ayrı yönetim forest’ı ile workgroup arasında nasıl seçim yapmalıyım?

Yedek altyapısı bir-iki sunucudan ibaretse workgroup ve yerel hesaplar basit ve yönetilebilirdir. Çok sayıda proxy, depo ve yönetici olan ortamlarda merkezi yönetim, MFA ve denetim kaydı için ayrı yönetim forest’ı daha sürdürülebilirdir. İki durumda da üretim domain’iyle güven ilişkisi kurmayın.

Yedek konsoluna MFA eklemek yeterli bir koruma mı?

Hayır. MFA konsol girişini korur; ama yedek sunucusunun işletim sisteminde yönetici olan biri veritabanına, yapılandırma yedeğine veya servislere doğrudan müdahale edebilir. MFA; domain dışı konumlandırma, rol ayrımı, dört göz onayı ve değiştirilemez depoyla birlikte anlam kazanır.

Misafir işletim sistemi işleme kimlik bilgileri neden risklidir?

Uygulama farkındalıklı yedekleme sanal makinelerin içinde yönetici yetkisi ister ve bu kimlik bilgileri yedek sunucusunda saklanır. Domain denetleyicileri de kapsamdaysa saklanan hesap domain düzeyinde yetkilidir. Yedek sunucusunu ele geçiren bu kimliklere ulaşır; bu yüzden yedek sunucusu en kritik katmanda korunmalı.