Satır düzeyi filtreler sorgu zamanı vaadidir, depolama zamanı garantisi değil
En yaygın çok kiracılı mimari şöyle görünür: tek veritabanı, tek şema, her tabloda bir tenant_id sütunu ve her sorguda bir WHERE tenant_id = ? koşulu. Çalışır ve uzun süre görünmezdir — teslim baskısı altında yazılan tek bir uç nokta filtreyi unutana kadar. Kaçırılan o tek koşul, kiracılar arası bir veri sızıntısıdır ve rahatsız edici gerçek şudur: bu mimari o hatayı yapısal olarak yapmayı kolaylaştırır, çünkü izolasyon garantisi, her sorguda, her seferinde, sonsuza dek doğru yazılması gereken uygulama kodunda yaşar.
Bir denetim, filtrenin çoğu zaman mevcut olmasıyla ilgilenmez. İzolasyon sınırının, "çoğu zaman"ın yeterli olmadığı bir katmanda uygulanıp uygulanmadığıyla ilgilenir — eksik bir filtrenin başkasının verisini sessizce döndürmek yerine yüksek sesle başarısız olduğu bir katmanda.
İzolasyonu depolama katmanına indirmek
Alternatif, kiracılar arası erişimi prosedürle engellemek yerine yapısal olarak imkânsız kılmaktır. TotalApp'in yaklaşımı, kendi uygulamasının dışında bile ilkeyi göstermek için faydalı bir örnektir: kiracı verisi, yolun içinde doğrudan kiracı ID'sini barındıran JSON dosyaları olarak saklanır — server/data/tenants/<tenantId>/<module>/... — dolayısıyla yanlış kiracı bağlamına sahip bir istek işleyicisi yalnızca yanlış satırları sorgulama riski taşımaz, fiziksel olarak farklı bir dosya yolundan okur. Yanlış filtrelenebilecek paylaşımlı bir tablo yoktur, çünkü paylaşımlı bir tablo yoktur.
Bu, kiracı başına dosya depolamanın tek geçerli desen olduğu savı değil — veritabanının kendisi tarafından uygulanan satır düzeyi güvenlik politikalarıyla iyi tasarlanmış çok kiracılı bir Postgres şeması da aynı yapısal garantiyi sağlar. Önemli olan ilke her iki durumda da aynıdır: kiracı sınırı, her yeni uç noktanın uymayı hatırlaması gereken bir gelenek tarafından değil, unutamayan bir şey tarafından uygulanmalıdır.
- ✓İzolasyon yalnızca uygulama düzeyindeki sorgu mantığında değil, atlanamayacak katmanda uygulanır — dosya yolu, veritabanı RLS politikası ya da depolama ad alanı
- ✓Yeni uç noktalar izolasyon sınırını, her yazarın
WHERE tenant_idkoşulunu hafızadan doğru yeniden yazması yerine yapısı gereği devralır - ✓Tek bir eksik filtre "uç nokta başka kiracının verisini döndürüyor" yerine "uç nokta çalışmıyor" durumuna dönüşür
Kişisel veri ikinci, dikey bir sınırdır
Kiracı izolasyonu "hangi şirket bunu görebilir" sorusunu yanıtlar. "O şirket içinde hangi kişi bunu görebilir" sorusunu yanıtlamaz. Kişisel, kullanıcıya özel veriler — taslak belgeler, bireysel tercihler, bir kullanıcının kendi yapay zeka sohbet geçmişi — kiracı sınırının altında kendi sınırına ihtiyaç duyar; genellikle paylaşımlı modül klasörlerine karıştırılmak yerine kiracının ad alanı içinde kullanıcı ID'siyle anahtarlanır. İkisini karıştırmak daha ince bir denetim hatasıdır: teknik olarak veri kiracıdan hiç çıkmamıştır, ancak modül erişimi olan herhangi bir yönetici ya da ekip arkadaşı artık başka bir çalışanın kişisel taslaklarını görebilir; bu, özellikle İK ve hukuk bağlamlarında başlı başına bir uyumluluk sorunudur.
"Bir denetim, herkes geleneğe doğru uyduğunda ne olacağını değil, biri hata yaptığında ne olacağını sorar."
Denetçiler gerçekte neyi araştırır
Ciddi bir çok kiracılı güvenlik incelemesi yalnızca izolasyonu sağlaması beklenen kodu okumaz — bu uygulamanın ihmal yoluyla atlanabileceği kod yollarını arar. Sık bulgular: dahili araçlar için tüm kiracılar üzerinde sorgu yapan ve daha geniş kitleye açıldığında bir daha kapsamlandırılmayan bir yönetici uç noktası; kaynak ID'siyle anahtarlanmış ama kiracı ID'si katılmamış bir önbellek katmanı, dolayısıyla önbellek isabeti yanlış kiracının önbelleğe alınmış yanıtını sunar; "X türündeki tüm kayıtlar" üzerinde kiracı döngüsü sınırı olmadan yineleyen bir arka plan işi ya da zamanlanmış görev; orijinal şema tasarımının öngörmediği bir biçimde veri birleştiren bir dışa aktarma ya da raporlama özelliği.
Bunların her biri aynı kök nedenin bir çeşididir: izolasyon mantığı bir kez yapısal olarak garanti edilmek yerine, uygulama kodunda, her çağrı noktasında yeniden değerlendirilerek yaşar. Her durumda çözüm aynıdır — sınırı mimarinin izin verdiği en yakın noktada depolamaya yaklaştırın ve "tüm kiracıları" sorgulayan her kod yolunu normal bir desen değil, ayrıcalıklı ve açıkça denetlenen bir istisna olarak ele alın.
Bunu sonradan yamamak yerine ilk günden kurmak
Satır düzeyi filtrelerle başlamış bir sisteme depolama katmanı izolasyonunu sonradan eklemek pahalıdır — genellikle bir veri geçişi, her veri erişim fonksiyonunun yeniden yazılması ve iki desenin bir arada bulunup birbirinden kayabileceği bir dönem anlamına gelir. Bunu doğru yapmanın daha ucuz zamanı, ilk modül yayınlandığında, ikinci bir modül farklı bir gelenek oluşturmadan önce kiracıya özel depolama geleneğini zorunlu bir gereksinim olarak belirlemektir. Her yeni /api/data/* uç noktası yalnızca genel kod kalitesine karşı değil, özellikle bu geleneğe karşı gözden geçirilmelidir; çünkü bu, "testte çalıştı" ile "gerçek kiracılarla üretimde güvenli" ifadelerinin gerçekten farklı iddialar olduğu tek hata kategorisidir.
Kendi çalışma alanınızda çalışırken görün
Bir TotalApp kiracısı oluşturun ve bu yazıda bahsedilen modülleri bağlayın — her departman için ayrı kurulum gerekmez.