RAG Sisteminde Erişim Yetkisi: Kullanıcı Yalnız Görebildiği Belgeden Yanıt Alsın
Beceri rehberi

RAG Sisteminde Erişim Yetkisi: Kullanıcı Yalnız Görebildiği Belgeden Yanıt Alsın

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 6 dk okuma

Kurum içi RAG, kullanıcının erişemeyeceği bir belgeden yanıt üretirse sistem bir veri sızıntısı kanalına dönüşür. Yetkiyi parçaya taşımayı, aramadan önce uygulamayı ve sızıntıyı test etmeyi öğrenirsiniz.

Bir bakışta

  1. Yetki, dil modeline değil aramaya uygulanır. Model yetkisiz içeriği hiç görmediyse, sızdıramaz.
  2. Her parça kaynak belgenin yetki bilgisini taşır. Yetki, ayrıştırma ve indeksleme sırasında parçaya eklenir.
  3. Filtre aramadan önce çalışır, sonuçtan sonra değil. Sonradan süzmek boş ya da eksik yanıt üretebilir.
  4. Kaynak sistemdeki yetki değişikliği indekse yansımalıdır. Eski yetkiyle indekslenmiş parça, işten ayrılan kişiye bile görünür kalabilir.
  5. Sızıntı, farklı rollerle yapılan testle yakalanır. Yetkisiz kullanıcının sorusuna yetkili içeriğin yanıt vermediği doğrulanmalıdır.

Sorun: tek bir indeks, farklı yetkili kullanıcılar

Kurum belgeleri herkese açık değildir. İnsan kaynakları dosyaları, finansal tablolar, hukuk yazışmaları, yönetim kurulu notları ve müşteri sözleşmeleri belirli kişilerce görülebilir. RAG sistemi bu belgeleri tek bir indekste topladığında, kaynak sistemlerdeki yetki ayrımı kendiliğinden sürmez. Arama, kullanıcının kim olduğunu bilmiyorsa, en alakalı parçayı getirir; o parça yetkisiz kullanıcının erişemeyeceği bir belgeden gelebilir.

Model bunu fark etmez; elinde olan bilgiyi kullanır. Bir çalışan 'üst yönetimin bu yılki ücret düzenlemesi nedir' diye sorduğunda, yetkisi olmayan bir belgeden yanıt verilmesi, kurumsal bir veri ihlalidir. Bu ihlal belgeyi açmak olmadan, yalnız bir sohbet sorusu ile gerçekleşir.

İlke basittir: sistemin bir kullanıcıya gösterebileceği her şey, o kullanıcının kaynak sistemde zaten görebileceği şeylerin kümesi olmalıdır. RAG, mevcut yetki modelini genişletmemeli, aynen taşımalıdır.

Genel RAG kurulumu ayrı bir konudur; burada yalnızca yetkilendirmenin mimarideki yeri ve uygulaması ele alınır.

Yetkiyi parçaya taşımak: indeksleme tarafı

Çözümün ilk adımı, yetki bilgisinin ayrıştırma ve indeksleme sırasında yakalanmasıdır. Her belgenin kaynak sistemdeki erişim bilgisi (kullanıcılar, gruplar, roller, gizlilik sınıfı) okunur ve o belgeden üretilen her parçaya meta veri olarak eklenir. Bir belge yüzlerce parçaya bölünse de, hepsi aynı yetki etiketini taşır.

Yetki bilgisini bireysel kullanıcı listeleri yerine grup ve rol üzerinden tutmak genellikle daha sürdürülebilirdir. Kullanıcı sayısı ve değişimi yüksek olduğunda, tek tek kişilerin belge bazında eşlenmesi hem büyür hem hata üretir. Rol temelli etiketler, kurumun yetki dizininden gelen grup üyeliğiyle eşleştirilir.

Etiketleme sırasında varsayılan davranış önemlidir. Yetki bilgisi okunamayan ya da belirsiz bir belge için güvenli varsayım 'erişim yok'tur; böylece hata durumunda sistem fazla göstermek yerine az gösterir. Gizlilik sınıflandırması bulunan kurumlarda bu sınıf da etiket olarak taşınır.

Ayrıştırma aşamasında kaynak bilgisini kaybeden bir hat, yetkiyi sonradan eklemek zorunda kalır ve bu çoğu zaman mümkün olmaz. Bu yüzden meta veri tasarımı yetki gereksinimiyle birlikte baştan yapılmalıdır.

Sorgu zamanı: kimin sorduğunu bilmek ve aramadan önce süzmek

Sorgu geldiğinde sistem önce kullanıcının kimliğini doğrular ve grup, rol bilgisini kurumun yetki kaynağından alır. Bu bilgi sistemin kendi kararıyla değil, güvenilir bir kimlik katmanından gelmelidir; kullanıcıdan gelen bir alanın yetki beyanı olarak kabul edilmesi ciddi bir açıktır.

Sonra arama, yalnızca kullanıcının yetki etiketleriyle eşleşen parçalar içinde yapılır. Çoğu vektör veritabanı ve arama motoru, meta veriye göre filtrelemeyi arama sırasında destekler. Ön filtreleme, modele giden bağlamın başından itibaren yetkili olmasını sağlar.

Son filtreleme ise sonuçları getirip yetkisizleri çıkarır. Bu yöntem sorunlar yaratır: birincisi, en alakalı sonuçlar yetkisizse ayıklandıktan sonra geriye az ya da hiç sonuç kalabilir ve sistem yanıt veremeyebilir; bir diğeri, yetkisiz içeriğin arama sistemi içinde geçmesi, günlüklerde ya da önbellekte izler bırakması gibi riskler doğar.

Son bir kontrol katmanı olarak, modele verilen bağlamın yetki etiketleri üretim aşamasında yeniden doğrulanabilir. Bu bir yedek önlemdir; asıl koruma aramadan önce uygulanan filtredir.

Şekil 1

Yetkisiz içerik aramaya hiç girmemelidir

Ön filtrelemeSon filtreleme
Ne zaman çalışırArama yapılmadan önceSonuçlar geldikten sonra
Yetkisiz içerikAday kümeye hiç girmezAranır, sonra çıkarılır
Yanıt kalitesiYetkili parçalar içinden en alakalısı gelirAlakalı sonuçlar çıkarılırsa yanıt boş kalabilir
Sızıntı riskiDüşükGünlük ve önbellekte iz kalabilir
Kaynak: Sayfa içeriğiMindset Institute

Yetkinin güncel kalması: senkron, önbellek ve türev içerik

Yetkilendirme, indeksleme anında doğru olsa da zamanla bozulur. Bir çalışan departman değiştirir, bir belge gizlilik sınıfı yükselir, bir proje kapanır ve ekip erişimi kaldırılır. Kaynak sistemde değişen yetki, indekse yansımazsa eski yetkiyle erişim sürer.

Bunun için farklı yollar vardır. Birincisi, kaynak sistemden gelen yetki değişikliği olaylarını dinleyip ilgili parçaların etiketini güncellemektir. Bir diğeri, yetki bilgisini indekste tutmak yerine sorgu anında kaynak sisteme sormaktır; daha taze ama daha yavaştır. Pek çok kurum karma yapı seçer: etiket indekste durur, kritik belgeler için sorgu anında doğrulama yapılır.

Dikkat edilecek bir başka alan, yetki kontrolünü dolaşan türev içeriklerdir. Belgenin özeti, çıkarılan anahtar bilgiler, önbelleğe alınmış yanıtlar ve konuşma geçmişi, asıl belgenin yetkisini miras almalıdır. Yetkili bir kullanıcının aldığı yanıt önbelleğe girip başka bir kullanıcıya sunulursa, belge korunsa bile bilgi sızar. Önbelleği kullanıcı ya da yetki grubu bazında tutmak bu riski ortadan kaldırır.

Günlükler de gizlilik açısından incelenmelidir: soru ve getirilen parçalar kayıt altına alınıyorsa, kayıtlara erişim de aynı yetki mantığıyla sınırlanmalıdır.

Sızıntıyı test etmek ve izlemek

Yetki mimarisi kâğıt üzerinde doğru olabilir; asıl güvence testten gelir. Sızıntı testi, farklı rollerde sanal kullanıcılarla aynı soruları sormaktır. Yetkili kullanıcı yanıtı alır mı, yetkisiz kullanıcı alır mı? Hassas bir belgeye dolaylı yolla da yönelen sorular denenir: belgenin içeriğini özetleyen, çıkarım yapan ya da parçalar halinde sorulan sorular.

Test kümesinde bilinçli olarak hassas ve herkese açık belge çiftleri bulunmalı, aynı konuda farklı yetki düzeylerine sahip belgeler yer almalıdır. Başarı ölçütü şudur: yetkisiz kullanıcı için hassas içerik hiçbir koşulda yanıt metninde, kaynak listesinde ya da alıntıda görünmez.

İzleme de süreklidir. Her sorgu için kimlik, uygulanan yetki filtresi ve getirilen kaynaklar kayda geçer; olağan dışı erişim örüntüleri denetime konu olur. Yetki değişiklikleri ve test sonuçları belgelenmeli, düzenli aralıklarla tekrarlanmalıdır.

Bu çalışma teknik bir ekibin tek başına çözebileceği bir konu değildir. Yetki matrisini bilgi güvenliği, belge sahibi birimler ve uyum ekipleri birlikte onaylamalıdır; hangi belgenin kime açık olduğu bir iş kararıdır, teknik bir ayar değil.

Şekil 2

Yetki, belgeden yanıta kadar her katmanda taşınır

  1. Belge ve kaynak yetkisiKaynak sistemdeki kullanıcı, grup ve sınıf bilgisi.
  2. Parça meta verisiHer parça, belgenin yetki etiketini taşır.
  3. Sorgu zamanı filtreKimlik doğrulanır, yalnız yetkili parçalar aranır.
  4. Yanıt ve kayıtKaynaklar gösterilir, önbellek ve günlükler yetkiyi korur.
Kaynak: Sayfa içeriğiMindset Institute

Kurgusal örnek: insan kaynakları ve finans belgeleri

Bir şirket, iç belgeleri tek bir RAG asistanında topluyor: genel politikalar, ürün dokümanları, insan kaynakları dosyaları ve finansal raporlar. Genel politikalar herkese açık, insan kaynakları dosyaları yalnız İK ekibine, finansal raporlar yalnız finans ve yönetime açıktır.

İndeksleme sırasında her belgenin kaynak sistemdeki grup yetkisi okunur ve parçalara eklenir. Kullanıcı soru sorduğunda, kimlik katmanı üyelik gruplarını verir; arama yalnız bu gruplarla eşleşen parçalarda yapılır. Satış çalışanı 'şirketin izin politikası nedir' diye sorduğunda genel politika belgesinden yanıt alır. Aynı çalışan 'bir çalışanın performans notları neler' diye sorarsa, ilgili İK parçaları aday kümeye girmediği için sistem yanıt veremez ve bunu açıkça belirtir.

Bir çalışan finans ekibinden pazarlama ekibine geçtiğinde, kurumun yetki dizinindeki değişiklik olayı indekse yansıtılır ve çalışan artık finansal raporlara ulaşamaz. Test ekibi her rol için bir sanal kullanıcı oluşturur, hassas sorular sorar ve sızıntı olup olmadığını denetler.

Örnek kurgusaldır; mantık gerçektir: yetki kaynakta tanımlanır, parçaya taşınır, aramada uygulanır, testle doğrulanır.

Sık yapılan hatalar

  • Yetkiyi dil modelinden istemek: 'yetkisi yoksa söyleme' komutu bir güvenlik katmanı değildir
  • Yalnızca son filtreleme yapmak
  • Yetki meta verisini sonradan eklemeye çalışmak
  • İndekslemeden sonra gelen yetki değişikliklerini yansıtmamak
  • Önbelleği ya da konuşma geçmişini kullanıcı bazında ayırmamak
  • Kimlik bilgisini kullanıcıdan gelen alana güvenerek almak
  • Özet ve türev içeriklerin yetkisini asıl belgeden ayırmak
  • Sızıntı testini hiç yapmamak ya da yalnız yetkili kullanıcıyla denemek

Bu hataların ortak noktası, yetkiyi bir ayar olarak görmek ve mimarinin her katmanına yaymamaktır. Gerçek koruma, belge, parça, arama, yanıt ve kayıt katmanlarının birlikte çalışmasıyla gelir.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Yapay Zeka Uyum ve Etik Uzmanlığı (AI Governance) Sertifika Programı, Üretken Yapay Zeka ve Büyük Dil Modeli Yönetişimi modülünde RAG mimarilerinde kaynak doğruluğu ve erişim kontrolünü, ayrıca KVKK ve veri yönetişimi başlıklarını işler. Yapay Zeka (AI) Destekli İş Analitiği Uzmanlık Programı ise Kurumsal Veri Analitiğinde LLM ve RAG Mimarisi modülüyle teknik kurulum tarafını kapsar.

İlgili Mindset programı

Yapay Zeka (AI) Destekli İş Analitiği Uzmanlık Programı

Sık sorulanlar

Sık sorulan sorular

Dil modeline 'yetkisiz bilgiyi paylaşma' demek yeterli olmaz mı?

Olmaz. Komutla verilen kısıtlar manipüle edilebilir ve model bağlamda gördüğü bilgiyi sızdırabilir. Güvenli yaklaşım, yetkisiz içeriğin modele hiç ulaşmamasıdır; bu da yetki filtresinin aramadan önce uygulanmasıyla sağlanır.

Yetki bilgisi parçalara nasıl eklenir?

Belge ayrıştırılırken kaynak sistemden okunan kullanıcı, grup, rol ve gizlilik sınıfı bilgisi, o belgeden üretilen her parçaya meta veri olarak yazılır. Böylece arama sırasında bu alan üzerinden filtreleme yapılabilir. Meta veriyi belge bazında bir kez okumak, parça bazında tekrar sormaktan daha verimlidir.

Kaynak sistemde yetki değiştiğinde ne olur?

Değişiklik indekse yansımazsa eski yetki geçerli kalır. Bunu önlemek için kaynak sistemin değişiklik olayları dinlenir ve ilgili parça etiketleri güncellenir; kritik belgelerde ayrıca sorgu anında kaynak sisteme doğrulama yapılabilir.

Yanıtta kaynak göstermek yetki açısından sorun olur mu?

Kaynak yalnız kullanıcının erişebildiği belgelerden gelmelidir; bu durumda gösterim sorun yaratmaz, tersine güveni artırır. Yetkisiz belge adının ya da başlığının dahi gösterilmemesine dikkat edin; başlıklar bile hassas bilgi taşıyabilir.

RAG Sisteminde Erişim Yetkisi Nasıl Uygulanır?