Rate Limit Kontrol Listesi (RLCL)

Neden Böyle Bir Şeye İhtiyacımız Var?

API'ler dijital dünyada artık her yerde! Uygulamalar konuşuyor, sistemler veri paylaşıyor, cihazlar sürekli birbirine bağlanıyor. Bu kadar açık ve yoğun bir iletişim hali ister istemez bazı güvenlik risklerini beraberinde getiriyor. Kötüye kullanım, saldırılar, hizmet kesintileri derken, artık sadece "kim erişebilir?" sorusu yetmiyor. "Kim, ne kadar erişebilir?" sorusunu da sormamız gerekiyor.

API geliştirme ve yönetiminin dinamik dünyasında, gelen isteklerin akışını kontrol etmek sistem stabilitesini korumak, adil kullanımı sağlamak ve kötüye kullanımı önlemek için çok önemli.

İşte tam bu noktada Apinizer olarak devreye giriyoruz:

İlham Kaynağımız: Erişim Kontrol Listeleri (ACL)

Güvenlik dünyasında uzun yıllardır kullanılan "Access Control List" (ACL) kavramı, belli kaynaklara kimlerin erişebileceğini belirlemeye yarar. Liste bazlı, hedef odaklı, net kurallar içerir. Apinizer olarak düşündük: "Bu mantığı neden rate limiting için kullanmayalım?"

Ve ortaya Rate Limit Kontrol Listesi (RLCL) çıktı.

ACL vs RLCL: Apinizer'ın Güçlü İkili Çözümü

Apinizer, güvenlik ve trafik yönetimi için hem ACL hem de RLCL çözümlerini sunuyor. Her iki çözüm de birbirini tamamlayarak API'lerinizi tam koruma altına alıyor:

Bu iki güçlü mekanizmayı birlikte kullanarak API güvenliğinizi eksiksiz hale getirebilirsiniz. Önce ACL ile kimlerin erişebileceğini belirleyin, sonra RLCL ile bu erişimlerin sınırlarını tanımlayın.

Peki RLCL Tam Olarak Ne?

Adı üstünde: Rate limit kurallarını liste bazlı ve hedefli şekilde tanımlamanıza yarayan bir sistem. Artık her IP'ye, her API anahtarına, her kullanıcıya tek bir limit uygulamak zorunda değilsiniz. Dilerseniz:

• 192.168.1.25 IP'sine saniyede 5 istek,
• client-abc-* ile başlayan API key'lere dakikada 500 istek,
• Belirli kullanıcı ID'lerine günde 10.000 istek

gibi özel limitler tanımlayabilirsiniz. Üstelik operatör tabanlı esnek hedef kitle koşulları (eşittir, içerir, ile başlar, ile biter, listede yer alır gibi) veya conditional (örneğin mesai saatlerinde farklı mesai dışında farklı) tanımlar da yapabilirsiniz. Yani artık "herkes için tek kural" devri bitti!

Apinizer'da RLCL Nasıl Çalışıyor?

Karmaşık değil, adımlar net:

1. İstek gelir.
2. İsteğin kimliği belirlenir: seçilen kimlik kaynağına göre ya bir değişkenin değeri (IP, header, kullanıcı ID vs.) ya da kimlik doğrulamadan gelen kullanıcı kullanılır.
3. Bu kimliğin hedef kitlede olup olmadığına bakılır (kimlik listesinde mi yer alıyor, yoksa hedef kitle koşullarından biriyle mi eşleşiyor?).
4. Eğer hedef kitledeyse, ona özel tanımlanmış rate limit kuralı devreye girer.
5. Eğer hedef kitlede değilse, tanımladığınız hedef-dışı eyleme göre davranılır: istek ya engellenir ya da hedef-dışı istekler için ayrılan genel kota uygulanır.
6. Limit aşıldıysa, istek reddedilir (genellikle 429 Too Many Requests hatası ile).
7. İsteğe bağlı olarak rate limit durumu yanıt başlıklarına eklenebilir (X-RateLimit-*).

Apinizer RLCL'nin Esnekliği

Apinizer'ın Rate Limit Kontrol Listesi çözümü, esnekliği ile öne çıkıyor:

Zaman Penceresi Seçenekleri

RLCL, hem Sabit Pencere (FIXED) hem de Kayan Pencere (SLIDING) yaklaşımlarını destekler:

• Sabit Pencere: Belirli zaman dilimlerinde (örn. her saat başı) sayaçlar sıfırlanır
• Kayan Pencere: Her an için son X dakika/saat/gün içindeki istekler değerlendirilir

Bu, farklı iş senaryolarına uygun çözümler sunmanızı sağlar.

Çalışma Sırası (Execution Order)

RLCL politikasının diğer politikalar arasındaki konumunu belirlersiniz. Politika, istek işleme akışında altı farklı konumda çalışabilir:

• Proxy grubu politikalarından öncesi
• Proxy grubu politikalarından sonrası
• API proxy politikalarından öncesi (varsayılan)
• API proxy politikalarından sonrası
• API metodu politikalarından öncesi
• API metodu politikalarından sonrası

Kimlik Kaynağı Kilitlemesi

Kimlik kaynağı olarak "kimlik doğrulamadan gelen kullanıcı" seçilirse, kimlik ancak kimlik doğrulama sonrası bilinir. Bu nedenle konum otomatik olarak API metodu politikalarından sonrasına sabitlenir ve değiştirilemez. Bu durumda sistem bir uyarı gösterir. Kimlik kaynağı olarak "değişken seçimi" yapılmışsa (IP, başlık vb.), istediğiniz konumu seçebilirsiniz.

Bu esneklik sayesinde, kimliği istek başlığından okuyan bir kontrol, o başlığı değiştiren bir politikadan önce çalışabilir. Ya da kimlik doğrulama sonrası kontrol gerekiyorsa, politikayı doğru konumda yerleştirebilirsiniz.

Hedef-dışı Eylem ve Genel Kota

Kimlik belirlendikten sonra, hedef kitlede olup olmadığı kontrol edilir. Hedef kitlede ise tanımlı rate limit uygulanır. Hedef kitlede değilse iki davranıştan biri seçilir:

1. Akışı Durdur

İstek basitçe engellenir. Genellikle 429 Too Many Requests (hız limiti aşıldı) veya 403 Forbidden (yasak) gibi bir hata kodu döndürülür.

2. Genel Kota Uygula

Hedef-dışı isteklere için ayrılan genel bir kota (limit) devreye girer. Bu seçimde, sayım modu iki türde olabilir:

• Tüm hedef-dışı istekler için tek ortak kota: Tüm hedef-dışı istemciler tek bir ortak limiti paylaşır. Limiti bir istemci aşarsa, diğer tüm hedef-dışı istemciler de engellenir.

• Her hedef-dışı kimlik için ayrı kota: Her hedef-dışı kimliğin (IP, API anahtarı vb.) kendine ait ayrı limiti vardır. Bir istemcinin limitini aşması, diğerlerini etkilemez.

Bu sayede, ana hedefli kullanıcılara yüksek limitler verirken, kalan trafiğin de kontrollü kalmasını sağlayabilirsiniz.

Dinamik Kimlik Tanımlama

Apinizer RLCL, isteğin kimliğini belirlemek için son derece esnek seçenekler sunar:

• IP adresi
• API anahtarı
• Kullanıcı kimliği
• İstek başlıkları
• Çerez değerleri
• URL parametreleri
• İstek gövdesindeki alanlar

Hatta bunların kombinasyonlarını bile kullanabilirsiniz! Örneğin, "belirli bir kullanıcı ID'sine sahip ve belirli bir IP bloğundan gelen istekler" için özel kurallar tanımlayabilirsiniz.

Esnek Hedef Kitle Koşulları

RLCL, hedef kitleyi belirlemek için operatör tabanlı esnek koşullar tanımlamanıza olanak tanır. Her koşul bir operatör ve bir değerden oluşur; koşullar VEYA mantığıyla değerlendirilir. Örneğin:

• 192.168. ile başlayan tüm IP adresleri
• Belirli bir değeri içeren API anahtarları
• Belirli bir değere eşit kullanıcı kimlikleri
• Bir değerler listesinde yer alan kimlikler

Bu sayede, tek tek değerler yerine eşleştirme kuralları tanımlayarak yönetim yükünüzü azaltabilirsiniz.

Ayarlar Basit ve Anlaşılır

Apinizer olarak her zamanki kolay kullanım prensibimizi koruyarak sizlere basit ve anlaşılır arayüzler sunuyoruz. Zor tarafını arkada biz sizin için hallediyoruz. Karmaşık rate limiting mekanizmaları ve algoritmalarını endişe etmenize gerek kalmadan, aşağıdaki sade ayarlarla tüm ihtiyaçlarınızı karşılayabilirsiniz:

• İsim ve Açıklama: Yönetim kolaylığı için.
• Çalışma Sırası: Diğer politikalara göre önce mi sonra mı çalışacak?
• Zaman Penceresi Tipi: Sabit mi, yoksa kayan mı?
• İzin Verilen İstek Sayısı: Ne kadar istek geçirebilir?
• Zaman Aralığı: Saniye, dakika, saat, gün, ay olarak belirleyebilirsiniz.
• Kimlik Kaynağı: Kimlik bir değişkenden mi (IP, API anahtarı, kullanıcı ID) yoksa kimlik doğrulamadan gelen kullanıcıdan mı belirlensin?
• Hedef Kitle: Liste olarak veya operatör tabanlı koşullarla tanımlayabilirsiniz.
• Yanıt Başlıkları: Rate limit istatistiklerini göstermek ister misiniz?

Hata Mesajı Özelleştirme

Rate limit kontrolü sırasında hata oluştuğunda (hız limiti aşıldığında, kimlik çözümlenemediğinde veya hedef kitlede olmadığında) gönderilen yanıtları tamamen özelleştirilebilirsiniz.

Her hata durumu için:

• HTTP durum kodu (örn. 429, 403)
• Hata kodu (iş sisteminize göre tanımladığınız bir kod)
• Hata mesajı (kısa metin)
• Özel mesaj şablonu (isteğe bağlı; istemciye gönderilecek tam yanıt gövdesi, değişkenlerle dinamik hale getirilebilir)

tanımlayabilirsiniz.

Şablon ve Değişken Desteği

Özel mesaj şablonunda hata bilgileri (hata kodu, hata mesajı, durum kodu), istek bilgileri, ilişki kimliği ve tarih/saat gibi değişkenleri kullanabilirsiniz. Böylece istemciye daha bilgilendirici ve kişiselleştirilmiş hata mesajları sunabilirsiniz.

Plan genelinde bir genel şablon tanımlarsa, kendi özel şablonu olmayan tüm hatalar bu genel şablonu kullanırlar. Ancak belirli bir hata türü için başka bir şablon tanımlamışsanız, o özel şablon geçerli olur.

Neden RLCL? Ne Farkı Var?

Granüler kontrol: Kim, ne kadar erişebilir sorusuna net cevaplar verirsiniz.

Hedefli sınırlama: Tek bir kötü aktör tüm API'nizi kilitleyemez.

Esneklik: Partner, müşteri, servis — kim olursa olsun farklı SLA'lar tanımlayabilirsiniz.

Şeffaflık: Yanıtlara kalan limit bilgilerini de koyabilirsiniz.

Yönetilebilirlik: Tanımlamalar sade ve okunaklı.

Performans: Cache desteğiyle hızlı çalışır, sisteminizi yavaşlatmaz.

Gerçek Hayattan Örnekler

• Ücretsiz vs. Premium Kullanıcılar: Freemium modelindeki servisinizde ücretsiz kullanıcılara "günde 100 istek", premium kullanıcılara "saniyede 50 istek" limiti uygulayabilirsiniz. API'niz hem erişilebilir hem de adil olur.

• Coğrafi Bazlı Koruma: Belirli ülkeler veya IP bloklarından gelen isteklere farklı limitler uygulayabilirsiniz. Özellikle şüpheli trafik kaynakları için bu çok işe yarar.

• DDoS Önleme: Aniden yüksek trafik gönderen IP'leri anında tespit edip özel kısıtlamalar getirebilirsiniz. Böylece diğer kullanıcılarınızı etkilemeden sorunu izole edersiniz.

• Partner Yönetimi: Her bir iş ortağınıza özel API kullanım limitleri tanımlayabilirsiniz. Herkesin ihtiyacına göre — kimileri dakikada 1000 istek yaparken, kimileri saatte 10 istek yapabilir.

Son Söz

Apinizer olarak API güvenliği ve yönetimine yeni bir soluk getirmek istedik. Rate limitleri sadece bir sayı olmaktan çıkarıp, hedefli, esnek ve güçlü bir kontrol aracına dönüştürdük. Çünkü biliyoruz ki modern API dünyasında artık "herkese aynı kurallar" yetmiyor.

Rate Limit Kontrol Listesi çözümümüz, farklı ihtiyaçlara uyarlanabilir yapısı, kolay yapılandırılabilmesi ve güçlü performansıyla öne çıkıyor.

Apinizer ile artık kimin ne kadar erişeceğini siz belirlersiniz.