AWS API Gateway ve Ters Proxy Zafiyetleri: Bulut Güvenliğinde Görünmez Tehdit

Son iki yıl içinde kurumların %57'si API kaynaklı bir veri ihlali yaşadı (Traceable 2025 State of API Security, 2025). Bulut bilişimin hızı, maalesef beraberinde tehlikeli yapılandırma hatalarını da getiriyor. Mikro servislerin dünyaya açılan kapısı olan API'ler, artık saldırganların ilk hedefi. Bu yazıda, AWS API Gateway üzerindeki yaygın yapılandırma hatalarını, IP rotasyon saldırılarını ve Lambda yetkilendirici (authorizer) açıklarını teknik bir bakış açısıyla inceliyoruz.

1. API Ağ Geçitleri Neden Güvenliğin Merkezindedir?

Kurumların yalnızca %21'i API katmanındaki saldırıları yüksek doğrulukla tespit edebiliyor (Traceable, 2025). Modern web trafiğinin büyük bir kısmı API'ler üzerinden akar. AWS API Gateway gibi servisler, arka uç sistemlerine (backend) doğrudan erişimi gizleyerek kritik bir koruma katmanı oluşturur.

Geleneksel mimarilerin aksine API Gateway; yük dengeleme, SSL sonlandırma, JWT doğrulama ve hız sınırlama gibi işlemleri tek bir merkezde toplar. İstek, hedefe ulaşmadan önce bir dizi güvenlik filtresinden geçer. Bu durum, her servisin kendi güvenliğini sağlaması zorunluluğunu ortadan kaldırarak tutarlılık sağlar.

Aşağıdaki diyagramda, güvenli bir API isteğinin arka uç servislerine nasıl yönlendirildiği görülmektedir:

Bu merkezi yapı, güvenliği artırsa da yapılandırma hatalarının etkisini de merkezileştirir. Güvenlik kurallarındaki ufak bir açık, tüm ekosistemin tehlikeye girmesine neden olabilir.

2. FireProx ile IP Rotasyonu Saldırıları Nasıl Yapılır?

API saldırılarında kaba kuvvet (brute force) yöntemleri, ihlallerin %27'sini oluşturuyor (Traceable, 2025). Klasik güvenlik sistemleri, aynı IP'den gelen çok sayıda isteği anında fark edip engeller. Ancak bulutun gücü burada saldırganın lehine çalışabiliyor.

FireProx gibi araçlar, API Gateway'i bir "ters proxy" olarak kullanır. Saldırganın her isteği AWS üzerinden geçer ve her seferinde farklı bir AWS IP'si atanır. Hedef sunucu, saldırıyı tek bir kaynaktan değil, dünyanın her yerinden gelen meşru AWS trafiği sanır. Bu durum, sadece IP bazlı engelleme yapan sistemleri tamamen etkisiz bırakır.

Saldırganların IP rotasyonu için doğrudan AWS altyapısını kullanması, güvenlik ekiplerini zorlu bir ikilemde bırakır. Savunma tarafı AWS IP'lerini topyekün engellemeye kalkarsa, bu durum hedefin entegre olduğu diğer meşru bulut servislerini ve müşteri trafiğini de kesintiye uğratır. Bu taktik, yalnızca davranışsal analize ve API anormallik tespitine sahip olmayan sistemleri kolayca alt eder.

3. Lambda Authorizer'lardaki Joker Karakter Riski Nedir?

Bulut ortamındaki yanlış yapılandırmalar, güvenlik olaylarının %23'ünden sorumlu tutuluyor (Indusface, 2025). Indusface bu veriyi SentinelOne analizine dayandırıyor. Lambda authorizer'lar, isteğin geçerliliğini kontrol edip bir IAM politikası döndürür. Ancak burada kullanılan joker karakterler (*), büyük bir güvenlik boşluğu yaratabiliyor.

"Açgözlü Genişleme (Greedy Expansion)" olarak adlandırdığımız bu durumda, * karakteri amaçlanan sınırların dışına taşar. IAM politikasındaki tek bir yıldız, test ortamı için üretilmiş sıradan bir token'ın üretim (prod) ortamındaki kritik verilere erişmesine izin verebilir.

# 1. Beklenen Davranış: Test ortamına yetkili erişim
curl -H "authorizationToken: hackpapertest" https://api.hedefsite.com/test/kullanicilar/
> {"durum": "basarili"}

# 2. Zafiyetin Tetiklenmesi: Aynı token ile PROD ortamına erişim (Bypass)
curl -H "authorizationToken: hackpapertest" https://api.hedefsite.com/prod/admin/
> {"durum": "başarılı", "admin_anahtarı": "gizli_veri"}

4. API Güvenliğini Sağlamak İçin Hangi Adımlar Atılmalı?

Kurumsal veri ihlallerinde saldırganların 0-day açıklarını kullanma oranı %32 seviyesinde (Indusface, 2025). Ancak asıl hasarı genellikle basit yapılandırma hataları veriyor. API Gateway seviyesinde güvenliği sağlamak için şu adımları mutlaka uygulayın:

• Erişim Sınırlarını Daraltın (Least Privilege): Lambda yetkilendiricilerinin döndürdüğü politikalarda ARN kısıtlamalarını kesin sınırlarla çizin. Hangi kullanıcının hangi method ile hangi path üzerine gideceği net olmalıdır.
• Hız Sınırları ve Kotalar (Throttling): Kimlik doğrulamasından geçmiş olsa bile, her bir API anahtarı (API Key) için kullanım planları oluşturun. Ani trafik artışlarını kesmek kaba kuvvet saldırılarını durdurur.
• Görünürlüğü Artırın (Logging & Monitoring): Sadece engellemeye odaklanmak yeterli değildir. IP rotasyonu gibi sinsi saldırıları tespit edebilmek için API Gateway üzerinde Execution Logs ve AWS CloudTrail entegrasyonlarını aktif hale getirin. Anormal yetkilendirme hatalarını yakalamak için CloudWatch alarmları kurun.
• Karşılıklı Kimlik Doğrulama (mTLS): Özellikle B2B iletişimde API Gateway'in sunduğu mTLS özelliğini aktif ederek, yalnızca geçerli bir X.509 sertifikasına sahip istemcilerin ağ geçidine ulaşmasını sağlayın.
• WAF Entegrasyonu: AWS WAF'ı API Gateway'in hemen önüne yerleştirin. IP itibarına (reputation) güvenmek yerine, davranışsal anormallikleri tespit eden kurallar yazın.
• Bağımlılıkları Dışarı Kapatın: Sadece iç sistemlerin konuştuğu bir API'niz varsa, onu internete açmak yerine Özel Ağ (VPC Link) üzerinden haberleştirin.

Sıkça Sorulan Sorular

Sonuç

Bulut servislerinin doğası gereği sunduğu esneklik, yapılandırma aşamasında en büyük zayıflığa dönüşebiliyor. AWS API Gateway, trafiği güvenli şekilde yönetmek için devasa yetenekler sunsa da, FireProx benzeri araçlarla saldırganlara kaynak IP gizleme avantajı da yaratabiliyor. IAM politikalarındaki tek bir * karakterinin tüm veri tabanını dışarıya açabileceği bir ekosistemde güvenliği sağlamak, varsayılan ayarları kabul etmekle değil; her katmanda şüpheci ve kısıtlayıcı (Zero Trust) bir mimari kurmakla mümkün olur.

Kaynakça

• Traceable. (2025). 2025 State of API Security Report. Traceable
• Daily.dev. (2026). The Developer Guide to API Security. Daily.dev
• Indusface. (2025). 227 Cybersecurity Statistics for 2025. Indusface
• SentinelOne. (2025). 9 Critical AWS Security Issues. SentinelOne
• AWS. (2026). AWS Security Documentation. AWS