1. Kaynak Sömürme Saldırıları (Resource Exhaustion) Nedir?
Resource exhaustion; sistemi “hacklemekten” çok, kaynaklarını tüketerek erişilemez hale getirmeyi hedefler. Bazen saldırı değildir; kötü yazılmış bir sorgu, rapor/export gibi ağır işlem veya yanlış konfigürasyon da aynı etkiyi doğurur. Ortak payda: CPU/RAM/connection/worker gibi kaynakların kontrolsüz tüketilmesi.
Kaynak sömürme saldırıları (resource exhaustion) nedir, nasıl önlenir?
Resource exhaustion; çok sayıda istek veya ağır işlemlerle CPU/RAM/connection gibi kaynakları tüketip hizmeti yavaşlatma/çökertme durumudur. Önleme; katmanlı limit koymak (OS/web/app), kritik endpoint’lerde rate limit ve throttling uygulamak, ağır işleri kuyruklamak ve limit aşımlarında kontrollü “graceful degradation” ile yanıt vermektir.
Neden “limit” güvenlik kontrolüdür?
Limitler; saldırganın “sonsuz deneme” ve “sonsuz kaynak tüketimi” imkânını kısar. Aynı zamanda gerçek kullanıcıların trafik dalgalanmasında tamamen kaybolmasını engeller. Sheet’teki veri noktasıyla uyumlu olarak; limit stratejisi oturan projelerde ani artışlar kesintiye dönüşmeden kontrollü yavaşlama ile yönetilebilir.
☑ Mini Check: Resource exhaustion sinyalleri
- •CPU/RAM spike aniden mi yükseliyor?
- •Connection sayısı tavan yapıyor mu?
- •Belirli endpoint’ler (login/search/export) yoğunlaşıyor mu?
- •5xx artışı p95 latency ile birlikte mi yükseliyor?
- •429/limit tetikleri hiç yok mu (yani limit yok mu)?
Ne yapmalıyım?
- • Sinyali topla: endpoint bazlı yoğunluk, CPU/RAM, queue depth.
- • Limitleri katmanlı kur: OS→web server→uygulama→API.
- • Kritik endpoint’lere ayrı profil koy (login/search/export).
- • Aşımda “kibar” yanıt + geri dene stratejisi tasarla.
2. CPU/RAM ve Connection Limitleri
Burada amaç; sistemi “sonsuz kaynak” gibi davranmaktan çıkarıp kontrollü bir kapasite modeline sokmaktır. Limit yoksa bir kullanıcı veya bir endpoint tüm kaynakları tüketebilir. Limit varsa sistem “öncelik” belirleyebilir.
CPU/RAM ve connection limitlerini nasıl ayarlamalıyım?
Önce kritik iş akışları için (login/booking/search, rapor/export) normal kullanım desenini ölçün; p95/p99 ve peak değerleri çıkarın. Sonra OS ve uygulama seviyesinde makul sınırlar koyup, aşımlarda 429/503 gibi kontrollü yanıt ve backoff stratejisi uygulayın. Hedef; “tam çöküş” yerine “kısa süreli kontrollü yavaşlama”dır.
Connection limitleri (TCP ve web server)
- •Aynı anda kabul edilecek bağlantı sayısı
- •Keep-alive dengesi (çok yüksekse kaynak tüketir)
- •Slow client ve benzeri durumlarda zaman aşımı politikaları
Worker/thread/queue limitleri (uygulama tarafı)
- •Worker sayısı ve iş kuyruğu sınırı
- •Ağır işlerin ayrı işçi havuzuna alınması (export/rapor)
- •DB bağlantı havuzu (pool) ve maksimum eşzamanlı sorgu
“Kritik akışlar” için önceliklendirme
Otel: booking/search akışını korumak; rapor/analytics işleri gerektiğinde yavaşlatmak.
B2B: portal login ve kritik işlemler öncelik; büyük export işleri kuyrukta.
☑ Mini Check: Kaynak limit seti
- •Web server connection/timeouts tanımlı
- •Worker/thread sayısı ve queue kapasitesi tanımlı
- •DB connection pool limitleri var
- •Ağır işler ayrı kuyruk/pool’da
- •Peak anında kritik akışlar korunuyor
Ne yapmalıyım?
- • Export/rapor gibi ağır işleri ayrı kuyruğa al.
- • Web server timeouts ve connection limitlerini ayarla.
- • DB pool limitini “kırılma noktası”na göre belirle.
- • Kritik akışları (booking/login) önceliklendir.
3. Uygulama Katmanında Rate Limit ve Throttling
Rate limit “kaç istek?” sorusunu sınırlar; throttling ise “yük altında nasıl yavaşlatırım?” sorusunu yönetir. İkisi farklıdır: rate limit genelde 429 ile keser; throttling daha kontrollü bir QoS uygular (kuyruğa alma, geciktirme, degrade).
Rate limit ve throttling stratejisi nasıl kurgulanır?
Önce endpoint’leri sınıflandırın: kritik (login/booking/search), ağır (rapor/export), düşük risk (statik içerik). Sonra kimlik bazlarını seçin: IP, kullanıcı, token, tenant. Kritik endpoint’lerde daha sıkı rate limit; ağır endpoint’lerde kuyruk + throttling; aşımda ise net mesaj ve backoff ile kullanıcı deneyimini yönetin. Tüm kuralları log/izleme ile iteratif ayarlayın.
Endpoint bazlı strateji (otel + B2B örnekleri)
- •/login: brute-force ve abuse’a karşı sıkı limit
- •/booking: kritik gelir akışı; limit var ama “kibar” davranış (graceful)
- •/search: bot taramasına açık; hız sınırı + cache + davranış kontrolü
- •/report/export: en ağır; kuyruk + job id + asenkron çıktı (mümkünse)
Graceful degradation (kullanıcı deneyimi)
Limit aşımlarında iki hatalı uç var:
- •Sert kesmek (her şeyi 429/500) → iş kaybı
- •Hiç kesmemek → sistem çöker
Aradaki doğru yaklaşım:
- •Kritik akışı koru (booking/login)
- •Ağır işleri geciktir/kuyruğa al (export)
- •Net hata mesajı + retry-after/backoff
☑ Mini Check: Rate limit tasarımı
- •Endpoint’ler kritik/ağır/normal sınıflandı
- •Kimlik bazları seçildi (IP/kullanıcı/token)
- •Login için sıkı limit + lockout stratejisi var
- •Export işleri kuyruklanıyor (asenkron)
- •429/503 mesajları kullanıcıya yön gösteriyor
Ne yapmalıyım?
- • Endpoint sınıflandırması yap; her endpoint aynı değildir.
- • Export’u asenkrona çevir; job id ile yönet.
- • Login ve search için ayrı kurallar koy; bot etkisini azalt.
- • Limit aşımlarını raporla; eşikleri gerçek kullanıma göre ayarla.
4. Otel ve B2B İçin Örnek Limit Stratejileri
Bu bölüm “örnek değer” bekleyen ekipler için çerçeve verir; ancak değerler altyapıya göre değişir. Burada amaç sayı ezberi değil; profil mantığıdır: kritik akış = koru, ağır iş = kuyrukla, riskli uç = sıkı sınırla.
Otel — booking/search akışları
- •Search: cache + kısa süreli limit (botları kes)
- •Booking: daha tolerant limit + WAF/CDN ile koruma
- •Login: sıkı limit + anomali alarmı
B2B — rapor/export istekleri
- •Export: asenkron job, kişi/token bazlı limit, queue kapasitesi
- •Rapor: sayfalama, maksimum aralık, “bir seferde çok veri” engeli
- •API: tenant bazlı QoS (enterprise müşteriye farklı profil olabilir)
Otel/B2B için login/booking/search ve rapor/export istekleri için örnek limitler neler?
Örnek yaklaşım; login’de sıkı IP/kullanıcı limitleri, search’te kısa pencereli hız sınırı ve cache, booking’de daha toleranslı ama abuse’ı yakalayan kurallar, export’ta ise asenkron kuyruk + token bazlı limit ve maksimum eşzamanlı job sınırıdır. Değerler, gerçek kullanım loglarından türetilip iteratif ayarlanmalıdır.
☑ Mini Check: Profil bazlı limit
- •Her endpoint için profil belirlendi
- •Booking/login korunuyor, export kontrol altında
- •Queue kapasitesi ve worker limiti tanımlı
- •Tenant/kullanıcı bazlı QoS var
- •Limit ihlali kullanıcı deneyimi tasarlandı (graceful)
Ne yapmalıyım?
- • Rapor/export’i “kritik akış”tan ayır ve asenkronlaştır.
- • Booking/login için “kesintisiz” hedef; agresif koruma + kibar hata.
- • Search’te bot ve cache stratejisini birlikte kullan.
- • QoS profilini müşteri/tenant bazlı düşün (B2B).
5. İzleme ve Alarm
Limit koymak tek başına yetmez; yanlış limit “gizli kesinti” üretir. Bu yüzden izleme; performans+güvenlik stratejisinin son halkasıdır.
Hangi metrikler izlenmeli?
- •429/403/503 oranı (limit ve koruma etkisi)
- •p95/p99 latency, 5xx oranı
- •CPU/RAM, connection, queue depth
- •Endpoint bazlı istek yoğunluğu (login/search/export)
Alarm stratejisi (az ama etkili)
- •429 patlaması: abuse veya yanlış eşik
- •Queue depth tavan: export/worker kapasite sorunu
- •p95↑ + 5xx↑: overload/kaynak tükenmesi
Bu sinyaller, raporlama panellerine bağlanmalı. Sheet’teki bağlantı notuyla uyumlu olarak; özellikle rapor/export akışlarının izlenmesi için /tr/raporlama/satis-donusum ve /tr/veri-analiz-ve-raporlama ile birlikte düşünülmelidir.
☑ Mini Check: İzleme doğrulaması
- •429/503 trendleri dashboard’da
- •Queue depth ve worker tüketimi izleniyor
- •Endpoint bazlı metrikler var
- •Alarm eşikleri runbook’a bağlı
- •Limitler periyodik gözden geçiriliyor (180 gün)
Ne yapmalıyım?
- • Limitleri metriklerle doğrula; gürültü ve false-positive’i azalt.
- • Export/rapor için ayrı dashboard kur.
- • Alarm → runbook → aksiyon zincirini tamamla.
- • 180 günde bir eşikleri loglardan yeniden ayarla.
6. İçerik İçi Tablo: Endpoint Türleri İçin Örnek Limit Profilleri
| Endpoint türü | Risk | Limit/Throttling yaklaşımı | Kullanıcı deneyimi |
|---|---|---|---|
| /login | Brute-force | Sıkı rate limit + anomali | Net mesaj + kısa bekleme |
| /search | Bot taraması | Kısa pencere limit + cache | Kademeli yavaşlama |
| /booking | Gelir kritik | Toleranslı limit + koruma | Önceliklendirme + graceful |
| /report | Ağır sorgu | Sayfalama + limit | “Daha dar aralık” yönlendirme |
| /export | En ağır | Asenkron job + queue | Job ID + sonra indir |
7. Kritik Endpoint’ler İçin Kaynak/Rate Limit & Throttling Planlama Şablonunu İndir
Kritik Endpoint’ler İçin Kaynak/Rate Limit & Throttling Planlama Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu şablon, performans ve güvenliği birlikte ele alan katmanlı limitleme modeli kurmak için hazırlanmıştır. OS/web server/uygulama/API katmanlarında kaynak limitlerini ve endpoint bazlı rate limit/throttling profillerini tek dokümana toplar. Amaç; ani trafik artışlarında kesinti yerine kontrollü yavaşlama ve net uyarılarla sistemi korumaktır.
Kim Kullanır?
Backend, DevOps/SRE, platform mühendisliği; otel/B2B ürün ekipleri.
Nasıl Kullanılır?
- Kritik endpoint envanterini ve risk sınıfını çıkar.
- Katman bazlı limitleri ve throttling davranışını yaz (kuyruk + degrade).
- İzleme/alarmları ekleyip eşikleri loglardan iteratif ayarla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Endpoint sınıflandırması yapıldı
- ▢ ✅ Export işleri asenkron/kuyruklu
- ▢ ✅ Booking/login önceliklendirildi
- ▢ ✅ 429/503 mesajları ve retry stratejisi net
- ▢ ✅ İzleme ve alarm seti kuruldu
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5) Kontrol listesi
- •Endpoint sınıflandırması yapıldı
- •Export işleri asenkron/kuyruklu
- •Booking/login önceliklendirildi
- •429/503 mesajları ve retry stratejisi net
- •İzleme ve alarm seti kuruldu
Bir Sonraki Adım
Booking/search ve rapor/export gibi kritik endpoint’lerde kesintiyi kontrollü yavaşlamaya çevirmek isteyen otel ve B2B backend/DevOps ekipleri için.