Sızma testi (pentest), yetkili bir güvenlik uzmanının sistemlerinize gerçek bir saldırganın bakış açısıyla, ama yazılı izinle ve kontrollü biçimde yaklaşmasıdır. Amaç "açık var mı?" sorusunu otomatik bir listeyle değil, gerçekten istismar edilebilir mi ve işe etkisi ne? sorusunu kanıtla yanıtlamaktır. Bu rehberde sızma testini zafiyet taramasından ve red team çalışmasından ayırıyor, black/gray/white box yaklaşımlarını karşılaştırıyor, yedi adımlık test sürecini ve bir pentest raporunun nasıl okunacağını CVSS örnekleriyle anlatıyoruz. Kapsam Sihirbazı ile kendi test kapsamınızı çıkarın, Risk Matrisi Gezgini ile bulguları iş riskine çevirmeyi deneyin.
- Sızma testi, bulunan açığın gerçekten istismar edilebilir olduğunu kanıtlayan, yetkili ve kontrollü bir güvenlik değerlendirmesidir.
- Zafiyet taraması otomatik ve sık yapılır; sızma testi insan uzmanlığıyla zincirleme riskleri bulur; red team ise tespit ve müdahale yeteneğinizi sınar.
- Gray box yaklaşımı (sınırlı bilgi ve test hesabı) çoğu kurum için süre ve kapsam dengesini en iyi kurar.
- Raporda CVSS puanı bulgunun teknik ciddiyetini, risk matrisi ise sizin işinize etkisini gösterir; ikisi aynı şey değildir.
- Test yılda en az bir kez ve her büyük değişiklikten sonra tekrarlanmalı; düzeltmeler doğrulama testiyle kapatılmalıdır.
- Yazılı yetkilendirme olmadan hiçbir sisteme test yapılmaz; izinsiz test, iyi niyetli olsa da suç oluşturabilir.
Sızma testi (pentest) nedir?
Sızma testi, İngilizce adıyla penetration test ya da kısaca pentest; bir sistemin, uygulamanın veya ağın güvenliğini, saldırganların kullandığı yöntemleri taklit ederek ölçen yetkili bir değerlendirmedir. Türkçede "penetrasyon testi" ifadesi de aynı anlamda kullanılır. Test sonunda elinize geçen şey bir araç çıktısı değil; bulguların kanıtıyla, iş etkisiyle ve çözüm önerisiyle yazıldığı bir rapordur.
Pentestin ayırt edici yanı doğrulamadır. Bir tarama aracı "bu sürümde bilinen bir açık olabilir" der; sızma testi uzmanı ise o açığın sizin ortamınızda gerçekten kullanılabilir olup olmadığını, kontrollü ve zarar vermeyecek şekilde kanıtlar. Böylece yanlış alarmlar elenir, gerçek riskler önceliklendirilir.
İkinci ayırt edici yan bağlamdır. Tek başına "düşük" görünen üç küçük sorun, bir saldırganın elinde birleştiğinde müşteri verisine giden kritik bir yola dönüşebilir. Örneğin sızan bir kullanıcı adı listesi, zayıf parola politikası ve çok faktörlü doğrulamanın olmaması birlikte değerlendirildiğinde hesap ele geçirme senaryosu ortaya çıkar. Bu zincirleme düşünce, otomatik araçların en zayıf olduğu alandır.
Sızma testi bir kez yapılıp rafa kaldırılacak bir denetim de değildir. Uygulamanız her sürümde değişir, yeni bir API uç noktası eklenir, bir sunucu buluta taşınır. Güvenliği yazılım geliştirme yaşam döngüsünün parçası olarak ele alan ekipler, pentesti web yazılım geliştirme sürecindeki kod incelemesi ve otomatik testlerle birlikte kurgular.
Zafiyet taraması, sızma testi ve red team arasındaki fark nedir?
Bu üç kavram sıkça birbirinin yerine kullanılır, ama farklı sorulara cevap verir. Zafiyet taraması "bilinen açıklar nerede olabilir?" sorusunu hızlı ve geniş biçimde yanıtlar. Sızma testi "bu açıklar gerçekten kullanılabilir mi ve nereye kadar ilerlenebilir?" sorusunu derinlemesine yanıtlar. Red team ise "gerçek bir saldırı olsa ekibimiz fark eder ve durdurabilir mi?" sorusunu sınar. Olgun bir güvenlik programı üçünü birbirinin yerine değil, birbirinin tamamlayıcısı olarak kullanır.
| Ölçüt | Zafiyet taraması | Sızma testi | Red team |
|---|---|---|---|
| Temel soru | Bilinen açıklar nerede olabilir? | Açıklar istismar edilebilir mi, etkisi ne? | Saldırıyı tespit edip durdurabiliyor muyuz? |
| Yöntem | Büyük ölçüde otomatik araçlar | Uzman eli + araç desteği, manuel doğrulama | Hedefe yönelik, gizli, çok vektörlü senaryo |
| Kapsam | Geniş: tüm IP ve uygulamalar | Tanımlı varlıklar, derinlemesine | Hedef odaklı (ör. finans verisine ulaşmak) |
| Yanlış alarm | Görece yüksek, ayıklama gerekir | Düşük, bulgular kanıtlanır | Düşük, senaryo bazlı raporlanır |
| Kimin haberi var? | BT ekibi bilir | Genellikle BT ve güvenlik ekibi bilir | Çoğunlukla yalnız sınırlı bir yönetici grubu bilir |
| Tipik sıklık | Sürekli veya aylık/üç aylık | Yılda en az bir kez + büyük değişiklikte | Olgunluk arttıkça, genellikle yıllık |
| Çıktı | Zafiyet listesi | Kanıtlı bulgu raporu + çözüm önerileri | Saldırı hikâyesi + tespit/müdahale boşlukları |
| Kimler için uygun? | Herkes; temel hijyen | İnternete açık uygulaması veya kişisel verisi olan her kurum | Olgun güvenlik ekibi ve SOC'si olan kurumlar |
Black box, gray box ve white box test nedir?
Yaklaşım, test ekibine test öncesinde ne kadar bilgi ve erişim verildiğini tanımlar. Bilgi azaldıkça senaryo dış saldırgana benzer, ama aynı sürede daha az derinliğe inilir. Bilgi arttıkça kapsam daha verimli taranır. Doğru seçim, neyi kanıtlamak istediğinize bağlıdır.
Black box
Test ekibine yalnızca hedef adresler verilir; kullanıcı hesabı, dokümantasyon veya kaynak kod paylaşılmaz. İnternetteki anonim bir saldırganın görebildiğini gerçekçi biçimde simüle eder.
Artı: Gerçekçi dış bakış; bilgi sızıntılarını ve unutulmuş varlıkları ortaya çıkarır.
Eksi: Keşfe çok zaman gider; oturum açılan alanların ve iş mantığının derinliği sınırlı kalabilir.
Gray box
Test ekibi farklı rollerde test hesapları, temel mimari bilgisi ve API dokümantasyonu gibi sınırlı bilgilerle çalışır. Kötü niyetli bir müşteri, ele geçirilmiş bir kullanıcı hesabı veya içerideki bir çalışan senaryosuna yakındır.
Artı: Süre ve derinlik dengesi en iyisi; yetkilendirme hatalarını (IDOR, yetki yükseltme) verimli bulur.
Eksi: Tamamen anonim saldırganın keşif yeteneğini tam olarak ölçmez.
White box
Kaynak kod, mimari diyagramlar, yapılandırma dosyaları ve gerekirse yönetici erişimi paylaşılır. Test, kod incelemesi ve yapılandırma denetimiyle birleşir.
Artı: En kapsamlı yaklaşım; gizli iş mantığı hatalarını ve kök nedenleri bulur.
Eksi: Hazırlık ve analiz süresi uzundur; dış saldırgan gerçekçiliği daha düşüktür.
Hangi sistemler test edilir? Pentest türleri ve kapsam sihirbazı
"Sızma testi yaptıralım" demek, hangi varlıkların test edileceği netleşmeden yarım bir karardır. Web uygulaması testi ile iç ağ ve Active Directory testi bambaşka hazırlık, metodoloji ve süre ister. Kapsam ne kadar net yazılırsa teklifler o kadar karşılaştırılabilir, rapor o kadar işe yarar olur.
Aşağıdaki sihirbazda test ettirmek istediğiniz varlık türlerini, yaklaşımı ve ortamı seçin. Sihirbaz size kapsam özetini, uygun test metodolojilerini, hazırlamanız gerekenleri ve örnek bir süre aralığını çıkarır. Mobil tarafta test planlarken uygulamanın mimarisini anlamak için mobil uygulama geliştirme süreci rehberimize de göz atabilirsiniz.
Web uygulaması, API · Gray box yaklaşım · Test (staging) ortam
- OWASP WSTG — Web Security Testing Guide — web uygulamaları için kapsamlı test senaryoları.
- OWASP ASVS — Application Security Verification Standard — doğrulanacak güvenlik gereksinimleri listesi.
- OWASP API Security Top 10 — API'lere özgü en yaygın risk kategorileri (2023 sürümü).
- Yetkilendirme ve rol ayrımı (IDOR)
- Oturum yönetimi
- Enjeksiyon türleri
- İş mantığı hataları
- Nesne düzeyinde yetkilendirme (BOLA)
- Fonksiyon düzeyinde yetkilendirme
- Hız sınırı ve kaynak tüketimi
- Hassas iş akışlarının kötüye kullanımı
- İmzalı yetkilendirme belgesi ve kapsam dokümanı
- Kritik bulgu anında bildirilecek iletişim kanalı
- SOC/izleme ekibinin test tarihleri ve kaynak IP'lerden haberdar edilmesi
- Rol bazlı test hesapları ve temel mimari özeti
- Test ortamının canlıyla aynı sürüm ve yapılandırmada olduğunun teyidi
- Gerçek kişisel veri yerine maskelenmiş veya sentetik veri
- Her kullanıcı rolü için en az iki test hesabı
- Rol ve yetki matrisi (kim neyi görebilir)
- Kapsamdaki alan adı ve URL listesi
- OpenAPI/Swagger dokümanı veya istek koleksiyonu
- Farklı yetkilerde token veya API anahtarı
- Hız sınırı ve kota politikaları
Süreler örnek ve yol göstericidir; tek, orta ölçekli bir varlık varsayımıyla hesaplanır. Rol sayısı, uç nokta adedi, IP sayısı ve iş mantığının karmaşıklığı süreyi belirgin biçimde değiştirir. Kesin plan için kapsamınızı teklif formu üzerinden paylaşın.
Sızma testi süreci nasıl işler? 7 adımda pentest
Profesyonel bir sızma testi, PTES ve NIST SP 800-115 gibi çerçevelerde tanımlanan aşamaları izler. Adımların adları firmadan firmaya değişse de mantık aynıdır: önce izin ve sınırlar, sonra bilgi toplama, doğrulama, etkinin ölçülmesi ve son olarak düzeltmelerin doğrulanması. Bir adımı seçerek o aşamada ne yapıldığını ve size ne teslim edildiğini görün.
1.Kapsam ve yetkilendirme
Adım 1 / 7Test edilecek varlıklar, kapsam dışı sistemler, tarih ve saatler, test kaynak IP'leri ve acil durum iletişimi yazılı hale getirilir. Kurallar (rules of engagement) üzerinde uzlaşılır ve yetkilendirme belgesi imzalanır.
Çıktı: İmzalı yetki belgesi, kapsam dokümanı, iletişim planı
Pentest raporu nasıl okunur?
İyi bir pentest raporu iki farklı okura aynı anda hitap eder. Yönetim hangi risklerin işi tehdit ettiğini, ne kadar acil olduğunu ve genel güvenlik durumunu bir iki sayfada anlamak ister. Teknik ekip ise her bulguyu yeniden üretebilmek ve düzeltebilmek için kanıta, etkilenen bileşene ve somut çözüm adımına ihtiyaç duyar.
Raporu okurken önce yönetici özetine ve bulgu dağılımına bakın, sonra kritik ve yüksek bulguların her birinde şu soruyu sorun: "Bu bulguyu kim, ne zamana kadar kapatacak?" Raporu bir iş listesine çevirmeyen kurumlarda aynı bulguların bir sonraki yılın raporunda tekrar çıkması şaşırtıcı değildir.
- 1.Yönetici özetiYönetimGenel risk durumu, en kritik 3–5 bulgu ve iş etkisi, öncelikli aksiyonlar.
- 2.Kapsam ve metodolojiHerkesTest edilen varlıklar, tarihler, yaklaşım, kullanılan standartlar ve kapsam dışı bırakılanlar.
- 3.Bulgu özetiYönetim + BTÖnem derecelerine göre dağılım ve varlık bazında bulgu tablosu.
- 4.Detaylı bulgularTeknik ekipHer bulgu için açıklama, CVSS, kanıt, etki ve çözüm önerisi.
- 5.Olumlu gözlemlerHerkesİyi çalışan kontroller; güvenlik yatırımlarının doğru yere yapıldığının kanıtı.
- 6.EklerTeknik ekipAraç listesi, test kaynak IP'leri, ham çıktılar ve maskelenmiş kanıtlar.
Örnek rapor bulgu kartı anatomisi
Aşağıdaki kart kurgusal bir örnektir. Bir bölümün üzerine tıklayarak o alanın neden raporda bulunması gerektiğini görün.
Önem ve CVSS vektörü: Sayısal puan tek başına yetmez; vektör, puanın hangi varsayımlarla hesaplandığını gösterir ve başka bir uzmanın aynı sonucu doğrulamasını sağlar.
Sipariş detay servisinde nesne düzeyinde yetkilendirme eksikliği (IDOR / BOLA)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N- Etkilenen bileşen
- Müşteri paneli API'si · sipariş detay ve adres güncelleme uç noktaları (örnek)
- İş etkisi
- Oturum açmış herhangi bir müşteri, başka müşterilere ait sipariş, adres ve telefon bilgilerini görüntüleyip teslimat adresini değiştirebilir. Bu durum kişisel veri ihlali ve doğrudan müşteri mağduriyeti riski taşır.
- Kanıt
- A kullanıcısının oturumuyla B kullanıcısına ait bir sipariş numarası istendiğinde sunucunun B'nin kaydını döndürdüğü görüldü. İstek/yanıt kayıtları ve ekran görüntüleri Ek-2'dedir; kişisel veriler maskelenmiştir.
- Çözüm önerisi
- Her istekte kaydın oturumdaki kullanıcıya veya kiracıya ait olduğunu sunucu tarafında doğrulayın. Yetkilendirmeyi uç nokta bazında değil merkezi bir katmanda uygulayın. Tahmin edilmesi zor kimlikler tek başına koruma sayılmaz. Düzeltme sonrası doğrulama testi planlayın.
CVSS nedir? v3.1 ve v4.0 puanı nasıl okunur?
CVSS (Common Vulnerability Scoring System), bir zafiyetin teknik ciddiyetini 0.0 ile 10.0 arasında puanlayan açık bir standarttır ve FIRST tarafından yönetilir. Puanın gücü, bir vektör dizisiyle birlikte gelmesidir: vektör, saldırının ağ üzerinden mi yapıldığını, yetki gerektirip gerektirmediğini, kullanıcı etkileşimi isteyip istemediğini ve gizlilik, bütünlük, erişilebilirlik üzerindeki etkisini kısaltmalarla anlatır.
- Yok0.0
- Düşük0.1–3.9
- Orta4.0–6.9
- Yüksek7.0–8.9
- Kritik9.0–10.0
Raporlarda bugün hâlâ en yaygın sürüm CVSS v3.1'dir. Kasım 2023'te yayımlanan CVSS v4.0 ise temel metrikleri inceltti: "Scope" metriği kaldırıldı, yerine etkinin zafiyetli sistemde (VC/VI/VA) ve sonraki sistemlerde (SC/SI/SA) ayrı ayrı değerlendirilmesi geldi; saldırı gereksinimleri (AT) eklendi, kullanıcı etkileşimi "pasif" ve "aktif" olarak ayrıldı. Ayrıca puanın hangi metrik gruplarıyla hesaplandığını gösteren CVSS-B, CVSS-BT, CVSS-BE ve CVSS-BTE adlandırması getirildi.
En önemli uyarı şudur: CVSS risk değil, ciddiyet ölçer. FIRST da temel puanın tek başına risk değerlendirmesi olarak kullanılmaması gerektiğini vurgular. İnternete kapalı bir test sunucusundaki 9.8 puanlı bir açık, müşteri verisi tutan bir API'deki 6.5 puanlı yetkilendirme hatasından daha az acil olabilir. Bu yüzden iyi raporlar CVSS'in yanında bir de iş bağlamlı risk değerlendirmesi sunar.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:NAynı bulgunun v4.0 vektörü yukarıdaki gibidir. v4.0 puanı formülle değil, FIRST'ün yayımladığı resmi hesaplayıcı ve eşdeğerlik tablolarıyla hesaplanır; bu nedenle raporda puanla birlikte sürüm ve vektörün mutlaka yazılması gerekir.
Risk matrisi: bulguları iş riskine nasıl çevirirsiniz?
CVSS bir bulgunun teknik ağırlığını gösterir; hangi bulgunun önce kapatılacağına ise olasılık × etki değerlendirmesiyle karar verilir. Olasılık, açığın ne kadar kolay bulunup kullanılabileceğini (internetten mi, kimlik doğrulama gerekiyor mu, bilinen bir yöntem var mı) anlatır. Etki ise gerçekleşirse işinize ne olacağını: kişisel veri sızıntısı, finansal kayıp, hizmet kesintisi, itibar zararı.
Aşağıdaki gezginde bir hücre seçin; o hücreye düşebilecek örnek bir bulgu türünü, iş etkisini ve önerilen aksiyonu görün. Süreler örnek hedeflerdir; kendi risk iştahınıza ve sözleşmelerinize göre uyarlayın. Barındırma katmanındaki bulgular için sorumluluğun sizde mi sağlayıcıda mı olduğunu anlamak isterseniz web hosting, VPS, bulut ve dedicated sunucu farkları yazımız yardımcı olur.
- Kritik (20+)
- Yüksek (12+)
- Orta (6+)
- Düşük (1+)
Matris sadeleştirilmiş bir modeldir. Aynı bulgu türü, farklı bir sistemde farklı hücreye düşebilir; hücreyi belirleyen şey bulgunun adı değil, sizin ortamınızdaki olasılık ve etkidir.
OWASP Top 10:2025 haritası: web testinde nelere bakılır?
OWASP Top 10, web uygulamalarındaki en kritik risk kategorilerini listeleyen bir farkındalık belgesidir; bir test metodolojisi değil, ortak bir dildir. 2025 sürümünde erişim kontrolü birinci sırada kaldı, yazılım tedarik zinciri ve istisnai durumların hatalı yönetimi yeni kategori olarak eklendi. Web testlerinin ayrıntılı senaryoları ise OWASP WSTG'de bulunur; API'lerde OWASP API Security Top 10 ayrıca dikkate alınmalıdır. Kendi API'lerinizi tasarlarken bu kategorileri baştan hesaba katmak için API geliştirme sürecinde güvenlik gereksinimlerini netleştirin.
- A01Erişim kontrolü hatalarıBroken Access ControlTestte: Bir kullanıcı başkasının verisine veya yönetici işlevine ulaşabiliyor mu? (IDOR, yetki yükseltme)
- A02Güvenlik yapılandırma hatalarıSecurity MisconfigurationTestte: Varsayılan ayarlar, açık yönetim arayüzleri, gereksiz servisler, ayrıntılı hata mesajları.
- A03Yazılım tedarik zinciri hatalarıSoftware Supply Chain FailuresTestte: Bağımlılıklar, derleme hattı ve üçüncü taraf bileşenler güvenilir ve güncel mi?
- A04Kriptografik hatalarCryptographic FailuresTestte: Hassas veri aktarımda ve depoda yeterince korunuyor mu, zayıf algoritma var mı?
- A05EnjeksiyonInjectionTestte: Kullanıcı girdisi sorgu, komut veya sayfa içeriğine güvensiz biçimde karışıyor mu?
- A06Güvensiz tasarımInsecure DesignTestte: İş akışında kötüye kullanılabilecek bir mantık boşluğu var mı?
- A07Kimlik doğrulama hatalarıAuthentication FailuresTestte: Parola politikası, çok faktörlü doğrulama, oturum ve parola sıfırlama akışları.
- A08Yazılım veya veri bütünlüğü hatalarıSoftware or Data Integrity FailuresTestte: Güncellemeler, serileştirilmiş veriler ve kritik kararlar bütünlük kontrolünden geçiyor mu?
- A09Güvenlik kaydı ve alarm eksikliğiSecurity Logging & Alerting FailuresTestte: Saldırı denemeleri kayda geçiyor ve birine alarm olarak ulaşıyor mu?
- A10İstisnai durumların hatalı yönetimiMishandling of Exceptional ConditionsTestte: Beklenmeyen girdide sistem güvenli biçimde mi hata veriyor, yoksa "açık" mı kalıyor?
Sızma testi ne sıklıkla yapılmalı? KVKK ve standartlar ne diyor?
Tek bir doğru sıklık yoktur, ama yaygın kabul gören pratik şudur: kritik sistemler için yılda en az bir kez kapsamlı bir sızma testi ve her önemli değişiklikten sonra hedefli bir test. Sürekli değişen uygulamalarda bu yıllık test, sürekli zafiyet taraması ve geliştirme sürecine gömülü güvenlik kontrolleriyle desteklenmelidir.
- Yıllık periyotKritik uygulama ve altyapılar için en az yılda bir kapsamlı test.
- Büyük sürümYeni ödeme akışı, üyelik sistemi veya yetki modeli değişikliği.
- Yeni dış servisİnternete açılan yeni bir API, panel veya uzak erişim çözümü.
- Altyapı taşımaBuluta geçiş, veri merkezi değişikliği, yeni ağ mimarisi.
- Güvenlik olayıBir ihlal veya ciddi şüphe sonrası, düzeltmelerin etkinliğini görmek için.
- Müşteri / denetim talebiKurumsal müşteri sözleşmeleri veya sertifikasyon denetimleri.
6698 sayılı Kanun'un 12. maddesi, veri sorumlusuna kişisel verilerin güvenliği için "uygun güvenlik düzeyini" sağlayacak teknik ve idari tedbirleri alma yükümlülüğü getirir. Kişisel Verileri Koruma Kurulu'nun yayımladığı Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler), sızma testini bu teknik tedbirler arasında sayar. Kanun metni belirli bir test sıklığı öngörmez; ancak düzenli testler, uygun tedbirlerin alındığını göstermenin güçlü bir yoludur.
Kart verisi işleyen kurumlar için PCI DSS v4.x, iç ve dış sızma testlerinin periyodik olarak (en az yılda bir) ve önemli altyapı veya uygulama değişikliklerinden sonra yapılmasını, ağ ayrımı kullanılıyorsa bunun da test edilmesini ister.
Standart doğrudan "sızma testi yapın" demez, ama teknik zafiyetlerin yönetimi kontrolü kapsamında zafiyetlerin belirlenip değerlendirilmesini bekler. Sızma testi raporları bu kontrolün etkinliğine dair yaygın bir kanıttır.
Bankacılık, ödeme hizmetleri ve kamu gibi alanlarda ilgili otoritelerin düzenlemeleri, test kapsamı, sıklığı ve testi yapacak firmanın niteliklerine dair ek koşullar getirebilir. Kendi sektörünüzün güncel mevzuatını uyum ekibinizle doğrulayın.
Bir güvenlik testini seçerken yalnız teknik yetkinliğe değil, firmanın süreçlerine de bakın: yetkilendirme, gizlilik, raporlama kalitesi ve doğrulama testi. Bu kriterleri genel bir tedarikçi değerlendirmesiyle birlikte ele almak için yazılım firması seçerken dikkat edilmesi gerekenler rehberindeki güvenlik kriterinden yararlanabilirsiniz.
Sızma testi öncesi hazırlık kontrol listesi
Testin verimi büyük ölçüde hazırlığa bağlıdır. Test hesabı eksik diye kaybedilen bir gün, rapordaki derinliği doğrudan azaltır. Aşağıdaki listeyi işaretleyerek ilerleyin; tamamladığınızda metni kopyalayıp kendi proje dokümanınıza yapıştırabilirsiniz.
Yetkilendirme ve yasal izin: izinsiz test neden yapılmaz?
Sızma testini bir saldırıdan ayıran tek şey yazılı izindir. Kullanılan yöntemler benzer olabilir; fark, sistem sahibinin önceden onay vermesi ve sınırların belgelenmesidir. Türk Ceza Kanunu'nun bilişim suçlarına ilişkin hükümleri (ör. 243. madde, bilişim sistemine hukuka aykırı girme) iyi niyetli olsa bile izinsiz erişimi suç olarak tanımlar.
İzin, yalnızca sistemin gerçek sahibinden alınabilir. Kendi web sitenizin çalıştığı paylaşımlı sunucu, kullandığınız SaaS ürünü veya bulut sağlayıcısının altyapısı üzerinde test yapmak, ilgili sağlayıcının kurallarına tabidir. Bulut sağlayıcıların çoğu müşterilerin kendi kaynaklarını test etmesine belirli kurallarla izin verir, ama paylaşılan altyapıya yönelik testleri yasaklar. Altyapınızı bulut sunucu kiralama ile kendi kontrolünüzdeki ortamda çalıştırıyorsanız kapsamı tanımlamak çok daha kolaydır.
- Kapsam, tarih aralığı ve yöntemleri tanımlayan imzalı yetki belgesi
- Üçüncü taraf sistemleri için ilgili sağlayıcının kuralları veya onayı
- Kişisel verilere erişilirse nasıl davranılacağını belirleyen gizlilik şartları
- Kapsam dışına çıkıldığında veya beklenmeyen bir etki oluştuğunda testi durdurma prosedürü
Sızma testinde en sık yapılan hatalar
- Taramayı pentest sanmakOtomatik araç çıktısını kanıtsız bir liste olarak almak; zincirleme riskler ve iş mantığı hataları görünmez kalır.
- Kapsamı fazla daraltmakYalnız ana sayfayı test ettirip API'yi, mobil arka ucu veya yönetim panelini dışarıda bırakmak.
- Test hesabı vermemekBütçe gray box için ayrılmışken hesap vermeyerek testi fiilen black box'a çevirmek ve derinliği kaybetmek.
- Raporu çekmecede bırakmakBulguları sorumlu ve tarihle iş takip sistemine aktarmamak; aynı bulguların ertesi yıl tekrar çıkması.
- Doğrulama testini atlamakDüzeltmenin gerçekten işe yaradığını kanıtlamamak; kısmi düzeltmeler açık kapıyı aralık bırakır.
- Sadece CVSS'e göre sıralamakİş bağlamını göz ardı edip düşük erişilebilir sistemlerdeki yüksek puanlara zaman harcamak.
Sızma testinden gerçek değer almak için
Kapsamı net yazın, gray box ile derinlik kazanın, raporu bir iş listesine çevirin ve düzeltmeleri doğrulama testiyle kapatın. W3 güvenlik ekibi web, mobil, API ve altyapı testlerini yazılı yetkilendirme, kanıtlı raporlama ve doğrulama testiyle yürütür. Sihirbazda çıkardığınız kapsamı bize iletin; ihtiyacınıza uygun test planını birlikte netleştirelim.
Hangi test türüyle başlamanız gerektiğinden emin değilseniz iletişim sayfamızdan kısa bir ön görüşme isteyin; tamamlanan işlerimizin yaklaşımını görmek için projelerimize göz atabilirsiniz. Test sürecinin tamamı hakkında ayrıntı güvenlik ve sızma testi hizmeti sayfamızda.
Sık Sorulan Sorular
OSCP sertifikalı sızma testçisi. Hacettepe Bilgisayar Mühendisliği; web, ağ ve altyapı saldırı senaryolarında geniş pratik deneyim. Teknik bulgu ile iş riski arasındaki köprüyü kurar.
Profili gör