Bilgi Bankası
GenelGüvenlik ve yetki 16 dk 14.06.2026

Tenant izolasyonu: çok kiracılı veritabanı mimarisinde risk nasıl küçültülür?

Çok kiracılı sistemlerde asıl soru sadece “veri ayrı mı?” değildir. Ağ yolu, kullanıcı yetkisi, yedek, metrik, destek erişimi ve kaynak tüketimi de tenant sınırını doğru okumalıdır.

Bu yazı sana şu durumda yardımcı olur
  • tenant_id filtresi uygulama kodunda unutulabilir diye endişe ediliyor
  • bir müşterinin yoğunluğu diğerini etkiliyor
  • destek ekibi müşteri verisine nasıl güvenli bakacağını bilmiyor
  • yedek veya loglarda tenant sınırı belirsiz
  • ağ izolasyonu sadece dökümanda kalmış olabilir
Yazıyı bitirince

Tenant izolasyonunu yalnızca tablo kolonuyla değil, ağ, kimlik, kaynak ve operasyon sınırı olarak düşünebileceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB tenant başına namespace, ağ politikası, TLS, izin listesi ve WireGuard gibi izolasyon katmanlarını ürün hikayesinin merkezine alır. Bu yine de uygulama sorgularındaki tenant bağlamını doğru taşımak zorunda olmadığınız anlamına gelmez.

Tenant izolasyonu tek katmanlı bir iş değildir

Sadece her tabloda tenant_id olması izolasyon değildir. Bu iyi bir başlangıçtır; ama sorgu hatası, yanlış yetki, paylaşılan gizli değer, gevşek ağ kuralı veya ortak yedek yolu aynı sınırı zayıflatabilir.

Sağlıklı modelde izolasyon birden fazla katmanda kendini tekrar eder: kimlikte, ağda, veride, yedek yolunda, destek erişiminde ve denetim kaydında.

  • Kimlik: her istek tenant bağlamı taşımalı.
  • Ağ: tenant veritabanı yalnızca izinli kaynaklardan erişilebilir olmalı.
  • Yetki: kullanıcılar tenant ve rol sınırını aşmamalı.
  • Kaynak: noisy neighbor etkisi ölçülmeli ve sınırlandırılmalı.
  • Operasyon: destek ve admin erişimi denetim ile izlenmeli.

Noisy neighbor güvenlik kadar performans problemidir

Bir tenantın yoğun sorguları diğer müşterinin gecikme değerini bozuyorsa izolasyon eksiktir. Bu her zaman veri sızıntısı değildir; ama hizmet kalitesi açısından aynı derecede can sıkıcıdır.

Bu yüzden tenant izolasyonu kapasite planıyla birlikte düşünülmelidir. CPU, disk I/O, connection pool ve yavaş sorgu örnekleri tenant veya cluster bağlamında okunabiliyorsa problem daha hızlı ayrılır.

Ağ sınırı uygulama hatasını telafi eder

Uygulama kodunda hata olabilir, gizli değer yanlış yere kopyalanabilir, eski entegrasyon unutulabilir. Ağ izolasyonu bu hataların etkisini sınırlar. IP izin listesi, private tünel, namespace izolasyonu ve network policy birlikte daha güvenli bir zemin kurar.

Erişim katmanlarını birlikte düşünme

tenant-isolation-checklist.txt
1. Tenant veritabanı public erişime kapalı mı?
2. İzin listesi kuralı kimden ve neden geliyor?
3. Uygulama runtime ayrı gizli değer kullanıyor mu?
4. Destek erişimi süreli ve denetimli mi?
5. Yedek yolu tenant bağlamı taşıyor mu?
6. Metrikler tenant/cluster ayrımıyla okunabiliyor mu?

İzolasyon kanıtı düzenli kontrol ister

İzolasyon bir kere kurulan ve unutulan bir mimari kararı değildir. Yeni servisler, yeni BI araçları, yeni destek süreçleri ve yeni migration işleri tenant sınırını yeniden test eder.

TürkDB’nin burada güçlü tarafı, tenant bağlamını platformun temel kavramlarından biri olarak taşımasıdır. Ama uygulama ekibi de sorgu deseninde, rol ayrımında ve veri yaşam döngüsünde aynı disiplini korumalıdır.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler