Hızlı cevap: Çok kiracılı (multi tenant) bir yazılım, tek bir uygulama ve veritabanı üzerinde birden fazla müşteriye (kiracıya) hizmet verir; her müşterinin verisi mantıksal olarak ayrılır ama fiziksel olarak aynı sistemde durur. Bu ayrımı sağlayan tek şey genelde bir kiracı numarasıdır (tenant id, property id gibi) ve bu numara istek içinde açıkça taşınıyorsa, sunucu her seferinde "bu isteği yapan gerçekten bu kiracıya mı ait" diye kontrol etmiyorsa, bir kiracı sadece bu numarayı değiştirerek başka bir müşterinin verisine erişebilir. Bu sınıfa çok kiracılı IDOR (Insecure Direct Object Reference) ya da BOLA (Broken Object Level Authorization) denir ve otomatik ölçekte pek çok müşteriyi aynı anda etkileme potansiyeli taşıdığı için özellikle tehlikelidir.

Bir SaaS ürünü büyürken müşteri sayısı arttıkça her müşteri için ayrı bir sunucu kurmak pahalı ve yönetilmesi zor hale gelir. Bunun yerine neredeyse tüm modern SaaS ürünleri tek bir uygulamayı ve tek bir veritabanını binlerce müşteri arasında paylaştırır; buna çok kiracılı mimari denir. Bu mimarinin tüm güvenliği, kiracılar arasındaki sınırın her istekte doğru çizilmesine bağlıdır.

Sorun nerede ortaya çıkar

Çok kiracılı bir sistemde bir API isteği genelde şu şekle benzer: GET /api/menus?propertyId=23. Sunucu bu isteği aldığında iki ayrı şeyi kontrol etmesi gerekir: birincisi, propertyId=23 diye bir kayıt var mı; ikincisi, bu isteği yapan gerçekten propertyId=23'e yetkili mi. Pek çok gerçek dünya olayında geliştirici sadece birinci kontrolü yapar; kayıt var mı diye bakar, kimin sorduğuna bakmaz. Sonuç olarak propertyId değeri 1, 2, 3 diye sırayla denendiğinde sistem her seferinde farklı bir müşterinin verisini olduğu gibi döndürür.

Kontrol türü Ne sorar Eksik olursa sonuç
Varlık kontrolü Bu kayıt var mı Genelde her zaman yapılır
Yetki kontrolü Bu isteği yapan bu kayda erişebilir mi Eksikse çapraz kiracı veri sızıntısı

Neden özellikle tehlikeli

Klasik bir IDOR açığı genelde tek bir kullanıcının verisini etkiler; bir çok kiracılı IDOR ise tüm müşteri tabanını etkileyebilir çünkü kiracı numarası genelde küçük, tahmin edilebilir bir tam sayıdır ve tek bir döngüyle onlarca hatta yüzlerce kiracı taranabilir. Sızan veri türü de önemlidir: bazı durumlarda sadece herkese açık pazarlama içeriği sızarken, bazı durumlarda finansal hesap bilgisi, müşteri kişisel verisi ya da iş sırrı niteliğinde ticari bilgi sızabilir. Bu ayrım, bir bulgunun düşük mü yoksa kritik mi olarak değerlendirileceğini doğrudan belirler; tıpkı genel IDOR ve yetkisiz erişim açıklarında olduğu gibi, etki her zaman veri türüne göre ölçülmelidir, sadece açığın varlığına göre değil.

Tipik bulgu şekilleri

Bu sınıf açık genelde tek bir uç noktada değil, aynı kiracı numarasını kullanan birden fazla uç noktada tekrar eder: menü ve içerik servisleri, arama ve envanter servisleri, ödeme ve tahsilat bilgisi servisleri, hatta oturum açma servisleri kiracı numarasına göre farklı davranış gösterebilir ve bu davranış farkı tek başına hangi kiracı numaralarının gerçekten var olduğunu ortaya çıkarabilir. Bu yüzden bir API güvenlik testi sırasında tek bir uç noktayı doğrulamak yeterli değildir; aynı parametre kalıbını kullanan tüm uç noktalar sistematik olarak taranmalıdır.

Nasıl önlenir

Çözüm mimari düzeydedir: kiracı kimliği hiçbir zaman sadece istekten gelen bir parametreye güvenilerek belirlenmemeli, oturum ya da kimlik doğrulama token'ından türetilmelidir. Veritabanı sorgularının her biri, bu doğrulanmış kiracı kimliğini bir filtre olarak zorunlu kılmalıdır; pek çok modern çerçevede bu, satır düzeyi güvenlik (row level security) ile veritabanı katmanında da uygulanabilir. Bu yaklaşım, bulut güvenlik denetimlerinde da sıkça karşılaşılan "en az yetki" prensibinin bir API düzeyinde uygulanmasıdır.

KAOS ve DSET yaklaşımı

DSET, paylaşımlı SaaS altyapılarında kiracı izolasyonunu sistematik olarak test eder; tek bir istekle değil, bir parametrenin farklı değerlerle tekrar edilmesi sonucunda elde edilen diferansiyel kanıtla. Yerel yapay zekâ motorumuz KAOS, bir uç noktayı farklı kiracı kimlikleriyle otomatik olarak dener, dönen içeriği karşılaştırır ve gerçek bir çapraz kiracı sızıntısını hipotezden ayırarak canlı kanıtla raporlar. Sızan verinin niteliğine (herkese açık içerik mi, finansal bilgi mi, kişisel veri mi) göre etki seviyesi ayrı ayrı değerlendirilir; abartılı bir "kritik" etiketi kadar, gerçek riski küçümsemek de yanlıştır.

Sık sorulan sorular

Çok kiracılı IDOR ile klasik IDOR arasındaki fark nedir? İkisi de aynı temel mantığa dayanır: bir kimliği değiştirerek başkasının verisine erişmek. Fark ölçektedir; klasik bir IDOR genelde tek bir kullanıcıyı hedefler, çok kiracılı IDOR ise bir kiracı numarasının küçük ve öngörülebilir olması sayesinde tüm müşteri tabanını sistematik olarak taramaya açık hale gelir.

Sızan veri herkese açık içerikse bu gerçekten bir güvenlik açığı mıdır? Evet, ama etkisi düşüktür. Sorun sadece verinin gizliliği değil, sistemin yetki kontrolünün tamamen çalışmıyor olmasıdır; bugün herkese açık içerik dönen bir uç noktaya yarın finansal ya da kişisel veri eklenirse aynı kusur çok daha ciddi bir sızıntıya dönüşür. Bu yüzden düşük etkili bir örnek bile kök nedeniyle birlikte düzeltilmelidir.

Bu tür açıklar nasıl tespit edilir? En güvenilir yöntem, gerçek ve yetkili bir hesapla yapılan bir isteğin parametrelerini sistematik olarak değiştirip sonucu karşılaştırmaktır. Statik kod incelemesi bazı durumları yakalayabilir ama asıl kanıt, çalışan sistemde farklı kiracı kimlikleriyle elde edilen gerçek, karşılaştırılabilir yanıtlardan gelir.

Kaynaklar

Çok kiracılı sisteminizin kiracı izolasyonunu test etmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan API ve SaaS güvenlik danışmanlığı sağlıyoruz.