Tenant İzolasyonunu Bozmadan Multi-Tenant Erişim Kontrolü

Tenant İzolasyonu SaaS Dünyasında En Azımsanan Güvenlik Sınırlarından Biri

Çok kiracılı (multi-tenant) bir üründe geçerli bir kimlik doğrulama tokeni tek başına yetmez. Sistem, her anlamlı işlemde çağıranın doğru tenant kapsamına ait olduğunu ve eriştiği nesne ya da işlevle meşru bir ilişkisi bulunduğunu doğrulamak zorundadır. Kimlik doğrulamayı geçmek yalnızca giriş kapısıdır — tenant kapsamına göre yetkilendirme ise asıl kontrol mekanizmasıdır.

Bu prensip kulağa açık gelse de SaaS güvenlik olaylarının büyük bir kısmı tam olarak bu boşluktan kaynaklanır: kimlik doğrulama temiz biçimde geçer; tenant izolasyonu ise bir yerlerde sessizce bozulur.

İzolasyon Modelleri: Tekli ve Çok Kiracılı Karşılaştırması

Her izolasyon modeli eşit risk taşımaz. Aşağıdaki tablo, tekli (single-tenant) ve çok kiracılı dağıtım arasındaki temel farklılıkları gösteriyor; bunları tasarım aşamasında göz önünde bulundurmak şart:

| Boyut | Tekli Kiracı | Çok Kiracılı |

|-------|-------------|--------------|

| Veri sınırı | Müşteri başına ayrı veri tabanı | Paylaşımlı veri tabanı; satırlar tenant ID ile etiketlenir |

| Yanlış yapılandırmanın patlama yarıçapı | Tek müşteri etkilenir | Tüm tenantlar potansiyel olarak etkilenebilir |

| Çapraz tenant riski | Mimari gereği yok | Var; açık yaptırım zorunlu |

| RLS zorunluluğu | İsteğe bağlı | Zorunlu |

| Denetim karmaşıklığı | Düşük | Yüksek; tenant başına log filtreleme gerekir |

Tenant İçi Rol Hiyerarşisi

Tenantlar arası izolasyon bir ekseni oluşturuyor. Tenant içi rol tabanlı yetkilendirme ise diğer eksen. Kullanıcı bir tenant sınırının içine girdikten sonra ayrıcalık yükseltmesini önlemek için net bir rol hiyerarşisi şart:

SuperAdmin → tam sistem erişimi, çapraz tenant işlemler (yalnızca platform operatörlerine açık)

Admin → kendi tenant'ında tam erişim; başka tenantları okuyamaz

Analist → kendi tenant'ında okuma ve not ekleme; yapılandırma değişikliği yapamaz

Salt Okunur → yalnızca okuma; bulguları veya ayarları değiştiremez

Uygulamadaki her işlem hem tenant kapsamına hem de rol seviyesine karşı doğrulanmalıdır — ikisinden birine değil, her ikisine.

Tasarımlar En Çok Nerede Kırılıyor?

Kırılma neredeyse her zaman login akışında değil, servis mantığında yaşanır. Tekrarlayan örüntüler şunlardır:

nesneleri sorguyu çağıranın tenant kapsamına bağlamadan yalnızca identifier ile çekmek.

işlemi başlatan kullanıcıdan daha geniş erişim haklarıyla çalışan arka plan jobları ve asenkron işçiler.

normal izolasyon garantilerini yeterli loglama olmadan devre dışı bırakan destek araçları ve admin override akışları.

verileri tenant sınırları genelinde farkında olmadan birleştiren analitik aggregation'lar ve export özellikleri.

Bu açıklar özellikle tehlikelidir; çünkü bir müşteri başka bir tenant'a ait veriyle karşılaşana kadar sistem tamamen sağlıklı görünür. O noktaya gelene kadar maruziyet penceresi çoğu zaman uzun süredir açık durumdadır.

Sağlam İzolasyon Neye Benzer?

Güçlü çok kiracılı yetkilendirme tasarımı birkaç temel özelliği tutarlı biçimde paylaşır:

tenant kimliği, tam istek işleme yolu boyunca açık ve değişmez biçimde taşınır.

her nesne erişimi, yalnızca API sınırında değil, veri alım noktasında tenant kapsamına karşı doğrulanır.

idari istisnalar ve destek override'ları nadir tutulur, kapsamlı biçimde loglanır ve periyodik olarak gözden geçirilir.

row-level security (satır düzeyinde güvenlik) gibi veri katmanı yaptırım mekanizmaları, uygulama katmanı yetkilendirme mantığının yerini almak yerine onu güçlendirir.

MyVuln Yaklaşımı

MyVuln gibi bir güvenlik platformu için bu model salt bir mühendislik meselesi değil, doğrudan bir müşteri güveni meselesidir. Row-level security politikaları, platformdaki her sorgu için veri tabanı katmanında uygulanıyor; böylece uygulama katmanı yetkilendirme mantığında bir boşluk olsa bile veri katmanı çapraz tenant erişim girişimini reddediyor. Güvenlik ürününde çapraz tenant izolasyon belirsizliği, müşteri güvenini neredeyse başka herhangi bir hata sınıfından daha hızlı çökerter. Güçlü erişim kontrolü, ilk olay sonrası yamalar yerine baştan tasarıma gömülmek zorundadır.

Multi-tenant mimarilerde en büyük hata, tenant izolasyonunu yalnızca oturum açma anında doğrulanan bir özellik gibi görmektir. Gerçek veri sızıntıları çoğu zaman görünür kullanıcı akışında değil, çevresindeki yardımcı sistemlerde ortaya çıkar: bulk export uçları, arka plan job'ları, raporlama servisleri, destek ekiplerinin kullandığı admin panelleri, toplu arama fonksiyonları ve cache katmanları bu açıdan özellikle tehlikelidir. Her biri "üst katman zaten doğruladı" varsayımıyla biraz daha geniş erişim yetkisiyle çalışmaya başlar. Yetki sınırı bir kez gevşedi mi, veri doğru kullanıcıya değil; doğru görünen isteğe akar.

Bu nedenle sağlam izolasyon tek noktada değil, birbirinden bağımsız birden fazla katmanda tekrar edilmelidir. Katmanlı bir uygulama örneği:

Kimlik doğrulama token'ı — isteği JWT claim üzerinden belirli bir tenant bağlamına daraltır.

Servis katmanı — kayıt sahipliğini doğrular: if (record.tenant_id !== user.tenant_id) throw 403.

Veri katmanı (RLS) — row-level security, uygulama mantığı hata yapsa bile yetkisiz tenant satırını reddeder.

Object storage — bucket politikaları tenant önekli yol erişimini zorlar: tenant/{tenant_id}/*.

Arama indeksleri — filtre sonuç gösteriminde değil, sorgu anında uygulanır.

Raporlama deposu — WHERE clause'lu paylaşımlı view değil; tenant başına ayrı materialized view veya şema.

Üstelik iyi ekipler tenant izolasyonunu mutlu senaryo değil, kasıtlı kötü senaryo üzerinden test eder. Bir kullanıcının başkasına ait nesneyi ID manipülasyonuyla görmeye çalışması, export kuyruğuna yanlış tenant kapsamının düşmesi, destek personelinin geçici erişim token'ıyla neyi görüp göremeyeceği ve cache temizliği sonrası eski yanıtların farklı bir tenant'a sızıp sızmadığı gibi senaryolar bu testlerin temelini oluşturur. Multi-tenant bir üründe güvenlik sınırı doğrudan ürünün kendisidir. Özellik seti ne kadar zengin olursa olsun, sızdıran bir izolasyon sınırı platforma duyulan kurumsal güveni kalıcı biçimde zedeler.