RAG prompt injection için beş katmanlı savunma

RAG sisteminde belgeye gömülü talimatları sınırlamak için OWASP’nin RAG kontrollerini beş uygulama katmanına yerleştirin: belge kökeni ve karantina, metin taraması, parça düzeyinde erişim, çıktı denetimi ve CI saldırı testleri. Her katmanı, belgenin depodan yanıt veya araç çağrısına ilerlediği ayrı bir karar noktasına bağlayın.

Paylaşılan depodaki bir belge arama sonucuna girip modele taşındığında içindeki talimat da bağlama ulaşabilir. Katmanlı RAG savunması araştırması, yalnızca kullanıcı girdisini inceleyen filtrenin getirilen belgeleri göremediğini, yalnızca çıktı denetiminin ise zararlı içeriğin modele ulaşmasını önleyemediğini açıklıyor. Belgenin aramada bulunması, içindeki ifadelerin uygulama için komut sayılması anlamına gelmemeli.

1. Belgeyi dizine almadan önce kökenini doğrulayın

Paylaşılan depodan gelen yeni veya değişmiş dosyayı önce bekleme alanına alın; kaynağı ve onay durumu belli olmadan parçalara ayırıp vektör dizinine yazmayın. Alım kaydında belge kimliği, kaynak bağlayıcı, yükleyen kişi veya servis, kaynak sürümü, onaylayan taraf ve içerik özetini tutun. Böylece şüpheli bir sürüm bulunduğunda hangi parçaların ondan üretildiği izlenebilir.

İzin verilen kaynaklar listesinin dışındaki belgeyi reddedin; onaylı kaynaktan gelen değişikliği tarama bitene kadar aramaya kapatın. Onaylı sürümün özetini, belgeyi yazabilen hesabın değiştiremediği imzalı ayrı bir kayıtla karşılaştırın. Eşleşme yalnızca dosyanın onaylı sürümle aynı olduğunu gösterir; o sürümün güvenli olduğunu kanıtlamaz. Yeni sürümü onaylama yetkisini depoya yükleme yetkisinden ayırın; doğrulama başarısızsa parçaları erişime açmayın.

2. Çıkarılan metni tarayın ve bağlam sınırını koruyun

Tarama dosya adına veya uzantısına değil, ayrıştırıcıdan çıkan metne uygulanmalı. Rol taklidi yapan komutları, önceki talimatları yok sayma ifadelerini, görünmez Unicode karakterlerini ve sıfır genişlikli boşlukları işaretleyin. Şüpheli içeriği incelemeye ayırın; tarama servisi çalışmıyorsa dosyayı sessizce dizine eklemeyin. Kararı belge kimliği, sürüm ve tarama kuralıyla kaydedin; böylece yeni bir kural çıktığında etkilenmiş belgeler yeniden taranabilir.

Alım taramasını geçen parçaları, modele eklemeden önce yeniden değerlendirin: ayrı ayrı masum görünen parçalar bir araya geldiğinde talimat oluşturabilir. Modele verilen her parçayı belirgin ayraçlarla çevreleyin, getirilen içeriğin kaynak veri olduğunu belirtin ve toplam parça boyutunu sınırlayın. Uzun içerik, güvenilir talimatların modelin dikkatinde geri plana düşmesine yol açabilir. Ayraçların ve sınırların etkisini kullandığınız model sürümüyle saldırı testinde sınayın; tek başına metinsel uyarıyı güvenlik kararı saymayın.

3. Yetkiyi aramadan önce her belge parçasına uygulayın

Belgeyi parçalamak erişim kurallarını parçalamamalı. Her vektör parçası belge kimliğiyle birlikte tenant kimliği, sınıflandırma, izin verilen roller ve kaynak izin sürümünü taşımalı. Sorgu anında kullanıcının güncel yetkisini doğrulayın; tenant ve sınıflandırma sınırını benzerlik aramasından önce arama kapsamına uygulayın. Sonuçları yalnızca aramadan sonra ayıklamak, yetkisiz parçaların arama sürecine katılmasını engellemez.

Yapılandırma taslağında arama kapsamını tenant_id ve izinli koleksiyonlarla daraltın; modele gidecek sonuç kümesine yalnızca yetki kontrolünden geçen chunk_id değerlerini alın. Yetki servisi yanıt vermiyorsa sonuç döndürmeyin. Kaynak belgenin izni kaldırıldığında veya belge silindiğinde ilgili parçaları, türetilmiş dizin kayıtlarını ve o belgeye bağlı önbellek yanıtlarını temizleyin. Önbellek anahtarını kullanıcı, tenant ve yetki kapsamına bağlayın; ortak anahtar farklı erişim haklarına sahip kişilere aynı yanıtı taşıyabilir.

4. Yanıtı ve araç çağrısını ayrı kurallarla doğrulayın

Modelin ürettiği metni kullanıcıya ya da başka bir sisteme göndermeden önce uygulama denetlemeli. Otomatik akış için dar bir çıktı şeması tanımlayın: örneğin answer metin, source_chunk_ids kimlik listesi ve proposed_action izinli eylemlerden biri olsun. Şema bozulursa yanıtı reddedin; kaynak kimliklerinin gerçekten bu istek için yetkilendirilip getirildiğini ayrıca doğrulayın. Geçerli JSON, yanıtın doğru veya güvenli olduğu anlamına gelmez.

Yanıtta sır, kimlik bilgisi veya kullanıcının göremeyeceği veri bulunup bulunmadığını kontrol edin. Asistan araç çağırabiliyorsa eylem adını ve parametrelerini izin listesiyle karşılaştırın; işlemin kullanıcı adına yapılmasına yetki olup olmadığını araç katmanında yeniden sorgulayın. Yüksek riskli bir işlem için açık kullanıcı onayı isteyin. Belgedeki “şu adrese gönder” ifadesi, dış sisteme veri aktarma yetkisi vermez.

5. Saldırı örneklerini CI hattına koyun ve kararları izleyin

Dağıtım öncesi test yalnızca modelin kötü niyetli cümleye nasıl cevap verdiğini ölçmemeli; zararlı parçanın hangi aşamadan geçtiğini de göstermeli. Sentetik bir test deposunda zehirli belge, başka tenant’a ait parça, izni geri alınmış belge ve başka kullanıcıya ait önbellek yanıtı bulundurun. Böylece gerçek müşteri verisini kullanmadan alma, arama, yanıt ve araç sınırları sınanır.

Zehirli belge taramayı geçerse veya karantinadaki parça arama sonucuna girerse dağıtımı durdurun.
Başka tenant’ın ya da yetkisi kaldırılmış belgenin parçası sonuçta görünürse erişim testini başarısız sayın.
Getirilen belgedeki talimat izin dışı araç çağrısına dönüşürse veya çıktı denetimi bunu geçirirse dağıtımı durdurun.
Kaynak silindikten sonra parça ya da ona bağlı önbellek yanıtı dönerse silme akışını başarısız sayın.

Her istek için ilişkilendirme kimliği, getirilen belge ve parça kimlikleri, yetki ve tarama kararları, model sürümü ile araç çağrısı sonucunu kaydedin. Ham sorguları, belge metnini ve yanıtları varsayılan olarak günlüklemeyin; hassas veri içerebilirler. Bir belge sonradan şüpheli bulunursa kayıtlarla etkilenen parçaları ve yanıtları saptayın, belgeyi aramadan çıkarın ve ilgili önbelleği geçersiz kılın.

Ayrıca okuyun: