SaaS Projelerinde Multi-Tenant (Çoklu Kiracı) Veritabanı Mimarisi Neden Şarttır?

Bir "Software as a Service" (SaaS) projesi kodladınız ve örneğin Türkiye'deki 50 farklı kliniğe bulut hizmeti veriyorsunuz. Sahnede tek bir yazılım kopyası çalışır ancak her klinik kendi müşterilerini, kendi faturalarını görür. Başka kliniğin verisine ulaşılamaz. İşin bu en kritik güvenlik izolasyonuna Multi-Tenant (Çoklu Kiracı) Mimarisi denir.

Yanlış Kurgu: Ortak Havuz Riski

Piyasada ucuz bütçeyle yazılan SaaS ürünlerinin çoğu tek bir veritabanı tablosu ile çalışır (Tenant_ID sütunu ile ayırarak). Yani sizin firmanızın bilançosu ile ezeli rakibinizin bilançosu aynı tabloda, alt alta hücrelerde durmaktadır. Yazılımcının atladığı küçücük bir WHERE clause (Şart filtresi) veya SQL Injection hatasında, müşteriniz panelinde yanlışlıkla başka şirketin verilerini görebilir. Sonuç: Devasa tazminat davaları ve sönen bir girişim.

Doğru Kurgu: Row-Level Security ve Şema Ayrımı

AZC Software kurumsal mühendislik ilkelerinde, B2B SaaS projeleri verilerin izolasyon riskini sıfırlayan katı mimarilerle (Tenant Izolation) yazılır:

• Logical Separation (Mantıksal İzolasyon): Tek PostgreSQL veritabanında çalışılır ancak her şirket için ayrı bir Schema (Şema) verilir. Şirketler arası köprü kasten kilitlidir.
• RLS (Row Level Security): Veritabanı tabanındaki en katı güvenlik polisidir. Sunucu, kendi Token'ına (Kurum İmzası) sahip olmayan hiçbir sorguya ilgili şirketin verisini çekme hakkı vermez, yazılımcı açık bıraksa bile SQL motoru bu işlemi engeller.

B2B müşterilerinize "Milyonluk verileriniz rakibinizin asla göremeyeceği şekilde askeri şifrelemeyle ve izole tenant ile korunuyor" diyebilmek pazar satış gücünüzü direkt olarak artırır.