Tenant İzolasyonunu Mimari Sınır Olarak Tasarlamak

Çok kiracılı bir SaaS uygulamasında kullanıcıların yalnızca kendi kuruluşlarına ait verilere erişmesi, her sorguya basit bir filtre eklemekten ibaret değildir. Kimlik doğrulama kullanıcının kim olduğunu, yetkilendirme hangi işlemleri yapabileceğini, tenant izolasyonu ise hangi veri kapsamına erişebileceğini belirler. Bu kavramlar birbirine karıştırıldığında çalışan görünen ancak veri sızıntısına açık sistemler oluşabilir.

Her istek için güvenilir bir tenant bağlamı oluşturulmalıdır. Bu bağlam, istemcinin gönderdiği serbest bir tenant_id değerinden türetilmemeli; oturum, erişim belirteci ve sunucu tarafındaki üyelik kaydı birlikte doğrulanmalıdır. Kullanıcının URL’ye başka bir tenant kimliği yazması veya isteğe farklı bir kimlik eklemesi tek başına erişim sağlamamalıdır.

Mimari karar verilmeden önce tehdit modeli çıkarılmalıdır. Tenant’lar yalnızca mantıksal olarak mı ayrılacak, yoksa ayrı şema veya veritabanı mı kullanılacak? Destek personelinin çapraz tenant erişimi olacak mı? Arka plan işleri, raporlar, dosyalar ve önbellek aynı izolasyon kurallarına tabi mi? Bu soruların yanıtı veri modelini ve operasyon maliyetini doğrudan etkiler.

Veri Erişiminde Savunma Katmanları

Tenant’a ait kaynaklarda açık bir tenant ilişkisi bulunması denetimi kolaylaştırır. Uygulama katmanında ortak sorgu yardımcıları, repository kuralları veya merkezi veri erişim servisleri kullanılabilir; ancak güvenlik yalnızca geliştiricinin her sorguya doğru koşulu eklemesine bırakılmamalıdır.

Temel kontroller:

• Kaynak kimliği üzerinden yapılan her okuma, güncelleme ve silme işlemi tenant bağlamıyla birlikte çalışmalıdır.
• Yeni kayıtların tenant bilgisi istemciden değil, doğrulanmış oturum ve üyelik bilgisinden alınmalıdır.
• Bir kaynak bulunamadığında, yetkisiz erişimi açığa çıkarmayacak güvenli ve tutarlı hata yanıtları kullanılmalıdır.
• Toplu arama, dışa aktarma, raporlama ve dosya indirme uç noktaları da aynı tenant sınırını uygulamalıdır.
• Önbellek anahtarlarında tenant kimliği bulunmalı; ortak önbellekte tenant’lar arasında veri karışması önlenmelidir.
• Kuyruğa alınan her arka plan işinde tenant bağlamı açıkça taşınmalı ve iş çalışırken yeniden doğrulanmalıdır.

Veritabanı seviyesinde satır bazlı güvenlik, ayrı şema veya ayrı veritabanı gibi seçenekler tehdit modeli, ekip yetkinliği, yedekleme stratejisi ve işletim maliyetiyle birlikte değerlendirilmelidir. Daha güçlü bir izolasyon yöntemi, hatalı uygulama kodunun tüm etkilerini otomatik olarak ortadan kaldırmaz; ancak bağımsız bir savunma katmanı sağlar. Seçilen modelin sınırları mimari karar kaydında belgelenmeli ve yeni geliştiriciler için görünür olmalıdır.

Rol, Yetki ve İş Kuralını Birbirinden Ayırmak

Yalnızca admin ve user rollerine dayanan bir model ürün büyüdükçe yetersiz kalabilir. Rol tabanlı erişim kontrolü başlangıç için uygun olsa da kaynak sahipliği, ekip üyeliği, abonelik planı, işlem durumu ve özellik bayrakları gibi koşullar için kaynak veya özellik tabanlı kurallar gerekebilir.

Örneğin bir kullanıcının raporu görüntüleyebilmesi, raporu silmeye veya dışa aktarmaya yetkili olduğu anlamına gelmez. Bir işlemi değerlendirirken şu sıra izlenebilir:

• Kullanıcı etkin ve kimliği doğrulanmış mı?
• İlgili tenant’ın geçerli bir üyesi mi?
• Kaynak gerçekten aynı tenant’a mı ait?
• Rol veya izin ilgili eylemi destekliyor mu?
• İş kuralı, kaynağın mevcut durumunda bu işlemi engelliyor mu?
• Plan limiti, kota veya onay gereksinimi işlemi kısıtlıyor mu?

Bu kontrolleri denetleyicilere dağınık biçimde yazmak yerine merkezi yetki servisleri veya açık politika fonksiyonları kullanılmalıdır. Politika fonksiyonları test edilebilir, isimleri anlaşılır ve varsayılan davranışları reddetmeye yönelik olmalıdır. Yetki reddi yanıtlarında gereksiz iç detaylar gösterilmemeli; günlüklerde inceleme için gereken güvenli bağlam, hassas veri kaydedilmeden tutulmalıdır.

Test, Kod Kalitesi ve Sürüm Kontrolü

Tenant izolasyonu yalnızca başarılı isteklerle test edilemez. Her kaynak türü için farklı tenant’a ait bir kimlikle okuma, güncelleme, silme ve dışa aktarma denemeleri yazılmalıdır. Aynı kurallar API uç noktaları, yönetim ekranları, zamanlanmış görevler ve kuyruk tüketicileri için ayrı ayrı doğrulanmalıdır.

Öncelikli test senaryoları:

• Geçerli bir kullanıcının başka tenant’a ait kaynak kimliği göndermesi.
• Tenant üyeliği kaldırıldıktan sonra eski erişim belirteciyle istek yapılması.
• Arka plan işinin tenant bağlamı olmadan kuyruğa alınması.
• Bir tenant’ın önbellek sonucunun başka tenant’a dönmesi.
• Yetkisiz kullanıcının toplu dışa aktarma veya geniş kapsamlı arama uç noktasını çağırması.
• Bir tenant’a ait dosya, webhook veya bildirim bağlantısının başka tenant tarafından kullanılması.

Birleştirme taleplerinde yalnızca işlevsel test sonucu değil, tenant sınırı, yetki politikası ve geri dönüş davranışı da incelenmelidir. Tehlikeli değişiklikler küçük ve geri alınabilir sürümlere bölünmeli; şema değişiklikleri önce geriye uyumlu biçimde uygulanmalı, ardından uygulama kodu yeni alanları kullanmalı ve son aşamada eski yapı kaldırılmalıdır. Gerçek kişisel veriler test ortamına taşınmamalı, başarısız yetki denemeleri ölçülebilir metriklerle izlenmelidir.

Geçiş, Gözlemlenebilirlik ve Bakım Maliyeti

Yeni bir tenant modeline geçmeden önce veri envanteri çıkarılmalı, tenant sahibi bulunmayan kayıtlar belirlenmeli ve migrasyon planı hazırlanmalıdır. Büyük tablolarda uygun indeksler oluşturulmalı; kilitlenme, uzun süren sorgular ve geri alma senaryoları önceden değerlendirilmelidir. Eski ve kapsamı belirsiz sorgular doğrudan silinmek yerine önce gözlemlenebilir hâle getirilmeli, sonra güvenli biçimde dönüştürülmelidir.

Üretim günlüklerinde kişisel veya hassas içerik yerine tenant, kullanıcı, kaynak türü ve sonuç kodu gibi sınırlı bağlamlar tutulabilir. Yetki reddi oranındaki artışlar, beklenmeyen tenant değişimleri, olağandışı dışa aktarma hacmi ve erişim politikası hataları için alarm tanımlanmalıdır. Destek veya yönetici erişimi gerekiyorsa süreli yetki, gerekçe, onay ve denetim kaydı gibi ek kontroller uygulanmalıdır.

Sürdürülebilir bir SaaS mimarisi; veri modelini, yetki politikasını, testleri, sürümleme sürecini ve operasyonu birlikte ele alır. En düşük maliyetli çözüm, en az kod yazılan çözüm değildir. Açık tenant sınırları, merkezi kontroller, savunma katmanları ve saldırgan test senaryoları; veri sızıntısı riskini ve ürün büyüdükçe ortaya çıkacak pahalı yeniden yazımları azaltır.