Stoaixhub
Giriş yap
Topluluk
AkışTrending ReposÜyeler
Akademi
Akademi
Kullanım KoşullarıGizlilik PolitikasıKVKK Aydınlatma MetniMesafeli Satış Sözleşmesiİptal, İade ve Cayma Hakkı
© 2026 Stoaix · Tüm hakları saklıdır.
AkışTrending ReposÜyelerAkademi
Akademi

Karşılaştığımız problem: kiracı sınırları

6 dk okumaETEmir Türköz · Kurucu · CTO

Stoaix'i tek bir platform olarak kurduk — ama üstünde onlarca farklı müşteri çalışıyor. Yazılım dünyasında buna çok kiracılı (multi-tenant) mimari deniyor: tek bir uygulama, tek bir veritabanı, ama içinde birbirinden habersiz onlarca "kiracı".

Her kiracının kendi dünyası var: müşteri kayıtları, konuşmaları, bilgi tabanı, faturası. Ve tek bir kural var — basit ama acımasız:

Bir müşterinin verisi, başka bir müşteriye asla görünmemeli. Bir kez sızarsa geri alamazsın; veriyle birlikte güven de sızar.

Kulağa kolay geliyor, değil mi?

"Her sorguya bir müşteri filtresi ekle, bitti" diye düşünülür. Sahada işler böyle yürümüyor. Sistemin büyüklüğünü bir düşün:

  • Yüzlerce API ucu (endpoint)
  • Onlarca ekran ve sayfa
  • Arka planda sessizce çalışan işler (job'lar)

Bunların her birinde kiracı sınırını doğru çekmen gerekiyor. Bir tanesini unutursan, açık sessizce orada bekler — ve fark ettiğinde iş işten geçmiş olabilir.

Asıl tehlike: "sana inanıyorum" hatası

Erken dönemde yaşadığımız şey tam buydu. Bazı uçlar, "hangi müşteriye yazıyorsun?" bilgisini isteğin gövdesinden (request body) alıyordu. Yani kullanıcı "ben şu müşteriyim" diye söylüyordu, sistem de sorgusuz kabul ediyordu.

Kırılgan yaklaşım
  • Kullanıcı gövdede: org_id = "herhangi_biri"
  • Sistem bu iddiaya inanır
  • Sonuç: başkasının verisine erişim
Doğru yaklaşım
  • Sistem sorar: bu kullanıcı hangi kiracının üyesi?
  • Cevabı veritabanından okur
  • Sonuç: iddia değil, gerçek belirler

Bir sonraki derste bu açığın adını (IDOR) ve onu istisnasız her katmanda nasıl kapattığımızı anlatıyorum.

🔐 Çok Kiracılı SaaS'ta Veri İzolasyonu: Bir Müşterinin Verisi Diğerine Sızmasın