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:

Önce Gateway → Tüm trafik merkezi noktadan geçsin
Sonra Management → Envanter oluşsun, sahiplik belirlensin
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 (ya da birisi acil bir API açmamız lazım demiştir o an için açılıp sonrada unutulmuştur, tanıdık geldi mi ). Ve eminim, aynı işi yapan bir çok duplicate Shadow API vardır.
- Legacy sistemlerden kalma, dokümante edilmemiş endpoint'ler. (Dokümante edilenlerde çok eski kalmıştır ve API ile hiç alakası yoktur, entegre olmak isteyenlerin canına okumuştur. Nereden biliyorsun demeyin bir arkadaşın başına gelmiş oradan biliyorum )
- 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 (entegre olmayan çalışan arkadaşlar bu arkadaşların kulaklarını çok çınlatmıştır . Kardeşim, Internal Server Error diye hata mesajı mı olur , neyse konumuza devam edelim)
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 konusuna gelmişken, bu konuda API Developer Portal kullanımın artık yaygınlaşmasının zamanı geldi ve geçiyor. Özellikle word ile paylaşılan ve yukarıdaki maddelerdeki problemlerden sizi kurtacaktır, ama envanterden değil tabi ki

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:

Görünürlük eksikliği: API envanteri tam değildi
Gateway eksikliği: Tüm API trafiği merkezi noktadan geçmiyordu
Governance zafiyeti: API yaşam döngüsü yönetimi yoktu
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. Bu sorulara vereceğiniz cevaplar, yatırımınızın başarılı mı yoksa boşa mı gideceğini belirleyecek.

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)

Bilgi : Bu bölümü şuan Ankara'da Vatandaşa doğrudan hitap eden en kritik kurumlarımızdan birinde benim de bilgisine ve tecrübesine hayran olduğum Kurumsal Mimari Uzmanı olan bir büyüğümüz yapmak için çalışıyor ve yaptıklarını görünce hayran olmamak elde değil. Bu makalenin bir çok bölümü de zaten orada gördüklerimden ve onunla konuştuktan sonra ortaya çıktı diyebilirim

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 (sizler de araştırıp bulabilirsiniz makalelerde):

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):

✅ Merkezi Gateway Mimarisi:

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

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

Traffic Monitoring: HTTP request/response trafiğini yakalar
Baseline Learning: Normal davranış patternlerini öğrenir
Anomaly Detection: Normalden sapmaları tespit eder
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?

API Security ürünleri Shadow API'ları nasıl tespit eder?

Gateway trafiğini analiz eder
Envanter ile karşılaştırır
Envanterde olmayan endpoint'leri işaretler
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ı

Bu 3 soruya verdiğiniz cevaplar, API Security yatırımınızın kaderini belirler:

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

Sahadan gözlemlerim ve T-Mobile vakası yeterince çarpıcı değil mi? Peki ya veriler? Global araştırma şirketleri, güvenlik firmaları ve endüstri otoriteleri ne söylüyor?

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

Gartner'ın 2024 raporundaki en çarpıcı bulgu:

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

Gartner'ın önemli tespitleri:

API'lar yeni saldırı vektörü:
- 2023'te web uygulamalarına yapılan saldırıların %30'u API'lar üzerinden gerçekleşti
- 2024'te bu oranın %40'a çıkması bekleniyor
Shadow API sorunu büyüyor:
- Organizasyonların çoğu API envanterini %100 doğru bilemiyor
- Ortalama bir enterprise'da 200-300 kayıt dışı API var
- Bu API'lar tespit edildiğinde, genellikle kritik güvenlik açıkları taşıyor
API Security pazarı büyüyor ama...
- 2024'te API Security pazarı $1.2 milyar
- 2028'de $4.8 milyar olması bekleniyor
- Ama Gartner uyarıyor: "Ürün almak sorunu çözmez, temel visibility gerekir"

Gartner'ın tavsiyesi:

"API güvenlik araçları satın almadan önce, organizasyonlar tüm API'larını tespit etmeli, envanter oluşturmalı ve merkezi bir API Gateway üzerinden yönetmelidir."

Salt Security & LevelBlue: %94 Güvenlik Sorunu

Kaynak: Salt Security ve LevelBlue 2024 "State of API Security" Araştırması

Salt Security, API güvenliği konusunda dünyanın önde gelen firmalarından biri. LevelBlue (eski adıyla AT&T Cybersecurity) ile birlikte yaptıkları 2024 araştırması gerçek felaket senaryosunu ortaya koyuyor.

Baş Döndürücü İstatistikler:

%94 - Production API'larında güvenlik sorunu yaşayan organizasyon oranı

Yani 100 şirketten 94'ü geçen yıl en az bir API güvenlik olayı yaşadı
Bu sadece tespit edilenler; tespit edilmeyenler dahil değil

%62 - API saldırılarında artış (2022'ye göre 2023)

Saldırganlar API'ların savunmasız olduğunu öğrendi
Artık web uygulamasını değil, doğrudan API'yı hedef alıyorlar

%31 - API'lar üzerinden müşteri verisi sızdıran organizasyonlar

Bu sadece 1 yılda yaşananlar
T-Mobile gibi tekrarlayan ihlaller bu istatistiğe dahil değil

%17 - API ihlali nedeniyle gelir kaybı yaşayan şirketler

Sadece veri sızıntısı değil, operasyonel kayıplar da var
Müşteri kaybı, itibar hasarı, yasal yükümlülükler

En Kritik Bulgu: Görünürlük Sorunu

Araştırmanın en önemli tespiti:

"Birçok işletme API envanteri konusunda sınırlı görünürlüğe sahip. Çoğu organizasyon kaç API'lerinin olduğunu bile bilmiyor."

Detaylar:

%48 - API envanterinin eksik veya güncel olmadığını belirten şirketler
%37 - Shadow API'ları tespit edecek mekanizmaları olmayan şirketler
%29 - Hangi API'ların hassas veri işlediğini bilmeyen şirketler

Salt Security CEO'su Roey Eliyahu:

"En tehlikeli API, bilmediğiniz API'dır. Göremediğiniz şeyi koruyamazsınız."

Saldırı Tipleri ve Frekansları:

Saldırı Tipi	Oran	Açıklama
Broken Authentication	%34	Zayıf kimlik doğrulama
BOLA (IDOR)	%28	Yetkisiz veri erişimi
Excessive Data Exposure	%23	Gereksiz veri döndürme
Lack of Rate Limiting	%19	DDoS ve scraping
Mass Assignment	%15	Parametre manipülasyonu

Dark Reading: En Acil Sorun "Envanter Eksikliği"

Kaynak: Dark Reading, Kasım 2024 - "The API Inventory Crisis"

Dark Reading, siber güvenlik profesyonellerinin en çok takip ettiği yayınlardan biri. Kasım 2024'teki makalelerinde çarpıcı bir başlık:

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

Dark Reading'in Saha Araştırması:

500 CISO ile yapılan görüşme sonuçları:

%71 - "API envanterimiz %100 doğru değil" diyor
%58 - "Shadow API'larımız olduğunu biliyoruz ama tespit edemiyoruz"
%43 - "Legacy sistemlerdeki API'ları bilmiyoruz"
%39 - "Satın aldığımız şirketlerin API'larını entegre edemedik"

"The API Sprawl Problem" - API Yayılma Sorunu

Dark Reading'in tanımladığı "API Sprawl" (API Yayılması) 4 kategoride ortaya çıkıyor:

1. Shadow API'lar (%68):

Güvenlik ekibinin bilmediği API'lar
Genellikle geliştiriciler tarafından test için oluşturulmuş
Production'a yanlışlıkla deploy olmuş
Dokümantasyon yok

2. Zombie API'lar (%52):

Kullanılmıyor sanılan ama hala aktif olan API'lar
Eski versiyonlar, deprecated endpoint'ler
Güvenlik güncellemeleri yapılmamış
Monitoring edilmiyor

3. Ghost API'lar (%34):

Dokümantasyonda var ama gerçekte farklı çalışan
API spesifikasyonu ile implementasyon uyuşmuyor
Güvenlik testleri dokümana göre yapılıyor
Gerçek açıklar kaçırılıyor

4. Rogue API'lar (%21):

İzinsiz oluşturulmuş API'lar
Governance süreçleri bypass edilmiş
Genellikle "acil ihtiyaç" bahanesiyle yapılmış

Saldırganların Yeni Stratejisi: "API Reconnaissance"

Dark Reading'in en ilginç bulgusu: Saldırganlar artık sistematik API keşfi yapıyor.

Saldırı Süreci:

Reconnaissance (Keşif): Hedef organizasyonun tüm API'larını bul
Shadow API Identification: Dokümante edilmemiş olanları tespit et
Vulnerability Assessment: Shadow API'lardaki zafiyetleri bul
Exploitation: Zayıf olanlardan gir

Ortalama süre:

Keşif: 2-3 gün
Shadow API bulma: 1-2 gün
Saldırı: 1 gün
Toplam: 4-6 gün

T-Mobile'ın 41 günü hatırlayın. Saldırgan muhtemelen ilk 4-5 günde içeri girdi, geri kalan 36 gün boyunca veri topladı.

OWASP API Security Top 10: #9 - Improper Inventory Management

Kaynak: OWASP API Security Top 10 (2023)

OWASP (Open Web Application Security Project), web ve API güvenliği standartlarının küresel otoritesi. API Security Top 10 listesi, sektörün en çok referans gösterdiği kaynak.

2023 güncellemesinde #9 numarada:

API9:2023 - Improper Inventory Management
"Organizations tend to expose more API endpoints than necessary,
and fail to properly inventory and manage all API versions."

OWASP'nin Tanımı:

"API varlıklarının yetersiz yönetimi. API hosts ve deployed API versiyonlarının düzgün yönetilmemesi. Eski API versiyonları veya debug endpoint'leri production'da çalışmaya devam ediyor."

Risk Faktörleri:

Yüksek Risk Senaryoları:

✗ Tüm API'ların tam envanteri yok
✗ Hangi API versiyonlarının aktif olduğu bilinmiyor
✗ Deprecated API'lar silinmemiş, hala erişilebilir
✗ Debug endpoint'leri production'da açık
✗ Legacy sistemlerdeki API'lar unutulmuş
✗ Internal/External API ayrımı net değil

OWASP'nin Gerçek Vaka Örnekleri:

Örnek 1: Eski API Versiyonu

v1/users/{id}        → Deprecated, ama hala çalışıyor
v2/users/{id}        → Güncel, korumalı
v3/users/{id}        → En yeni, en güvenli

Saldırgan: v1'i kullanır, çünkü authentication zayıf

Örnek 2: Debug Endpoint

/api/users           → Production, korumalı
/api/debug/users     → Test için açılmış, unutulmuş
                        Authentication yok!

Örnek 3: Shadow API

Dokümantasyon: 50 API endpoint
Gerçekte: 127 API endpoint
Fark: 77 Shadow API (kimse bilmiyor)

OWASP'nin Tavsiyesi:

Önleme Stratejileri:

Comprehensive Inventory:
- Tüm API'ların envanterini çıkar
- Host, versiyon, endpoint, authentication method
- Internal/External, deprecated/active durumları
API Gateway Kullanımı:
- Tüm API trafiği merkezi noktadan geçmeli
- Envanter otomatik olarak güncellenebilmeli
Lifecycle Management:
- API yaşam döngüsü yönetimi
- Deprecated API'ları kontrollü şekilde kapat
- Eski versiyonları sunset et
Continuous Monitoring:
- Sürekli API keşfi
- Shadow API tespiti
- Anomali izleme

Rakamlar Özeti: Durum Vahim

Tüm bu araştırmaları bir araya getirdiğimizde ortaya çıkan tablo:

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

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."

Bu basit ama derin bir gerçek. Ve API güvenliğinde bu kural daha da kritik hale geliyor.

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

%94 organizasyon güvenlik sorunu yaşıyor. Neden? Çünkü API'larının tamamını görmüyorlar.

Shadow API'lar en büyük tehdit. Neden? Çünkü tanım gereği görünmüyorlar.

Gelin bu "görünürlük" meselesini derinlemesine inceleyelim.

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

API güvenliğinde görünürlük tek boyutlu değildir. 3 farklı seviyede visibility gerekir:

Seviye 1: Asset Visibility (Varlık Görünürlüğü)

Soru: Hangi API'larınız var?

Bu en temel seviye. Ama çoğu organizasyon burada başarısız oluyor.

Asset Visibility şunları içerir:

Kaç API'niz var?
Bu API'lar nerede host ediliyor?
Hangi endpoint'ler aktif?
Hangi HTTP metodları kullanılıyor?
İnternal mi, external mi?
Hangi versiyonlar çalışıyor?

Gerçek Senaryo - Bir Finans Kurumu:

İlk İddia:
"Bizim 87 API'mız var, hepsini biliyoruz."

Discovery Çalışması Sonrası:

Production'da 312 API bulundu
225 tanesi envanterde yoktu
Bunlardan:
- 143'ü mikroservislerden (farklı takımlar oluşturmuş)
- 47'si legacy sistemlerden (10+ yıllık)
- 35'i satın alınan şirketten (3 yıl önce M&A)

Sonuç: Asset Visibility olmadan güvenlikten bahsedemezsiniz.

Seviye 2: Traffic Visibility (Trafik Görünürlüğü)

Soru: API'larınız nasıl kullanılıyor?

API'nizi bilmek yetmez. Nasıl kullanıldığını da görmeniz gerekir.

Traffic Visibility şunları içerir:

Kimler API'nizi çağırıyor?
Ne sıklıkla çağırıyor?
Hangi parametreler kullanılıyor?
Hangi data gönderiliyor/dönüyor?
Response süreleri nedir?
Hata oranları ne?
Hangi saatlerde yoğunluk var?

Bu neden kritik?

Behavioral analysis ve anomaly detection için baseline gerekir. Baseline oluşturmak için trafiği görmeniz lazım.

T-Mobile Vakasında Eksik Olan:

Normal Trafik (Görseydi):
10:00 - 100 request/min
11:00 - 120 request/min
12:00 - 110 request/min

Saldırı Trafiği:
10:00 - 100 request/min
11:00 - 120 request/min
12:00 - 850 request/min  ← ⚠️ ANOMALY!

Ama göremediler çünkü API Gateway'den geçmiyordu.

Seviye 3: Data Visibility (Veri Görünürlüğü)

Soru: API'larınız hangi verileri işliyor?

En kritik seviye. Çünkü asıl korunması gereken veri.

Data Visibility şunları içerir:

Hangi API PII (Personally Identifiable Information) işliyor?
Hangi API finansal veri taşıyor?
Hangi API hassas sağlık verisi içeriyor?
Hangi API şifre, token gibi credential'lar dönüyor?
GDPR, KVKK, PCI-DSS kapsamında hangi API'lar var?

OWASP API3:2023 - Excessive Data Exposure:

Bir API, gerekenden fazla veri döndürebilir. Frontend sadece 3 field kullanıyor ama backend 20 field gönderiyor.

Örnek:

json

// Frontend'in ihtiyacı:
{
  "name": "Ahmet Yılmaz",
  "email": "ahmet@example.com"
}

// API'nin döndüğü:
{
  "name": "Ahmet Yılmaz",
  "email": "ahmet@example.com",
  "phone": "+90 532 xxx xxxx",
  "address": "İstanbul, Türkiye",
  "birth_date": "1985-05-15",
  "salary": 85000,
  "ssn": "12345678901",
  "credit_card": "************1234",
  "internal_employee_id": "EMP-9876"
}

Data Visibility olmadan, bu excessive exposure'u fark edemezsiniz. Maalesef bu son zamanlardaki en büyük problemlerden birisi. Frontedde görünen ile API'nın döndüğünün verinin aynı olmadığı senaryo

Görünürlük Olmadan API Security Ürünleri Nasıl Kör Kalır?

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

1. Trafiği İzle (Traffic Monitoring) → 2. Öğren (Behavioral Learning) → 3. Baseline Oluştur (Normal Pattern) → 4. Karşılaştır (Comparison) → 5. Anomali Tespit Et (Detection) → 6. Alarm Ver (Alert)

Ama bu döngü şuna bağlı:

→ Trafiği görmek
→ Tüm endpoint'leri bilmek
→ Data flow'u anlamak

Eğer API Gateway'den geçmiyorsa, güvenlik ürünü:

❌ Trafiği göremez
❌ Baseline oluşturamaz
❌ Anomali tespit edemez
❌ Saldırı anında kör kalır

Bu teorik değil, T-Mobile'da gerçekleşti:

Shadow API → Gateway'den geçmiyor
         ↓
API Security ürünü görmüyor
         ↓
41 gün saldırı devam ediyor
         ↓
37 milyon müşteri etkileniyor

Gerçek Vaka: Görünürlük Eksikliği = 8 Milyon Dolar Kayıp

Sektör: E-ticaret
Şirket Büyüklüğü: 5000+ çalışan
Olay: 2023 Q2

Ne Oldu?

Şirket, "modern ve güvenli" bir API altyapısına sahip olduğunu düşünüyordu:

✅ API Gateway var (yeni servisler için)
✅ WAF var
✅ API Security ürünü var ($400K yıllık lisans)
✅ SOC ekibi 7/24 izliyor

Ama...

Mikroservis mimarisine geçiş sırasında, bazı legacy API'lar eski yöntemle yayında kalmaya devam etmişti. Gateway'e entegre edilmemişti.

Saldırı:

Gün 1-3: Saldırgan, reconnaissance yaptı. Public endpoint'leri taradı.

Gün 4: Bir legacy API buldu: /api/v1/orders/export

Bu API, Gateway'den geçmiyordu
Direkt olarak load balancer'dan expose olmuştu
Rate limiting yoktu
Düzgün authentication yoktu (eski token sistemi)

Gün 5-12: Saldırgan, sistematik olarak tüm order verilerini export etti:

Müşteri isimleri
Adresler
Telefon numaraları
Sipariş geçmişleri
Kart son 4 haneleri

8 gün boyunca hiçbir alarm çalmadı.

Gün 13: Bir müşteri şikayeti sonrası fark edildi.

Hasar:

💰 Doğrudan Maliyetler:

Forensic analiz: $500K
Yasal danışmanlık: $800K
Müşteri bilgilendirme: $300K
Credit monitoring servisi (1 yıl): $1.2M
KVKK cezası: $2M
Toplam: $4.8M

💰 Dolaylı Maliyetler:

Müşteri kaybı: ~15,000 müşteri churn
Ortalama customer lifetime value: $180
İtibar hasarı: $3.2M
Toplam: $5.9M

Genel Toplam: $10.7M

Root Cause:

"Görünürlük eksikliği."

Legacy API, API Gateway'den geçmiyordu
API Security ürünü görmüyordu
SOC ekibi izlemiyordu
Envanterde yoktu

İlginç detay: Şirketin yüz binlerce dolarlık API Security ürünü mükemmel çalışıyordu. Ama görebildiği API'lar için. Legacy API görünmez olduğu için, 8 gün boyunca kör kaldı.

500ms Latency, Milyonlarca Dolarlık Kayıp

Şimdi başka bir boyuta bakalım: Performance ve Görünürlük İlişkisi

Bazı kuruluşlar şöyle düşünür:

"Gateway kullanırsak latency artar. Bu da müşteri deneyimini bozar. O yüzden bazı API'ları direkt expose edelim."

Bu mantık felaketle sonuçlanır.

Gerçek Rakamlar: Latency'nin İş Etkisi

Amazon'un Bulgusu:

100ms latency artışı = %1 satış kaybı
Amazon'un yıllık geliri: ~$500 milyar
100ms = $5 milyar kayıp

Google'ın Bulgusu:

500ms arama gecikmesi = %20 trafik kaybı

Akamai'nin Araştırması:

Sayfa yükleme 3 saniyeden fazla = %53 mobil kullanıcı terk eder

Ama Gateway Latency Ne Kadar Ekler?

Modern API Gateway'lerin ortalama latency'si: 5-15ms

Evet, yanlış okumadınız. 5-15 milisaniye.

Karşılaştırma:

Bileşen	Ortalama Latency
DNS lookup	20-120ms
TCP handshake	50-200ms
TLS handshake	50-100ms
API Gateway	5-15ms
Database query	50-500ms
External API call	200-2000ms

Gateway'in eklediği latency, total request time'ın %1-2'si.

Latency vs Security: Yanlış İkilem

Bazı mimari kararlar şöyle olur:

❌ YANLIŞ KARAR:

"Kritik API'ları Gateway'e koymayalım, 
 performans için direkt expose edelim."

Mantık: 10ms latency kaybetmeyelim
Sonuç: Shadow API oluşuyor
Risk: 41 gün görünmez saldırı
Maliyet: $350 milyon (T-Mobile)

Doğru yaklaşım:

✅ DOĞRU KARAR:

"Tüm API'ları Gateway'den geçirelim,
 performansı başka yöntemlerle optimize edelim."

Yöntemler:
- Caching (Redis, CDN)
- Connection pooling
- Async processing
- Database optimization

Sonuç: +5-10ms latency, %100 visibility
Risk: Kontrollü
Maliyet: Yönetilebilir

Maliyet-Fayda Analizi:

Senaryo 1: Gateway Yok (Latency: 0ms, Visibility: %40)

Yıllık Tasarruf (Latency): ~$0 (zaten minimal)
Yıllık Risk (İhlal olasılığı %15): $15M * 0.15 = $2.25M
Net: -$2.25M

Senaryo 2: Gateway Var (Latency: +10ms, Visibility: %100)

Gateway Maliyeti: $200K/yıl
Latency Etkisi: Minimal (~$50K/yıl max)
Yıllık Risk (İhlal olasılığı %2): $15M * 0.02 = $300K
Net: -$550K

Fark: $1.7M/yıl tasarruf

Gateway kullanmak, kullanmamaktan 3-4 kat daha ekonomik.

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

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

Görünürlük size şunları sağlar:

✅ 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:

Performans sorunlarını görebilirsiniz
Kullanılmayan API'ları kapatabilirsiniz
Kaynakları optimize edebilirsiniz

✅ Business Intelligence:

Hangi API'lar en çok kullanılıyor?
Hangi entegrasyonlar değer yaratıyor?
Monetization fırsatları nerede?

Son Söz: "You Can't Protect What You Can't See"

Siber güvenlikte en pahalı hata, "görmediğinizi bilmemektir."

API Security ürünleri harika araçlar. Ama araç, görünürlük olmadan işe yaramaz.

"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."

Sorular kendinize sorun:

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?
API Security ürününüz tüm trafiği analiz edebiliyor mu?

Eğer bu sorulara HAYIR diyorsanız, T-Mobile'ın 41 gününe çok yakınsınız.

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

Şimdiye kadar ne yapılmaması gerektiğini gördük. Şimdi doğru yolu görelim .

API güvenliği bir maraton, sprint değil. Ve doğru sırayla adım atmak kritik.

Yanlış Sıralama: Başarısızlığa Giden Yol

API Security ürünü al ($500K) --> Deploy et, beklentiler yüksek --> Sadece %30-40 API görünür --> Shadow API'lar tespit edilemiyor --> ROI düşük, hayal kırıklığı --> Proje rafa kalkıyor

Sonuç: Para harcandı, sorun çözülmedi, T-Mobile senaryosu devam ediyor.

Doğru Sıralama: 3 Adımlı Framework

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)

Kriterler:

High availability & scalability
Rate limiting, throttling, caching
Monitoring & logging capability
Security tool entegrasyonu
Yeni nesil sistem mimarilerine uygun (kubernetes, openshift)
CI/CD süreçlerinde entegre edilmek için APIOPS özelliği

Hızlı Kazanım:

Merkezi authentication
Rate limiting ile DDoS koruması
Basic logging

1.2 API Migration (Ay 2-4)

Öncelik Sırası:

External API'lar (En riskli)
PII işleyen API'lar (GDPR/KVKK kritik)
High-traffic API'lar (İş kritik)
Legacy API'lar (Shadow risk)
Internal API'lar

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 (Security için)

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

Hedef: Kontrol ve yönetim (Şuan bir çok kurum ve kuruluş bu aşamaya geçmeli. Gateway kullanıyor olabilirsiniz ama bu aşamayı kesinlikle atlamamalısınız!!!). Apinizer yol haritasında özellikle bu konu ile ilgili bir çok özellikler gelecek.

2.1 API Envanteri (Ay 6-8)

Envanter Şeması:

API adı, versiyon, endpoint'ler
Sahip (Product Owner, Tech Lead)
İş birimi, kullanım amacı
Data classification (PII, hassas veri)
SLA, rate limits
Authentication/Authorization
Compliance (GDPR, KVKK, PCI-DSS)

2.2 API Lifecycle Management (Ay 8-10)

Süreç:

Design → Develop → Test → Deploy → Monitor → Deprecate → Retire

Governance Kuralları:

Yeni API mutlaka envantere eklenmeli
Deprecated API'lar kontrollü kapatılmalı
Versiyon yönetimi standardize edilmeli
Documentation zorunlu

2.3 Shadow API Elimination (Ay 10-12)

Gateway trafiği vs envanter karşılaştırması
Shadow API tespiti
Sahiplik belirleme
Entegre et veya kapat

Çıktı: Güncel, tam envanter, Sahiplik ve sorumluluk netliği, Shadow API'lar eliminate edildi, Governance süreçleri ç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 API Security Platform Seçimi (Ay 12-13)

Vendor Değerlendirme:

Gateway entegrasyonu
Behavioral analysis capability
OWASP API Top 10 coverage
Threat intelligence

PoC Kriterleri:

Gerçek production trafiği üzerinde test
Shadow API tespit başarı oranı
False positive oranı
Response time impact

3.2 Deployment & Tuning (Ay 13-15)

API Security platform entegrasyonu
Baseline learning (2-4 hafta)
Policy tanımlama
Alert tuning (false positive azaltma)

3.3 Operasyonelleştirme (Ay 15-18)

SOC ekibi eğitimi
Playbook oluşturma
Incident response süreçleri
KPI tanımlama

Çıktı: API Security platform aktif, Behavioral analysis çalışıyor, Anomali tespiti operasyonel, Saldırı süreleri dakikalar (41 gün değil!)

Son Tavsiye: Sabırlı Olun

SOA hatalarını tekrarlamayın:

x "Ürün alırsak her şey çözülür"
x "Hızlı kazanım için adım atlayalım"
x "Önce security, sonra temeller"

Doğru yaklaşım:

✓ Adım adım ilerle
✓ Her adımı sağlamlaştır
✓ Quick wins'i kutla ama maraton kos
✓ Gateway → Management → Security sırasını bozma

"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

Şu anda şunu düşünüyorsunuz: "Güzel yazı ama bizde olmaz. Biz farklıyız."

T-Mobile de öyleydi. $350 milyon ödedikten sonra bile.

Ben yaklaşık 20 yıldır bu işin içindeyim. Ve neredeyse tüm kariyerim Web Servis/API'larla geçti. Hatta juniorken çalıştığım şirkette kariyerime ilk başladığım projede 3 farklı ekip vardı bir projeyi yapan, ben web service'leri yazan ekipteydim yani kariyerimin çok büyük bir kısmı bu konularlar geçti. Global firmalarda danışmanlık yaptım oradaki durumları da gözlemleme fırsatım SOA'da gördüm, şimdi API'da görüyorum. Herkes farklı olduğunu düşünür. Sonra aynı çukura düşer.

Gerçekten farklı mısınız? Gelin test edelim 10 Basit Soru

#	Soru	İyi Durum	Orta Risk	Yüksek Risk	Gerçek
1	Envanter: "Kaç API'niz var?" diye sorsam, şu anda, 5 dakikada cevap verebilir misiniz?	Evet, güncel listem var	Bilmiyorum, bakıp söylerim	Tahmin edebilirim ama emin değilim	"Tahmin" = Shadow API'lar var
2	Shadow API: Son 6 ayda "Bu API nereden çıktı?" dediğiniz oldu mu?	Hayır, hepsini biliyoruz	1-2 kere oldu	Sık karşılaşıyoruz	41 gün görünmez kalan API böyle başladı
3	Sahiplik: Rastgele bir API seçin. Gerçek sahibi kim? (Kod yazan değil, iş sorumlusu)	Biliyorum	Bulurum ama araştırma lazım	Kimse sahiplenmiyor	Sahibi olmayan = Korumasız
4	Gateway: TÜM API'larınız tek Gateway'den geçiyor mu? İstisna yok mu?	Evet, %100 hepsi	Çoğu geçiyor, birkaç istisna var	Hayır, dağıtık yapı	T-Mobile'ın "istisnası" 37M müşteriye mal oldu
5	Legacy: 3+ yıl önce yazılmış, hala çalışan API'larınız var mı?	Yok veya çok az	Var ama takip ediyoruz	Var, durumunu bilmiyoruz	Legacy = Zombie API = Zaman ayarlı bomba
6	Yeni Proje: Son 1 yılda kurumunuza yeni yazılım firması geldi mi?	Hayır	Evet, API'larını entegre ettik	Evet, entegrasyon yarım kaldı	Her yeni firma = Potansiyel Shadow API
7	Mikroservis: Her takım kendi API'sını özgürce deploy edebiliyor mu?	Hayır, sıkı kontrol var	Evet ama governance var	Evet, özerk çalışıyorlar	Özerklik ≠ Kontrolsüzlük
8	Security Ürünü: API Security ürününüz var mı? Tüm API'ları görebiliyor mu?	Var, her şeyi görüyor	Yok henüz	Var, sadece Gateway'dekileri görüyor	"Sadece Gateway'dekileri" = Shadow API'lar görünmez
9	Geçmiş: Son 2 yılda API ile ilgili güvenlik olayınız oldu mu?	Hayır	Küçük bir olay oldu	Evet, ciddi bir şey	"Küçük" = Tespit ettiğiniz. Peki etmediğiniz?
10	Uyku Testi: Gece rahat uyuyabiliyor musunuz?	Evet, rahatım	Bazen endişeleniyorum	Sürekli düşünüyorum	Bir IT çalışanı olarak yukarıdaki 9 maddeyi boş verin sadece bunun cevabı bile gerçek durumu gösterir

SOA'dan Öğrendiğim Tek Şey

20 yıl önce SOA'ya aynı hataları yaptık:

"Ü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 100 kat 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.".