Bulut Olay Müdahalesi: Geleneksel Yaklaşımdan Farkları

Adli Bilişim kütüphanemizde işlediğimiz olay müdahale ilkeleri (delil toplama, volatilite sırası, chain of custody), BULUT ortamlarında UYGULANMASI GEREKTİĞİNDE ÖNEMLİ ÖLÇÜDE FARKLILAŞIR — çünkü GELENEKSEL yöntemlerin ÇOĞU, FİZİKSEL bir sunucuya ELİNİZLE DOKUNABİLDİĞİNİZ varsayımına DAYANIR.

Temel Fark: Fiziksel Erişim Yok

Adli Bilişim kütüphanemizdeki "Disk İmajlama" makalesinde ANLATTIĞIMIZ, bir sunucuya write blocker TAKIP bit-bit imaj ALMA süreci, bulutta DOĞRUDAN MÜMKÜN DEĞİLDİR — çünkü fiziksel donanıma ERİŞİMİNİZ YOKTUR, sadece bulut sağlayıcının SUNDUĞU API'LER üzerinden İŞLEM yapabilirsiniz. Bunun yerine:

• Snapshot alma: Bulut sağlayıcıların ÇOĞU, bir sanal disk'in ANLIK bir kopyasını (snapshot) API ÜZERİNDEN, SANİYELER içinde ALMANIZA imkân TANIR — bu, GELENEKSEL disk imajlamanın bulut KARŞILIĞIDIR.
• İzole edilmiş inceleme ortamı: Alınan snapshot, ORİJİNAL, potansiyel olarak TEHLİKELİ ortamdan İZOLE, AYRI bir "adli bilişim" hesabına/ortamına AKTARILIP ORADA incelenir — bu, ORİJİNAL sistemin KANITLARI bozmadan, GÜVENLİ bir şekilde analiz edilmesini SAĞLAR.

Volatilite Sırası, Bulutta Nasıl Değişir?

Adli Bilişim kütüphanemizdeki RFC 3227 volatilite sıralamasını HATIRLARSAK, RAM en GEÇİCİ veriydi. Bulutta, bir sanal makineyi DURDURMAK (stop), genelde RAM İÇERİĞİNİN KAYBOLMASINA yol AÇAR — bu yüzden, EĞER mümkünse, bellek ANALİZİ (Malware Analizi kütüphanemizdeki Volatility makalesinde İŞLEDİĞİMİZ teknikler), sistemi DURDURMADAN ÖNCE, CANLI olarak YAPILMALIDIR.

Loglar: Bulut Sağlayıcının Kendi Kayıtları KRİTİK

Bulut ortamlarının EN BÜYÜK avantajlarından biri, sağlayıcının KENDİSİNİN, HER API çağrısını OTOMATİK olarak LOGLAMASIDIR:

• AWS CloudTrail: "Kim, NE ZAMAN, HANGİ API'yi ÇAĞIRDI" bilgisinin TAMAMINI kaydeder.
• Azure Activity Log / GCP Audit Logs: BENZER işlevi GÖRÜR.

Bu loglar, Adli Bilişim kütüphanemizdeki "Log Analizi ve Zaman Çizelgesi" makalesinde ANLATTIĞIMIZ SÜPER ZAMAN ÇİZELGESİ oluşturma sürecinin, BULUTTAKİ EN DEĞERLİ VERİ KAYNAĞIDIR — bir saldırganın TAM OLARAK HANGİ ADIMLARI ATTIĞINI (hangi kaynakları OLUŞTURDUĞUNU, SİLDİĞİNİ, DEĞİŞTİRDİĞİNİ), NEREDEYSE SANİYE SANİYE takip etmeyi SAĞLAR.

Kapsam Belirleme (Containment) Bulutta Nasıl Yapılır?

Geleneksel olay müdahalesindeki "kabloyu ÇEKME" (ağ bağlantısını fiziksel olarak KESME) yaklaşımı, bulutta API ÜZERİNDEN yapılan İŞLEMLERE dönüşür:

• Ele geçirilen bir kaynağın GÜVENLİK GRUBUNU (firewall kuralları), TÜM giden/gelen trafiği ENGELLEYECEK şekilde DEĞİŞTİRMEK — bu, kaynağı SİLMEDEN, ADLİ BİLİŞİM için KORUYARAK, ağdan İZOLE eder.
• Ele geçirilen bir IAM kimlik BİLGİSİNİN yetkilerini ANINDA İPTAL etmek (revoke).

Pratik Senaryo

Bir şirketin bulut ortamındaki BİR sanal makinenin ELE GEÇİRİLDİĞİNDEN ŞÜPHELENİLİYOR. Ekip, GELENEKSEL refleksle makineyi HEMEN "kapatmayı" (stop) DÜŞÜNÜYOR — ama bu, RAM'deki DEĞERLİ kanıtların (saldırganın BELLEKTE ÇALIŞAN, dosyasız zararlı YAZILIMI gibi) KAYBOLMASINA yol AÇACAKTI. Bunun yerine ekip: ÖNCE bir bellek SNAPSHOT'ı alıyor, SONRA makinenin güvenlik GRUBUNU değiştirerek AĞ İZOLASYONU sağlıyor (makineyi KAPATMADAN), ve PARALEL olarak CloudTrail loglarını İNCELEYEREK saldırganın TAM OLARAK HANGİ API çağrılarını YAPTIĞINI (hangi YENİ kullanıcı OLUŞTURDUĞUNU, hangi VERİYE ERİŞTİĞİNİ) ORTAYA ÇIKARIYOR — TÜM bu ADIMLAR, makineyi HİÇ FİZİKSEL OLARAK DOKUNMADAN, TAMAMEN API ÜZERİNDEN gerçekleştiriliyor.

Neden Önceden Hazırlık Şart?

Bulut olay müdahalesinin EN BÜYÜK ZORLUĞU, KRİZ ANINDA "nasıl snapshot ALINIR, hangi log NEREDE" diye ARAŞTIRMAYA BAŞLAMAKTIR — Adli Bilişim kütüphanemizdeki hazırlık AŞAMASININ ÖNEMİ, bulutta DAHA da BÜYÜKTÜR: ekiplerin, bir olay GERÇEKLEŞMEDEN ÖNCE, bulut SAĞLAYICIYA ÖZGÜ araçları ve PROSEDÜRLERİ ÖNCEDEN TEST etmiş OLMASI GEREKİR.

Bu makale, bulut olay müdahalesinin geleneksel yaklaşımdan farklarının orta-ileri seviye bir özetidir ve Bulut Güvenliği kütüphanemizin son makalesidir; siber-arsiv ekibi tarafından hazırlanmış özgün içeriktir.