Backend Authorization ve Tenant Isolation

Backend Güvenliğinin Kalbi Authorization'dır

Authentication kullanıcının kim olduğunu söyler. Authorization ise neye erişebileceğini belirler. Çok kiracılı SaaS sistemlerinde asıl kırılma genellikle ikinci tarafta yaşanır. Kullanıcı doğru giriş yapmıştır ama başka tenant'a ait kaynaklara erişebiliyordur.

BOLA ve IDOR zafiyetleri bu nedenle yalnızca API endpoint problemi değildir. Veri modeli, query tasarımı, cache anahtarı, queue mesajı ve background job akışı tenant sınırını birlikte korumalıdır.

Yanlış Tasarım Örneği

En tehlikeli pattern şudur:

const invoice = await db.invoice.findUnique({ where: { id: invoiceId } });

Bu query doğru faturayı getirir ama faturanın mevcut kullanıcının tenant'ına ait olduğunu kanıtlamaz. Doğru yaklaşım tenant filtresini veri erişiminin vazgeçilmez parçası yapmaktır:

const invoice = await db.invoice.findFirst({
  where: {
    id: invoiceId,
    tenantId: session.tenantId,
  },
});

Bu fark küçük görünür ama SaaS güvenliğinde üretim ile ihlal arasındaki çizgidir.

Tenant Isolation Kontrol Listesi

Her kaynak sorgusunda tenant filtresi zorunlu olmalı.
Cache key içinde tenant bilgisi yer almalı.
Admin rolleri tenant sınırını otomatik kaldırmamalı.
Background job içinde tenant tekrar doğrulanmalı.
Dosya depolama path'i tenant bazlı ayrılmalı.
Audit log kullanıcı, tenant ve kaynak ilişkisini birlikte tutmalı.

Eresus Yaklaşımı

Eresus Security, backend ve API güvenlik testlerinde tenant isolation kontrollerini iş mantığı seviyesinde zorlar. Scanner'ların kaçırdığı BOLA ve IDOR açıkları çoğu zaman tek bir endpoint'ten değil, sistemin veri erişim alışkanlığından doğar.

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?