Sızma Testi Öncesi Hazırlık: Kapsam, Yetki ve Ortam

Sızma testi (penetration test), sistemlerinizin gerçek bir saldırganın yöntemleriyle, kontrollü ve yetkili biçimde sınanmasıdır. Testin değeri, hazırlığın kalitesine bağlıdır: kapsamı belirsiz, yetkisi yazılı olmayan ya da ortamı hazırlanmamış bir test ya eksik bulgu üretir ya da canlı sistemde istenmeyen etkiler yaratır. Bu rehber, sızma testi öncesinde kurum tarafında tamamlanması gereken hazırlıkları adım adım açıklar.

01Kapsamı Tanımlayın

Kapsam, neyin test edileceğini ve neyin test edilmeyeceğini yazılı olarak belirler. Alan adları, IP aralıkları, mobil uygulamalar, API'ler, iç ağ segmentleri ve bulut hesapları tek tek listelenmelidir. Kapsam dışı bırakılan sistemler (ör. üçüncü taraf barındırılan ödeme sayfası, üretim SCADA ağı) da açıkça yazılmalıdır. Kapsamı belirlerken şu sorular yol gösterir:

• Hangi sistemler en kritik veriyi (kişisel veri, finansal veri, ticari sır) işliyor?
• Son bir yılda hangi sistemler değişti ya da yeni devreye alındı?
• Dışarıya açık yüzey (web, API, VPN, e-posta) ile iç ağ ayrı ayrı mı test edilecek?
• Sosyal mühendislik (oltalama) ve fiziksel güvenlik kapsamda mı?

02Test Türünü Seçin

• Kara kutu: Test ekibi yalnızca dışarıdan görülebilen bilgiyle çalışır; gerçek saldırgan senaryosuna en yakın olandır ancak süre kısıtı nedeniyle derinlik sınırlıdır.
• Gri kutu: Kullanıcı hesapları, mimari şema ve API dokümantasyonu paylaşılır; verilen sürede en yüksek bulgu verimini sağlar ve yaygın tercihtir.
• Beyaz kutu: Kaynak kod ve yapılandırma dahil tam erişim; kod denetimiyle birleştirildiğinde en kapsamlı sonucu verir.

Web uygulaması testlerinde farklı rollerde (yönetici, standart kullanıcı, misafir) hesaplar hazırlanması, yetki atlama testlerinin yapılabilmesi için gereklidir.

03Yazılı Yetkilendirme Hazırlayın

Sızma testi, yazılı yetki olmadan yapıldığında hukuken izinsiz erişim sayılır. Test sözleşmesi ya da yetki yazısı şunları içermelidir: kapsam listesi, test tarihleri ve saat penceresi, izin verilen teknikler (ör. hizmet dışı bırakma testlerinin yasak olması), acil durumda iletişime geçilecek kişiler ve testi durdurma yetkisi olan kişi. Sistemleriniz bir barındırma ya da bulut sağlayıcısında çalışıyorsa, sağlayıcının sızma testi politikası kontrol edilmeli; bazı sağlayıcılar önceden bildirim ister.

04Ortamı Hazırlayın

• Canlı mı, test ortamı mı: Test ortamı canlıya eşdeğerse tercih edilir; canlı ortamda test yapılacaksa yoğun olmayan saatler seçilmeli ve veri değiştiren işlemler için kurallar konmalıdır.
• Yedek: Testten hemen önce doğrulanmış tam yedek alınmalıdır; geri yükleme adımları hazır olmalıdır.
• Test verisi: Test hesapları gerçek müşteri verisi içermemeli; test sırasında oluşturulan kayıtlar (siparişler, form gönderimleri) sonradan temizlenecek biçimde işaretlenmelidir.
• Güvenlik cihazları: WAF, IPS ve hız sınırlayıcıların test kaynak IP'leri için beyaz listeye alınıp alınmayacağına karar verilmelidir. Beyaz liste, uygulamanın kendi zafiyetlerinin görülmesini sağlar; kapalı tutmak ise savunma katmanının etkinliğini ölçer. Çoğu projede iki aşama birden planlanır.
• Bildirimler: SOC ekibi ya da izleme hizmeti alınan firma test hakkında bilgilendirilmeli, alarmların gerçek saldırıyla karışmaması sağlanmalıdır.

05Bilgi ve Erişimleri Paylaşın

Gri ve beyaz kutu testlerde mimari şema, API dokümantasyonu, kullanıcı rolleri, entegrasyon listesi ve varsa önceki test raporları paylaşılır. Erişimler süreli ve test bitiminde iptal edilecek biçimde tanımlanmalı; paylaşım şifreli kanalla yapılmalıdır. Kaynak kod paylaşımı gizlilik sözleşmesi kapsamında olmalıdır.

06İletişim ve Acil Durum Planı

Test boyunca iki tarafta da ulaşılabilir birer sorumlu belirlenir. Kritik bir zafiyet (ör. kimlik doğrulamasız veri erişimi) bulunduğunda rapor beklenmeden anında bildirilmesi kural olmalıdır. Test sırasında beklenmeyen bir etki (performans düşüşü, hata artışı) gözlenirse testi durdurma kararının kim tarafından verileceği önceden yazılmalıdır.

07Raporun Nasıl Olacağını Konuşun

Rapor formatını baştan netleştirmek, sonuçların işe yaramasını sağlar: yönetici özeti, bulguların risk derecelendirmesi (kritik, yüksek, orta, düşük), her bulgu için etki, kanıt ve yeniden üretim adımları, düzeltme önerileri ve genel değerlendirme. Bulguların hangi standartlara (OWASP Top 10, CWE) eşleneceği ve raporun hangi dilde teslim edileceği de belirlenmelidir.

08Doğrulama Testini Planlayın

Bulgular düzeltildikten sonra yapılan doğrulama testi (re-test), zafiyetlerin gerçekten kapandığını kanıtlar. Doğrulama testinin kapsamı, süresi ve ücretlendirmesi başta anlaşılmalıdır. Düzeltme planında bulguların sahipleri ve hedef tarihleri yer almalı; kritik bulgular için hızlı düzeltme döngüsü tanımlanmalıdır.

09Hazırlık Kontrol Listesi

• Kapsam ve kapsam dışı sistemler yazılı olarak listelendi.
• Test türü seçildi, gerekli hesaplar ve dokümanlar hazırlandı.
• Yetki yazısı imzalandı; barındırma sağlayıcısına gerekiyorsa bildirim yapıldı.
• Test tarihleri ve saat penceresi belirlendi.
• Doğrulanmış yedek alındı, geri yükleme planı hazır.
• WAF/IPS beyaz liste kararı verildi; SOC bilgilendirildi.
• Her iki tarafta sorumlu ve acil iletişim kanalı tanımlandı.
• Rapor formatı ve doğrulama testi anlaşıldı.

10Sonuç

İyi hazırlanmış bir sızma testi, kurumun güvenlik durumunu gerçekçi biçimde ortaya koyar ve düzeltme çalışmalarını önceliklendirir. Hazırlık aşamasında netleştirilen kapsam, yetki, ortam ve iletişim kuralları hem testin verimini artırır hem de canlı sistemleri korur. Kurumunuz için sızma testi kapsamı belirlemek üzere ücretsiz ön görüşme talep edebilirsiniz.