Çoklu Kiracı Mimarisi: Arama Uygulamaları Neden Buna İhtiyaç Duyuyor?

Eğer bir BPO (İş Süreçleri Dış Kaynak Kullanımı) şirketi, bir bayi işletmesi veya aynı arama platformunda birden fazla müşteriye hizmet veren herhangi bir işletme yürütüyorsanız, çoklu kiracılık sadece isteğe bağlı bir özellik değil, her şeyin üzerine kurulu olduğu temeldir.

Çoklu Kiracılığın Gerçek Anlamı

Çoklu kiracılık, birden fazla bağımsız istemcinin (kiracının) aynı yazılım altyapısını paylaşırken, verilerinin, yapılandırmalarının ve uyumluluk kurallarının tamamen izole edilmiş olması anlamına gelir. Her kiracı kendi özel sistemine sahipmiş gibi çalışır, ancak temel platform paylaşılır.

Anahtar kelime şudur: isolationAyırma değil. Filtreleme değil. İzolasyon.

İzolasyonun Önemi

Veri koruma. Müşteri A'nın iletişim bilgileri, çağrı kayıtları, temsilci verileri ve kampanya sonuçları Müşteri B için görünmez olmalıdır. Sadece gizli değil, kanıtlanabilir şekilde erişilemez olmalıdır. Bir geliştirici sorguda hata yapsa bile, veritabanı yine de farklı müşteriler arasındaki veri erişimini engellemelidir.

Uyumluluk bağımsızlığı. Müşteri A, TDRA kurallarına (BAE) göre faaliyet gösterebilir. Müşteri B, CITC'ye (Suudi Arabistan) göre. Müşteri C, TCPA'ya (ABD) göre. Her kiracının kendi uyumluluk kurallarına, DNC listelerine, arama saatlerine ve onay takibine ihtiyacı vardır. Bir kiracının uyumluluk ihlali diğerini etkileyemez.

İzolasyonun kaydedilmesi. Çağrı kayıtları, bir çağrı merkezindeki en hassas verilerdir. Her bir müşterinin kayıtları, müşteriye özel erişim kontrolleriyle yalıtılmış depolama yollarında saklanmalıdır. Müşteri A'nın kaydı için imzalanmış bir URL, asla Müşteri B için çalışmamalıdır.

Fatura izolasyonu. Her kiracının kendine ait temsilci sayısı, kullanım ölçütleri ve faturalama döngüsü vardır. Faturalama verileri, her kiracı için doğru olmalı ve çapraz bulaşma olmamalıdır.

Yanlış Yol: Uygulama Düzeyinde Filtreleme

Birçok arama hizmeti sağlayıcısı, basit bir yöntemle "çoklu kullanıcı" özelliğini hayata geçiriyor. tenant_id = ? Uygulama kodlarında bir filtre kullanıyorlar. Her sorgu bu filtreyi ekliyor. Çalışıyor... ta ki biri unutana kadar.

Sorunlar:

• Filtrelerden birinin atlanması = kiracılar arasında veri sızıntısı
• Birleştirme işlemleri içeren karmaşık sorgular kolayca yanlış yapılabilir.
• Toplama sorguları (raporlar, gösterge tabloları) özellikle risklidir.
• Başvuruda hata olduğunda hiçbir güvenlik ağı yok.

Uygulama düzeyinde filtreleme, izolasyon anlamına gelmez. Her geliştiricinin, her sorgunun, her kod yolunda %100 doğru sonuç vermesine bağlı olan, en iyi çabayı gösteren bir filtredir. Bu yeterli değil.

Doğru Yol: Veritabanı Düzeyinde İzolasyon

DialerBee, derinlemesine bir savunma katmanı olarak PostgreSQL Satır Düzeyinde Güvenlik (RLS) kullanır. İşte çalışma şekli:

1. Kiracılara ait her masanın bir tenant_id column
2. RLS politikaları her kiracı tablosunda etkinleştirilmiş ve ZORUNLU olarak uygulanmıştır.
3. Her veritabanı işlemi başlangıcında, şunu ayarlıyoruz: SET LOCAL app.current_tenant_id = :tid
4. Veritabanı, SELECT, INSERT, UPDATE, DELETE gibi her sorguyu filtreleyerek yalnızca geçerli kiracıya ait satırları döndürür.
5. Uygulama kullanıcısının BYPASSRLS izni yok; ham SQL bile filtreyi atlatamıyor.

Bu, uygulama kodunda bir hata olsa bile (eksik bir WHERE koşulu, hatalı bir JOIN, gruplandırma yapılmamış bir toplama işlemi gibi) veritabanının farklı kiracılar arasındaki veri erişimini engellediği anlamına gelir. Uygulamanın filtresi birincil savunma mekanizmasıdır. RLS ise güvenlik ağıdır.

İzolasyon Testi

İzolasyon iddiası yeterli değil. Bunu kanıtlamanız gerekiyor. DialerBee, her API uç noktasında düşmanca kiracı izolasyon testleri yürütür:

1. Kiracı A bir kaynak oluşturuyor (iletişim, kampanya, kayıt vb.).
2. Kiracı B, bu kaynak üzerinde GET, PATCH, DELETE işlemlerini deniyor.
3. Her deneme 404 (bulunamadı) hatası döndürmeli, asla 403 (yasak) hatası döndürmemeli.

Neden 403 yerine 404? Çünkü 403 ("izniniz yok") kaynağın var olduğunu doğrular. 404 ("bulunamadı") ise hiçbir şey ortaya koymaz. Kiracı B'nin kaynağın varlığından bile haberdar olmaması gerekir.

Bu testler, her kod değişikliğinde CI ortamında çalıştırılır. Herhangi bir test başarısız olursa, kod birleştirilmez.

Ortakların Talep Etmesi Gerekenler

Beyaz etiketli veya bayilik kullanımı için bir arama yazılımı değerlendiriyorsanız, şu soruları sorun:

• Kullanıcı izolasyonu veritabanı düzeyinde mi yoksa yalnızca uygulama kodunda mı uygulanıyor?
• Bana düşman saldırılarına karşı izolasyon test paketini gösterebilir misiniz?
• Sorgu yanlışlıkla kiracı filtresini atlarsa ne olur?
• Çağrı kayıtları, kullanıcıya özel yollarda mı saklanıyor?
• Bir kiracının sözleşme ihlali başka bir kiracıyı etkileyebilir mi?
• İş ortağı portalı üzerinden bir kiracı oluşturursam, bu kiracı diğer tüm kiracılardan anında izole edilir mi?

Bu soruların herhangi birine verilen cevap belirsizse, aramaya devam edin. Yanlış uygulanan çoklu kiracılık, hiç çoklu kiracılık olmamasından daha kötüdür; çünkü size yanlış bir güvenlik hissi verir.