Meşru Trafiği Bozmadan API DoS Önleme

API DoS Çoğu Zaman Ekonomi Problemidir

Birçok ekip API hizmet reddi (Denial of Service — DoS) saldırısını tamamen bir istek hacmi sorunu olarak görür: bant genişliğini dolduracak ya da bağlantı limitlerini tüketecek kadar trafik. Bu model eksik. Daha sık karşılaşılan durumda API DoS bir ekonomi sorunudur: saldırgan, tam tablo veritabanı taraması, karmaşık join, ağır arama indeksi sorgusu, dosya üretme veya zincirlenmiş üçüncü taraf API çağrısı gibi orantısız biçimde pahalı arka plan işini, hedefe yüklediği hesaplama yüküyle kıyaslandığında kendisi için önemsiz bir maliyetle tetikleyebildiği bir endpoint bulur.

Maliyet Amplifikasyonu Saldırı Kalıpları

API DoS ekonomisi, maliyet amplifikasyonu kalıplarını incelediğinizde netleşiyor — saldırganların ucuz istekleri pahalı arka plan işlemlerine dönüştürdüğü spesifik yollar:

| Saldırı Kalıbı | Saldırgan Maliyeti | Savunmacı Maliyeti | Örnek |

|---------------|-------------------|-------------------|-------|

| Sınırsız arama | 1 HTTP isteği | Tam tablo DB taraması | Sayfalama olmadan GET /vulns?q=* |

| Derin sayfalama | 1 HTTP isteği | Büyük offset DB sorgusu | GET /export?page=50000 |

| İç içe toplama | 1 HTTP isteği | Çok join hesaplaması | GET /stats?group=vendor&altgroup=urun |

| Dosya üretme | 1 HTTP isteği | CPU yoğun işleme | GET /export?format=pdf&rows=100000 |

| Zincirleme üçüncü taraf | 1 HTTP isteği | N×harici API gecikmesi+maliyet | Öğe başına AI çıkarımıyla toplu çeviri |

Hangi endpoint'lerinizin bu kalıplara uyduğunu anlamak ilk adım. Öte yandan yalnızca hız sınırlaması maliyet amplifikasyonunu durdurmaz — saldırgan her IP başına hız limitinin altında kalırken her seferinde en pahalı yolu tetikleyebilir.

Kapsama Göre Hız Sınırlama Stratejisi

Katmanlı bir hız sınırlama stratejisi, farklı kötüye kullanım kimliklerini dikkate alır. Yalnızca IP başına limit, dağıtık altyapıyla kolayca aşılır. Eksiksiz bir strateji dört kapsamı da içermek zorunda:

| Kapsam | Önerilen Limit (örnek) | Amaç |

|--------|----------------------|------|

| IP başına | Okuma: 100 istek/dk, yazma: 10 istek/dk | Anonim yoklamayı engelle |

| Kullanıcı başına | Kimlik doğrulamalı 300 istek/dk | Normal kullanıma izin ver, kötüye kullanımı yakala |

| Tenant başına | Toplam 1.000 istek/dk | Paylaşımlı altyapıyı gürültülü komşulardan koru |

| Global | %80 kapasitede devre kesici | Son çare kullanılabilirlik koruması |

Sadece Rate Limiting Neden Yetmez?

Rate limiting zorunlu bir kontrol ama tek başına yetmez. Kapsamlı bir API dayanıklılığı modeli şu konuları da kapsamalıdır:

istek hacminden bağımsız olarak bazı işlemlerin diğerlerinden kat kat daha pahalı olduğu endpoint maliyet asimetrisi.

anonim yoklamayı kimliği doğrulanmış kötüye kullanımdan ayırt etmek için kimlik doğrulama durumu ve abuse kimliği.

sınırsız sonuç kümesi çıkarımını önlemek için pagination disiplini.

keyfi biçimde pahalılaştırılabilen arama ve filtreleme işlemleri için sorgu karmaşıklık limitleri.

aşırı yük altında tamamen çökmek yerine servis kullanılabilirliğini koruyan graceful degradation ve backpressure mekanizmaları.

Hedef Sadece Engellemek Değil, Adaleti Korumak

Etkili API DoS önleme, meşru yüksek hacimli kullanıcıları gereksiz yere cezalandırmadan servis kullanılabilirliğini korur. Bunun için kontrol stratejisinin normal yüksek kullanım kalıplarını düşmanca amplifikasyon davranışından doğru biçimde ayırt etmesi gerekir; bu ayrım salt eşik karşılaştırmalarıyla değil, davranışsal bağlamla mümkün olur.

MyVuln Yaklaşımı

MyVuln bu alanda en çok, dış maruziyet envanteri, gözlemlenen API zayıflık kalıpları ve abuse sinyal verisi tek bir görünümde ilişkilendirildiğinde değer üretir. Platform, hangi dışarıya açık API yollarının operasyonel maliyet amplifikasyonuna veya servis kullanılabilirliği hasarına dönüştürülme riskinin en yüksek olduğunu önceliklendirilmiş biçimde ortaya koyuyor — güvenlik ekiplerine hizmet dışı bırakmanın teorik olarak mümkün olduğuna dair genel bir ifade değil, somut bir remediation listesi sunuyor.

API katmanında hizmet kesintisi çoğu zaman saldırganın aşırı sofistike olmasından değil; her isteğin eşit maliyet taşıdığı varsayımından kaynaklanır. Gerçekte basit bir kayıt okuma ucu ile bulk export, toplu arama, zaman serisi toplama ya da PDF oluşturma ucu arasındaki hesaplama, I/O, sorgu sayısı, dış servis gecikmesi ve bellek tüketimi farkı büyük boyutlara ulaşabilir. Her ikisine aynı istek sayısı limitini uygulamak, pahalı bir işlemin herhangi bir kimlik doğrulanmış kullanıcı tarafından hizmet engelleme (DoS) vektörüne dönüştürülmesine zemin hazırlar.

Etkili API DoS savunması önce maliyet modelini çıkarır. Pratik bir uç nokta sınıflandırması:

| Uç nokta türü | Maliyet profili | Limit yaklaşımı |

|---|---|---|

| Basit kayıt okuma | Düşük CPU, tek DB sorgusu | Yüksek istek/dak, kullanıcı başına |

| Filtreli liste | Orta I/O, indeksli sorgu | Orta istek/dak, kullanıcı başına |

| Zaman serisi toplama | Yüksek CPU, tam tarama potansiyeli | Düşük istek/dak, kuyruk |

| Bulk export (CSV/JSON) | Yüksek I/O, satır limiti zorunlu | Çok düşük istek/saat, asenkron |

| PDF oluşturma | Yüksek CPU + bellek | Eşzamanlılık sınırı (örn. 2 eşzamanlı) |

| N downstream'e fan-out | Değişken, tahmin edilemez | İstek başı timeout + circuit breaker |

Ölçüm yapılmadan belirlenen limitler çoğunlukla sezgisel tahmin olmaktan öteye geçemez. Raporlama, toplu arama, tenant bazlı listeleme ve PDF oluşturma uçları bu maliyet varyansının en belirgin olduğu yerlerdir; tek bir yanlış metriklenmiş istek tüm tenant'lar için paylaşılan altyapıyı tüketebilir.

İkinci savunma katmanı kontrollü bozulma (graceful degradation) tasarımıdır. Yüksek yük altında tüm sistemin aynı anda yavaşlamasına izin vermek yerine pahalı kod yollarının kademeli olarak kısıtlanması, öngörülebilir sorguların cache katmanına yönlendirilmesi, eşzamanlılık kontrollerinin ağır işlem sayısını sınırlandırması ve istemcilerin tutarlı hata davranışı alması gerekir. Amaç yalnızca saldırıyı durdurmak değil; kapasite kısıtlı olduğunda hangi kullanıcıların hizmet almaya devam edeceğine bilinçli karar verebilmektir. İyi tasarlanmış bir API erişilebilirlik stratejisi herkese kapıyı kapatan sistem üretmez; baskı altında bilinçli kabul kararı alabilen sistem üretir.