Amaç ve Tehdit Modeli

Rate limiting; tek bir istemci, kullanıcı, servis hesabı, tenant veya IP adresinin API kaynaklarını aşırı tüketmesini sınırlayarak kullanılabilirliği ve hizmet sürekliliğini korur. Hedef yalnızca saldırıları engellemek değil; hatalı istemci davranışlarını, kontrolsüz otomasyonu, kimlik bilgisi kötüye kullanımını ve beklenmeyen maliyet artışlarını erken fark etmektir.

Uygulamadan önce şu kararları yazılı hâle getirin:

• Parola sıfırlama, arama, dosya işleme ve rapor üretme gibi yüksek maliyetli uç noktalar hangileri?
• Limit IP, kullanıcı, API anahtarı, tenant veya bunların güvenilir bir birleşimi üzerinden mi uygulanacak?
• Aşım durumunda istek reddedilecek mi, geciktirilecek mi, yoksa daha düşük öncelikli bir kuyruğa mı alınacak?
• Ortak NAT, mobil ağ veya kurumsal proxy kullanan meşru kullanıcıların haksız biçimde engellenmesi nasıl önlenecek?
• Limit politikasının hedefi istek sayısı mı, istek başına işlem maliyeti mi, yoksa eşzamanlı görev sayısı mı olacak?

Yetkili testler yalnızca yazılı izin bulunan sistemlerde, belirlenmiş hız, süre ve kapsam sınırları içinde yürütülmelidir. Üretimde kontrollü test yapılacaksa geri dönüş planı, izleme kapsamı ve sorumlu iletişim kişisi önceden belirlenmelidir.

Algoritma ve Katmanlı Uygulama Tasarımı

Sabit pencere uygulanması kolaydır; ancak pencere sınırlarında ani istek kümelerine izin verebilir. Kayan pencere, token bucket ve leaky bucket yöntemleri daha dengeli sonuçlar sunabilir. Seçim yapılırken yalnızca teorik kapasite değil, dağıtık düğümler arasındaki sayaç tutarlılığı, veri deposu gecikmesi ve hata durumundaki davranış da ölçülmelidir.

Pratikte katmanlı bir yaklaşım kullanılabilir:

• Kenar veya CDN katmanı, belirgin trafik patlamalarını uygulamaya ulaşmadan azaltır.
• API gateway, kimlik, tenant ve uç nokta bazlı ortak politikaları uygular.
• Uygulama katmanı, işlemin maliyetini, kullanıcının rolünü ve iş kuralını değerlendirir.
• Kuyruk katmanı, uzun süren görevleri doğrudan HTTP isteği yerine kontrollü biçimde işler.

Yalnızca IP adresine güvenmek çoğu senaryoda yeterli değildir. Kimliği doğrulanmış isteklerde kullanıcı, servis hesabı veya tenant bilgisi; anonim isteklerde ise IP, uç nokta ve güvenilir istemci sinyalleri birlikte değerlendirilebilir. İstemcinin gönderdiği başlıklar, güvenilir proxy zinciri doğrulanmadan kimlik kanıtı olarak kabul edilmemelidir.

Güvenli Yanıtlar ve Hata Yönetimi

Limit aşımında tutarlı bir HTTP yanıtı verilmesi, istemcilerin doğru geri çekilme davranışı uygulamasını sağlar. Uygulama, uygun durumlarda 429 yanıtı ve sınırlı bir bekleme bilgisi döndürebilir. Yanıt gövdesi; iç sistem ayrıntılarını, limit anahtarını veya başka kullanıcıların durumunu açıklamamalıdır. Bekleme süresi bilgisi, saldırgana sınırsız deneme planı sunacak ayrıntıya dönüşmemelidir.

İstemci tarafında şu davranışlar teşvik edilmelidir:

• Limit yanıtını tanımak ve isteği art arda tekrarlamamak.
• Üstel geri çekilme ve rastgele küçük bir bekleme payı kullanmak.
• Başarısız istekleri sınırsız paralellikte yeniden göndermemek.
• İşlem kimliği veya idempotency anahtarıyla aynı işlemin tekrar üretilmesini önlemek.

Parola deneme, doğrulama kodu ve parola sıfırlama akışlarında rate limit tek savunma değildir. Güvenli parola saklama, çok faktörlü kimlik doğrulama, hesap kilitleme yerine kademeli gecikme ve anomali izleme birlikte değerlendirilmelidir. Hata mesajları hesap varlığını açığa çıkarmamalıdır.

Loglama, Metrikler ve Alarm Kriterleri

Rate limit olaylarını yalnızca toplam sayaç olarak saklamayın. Gereksinim ve veri koruma politikalarına uygun olarak şu alanlar kaydedilebilir:

• Zaman damgası, servis ve uç nokta adı.
• Sonuç: izin verildi, geciktirildi veya reddedildi.
• Politika adı ve güvenli istek korelasyon kimliği.
• Kimlik türü: anonim, kullanıcı, servis hesabı veya tenant.
• İşlem süresi, yanıt kodu ve kaynak tüketimi.

IP adresi, kullanıcı adı ve token gibi alanlar erişim yetkisine göre korunmalı; gereksiz kişisel veri saklanmamalı ve saklama süresi tanımlanmalıdır. Tokenların tamamı loglanmamalı; ihtiyaç varsa geri döndürülemeyecek biçimde maskelenmeli veya özetlenmelidir.

Alarm eşikleri tek bir olaydan çok eğilim ve bağlamla belirlenmelidir. Aynı tenant için ani ret artışı, çok sayıda hesaba yayılan başarısız doğrulama, tek bir anahtarın beklenmeyen coğrafyalardan kullanılması veya normal saatler dışındaki kaynak tüketimi inceleme başlatabilir. Alarmlar, olay müdahale ekibinin gerçekten değerlendirebileceği sayıda tutulmalıdır.

Yetkili Test ve İşletim Kontrol Listesi

Test ortamında düşük riskli ve ölçülebilir senaryolar hazırlayın. Her testten önce başlangıç trafiğini, beklenen limiti, başarı ölçütünü ve geri dönüş koşulunu kaydedin.

• Tek bir istemcinin limit aşımında beklenen yanıtı alıp almadığını doğrulayın.
• Aynı NAT arkasındaki farklı kullanıcıların gereksiz biçimde engellenmediğini kontrol edin.
• Dağıtık düğümlerde sayaçların kabul edilebilir tutarlılıkta olduğunu ölçün.
• Kimlik doğrulama öncesi ve sonrası politikaların birbirini atlamadığını inceleyin.
• Limit servisi kullanılamadığında güvenli varsayılan davranışı ve hata bütçesini test edin.
• Loglarda gizli bilgi bulunmadığını, korelasyon kimliklerinin çalıştığını ve alarmların üretildiğini doğrulayın.
• Politika değişikliklerini kod incelemesi, kademeli dağıtım ve geri alma planıyla yönetin.

Başarıyı yalnızca “saldırı durdu” ölçütüyle değerlendirmeyin. İyi tasarım meşru kullanıcı deneyimini korur, kaynak tüketimini öngörülebilir kılar, olay incelemesini kolaylaştırır ve politika değişikliklerinin etkisini ölçmeye izin verir. Rate limit kurallarını gerçek trafik verileriyle düzenli olarak gözden geçirin; yanlış pozitifleri, ret oranlarını ve gecikme etkisini izleyerek kontrollü biçimde güncelleyin.