TSE TS 13638’e Göre Test Öncesi Kapsam ve Yetkilendirme
Uzmanlar güvenlik testi dediğinde akla genellikle teknik araçlar, zafiyet taramaları ve penetrasyon senaryoları gelir. Bir testin kalitesi ise test başlamadan önce ekibin ne kadar sağlam bir zemin hazırladığıyla doğrudan bağlantılıdır. Test öncesi kapsam ve yetkilendirme aşaması, pek çok profesyonelin önemsiz saydığı ama aslında ekiplerin tüm süreci üzerine inşa ettiği temeldir.
Bu aşamayı atlamak ya da yüzeysel geçmek ciddi sonuçlar doğurur. Hukuki riskler, kapsam dışı kalan kritik sistemler ve yanlış anlaşılmalardan kaynaklanan şikayetlerlerin başında gelir. TSE TS 13638, bu riskleri en aza indirmek için test öncesi süreci açıkça tanımlar ve belgeleme gerekliliklerini standartlaştırır.
- Güvenlik testlerinde hukuki ve teknik riskleri önlemenin temeli yazılı kapsam ve yetkilendirme belgeleridir.
- Yetkisiz testler Türk Ceza Kanunu kapsamında suç teşkil eder; yasal temsilci onaylı yetki belgesi zorunludur.
- Taraflar KVKK uyumu ve kişisel verilerin korunmasını test öncesinde sözleşmesel olarak garanti altına almalıdır.
Kapsam Neden Bu Kadar Önemli?
Güvenlik testinde kapsam, neyi test edeceğini ve daha önemlisi neyi test etmeyeceğini belirler. Bu sınırlar olmadan test ekibi nelerin dahil olduğunu bilemez; müşteri ise hangi sistemleri koruduğunu bilemez.
Yanlış tanımlanmış bir kapsam iki farklı soruna yol açar. Birincisi, kritik sistemlerin test dışı kalmasıdır. İkincisi ise test ekibinin yetkisiz bölgelere yaptığı işlemlerin hukuki soruna dönüşmesidir. Bu nedenle TSE TS 13638, kapsam belirlemeyi sürecin başına alır ve bunu yazılı belgelerle desteklemeyi zorunlu kılar. Söz konusu belge test ekibine ve müşteriye ortak bir referans noktası sunar.
Kapsam yalnızca teknik bir kavram değildir. İş süreçleri, veri akışları ve organizasyon yapısı da kapsamı belirleme sürecine doğrudan etki eder. Taraflar kapsam belirleme toplantılarına hem teknik hem de iş birimi temsilcilerini dahil eder.
Kapsam Belgesi Nasıl Oluşturulur?
Kapsam belgesi, ekibin test edeceği sistemleri, URL’leri, IP aralıklarını, API uç noktalarını ve uygulamaları listeler. Belirsizliğe yer bırakmaz. Ekip her maddeyi yazılı ve ölçülebilir biçimde tanımlar.
Öncelikle ekipler test edecekleri ortamın türünü belirler. Üretim ortamı mı, test ortamı mı, yoksa her ikisi birden mi? Bu sorunun yanıtı hem test yaklaşımını hem de risk düzeyini şekillendirir. Örneğin, ekibin üretim ortamında yaptığı testler gerçek kullanıcılara ve canlı verilere doğrudan etki edebilir. Canlı veriyle çalışmak ek bir sorumluluk gerektirir. Bu yüzden üretim testleri ayrı bir onay mekanizması gerektirir.
Bunun yanı sıra, kapsam belgesi sistemlerin bulunduğu altyapıyı da içerir. Bulut tabanlı bir sistem mi, yoksa şirket içi bir sunucu altyapısı mı? Bu bilgi, ekibin testi nasıl yürüteceğini ve hangi erişim yöntemlerini kullanacağını doğrudan şekillendirir.
Ayrıca ekipler, üçüncü taraf hizmetlerin kapsama girip girmeyeceğini de açıkça belirtir. Bir uygulamanın kullandığı ödeme servisi veya kimlik doğrulama sağlayıcısı kapsam dışında kalıyorsa taraflar bunu yazılı olarak kayıt altına alır. Test ekibi bu hizmetlerin güvenlik yapılarının kapsam dışında kaldığını müşteriye açıkça hatırlatır.
| Ortam Türü | Avantajı | Risk Düzeyi | TSE TS 13638 Gereksinimi |
|---|---|---|---|
| Üretim (Live) Ortamı | Gerçek konfigürasyonu ve canlı veri akışını yansıtır. | Yüksek (Canlı servis kesintisi riski) | Özel yazılı onay ve acil durdurma prosedürü |
| Test / Staging Ortamı | Kesintisiz ve agresif test senaryolarına imkan tanır. | Düşük (Canlı kullanıcı etkilenmez) | Üretim ile birebir mimari eşleşme doğrulaması |
| Bulut / 3. Taraf Altyapı | Esnek erişim ve genişleme imkanı sunar. | Orta (Saas/IaaS tedarikçi kısıtları) | Sağlayıcı izin belgesi & kapsam dışı bildirimi |
Kapsam Dışı Alanlar
Ekiplerin kapsam belirlerken en çok atladığı nokta, kapsam dışı alanları yazılı olarak tanımlamaktır. Bu alan, kapsam içi bölümler kadar kritik bir öneme sahiptir.
Pratikte ekipler bu bölümü çoğu zaman boş bırakır ya da standart bir madde listesiyle geçiştirir. Test sırasında ekibin kapsam dışı bir sisteme erişmesi hem teknik hem de hukuki sorunlar yaratır. Bu tür durumlar hem sözleşmesel hem de yasal yaptırımları devreye sokabilir. Standart bu nedenle kapsam dışı alanlara yönelik açık gerekçeler sunmayı zorunlu tutar.
Ekip, kapsam dışı sistemlerin erişim kontrollerini de inceleme altına alır. Taraflar test ekibinin bu sistemlere teknik erişimini netleştirir. Böylece olası bir yanlış adreslemede sorumluluk tartışmaları ortadan kalkar.
Yetki Belgesi
Yetkilendirme, güvenlik testinin belki de en kritik unsurlarından biridir. Ekiplerin yetkisiz yaptığı teknik açıdan kusursuz bir test bile ciddi hukuki sonuçlar doğurur.
Pek çok ülke yetkisiz sistem taraması ve sızma testi girişimini suç kapsamında değerlendirir. Türkiye’de de Türk Ceza Kanunu bu tür eylemleri kapsar. Ekiplerin TSE TS 13638 kapsamında yürüttüğü testler yazılı yetki belgesini zorunlu kılar.
Yetki belgesi tek bir imzadan ibaret değildir. Zira belge; test edilecek sistemlerin listesini, test tarih aralığını, test ekibinin kimlik bilgilerini, kullanılacak yöntemleri ve müşterinin yetkili temsilcisinin imzasını içerir. Bu doküman aynı zamanda testin hukuki zeminini oluşturur.
Yetki belgesi ayrıca test ekibinin hangi IP adreslerinden test gerçekleştireceğini de açıkça belirtir. Güvenlik duvarı ve izleme sistemleri bu sayede teste özgü trafiği engellemez. Ekipler test süresince kurumun güvenlik operasyon merkezini de önceden bilgilendirir. Ekip bu bilgilendirmeyi yapmadığında gerçek bir saldırı ile test trafiği birbirine karışır.
Yetki Belgesinde Bulunması Gereken Asgari Bileşenler
- Test Edilecek Sistemler: Tam IP adresleri, URL’ler ve API uç noktaları listesi.
- Zaman Aralığı ve Saatler: Testin başlayacağı ve biteceği kesin tarih ve saatler.
- Kaynak IP Adresleri: Test ekibinin trafiği başlatacağı sabit IP adresleri.
- Yasal Temsilci İmzası: Kurum adına imza atmaya yetkili kişinin ıslak/elektronik imzası.
- SOC Bilgilendirmesi: Güvenlik Operasyon Merkezi irtibat detayları ve kural istisnaları.
Yasal Zemin ve Veri Güvenliği
Yetki belgesinin ötesinde taraflar, test sürecinde karşılaşabilecekleri kişisel verilerin işleme esaslarını önceden belirler.
Özellikle Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında kişisel veri barındıran sistemleri test etmek ek yasal yükümlülükler doğurur. Test sırasında kişisel verilere erişim durumunda taraflar; erişim sınırlarını, kayıt esaslarını ve test bitimindeki imha prosedürünü netleştirir.
Bazı sektörler güvenlik testleri için ek düzenleyici onay gerektirir. Bankacılık sektöründe BDDK’nın belirlediği çerçeve, sağlık sektöründe ise Sağlık Bakanlığı’nın düzenlemeleri bu duruma örnek oluşturur. Bu nedenle ekipler sektöre özgü yükümlülükleri kapsam ve yetkilendirme aşamasında gözden geçirir. Ekipler söz konusu adımı zaman zaman göz ardı etse de bu konu hukuki açıdan büyük önem taşır.
Taraflar gizlilik anlaşmalarını da bu süreçte imzalar. Test ekibi, testi sırasında öğrendiği tüm bilgileri gizli tutmakla yükümlüdür. Sözleşme, raporlama sürecinde ekibin bilgileri kiminle paylaşacağını açıkça tanımlar.
Test Ortamı Hazırlığı
Ekipler kapsam ve yetkilendirme belgelerini tamamladıktan sonra teknik hazırlık aşamasına geçer. Kötü hazırlanmış bir ortam tüm test sürecini sekteye uğratabilir. Pek çok ekip bu aşamayı sıklıkla göz ardı eder. Hazırlık eksikliği genellikle sürecin tam ortasında ortaya çıkar.
İlk olarak, test ekibi farklı yetki seviyelerini temsil eden hesaplar oluşturur. Ekip; standart kullanıcı, yönetici ve misafir rollerini ayrı ayrı tanımlar. Böylece ekip farklı senaryoları gerçekçi koşullarda test edebilir.
İkinci olarak ekip, test ortamının üretim ortamıyla örtüşme düzeyini belirler. Test ortamı üretimden farklıysa ekip bu farklılıkların güvenlik açısından ne anlam ifade ettiğini değerlendirir. Staging ortamında kapanan bir açık üretimde hâlâ açık kalabilir. Ekipler bu durumu çoğu zaman göz önünde bulundurmaz. Farkları bu yüzden detaylıca belgelerler.
Üçüncü olarak ekipler yedekleme ve geri yükleme planlarını gözden geçirir. Testler sırasında bir sistem beklenmedik biçimde zarar görebilir. Bu ihtimal ne kadar küçük görünse de önceden kurtarma planı hazırlamak standardın temel beklentisidir.
İletişim Kanalları
Tarafların test sürecinde iletişim kanallarını net tanımlaması küçük ama kritik bir ayrıntıdır. Kimler kiminle iletişim kuracak? Taraflar olası acil bir durumda hangi prosedürün devreye gireceğini de önceden netleştirmelidir.
Standart bu doğrultuda bir iletişim matrisi oluşturmayı öngörür. Matris; test ekibinin irtibat kişilerini, müşteri tarafındaki teknik sorumluyu ve üst düzey onay mercilerini içerir. Taraflar her satır için bir yedek iletişim kişisi de belirler. Ayrıca ekipler acil iletişim için ayrı bir prosedür oluşturur. Prosedür test sözleşmesinin ekinde yer alır.
Öte yandan, canlı bir sistemin çökmesi veya veri sızıntısı durumunda kimin ne yapacağını taraflar önceden belirler. Bu hazırlık sayesinde taraflar panik anında zaman kaybetmez. Böylelikle hem müşteri hem de test ekibi aynı sayfada yer alır.
Kapsam Değişikliği
Test başladıktan sonra kapsam değişikliği talebi ekiplerin beklediğinden daha sık gelir. Müşteri yeni bir sistem eklemek isteyebilir ya da ekibin test sırasında gözden kaçırdığı bir kritik bileşen ortaya çıkabilir. Her iki durumda da taraflar süreci aynı disiplinle yönetir.
Kapsam değişikliği her koşulda ekiplerin tanımladığı bir prosedürü takip etmelidir. Taraflar kapsamı sözlü olarak genişletmeyi hiçbir zaman kabul etmez. Aksine taraflar her değişikliği yazılı olarak belgeler ve yeni bir yetki belgesiyle onaylar. Taraflar kapsamı daralttığı durumda da aynı kural geçerliliğini korur.
Hem test ekibi hem de müşteri ekibin neyi test edip neyi test etmediğini her an net biçimde bilebilir. Kapsam belirsizliği ortadan kalkar. Tarafların anlaşmazlık durumunda referans alacağı belgeler eksiksiz kalır.
Sık Yapılan Hatalar
Kapsam ve yetkilendirme aşamasında bazı hatalar tekrar tekrar karşımıza çıkar.
Öncelikle, ekiplerin kapsamı çok genel tutması yaygın bir sorundur. “Tüm web uygulamaları” veya “tüm sistemler” gibi ifadeler belirsizlik yaratır. Bunun yerine ekipler her sistemi bağımsız olarak listeler ve tanımlar. Bu basit adım pek çok karışıklığı önler.
Ayrıca yetkisiz bir kişinin yetki belgesini imzalaması ciddi bir sorun oluşturabilir. IT yöneticisinin imzası hukuki açıdan yetki sağlamayabilir. Bu doğrultuda standart, organizasyonun yasal temsilcisinin belgeyi imzalamasını şart koşar. Aksi durumda test belgesi yasal geçerlilik taşımayabilir.
Öte yandan, test tarihlerini yeterince düşünmeden belirlemek de ekiplerin sık yaptığı bir hatadır. Hafta sonu, tatil dönemi ya da yoğun kampanya sürecindeki bir test beklenmedik sonuçlar doğurabilir. Doğru bir zaman planlaması bu riskleri büyük ölçüde ortadan kaldırır. Zaman planlaması için müşteriyle birlikte çalışmak en sağlıklı yaklaşımdır.
Son olarak, ekiplerin kapsam belgesini test bittikten sonra arşivlememesi ciddi bir eksikliktir. Bu belge raf köşesinde kalmamalıdır. Oysa bu belge test raporunun ayrılmaz bir ekidir ve ilerideki tekrar testlerde referans görevi görür.
| Sık Yapılan Hata | Olası Sonucu | TSE TS 13638 Uyumlu Çözüm |
|---|---|---|
| Genel ve muğlak kapsam tanımı (“Tüm sistemler”) | Kritik sistemlerin atlanması veya yanlış testler | IP, URL ve API bazında detaylı envanter listesi |
| Yetkisiz personel imzası (IT Uzmanı imzası) | Testin hukuki açıdan geçersiz sayılması | Şirket imza sirkülerine sahip yasal temsilci onayı |
| Sözlü kapsam değişikliği talepleri | Sorumluluk karmaşası ve hukuki anlaşmazlıklar | Yazılı ek protokol ve güncel yetki belgesi |
Sonuç
Test öncesi kapsam ve yetkilendirme aşaması, teknik yetkinlikle eşdeğer bir öneme sahiptir. En iyi test ekibi bile müşteriyle kötü belgelediği bir kapsamla çalışırsa sonuçlar güvenilmez olur.
Kısacası, TSE TS 13638 bu aşamayı standartlaştırarak hem test ekiplerine hem de kurumlara net bir çerçeve sunar. Bu çerçeveye uymak, güvenlik testini bir formalite olmaktan çıkarır ve gerçek bir güvenlik iyileştirme sürecine dönüştürür.
Sonuç olarak, iyi bir test öncesi hazırlık yalnızca riski azaltmaz. Test sürecinin her aşaması daha verimli hale gelir. Belgeleme alışkanlığı bir kültür meselesidir ve bu kültürü kurumlar içinde yaygınlaştırmak uzun vadeli güvenlik başarısının temel koşuludur.
Sık Sorulan Sorular
TSE TS 13638 kapsam belirleme aşamasında neleri zorunlu kılar?
TSE TS 13638, ekiplerin test edeceği ve etmeyeceği tüm sistemleri, IP aralıklarını, URL’leri ve uygulamaları yazılı olarak ve ölçülebilir detayda belgelemesini zorunlu kılar.
Sızma testi yetki belgesini kim imzalamalıdır?
Kurum adına yasal sorumluluk ve imza yetkisi bulunan yasal temsilciler (Şirket Müdürü, CEO veya Yetkili Yönetici) yetki belgesini imzalamalıdır. IT teknik personelinin imzası hukuki açıdan yetersiz kalabilir.
Ekipler test sırasında kişisel verilerle (KVKK) karşılaşırsa ne yapmalıdır?
Taraflar kişisel verileri kaydetmemeyi, erişimi sınırlandırmayı ve geçici verileri imha etmeyi sözleşmede protokole bağlar.
Test devam ederken yeni bir sistem kapsama eklenebilir mi?
Taraflar sözlü taleplerle kapsamı genişletemez. Kapsam değişikliği için yazılı bir ek protokol hazırlamalı ve güncellenmiş yetki belgesini yeniden imzalamalıdır.