Provider Management Backend Mimarisi

Üçüncü Parti Provider Tek Nokta Hatasıdır

Modern backend sistemleri email, SMS, WhatsApp, push notification, ödeme, KYC, fraud skorlama ve dosya işleme gibi birçok üçüncü parti sağlayıcıya bağlıdır. İlk sürümde tek provider ile başlamak normaldir; ancak ürün büyüdükçe bu bağımlılık operasyonel ve güvenlik riskine dönüşür.

Provider Management katmanı, uygulamanın dış sağlayıcılarla doğrudan değil, kontrollü bir karar katmanı üzerinden konuşmasını sağlar. Böylece provider kesintisi, kota dolması, fiyat değişimi, bölgesel problem veya güvenlik olayı yaşandığında sistem yeniden deploy edilmeden yön değiştirir.

Hard-Coded Provider Neden Riskli?

Kod içinde doğrudan sendWithTwilio() veya sendWithSes() çağırmak basit görünür. Fakat provider değişimi gerektiğinde deployment, config değişimi, test ve rollback süreci gerekir. O an production incident yaşanıyorsa bu gecikme müşteri deneyimini bozar.

Daha kötüsü, tek provider mimarisi saldırgan için hedefi basitleştirir. Provider API key'i sızarsa, rate limit tetiklenirse veya provider hesabı askıya alınırsa sistem tamamen durabilir.

Kontrol Katmanı Nasıl Çalışır?

Sağlıklı bir provider management sistemi şu bileşenlere sahip olmalıdır:

• Provider registry
• Kanal bazlı aktif provider seçimi
• Failover ve fallback kuralları
• Kota ve rate limit takibi
• Health check ve latency ölçümü
• Admin kontrollü provider switch
• Audit log ve approval mekanizması

Uygulama "SMS gönder" der; provider katmanı hangi sağlayıcının kullanılacağına karar verir.

Güvenlik Kontrolleri

Provider switch işlemi kritik bir admin aksiyonudur. Yanlış kişiye bu yetki verilirse saldırgan mesajları kendi kontrol ettiği sağlayıcıya yönlendirebilir veya müşterilere sahte ileti gönderebilir.

Bu nedenle:

• Provider config secret store içinde tutulmalı.
• Admin değişiklikleri approval gerektirmeli.
• Her switch audit log üretmeli.
• Test ve production provider ayrılmalı.
• Webhook imza doğrulaması provider bazında yapılmalı.
• Fallback sırasında veri minimizasyonu korunmalı.

Eresus Yaklaşımı

Eresus Security, backend mimari incelemelerinde provider bağımlılıklarını sadece uptime açısından değil, güvenlik ve veri akışı açısından da test eder. Eğer kullanıcı iletişimi, ödeme veya kimlik doğrulama provider'lara bağlıysa, provider management katmanı iş sürekliliği kadar güvenlik kontrolüdür.

Saha Kontrol Notları

Backend ve API güvenliği, endpoint saymaktan ibaret değildir. Asıl risk çoğu zaman rol, tenant, object ownership ve async iş akışlarında ortaya çıkar.

İnceleme sırasında şu kanıtlar toplanmalıdır:

• Endpoint hangi business object üzerinde çalışıyor?
• Kullanıcı rolü aksiyonla eşleşiyor mu?
• Tenant ID kullanıcıdan mı geliyor, sunucu tarafında mı çözülüyor?
• JWT sadece kimlik taşıyıcısı mı, yoksa yanlışlıkla yetki kaynağı mı yapılmış?
• Rate limit kullanıcı, IP ve maliyetli aksiyon bazında ayrılıyor mu?
• Webhook ve queue tarafında aynı yetki kontrolü tekrar ediliyor mu?
• Loglar object ID ve tenant bağlamını gösteriyor mu?
• Hata cevapları veri sızdırıyor mu?
• Test hesapları gerçek rolleri temsil ediyor mu?
• Retest için net başarı kriteri var mı?

Uygulama Kontrol Listesi

• Her endpoint için ownership kontrolü yazılmalı.
• BOLA ve IDOR testleri rol ve tenant çaprazlamasıyla yapılmalı.
• Admin aksiyonları ayrı onay ve log gerektirmeli.
• Provider entegrasyonları token kapsamı açısından incelenmeli.
• Async job ve webhook akışları test kapsamına alınmalı.
• Bulgular teknik etki ve iş etkisiyle birlikte sınıflandırılmalı.

Karar Noktası

API müşteri verisi, ödeme, abonelik, dosya veya entegrasyon taşıyorsa manuel assessment gerekir. Eresus Security bu noktada scanner çıktısının ötesine geçip yetki hatasını gerçek isteklerle kanıtlar.

Operasyonel İnceleme Checklisti

• Object ownership kontrolü her endpointte var mı?
• Tenant ID sunucu tarafında doğrulanıyor mu?
• JWT kapsamı gerçek yetkilendirme yerine kullanılmıyor mu?
• Webhook ve async job aynı yetki modelini izliyor mu?
• Rate limit maliyetli aksiyonlara göre ayrıldı mı?
• Admin ve düşük yetkili kullanıcı çapraz test edildi mi?
• BOLA ve IDOR senaryoları kanıtla doğrulandı mı?
• Provider token kapsamı daraltıldı mı?
• Hata cevapları gereksiz veri sızdırıyor mu?
• API dokümantasyonu gerçek davranışla uyumlu mu?
• Kapsam net yazıldı mı?
• Etkilenen varlık sahibi belli mi?
• Test ortamı production etkisinden ayrıldı mı?
• Kullanıcı rolleri doğru temsil ediliyor mu?
• Hassas veri sınıfı tanımlandı mı?
• Yetki sınırı teknik olarak doğrulandı mı?
• Log kaynağı ve saklama süresi belli mi?
• Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
• İş etkisi teknik etkiden ayrı açıklandı mı?
• Düzeltme sahibi belirlendi mi?
• Retest kriteri yazıldı mı?
• Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
• Monitoring veya alert tarafında görünürlük var mı?
• Olay müdahale adımı gerekiyorsa planlandı mı?
• Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?