Kurumsal RAG'de Yetki Duyarlı Arama

İstek yapan kullanıcının okuyamadığı pasaj modele hiç ulaşmamalıdır. Bunu nerede uygulayacağınızı, dizine ne yazacağınızı ve nasıl test edeceğinizi anlatıyoruz.

Yetki duyarlı arama nedir, neden gerekir?

Kurumsal bir RAG sistemi; ortak sürücüdeki dosyaları, destek kayıtlarını, wiki sayfalarını ve sözleşme arşivini tek bir arama dizininde birleştirir. Kaynak sistemlerde her belgenin kimin okuyabileceğini söyleyen bir erişim listesi (ACL) vardır. Bu liste içe alma sırasında kaybolursa dizin, herkesin her şeyi görebildiği tek bir havuza dönüşür. Kullanıcı yalnızca kendi yetkisindeki bir soruyu sorsa bile arama, anlamca en yakın pasajı getirir; o pasaj da yöneticilere özel bir ücret tablosu olabilir.

Yetki duyarlı arama, aramanın yalnızca soruyu soran kişinin kaynak sistemde okuyabildiği pasajları döndürmesidir. Risk yalnızca yanıtın atıf göstermesi değildir: model gizli pasajı bağlamında gördüğü anda içeriği özetleyebilir, başka kelimelerle aktarabilir ya da bir sonraki araç çağrısında kullanabilir. OWASP'ın 2025 yılı büyük dil modeli risk listesi bu durumu ayrı bir başlık olarak ele alır: vektör ve embedding zayıflıkları arasında, bir grubun belgelerinin başka bir grubun sorgusuyla getirilmesi ve kiracılar arası bağlam sızıntısı sayılır. Aynı kaynak, embedding vektörlerinden kaynak metnin önemli bir kısmının geri elde edilebileceğini de hatırlatır; yani vektör deposu da en az belge deposu kadar korunmalıdır.

Yetki nerede uygulanmalı?

Yetkiyi uygulayabileceğiniz dört yer vardır ve hepsi aynı güvenceyi vermez. En sık yapılan hata, yetki kontrolünü en sona, modele verilen talimata bırakmaktır.

Yöntem	Ne zaman uygun?	Dikkat edilecek nokta
Arama sırasında güvenlik filtresi	Çoğu kurumsal RAG için varsayılan seçim	Her pasajda güncel izin alanı gerekir
Kiracı veya gruba göre ayrı dizin	Az sayıda, kesin sınırlı müşteri ya da birim	Grup sayısı arttıkça maliyet ve bakım yükü büyür
Sonuçları kaynak sisteme sorarak eleme	Yetkinin çok sık değiştiği, gecikmenin kabul edildiği durumlar	Ek gecikme, API sınırları; tek başına değil filtreyle birlikte
Arama sonrası, model öncesi eleme	Filtre kurulana kadar geçici önlem	Elenen sonuçlar yüzünden yanıt kalitesi düşer
Modele "gizli bilgiyi kullanma" talimatı	Hiçbir zaman tek başına	Model gizli metni zaten görmüştür

Önerdiğimiz yol, yetkiyi sıralamadan ve üretimden önce, aramanın kendisinde filtre olarak uygulamaktır. Microsoft bunu Azure AI Search için güvenlik filtresi deseni olarak anlatır: her belgede izinli grup kimliklerini tutan bir alan bulunur, sorgu bu alana kullanıcının gruplarıyla filtre ekler. Elasticsearch'te aynı iş, rol tanımına yazılan bir sorguyla yapılan belge düzeyi güvenlikle çözülür; rol sorgusu oturum açmış kullanıcının bilgisine şablonla başvurabilir.

Dizine hangi yetki bilgisi yazılmalı?

Filtrenin doğru çalışması için her pasajla birlikte en az şu alanları saklayın:

Kaynak belge kimliği: Pasajın hangi belgeden ve hangi sürümden geldiği.
Kiracı: Çok müşterili bir üründe pasajın ait olduğu müşteri; her sorguda zorunlu filtre.
İzinli kullanıcı ve gruplar: E-posta adresi gibi değişebilen bilgiler yerine kalıcı kimlikler. Azure AI Search'ün belge düzeyi erişim özelliği de kullanıcı ve grup alanları için Microsoft Entra nesne kimliklerini ister.
Yetkinin kaynağı: İzin klasörden mi miras geldi, belgeye özel mi verildi, paylaşım bağlantısıyla mı açıldı.
Eşitleme zamanı ve ACL sürümü: Bu bilginin ne kadar eski olduğunu ölçebilmek için.
Hassasiyet etiketi: Varsa "gizli" veya "kişisel veri içerir" gibi sınıflar.

Hazır çözümlerin olgunluğunu da kontrol edin. Azure AI Search'ün belge düzeyi erişim özellikleri (ADLS Gen2 ACL'leri, SharePoint izinleri, Microsoft Purview hassasiyet etiketleri) bu yazının güncellendiği tarihte hâlâ önizleme durumundadır. Önizleme özellikleri hizmet seviyesi taahhüdü kapsamında değildir ve Microsoft bunları üretim için önermez. Aynı belgeye göre ADLS Gen2'deki öznitelik tabanlı (ABAC) koşullar değerlendirilmez ve izin değişikliklerinin aramaya yansıması bir süre alır. Bu yüzden hangi yolu seçerseniz seçin, davranışı kendi verinizle test etmeden üretime almayın.

Miras, istisna ve yetki kaldırma

Klasör izni, paylaşım bağlantısı, belgeye özel istisna ve grup üyeliğinin pasajlara nasıl geçtiğini yazılı bir kurala bağlayın. Bir alt dosya klasör kuralını değiştirebilir; yalnızca klasörden miras alınan grup etiketi bu durumda yanlış olur. İç içe gruplar da sık atlanan bir noktadır: kullanıcı doğrudan değil, bir alt grup üzerinden yetkili olabilir.

Yetki kaldırma için bir hedef süre belirleyin ve ölçün. Örneğin bir çalışan insan kaynakları grubundan çıkarıldığında, bordro belgelerinin 15 dakika içinde aramada görünmez olmasını hedefleyebilirsiniz. Önemli olan sayının kendisi değil, kaynak sistemdeki beklentiyle uyumlu olması ve izlenmesidir. Eşitleme gecikirse uyarı üretin; ACL bilgisi belirlenen süreden eski olan belgeleri aramaya kapatmak, yanlış kişiye göstermekten daha güvenlidir.

Örnek: bordro sorgusu testi

Bir çalışan "Bu yıl maaş artışı nasıl hesaplanıyor?" diye soruyor. Dizinde iki belge var: herkese açık ücret politikası ve yalnızca yöneticilerin görebildiği, kişi bazında artış oranlarını içeren tablo. Tablo, soruya anlamca daha yakın olabilir. Aynı soruyu üç kimlikle sorun ve ham arama sonuçlarını, yani modele gitmeden önceki pasaj listesini kontrol edin:

Kimlik	Görmesi gereken	Görmemesi gereken
Çalışan	Ücret politikası	Artış tablosu
İnsan kaynakları uzmanı	Politika ve tablo	Başka şirketin (kiracının) belgeleri
Gruptan yeni çıkarılan uzman	Ücret politikası	Artış tablosu (hedef süre dolduktan sonra)

Yalnızca son yanıtı değil, ham sonuç kimliklerini ve pasajları denetleyin. Model gizli pasajı görüp zararsız bir yanıt yazmış olabilir; bu, testin geçtiği anlamına gelmez.

Sızıntı test planı

Aşağıdaki testleri otomatikleştirip her bağlayıcı, grup eşitlemesi veya dizin değişikliğinden sonra çalıştırın:

Aynı soruyu farklı yetkideki kimliklerle sorun ve ham sonuçları karşılaştırın.
Bir kullanıcının grup üyeliğini kaldırın, hedef süre dolduktan sonra testi yineleyin.
İki kiracı için aynı adı taşıyan belgeler oluşturun; kiracılar arasında hiçbir sonuç geçmemeli.
Gizli bilgiyi adıyla değil dolaylı anlatımla isteyin ("yöneticilerin geçen yılki artış aralığı").
Bağlantıyla paylaşılmış ve şirket dışına açılmış dosyaların nasıl dizine alındığını kontrol edin.
ACL bilgisi eksik bir belge ekleyin; arama bu belgeyi hiç döndürmemeli.
Önbellekten dönen yanıtları farklı kimliklerle sınayın.
Yanıttaki atıf bağlantısını yetkisiz kullanıcıyla açın; kaynak sistem erişimi reddetmeli.

İçe alma hattını ve kimlikleri ayırın

Bağlayıcıların kaynak dosyaları okumak için geniş bir okuma yetkisine ihtiyacı olabilir; bu yetki hiçbir zaman sorguyu yapan kullanıcıya geçmemelidir. İçe alma ve sorgu için ayrı hizmet kimlikleri kullanın, her pasajın kökenini kaydedin. OWASP'ın yapay zekâ ajanı güvenlik rehberi en az yetki ilkesini ve getirilen içeriğin güvenilmeyen veri sayılmasını vurgular. Aynı ilke, kötü niyetli bir belgenin sonraki araç çağrılarını yönlendirmesini de zorlaştırır.

Önbellek, atıf ve kayıtlar

Yanıt önbelleği maliyeti düşürür ama yetki sınırını kolayca deler: yöneticinin sorusuna üretilen yanıt, aynı soruyu soran çalışana önbellekten dönebilir. Önbellek anahtarına kiracıyı ve kullanıcının izin kümesini ekleyin ya da yetkiye duyarlı sorgularda önbelleği kapatın. Atıf bağlantıları kaynak sistemin kendi yetki kontrolünden geçmelidir. Denetim kaydında kullanıcı kimliğini, uygulanan filtreyi, dönen belge kimliklerini, ACL sürümünü ve zamanı tutun; gereksiz yere hassas metni kaydetmeyin. Yetki değerlendirilemiyorsa aramayı genişletmek yerine güvenli bir hata döndürün.

Sık yapılan hatalar

Yetkiyi yalnızca arayüzde gizlemek, aramada uygulamamak.
İzinleri bir kez içe alıp grup değişikliklerini eşitlememek.
E-posta adresi gibi değişebilen bilgileri kimlik olarak kullanmak.
Testleri yalnızca son yanıt üzerinden yapmak, ham sonuçlara bakmamak.
Önbelleği ve özet dizinlerini yetki modelinin dışında bırakmak.

Hatson Tech bunu nasıl kuruyor?

Getirme anında uygulanan yetki filtreleri, RAG ve anlamsal arama çözümlerimizde temel bir gerekliliktir. Projeye kaynak sistemlerin yetki modelini çıkararak başlıyor, yukarıdaki test planını kabul ölçütlerine yazıyoruz. Verinin kurum dışına çıkamadığı durumlar için kurum içi yapay zekâ rehberimize, arama kalitesini artırmak için hibrit arama ve yeniden sıralama yazımıza bakabilirsiniz. Bu yaklaşımı uygulamadan önce kaynakları kendi verinizle, yetkilerinizle ve kullandığınız ürün sürümüyle karşılaştırın.

Sıkça sorulan sorular

RAG'de yetkiyi modele talimat vererek sağlayabilir miyim?

Hayır. Model talimatı okuduğunda gizli pasaj zaten bağlamındadır; özetlerde, farklı ifadelerde ya da araç çağrılarında ortaya çıkabilir. Yetki, sıralama ve üretimden önce aramanın içinde uygulanmalıdır.

Vektör veritabanları yetki kontrolünü kendisi yapar mı?

Birçoğu meta veri filtresi, ad alanı ya da belge düzeyi güvenlik sunar; ancak yalnızca kendisine verilen bilgiyi uygulayabilir. Uygulamanızın her pasajla yetki alanlarını saklaması ve her sorguda oturum açmış kullanıcının kimliğini ve gruplarını iletmesi gerekir.

Kaldırılan bir yetki RAG'e ne kadar sürede yansımalı?

Kaynak sistemdeki beklenti ne kadar hızlıysa o kadar. Bir hedef süre belirleyin, her grup eşitlemesinden sonra ölçün ve yetki bilgisi belirlenen süreden eski olan belgeleri gizleyin.

Embedding'ler de hassas veri sayılır mı?

Evet. OWASP, embedding vektörlerinden kaynak metnin önemli bir kısmının geri elde edilebileceğini belirtir. Bu yüzden vektör deposu da belgelerle aynı erişim, şifreleme ve saklama kurallarına tabi olmalıdır.

Çok kiracılı bir üründe tek dizin mi, kiracı başına dizin mi?

Az sayıda ve kesin ayrılmış müşteri varsa ayrı dizinler en güçlü yalıtımı verir. Kiracı sayısı fazlaysa, her sorguda zorunlu kiracı filtresi olan ortak bir dizin genellikle daha uygulanabilirdir; yeter ki kiracılar arası testler otomatik çalışsın.