Muhasebe sunucusuna bulaşan fidye yazılımı, network share üzerindeki e-defter arşivini şifrelememesi için nasıl bir mimari kurmalıyız?
2 Cevap
Geleneksel Windows/Samba ağ paylaşımları (SMB/CIFS), fidye yazılımlarının yatayda yayılması (lateral movement) ve kurumsal arşivleri imha etmesi için en savunmasız saldırı yüzeyini oluşturur. Muhasebe sunucusuna veya bir kullanıcı terminaline sızan modern fidye yazılımları, lsass.exe belleğinden NTLM hash'lerini veya Kerberos biletlerini çalarak (Pass-the-Hash / Pass-the-Ticket), kurbanın erişim yetkisine sahip olduğu tüm SMB paylaşımlarındaki dosyaları şifreler. Muhasebe sunucusu tamamen ele geçirilse dahi e-defter arşivinin sağlam kalmasını garanti eden mimari, Sıfır Güven (Zero-Trust), Değiştirilemez Depolama (Immutable Storage / WORM) ve Ağ İzolasyonu prensipleri üzerine inşa edilmelidir.
1. SMB Paylaşımlarının Tamamen Ortadan Kaldırılması ve Ağ İzolasyonu:
Muhasebe sunucusu ile arşiv deposu arasında kalıcı bir SMB (TCP 445) veya NFS bağlantısı kesinlikle bulunmamalıdır:
- Ağ güvenlik duvarında (Next-Generation Firewall) muhasebe segmentinden depolama ağına doğru SMB, RDP ve SSH portları çift yönlü olarak engellenmelidir.
- Muhasebe sunucusu hiçbir ağ sürücüsünü (Mapped Drive /
Z:\) kalıcı olarak bağlamamalıdır; fidye yazılımları ilk olarak bağlı harf sürücülerini şifreler.
2. WORM (Write Once, Read Many) ve Object Lock Mimarisi:
E-defterler yasal olarak onaylandıktan sonra içeriği asla değiştirilmeyen statik dosyalardır. Bu nedenle arşiv katmanında S3 uyumlu Object Storage ve Object Lock (Compliance Mode) kullanılmalıdır:
- S3 Compliance Mode devreye alındığında, AWS root kullanıcısı veya yerel Linux sistem yöneticisi dahi retention period (örneğin 10 yıl) dolmadan dosyayı silemez, yeniden adlandıramaz veya üzerine yazamaz (overwrite).
- Fidye yazılımı API anahtarlarını ele geçirse dahi
s3:PutObjectçağrısıyla yeni bir sürüm yüklemeye çalışsa bile WORM politikası orijinal sürümü (versioning) kilitli tutar; imha imkansızdır.
3. İtiş (Push) Yerine Çekiş (Pull) Tabanlı Yedekleme:
Muhasebe sunucusu veriyi depolama alanına 'göndermemeli' (Push); bunun yerine izole bir yedekleme sunucusu (örneğin Linux tabanlı Veeam Hardened Repository veya izole bir SFTP ajanı) muhasebe sunucusuna bağlanarak veriyi 'çekmelidir' (Pull). Böylece muhasebe sunucusu hacklense bile depolama sunucusunun IP'sini, kimlik bilgilerini veya erişim anahtarlarını barındırmaz.
4. Sıfır Güven (Zero-Trust) Güvenli Arşiv API Ağ Geçidi ve HSM Bütünlüğü:
Muhasebe uygulaması arşivleme yapacağı zaman doğrudan dosya sistemine değil, bir Arşiv API Ağ Geçidine konuşmalıdır:
- mTLS (Karşılıklı TLS) ve Kısa Ömürlü Token: API bağlantısı mTLS istemci sertifikası ve HSM FIPS 140-2 Level 3 tarafından imzalanmış kısa ömürlü JWT belirteçleri ile doğrulanmalıdır.
- Tek Yönlü İzinler (Append-Only): API servis hesabının yetkisi yalnızca 'Upload' (Yazma) ile sınırlandırılmalıdır. Servis hesabının 'Update', 'Rename' veya 'Delete' yetkisi mimari olarak API seviyesinde kodlanmamalıdır (No-Delete API).
- XSD ve Hash Ön Doğrulaması: API ağ geçidi gelen XML'in e-defter şemasına (XSD) uygunluğunu ve SHA-256 özetini bellekte hesaplayıp WORM depolamaya yazar, istemciye sadece kriptografik makbuz döner.
5. Bağımsız Kimlik Alanı (Out-of-Band IAM):
Arşiv ve depolama sistemleri asla kurumsal Active Directory domain'ine üye yapılmamalıdır. Saldırgan Domain Admin yetkisi elde etse dahi, ayrı bir MFA ile korunan Linux tabanlı ve bağımsız IAM politikalarına sahip arşiv katmanına erişememelidir.
Savunma derinliği (Defense-in-Depth) stratejisi kapsamında uç nokta ve depolama seviyesinde şu ilave tedbirler alınmalıdır:
- FSRM ve Canary Dosyaları (Erken Uyarı Tuzakları): Windows File Server Resource Manager üzerinde bilinen fidye yazılımı uzantıları (
.lockbit,.cryingvb.) için dosya tarama kuralları tanımlanmalı; dizinlere 'Honey-token' sahte defter dosyaları yerleştirilmelidir. Bu dosyalara yazma denemesi yapıldığı an EDR ağ bağlantısını otomatik kesmelidir. - Hava Boşluklu (Air-Gapped) ve ZFS Tabanlı Snapshot: Depolama sisteminde günlük olarak alınan ZFS snapshot'ları read-only modda saklanmalı ve haftalık olarak fiziksel olarak ağdan kopuk (Air-Gapped LTO teyp kartuşu veya çevrimdışı NAS) ortama aktarılmalıdır.