API Gateway Olmadan Güvenlik Olmaz: API Altyapısında Doğru Sıralama Rehberi

37 Milyon Müşteri Kaybı, 41 Gün Görünmez Saldırı: T-Mobile Vakasından API Security'ye Yeniden Bakmak

Ocak 2023. T-Mobile, 37 milyon müşteri hesabını etkileyen bir API veri ihlali açıkladı. Saldırgan, 25 Kasım 2022'de bir API'yi "yetkisiz" kullanmaya başlamıştı. 41 gün boyunca kimse fark etmedi. İsim, adres, telefon, e-posta, doğum tarihi... Her şey sızdı.

Peki bu nasıl oldu? Cevap basit ama acı: Varlığını bilmedikleri bir API'yı koruyamazdılar.

Salt Security'nin analizi net: Bu bir "Shadow API" vakasıydı. Güvenlik ekipleri bu API'nın varlığından, işlediği verilerden ve güvenlik duruşundan habersizdi. API yönetim ve güvenlik programının görüş alanı dışındaydı.

Ve bu T-Mobile'ın 8. ihlaliydi. 2018'den beri. 2021'deki bir ihlal için $350 milyon ödeme yapmayı kabul etmişlerdi.

Ama asıl soru şu: T-Mobile'ın API Security ürünü yok muydu? Muhtemelen vardı. Peki neden işe yaramadı?

---

Sahadan Gerçekler: "API Security Ürünü Almalı mıyız?"

Özellikle son birkaç ayda birçok banka, kamu kurumu ve savunma sanayindeki müşterilerimizin, başta güvenlik ekipleri olmak üzere, alt yapı, sistem mimarları, servis yöneticiler, kurumsal mimarlar ile yaptığım görüşmelerde ortak bir pattern gördüm. Hepsinin aynı sorusu: "Bir API Security ürünü almalı mıyız?"

Anlattıklarına göre, bir çok sunumlar dinledik, PoC'ler yapıldı, ama hala kafamızdaki bir sorulara cevap bulamadık. Her API Security vendor'ı farklı şeyler anlatıyor, hangisi doğru anlayamıyoruz. Bazıları davranış analizi yapıyor, bazıları API Discovery yapıyor, bazıları makine öğrenmesi ile tehdit tespiti vaat ediyor, bazıları "full visibility" diyor ama nasıl sağladıklarını gerçek senaryolar üzerinden hiç birini detaylı açıklamıyorlar (ya da açıklayamıyorlar). Hatta bazıları işi abartıp biz problemleri havada yakalıyoruz (bir müşterimize aynen böyle demişler).

Her toplantıda aynı soruyu sordum: "API Security deyince ne anlıyorsunuz ve ne bekliyorsunuz?". Bu soruyu sadece aktif müşterilerimize değil sunumda tanışdığımız uzman arkadaşlarla konu güvenlik kısmına geldiğinde de sordum.

İşin detayına indiğimizde, asıl ihtiyaçları şuydu:

• Kurum içinde dışa sunulan ve dışarıdan tüketilen tüm API'ları bilmek. (Son zamanlarda internal API'ların da envanterine hakim olmak istiyorlar)
• API envanterine hakim olmak
• Her API'nin sahibinin ve sorumlusunun kim olduğunu bilmek (ya da sorun çıkınca kim suçlu onu bilelim)

API Security ürünlerinin sunmuş olduğu davranış analizi ve tehdit tespiti yetenekleri? İkinci, hatta üçüncü aşamada istedikleri bir şey, yani pastanın üzerindeki çilek.

Cevap hep aynı: Envantere hakim olmak, en öncelikli konu bu.

T-Mobile vakası tam da bunu gösteriyor: Envanter olmadan, 41 gün boyunca saldırı görünmez kalır.

Sahi, T-Mobile'da Tam Olarak Ne Oldu?

T-Mobile vakasında 41 gün boyunca saldırı tespit edilemedi çünkü:

• API merkezi yönetim dışındaydı (shadow API)
• Gateway üzerinden geçmiyordu
• Görünürlük yoktu
• Behavioral baseline oluşturulmamıştı
• Anomali tespiti çalışmıyordu

Sonuç: API Security ürünü bu API'nin varlığından bile haberdar değildi. Nasıl korusun?

"Bir API Gateway üzerinden geçmeyen trafiği, hiçbir API Security ürünü göremez. Göremediğini koruyamaz. Shadow API'ler için hiçbir işe yaramaz."

Bu yüzden sıralama kritik:

1. Önce Gateway → Tüm trafik merkezi noktadan geçsin
2. Sonra Management → Envanter oluşsun, sahiplik belirlensin
3. En son Security → Şimdi koruma anlamlı

Aksi takdirde, çok pahalı bir API Security ürünü alırsınız ama T-Mobile gibi 41 gün boyunca saldırıyı göremezsiniz.

---

Acı Gerçek: API Security Ürünleri Nasıl Çalışır?

Burada çok kritik bir noktayı anlamak gerekiyor. API Security ürünleri kör değildir, ama görmeleri için göz lazımdır.

API Security ürünleri şunlara ihtiyaç duyar:

• API Gateway veya WAF trafiğini izleyerek çalışır
• HTTP request-response çiftlerini analiz eder
• Normal davranış patternleri öğrenir
• Anomalileri tespit eder

Eğer merkezi bir trafik noktanız yoksa, güvenlik ürünü kör kalır.

Bu ürünler şunları yapmak için tam görünürlük gerektirir:

• API Discovery (hangi API'lar var?)
• Behavioral Analysis (normal davranış nedir?)
• Anomaly Detection (sapma nerede?)
• Shadow API Detection (kayıt dışı API'lar nerede?)
• Threat Intelligence (saldırı pattern'leri neler?)

---

SOA Hikayesi Tekrar mı Ediliyor?

Bu durumu gördüğümde, yıllarca SOA tarafında yaşadığım deneyimler aklıma geldi.

O zaman herkes SOA'yı konuşuyordu. Global vendor'lar SOA adı altında ürünler satıyordu. Enterprise Service Bus (ESB) ürünleri, SOA governance platformları, service registry'ler... Milyonlarca dolar harcandı.

Günün sonunda maalesef o ürünlerle yapılan projelerin çoğu fail oldu. Devam edenler de bir şekilde çalıştığı için kimse dokunmaya korktuğundan duruyor.

Neden başarısız oldu?

Çünkü sadece ürüne güvenip "ürün ile her şey çözülür" dediler. Global ürün satıcıları ellerindeki ürünleri SOA diye çok güzel pazarladılar. Satış sunumları harikaydı. Demo'lar etkileyiciydi.

Ama unutulan gerçek şuydu:

SOA (Service-Oriented Architecture) bir ürün değil, bir Mimari yaklaşım (Architectural Approach) veya felsefi paradigmadır.
SOA bir ürün değil, sistemleri tasarlamak için mimari bir yaklaşımdır.

Lego'nun parçaları gibi, sizin kurmanız gerekir. Önce mimari prensipleri anlamanız, sonra governance modelinizi oluşturmanız, ardından altyapınızı adım adım inşa etmeniz gerekir.

Ürün satın almak, bir SOA mimari yaklaşımına sahip olmak demek değildi.

Şimdi aynı film API Security alanında mı tekrarlanıyor?

Birçok kurum şu mantıkla hareket ediyor:

• "Hemen bir API Security ürünü alalım, güvenlik öncelikli"
• "Gateway'i sonra düşünürüz"
• "Envanter yavaş yavaş çıkar" Yani; Kervan yolda düzülür. (Teknik olmayan konular için iyi bir yaklaşım olabilir ama Teknik mimari konularında maalesef felaket ile sonuçlanır.)

Bu tam tersi bir yaklaşım. SOA'da ESB alıp "artık SOA'mız var" demek gibi bir şey.

Sonuç aynı olur: Para harcanır, beklentiler karşılanmaz, shadow API'ler hala görünmez kalır, proje rafa kalkar.

Peki Ya Veriler?

Sadece sahadan gözlemler değil, veriler de aynı gerçeği işaret ediyor:

Gartner 2024 Market Guide for API Protection:

"Shadow ve dormant API'lar, diğer ihlallerden ortalama olarak daha büyük veri sızıntılarına neden oluyor."

Salt Security ve LevelBlue Araştırması (2024):

"Organizasyonların %94'ü geçen yıl production API'larında güvenlik sorunu yaşadı. Birçok işletme API envanteri konusunda sınırlı görünürlüğe sahip."

Dark Reading (Kasım 2024):

"Organizasyonlar için en acil sorun, tüm external API'ların envanterinin olmaması. Saldırganlar bu açığı istismar ediyor."

OWASP API Security Top 10:

"#9 Improper Inventory Management: API varlıklarının yetersiz yönetimi. Tüm API'ların farkında olmama, güvenlik açıklarına yol açıyor."

Pattern açık: Gateway ve envanter olmadan API Security ürünleri kör kalır.

---

BÖLÜM 2: T-Mobile Vakası - Derin Dalış

41 Gün: Bir API İhlalin Anatomisi

T-Mobile vakası, API güvenliğinde "teorik risk"lerin nasıl gerçek felakete dönüştüğünü gösteren mükemmel bir vaka çalışması. Gelin kronolojik olarak ne olduğuna bakalım:

25 Kasım 2022 - Sıfır Günü: Saldırgan, T-Mobile'ın API'larından birine yetkisiz erişim sağladı. Ancak bu sıradan bir API değildi. Bu bir "Shadow API" idi - sistemde kayıtlı olmayan, dokümante edilmemiş, güvenlik ekiplerinin varlığından haberdar olmadığı bir API.

26 Kasım - 4 Ocak (40 Gün): Sessizlik. Tam sessizlik. Saldırgan her gün, sistematik olarak 37 milyon müşterinin verilerine erişti:

• İsim, soyisim
• Fatura adresleri
• E-posta adresleri
• Telefon numaraları
• Doğum tarihleri
• T-Mobile hesap numaraları

Güvenlik ekipleri? Hiçbir şeyden haberdar değil. SIEM'ler alarm vermiyor. API Security ürünleri sessiz. Çünkü göremedikleri bir API'dan bahsediyoruz.

5 Ocak 2023 - Tespit: 41 gün sonra, anormallik tespit edildi. Nasıl? Detaylar tam olarak açıklanmadı, ama büyük ihtimalle başka bir güvenlik katmanında ya da manuel bir kontrolde fark edildi.

6 Ocak 2023 - Durdurma: T-Mobile, saldırıyı tespit ettikten sadece 1 gün sonra durdurdu.

Dikkat çeken nokta: Tespit edildikten sonra 1 günde durdurulabildiyse, neden 41 gün görünmedi?

Root Cause: Shadow API ve API Sprawl

Salt Security'nin derinlemesine analizi, sorunu net bir şekilde ortaya koydu:

"Varlığı API yönetim ve güvenlik programının görüş alanı dışında kalan, dokümante edilmemiş API. Güvenlik ekipleri bu API'ların varlığından, işlediği verilerden ve güvenlik duruşundan habersiz."

Bu sadece "bir API'yi unuttuk" meselesi değil. Bu, "API Sprawl" (API yayılması) denilen sistematik bir sorunun sonucu:

1. Shadow API'lar (Gölge API'lar)

• Tanım: Kimsenin bilmediği, kayıt dışı API'lar
• Nasıl oluşur?
  • Geliştiriciler test için oluşturur, unutur (veya acil bir API açılıp sonra unutulmuştur). Aynı işi yapan bir çok duplicate Shadow API vardır.
  • Legacy sistemlerden kalma, dokümante edilmemiş endpoint'ler.
  • Mikroservis mimarisinde kontrol dışı çoğalan servisler
  • Satın alınan şirketlerden gelen entegre edilmemiş API'lar
• T-Mobile'da: İşte bu kategori ihlale neden oldu

2. Zombie API'lar (Ölü API'lar)

• Tanım: Kullanılmıyor sanılan ama hala aktif olan API'lar
• Neden tehlikeli?
  • Güvenlik güncellemeleri yapılmıyor
  • Monitoring edilmiyor
  • Eski, bilinen güvenlik açıkları var
  • "Devre dışı" sanılıyor ama çalışıyor

3. Ghost API'lar (Hayalet API'lar)

• Tanım: Dokümantasyonda var ama gerçekte farklı çalışan API'lar (Internal Server Error gibi hata mesajlarıyla karşılaşan entegre ekipler bu tür API'lardan mustarip.)
• Sorun:
  • Dokümantasyon ile gerçek davranış arasında fark
  • Güvenlik testleri dokümana göre yapılıyor, gerçek açıklar kaçıyor
  • Sürüm uyuşmazlıkları
    Dokümantasyon konusunda API Developer Portal kullanımının yaygınlaşması bu tür problemleri azaltır; ancak envanter konusunu çözmez.

API Sprawl'ın Boyutları

T-Mobile vakası tekil bir olay değil. Salt Security ve LevelBlue'nun 2024 araştırması gösteriyor ki:

• Organizasyonların %94'ü geçen yıl production API'larında güvenlik sorunu yaşadı
• Çoğu işletme API envanteri konusunda sınırlı görünürlüğe sahip
• Ortalama bir enterprise'da 200-500 adet kayıt dışı API bulunuyor

T-Mobile'ın gerçeği daha da acı: Bu onların 8. veri ihlaliydi.

8 İhlal, 350 Milyon Dolar

T-Mobile'ın veri ihlali geçmişi:

• 2018: 2 milyon müşteri etkilendi
• 2019: Haziran'da prepaid müşteriler, Kasım'da başka bir ihlal
• 2020: Çalışan e-postaları, müşteri bilgileri
• 2021 (Ağustos): 54 milyon müşteri - en büyük ihlal
• 2022 (Nisan): SIM swap saldırıları
• 2022 (Kasım 25): Bizim vakamız başlıyor
• 2023 (Ocak): 37 milyon müşteri - Shadow API ihlali

2021 ihlalinin bedeli: T-Mobile, bir toplu dava (class action) sonucu $350 milyon ödeme yapmayı kabul etti. Buna ek olarak $150 milyon'luk siber güvenlik yatırımı taahhüt etti.

Soru: $350 milyon ödemesine ve $150 milyon siber güvenlik yatırımına rağmen, nasıl 2023'te yine aynı tip bir ihlal yaşandı?

Neden Tekrarlandı?

Salt Security'nin analizi çok net:

1. Görünürlük eksikliği: API envanteri tam değildi
2. Gateway eksikliği: Tüm API trafiği merkezi noktadan geçmiyordu
3. Governance zafiyeti: API yaşam döngüsü yönetimi yoktu
4. Shadow API'lar: Sürekli oluşuyordu, tespit edilmiyordu

T-Mobile muhtemelen 2021 sonrası:

• API Security ürünleri aldı
• Güvenlik ekibini güçlendirdi
• Penetrasyon testleri yaptırdı
• Compliance çalışmaları yaptı

Ama yapmadığı şey:

• Merkezi API Gateway altyapısı kurmadı
• Tüm API'ları envanterlemedi
• Shadow API'ları tespit edecek mekanizma oluşturmadı
• API yaşam döngüsü yönetimini kurumsallaştırmadı

Sonuç: Güvenlik ürünleri aldılar ama görecek göz vermediler. Shadow API'lar görünmez kaldı ve 41 gün boyunca saldırı devam etti.

T-Mobile Vakasından Çıkarılması Gereken 3 Ders

1. Para Harcamak ≠ Güvenli Olmak
$500 milyon harcayabilirsiniz, ama doğru sıralamayı takip etmezseniz aynı hatayı tekrarlarsınız.

2. Görünürlük Her Şeyden Önce Gelir
41 gün görünmez kalan bir saldırı = Gateway ve envanter eksikliği. Önce görebilmeli, sonra koruyabilirsiniz.

3. API Sprawl Bir Gerçek
Shadow, Zombie ve Ghost API'lar sürekli oluşuyor. Bunu engelleyecek sistematik süreçler gerekiyor, sadece araçlar değil.

---

BÖLÜM 3: API Security Ürünü Almadan Önce Sormanız Gereken 3 Kritik Soru

T-Mobile, 2021'deki ihlalin ardından $350 milyon ödedi ve $150 milyon siber güvenlik yatırımı yaptı. Muhtemelen en iyi API Security ürünlerini satın aldılar. Yine de 2023'te aynı tipte bir ihlal yaşadılar.

Sorun ürünlerde değildi. Sorun temellerde.

Eğer siz de organizasyonunuzda "API Security ürünü almalı mıyız?" diye tartışıyorsanız, önce kendinize bu 3 soruyu sorun.

SORU 1: API Envanteriniz Var mı?

"Kaç tane API'niz var?"

Bu soruyu sahada sorduğumda aldığım cevaplar:

• "Tam olarak bilmiyoruz ama yaklaşık 200 civarı olmalı" (Gerçekte 847 API olduğu ortaya çıktı)
• "Her departmanın kendi API'ları var, toplam sayıyı kimse bilmiyor"
• "Legacy sistemlerimizde API var mı bilmiyoruz bile"
• "Mikroservislere geçtiğimizden beri kontrol elimizden çıktı"

Envanter Olmadan Güvenlik Olmaz

API envanteri sadece bir Excel listesi değildir. Tam bir envanter şunları içermelidir:

Temel Bilgiler:

• API adı ve versiyonu
• Endpoint'ler (URL'ler)
• HTTP metodları (GET, POST, PUT, DELETE, vb.)
• Hosting bilgisi (hangi sunucuda, hangi ortamda)

Sahiplik ve Yönetim:

• API sahibi (Product Owner)
• Teknik sorumlu (Developer Team)
• İş birimi (hangi departman kullanıyor)
• Yaşam döngüsü durumu (development, production, deprecated)

Güvenlik ve Uyumluluk:

• Kimlik doğrulama yöntemi (OAuth, API Key, JWT, vb.)
• Yetkilendirme modeli
• İşlediği veri tipleri (PII, PCI, hassas veri var mı?)
• Compliance gereksinimleri (GDPR, KVKK, PCI-DSS, vb.)

Teknik Detaylar:

• Teknoloji stack (Node.js, Java, .NET, vb.)
• Bağımlılıkları (hangi servislerle konuşuyor)
• SLA gereksinimleri
• Rate limiting ve throttling ayarları

Envanter Olmadan API Security Ürünü Aldığınızda Ne Olur?

Gerçek bir senaryo: Bir finans kurumu, 2 milyon dolarlık bir API Security platformu satın aldı. Ürün harika şeyler vaat ediyordu: Behavioral analysis, Anomaly detection, Shadow API discovery, Threat intelligence.

6 ay sonra durum:

• Ürün 180 adet API tespit etti (gateway üzerinden geçenler)
• Manuel envanter çalışmasında 540 adet API bulundu
• 360 API ürünün göremediği yerlerde çalışıyordu
• Shadow API'ların %67'si hiçbir zaman tespit edilemedi

Sonuç: 2 milyon dolar harcanmış, ama API'ların çoğu hala görünmez.

"Envanter olmadan API Security ürünü almak, haritası olmayan bir şehirde polis devriyesi yapmak gibidir. Hangi sokakları koruyacağınızı bilemezsiniz."

SORU 2: Merkezi Bir API Gateway'iniz Var mı?

"Tüm API trafiğiniz merkezi bir noktadan geçiyor mu?"

Bu soru çok daha kritik. Çünkü API Security ürünleri Gateway trafiğini izleyerek çalışır.

Sahada gördüğüm yaygın mimariler:

Dağıtık Mimari (En Riskli): Her API farklı yollardan expose; merkezi görünürlük yok.

Merkezi Gateway Mimarisi: Tüm trafik tek noktadan geçer; tam görünürlük.

Gateway Olmadan API Security Ürünü Neden Kör Kalır?

API Security ürünlerinin çalışma prensibi:

1. Traffic Monitoring: HTTP request/response trafiğini yakalar
2. Baseline Learning: Normal davranış patternlerini öğrenir
3. Anomaly Detection: Normalden sapmaları tespit eder
4. Threat Intelligence: Bilinen saldırı patternleriyle karşılaştırır

Ama bu döngü çalışması için TRAFİĞİ GÖRMESİ lazım.

T-Mobile vakasında: Shadow API Gateway'den geçmiyordu; API Security ürünü trafiği göremiyordu; 41 gün boyunca kör kaldı; Behavioral baseline oluşturulamadı; Anomali tespit edilemedi.

"Biz WAF Kullanıyoruz, Yeterli Değil mi?"

Hayır. WAF ve API Gateway farklı şeyler:

WAF (Web Application Firewall):

• Layer 7 ataklarını engeller (SQL injection, XSS, vb.)
• Pattern-based çalışır
• API-aware değildir
• API envanteri çıkaramaz
• API-specific saldırıları (BOLA, Mass Assignment, vb.) tespit edemez

API Gateway:

• API trafiğini yönetir
• Rate limiting, throttling yapar
• API envanteri oluşturur
• Request/response transformasyon
• API Security ürünlerine tam görünürlük sağlar

"WAF'ınız varsa güvenlisiniz demek, kapıda güvenlik görevlisi olduğu için binanızdaki tüm odaları bildiğinizi sanmak gibidir."

Gerçek Rakamlar

Gartner'ın 2024 araştırması:

• Merkezi Gateway kullanmayan organizasyonlarda Shadow API oranı: %68
• Merkezi Gateway kullanan organizasyonlarda Shadow API oranı: %23

Fark 3 kat.

SORU 3: Internal ve External API'larınızı Ayırt Edebiliyor musunuz?

"Hangi API'larınız internete açık, hangileri sadece internal?"

Bu soru sanki basit gibi görünür ama çoğu organizasyon için değildir.

Gerçek Bir Vaka

Bir e-ticaret şirketi ile çalıştım. Kendilerinden emin görünüyorlardı:

Onlar: "Sadece 12 API'miz external. Geri kalanı internal."

Gerçek durum:

• Network taraması yaptık
• 47 API internete açıktı
• 35 tanesi "yanlışlıkla" expose olmuştu
• Geliştiriciler test için açmış, kapatmayı unutmuş
• Bazıları yıllardır açıktı, kimse fark etmemişti

Internal vs External API Riski

External API'lar: Bilinçli olarak dışarıya açılır, genellikle daha iyi korunur, monitoring edilir, dokümante edilir.

Internal API'lar (yanlışlıkla external olmuş): Güvenlik önlemleri minimal, "İçeride kullanılacak" düşüncesiyle tasarlanmış, Authentication/authorization zayıf veya yok, Monitoring edilmiyor, Saldırganlar için altın madeni.

OWASP API Security Top 10'da #9

#9 Improper Inventory Management
"API hosts and deployed API versions are not properly managed."
Risk faktörleri:
- Eski API versiyonları korunmadan çalışmaya devam ediyor
- Deprecated API'lar silinmemiş
- API inventory yok veya güncel değil
- Internal/External ayrımı net değil

Shadow API Tespiti Nasıl Çalışır?

1. Gateway trafiğini analiz eder
2. Envanter ile karşılaştırır
3. Envanterde olmayan endpoint'leri işaretler
4. Davranış analizi yapar

Ama bu döngü çalışması için: Gateway olmalı (trafik görünürlüğü), Envanter olmalı (karşılaştırma referansı), Internal/External ayrımı olmalı (risk seviyesi).

Yoksa: API Security ürünü sadece gördüğü API'ları tespit eder. Görmediği 360 API Shadow olarak kalır.

SONUÇ: 3 Soruya HAYIR Diyorsanız = Para Kaybı

Soru	HAYIR ise Sonuç
API Envanteriniz var mı?	API Security ürünü neyi koruyacağını bilemez. Karşılaştırma referansı yok. Shadow API tespit edilemez.
Merkezi Gateway'iniz var mı?	API Security ürünü trafiği göremez. Behavioral analysis çalışmaz. Anomali tespiti imkansız.
Internal/External ayrımı yapabiliyor musunuz?	Risk seviyesi belirlenemez. Yanlışlıkla expose olan API'lar bulunamaz. Prioritization yapılamaz.

---

BÖLÜM 4: Veriler Ne Diyor? Sektör Araştırmaları ve İstatistikler

Son 12 ayda yayınlanan raporlar, hepimizin bildiği ama kabul etmek istemediğimiz acı gerçeği ortaya koyuyor: API güvenliği krizi içindeyiz ve sorun teknik değil, temel. Yani ürünle çözülmez. Ve kurumunuzda bir kültür değişiminin zamanının geçtiğinin çok açık bir göstergesi.

Gartner 2024: Shadow API'lar Daha Büyük Hasara Yol Açıyor

Kaynak: Gartner 2024 Market Guide for API Protection

• %94 - Production API'larında güvenlik sorunu yaşayan organizasyon oranı (Salt Security)
• %71 - Envanteri %100 doğru olmayan kuruluşlar (Dark Reading)
• %68 - Shadow API'ları olan kuruluşlar (Dark Reading)
• %62 - API saldırılarındaki yıllık artış (Salt Security)
• %48 - API envanteri eksik veya güncel olmayan (Salt Security)
• %40 - Web saldırılarının API üzerinden gelme oranı 2024 (Gartner)
• %31 - API üzerinden veri sızdıran kuruluşlar (Salt Security)
• 3 kat - Gateway olmayan vs olan kuruluşlarda Shadow API farkı (Gartner)

Sonuç: Bu sadece birkaç "kötü örnek" değil. Bu sistematik, yaygın, büyüyen bir kriz.

Pattern Açık: Kök Sebep Aynı

Farklı kuruluşlar, farklı coğrafyalar, farklı sektörler... Ama kök sebep hep aynı:

• API envanteri yok
• Merkezi Gateway yok
• Görünürlük yok
• Shadow API'lar kontrol dışı

Ve sonuç da hep aynı: Veri ihlali, Müşteri kaybı, İtibar hasarı, Yasal cezalar, Milyonlarca dolar kayıp.

---

BÖLÜM 5: "Göremediğiniz Şeyi Koruyamazsınız" - Visibility Neden Kritik?

Siber güvenlikte altın bir kural vardır:

"You can't protect what you can't see." — "Göremediğiniz şeyi koruyamazsınız."

T-Mobile 41 gün boyunca saldırıyı göremedi. Neden? Çünkü o API'yi görmüyorlardı.

Görünürlük Nedir? 3 Seviye Visibility

Seviye 1: Asset Visibility (Varlık Görünürlüğü) — Hangi API'larınız var? Kaç API, nerede host, hangi endpoint'ler, internal/external, hangi versiyonlar.

Seviye 2: Traffic Visibility (Trafik Görünürlüğü) — API'larınız nasıl kullanılıyor? Kimler çağırıyor, ne sıklıkla, hangi parametreler, response süreleri, hata oranları. Behavioral analysis ve anomaly detection için baseline gerekir; baseline için trafiği görmeniz lazım.

Seviye 3: Data Visibility (Veri Görünürlüğü) — API'larınız hangi verileri işliyor? PII, finansal veri, hassas sağlık verisi, credential'lar, GDPR/KVKK/PCI-DSS kapsamı. OWASP API3:2023 - Excessive Data Exposure: Bir API gerekenden fazla veri döndürebilir; frontend 3 field kullanıyor ama backend 20 field gönderiyor. Data Visibility olmadan bu tespit edilemez.

Görünürlük = Kontrol = Güvenlik

Visibility sadece "görmek" değildir. Visibility = Kontrol demektir.

• Proaktif Güvenlik: Saldırı olmadan önce zafiyetleri görürsünüz; Shadow API'ları tespit edersiniz; Anomalileri erken yakarsınız.
• Hızlı Müdahale: T-Mobile 41 gün geç kaldı; Görünürlük olsaydı, 41 dakikada tespit edilirdi.
• Compliance: GDPR, KVKK, PCI-DSS denetimlerinde "Hangi API'lar PII işliyor?" sorusuna cevap verebilirsiniz.
• Operasyonel Verimlilik ve Business Intelligence: Performans sorunları, kullanılmayan API'lar, monetization fırsatları.

Gateway Latency vs Güvenlik: Yanlış İkilem

Bazı kuruluşlar "Gateway kullanırsak latency artar" diye düşünür. Bu mantık felaketle sonuçlanır.

Modern API Gateway'lerin ortalama latency'si: 5-15ms. DNS lookup 20-120ms, TCP handshake 50-200ms, TLS handshake 50-100ms, Database query 50-500ms, External API call 200-2000ms ile kıyaslandığında Gateway'in eklediği latency total request time'ın %1-2'si.

Doğru yaklaşım: Tüm API'ları Gateway'den geçirelim; performansı caching, connection pooling, async processing, database optimization ile artıralım. Sonuç: +5-10ms latency, %100 visibility. Gateway kullanmak, kullanmamaktan 3-4 kat daha ekonomik.

---

BÖLÜM 6: Gateway → Management → Security: Doğru Sıralama ile Adım Adım Yol Haritası

Yanlış sıralama: API Security ürünü al → Deploy et → Sadece %30-40 API görünür → Shadow API'lar tespit edilemiyor → ROI düşük, hayal kırıklığı → Proje rafa kalkıyor.

Doğru sıralama: ADIM 1: GATEWAY (Görünürlük) → ADIM 2: MANAGEMENT (Envanter & Governance) → ADIM 3: SECURITY (Koruma & Anomali)

Her adım bir öncekinin temelini oluşturur. Atlamak = başarısızlık.

ADIM 1: API Gateway - Temel Taşı (0-6 Ay)

Hedef: %100 görünürlük

• 1.1 Gateway Seçimi ve Kurulum (Ay 1-2): High availability & scalability, Rate limiting/throttling/caching, Monitoring & logging, Security tool entegrasyonu, Kubernetes/OpenShift uyumu, APIOPS/CI-CD entegrasyonu. Hızlı kazanım: Merkezi authentication, rate limiting ile DDoS koruması, basic logging.
• 1.2 API Migration (Ay 2-4): Öncelik: External API'lar (en riskli), PII işleyen (GDPR/KVKK), High-traffic, Legacy (shadow risk), Internal.
• 1.3 Discovery & Baseline (Ay 4-6): Tüm API'ları Gateway'den geçir; traffic pattern'leri öğren; baseline oluştur. Çıktı: %100 API Gateway coverage, merkezi görünürlük, baseline hazır.

ADIM 2: API Management - Envanter & Governance (6-12 Ay)

Hedef: Kontrol ve yönetim. Gateway kullanıyor olsanız bile bu aşamayı atlamayın.

• 2.1 API Envanteri (Ay 6-8): API adı, versiyon, endpoint'ler; Sahip (Product Owner, Tech Lead); İş birimi; Data classification; SLA, rate limits; Auth; Compliance.
• 2.2 API Lifecycle Management (Ay 8-10): Design → Develop → Test → Deploy → Monitor → Deprecate → Retire. Governance: Yeni API mutlaka envantere; Deprecated kontrollü kapatılmalı; Versiyon standardı; Documentation zorunlu.
• 2.3 Shadow API Elimination (Ay 10-12): Gateway trafiği vs envanter karşılaştırması; Shadow tespiti; Sahiplik belirleme; Entegre et veya kapat. Çıktı: Güncel envanter, sahiplik netliği, Shadow API'lar eliminate, governance çalışıyor.

ADIM 3: API Security - Koruma & Anomali Tespiti (12-18 Ay)

Hedef: Proaktif güvenlik. ŞİMDİ API Security ürünü alın. Çünkü %100 görünürlük var, envanter hazır, baseline oluşmuş, governance çalışıyor.

• 3.1 Platform Seçimi (Ay 12-13): Gateway entegrasyonu, Behavioral analysis, OWASP API Top 10, Threat intelligence. PoC: Production trafiği, Shadow API tespit oranı, false positive, response time impact.
• 3.2 Deployment & Tuning (Ay 13-15): Entegrasyon, baseline learning (2-4 hafta), policy, alert tuning.
• 3.3 Operasyonelleştirme (Ay 15-18): SOC eğitimi, playbook, incident response, KPI. Çıktı: Saldırı süreleri dakikalar (41 gün değil!).

Son Tavsiye: "Ürün alırsak her şey çözülür", "Adım atlayalım", "Önce security, sonra temeller" demeyin. Adım adım ilerleyin; Gateway → Management → Security sırasını bozmayın. "18 ay gibi görünebilir. Ama T-Mobile 8 yılda 8 ihlal yaşadı ve $350M+ ödedi. Hangi yolu tercih edersiniz?"

---

BÖLÜM 7: Yarın Çok Geç Olabilir - Bugün Kontrol Edin

"Güzel yazı ama bizde olmaz. Biz farklıyız." — T-Mobile de öyleydi. $350 milyon ödedikten sonra bile.

Gerçekten farklı mısınız? 10 basit soru: Envanter (5 dakikada kaç API?), Shadow ("Bu API nereden çıktı?" dediniz mi?), Sahiplik (rastgele bir API'nin iş sorumlusu kim?), Gateway (TÜM API'lar tek Gateway'den mi?), Legacy (3+ yıl önce yazılmış API?), Yeni firma/entegrasyon, Mikroservis özerkliği, Security ürünü tüm API'ları görüyor mu?, Son 2 yılda API güvenlik olayı?, Gece rahat uyuyor musunuz? — Bu sorulara verdiğiniz cevaplar gerçek durumu gösterir.

SOA'dan Öğrendiğim Tek Şey

20 yıl önce SOA'da "Ürün alırsak çözülür" dedik; temelleri atlamak istedik; sabırsız olduk; başarısız olduk. Şimdi aynı hatayı API Security'de yapıyoruz. Ama bir fark var: API ekonomisi SOA'dan çok daha kritik. Hata yapma lüksümüz yok.

Son Söz

"En tehlikeli API, bilmediğiniz API'dır."
"En pahalı güvenlik açığı, görmediğiniz açıktır."
"En büyük hata, 'bizde olmaz' demektir."

En iyi API Security ürününü alabilirsiniz. Milyonlar harcayabilirsiniz. Ama eğer API'larınız Gateway'den geçmiyorsa, o ürün sadece gördüklerini korur. Görmediklerini değil. API'larınızın %100'ünü görebiliyor musunuz? Shadow API'larınızı tespit edebiliyor musunuz? Tüm API trafiği merkezi bir noktadan geçiyor mu? Bu sorulara HAYIR diyorsanız, T-Mobile'ın 41 gününe çok yakınsınız.