Travelport Vakası: 73 Bin Kişilik Veri İhlali Bir API Hatasıyla Nasıl Oluştu?
KVKK'nın 27 Ağustos 2026 tarihli Travelport veri ihlali duyurusunda 73.958 kişinin etkilenmiş olabileceği, rezervasyon ve seyahat bilgilerinin yetkisiz erişime konu olduğu açıklandı. Resmî duyuru teknik nedeni açıkça ViewTrip uygulamasındaki API yapılandırma hatası olarak tanımlamaktadır.
Kısa Cevap
KVKK’nın 27 Ağustos 2026 tarihli Travelport duyurusu teknik nedeni açıkça ViewTrip uygulamasındaki bir API yapılandırma hatası olarak tanımlıyor. Normalde kayda erişim için PNR numarası ile soyadının birlikte girilmesi gerekirken yalnız rezervasyon referansı kullanılarak kayıt görüntülenebiliyordu. Veri sorumlusu ihlalden 73.958 kişinin etkilendiğini bildirdi; bu rakam Türkiye’deki seyahat acentelerinin oluşturduğu PNR kayıtlarına dayanıyor ve Türkiye’de ikamet eden tekil kişi sayısını bire bir göstermiyor.
Neden Önemli?
Travelport vakası veri ihlallerinin her zaman karmaşık bir saldırı zincirinden doğmadığını gösteriyor. Resmî duyuruya göre sorun ViewTrip uygulamasındaki API yapılandırmasındaydı: kayıt görüntüleme sürecinde beklenen iki bilgi yerine yalnız rezervasyon referansı yeterli hale gelmişti. Bu durum kimliği belirlenemeyen üçüncü kişinin rezervasyonlarla ilgili sınırlı bilgiye erişmesine imkân verdi.
Potansiyel olarak etkilenen veri kategorileri yolcu adı, PNR bilgisi, referans numarası, uçuş, otel, araç ve demiryolu güzergâh bilgileriydi; bazı durumlarda iletişim bilgilerinin de etkilenmiş olabileceği bildirildi. Olay 6–7 Ağustos 2026 arasında gerçekleşti, 20 Ağustos’ta tespit edildi ve Kurul 26 Ağustos’ta 2026/1797 sayılı kararla kamuya ilan edilmesine karar verdi.
73.958 Sayısı Nasıl Okunmalı?
Duyurudaki 73.958 kişi sayısını “Türkiye’de yaşayan 73.958 tekil kişi” şeklinde yorumlamak doğru değildir. Kurum, hesabın Türkiye’deki seyahat acenteleri tarafından oluşturulan PNR kayıtlarına dayandığını; ikamet ülkesi alanının bulunmaması ve mükerrer rezervasyonların ayrılamaması nedeniyle Türkiye’de ikamet eden kişi sayısının daha düşük olmasının muhtemel olduğunu açıkça belirtiyor.
Bu Bir BOLA Vakası mı?
KVKK duyurusu olayı OWASP terminolojisiyle “BOLA” olarak sınıflandırmıyor. Ancak kullanıcıdan gelen bir rezervasyon referansı üzerinden başka bir kayda erişimin yeterince kısıtlanmaması, teknik güvenlik incelemesinde object-level authorization kontrollerinin değerlendirilmesini gerektiren bir senaryodur. OWASP da nesne kimliği alan API fonksiyonlarında kullanıcının ilgili nesneye gerçekten erişim yetkisinin doğrulanmasını öneriyor.
Şirketler Ne Yapmalı?
Travelport Vakasından Çıkan 9 Teknik ve KVKK Dersi
- API endpoint envanteri tutun. İnternet, mobil uygulama, partner ve legacy endpoint’leri aynı envanterde görün.
- Kimlik doğrulama ile yetkilendirmeyi ayırın. Kullanıcının bir bilgi bilmesi, o kayda erişme yetkisine sahip olduğunu otomatik olarak göstermemelidir.
- Object-level authorization testi yapın. Bir kullanıcının başka nesne ID veya referanslarını değiştirerek erişim sağlayamadığını negatif testlerle doğrulayın.
- Tahmin edilemez identifier’a tek başına güvenmeyin. Karmaşık veya rastgele rezervasyon referansı yetkilendirme kontrolünün yerine geçmez.
- Response minimization uygulayın. Endpoint yalnız işlev için gereken alanları döndürmelidir.
- Rate ve anomaly monitoring kurun. Çok sayıda farklı rezervasyon referansına erişim gibi olağan dışı davranışları tespit edin.
- Authorization regression testlerini CI/CD’ye bağlayın. Konfigürasyon değişikliği eski kontrolü devre dışı bırakmamalıdır.
- Logları incident evidence olarak tasarlayın. Hangi nesneye, hangi zamanda, hangi istemci üzerinden erişildiği sonradan analiz edilebilmelidir.
- KVKK incident sürecini teknik olayla bağlayın. Veri kategorisi, etkilenen kişi hesabı ve olay zaman çizelgesi doğrulanmış teknik bulguya dayanmalıdır.
Negatif Authorization Testi Nedir?
Normal fonksiyon testi “doğru rezervasyon referansıyla kayıt açılıyor mu?” sorusunu kontrol eder. Güvenlik testi ise “başka kullanıcıya ait referansla açılabiliyor mu?”, “soyadı eksik olduğunda ne oluyor?”, “aynı oturum çok sayıda kayda erişebiliyor mu?” gibi başarısız olması gereken senaryoları da test eder.
Özellikle konfigürasyon tabanlı erişim kurallarında bu negatif testlerin release pipeline içinde otomatik çalışması önemlidir. Böylece kod değişmese bile bir environment veya gateway ayarı erişim kontrolünü zayıflattığında release öncesinde sinyal üretilebilir.
B10 İçin Önerilen Ölçüm Modeli
| API Kontrolü | KPI | Risk |
|---|---|---|
| Inventory | Known endpoint coverage | Shadow / legacy API |
| Authorization | Negative auth test pass rate | Başka nesneye erişim |
| Response | Sensitive-field exposure count | Gereksiz veri |
| Detection | Abnormal object-access detection | Fark edilmeyen tarama |
| Logging | Object-access traceability | Eksik incident kanıtı |
| Release | Authorization regression coverage | Konfigürasyon regresyonu |
Bu göstergeler yalnız pentest sonucunu değil, API erişim kontrolünün ürün yaşam döngüsü boyunca ne kadar izlenebilir olduğunu ölçer.
Uzman Değerlendirmesi
Travelport vakasının en önemli dersi, authentication ve authorization kavramlarının birbirine karıştırılmamasıdır. Bir kullanıcının rezervasyon referansını bilmesi o rezervasyon kaydını görüntüleme yetkisine sahip olduğunu tek başına kanıtlamaz. API, her hassas nesne erişiminde ilgili erişim politikasını uygulamalıdır.
Ayrıca olayın teknik sınıflandırması yapılırken resmî duyuru ile güvenlik metodolojisi ayrılmalıdır. “API yapılandırma hatası” resmî olgu; object-level authorization/BOLA eşleştirmesi ise teknik risk analizidir.
Dijital Risk ve Uyum Analizi
B10, API envanteri, object-level authorization testleri, hassas response alanları, logging kapsamı ve KVKK incident evidence ihtiyaçlarını ortak bir Privacy & API Exposure Matrix üzerinde eşleştirebilir.
İlgili İçerikler
Resmî ve Birincil Kaynaklar
Sık Sorulan Sorular
Bu konu neden şimdi önemli?
KVKK'nın 27 Ağustos 2026 tarihli Travelport veri ihlali duyurusunda 73.958 kişinin etkilenmiş olabileceği, rezervasyon ve seyahat bilgilerinin yetkisiz erişime konu olduğu açıklandı. Resmî duyuru teknik nedeni açıkça ViewTrip uygulamasındaki API yapılandırma hatası olarak tanımlamaktadır.
Şirketler ilk olarak neyi kontrol etmeli?
Olayın kapsamını resmî duyurudan ayırmadan teknik kök neden varsayımı yapmayın.
Tek seferlik kontrol yeterli mi?
Evet. Bu vakada KVKK duyurusu teknik nedeni açıkça ViewTrip uygulamasındaki API yapılandırma hatası olarak ifade ediyor. Ancak “BOLA” gibi OWASP sınıflandırmaları Kurumun kullandığı resmî niteleme değil, teknik analiz çerçevesidir.
B10 bu konuda ne sağlayabilir?
B10; API endpoint envanteri, object-level access testleri, veri minimizasyonu, log izlenebilirliği ve incident evidence kontrollerini birlikte raporlayabilir.
