Hızlı cevap

RAG müşteri izolasyonu bir kullanıcının erişemediği belgenin arama sonuçlarına ve model bağlamına taşınmasını önleyen yetki sınırıdır. Güvenli yanıt üretmek için modelden gizli bilgiyi söylememesini istemek yeterli değildir. Belge izinleri getirme aşamasında uygulanmalı; önbellek ve kaynak bağlantıları da aynı sınırı korumalıdır. Yetki kaldırıldığında eski kopyaların ne zaman erişilemez olduğu ölçülmelidir.

Bu yazı genel bir RAG tanıtımı değildir. Kurumsal arama veya birden fazla müşteriye hizmet veren bir asistan için uygulanabilir kabul testlerine odaklanır. Temel kavramlar için RAG ve vektör veritabanı güvenliği rehberini okuyabilirsiniz.

Sorun yalnızca son yanıtta görünmez

Kullanıcıya gösterilen cevap doğru filtrelenmiş olabilir. Ancak yetkisiz belge daha önce model sağlayıcısına veya izleme sistemine gönderilmişse koruma geç kalmıştır. Bu nedenle inceleme dört ayrı çıktıya bakmalıdır: getirilen parçalar; model bağlamı; son cevap; kaynak dosyaya erişim.

Microsoft'un RAG güvenlik açıklaması erişim kontrolünü getirme aşamasında uygulamayı ve getirilen metni güvenilmeyen içerik olarak ele almayı önerir. Bu genel yaklaşım ürün seçiminin ötesinde anlam taşır: metnin ilgili olması okunmasına izin verildiği anlamına gelmez.

Bir belgeden üretilen parça yalnızca metin taşımaz. Belge kimliği ve sürümüyle birlikte sahiplik bağını da korumalıdır. İzin verisi yoksa belgenin herkese açık olduğu varsayılmamalıdır. Kurum gerçekten herkese açık bir koleksiyon kullanıyorsa bu durum ayrı ve açık bir politika olarak tanımlanmalıdır.

Dört kimlikli sentetik test düzeni

İki örnek müşteri oluşturun: A ve B. Her müşteri için standart kullanıcı tanımlayın. Ayrıca A müşterisinin yöneticisini ve yetkisi daha sonra kaldırılacak bir kullanıcıyı hazırlayın. Her role özel belgelerde tahmin edilmesi zor ve gerçek veri içermeyen işaretleyiciler kullanın.

Örneğin A'ya ait bir deneme belgesindeki işaretleyici B'nin yanıtında görünürse açık bir çapraz erişim bulgusu elde edilir. İşaretleyicinin görünmemesi tek başına başarı kanıtı değildir. Getirme kaydı yetkisiz parçanın modele gönderildiğini gösterebilir. Test verisi tasarımı ile gözlem noktaları birlikte hazırlanmalıdır.

Yetki kararını istemcinin gönderdiği müşteri adından üretmeyin. Sunucu tarafından doğrulanan kimlik ile müşteri bağını kullanın. OWASP çok kiracılı sistem güvenliği rehberi müşteri sınırını veritabanı ve önbellek gibi katmanlarda ele alır. RAG testine bu katmanların tamamı dahil edilmelidir.

DSET tarafından önerilen 12 test

Bu tablo bir ürünün bütün güvenliğini puanlayan standart değildir. Sentetik bir değerlendirmede gözlenebilir sonuç üretmek için hazırlanmıştır. Her satırda kullanılan kullanıcı ve belge sürümü saklanmalıdır.

No Deneme Beklenen sonuç Gözlem noktası
1 A kullanıcısı kendi belgesini sorar Yetkili içerik döner Getirme ve cevap
2 B kullanıcısı A belgesini aynı ifadeyle sorar A içeriği getirilmez Getirme kaydı
3 Yetkisiz belgenin tam başlığı sorulur Gizli başlık ve özet sızmaz Cevap ve kaynak listesi
4 İstek içindeki müşteri alanı değiştirilir Sunucu kimliği esas alır Yetkilendirme kaydı
5 Arama önbelleği diğer müşteriyle ısıtılır Önceki müşterinin sonuçları kullanılmaz Önbellek anahtarı ve sonuç
6 Cevap önbelleği başka kullanıcıyla tekrar okunur İzin bağlamı korunur Önbellek politika sürümü
7 İzin alanı eksik belge eklenir Belge karantinaya alınır veya erişim reddedilir İndeksleme sonucu
8 Kullanıcının grup üyeliği kaldırılır Tanımlanan süre içinde erişim kesilir İptal zaman çizelgesi
9 Belge yeni müşteriye veya klasöre taşınır Eski sahiplik yetki sağlamaz İndeks ve kaynak kontrolü
10 Eski cevap içindeki kaynak bağlantısı açılır Güncel izin yeniden değerlendirilir Dosya erişim kaydı
11 Arama altyapısı hata verir Daha geniş yetkili yola sessiz geçiş olmaz Hata ve yedek akış kaydı
12 Yetkisiz metin çıktı filtresinde gizlenir Daha önce bağlama taşındıysa test başarısızdır Model isteği özeti

RAG izolasyon çalışma tablosunu indir. Başarılı yetkili erişim ilk satırda özellikle tutulmuştur. Her şeyi engelleyen bir sistem işlevsel kabul testini geçmez.

Yetki iptalindeki gecikme nasıl ölçülür?

İptal zamanı ile erişimin gerçekten kesildiği zaman farklı olabilir. Kaynak sistemdeki grup değişikliği indeksleyiciye geç ulaşabilir. Kullanıcı oturumunda eski grup bilgisi bulunabilir. Cevap önbelleği eski bir sonucu sunabilir. Bunları tek bir senkronizasyon sorunu olarak ele almak tanıyı zorlaştırır.

Bu rehberde önerilen ölçüm dört kayıt tutar: kaynaktaki iptal zamanı; politika bilgisinin güncellenme zamanı; son başarılı yetkisiz erişim zamanı; ilk tutarlı ret zamanı. Test sıklığı sonucu etkilediği için rapora yazılmalıdır. Otuz saniyede bir test yapıldıysa milisaniyelik doğruluk iddia edilmez.

Kabul süresini kurum belirlemelidir. Örneğin sentetik bir senaryoda sözleşmesel sınır beş dakika olarak seçilebilir. Bu süre evrensel güvenlik standardı değildir. Hassas bir veri sınıfında çok daha kısa bir süre veya her istekte güncel kontrol gerekebilir. İptal politikası eski konuşma kayıtlarına erişimin ne olacağını da açıklamalıdır. Daha önce kullanıcının indirdiği kopyayı geri almak ayrı bir problemdir.

Belge düzeyinde kontrolün uygulanışı ürüne göre değişir. Bazı özellikler önizleme aşamasında olabilir ve kaynak izinleri belirli aralıklarla aktarılabilir. Kullanılan sürümün izin güncelleme davranışı doğrulanmalıdır. Azure AI Search belge erişim modelleri bu ayrımlar için somut bir ürün örneğidir; bütün RAG ürünlerinin aynı davrandığı varsayılmamalıdır.

Kurgusal örnek: önbellekte kalan teklif

Bir asistan A müşterisinin indirim teklifini yanıtlar. Cevap önbelleği yalnızca soru metnine göre anahtar üretir. B müşterisi aynı soruyu sorunca eski yanıt geri gelir. Vektör araması müşteri filtresini doğru uygulasa bile önbellek bu yolu tamamen atlamış olabilir.

Bu örnekte düzeltmenin doğrulanması iki aşamalıdır. Önce önbellek anahtarının yetki bağlamına bağlandığı gösterilir. Ardından aynı kullanıcının izni değiştiğinde eski yanıtı okuyamadığı denenir. Yalnızca müşteri kimliği eklemek rol değişikliğini veya belge iptalini otomatik çözmez. Paylaşılan önbellek kullanılacaksa paylaşımın güvenli olduğunu ispatlayan politika ayrıca gerekir.

Sonuç raporu nasıl okunmalı?

Raporu yalnızca sızıntı sayısıyla değerlendirmeyin. Test edilen kimlik çiftlerini ve veri sınıflarını görün. Getirme kaydı incelenmediyse bu sınırı açıkça yazın. Model isteğinin tamamını saklamak yerine gerekli kanıt alanlarını seçin ve hassas metinleri koruyun.

Her başarısız satırın bir düzeltme sahibi bulunmalıdır. Tekrar testte aynı belge kümesini kullanmak karşılaştırılabilirliği artırır. Yeni bir veri kaynağı eklendiğinde izin aktarımının yeniden değerlendirilmesi gerekir. Bu çalışma bir kez alınan genel güvenli etiketi yerine sürdürülebilir bir kabul prosedürü üretir.

Sık sorulan sorular

Her müşteri için ayrı vektör veritabanı zorunlu mu?

Hayır. Fiziksel ayrım ve mantıksal ayrım farklı tasarım seçenekleridir. Seçim operasyon yükü ve risk gereksinimlerine bağlıdır. Her iki modelde de kimlik aktarımı ve kaynak dosyaya erişim test edilmelidir.

Prompt içine müşteri adı yazmak yeterli mi?

Hayır. Model girdisi yetkilendirme mekanizması değildir. Getirme ve dosya erişimi sunucu tarafındaki politika ile sınırlandırılmalıdır.

Veri sızıntısı yoksa test geçmiş sayılır mı?

Yalnızca görünür yanıt incelendiyse böyle bir sonuç çıkarılamaz. Yetkisiz içeriğin model bağlamına veya loglara taşınıp taşınmadığı da bilinmelidir.

Silinen belge geçmiş cevaplardan da kalkmalı mı?

Bu davranış ürünün saklama ve erişim politikasına göre tanımlanmalıdır. Güncel kaynağı engellemek eski konuşma kopyalarını kendiliğinden silmez.

DSET ile değerlendirme kapsamı

DSET güvenlik değerlendirmesi için veri kaynaklarını ve rol modelini listeleyin. Kaynak izinlerinin nerede tutulduğunu belirtin. Gerçek müşteri belgesi paylaşmadan sentetik test kümesi hazırlanabilir. Bağlı araçlar da kullanılıyorsa MCP kabul testlerini değerlendirmeye ekleyin.

Editoryal not: Senaryo ve ölçüm tablosu bu rehber için hazırlanmıştır. Gerçek müşteri verisi veya ölçülmüş başarı oranı içermez. Kaynak kontrol tarihi 11 Ekim 2026'dır.