SaaS Geliştirme: Çok Kiracılı Mimari ve Veri İzolasyonu

Çok kiracılı sistemde ayrılması gereken şey nedir?

Kiracı, sisteminizi kullanan bağımsız müşteri kuruluşudur. Aynı kuruluşun şubeleri, departmanları ve kullanıcıları olabilir. Bunları aynı kavram gibi ele almak, yetki modelini daha ilk aşamada zorlaştırır. Bir kişinin iki farklı kuruluşta çalışması da mümkündür. Bu nedenle kullanıcı kimliği, aktif kuruluş ve o kuruluştaki yetki birbirinden ayrı düşünülmelidir.

AWS’nin SaaS izolasyon rehberi, paylaşımlı altyapının müşteri kaynakları arasında erişim sınırı gerektirdiğini ve tek bir evrensel izolasyon yaklaşımı olmadığını vurgular. Uygun seçim iş alanına, dağıtım modeline ve kullanılan altyapıya bağlıdır. [1]

Bu yazıdaki örnek, farklı mobilya üreticilerine sunulan varsayımsal bir bayi yönetim ürünüdür. Her üreticinin ürünleri, bayileri, fiyat listesi ve siparişleri vardır. Örnek gerçek bir Ganz müşteri projesi veya ölçülmüş başarı hikâyesi değildir; mimari kararı somutlaştırmak için kullanılır.

İzolasyon modelini müşteri ve operasyon beklentisiyle seçin

Tablo bir güvenlik sıralaması değildir. Ayrı veritabanı, yanlış yetkiyle başka müşterinin bağlantısının seçilmesini kendiliğinden önlemez. Ortak veritabanı da her proje için yanlış değildir. Hangi sınırın hangi mekanizmayla korunduğunu, kimin yönettiğini ve nasıl test edildiğini açıklamak gerekir.

Örneğin tek müşterinin verisini yedekten geri yüklemek önemli bir gereksinimse, ortak veri yapısının seçici geri yükleme yükünü değerlendirin. Her kuruluşa ayrı sürüm dağıtmak isteniyorsa, sürüm çeşitliliğinin destek yükünü hesaba katın. Müşteri başına maliyet ile izolasyon gereksinimini aynı karar kaydında tartışın; yalnızca ilk kurulum kolaylığına bakmayın.

Kiracı bağlamı istemciden gelen bir etikete güvenmemelidir

Varsayımsal sipariş kaydında tenant_id, order_id ve işlemi yapan kullanıcı bulunabilir. İstemcinin gönderdiği kuruluş kimliğini doğrudan doğru kabul etmek yerine, sunucu kimliği doğrulanmış kullanıcının o kuruluşla ilişkisini doğrulamalıdır. Daha sonra istenen nesne ve eylem için yetki değerlendirilmelidir.

OWASP, varsayılan olarak reddetme, en az yetki ve her istekte izin kontrolünü önerir. Ekranda bir butonu gizlemek bu kontrolün yerine geçmez; dosya gibi kaynaklar da erişim kapsamına dahildir. [2]

Önerilen düşünme sırası şöyledir: Bu kullanıcı kim? Hangi kuruluş adına işlem yapıyor? İstenen kayıt o kuruluşa mı ait? Kullanıcının bu kayıtta bu işlemi yapma yetkisi var mı? “Yönetici” etiketi son sorunun cevabıdır; ilk üç soruyu ortadan kaldırmaz. Destek ekibinin müşteri hesabına erişimi de ayrı ve izlenebilir bir yetki olarak tasarlanmalıdır.

Veritabanı dışındaki beş yolu ayrıca inceleyin

Önbellek anahtarının yalnızca ürün kodundan oluştuğunu düşünün. İki üretici de MASA-01 kodunu kullanıyorsa, kapsam içermeyen anahtar yanlış fiyatın gösterilmesine yol açabilir. Önerilen tasarımda önbellek anahtarı kuruluş, ürün ve gerekiyorsa fiyat listesi sürümünü birlikte temsil eder. Bu, örneğin ihtiyaçlarına göre verilmiş bir tasarım önerisidir.

Arama dizini, rapor dışa aktarımı, dosya indirme bağlantısı, bildirim ve kuyruk işleri için de aynı incelemeyi yapın. Arka plan çalışanı tarayıcı oturumuna sahip değildir. İş kaydında güvenilir kuruluş bağlamının nasıl taşındığı ve işlem anında nasıl kontrol edildiği belirlenmelidir. Kullanıcının yetkisi iş kuyruktayken kaldırıldıysa rapor yine gönderilecek mi? Ürün kuralı burada açık olmalıdır.

Abonelik hakkı ile veri yetkisini karıştırmayın

Bir işletmenin gelişmiş rapor paketini satın alması, kullanıcısının bütün şirket verilerini görebileceği anlamına gelmez. Paket özelliğin kullanılabilirliğini, yetki ise kimin hangi veriyle ne yapabileceğini belirler. Bu iki kontrolün ayrı olması, fiyatlandırma değişikliklerinin güvenlik sınırlarını değiştirmesini önlemeye yardımcı olan bir tasarım yaklaşımıdır.

Ödeme bekleyen, askıya alınmış veya iptal edilmiş kuruluş için davranışları ürün kararı olarak yazın. Yeni kayıt engellenecek mi? Eski veriler okunabilecek mi? Veri dışa aktarımı nasıl yapılacak? Ticari durum değiştiğinde veriyi otomatik silmek yerine saklama, çıkış ve yetki gereksinimlerini ayrıca değerlendirin. Hukuki yükümlülükler için projeye özgü uzman incelemesi gerekir; mimari seçim tek başına mevzuat uyumu sağlamaz.

Büyümeyi yalnız toplam kullanıcı sayısıyla ölçmeyin

Bir kiracı diğerlerinden çok daha fazla rapor üretebilir. Önerilen kapasite planında toplam istek sayısının yanında kuruluş başına kuyruk bekleme süresi, işlem yoğunluğu ve kaynak tüketimi görünür olsun. Tek yoğun müşterinin diğerlerinin işlerini geciktirmesi ihtimalini yük senaryosuna ekleyin.

Bu noktada otomatik ölçek büyütme tek seçenek değildir. Uzun raporları kuyruğa almak, kuruluş başına eşzamanlı iş sınırı belirlemek veya büyük işleri küçük parçalara bölmek değerlendirilebilir. Her çözümün müşteri deneyimindeki bedelini yazın. Kullanıcıya “rapor hazırlanıyor” göstermek kabul edilebilir olabilir; sipariş ekranını açıklamasız bekletmek aynı deneyim değildir.

Test ortamından üretime geçerken hangi kanıtlar gerekir?

En az iki sentetik kuruluş ve farklı rollerde kullanıcılar oluşturun. Yalnızca başarılı erişimi değil, kuruluşlar arası geçişin reddini de test edin. Yeni özellik eklendiğinde aynı matrisin çalıştırılmasını teslim sürecine bağlayın. Test adında kullanılan kayıt, beklenen sonuç ve koşul açık olsun.

Bir testin geçmesi bütün erişim yollarının güvenli olduğunu kanıtlamaz. Test kapsamı, veri yolları envanteriyle birlikte tutulmalıdır. Yeni bir rapor veya entegrasyon eklendiğinde envanter güncellenmelidir. Özellikle destek araçları ve yönetim ekranları, müşteri arayüzünden daha geniş erişime sahip olabileceği için ayrı incelenmelidir.

Önerilen teslim paketi veri modeli, kiracı bağlamının taşınma kuralı, yetki matrisi, izolasyon testleri, müşteri çıkış akışı ve işletim ölçümlerini içerir. Bu belgeler belirli bir teknolojiyi zorunlu kılmaz; teknik ekibin hangi sınırları koruduğunu görünür hale getirir.

Her müşteriye ayrı veritabanı açmak şart mı?

Hayır. Gereksinimlere göre seçilen sınırların güvenilir şekilde uygulanması ve test edilmesi gerekir. Ayrı veritabanı belirli operasyonları kolaylaştırırken çoklu sürüm geçişi ve bakım yükü yaratabilir.

İlk sürümde izolasyon testlerini erteleyebilir miyiz?

Birden fazla müşterinin gerçek verisi sisteme girecekse bunu yalnız sonraki sürüm konusu saymayın. İlk kapsam küçük tutulabilir; fakat o kapsamdaki müşteriler arası erişim sınırı baştan tanımlanmalıdır. Az özellikli ama sınırları belli ürün, geniş fakat belirsiz erişim modeliyle karıştırılmamalıdır.