Giriş

Bu yazı, açık ve doğrulanabilir kamu belgelerine dayanmak yerine bağımsız değerlendirme yapmak isteyen kişiler ve ekipler için hazırlanmış bir rehberdir. Mevcut belgelerde sınırlı bilgiler bulunduğu için Dodo yazılımının kendisi doğrudan test edilmemiştir; amaç, bir tedarikçiyi veya ürünün bir kurulumunu değerlendirirken takip edilebilecek güvenlik, ödeme ve performans adımlarını pratik şekilde açıklamaktır.

Değerlendirme Çerçevesi: Üç Temel Alan

Yazılım değerlendirmesini üç ana başlık altında düzenlemek işleri kolaylaştırır:

• Güvenlik: Şifreleme, kimlik doğrulama, zaafiyet yönetimi ve izleme.
• Ödeme altyapısı: Ödeme akışları, sağlayıcı entegrasyonları, hata senaryoları ve mutabakat.
• Performans: Yükleme süreleri, API gecikmeleri, ölçeklenebilirlik ve süreklilik.

Güvenlik Protokolleri ve Kontroller

Değerlendirme yaparken aşağıdaki kontrolleri isteyin ve test edin. Aktif tarama veya penetrasyon testi yapmadan önce mutlaka ilgili yetkiyi alın; üretim ortamlarında izinsiz testler zarar verebilir.

• TLS ve sertifika yapılandırması: Sunucu sertifika zinciri, desteklenen TLS sürümleri ve şifre paketleri, HSTS politikası ve sertifika yenileme süreçleri gözden geçirilmeli. Bu kontroller için Qualys SSL Labs gibi araçlar kullanılabilir (https://www.ssllabs.com/ssltest/).
• Uygulama güvenliği: OWASP Top Ten başlıkları üzerinden giriş doğrulama, SQL enjeksiyonu, XSS ve yetkilendirme hataları kontrol edilmeli. Pasif tarama ve kontrollü DAST araçlarıyla (örneğin OWASP ZAP) test edilebilir (https://owasp.org/www-project-top-ten/).
• Bağımlılık ve tedarik zinciri: Üçüncü taraf kütüphaneler için bağımlılık taraması, bilinen CVE'lerin izlenmesi ve güncelleme politikası değerlendirilmelidir. OWASP Dependency-Check gibi araçlar referans olabilir (https://owasp.org/www-project-dependency-check/).
• Kimlik doğrulama ve oturum yönetimi: Parola politikaları, çok faktörlü doğrulama destekleri, güvenli cookie bayrakları, oturum zaman aşımı, token yenileme gibi uygulamalar incelenmeli.
• Güncelleme ve yama süreçleri: Yazılım ve altyapı yamalarının ne sıklıkta uygulandığı, kritik güvenlik açıklarına yanıt SLA'sı (örnek: kritik CVE'lere kaç gün içinde müdahale edildiği) talep edilmeli.
• İzleme, loglama ve olay müdahalesi: Logların merkezi toplanması, boru hattı (SIEM) entegrasyonu ve uyarı eşiği kontrolleri gözden geçirilmeli. Olay müdahale planı olup olmadığı sorulmalı.

Pratik Güvenlik Testleri (yetkili ortamda)

• Sertifika ve TLS testi: Bir hedef URL için SSL Labs raporu alın.
• Pasif DAST: OWASP ZAP ile ilk tarama yapılır; rapor üretip yüksek öncelikli bulgular not edilir.
• Bağımlılık taraması: CI/CD boru hattında otomatik SCA çalıştırılmasını talep edin.
• Yetki ve kimlik testi: Test kullanıcılarıyla rol tabanlı erişim kontrolleri doğrulanır.

Ödeme Altyapısı: Denetim Noktaları

Ödeme entegrasyonu denetiminde şu öğeler önceliklidir:

• Belgelendirme ve uyumluluk: Ödeme işleme ile ilgili olarak sağlayıcının veya entegrasyonun uygunluk belgeleri (örneğin ilgili uyumluluk süreçlerine ait doğrulamalar) talep edilmeli. Resmi standartlar için referans: https://www.pcisecuritystandards.org/.
• Tokenizasyon ve veri saklama: Kart verileri sunucu tarafında saklanıyorsa tokenizasyon, şifreleme ve erişim kısıtları incelenmeli.
• 3D Secure ve kimlik doğrulama: Yetki gerektiren akışlarda 3D Secure veya benzeri kimlik doğrulama akışları desteklenmeli; bu akışların son kullanıcı deneyimi de test edilmelidir.
• Webhook ve callback güvenliği: Webhook imzalama, nonce veya timestamp kontrolü ve idempotent işlem işaretleri olmalı.
• Hata ve geri dönüş senaryoları: Başarısız işlemler, ağ kesintileri, duplicate istekler ve iade/chargeback gibi senaryoların nasıl işlendiği test edilmeli.

Ödeme Testleri: Örnek Senaryolar

1. Sandbox ortamında başarılı ödeme akışı test edin (authorization → capture).
2. 3D Secure doğrulama adımını tetikleyin ve kullanıcı deneyimini değerlendirin.
3. İade ve kısmi iade süreçlerini çalıştırın ve mutabakat kayıtlarını kontrol edin.
4. Webhooks için imzalama doğrulaması ve tekrar eden bildirim senaryolarını simüle edin.

Yükleme Süresi ve Performans Ölçümleri

Performans değerlendirmesinde hem son kullanıcı deneyimi (frontend) hem de API/altyapı performansı ölçülmelidir:

• Temel metrikler: TTFB (Time to First Byte), FCP (First Contentful Paint), LCP (Largest Contentful Paint), TTI (Time to Interactive), p95/p99 API gecikmeleri ve hata oranları izlenmeli.
• Araçlar: Lighthouse (https://developers.google.com/web/tools/lighthouse), WebPageTest (https://www.webpagetest.org/) ve RUM/izleme çözümleri tercih edilebilir.
• Ölçek testi: Yük testi için k6 (https://k6.io/), JMeter veya wrk gibi araçlarla artan yük senaryoları çalıştırılmalı. Testler; ramp-up, plateau ve soak dönemlerini içermeli.
• Optimizasyon alanları: CDN kullanımı, cache politikaları, sıkıştırma (Brotli/Gzip), resim optimizasyonu, HTTP/2 veya HTTP/3 desteği ve veritabanı sorgu optimizasyonu gözden geçirilmeli.

Performans Test Planı (kısa)

1. Baseline ölçümü: Tipik trafik altında ortalama ve p95 gecikmeler kaydedilir.
2. Stres testi: Artan eş zamanlı kullanıcı ile uygulama sınırları tespit edilir.
3. Soak testi: Uzun süreli ortalama yük altında bellek sızıntısı, kaynak tüketimi incelenir.
4. Sonuç değerlendirme: Kritik noktalar belirlendikten sonra önceliklendirilmiş iyileştirme listesi hazırlanır.

Denetim ve Uygulama Adımları (Adım Adım)

1. Doküman talebi: Mimari diyagram, veri akış çizimleri, üçüncü taraf raporlar ve SLA'lar isteyin.
2. Test ortamı: Üretimi etkilemeyecek staging/sandbox ortamı ve test hesapları talep edin.
3. Otomatik taramalar: CI/CD hattına SCA ve SAST eklenmesini isteyin.
4. Kontrollü DAST ve yük testleri: Yetkiyle gerçekleştirilecek güvenlik ve performans testleri planlayın.
5. Raporlama: Bulunan açıkların etkisi ve çözüm önerileriyle birlikte bir rapor hazırlanmalı; kritikler için acil düzeltme planı oluşturulmalı.

Raporlama ve Karar Verme

Test sonuçlarını risk matrisine oturtun: kritik, yüksek, orta, düşük. Kritik bulgular için üretimi etkileyebilecek açıklar listesine hızlı müdahale planı ekleyin. Karar verirken aşağıdaki belgeler yardımcı olur: mimari diyagram, günlük/izleme örnekleri, üçüncü taraf denetim raporları ve yama geçmişi.

Sonuç

Bu rehber, Dodo yazılımının doğrudan test edilmemiş olduğu sınırlılığını göz önünde bulundurarak, bir tedarikçi veya kurulum değerlendirmesi yaparken takip edilebilecek pratik kontrolleri, test planlarını ve önceliklendirme adımlarını sundu. En sağlıklı sonuçlar, tedarikçiden talep edeceğiniz teknik belgeler ve yetkili testlerle elde edilir. Kritik güvenlik veya uyumluluk gereksinimleri varsa bağımsız üçüncü taraf denetimi önerilir.

Not: Aktif güvenlik testleri her zaman yetki gerektirir; üretim altyapısında izinsiz test yapmak sistem çalışmasını etkileyebilir. Aynı şekilde ödeme testleri için sağlayıcıların sandbox ortamları kullanılmalıdır.