Bulut tabanlı bir acente yazılımında yüzlerce farklı acente aynı uygulamayı kullanır. Her acentenin müşteri listesi, teklif geçmişi, poliçe portföyü ve tahsilat kayıtları vardır. Bu veriler aynı altyapı üzerinde dururken, bir acentenin kullanıcısının başka bir acentenin tek bir kaydını bile görememesi gerekir. Çok kiracılı (multi-tenant) mimari, kaynakları paylaşmanın verimliliğini veri izolasyonunun güvenliğiyle birleştirme sanatıdır. Bu yazıda acente verilerini izole etmenin farklı modellerini, avantaj ve risklerini ele alıyoruz.
Kiracı kavramı
Çok kiracılı mimaride kiracı, verileri birbirinden ayrılması gereken bağımsız bir müşteri birimidir. Acente yazılımında kiracı genellikle acentenin kendisidir. Bir acentenin altında birden fazla şube, alt kullanıcı ve rol bulunabilir; ancak bunlar kiracının içindeki yetki ayrımlarıdır. Kiracılar arası izolasyon ile kiracı içi yetkilendirme farklı katmanlarda ele alınmalıdır. İlki mutlak bir sınırdır; ikincisi acentenin kendi kurallarına göre ayarlanabilir.
Üç temel izolasyon modeli
Paylaşılan veritabanı, paylaşılan şema
Bütün kiracıların verileri aynı tablolarda tutulur ve her satırda bir kiracı kimliği bulunur. Her sorgu, kiracı kimliğine göre filtrelenir. Kaynak kullanımı en verimli modeldir; yeni bir acente eklemek yalnızca yeni bir kayıt oluşturmaktır. Şema değişiklikleri tek seferde herkese uygulanır. Buna karşılık izolasyon tamamen uygulama koduna dayanır. Tek bir sorguda kiracı filtresinin unutulması, veri sızıntısına yol açabilir. Bu nedenle bu model, katı mühendislik disiplini ve ek güvenlik katmanları gerektirir.
Paylaşılan veritabanı, kiracı başına şema
Her acente aynı veritabanı sunucusunda kendi şemasına sahiptir. Tablolar her şemada aynı yapıdadır ama veriler fiziksel olarak ayrı tablolarda durur. İzolasyon daha güçlüdür ve tek bir acentenin verisini yedeklemek veya taşımak kolaylaşır. Dezavantajı, şema değişikliklerinin her kiracı için ayrı ayrı uygulanması ve kiracı sayısı arttıkça yönetim yükünün büyümesidir.
Kiracı başına ayrı veritabanı
Her acentenin tamamen ayrı bir veritabanı vardır. En güçlü izolasyonu sunar ve kiracıya özel yedekleme, performans ayarı veya veri konumu gereksinimlerini karşılamayı kolaylaştırır. Ancak altyapı maliyeti ve operasyon karmaşıklığı en yüksek modeldir. Çok sayıda küçük kiracısı olan platformlar için genellikle pratik değildir.
Karma yaklaşım
Pratikte birçok platform tek bir modele bağlı kalmaz. Küçük ve orta ölçekli acenteler paylaşılan şemada çalışırken, özel gereksinimleri olan büyük yapılar ayrı veritabanına taşınabilir. Bu esnekliğin mümkün olması için uygulama kodunun kiracı verisine erişimi, hangi modelin kullanıldığını soyutlayan bir katman üzerinden yapmalıdır. Uygulamanın geri kalanı, verinin fiziksel olarak nerede durduğunu bilmek zorunda kalmamalıdır.
Paylaşılan şemada izolasyonu güçlendirmek
En yaygın model olan paylaşılan şema için ek güvence katmanları kritik önem taşır:
- Merkezi kiracı bağlamı: Kiracı kimliği her istekte kimlik doğrulama bilgisinden türetilir ve istek boyunca merkezi bir bağlamda tutulur. İstemcinin gönderdiği bir parametreye asla güvenilmez.
- Otomatik filtre: Veri erişim katmanı, kiracı filtresini her sorguya otomatik olarak ekler. Geliştiricinin filtreyi elle yazması gerekmez; filtre olmadan sorgu çalıştırmak bilinçli ve denetlenen bir istisna olur.
- Veritabanı düzeyinde satır güvenliği: Destekleyen veritabanlarında satır düzeyinde güvenlik politikaları, uygulama katmanındaki bir hataya karşı ikinci bir savunma hattı oluşturur.
- Benzersizlik kısıtlarında kiracı: Poliçe numarası veya müşteri kodu gibi alanlardaki benzersizlik kısıtları kiracı kimliğiyle birlikte tanımlanmalıdır. Aksi halde bir acentenin girdiği değer, başka bir acentenin kaydıyla çakışarak dolaylı bilgi sızdırabilir.
- Otomatik testler: Her yeni uç nokta için, başka bir kiracının kaydına erişmeye çalışan ve reddedilmesi beklenen testler yazılmalıdır.
Veritabanı dışındaki izolasyon noktaları
Veri izolasyonu yalnızca ana veritabanıyla sınırlı değildir. Sıklıkla gözden kaçan alanlar şunlardır:
- Dosya depolama: Poliçe belgeleri ve ruhsat görselleri gibi dosyalar kiracıya göre ayrılmış yollarda tutulmalı ve erişim bağlantıları kısa ömürlü olmalıdır.
- Önbellek: Önbellek anahtarlarına kiracı kimliği eklenmezse bir acentenin verisi başka bir acenteye sunulabilir.
- Arama indeksleri: Tam metin arama altyapılarında da kiracı filtresi zorunlu olmalıdır.
- Kuyruk mesajları ve loglar: Arka plan işleri, işledikleri mesajın kiracı bağlamını doğru şekilde yüklemelidir.
- Sigorta şirketi kimlik bilgileri: Her acentenin şirket portallarına erişim bilgileri kendi kiracı kapsamında, şifrelenmiş olarak saklanmalı ve yalnızca o acentenin sorgularında kullanılmalıdır.
Gürültülü komşu sorunu
İzolasyon yalnızca güvenlikle değil performansla da ilgilidir. Paylaşılan altyapıda bir acentenin ağır bir rapor sorgusu veya toplu işlemi diğer acentelerin deneyimini olumsuz etkileyebilir. Bu duruma gürültülü komşu sorunu denir. Kiracı bazlı hız sınırları, ağır işlerin ayrı kuyruklara yönlendirilmesi ve raporlama sorgularının okuma kopyalarına taşınması bu etkiyi azaltır.
Kiracı yaşam döngüsü
Bir acentenin platforma katılmasından ayrılmasına kadar geçen süreç de izolasyon açısından planlanmalıdır. Yeni kiracı oluşturulurken varsayılan ayarlar, roller ve modül yetkileri otomatik tanımlanmalıdır. Kiracı ayrıldığında verilerinin dışa aktarılabilmesi ve sözleşmede belirtilen süre sonunda güvenli biçimde silinebilmesi gerekir. Paylaşılan şemada bu silme işlemi, tüm tablolarda ilgili kiracıya ait satırların eksiksiz bulunmasını gerektirir; bu da kiracı kimliğinin istisnasız her tabloda yer almasının bir başka gerekçesidir.
Destek erişimi ve denetim
Platform ekibinin destek amacıyla bir acentenin verisine erişmesi gerekebilir. Bu erişim, izolasyon ilkesinin en hassas istisnasıdır. Destek erişimi varsayılan olarak kapalı olmalı, gerektiğinde süreli ve kapsamı sınırlı biçimde açılmalı ve yapılan her işlem denetim kaydına yazılmalıdır. Mümkünse acente yöneticisinin bu erişimi onaylaması veya en azından bilgilendirilmesi sağlanmalıdır. Böylece izolasyon yalnızca kiracılar arasında değil, platform sağlayıcısı ile kiracı arasında da şeffaf biçimde korunur.
InsureHub'ın bakışı
InsureHub, sigorta acentelerine yazılım sağlayan bir SaaS platformu olarak her acenteyi ayrı bir kiracı olarak ele alır; modül yetkileri, abonelik bilgileri ve şirket bağlantı ayarları acente bazında yönetilir. Sigorta acentesi yazılımı içindeki şube ve alt kullanıcı yapısı kiracı içi yetkilendirmeyle, kiracılar arası ayrım ise platform düzeyindeki izolasyonla sağlanır. Bu yapının Acente CRM ekranlarında nasıl karşılık bulduğunu kendi verilerinize benzer senaryolarla değerlendirebilirsiniz.