SaaS Tenant Isolation Testi Nasıl Yapılır?

Temel Değerlendirme

SaaS tenant isolation testi, bir kullanıcının başka müşteri, workspace veya organization verisine erişip erişemediğini API, database query, cache, queue, dosya depolama, admin panel ve background job katmanlarında doğrular. Test yalnızca URL'deki ID değerini değiştirmekten ibaret değildir. Tenant sınırı her veri erişiminde, her async işlemde ve her provider çağrısında korunmalıdır. SaaS ürününüzde müşteri verisi ayrımı varsa tenant isolation bir özellik değil, sistemin güvenlik değişmezidir.

Tenant Isolation Neden Kritik?

Çok kiracılı SaaS ürünlerinde aynı uygulama, aynı database veya aynı storage alanı içinde farklı müşterilerin verisini işler. Bu model ölçeklenebilirlik sağlar ama güvenlik sınırını doğru tasarlamayı zorunlu kılar.

Bir tenant isolation hatası şu etkilere yol açabilir:

Başka müşterinin faturası veya raporu görüntülenir.
Dosya storage path'i tahmin edilerek belge indirilir.
Queue job yanlış tenant adına çalışır.
Cache key eksik tasarlandığı için başka kullanıcıya veri döner.
Admin işlemi tenant sınırını gereksiz aşar.
API token farklı organization üzerinde işlem yapar.

Bu riskler çoğu zaman scanner ile bulunmaz; çünkü iş bağlamı gerekir.

Test Nereden Başlar?

İlk adım veri ve rol modelini anlamaktır:

Tenant ne demek: company, workspace, organization, project?
Kullanıcı birden fazla tenant'a üye olabilir mi?
Roller tenant bazlı mı global mi?
Admin kullanıcı tenant sınırını ne zaman aşabilir?
Dosyalar ve cache tenant bazlı ayrılıyor mu?
Queue mesajlarında tenant bilgisi taşınıyor mu?

Bu sorular netleşmeden yapılan test yüzeysel kalır.

Tenant Isolation Test Matrisi

| Katman | Test | Beklenen güvenli davranış | |---|---|---| | API endpoint | Başka tenant'a ait ID ile istek atılır | 403 veya 404; veri dönmez | | Database query | Query tenant filtresi olmadan çalışıyor mu incelenir | Her erişimde tenant koşulu zorunlu | | Cache | Cache key tenant bilgisini içeriyor mu test edilir | Cross-tenant cache hit oluşmaz | | Queue/worker | Job payload tenant sınırını koruyor mu | Worker tenant'ı tekrar doğrular | | File storage | Path veya object key tahmin edilebilir mi | Signed URL ve tenant policy uygulanır | | Admin panel | Admin rolleri gereksiz global erişim alıyor mu | Yetki kapsamı açıkça sınırlıdır | | API token | Token farklı tenant üzerinde kullanılabiliyor mu | Token tenant veya scope sınırına bağlıdır |

Pratik Örnek

Bir proje yönetim SaaS'ında iki tenant olsun: acme ve nova. acme kullanıcısı şu isteği atabiliyor:

GET /api/projects/prj_123/files
Authorization: Bearer acme_user_token

prj_123 aslında nova tenant'ına aitse backend sadece kullanıcının login olmasına bakmamalı. Projenin de kullanıcının aktif tenant kapsamına ait olduğunu doğrulamalı.

Riskli query:

const project = await db.project.findUnique({ where: { id: projectId } });

Daha güvenli yaklaşım:

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

Bu kontrol yalnızca controller'da değil, servis katmanı, worker ve repository pattern içinde de tutarlı olmalıdır.

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "Frontend tenant seçtiriyor, yeterli." | Frontend kontrolü güvenlik sınırı değildir. | | "UUID tahmin edilemez, risk düşük." | ID tahmini zor olsa bile sızıntı, log, referer veya paylaşım yoluyla ID ele geçebilir. | | "Admin her şeyi görmeli." | Admin yetkisi bile audit, scope ve onay modeline bağlı olmalıdır. | | "Sadece API test etmek yeterli." | Cache, queue ve storage katmanları da cross-tenant sızıntı doğurabilir. |

Profesyonel Destek Ne Zaman Gerekir?

Şu koşullardan biri varsa tenant isolation testi geciktirilmemelidir:

Ürün B2B SaaS veya fintech yapısında çalışıyor.
Aynı database içinde birden fazla müşteri verisi var.
Müşteriler dosya, rapor, fatura veya finansal veri tutuyor.
Background job, webhook veya provider entegrasyonu tenant adına işlem yapıyor.
Kurumsal müşteri güvenlik değerlendirmesi veya compliance süreci yaklaşıyor.

Eresus Yaklaşımı

Eresus Security, SaaS API pentestlerinde tenant isolation testini endpoint, query, cache, queue, storage ve admin akışları boyunca yürütür. Amacımız "başka tenant verisi görülebiliyor mu?" sorusuna teknik kanıtla cevap vermektir. SaaS ürününüzde müşteri verisi ayrımı kritikse, API Security Test Plan üzerinden kapsamı birlikte çıkarabiliriz.

SSS

Tenant isolation BOLA ile aynı şey mi?

Yakındır ama aynı değildir. BOLA nesne seviyesinde yetki hatasıdır; tenant isolation ise tüm sistemde müşteri sınırının korunmasıdır.

UUID kullanmak tenant isolation için yeterli mi?

Hayır. UUID tahmini zorlaştırır ama authorization kontrolünün yerine geçmez.

Bu test staging ortamında yapılabilir mi?

Evet, ancak staging ortamı production veri modeli, role model, cache ve storage davranışını temsil etmelidir.

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?