Fintech Bulk Messaging Control Architecture

Bulk Messaging Sadece Operasyon Değil, Riskli Bir Yetkidir

Fintech sistemlerinde toplu mesaj gönderimi müşteri bilgilendirme, kampanya, OTP dışı uyarı, ödeme hatırlatma ve kriz iletişimi için kullanılır. Ancak bu yetki yanlış tasarlanırsa müşteri güvenini doğrudan etkileyen büyük bir saldırı yüzeyine dönüşür.

Bir saldırgan bulk messaging paneline erişirse binlerce müşteriye sahte bağlantı gönderebilir, marka güvenini zedeleyebilir veya finansal dolandırıcılık kampanyası başlatabilir. Bu yüzden bulk messaging sıradan admin özelliği değildir; yüksek riskli işlem olarak tasarlanmalıdır.

Kontrol Mimarisinin Temel Katmanları

Güvenli bulk messaging sistemi şu katmanları içermelidir:

Segment kontrolü: Kimlere mesaj gideceği açıkça doğrulanmalı.
İçerik kontrolü: Link, domain, para ifadesi ve kişisel veri taranmalı.
Onay akışı: Yüksek hacimli kampanyalar çift onay istemeli.
Provider seçimi: SMS, e-posta ve WhatsApp provider'ları merkezi yönetilmeli.
Kota ve hız sınırı: Hacim tenant, kampanya ve kanal bazında kısıtlanmalı.
Audit log: Kim, ne zaman, kime, hangi içerikle gönderdi sorusu cevaplanmalı.

Bu katmanlar olmadan bulk messaging sadece "send loop" olur.

Saldırı Senaryoları

En sık görülen senaryolar:

Admin hesabı ele geçirilir ve phishing mesajı gönderilir.
Test kampanyası yanlışlıkla production segmentine çıkar.
Segment filtresi manipüle edilerek farklı müşteri grubuna erişilir.
Provider webhook'u sahte delivery status ile sistemi yanıltır.
Retry hatası aynı mesajı binlerce kez gönderir.
Rate limit olmadığı için provider maliyeti patlar.

Bu senaryoların her biri teknik olduğu kadar reputasyon riskidir.

Güvenli Tasarım İlkeleri

Bulk messaging sisteminde içerik ve hedef kitle immutable campaign snapshot olarak saklanmalıdır. Onay verilen içerik sonradan değiştirilememeli; değişirse onay süreci yeniden başlamalıdır. Link domainleri allowlist ile kontrol edilmeli, kısaltılmış URL kullanımına kısıt getirilmelidir.

Gönderim worker'ları idempotent olmalı ve provider response'ları audit ile ilişkilendirilmelidir. Bir mesajın kaç kez denendiği, hangi provider üzerinden gittiği ve son durumunun ne olduğu sonradan kanıtlanabilmelidir.

Eresus Yaklaşımı

Eresus Security, fintech backend testlerinde bulk messaging akışlarını yetki, segment izolasyonu, provider güvenliği, retry davranışı ve audit izleriyle birlikte değerlendirir. Müşteriye mesaj gönderebilen her sistem, saldırgan için doğrudan sosyal mühendislik platformudur.

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?