Herkese açık API'ler için oran sınırlaması: pratik kotalar ve kilitleme akışları

Hangi sorunu oran sınırlama gerçekten çözüyor

Herkese açık API'ler için oran sınırlama, kullanıcıları cezalandırmakla ilgili değildir. Trafik garipleştiğinde servisin kullanılabilirliğini koruyan bir emniyet sübabıdır; bu "gariplik" kötü niyetli olabileceği gibi bir istemci hatası da olabilir.

"Kötüye kullanım" çoğunlukla başta normal görünür: verileri kopyalamak için tüm uç noktaları gezen bir kazıyıcı (scraper), kaba kuvvetle giriş denemeleri, kimlik doğrulama rotalarına karşı token stuffing veya zaman aşımından sonra sık döngüyle aynı isteği yeniden deneyen kontrolden çıkmış bir istemci. Bazen kimse size saldırmıyordur; bir mobil uygulama güncellemesi hatalı bir önbellekleme kuralı içerir ve aniden her cihaz API'nizi her saniye sorgulamaya başlar.

İşin görevi basittir: gerçek kullanıcıların işlerini engellemeden çalışma süresini korumak ve maliyetleri kontrol altında tutmak. Eğer altyapınız saatlik/aylık olarak ölçümleniyorsa (hesaplama, veritabanı, e-posta/SMS, AI çağrıları), tek bir gürültülü aktör faturanızın hızla artmasına neden olabilir.

Tek başına oran sınırlama da yeterli değildir. İzleme ve net hata yanıtları yoksa sessiz başarısızlıklar, kafası karışmış müşteriler ve "API'niz kapalı" gibi görünen destek talepleri alırsınız; oysa gerçekte throttling söz konusudur.

Tam bir koruma hattı genellikle birkaç ayrı parçadan oluşur:

• Oran limitleri: ani dalgalanmaları durduran kısa pencere kapasiteleri (saniye/dakika başına).
• Kotalar: kullanımın öngörülebilir kalmasını sağlayan daha uzun dönem bütçeler (gün/ay bazında).
• Kilitlemeler: bariz kötü desenler için geçici bloklar.
• İstisnalar: güvenilir entegrasyonlar, dahili araçlar veya VIP müşteriler için izin listeleri.

AppMaster gibi bir platformda bir API arka ucu inşa ediyorsanız, bu kurallar yine önemlidir. Temiz, yeniden üretilmiş kod olsa bile bir hatalı istemci tüm servisinizi götürmesin diye koruyucu varsayılanlar istersiniz.

Ana terimler: oran limitleri, kotalar, throttling ve kilitlemeler

Bu terimler karışık kullanılır, ama farklı sorunları çözer ve kullanıcılara farklı hissettirir.

Oran limiti, kota ve eşzamanlılık: her birinin anlamı

Bir oran limiti hız sınırıdır: bir istemcinin kısa bir pencerede (saniye, dakika başına) kaç istek yapabileceği. Bir kota bütçedir: daha uzun bir dönemdeki toplam kullanım (günlük, aylık). Bir eşzamanlılık limiti aynı anda kaç isteğin işlenebileceğini sınırlar; bu, istek hızı normal görünse bile pahalı uç noktalar için faydalıdır.

Limitin nerede uygulandığı önemlidir:

• IP başına: basit ama paylaşılan ağları (ofisler, okullar, mobil taşıyıcılar) cezalandırır.
• Kullanıcı başına: giriş yapılmış uygulamalar için harika, ama güvenilir kimliğe bağlıdır.
• API anahtarı başına: herkese açık API'lerde yaygın, açık sahiplik ve mesajlaşma kolaylığı sağlar.
• Uç nokta başına: bir rota diğerlerinden çok daha ağırsa faydalıdır.

Throttling vs engelleme ve kilitlemelerin yeri

Yumuşak throttling istemciyi yavaşlatır (g gecikmeler, düşük patlama kapasitesi) böylece iş akışları bozulmadan geri dönülebilir. Sert engelleme istekleri genellikle HTTP 429 ile hemen reddeder.

Bir kilitleme normal bir 429'dan daha güçlüdür. 429 "biraz sonra tekrar deneyin" der. Bir kilitleme ise "bazı koşullar sağlanana kadar dur" der; örneğin bir soğuma süresi, manuel inceleme veya anahtar sıfırlaması gibi. Kilitlemeleri açık kötüye kullanım sinyalleri (kimlik bilgisi doldurma, agresif kazıma, tekrarlayan geçersiz kimlik doğrulama) için saklayın; normal trafik için değil.

AppMaster ile bir API inşa ediyorsanız, bunları ayrı kontroller olarak ele alın: patlamalar için kısa pencereler, maliyet için daha uzun kotalar ve yalnızca tekrarlayan kötü davranışlarda kilitlemeler.

Tahmin yürütmeden pratik limitler seçmek

İyi limitler tek bir hedefle başlar: normal kullanıcıların işini bitirmesine izin verirken arka ucu korumak. İlk günden mükemmel sayılarınız olmasına gerek yok. Güvenli bir temel ve bunu ayarlama yolu yeterlidir.

Basit bir başlangıç noktası, çalıştırdığınız API türüne uyan anahtar başına limitlerdir:

• Düşük trafik: anahtar başına dakikada 60-300 istek
• Orta trafik: anahtar başına dakikada 600-1.500 istek
• Yüksek trafik: anahtar başına dakikada 3.000-10.000 istek

Sonra limitleri uç nokta türlerine göre ayırın. Okumalar genellikle daha ucuzdur ve daha yüksek limitlere izin verebilir. Yazma işlemleri veriyi değiştirir, genellikle ekstra mantık tetikler ve daha sıkı kaplara layıktır. Yaygın bir örüntü: GET rotaları için 1.000/dak, POST/PUT/DELETE için 100-300/dak.

Ayrıca pahalı uç noktaları belirleyin ve ayrı ele alın. Arama, rapor üretme, dışa aktarma, dosya yüklemeleri ve birden çok tabloyu vuran veya ağır iş mantığı çalıştıran her şey, geri kalan API cömert olsa bile daha küçük bir havuza sahip olmalıdır. Arka ucunuz görsel iş akışları (örneğin Business Process akışları) kullanıyorsa, her ek adım yük altında gerçek iş artırır.

Ani yükselişler için iki pencereye hazırlanın: hızlı dalgaları emen kısa pencere ve sürekli kullanımı kontrol eden daha uzun pencere. Yaygın bir kombinasyon 10 saniye artı 10 dakikadır. Bu, hızlı tıklayan gerçek kullanıcılara yardım eder, kazıyıcılara sınırsız hız vermez.

Son olarak, istemci limiti aştığında ne olacağına karar verin. Çoğu halk API'si HTTP 429 ve açık bir yeniden deneme süresi döner. İş geciktirilebilecek türdense (örneğin bir dışa aktarma), sert engelleme yerine kuyruğa alma düşünün ki gerçek kullanıcılar yine de sonuç alabilsin.

Adil hissettiren anahtar başına kotalar tasarlamak

Anahtar başına kotalar genellikle en adil yaklaşımdır çünkü müşterilerin hizmetinizi nasıl kullandığıyla uyuşur: bir hesap, bir API anahtarı, açık sorumluluk. IP tabanlı limitler hala faydalıdır ama masum kullanıcıları sıkça cezalandırır.

Paylaşılan IP'ler büyük sebeptir. Bir ofis tüm çıkışı tek bir genel IP üzerinden yapabilir ve mobil taşıyıcılar binlerce cihazı küçük bir IP havuzu arkasına koyabilir. Sadece IP kasağına güvenirseniz, bir gürültülü kullanıcı herkesin yavaşlamasına neden olabilir. Anahtar başına kota bunu önler ve belirgin sel durumları için hafif bir IP başına limitini yedek olarak tutabilirsiniz.

Kotaları adil hissettirmek için bunları müşteri katmanlarına bağlayın, ama yeni kullanıcıları tuzağa düşürmeyin. Ücretsiz veya deneme anahtarı gerçek testler için çalışmalı, sadece ölçeklendirme düzeyinde zarar vermemeli. Basit bir örüntü: cömert patlamalar, mütevazı bir sürekli oran ve plana uygun günlük kota.

Tahmin edilebilir bir anahtar başına politika:

• Kısa patlamalara izin verin (sayfa yüklemeleri, toplu içe aktarmalar), sonra kararlı bir oran uygulayın.
• Kazımayı ve kontrolden çıkmış döngüleri sınırlamak için anahtar başına günlük bir üst sınır ekleyin.
• Limitleri plana göre artırın, ama aynı yapıyı koruyun ki davranış tutarlı olsun.
• Yeni oluşturulmuş anahtarlar için iyi bir geçmiş oluşturana kadar daha düşük bir cap kullanın.
• Açık sel durumlarını yakalamak için küçük bir IP başına limit tutun.

Anahtar paylaşımını ve otomatik kayıtları caydırmak için ağır gözetim gerekmez. Olağan dışı coğrafya değişiklikleri, bir anahtar için saatte çok fazla farklı IP, veya aynı kaynaktan çok sayıda yeni anahtar gibi basit kontrollerle başlayın. Önce işaretleyin ve yavaşlatın; yalnızca tekrarlayan sinyallerde kilitleyin.

Anonim trafik sıkı kaplar gerektiren yerdir. Deneme anahtarları sunuyorsanız, bunları sıkı rate-limitlerle sınırlandırın ve limitleri yükseltmeden önce temel bir doğrulama adımı isteyin. API'niz bir kamu formunu güçlendiriyorsa, geri kalan arka ucunuzun korunması için ayrı bir anonim uç nokta ve kendi kotasını düşünün.

AppMaster ile API'nizi inşa ediyorsanız, anahtar başına mantığı tutarlı tutmak daha kolaydır çünkü kimlik doğrulama, iş kuralları ve yanıt işleme tek bir yerde yaşar.

İstemci dostu yanıtlar ve başlıklar (kullanıcıların kurtulabilmesi için)

Oran sınırlama uzun vadede işe yarıyorsa istemciler ne olduğunu ve ne yapacaklarını anlayabilmelidir. Yanıtlar sıkıcı biçimde tahmin edilebilir olmalı: aynı durum kodu, aynı alanlar, aynı anlam uç noktalar arasında.

Bir istemci limitlere takıldığında HTTP 429 (Too Many Requests) dönün ve net bir mesaj ile somut bir bekleme süresi verin. En hızlı kazanım Retry-After eklemektir, çünkü basit istemciler bile buna göre duraklayabilir.

Küçük bir başlık seti limitleri kendi kendine açıklayıcı yapar. İsimleri tutarlı tutun ve hem başarılı yanıtlarda (istemciler pacing yapsın diye) hem de 429 yanıtlarında (kurtarma için) dahil edin:

• Retry-After: yeniden denemeden önce beklenmesi gereken saniye
• X-RateLimit-Limit: pencere başına izin verilen istek sayısı
• X-RateLimit-Remaining: mevcut pencerede kalan istek sayısı
• X-RateLimit-Reset: pencerenin ne zaman sıfırlanacağı (epoch saniye veya ISO zaman)
• X-RateLimit-Policy: kısa bir metin, örn. "60 requests per 60s"

Hata gövdesini başarı yanıtlarınız kadar yapılandırılmış yapın. Yaygın bir desen, sabit bir code, insan dostu bir message ve kurtarma ipuçları içeren bir hata nesnesidir.

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

İstemcilere 429 gördüklerinde nasıl geri çekileceklerini söyleyin. Üssel geri çekilme (exponential backoff) iyi bir varsayılandır: 1s, sonra 2s, sonra 4s bekleyin ve bir üst sınır koyun (örneğin 30-60 saniye). Ayrıca ne zaman denemeyi bırakacaklarını açıkça belirtin.

Kotalara yakın sürprizlerden kaçının. Bir anahtar bir kapa %80-90 yaklaştığında bir uyarı alanı veya başlık ekleyin ki istemciler başarısız olmadan önce yavaşlayabilsin. Bu, bir script birden fazla rotaya çabucak çarpıp bütçeyi beklenenden hızlı tüketebildiğinde daha da önemlidir.

Adım adım: limitler ve kotalar için basit bir dağıtım planı

Limitleri bir ürün davranışı olarak ele aldığınızda dağıtım en iyi çalışır; tek seferlik bir firewall kuralı gibi değil. Amaç aynı: arka ucu korurken normal müşterilerin hareket etmesini sağlamak.

Hızlı bir envanter ile başlayın. Her uç noktayı listeleyin, sonra her birini maliyet (CPU, veritabanı işi, üçüncü taraf çağrıları) ve risk (giriş, şifre sıfırlama, arama, dosya yükleme) açısından işaretleyin. Bu, her şeye tek bir sert limit uygulamanızı engeller.

Genellikle sürprizleri önleyen bir dağıtım sıralaması:

• Uç noktaları maliyet ve riske göre etiketleyin; hangilerinin daha sıkı kurallar gerektirdiğine karar verin (giriş, toplu dışa aktarma).
• Kimlik anahtarlarını öncelik sırasına göre seçin: önce API anahtarı, sonra kullanıcı id'si, IP sadece bir yedek olarak.
• Ani patlamaları durdurmak için kısa pencere limitleri ekleyin (10 saniye veya 1 dakika gibi).
• Sürekli kullanımı sınırlamak için daha uzun pencere kotaları ekleyin (saatlik veya günlük).
• Operasyon işlerinin engellenmemesi için güvenilir sistemler ve dahili araçlar için izin listeleri ekleyin.

İlk yayın muhafazakar olsun. Sonra gevşetmek daha kolaydır; kızgın kullanıcıları engellemek zor.

İzleyin ve ayarlayın, sonra politikanızı versiyonlayın. Kaç isteğin limitlere takıldığını, hangi uç noktaların bunu tetiklediğini ve kaç benzersiz anahtarın etkilendiğini izleyin. Sayıları değiştirdiğinizde bunu bir API değişikliği gibi ele alın: belgelenmiş, kademeli dağıtılmış ve eski ile yeni kuralları ayrı tutarak hızlı geri alabilme sağlayın.

AppMaster ile API'nizi inşa ediyorsanız, bu kuralları uç noktalar ve iş mantığınızla birlikte planlayın ki limitler her iş akışının gerçek maliyetiyle eşleşsin.

Abartısız şekilde kötüye kullanımı durduran kilitleme akışları

Kilitlemeler emniyet kemeridir. Bariz kötüye kullanımı hızlıca durdurmalı, ama bir şey ters gittiğinde normal kullanıcılara net bir kurtarma yolu sunmalıdır.

Sakin bir yaklaşım aşamalı cezalandırmadır. İstemcinin kötü niyetli olmayabileceğini varsayın ve desen tekrarlanmadıkça kademeli olarak sertleştirin.

Basit bir aşamalı merdiven

Açıklaması kolay ve uygulaması basit birkaç adım kullanın:

• Uyar: istemciye limitlere yaklaştığını ve ne zaman sıfırlanacağını söyleyin.
• Yavaşlat: o anahtar için kısa gecikmeler veya daha sıkı saniye başına limitler ekleyin.
• Geçici kilitleme: dakika bazında (saat değil) engelleme, kesin bir açılma zamanı ile.
• Daha uzun kilitleme: birden fazla pencere boyunca tekrarlanan patlamalardan sonra.
• Manuel inceleme: niyet kasıtlı gibi görünüyorsa veya tekrar ediyorsa.

Ne kilitlendiği önemlidir. Anahtar başına kilitleme genellikle en adildir çünkü çağıranı hedefler, paylaşılan bir ağdaki herkesi değil. Hesap başına kilitleme, kullanıcıların anahtar döndürmesinde faydalıdır. IP başına kilitleme anonim trafik için yardımcı olabilir ama NAT'lar, ofisler ve mobil taşıyıcılar için yanlış pozitiflere neden olur. Kötüye kullanım ciddi olduğunda sinyalleri birleştirin (örneğin anahtarı kilitleyin ve o IP için ek kontroller isteyin), ama etki alanını küçük tutun.

Kilitlemeleri basit zaman tabanlı kurallarla yapın: "14:05 UTC'ye kadar engellendi" ve "30 dakika iyi davranıştan sonra sıfırlanır" gibi. Otomatik sistemler için kalıcı yasaklardan kaçının. Hatalı bir istemci döngüye girip hızla limitleri tüketebilir, bu yüzden cezaları zaman içinde azalacak şekilde tasarlayın. Sürekli düşük oranlı davranış cezayı azaltmalıdır.

AppMaster'da API'nizi oluşturuyorsanız, bu merdiven saklama sayıcılarına ve iskey için açılma zamanını yazan bir Business Process'e iyi uyar.

Tekrarlayan kötü niyetliler için manuel inceleme yolu tutun. Kullanıcılarla tartışmayın. İstek ID'leri, zaman damgaları ve API anahtarı adını isteyin, sonra kanıta göre karar verin.

Yanlış pozitiflere neden olan yaygın hatalar

Yanlış pozitifler savunmalarınız normal kullanıcıları engellediğinde olur. Genellikle kurallar insanların API'yi gerçekte kullandığı şekle göre çok basit olduğunda ortaya çıkar.

Klasik hata her şey için tek bir küresel limit uygulamaktır. Ucuz bir okuma uç noktasını ve pahalı bir dışa aktarmayı aynı muameleye tabii tutarsanız ya ucuz olanı aşırı korursunuz (sinirlendirici) ya da pahalı olanı yetersiz korursunuz (tehlikeli). Limitleri uç nokta maliyetine göre ayırın ve ağır yolları daha sıkı yapın.

Sadece IP'ye dayalı sınırlama başka bir yaygın tuzaktır. Birçok gerçek kullanıcı tek bir genel IP paylaşır (ofisler, okullar, mobil taşıyıcılar). Bir yoğun kullanıcı herkesin engellenmesine neden olabilir ve rastgele kesintiler gibi görünür. Önce API anahtarı bazlı limitlemeyi tercih edin, sonra IP'yi açık kötü durumlar için ikincil sinyal olarak kullanın.

Limiter deposu (store) çöktüğünde hatalar da yanlış pozitiflere neden olabilir. "Fail closed" tüm API'nizi kapatabilir. "Fail open" ise bir yüklenme daveti çıkarır. Net bir geri plan seçin: uçta küçük bir acil kap tutun ve kritik olmayan uç noktalarda zarifçe düşürün.

İstemci tarafı işlemler çoğu ekip beklediğinden daha önemlidir. Jenerik bir 429 döndürürseniz kullanıcılar daha fazla yeniden dener ve daha fazla blok tetikler. Her zaman Retry-After gönderin ve hata metnini spesifik tutun ("Bu anahtar için çok fazla istek. 30 saniye sonra tekrar deneyin.").

En önlenebilir sorun gizliliktir. Gizli limitler müşteriler üretim yüküyle ilk karşılaştıklarında hata gibi hissedilir. Basit bir politika paylaşın ve uygulanmadan önce bildirin.

Yanlış pozitiflerden kaçınma kontrol listesi:

• Pahalı vs ucuz uç noktalar için ayrı limitler
• Birincil limitleme olarak API anahtarı, sadece IP değil
• Limiter kullanılamazsa tanımlı davranış
• Retry-After ile net 429 yanıtları
• Limitlerin uygulanmadan önce belgelenip iletilmesi

AppMaster ile API'nizi inşa ediyorsanız, genellikle bu, uç nokta başına farklı kaplar ayarlamak ve istemcilerin tahmin etmeden geri çekilebilmesi için tutarlı hata yükleri döndürmek demektir.

İzleme ve alarm verme (gerçekten yardımcı olan)

Oran sınırlama, neler olduğunu gerçek zamanlı görebiliyorsanız işe yarar. Amaç her dalgayı yakalamak değil; kesintiye veya kızgın kullanıcılara dönüşecek desenleri tespit etmektir.

Hacim ve niyeti birlikte açıklayan küçük bir sinyal seti ile başlayın:

• Dakika başına istekler (genel ve anahtar bazında)
• 429 oranı (throttled istekler) ve 5xx oranı (arka uç ağrısı)
• Tekrarlayan 401/403 patlamalar (hatali anahtarlar, credential stuffing, hatalı istemciler)
• Hacim ve maliyet bazında en çok trafik yapan uç noktalar (yavaş sorgular, ağır dışa aktarmalar)
• Beklenmeyen yeni uç noktaların ilk 10'a girmesi

"Kötü trafik" ile "biz bir şeyi yayınladık" arasını ayırmak için panolara bağlam ekleyin: deploy zamanı, feature flag değişiklikleri, pazarlama gönderimleri. Trafik bir sürümden hemen sonra artıp 429/5xx karışımı sağlamsa genelde büyüme, kötüye kullanım değildir. Eğer artış tek bir anahtar, bir IP aralığı veya pahalı bir uç noktada yoğunlaşmışsa, şüpheli sayın.

Uyarılar sıkıcı olmalı. Aynı olay için her dakika çağrılmamak üzere eşik ve soğuma süreleri kullanın:

• 10 dakika boyunca %X'in üzerinde 429 oranı, saatte bir bildirim
• 5 dakika boyunca %Y'nin üzerinde 5xx, hemen sayfa gönder
• Tek bir anahtar 15 dakika boyunca kota %Z'nin üzerinde, soruşturma aç
• Dakikada N'den fazla 401/403 patlaması, olası kötüye kullanım için işaretle

Bir uyarı tetiklendiğinde kısa bir olay notu bırakın: ne değişti, neler görüldü (en çok anahtar/uç nokta), ne ayarladınız (limitler, cache'ler, geçici bloklar). Zamanla bu notlar gerçek oyun kitabınız olur.

Örnek: yeni bir arama uç noktası başlattınız ve trafik iki katına çıktı. Çağrıların büyük çoğunluğu birçok anahtar arasında yayılmışsa, anahtar başına kotayı biraz yükseltin ve uç noktayı optimize edin. Eğer bir anahtar dışa aktarmayı durmaksızın çağırıp gecikmeye neden oluyorsa, o uç noktayı ayrı sınırlayın ve sahipleriyle iletişime geçin.

Hızlı kontrol listesi: yayın öncesi ve sonrası akıl sağlığı kontrolleri

İyi bir kurulum çalıştığında sıkıcıdır. Bu kontrol listesi genellikle yanlış pozitiflere veya belirgin boşluklara yol açan meseleleri yakalar.

Yeni bir uç noktayı yayınlamadan önce

Bu kontrolleri staging'de ve yayın sonrası hemen çalıştırın:

• Kimlik: limiter'in doğru şeye dayandığını doğrulayın (önce API anahtarı, sonra kullanıcı veya IP yedeği) ve döndürülen anahtarların eski cezaları miras almadığından emin olun.
• Limitler: varsayılan anahtar kotası belirleyin, sonra uç nokta maliyetine göre ayarlayın (ucuz okuma vs pahalı yazma) ve beklenen patlamaları hesaba katın.
• Yanıtlar: net durum ve kurtarma bilgisi döndürün (yeniden deneme zamanı, kalan bütçe, sabit hata kodu).
• Loglar: kimin limitlendiğini (anahtar/kullanıcı/IP), hangi rotanın ve hangi kuralın tetiklendiğini ve destek için bir istek ID'si kaydedin.
• Bypass: monitörleriniz ve güvenilir entegrasyonlar için acil bir izin listesi tutun.

AppMaster üzerinde inşa ediyorsanız, her yeni API uç noktasını bir maliyet-seviyesi kararı olarak ele alın: basit bir arama cömert olabilir, ağır iş mantığı tetikleyen bir şey başlangıçta daha sıkı olsun.

Bir olay olduğunda (kötüye kullanım veya ani trafik)

Arka ucu korurken gerçek kullanıcıların toparlanmasına izin verin:

• En az riskli rotalar için (çoğunlukla okumalar) geçici olarak capleri artırın ve hata oranlarını izleyin.
• Soruşturma sırasında bilinen iyi müşteriler için kısa bir izin listesi ekleyin.
• Global limitleri düşürmek yerine belirli riskli rotaları sıkılaştırın.
• Paylaşılan ağları engellememek için daha güçlü kimlik gereksinimini devreye alın (API anahtarlarını zorunlu kılın, IP'ye fazla güvenmeyin).
• Örnekler toplayın: en çok anahtar, en çok IP, user-agent'lar ve tam yük örüntüleri.

Bir müşteri için limitleri artırmadan önce normal istek desenlerini, uç nokta karışımını ve toplama veya backoff ekleyip ekleyemeyeceklerini kontrol edin. Ayrıca anahtarı birçok uygulama arasında paylaşıp paylaşmadıklarını doğrulayın.

Aylık olarak gözden geçirme: en çok limitlenen uç noktalar, limitlere takılan trafiğin yüzdesi, yeni yüksek maliyetli rotalar ve kotaların gerçek kullanıma uygunluğu.

Örnek senaryo: gerçek bir herkese açık API'yi kullanıcıları bozmadan korumak

Varsayalım halka açık bir API işletiyorsunuz ve iki uygulama kullanıyor: bir müşteri portalı (yüksek hacim, düzenli trafik) ve bir dahili yönetici aracı (düşük hacim ama güçlü işlemler). Her ikisi de API anahtarı kullanıyor ve portal ayrıca son kullanıcılar için bir giriş uç noktası içeriyor.

Bir öğleden sonra bir partner hatalı bir entegrasyon yayımlar. Hatalı entegrasyon başarısız istekleri sık döngüyle yeniden deniyor ve tek bir API anahtarından saniyede 200 istek göndermeye başlıyor. Koruyucu önlemler olmasaydı bu tek anahtar diğer herkesi baskılayabilirdi.

Anahtar başına limitler etki alanını sınırlar. Hatalı anahtar dakikalık kotasını aşar, 429 yanıtı alır ve diğer müşteriler çalışmaya devam eder. Ayrıca pahalı uç noktalar (dışa aktarmalar gibi) için ayrı ve daha düşük bir limitin olması, "izin verilen" trafiğin bile veritabanını aşırı yükleyememesini sağlar.

Aynı zamanda kaba kuvvet bir giriş denemesi kimlik doğrulama uç noktasını vuruyor. Tüm IP aralığını engellemek yerine (bu NAT arkası gerçek kullanıcıları da etkileyebilir), akışı önce yavaşlatır, sonra davranışa göre kilitlersiniz: bir hesap başına çok fazla başarısız deneme artı kısa bir pencerede IP başına da yüksek deneme. Saldırgan kademeli olarak daha uzun beklemeler ve ardından geçici bir kilitleme görür.

Bir müşteri yanlış parola birkaç kez girdiğinde toparlanabilir çünkü yanıtlarınız net ve öngörülebilirdir:

• İstemci ne zaman tekrar deneyeceğini bilsin diye Retry-After ile 429
• Kısa bir kilitleme penceresi (örneğin 10-15 dakika), kalıcı yasak değil
• Hesabın varlığını sızdırmayan tutarlı hata mesajları

Düzeltmeyi doğrulamak için birkaç metriği izlersiniz:

• API anahtarı ve uç nokta bazında 429 oranı
• Kimlik doğrulama başarısızlık oranı ve kilitleme sayıları
• Olay sırasındaki P95 gecikme ve veritabanı CPU kullanımı
• Etkilenen benzersiz anahtar sayısı (küçük olmalı)

Bu, arka ucunuzu cezalandırmadan koruyan koruyucu oran sınırlamanın nasıl göründüğüne dair bir örnektir.

Sonraki adımlar: küçük bir politika koyun ve yineleyin

İlk günde mükemmel bir model gerekmez. Küçük, net bir politika ile başlayın ve gerçek kullanıcıların nasıl davrandığını öğrendikçe geliştirin.

Sağlam bir ilk sürüm genellikle üç bölüm içerir:

• Çoğu uç noktayı kapsayan anahtar başına bir temel (dakika başına istek)
• Pahalı uç noktalar (arama, dışa aktarma, dosya yüklemeleri, karmaşık raporlar) için daha sıkı kaplar
• İstemcilere ne yapacaklarını söyleyen kısa bir mesaj içeren net 429 yanıtları

Kilitlemeleri yalnızca kötüye kullanım riski yüksek olduğunda ve niyetin kolayca çıkarılabildiği durumlarda ekleyin. Kayıt, giriş, şifre sıfırlama ve token oluşturma tipik adaylardır. Kilitlemeleri önce kısa tutun (dakikalar, günler değil) ve aşamalı sürtünmeyi tercih edin: önce yavaşlat, sonra geçici blok, sonra daha güçlü bir doğrulama isteyin.

Politikayı destek ekibinin mühendislik yardımına gerek duymadan açıklayabileceği şekilde sade dilde yazın. Ne sınırlandırılıyor (API anahtarı başına, IP başına, hesap başına), sıfırlama penceresi ve müşterinin nasıl kurtulacağı dahil olsun.

Yeni bir arka uç inşa ederken AppMaster pratik bir seçenek olabilir: API'leri oluşturup sayıcılar ve kilitleme kararları içeren iş süreçleri tanımlayabilir, sonra bulut sağlayıcılarına dağıtabilir veya altyapı ve politikalar üzerinde tam kontrol gerektiğinde üretilen kaynak kodunu dışa aktarabilirsiniz.