Cy Logic Insights

Fidye Yazılımına Hazırlık: Saldırı Gelmeden Önce Yapılması Gereken 10 Şey

Fidye yazılımı olaylarında belirleyici olan antivirüs değil, hazırlıktır: değiştirilemez yedekler, geri yükleme provaları, ağ segmentasyonu, yetki hijyeni ve olay müdahale planı. / Ransomware readiness is decided before the attack: immutable backups, restore drills, segmentation, privilege hygiene and an incident response plan.

Fidye yazılımı (ransomware), dosyaları şifreleyip erişimi geri vermek için ödeme isteyen zararlı yazılımdır; güncel saldırılarda şifrelemeden önce verinin dışarı sızdırılması ve ifşa tehdidi de eklenir. Hedef seçimi büyük kurumlarla sınırlı değildir; otomasyon sayesinde her ölçekteki işletme hedef olabilir. Bu yazıda, saldırı gerçekleştiğinde fark yaratacak hazırlıkları önem sırasına göre anlatıyoruz. Yazı genel bilgilendirme amaçlıdır; bir olay yaşanıyorsa yetkili makamlara ve uzman olay müdahale ekibine başvurulmalıdır.

1. Değiştirilemez ve çevrimdışı yedek

Saldırganlar önce yedekleri hedefler. Yedek, üretim sistemiyle aynı kimlik bilgileriyle erişilebilir bir ağ paylaşımındaysa yedek değildir. Klasik 3-2-1 kuralı hâlâ geçerlidir: en az üç kopya, iki farklı ortam, bir kopya farklı lokasyonda. Buna modern eklenti: en az bir kopya değiştirilemez (immutable) veya çevrimdışı olmalıdır. Nesne depolamada "object lock" özellikleri veya fiziksel olarak ayrılan diskler bu işi görür.

2. Geri yükleme provası

Alınan yedek değil, geri yüklenen yedek değerlidir. Düzenli aralıklarla (örneğin her çeyrek) kritik sistemin yedekten ayrı bir ortama geri yüklenmesi ve çalıştığının doğrulanması gerekir. Bu prova, iki soruya cevap verir: geri dönüş ne kadar sürüyor (RTO) ve ne kadar veri kaybediyoruz (RPO). Bu iki değer bilinmeden "hazırız" denemez.

# Örnek: PostgreSQL yedeğinin ayrı bir ortama geri yüklenmesi ve doğrulanması
pg_restore --clean --if-exists -d restore_test /backups/app_2026-10-01.dump
psql -d restore_test -c "select count(*) from invoices;"   # beklenen sayıyla karşılaştır

3. Yetki hijyeni

Fidye yazılımı, ele geçirdiği hesabın yetkisi kadar yayılır. Günlük işlerde yönetici hesabı kullanılmaması, yerel yönetici haklarının kaldırılması, servis hesaplarının en az yetkiyle tanımlanması ve çok faktörlü kimlik doğrulama (MFA) yayılma hızını ciddi biçimde düşürür.

4. Ağ segmentasyonu

Düz bir ağda bir cihazın enfekte olması tüm ağın enfekte olması demektir. Sunucular, kullanıcı cihazları, yedekleme ağı ve IoT cihazları ayrı segmentlerde tutulmalı; yedekleme sunucusuna yalnızca yedekleme trafiği ulaşmalıdır.

5. Yama ve açık servis yönetimi

İnternete açık ve güncellenmemiş servisler (uzak masaüstü, VPN cihazları, eski web uygulamaları) en yaygın giriş noktaları arasındadır. Dışa açık servislerin envanteri çıkarılmalı, gerekmeyenler kapatılmalı, kalanlar güncel tutulmalı ve MFA arkasına alınmalıdır.

6. E-posta ve kullanıcı farkındalığı

Oltalama (phishing) hâlâ en yaygın başlangıç noktasıdır. Teknik filtreler önemlidir; ancak çalışanların şüpheli e-postayı bildirmesini kolaylaştıran ve bildireni cezalandırmayan bir kültür en az filtreler kadar etkilidir.

Fidye yazılımı olaylarında ödemenin veriyi geri getireceğine dair hiçbir garanti yoktur. Tek güvenilir kurtarma yolu, saldırıdan önce alınmış ve test edilmiş yedektir.

7. Olay müdahale planı: kâğıt üzerinde olsun

Sistemler kilitlendiğinde dijital bir plana erişemeyebilirsiniz. Basılı bir kopyada şunlar olmalıdır: kimin aranacağı (yönetim, BT, hukuk, sigorta, gerekiyorsa kolluk ve veri koruma otoritesi), hangi sistemlerin önce izole edileceği, iletişimin hangi kanaldan yürütüleceği (kurumsal e-posta devre dışı kalabilir) ve geri yükleme sırası.

8. Veri sızıntısı senaryosu ve bildirim yükümlülüğü

Kişisel veri sızdıysa Türkiye'de KVKK, KKTC'de Kişisel Verilerin Korunması Yasası ve AB bağlantılı veriler için GDPR kapsamında bildirim yükümlülükleri doğabilir; süreler ve usul mevzuata göre değişir. Hangi verinin nerede tutulduğunu bilmek (veri envanteri), bu anda saatler kazandırır.

9. İzleme ve erken uyarı

Toplu dosya değişiklikleri, olağandışı saatlerde yönetici girişleri, yedek silme girişimleri gibi sinyaller merkezi kayıt sisteminde uyarıya bağlanmalıdır. Erken fark edilen bir olay, tüm ağ yerine tek bir segmentle sınırlı kalabilir.

10. Tatbikat

Yılda en az bir kez masa başı tatbikat yapın: "Pazartesi sabahı muhasebe sunucusu şifrelendi" senaryosunu yönetim ve BT ile birlikte adım adım yürütün. Çoğu kurum ilk tatbikatta planın eksik yerlerini keşfeder; keşfin yeri tatbikattır, gerçek olay değil.

Çerçeveler

Olay anı: ilk saatlerde ne yapılır?

Bu bölüm bir olay müdahale planının yerini tutmaz; ancak planı hazırlarken içermesi gereken başlıkları gösterir.

  1. İzole edin: Etkilenen cihazları ağdan ayırın (kapatmayın; adli inceleme için bellek önemli olabilir). Yedekleme sunucusunun ağ bağlantısını kesin.
  2. Yayılmayı durdurun: Şüpheli hesapların oturumlarını iptal edin, parolaları değiştirin, uzaktan erişimi geçici olarak kapatın.
  3. Kayıt alın: Ne zaman fark edildi, hangi sistemler etkilendi, fidye notunda ne yazıyor; ekran görüntüleri ve zaman damgaları.
  4. Bildirin: Yönetim, hukuk, sigorta ve planınızdaki dış uzmanlar. Kişisel veri etkilendiyse mevzuattaki bildirim sürelerini hukuk danışmanıyla değerlendirin.
  5. Kurtarmayı planlayın: Temiz bir ortama, doğrulanmış yedekten, öncelik sırasına göre geri yükleme. Enfekte sistemin üzerine geri yükleme yapılmaz.

Yedek doğrulaması: "temiz" olduğundan nasıl emin olunur?

Saldırganlar bazen şifrelemeden haftalar önce sisteme girer; bu dönemde alınan yedekler zararlıyı içerebilir. Bu nedenle yedek saklama politikası yalnızca son birkaç günü değil, haftalık ve aylık noktaları da içermelidir. Geri yükleme, izole bir ortamda yapılır ve sistem ağa açılmadan önce taranır. Uygulama verisinin (veritabanı) yedeği ile sistem imajının yedeği ayrı tutulursa, temiz bir işletim sistemi üzerine yalnızca veriyi geri yüklemek mümkün olur; bu çoğu zaman en güvenli yoldur.

Küçük işletmeler için asgari paket

  • Günlük otomatik yedek, haftalık ve aylık saklama noktaları.
  • Bir kopya şifreli olarak kurum dışında, üretim kimlik bilgileriyle silinemeyecek şekilde.
  • Tüm hesaplarda MFA; günlük işlerde yönetici hesabı kullanılmaması.
  • Otomatik güncellemeler açık; dışa açık uzak masaüstü yok.
  • Üç ayda bir geri yükleme provası; sonuç bir sayfada kayıtlı.
  • Basılı iletişim listesi ve müdahale adımları.

Bu paket mükemmel değildir ama fidye yazılımı olaylarının büyük kısmında belirleyici olan temel adımları kapsar.

Sigorta ve sözleşmeler

Siber sigorta poliçeleri genellikle belirli asgari önlemleri (MFA, yedekleme, güncelleme) şart koşar; önlemler yoksa teminat geçersiz olabilir. Poliçeyi yenilemeden önce şartları BT ekibiyle birlikte okuyun. Benzer şekilde, yazılım ve altyapı tedarikçilerinizle yapılan sözleşmelerde olay anındaki sorumluluk ve yanıt süreleri yazılı olmalıdır.

Kültür: suçlama değil, bildirim

Oltalama e-postasına tıklayan çalışan, bunu hemen bildirirse olay bir cihazla sınırlı kalabilir; cezalandırılacağını düşünüp saklarsa tüm ağa yayılır. "Tıkladım, ne yapmalıyım?" sorusunun cevabını herkesin bildiği ve soranın takdir edildiği bir kültür, en pahalı güvenlik ürününden daha etkilidir.

Son söz

Fidye yazılımı tehdidi ortadan kalkmayacak; ancak hazırlıklı bir işletme için bu bir felaket değil, yönetilebilir bir kesinti olabilir. Fark, saldırıdan önce yapılanlardadır.

NIST Cybersecurity Framework 2.0 (tanımla, koru, tespit et, müdahale et, kurtar, yönet) ve ISO/IEC 27001:2022'nin yedekleme, kayıt, olay yönetimi ve iş sürekliliği kontrolleri bu listeyle örtüşür. Cy Logic'in altyapı hizmetlerinde yedekleme stratejisi ve felaket kurtarma planı, kurulumun isteğe bağlı değil zorunlu parçasıdır.