RAG Sistemlerinde Tenant İzolasyonu
ve Vektör Veritabanı Güvenliği

Benzerlik Skoru Yetki Kararı Veremez

Embedding modeli içerikleri matematiksel yakınlığa göre sıralar. Tenant, departman, sözleşme veya kullanıcı rolü hakkında doğal bir güvenlik bilgisi taşımaz. Filtre uygulanmadan yapılan global arama, başka tenant’a ait parçayı yüksek benzerlikle döndürebilir.

Yetkilendirme retrieval çağrısından önce hesaplanmalı ve sorgunun değiştiremeyeceği sunucu tarafı filtre olarak uygulanmalıdır. Kullanıcı promptundan gelen tenant_id güvenilir kaynak değildir; kimlik doğrulama katmanındaki claim’den türetilmelidir.

Tenant Kimliğini Belge Yaşam Döngüsü Boyunca Taşıyın

İzolasyon yalnızca query anında eklenen metadata filtresi değildir. Belge sisteme girerken tenant sahibi, kaynak ACL’i, veri sınıfı, revision ve silme politikası kaydedilmelidir. Chunk ve embedding bu kimliği miras almalı; yeniden indekslemede kaybolmamalıdır.

Silme isteği yalnızca kaynak dosyayı değil chunk’ları, embedding’leri, cache’i ve türetilmiş özetleri kapsamalıdır. Aksi halde “silinmiş” içerik retrieval üzerinden yaşamaya devam eder.

Metadata Filter Injection ve Fail-Open Riski

Vektör DB filtresi string birleştirmeyle kuruluyorsa kullanıcı kontrollü alanlar query mantığını değiştirebilir. Typed query builder, izinli alan listesi ve parametreli filtre kullanılmalıdır. Boş veya geçersiz tenant filtresi global aramaya düşmemelidir; fail-closed davranmalıdır.

Uygulama erişim kontrolü ile veritabanı erişim kontrolü iki ayrı katmandır. Mümkünse tenant başına namespace, collection veya row-level policy kullanın. Tek filtre hatasının tüm koleksiyonu açmasını önleyin.

Cache ve Reranker İzolasyonu Bozabilir

Query cache anahtarı yalnızca metin hash’inden oluşuyorsa aynı soruyu soran iki tenant aynı retrieval sonucunu paylaşabilir. Cache key; tenant, rol, model, indeks revision ve politika sürümünü içermelidir. Reranker’a gönderilen adaylar da yetki filtresinden sonra seçilmelidir.

Generation katmanında kaynak parçalarına ait tenant etiketi korunmalı ve loglar buna göre ayrılmalıdır. Model güvenli cevap üretse bile çapraz tenant retrieval olayı güvenlik ihlalidir.

İzolasyonu Loglarda da Koruyun

İzolasyon kanıtı yalnızca final cevapta aranmaz. Ingestion, retrieval, reranking ve generation olayları aynı correlation ID altında tenant kimliği, politika sürümü ve kullanılan belge kimlikleriyle izlenmelidir. Ham belge veya hassas prompt içeriğini loglamak gerekmez; erişim kararını yeniden kurmaya yetecek metadata çoğu olay incelemesi için daha güvenli ve daha kullanışlıdır.

Aday belge ile istek sahibinin tenant kimliği eşleşmiyorsa sonuç modele ulaşmadan alarm üretilmelidir. Trace depolarının da tenant ve rol bazlı erişim kontrolü olmalı; aksi halde uygulamada engellenen veri gözlemlenebilirlik katmanından sızabilir. Bu kayıt zinciri, bir izolasyon hatasında etkilenen sorguları ve belgeleri hızlıca sınırlandırmayı sağlar.

Tenant Sınırı Poisoning’i de Daraltır

Yetkisiz belge yükleme yalnızca veri kalitesi sorunu değildir. Saldırgan kendi tenant’ına zararlı talimat eklediğinde global indeks veya ortak özet katmanı bu içeriği başka kullanıcılara taşıyabilir. Ingestion yetkisi, kaynak türü, dosya imzası ve içerik güvenlik taraması ayrı kontrollerdir.

Belgenin erişim kapsamı ile etkileyebileceği retrieval kapsamı aynı olmalıdır. Ortak bilgi tabanı güncellemeleri daha yüksek onay ve provenance gerektirir.

Çapraz Tenant Sızıntı Regresyonu

• İki tenant için anlamsal olarak çok benzer ama farklı gizli marker içeren belgeler hazırlayın.
• A tenant kimliğiyle B marker’ını hedefleyen normal ve adversarial sorgular çalıştırın.
• Retrieval adayları, reranker girdisi, final context ve model çıktısında B marker’ı olmadığını doğrulayın.
• Boş tenant, geçersiz tenant, silinmiş kullanıcı ve role downgrade senaryolarını test edin.
• Cache açık ve kapalı çalışmaları karşılaştırın.
• Silme sonrası tüm türetilmiş artefaktların erişilemez olduğunu doğrulayın.

Kaynaklar ve Kanıt Sınırı

• OWASP LLM08:2025 Vector and Embedding Weaknesses
• OWASP LLM02:2025 Sensitive Information Disclosure
• NIST AI RMF Generative AI Profile

Bu yazı Enes Deniz tarafından hazırlanmış bağımsız bir teknik değerlendirmedir. Bağlantılı upstream proje veya standart kuruluşu tarafından yayımlanmış ya da onaylanmış bir metin değildir. Merge, test ve kapsam iddiaları yukarıdaki birincil kayıtlara bağlanmıştır.