Multi-Tenant Mimari Güvenliği ve İzolasyon Rehberi
Multi-tenant mimari güvenliği uygulamaları, bulut bilişim hizmetlerinde farklı müşterilerin verilerini ve iş yüklerini birbirinden yalıtır. Çok kiracılı yapılar donanım, ağ ve veritabanı kaynaklarını ortak bir havuzda birleştirir. Bu tasarım modeli SaaS sağlayıcılarına eşsiz bir maliyet ve ölçeklenebilirlik avantajı kazandırır.
Ancak paylaşımlı kaynak havuzu beraberinde çok büyük siber riskler getirir. Tek bir yazılımsal açık bir firmanın başka bir firmanın finansal kayıtlarına sızmasına yol açabilir. Bu nedenle multi-tenant mimari güvenliği adımları modern bulut mühendisliğinin en kritik savunma hattıdır. Bu teknik rehberde veri izolasyon modellerini, satır düzeyi güvenliği, gürültülü komşu kalkanını ve şifreleme mimarilerini inceliyoruz.
- Multi-tenant mimari güvenliği kiracılar arası yetkisiz veri sıçramalarını engeller.
- PostgreSQL RLS mekanizması veritabanı motoru seviyesinde otomatik filtreleme yapar.
- Redis ve Kafka gibi paylaşımlı katmanlarda kiracı ön ekleri zorunlu tutulmalıdır.
- Her kiracıya özel şifreleme anahtarları (BYOK) kurumsal güveni perçinler.
Çok Kiracılı Sistemlerde Güvenliğin Rolü
Bulut yazılımları binlerce şirketin verisini aynı fiziksel sunucu kümelerinde barındırır. Çünkü paylaşımlı donanım kullanmak SaaS sağlayıcılarına fahiş altyapı tasarrufu sağlar. Fakat bu ekonomik model çok katı güvenlik gereksinimlerini beraberinde getirir. Dolayısıyla multi-tenant mimari güvenliği yatırımları müşteri güveninin ve kurumsal varlığın temel teminatıdır.
Ayrıca bir kiracının gerçekleştirdiği yoğun işlemler diğer müşterilerin hizmet kalitesini düşürmemelidir. Zira kaynakların kontrolsüz paylaşımı sistem genelinde kilitlenmelere zemin hazırlar. İzolasyon eksikliği doğrudan ticari prestij kaybı doğurur. Bu nedenle multi-tenant mimari güvenliği yaklaşımları hem veri gizliliğini hem de operasyonel sürekliliği güvenceye alır.
Hukuki açıdan bakıldığında KVKK, GDPR ve SOC 2 Tip II standartları kiracı verilerinin katı çizgilerle ayrılmasını emreder. Rakip bir şirketin verilerinin başka bir kullanıcı ekranına yansıması milyonlarca liralık tazminat cezaları doğurur. Nitekim şirket yöneticileri bu ağır yasal riskleri bertaraf etmek adına modern izolasyon modellerini benimsemelidir.
Güvenlik mühendisleri koruma kalkanını yalnızca uygulama seviyesinde kurmamalıdır. Çünkü kod tabanında yapılacak ufak bir mantık hatası tüm filtreleri boşa çıkarabilir. Ekipler veritabanından önbelleğe kadar her katmanda bağımsız bariyerler inşa eder. Sonuç olarak multi-tenant mimari güvenliği bütüncül ve tavizsiz bir mimari disiplin gerektirir.
Veri İzolasyonu Modelleri ve Karşılaştırması
Çok kiracılı sistemlerde veri saklama mimarisi üç farklı temel model üzerinden kurgulanır. Çünkü her modelin güvenlik, bakım zorluğu ve maliyet dengesi birbirinden tamamen farklıdır. Mühendislerin kurumsal ihtiyaçlara uygun modeli seçmesi hayati önem taşır.
| İzolasyon Modeli | Mimari Yapı | Güvenlik Derecesi | Altyapı Maliyeti |
|---|---|---|---|
| Ayrık Veritabanı (Database-per-Tenant) | Her kiracıya tamamen bağımsız fiziksel veya mantıksal veritabanı tahsis etme | En Yüksek | Yüksek |
| Ayrık Şema (Schema-per-Tenant) | Aynı veritabanı içinde her kiracı için bağımsız tablo şemaları açma | Yüksek | Orta |
| Paylaşımlı Tablo (Shared Table) | Tüm kiracı verilerini aynı tablolarda `tenant_id` kolonuyla tutma | Orta (Sıkı Kontrol Şart) | En Düşük |
Ayrık Veritabanı vs Paylaşımlı Tablo Mimarisi
Ayrık veritabanı mimarisinde bir kiracının verisine sızmak imkansıza yakındır. Çünkü her şirketin veritabanı bağlantı şifreleri ve depolama alanları birbirinden tamamen bağımsızdır. Bankacılık ve sağlık sektöründe faaliyet gösteren kurumsal müşteriler genellikle bu modeli şart koşar.
Fakat binlerce müşterisi olan kitle pazarı SaaS ürünlerinde ayrık veritabanı yönetmek devasa bir operasyonel yüktür. Bu sebeple çoğu girişim paylaşımlı tablo modelini tercih eder. Ancak paylaşımlı tablolarda yazılımcının bir sorguda filtre unutması tüm veriyi açığa çıkarır. Dolayısıyla multi-tenant mimari güvenliği standartları paylaşımlı yapılarda otomatik veritabanı kalkanlarını zorunlu kılar.
Satır Düzeyi Güvenlik (Row-Level Security)
Paylaşımlı tablo kullanan platformlarda insan hatalarını engellemenin en kesin yolu Satır Düzeyi Güvenlik (RLS) teknolojisidir. Çünkü RLS yetkilendirme mantığını yazılım kodundan alıp doğrudan veritabanı motoruna (PostgreSQL vb.) emanet eder. Veritabanı her sorguda kiracı kimliğini otomatik olarak denetler.
Yazılımcı sorgusunda yanlışlıkla `WHERE tenant_id` filtresini yazmasa dahi veritabanı motoru kuralı arka planda otomatik çalıştırır. Oturum açmış kiracıya ait olmayan hiçbir satır sorgu sonucuna eklenmez. Bu mimari BOLA ve IDOR açıklarını veritabanı seviyesinde kökten yok eder.
Mühendisler RLS kalkanını kurarken aşağıdaki teknik adımları izler:
- Oturum Değişkeni Tanımlama: Uygulama bağlantı açtığı an veritabanı oturumuna `app.current_tenant_id` değerini set etmek.
- Katı Güvenlik Politikaları (Policies): Tablolara `USING (tenant_id = current_setting(‘app.current_tenant_id’))` kuralını tanımlamak.
- Varsayılan Engelleme: RLS aktif edilen tablolarda kural dışı tüm okuma ve yazma işlemlerini varsayılan olarak reddetmek.
- Yönetici Muafiyetlerini Kapatma: Web uygulamasının bağlandığı veritabanı kullanıcısına `BYPASSRLS` yetkisi vermemek.
Veritabanı motorunun sağladığı bu koruma yazılım hatalarını tamamen tolere eder. Nitekim saldırgan kod açıklarını manipüle etse bile veritabanı sınırlarını aşamaz. Böylece multi-tenant mimari güvenliği kurgusu en alt katmandan itibaren zırhla kaplanır.
Bellek, Önbellek ve Mesaj Kuyruğu Ayrımı
Kiracı izolasyonu yalnızca veritabanı seviyesinde bırakıldığında büyük bir yanılsama doğar. Zira modern SaaS yazılımları yüksek hız için Redis gibi önbellekleri ve Kafka gibi mesaj kuyruklarını yoğun şekilde kullanır. Bu paylaşımlı katmanlardaki dikkatsizlikler tehlikeli veri kaçakları yaratır.
Örneğin bir kullanıcının profil verisi Redis önbelleğine yalnızca `user:104` anahtarıyla kaydedilirse komşu kiracı aynı anahtarla o veriyi okuyabilir. Benzer şekilde mesaj kuyruklarında kiracı ayrımı yapılmadığında arka plan işleri yanlış müşterinin sunucusunda çalışabilir.
Ekipler paylaşımlı bellek ve kuyruk katmanlarında şu mimari izolasyonları uygular:
- Ad Alanı ve Ön Ek Standartları: Önbellekteki her anahtarın başına mutlaka kiracı kimliği eklemek (`tenant_84:user_104`).
- Mantıksal Veritabanı Ayrımı: Redis üzerinde farklı müşterilere farklı veritabanı indeksleri veya ACL kullanıcıları atamak.
- İzole Kuyruk Başlıkları: Mesaj kuyruklarına atılan her paketin meta verisine kriptografik kiracı imzası iliştirmek.
- Tüketici Filtrelemesi: Arka plan işçilerinin (workers) gelen işi işlemeden önce kiracı bağlamını doğrulaması.
Önbellek temizleme (flush) operasyonları da kiracı bazında sınırlandırılmalıdır. Çünkü bir müşterinin önbelleğini temizlerken tüm sistemin önbelleğini sıfırlamak sunucu yükünü fahiş şekilde artırır. Dolayısıyla multi-tenant mimari güvenliği önbellek ve kuyruk seviyesinde kusursuz işletilmelidir.
Gürültülü Komşu ve Kaynak Tükenmesi Savunması
Çok kiracılı sistemlerde en sık karşılaşılan operasyonel krizlerden biri Gürültülü Komşu (Noisy Neighbor) problemidir. Bu problem bir kiracının aşırı kaynak tüketerek aynı sunucuyu paylaşan diğer kiracıların servislerini yavaşlatması veya çökertmesidir.
Kötü niyetli bir aktör devasa raporlama sorguları çalıştırarak işlemci ve bellek kaynaklarını bilinçli olarak tüketebilir. Bu durum paylaşımlı mimaride bir tür hizmet dışı bırakma (DoS) etkisi yaratır. Ekipler adil kaynak dağılımını teminat altına almak için savunma kalkanları kurar.
Sistem yöneticileri kaynak tükenmesini önlemek adına aşağıdaki kontrolleri devreye sokar:
- Kiracı Bazlı Hız Sınırlama (Rate Limiting): Her müşterinin API çağrı limitlerini abonelik paketine göre dinamik olarak sınırlandırmak.
- Sorgu Zaman Aşımı Sınırları: Veritabanında belirli bir saniyeyi (örneğin 5 saniye) aşan ağır sorguları otomatik olarak sonlandırmak.
- Konteyner ve Pod Kotaları: Kubernetes ortamında kiracı iş yüklerine işlemci ve bellek tüketim tavanları koymak.
- Dinamik Kuyruk Önceliklendirmesi: Yoğun veri işleyen kiracıların görevlerini arka planda düşük öncelikli kuyruklara yönlendirmek.
Adil kaynak kotaları hiçbir kiracının diğerini rehin almasına izin vermez. Zira altyapı her müşteriye kararlı ve tahmin edilebilir bir hız sunmalıdır. Sonuç olarak multi-tenant mimari güvenliği hizmet sürekliliğini de doğrudan koruma altına alır.
Kiracı Bazlı Şifreleme ve Anahtar Yönetimi
Geleneksel bulut mimarilerinde tüm veritabanı tek bir anahtar ile disk seviyesinde şifrelenir. Fakat kurumsal müşteriler kendi verilerinin komşu verilerden bağımsız şifrelenmesini talep eder. Hatta regülasyona tabi kurumlar kendi anahtarını getirme (BYOK – Bring Your Own Key) modelini zorunlu kılar.
Kiracı bazlı şifreleme mimarisinde her müşterinin verisi tamamen farklı bir veri şifreleme anahtarı (DEK) ile kriptolanır. Bu anahtarlar ise bulut sağlayıcısının Anahtar Yönetim Servisi (KMS) üzerinde saklanan ana anahtarlar (KEK) ile korunur. Müşteri aboneliğini iptal ettiğinde anahtarını sildiği an verileri anında okunamaz hale gelir.
Kriptografik ayrım sayesinde veritabanı yedeği çalınsa dahi saldırganlar anahtarlar olmadan hiçbir veriyi çözemez. Nitekim bu yaklaşım kriptografik kiracı izolasyonu sağlar. Böylece multi-tenant mimari güvenliği standartları en üst düzey kurumsal güvenceye kavuşur.
Mikroservisler ve Ağ Düzeyinde İzolasyon
Modern SaaS uygulamaları mikroservis ve konteyner kümeleri üzerinde çalışır. Ancak aynı Kubernetes kümesinde koşan farklı kiracı podları doğru konfigüre edilmezse birbirlerinin ağ trafiğini dinleyebilir. Ağ izolasyonu mikroservis güvenliğinin vazgeçilmez parçasıdır.
Mühendisler konteyner dünyasında izolasyonu pekiştirmek için şu katı adımları atar:
| İzolasyon Katmanı | Kullanılan Teknoloji | Sağlanan Güvenlik Faydası |
|---|---|---|
| Ağ Politikaları (Network Policies) | Calico veya Cilium | Podlar arası yetkisiz ağ iletişimini katman 3/4 seviyesinde tamamen engelleme. |
| Hizmet Ağı (Service Mesh) | Istio veya Linkerd | Servisler arası trafiği mTLS ile şifreleme ve kiracı bağlamını doğrulama. |
| Konteyner İzolasyonu | gVisor veya Kata Containers | Konteynerlerin ortak işletim sistemi çekirdeğini istismar etmesini önleme. |
| Düğüm (Node) Ayrımı | Kubernetes Taints ve Tolerations | Kritik kurumsal müşterilerin podlarını bağımsız sanal sunucularda koşturma. |
Ağ düzeyinde örülen duvarlar olası bir konteyner kaçışı (container breakout) saldırısını sınırda hapseder. Saldırgan bir podu ele geçirse bile diğer müşterilerin servislerine erişemez. Dolayısıyla multi-tenant mimari güvenliği altyapının en derin katmanlarında da kesintisiz korunur.
Kurumsal bulut savunmalarını pekiştirmek isteyen yazılım üreticileri, Sibertim bulut siber güvenlik çözümleri ile mikroservis ve konteyner ağlarını uluslararası standartlara kavuşturur.
Kurumsal Multi-Tenancy Yol Haritası
Çok kiracılı bir bulut platformunu güvenceye almak süreklilik gerektiren teknik bir süreçtir. Yazılıma eklenen her yeni özellik ve her yeni API uç noktası izolasyon risklerini yeniden tetikleyebilir. Şirketler sıfır hata prensibiyle şu yol haritasını tavizsiz hayata geçirmelidir:
- Otomatik İzolasyon Birim Testleri: CI/CD boru hattına kiracılar arası yetkisiz erişim denemelerini simüle eden otomatik testler eklemek.
- Periyodik Çok Kiracılı Sızma Testleri: Bağımsız etik hacker ekiplerine kiracılar arası veri sızdırma senaryolarını test ettirmek.
- Detaylı Kiracı Denetim Günlükleri: Her veri erişimini ve yetkisiz sorgu girişimini kiracı kimliğiyle etiketleyerek SIEM sisteminde toplamak.
- Dinamik Kaynak Kota İzleme: Anormal CPU, RAM veya API trafiği üreten kiracıları gerçek zamanlı tespit eden telemetri araçları kurmak.
- Geliştirici Farkındalık Programları: Yazılım mühendislerine BOLA, IDOR ve güvenli multi-tenancy kodlama eğitimleri vermek.
Sık Sorulan Sorular
Multi-tenant mimari güvenliği neden klasik web güvenliğinden daha zordur?
Çünkü klasik sistemlerde kullanıcılar aynı şirkete aittir. Çok kiracılı yapılarda ise birbirine tamamen rakip yüzlerce şirket aynı veritabanını ve bellek havuzunu ortaklaşa kullanır.
Paylaşımlı tablolarda kiracı ayrımı sadece kod ile yapılabilir mi?
Hayır, yalnızca koda güvenmek büyük risk taşır. Yazılımcının tek bir filtreyi unutması veri sızıntısına yol açar; bu nedenle veritabanı seviyesinde RLS kalkanı kurulmalıdır.
Gürültülü komşu (Noisy Neighbor) problemi bir siber güvenlik riski midir?
Evet, bilinçli veya bilinçsiz olarak aşırı kaynak tüketen bir kiracı diğer müşterilerin sistemini kilitleyerek fiili bir hizmet dışı bırakma (DoS) durumu yaratır.
BYOK (Kendi Anahtarını Getir) modeli kurumlara ne kazandırır?
Müşteri kendi şifreleme anahtarını yönetir. Müşteri bulut firmasından ayrılmak istediğinde anahtarını sildiği an veritabanındaki kayıtları anında tamamen okunamaz hale gelir.
Redis gibi önbellek sistemlerinde kiracı izolasyonu nasıl sağlanır?
Tüm önbellek anahtarlarına kiracı kimliği ön ek olarak tanımlanmalı ya da her müşteriye bağımsız ACL izinlerine sahip mantıksal veritabanları atanmalıdır.