RAG Sistemlerinde Yetkilendirme ve Tenant İzolasyonu Testi

Kısa cevap

RAG erişim kontrolü, prompt’a “yalnızca izinli belgeleri kullan” yazmakla sağlanmaz. Kullanıcının belge yetkisi retrieval öncesinde güvenilir backend katmanında uygulanmalı; cache, reranker, citation, geçmiş ve üretim boyunca korunmalıdır. Başarı ölçütü yetkisiz belgenin modele hiç sunulmaması ve yan kanallardan sızmamasıdır.

RAG, kaynak belgeleri parçalara ayırıp embedding ve indekslere kopyalar. Kaynak ACL ile indeks metadata’sı arasında güncelleme gecikmesi oluşabilir. Tenant veya grup üyeliği hatası, yanıt metni kadar citation, başlık, cache ya da konuşma geçmişinden veri sızdırabilir.

Yetkinin otoritatif kaynağı nedir?

Her belge için ACL’nin hangi sistemden geldiğini belirleyin: kaynak uygulama, senkronize grup üyeliği veya policy servisi. Kullanıcı rolü prompt’tan ya da istemci metadata’sından türetilmemelidir. Tenant bağlamı kimliği doğrulanmış istekte backend tarafından çözülmelidir.

Ingest sırasında tenant ve izin etiketleri indeks metadata’sına kopyalanıyorsa güncelleme garantisini belgeleyin. Retrieval önce tüm tenant’larda arayıp sonra prompt ile ayırmamalıdır; izin filtresi model bağlamı oluşmadan uygulanmalıdır.

ACL yaşam döngüsünü izleyin

Kullanıcının gruptan çıkarılması, belge izninin değişmesi veya tenant’ın askıya alınması indekse ne zaman yansıyor? Kaynak sistem güncelken indeks eski izinle çalışıyorsa yetki penceresi oluşur. Delta update başarısızlığı ve yeniden indeksleme sırasında eski kopyaları test edin.

Belge silme, aramadan kaybolmasından fazlasıdır. İçerik konuşma geçmişi, semantik cache, reranker cache, export veya citation URL’sinde kalabilir. Her depoda erişim kaldırıldığını ve tamamlanma durumunun gözlemlendiğini doğrulayın.

Chunk, cache ve citation

Belge ACL’si kaynakta doğru olsa bile chunk metadata’sı kaybolabilir. Her chunk’ın tenant ve izin etiketini taşıdığını örneklerle doğrulayın; birden çok belge birleştirilince en geniş izin kullanılmamalı, her kaynak ayrı değerlendirilmelidir.

Cache anahtarlarını tenant, kullanıcı veya izin sürümüne göre ayırın. Tenant A bir sorgu yaptıktan sonra Tenant B aynı sorguyu çalıştırıp A’nın cevabını almamalıdır. ACL değişince eski cache’in ne zaman geçersizleştiğini ölçün.

Citation bir veri çıkış yüzeyidir. Cevap metni belgeyi göstermese bile başlık, dosya yolu, müşteri adı ya da snippet sızabilir. Kullanıcı kaynak belgeyi açamıyorsa citation ve retrieval sonucu da belgeyi göstermemelidir.

Test matrisi

Her tenant ve grup için sentetik, benzersiz canary ifadeler hazırlayın. Aynı sorguyu izinli/izinsiz kullanıcılarla; doğrudan retrieval, doğal dil, follow-up, geçmiş, farklı dil ve cache ısınması sonrasında deneyin. Yetkisiz canary’nin modele, cevaba, citation’a veya kullanıcıya açık log çıktısına girmediğini kontrol edin.

Test ortamında rol değişimi, tenant switch, grup kaldırma, ACL değişikliği, kaynak kesintisi, indeks rebuild, cache temizleme ve silmeyi yürütün. Her geçiş için kabul edilebilir tutarlılık süresi ürün gereksiniminde tanımlı olmalıdır.

Mimari kontrol listesi

• Erişim kararını model değil, kimliği doğrulanmış backend verir.
• Tenant/ACL filtresi retrieval’dan önce uygulanır.
• Her chunk kaynak, tenant, izin sürümü ve silme durumunu taşır.
• ACL değişiminde cache geçersizleşir.
• Policy servisi kesintisinde filtresiz fallback yoktur.
• Citation ve konuşma geçmişi aynı erişim politikasına uyar.

Senkronizasyon gecikmesini ölçülebilir hale getirin

İzin değişikliği için sadece “yakında güncellenir” ifadesi yeterli değildir. Kaynak ACL değişiminin event’i, ingestion kuyruğunu, indeks güncellemesini ve cache invalidation’ı hangi sırayla tetiklediğini çıkarın. Her adımda retry ve başarısızlık durumu görünür olmalıdır. Ürün, kaldırılan kullanıcının eski izinle kaç dakika erişebileceğini kabul ediyorsa bu süre açıkça tanımlanmalı; yüksek hassasiyetli belgeler için daha sıkı bir sınır uygulanmalıdır.

Rebuild sırasında yeni indeks hazır olana kadar eski indeksin aktif kalması normal olabilir; ancak eski izinleri taşımaması gerekir. Mavi/yeşil indeks geçişi, ACL snapshot sürümüyle eşleşmeli ve geçiş atomik yapılmalıdır. Eski indeks veya cache üzerinde geri dönüş gerçekleşirse eski ACL’nin de geri gelmediğini kontrol edin.

Test verisini sızıntı izine dönüştürün

Canary metinleri tenant ve grup başına benzersiz seçin; örneğin rastgele oluşturulmuş, gerçek müşteri verisi içermeyen tanımlayıcılar. Her sorgu için modelin gördüğü retrieval chunk ID’lerini, tenant filtrelerini, cache hit/miss bilgisini ve dönen citation kimliklerini güvenli telemetride eşleştirin. Böylece kullanıcı cevabında görünmeyen ancak model bağlamına sızmış bir parçayı da tespit edebilirsiniz.

Rapor; hangi izin değişikliğinin ne zaman yapıldığını, retrieval’ın ne kadar süre eski sonucu verdiğini, cache’in etkisini ve hangi katmanda düzeltme gerektiğini göstermelidir. Sadece son yanıtı ekran görüntüsü almak yetersizdir; modelin tesadüfen hassas kısmı söylememesi, erişim kontrolünün çalıştığını kanıtlamaz.

Sınır durumlarını da kapsayın

İzin filtresinin yalnızca ilk retrieval çağrısında değil, query rewrite, çoklu indeks araması, reranking ve tool/function çağrısı sonrasında da korunduğunu inceleyin. Model bir kaynağa erişemediğinde aynı bilgiyi başka bir bağlı connector üzerinden bulabiliyor mu? Senkronizasyon sırasında kısmi başarısızlık olduğunda yalnızca güncellenmiş tenant’lar mı, yoksa tamamı mı sorgulanabilir kalıyor? Bu sorular sistemin gerçek erişim yüzeyini belirler. İzleme, kullanıcı sorgusunu ve ham belge metnini gereksiz yere toplamadan; karar verilen tenant filtresi, dönen kaynak kimlikleri ve policy sürümüyle sınırlandırılabilir.

Retest, modelin bir prompt’a “paylaşamam” demesinden fazlasını kanıtlamalı: yetkisiz içerik retrieval sonuçlarına girmemelidir. Tenant çaprazlaması, ACL gecikmesi, cache ve silme ayrı ayrı doğrulanmalıdır. RAG’ın retrieval ve backend sınırlarını incelemek için AI güvenlik değerlendirmemize bakabilirsiniz.