1. GİRİŞ

Penetrasyon testi (pentest), bir sistemin, uygulamanın veya altyapının güvenlik zafiyetlerini gerçekçi saldırı senaryoları ile tespit etmek amacıyla kontrollü şekilde saldırıya uğratılmasıdır. Dijital dönüşüm, bulut‑native mimariler, API‑bazlı servisler ve yazılım tedarik zincirinin karmaşıklığı arttıkça, kuruluşların güvenlik açıklarını önceden keşfedip kapatması hayati önem kazandı. Pentest, sadece bir güvenlik taraması değil; insan‑örgütlü saldırı zihin yapısına göre düşünmeyi, bulguları etki odaklı raporlamayı ve düzeltme adımlarını doğrulamayı hedefler.

Neden bugün önemli?

• Hızla değişen uygulama yüzeyi ve üçüncü parti bağımlılıkları yeni zafiyet sınıfları oluşturuyor.
• Regülasyonlar (PCI‑DSS, GDPR, KVKK vb.) ve siber sigorta gereksinimleri düzenli pentest raporları talep edebiliyor.
• Saldırganların otomasyon ve RaaS (Ransomware as a Service) modelleriyle hız kazanması, proaktif inceleme ihtiyacını artırıyor.

Kimler için önemli?

• Güvenlik ekipleri ve pentest mühendisleri
• Uygulama geliştiriciler ve SRE/DevOps
• Üst yönetim, risk ve uyumluluk ekipleri

2. KAVRAMSAL TEMELLER

2.1 Tanımlar

• Penetrasyon Testi (Pentest): Kontrol edilmiş saldırı simülasyonları ile zafiyet tespiti ve exploit denemeleri.
• Red Team: Uzun vadeli, hedef odaklı saldırı simülasyonları; genelde tespit etme (blue team) yeteneklerini ölçer.
• Vulnerability Assessment: Zayıf noktaların keşfi; genelde exploit denemesi içermez veya sınırlıdır.
• Rules of Engagement (RoE): Testin kapsamı, izin verilen eylemler, etkilenebilir sistemler ve iletişim kanallarını tanımlayan sözleşme.

2.2 Pentest türleri

• Black‑box: Hedef hakkında az bilgi ile dışarıdan saldırı benzetimi.
• White‑box: Kaynak kod, mimari ve iç ağ bilgisi ile kapsamlı analiz.
• Gray‑box: Kısmi bilgi (örn. user credentials) ile test; gerçek dünya servise benzer.
• Network, Web Application, Mobile, Cloud, API, IoT: Hedefe göre uzmanlaşmış test kategorileri.

3. NASIL ÇALIŞIR?

3.1 Metodoloji — genel aşamalar

1. Planlama ve Kapsam (Scoping): RoE, hedef IP/URL listesi, test zamanı, kritik sistemler, iletişim ve eskalasyon hattı belirlenir.
2. Reconnaissance (Keşif): Pasif ve aktif bilgi toplama; DNS, whois, subdomain enumeration, OSINT, açık kaynak analizleri.
3. Scanning ve Enumeration: Port scan, servis tespiti, web dizin tarama, API keşfi, versiyon ve teknoloji fingerprinting.
4. Vulnerability Identification: Otomatik tarayıcılar (Nessus, OpenVAS) + manuel testler (Burp, sqlmap) ile zafiyetler tespit edilir.
5. Exploitation: Gerekli izinlerle, kontrollü exploit denemeleri ile zaafiyetlerin reel etkisi doğrulanır.
6. Post‑exploitation / Lateral Movement: Yetki yükseltme, veri erişimi, persistence teknikleri ve etki analizi yapılır (ancak kurallara sadık kalınır).
7. Reporting: Teknik bulgular, risk değerlendirmesi (CVSS veya business‑impact), PoC, düzeltme önerileri ve re‑test planı ile raporlanır.
8. Remediation Verification: İyileştirmeler uygulandıktan sonra doğrulama (re‑test) yapılır.

3.2 Teknik adımlar — örnek akış

Keşif aşamasında subfinder, amass, crt.sh gibi araçlarla subdomain listesi çıkarılır. Nmap ile port ve servis keşfi yapılır; HTTP servislerde Burp Suite ile proxy altında manuel testler başlatılır. SQLi için parametrik testler ve waqt‑based teknikler, SSRF, XXE, IDOR, authentication bypass senaryoları denenir. Cloud ortamlarında IAM rol ve metadatasının yanlış konfigürasyonu araştırılır; S3/GCS bucket exposure, misconfigured IAM policies ve server metadata erişimleri önemli hedeflerdir.

3.3 Araç zinciri

• Recon: amass, subfinder, theHarvester, crt.sh
• Scanning: nmap, masscan, naabu
• Web app: Burp Suite, OWASP ZAP, sqlmap, dirbuster
• Vuln assessment: Nessus, OpenVAS, Qualys
• Exploitation & post‑exp: Metasploit, Cobalt Strike (etik kullanım ve lisans gereksinimi önemli), Empire
• Cloud: ScoutSuite, Prowler, Pacu
• AD / Enterprise: BloodHound, PowerSploit, Impacket

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Web uygulama testleri (örnek senaryo)

Bir fintech servisinde pentest: hedef web uygulamasında parameter tampering, stored XSS ve weak session yönetimi tespit edilir. Sensitive endpoint'ler için rate limit eksikliği ve eksik authorizat ion kontrolü keşfedilir. Exploit sonrası test ekibi, yalnızca doğrulama amaçlı non‑destructive PoC ile müşteri verilerine erişimi gösterir ve remediations request listesi sunar.

4.2 Cloud ve container senaryoları

Bir SaaS platformunda pentest sırasında yanlış IAM rol ataması ve açık S3 bucket tespit edilir. Ayrıca Kubernetes ortamında RBAC hatası ve insecure kubelet konfigurasyonu yoluyla pod erişimi ve container escape senaryoları test edilir.

4.3 Kurumsal / AD testleri

İç ağ testi kapsamında, zayıf servis hesapları ve GPO hataları kullanılarak lateral movement yöntemiyle domain admin poziyonuna ulaşma senaryosu, yine RoE dahilinde kontrollü olarak çalıştırılır; bulgularda ayrıntılı 'blast radius' ve önerilen hardening adımları verilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Gerçek saldırı senaryoları ile zafiyetlerin işletmeye etkisi ölçülür.
• Önceliklendirilmiş düzeltme listesi ve PoC ile geliştiriciye net aksiyon verilir.
• Uyumluluk ve raporlama ihtiyaçlarını karşılar; sigorta taleplerinde referans sağlar.

Sınırlamalar

• Pentest belirli bir zaman dilimindeki durumun snapshot'ını verir; sürekli güvenliği sağlamaz.
• Yanlış scope veya yetersiz RoE, iş kesintilerine veya yanlış sonuçlara yol açabilir.
• Otomatik tarayıcılar false positive/negative üretebilir; manuel uzmanlık gereklidir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Sözleşme ve scoping

• Rules of Engagement (RoE) açık, yazılı ve onaylı olmalı; test zamanları, acil iletişim ve out‑of‑band kontaklar net olmalıdır.
• Scope dışı sistemler ve üretim kritik yollar kesin olarak tanımlanmalı ve korunmalıdır.

7.2 Güvenlik ve etik

• Yasal izinler, gizlilik ve veri koruma kurallarına uyun; kişi‑veri erişimi gerekli ise masking/gizleme yöntemleri önceden planlanmalı.
• Kötü amaçlı yazılım kullanımı ve veri sızdırma gibi eylemler kesinlikle yasaktır; PoC'ler non‑destructive olmalıdır.

7.3 Raporlama ve remediation

• Teknik rapor: PoC, exploit adımları, loglar ve ilgili kod/CLI çıktılarını içermeli.
• Executive summary: İş etkisi, risk prioriteleri, önerilen roadmap kısa ve net şekilde sunulmalı.
• Re‑test planı: Öncelikli bulgular için re‑test takvimi ve doğrulama süreci belirlenmeli.

8. SIK YAPILAN HATALAR

• Yetersiz scoping: testin üretimi bozacak bileşenleri kapsaması.
• Eksik iletişim: kritik bir bulgu elde edildiğinde hızlı eskalasyon kanalı olmaması.
• Raporda sadece teknik detay vermek; iş etkisini ve düzeltme önceliklerini belirtmemek.
• Re‑test yapılmaması; bulguların kapatıldığı doğrulanmaması.

9. GELECEK TRENDLER

9.1 AI ve otomasyonun etkisi

AI, recon ve exploit keşif süreçlerinde hız sağlayacak; fakat adversarial kullanım riskleri ve doğrulanabilirlik (explainability) sorunları devam edecek. AI destekli fuzzing, intelligent scanning ve exploit suggestion araçları test verimliliğini artıracak.

9.2 Continuous pentesting ve BAS

Continuous pentest ve Breach and Attack Simulation (BAS) araçları, sürekli saldırı simülasyonu ile zafiyetlerin hızlı yakalanmasını sağlar; pentest ekipleri daha stratejik ve derin analizlere odaklanır.

9.3 Supply chain & software composition analysis

Yazılım tedarik zinciri saldırıları arttıkça SBOM, SCA araçları ve bağımlılık taramaları pentest kapsamının ayrılmaz parçası olacak. Bu alanlar derinlemesine kod ve paket analizi gerektirir.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Pentest ile vulnerability assessment arasındaki fark nedir?

   Vulnerability assessment zafiyetleri listeler ve genelde exploit denemeleri sınırlıdır. Pentest ise gerçekçi exploit senaryolarıyla zafiyetin etkisini doğrular ve business‑impact ölçer.

2. 2. Pentest ne sıklıkla yapılmalıdır?

   Risk profilinize göre değişir: kritik uygulamalar için en az yılda bir veya her büyük sürümde; continuous security uygulayan organizasyonlar için daha sık veya sürekli test önerilir.

3. 3. Üretim ortamında pentest güvenli midir?

   Üretim pentest yapılabilir ancak RoE, maintenance windows, backup/restore planları ve hızlı eskalasyon kanalları şarttır. Alternatif olarak staging/replica ortamları tercih edilir.

4. 4. Pentest maliyeti nasıl belirlenir?

   Maliyet scope, hedef tipleri, test süresi, uzmanlık seviyesi ve rapor detayına göre değişir; red team daha maliyetlidir. Sabit‑fiyat veya günlük ücret modelleri yaygındır.

5. 5. Raporlanan bulguların önceliğini nasıl belirlemeli?

   CVSS ile teknikal risk değerlendirmesi yapılır ama business impact (verinin değeri, erişim potansiyeli) göz önünde bulundurularak önceliklendirin.

6. 6. İçerdeki bir ekibin pentest yapması mı dış ekip mi daha iyi?

   Dış ekip taze göz, farklı taktik ve bağımsız doğrulama sunar; iç ekipler ise daha hızlı re‑test ve entegrasyon avantajı sağlar. Hibrit modeller faydalıdır.

7. 7. Exploit PoC'leri raporda nasıl sunulmalı?

   Non‑destructive, yeniden üretilebilir adımlar, CLI çıktıları ve gerekli log parçaları ile; canlı veri sızdırma yerine ekran görüntü veya dummy data kullanarak gösterilmelidir.

8. 8. Pentest sonrası en önemli adım nedir?

   Remediation ve re‑test. İyileştirmeler uygulandıktan sonra doğrulama yapılmadan test kapatılmamalıdır.

Anahtar Kavramlar

• RoE: Test kapsamı ve kurallarını belirleyen belge.
• PoC: Proof of Concept — zafiyetin demonstrasyonu.
• CVSS: Zafiyetlerin teknik ağırlığını gösteren skorlama sistemi.
• BAS: Breach and Attack Simulation — otomatik saldırı simülasyonu araçları.

Öğrenme Yol Haritası

1. 0–1 ay: Ağ ve web temel kavramları, HTTP/HTTPS, TLS, temel Linux komutları ve scripting (bash/python) öğrenin.
2. 1–3 ay: Nmap, Burp Suite, sqlmap gibi temel araçlarla pratik yapın; OWASP Top10'ı derinlemesine inceleyin.
3. 3–6 ay: Advanced exploitation, AD/enterprise security, cloud pentesting (AWS/Azure/GCP) ve container güvenliğini öğrenin; lab ortamlarında (VulnHub, TryHackMe) pratik yapın.
4. 6–12 ay: Red teaming, threat emulation, exploit development ve program yönetimi becerileri üzerinde çalışın; raporlama ve müşteri iletişimini geliştirin.