Ağ & Edge Güvenliği Sürekli / Aylık Hizmet

Hız Sınırlama (Rate Limiting)

Hız sınırlama, belirli bir anahtar (IP, kullanıcı, API anahtarı) için birim zamanda kabul edilecek istek sayısını sınırlayarak kaba kuvvet, kaynak tüketimi ve API kötüye kullanımını azaltır. Token-bucket ve sliding-window gibi algoritmalarla, kısa süreli meşru yükselmelere (burst) izin verirken sürekli aşırı istekleri throttle eder. Doğru tasarlanmış limit, meşru kullanıcıyı hiç fark ettirmeden yalnızca istismarı hedefler.

8 teknik alan 5 adımlı süreç 5 teslimat
WAF / DDoS Koruması Talep Et Ücretsiz Güvenlik Kontrolü Yap
Teknik kapsam
Token-bucket ve sliding-window hız sınırlama algoritmaları
Anahtar bazlı sınırlama: IP, kullanıcı, oturum, API anahtarı
Uç nokta hassasiyetine göre farklılaştırılmış limitler
Kaba kuvvete karşı giriş/parola sıfırlama uç noktası koruması
API kota yönetimi, katman (tier) bazlı limit ve aşım politikası
Neden ihtiyacınız var?

Bu hizmet hangi sorunu çözer?

Hız sınırı olmayan uç noktalar sınırsız denemeye açıktır: giriş sayfası kaba kuvvetle bombardıman edilir, arama/rapor gibi pahalı uç noktalar döngü içinde çağrılarak sunucu tüketilir, API anahtarları paylaşılıp kötüye kullanılır. Tek bir kötü niyetli veya kusurlu istemci, tüm servisin performansını düşürebilir. Öte yandan yanlış tasarlanmış bir limit — çok düşük eşik, yanlış anahtar seçimi (ör. NAT arkasındaki tüm kullanıcıları tek IP sayma) — meşru trafiği 429 hatalarıyla bloklar ve kullanıcı deneyimini bozar.

  • Giriş/parola sıfırlama uç noktalarına sınırsız kaba kuvvet denemeleri
  • Pahalı uç noktaların (arama, rapor, dışa aktarma) döngüde çağrılıp kaynağı tüketmesi
  • API anahtarlarının kötüye kullanımı ve maliyet/kota aşımı
  • Tek bir kusurlu istemcinin tüm servisi yavaşlatması
  • Yanlış yapılandırılmış limitin meşru kullanıcıları 429 ile engellemesi
Neden önemli?

Bu sorunu görmezden gelmenin riski

Kaba kuvveti ekonomik olmaktan çıkarırGiriş uç noktasına dakikada belirli sayıda deneme sınırı, otomatik parola tahminini pratik olarak imkânsız hale getirir. Sınır olmadan saldırgan sınırsız deneme yapar.
Kaynakları adil paylaştırırHız sınırı, tek bir kullanıcının veya botun servisi tekeline almasını önler; kaynaklar tüm kullanıcılar arasında öngörülebilir biçimde dağılır.
Doğru anahtar seçimi kritikSadece IP'ye göre limit, kurumsal NAT veya mobil ağlarda binlerce meşru kullanıcıyı tek kaynak sayar. IP + kullanıcı + API anahtarı gibi katmanlı anahtarlama gerekir.
Burst toleransı deneyimi korurToken-bucket, kısa süreli meşru yoğunlaşmalara izin verirken sürekli aşırı yükü sınırlar. Bu, meşru kullanıcıyı cezalandırmadan istismarı yakalar.
Kapsam

Neyi izler ve koruruz?

Limit tasarımı

  • Uç nokta bazlı limit: giriş, arama, ödeme, API için ayrı eşikler
  • Anahtar seçimi: IP, kullanıcı, oturum, API anahtarı veya bunların birleşimi
  • Algoritma seçimi: token-bucket, sliding-window, sabit pencere
  • Burst toleransı ve yenilenme hızının (refill) kalibrasyonu

Uygulama ve gözlem

  • Aşım yanıtı: 429 + Retry-After başlığı ve tutarlı hata gövdesi
  • Kademeli yanıt: uyar → yavaşlat (throttle) → geçici blok
  • Meşru yüksek hacimli istemciler için kota/istisna yönetimi
  • Limit isabet oranları ve 429 metriklerinin izlenmesi
Teknik kapsam

Ele aldığımız teknik alanlar

Token-bucket ve sliding-window hız sınırlama algoritmalarıAnahtar bazlı sınırlama: IP, kullanıcı, oturum, API anahtarıUç nokta hassasiyetine göre farklılaştırılmış limitlerKaba kuvvete karşı giriş/parola sıfırlama uç noktası korumasıAPI kota yönetimi, katman (tier) bazlı limit ve aşım politikasıStandart 429 yanıtı, Retry-After ve hız-limiti başlıklarıNAT/proxy senaryolarında doğru istemci kimliği çıkarımıLimit metrikleri, false-positive izleme ve uyarı
Metodoloji

Nasıl çalışırız?

Uç nokta ve trafik analiziHangi uç noktaların hassas (giriş, ödeme) veya pahalı (arama, rapor) olduğunu belirler, meşru istek hızlarının taban çizgisini çıkarırız.
Anahtar ve algoritma seçimiHer uç nokta için doğru sınırlama anahtarını (IP/kullanıcı/API anahtarı) ve algoritmayı, NAT/proxy senaryolarını dikkate alarak seçeriz.
Eşik kalibrasyonuLimitleri önce gözlem/loglama modunda çalıştırıp meşru trafiği kaç 429 üreteceğini ölçer, eşikleri meşru zirveyi bloklamayacak biçimde ayarlarız.
Aşım yanıtı tasarımıStandart 429 + Retry-After yanıtı, istemcilerin doğru geri çekilmesini sağlar; kademeli yanıtla önce uyarır, sonra sınırlarız.
İzleme ve ayarLimit isabetlerini ve 429 oranlarını izler, meşru kullanıcıların takılmadığını doğrular, saldırı desenleri değiştikçe eşikleri güncelleriz.
Örnek bulgular

Tipik olarak neler tespit ederiz?

Aşağıdakiler illüstratif örneklerdir; gerçek müşteri verisi değildir.

Yüksek

Giriş uç noktasında hız sınırı yok (örnek bulgu)

Etki

Parola tahmin/credential stuffing denemeleri sınırsız yapılabiliyor, hesap devralma riskini ciddi biçimde artırıyordu.

Öneri

Giriş ve parola sıfırlama uç noktalarına IP+kullanıcı bazlı sıkı limit uygula, aşımda kademeli gecikme ve challenge ekle.

Yüksek

Sadece IP bazlı limit meşru kullanıcıları blokluyor (örnek bulgu)

Etki

Kurumsal NAT arkasındaki tüm çalışanlar tek IP sayıldığı için ortak limit tükeniyor, meşru kullanıcılar 429 alıyordu.

Öneri

Anahtarı kullanıcı/oturum bazlı katmanla, IP'yi yalnızca kimlik doğrulanmamış trafikte kullan.

Orta

Pahalı rapor uç noktası korumasız (örnek bulgu)

Etki

Ağır bir dışa-aktarma uç noktası döngüde çağrılabiliyor, tek istemci veritabanını doyuruyordu.

Öneri

Pahalı uç noktaya düşük eşikli token-bucket limiti ve eşzamanlılık sınırı uygula, uzun işlemleri kuyruğa al.

Düşük

429 yanıtında Retry-After eksik (örnek bulgu)

Etki

İstemciler ne zaman tekrar deneyeceğini bilmeden agresif retry yapıyor, gereksiz yük ve kötü deneyim oluşuyordu.

Öneri

Standart 429 yanıtına Retry-After ve hız-limiti başlıklarını ekle, istemci geri-çekilme davranışını yönlendir.

Sonuç

Ne teslim alırsınız, kimler için?

Ne teslim alırsınız?

  • Uç nokta bazlı hız sınırlama politikası ve eşik tablosu
  • Anahtar/algoritma seçim gerekçeleri ve yapılandırması
  • Standart 429/Retry-After yanıt yapılandırması
  • Meşru yüksek hacimli istemciler için kota/istisna listesi
  • Limit metrikleri panosu ve 429 anomali uyarıları

Kimler için?

  • Giriş/kayıt/parola sıfırlama akışı olan tüm platformlar
  • API sağlayıcıları ve kota/tier yönetimi gereken ürünler
  • Arama, rapor, dışa-aktarma gibi pahalı uç noktaları olan siteler
  • Tek istemci kötüye kullanımından etkilenen servisler
Ne zaman?

Bu hizmeti ne zaman düşünmelisiniz?

  • Giriş uç noktanız kaba kuvvet denemeleri alıyorsa
  • Belirli uç noktalar tek istemci yüzünden yavaşlıyorsa
  • API anahtarları kötüye kullanılıyor veya kota aşılıyorsa
  • Meşru kullanıcılar açıklanamayan 429 hataları bildiriyorsa
Karşılaştırma

Hız Sınırlama ile DDoS Koruması farkı

Hız SınırlamaDDoS Koruması
Amaçİstek hızını anahtar bazında dengelemekBüyük ölçekli saldırı selini eritmek
Ölçekİstemci/anahtar düzeyinde adil kullanımAğ/edge düzeyinde hacimsel azaltma
Tipik tehditKaba kuvvet, API kötüye kullanımıDağıtık flood, botnet saldırısı
GranülerlikUç nokta + anahtar hassasiyetiTrafik profili ve kapasite
Birlikte mi?Evet — L7 saldırılarında ilk frenEvet — hacimsel katmanda tamamlayıcı
SSS

Sıkça Sorulan Sorular

Token-bucket algoritması nedir?
Her anahtar için bir "kova" düşünün: sabit hızla token eklenir, her istek bir token harcar. Kova boşsa istek sınırlanır. Bu model, kısa süreli meşru yoğunlaşmalara (burst) izin verirken sürekli aşırı isteği throttle eder.
Hız sınırı meşru kullanıcıyı engeller mi?
Doğru kalibre edilmişse hayır. Eşikleri meşru trafiğin zirvesini bloklamayacak biçimde belirler ve önce gözlem modunda ölçeriz. Yanlış eşik veya yanlış anahtar seçimi (ör. NAT'ı tek IP sayma) meşru kullanıcıyı engelleyebilir; bu yüzden ayar kritiktir.
IP'ye göre mi, kullanıcıya göre mi limitlemeli?
Duruma göre. Kimlik doğrulanmış trafik için kullanıcı/oturum bazlı limit daha adildir; kimlik doğrulanmamış trafikte IP kullanılır. Kurumsal NAT ve mobil ağlar tek IP arkasında çok kullanıcı barındırdığından, çoğu zaman katmanlı bir yaklaşım gerekir.
429 yanıtı ne anlama gelir?
HTTP 429 "Too Many Requests" (çok fazla istek) demektir. İyi bir uygulama, buna Retry-After başlığı ekleyerek istemciye ne zaman tekrar deneyebileceğini söyler; böylece istemci agresif retry yapmadan doğru geri çekilir.
Hız sınırlama DDoS korumasının yerini tutar mı?
Hayır. Hız sınırlama istemci/anahtar düzeyinde çalışır ve L7 kötüye kullanımına ilk frendir; ancak dağıtık, çok kaynaklı bir DDoS selini tek başına eritemez. İkisi birlikte, farklı ölçeklerde tamamlayıcı çalışır.
Farklı uç noktalara farklı limitler koyabilir miyim?
Evet ve koymalısınız. Giriş uç noktası çok sıkı, genel içerik uç noktaları gevşek, pahalı rapor uç noktaları ayrı ve düşük eşikli olmalıdır. Tek tip limit ya çok kısıtlayıcı ya çok gevşek olur.
API anahtarı başına kota nasıl yönetilir?
Her API anahtarına (veya müşteri katmanına) ayrı kota ve hız limiti tanımlarız. Böylece bir müşterinin kötüye kullanımı diğerlerini etkilemez ve kullanım öngörülebilir kalır. Aşımda net 429/kota yanıtı döneriz.
Limitin doğru çalıştığını nasıl anlarım?
Limit isabet oranı, 429 sayısı ve meşru kullanıcı şikayetlerini izleriz. Sağlıklı bir yapılandırmada 429'lar istismar kaynaklarında yoğunlaşır, meşru trafikte neredeyse hiç görülmez. Bu metrikleri panoda şeffafça sunarız.
Sonraki adım

İlgili hizmetler, araçlar ve rehberler

Bot Koruması
Ağ & Edge GüvenliğiDDoS Koruması
Ağ & Edge GüvenliğiTrafik Filtreleme
Ağ & Edge GüvenliğiWeb Uygulama Güvenlik Değerlendirmesi
Web Uygulama Güvenliği
Web Sitesi Güvenlik Kontrol
Ücretsiz araçGüvenlik Başlıkları Kontrol
Ücretsiz araç
Web Sitesi Güvenliği Nedir?
Rehber

Hız Sınırlama (Rate Limiting) için başlayalım

Kapsamı netleştirelim, önceliklerinizi belirleyelim ve size özel, şeffaf bir güvenlik yol haritası çıkaralım — abartılı vaat değil, ölçülebilir risk azaltma.

WAF / DDoS Koruması Talep Et Ağ & Edge Güvenliği Hizmetleri