Kurumsal RAG Mimarisinde Veri Sızıntısını Önleme: Rol Tabanlı Belge Erişimi (RBAC) ve Metadata Filtreleme

Kurum içi belgelerle bir Üretken Yapay Zeka (RAG - Retrieval Augmented Generation) sistemi kurduğunuzda, çalışanların yetkisi olmayan hassas bilgilere erişip erişemeyeceği endişesi haklıdır. Vektör veri tabanına gömülen verileri kullanıcı kimliğine göre filtrelemezseniz, potansiyel bir veri sızıntısı kaçınılmazdır. Bu sorunun etkin çözümü, sorgu aşamasında metadata seviyesinde Rol Tabanlı Belge Erişimi (RBAC) filtrelemesi uygulamak ve belge seviyesindeki erişim denetim listelerini (ACL) vektör aramasına dahil etmektir. Bu yaklaşım, kullanıcıların yalnızca görmeye yetkili oldukları bilgileri almasını sağlayarak hem yapay zeka sistemlerinin güvenliğini hem de veri gizliliğini korur.

RAG Sistemlerinde Veri Sızıntısı Riski ve Vektör Veri Tabanlarının Kör Noktası

Geleneksel veri tabanı sistemleri, veriye erişimi kontrol etmek için yerleşik yetkilendirme mekanizmalarına sahiptir. Kullanıcı kimlik doğrulandıktan sonra, yetkilendirme katmanı hangi tablolara, satırlara veya sütunlara erişebileceğini belirler. Ancak RAG mimarileri, bu geleneksel yaklaşımı doğrudan uygulamakta zorlanır. RAG'in temelinde yatan vektör veri tabanları, içeriği anlamsal olarak aramak üzere tasarlanmıştır. Belge parçacıklarını (chunk) yoğun vektörlere dönüştürür ve bu vektörler arasında anlamsal benzerlik araması yapar.

Bu tasarım, vektör veri tabanını, içeriğin kendisini "anlamsal" olarak bilse de, içeriğin kime ait olduğunu veya kimin erişebileceğini "bilmez" hale getirir. Örneğin, bir İnsan Kaynakları (İK) departmanına ait maaş bordroları veya bir Hukuk departmanına ait gizli sözleşmeler, diğer belgelerle birlikte vektör veri tabanına gömülebilir. Bir kullanıcı, yetkisi olmamasına rağmen, doğru sorguyu yaparak veya anlamsal olarak ilgili başka bir sorgu üzerinden bu hassas belgelere ait parçacıklara ulaşabilir. Vektör veri tabanı, kullanıcının kimliğini veya yetkisini sorgulamaz; yalnızca en benzer vektörleri döndürür.

Bu durum, özellikle sağlık bilgi sistemleri (HBYS) gibi hassas kişisel verilerin (e-Nabız entegrasyonu örneklerinde olduğu gibi) yoğun olduğu alanlarda büyük risk taşır. KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) ve GDPR gibi düzenlemeler, kişisel verilerin yetkisiz erişime karşı korunmasını zorunlu kılar. Bu nedenle, RAG sistemlerinin kurumsal ortamlarda güvenle kullanılabilmesi için, temel vektör aramasının üzerine bir erişim kontrol katmanı inşa etmek kritik öneme sahiptir. Bu katman olmadan, RAG'in getirdiği verimlilik avantajları, potansiyel veri sızıntısı riskleriyle gölgelenecektir.

Rol Tabanlı Belge Erişimi (RBAC) ve Metadata Filtreleme Mekaniği

RAG sistemlerinde veri sızıntısını önlemenin anahtarı, sorgu anında kullanıcı bağlamını vektör aramasına entegre etmektir. Bu, Rol Tabanlı Belge Erişimi (RBAC) prensiplerini metadata filtreleme ile birleştirmekle mümkündür. RBAC, kullanıcıları belirli rollere atar (örneğin, "İK Yöneticisi", "Finans Uzmanı", "Proje Lideri") ve her role belirli belge türlerine veya kategorilerine erişim yetkisi verir.

Metadata filtreleme ise, vektör veri tabanına eklenen her belge parçacığına (chunk) ilgili erişim kontrol bilgilerini metadata olarak eklemeyi gerektirir. Bu metadata, belgenin orijinal kaynağı, ait olduğu departman, hassasiyet seviyesi, oluşturulma tarihi veya erişim yetkisi olan rolleri içerebilir. Örneğin, bir belge parçacığı şu metadata ile etiketlenebilir:

{
  "document_id": "doc_12345",
  "document_type": "HR_Policy",
  "department": "Human Resources",
  "sensitivity": "Confidential",
  "allowed_roles": ["HR_Manager", "HR_Specialist"],
  "author_id": "user_A"
}

Bir kullanıcı RAG sistemine bir sorgu gönderdiğinde, öncelikle kullanıcının kimliği doğrulanır ve bu kimliğe atanmış roller (örneğin, "Proje Lideri") alınır. Ardından, kullanıcının sorgusu, bu rollerle uyumlu bir metadata filtresiyle zenginleştirilir. Vektör veri tabanına gönderilen arama sorgusu sadece anlamsal benzerlik aramakla kalmaz, aynı zamanda bu metadata filtresiyle eşleşen parçacıklarla sınırlandırılır. Örneğin, eğer "Proje Lideri" rolündeki bir kullanıcı bir sorgu yapıyorsa ve bu rolün yalnızca "Proje Belgeleri" türündeki ve "Public" hassasiyet seviyesindeki belgelere erişimi varsa, sorguya otomatik olarak "document_type": "Project_Document", "sensitivity": "Public" gibi metadata filtreleri eklenir.

Bu yöntem, vektör veri tabanının kendisinin erişim kontrol mantığını anlamasına gerek kalmadan, dışarıdan uygulanan bir filtreleme mekanizması sağlar. Bu sayede, vektör veri tabanından dönen sonuçlar, kullanıcının yetkisi dahilindeki bilgilerle sınırlı kalır. Bu yaklaşım, hem veri güvenliğini artırır hem de LLM'ye yanlış veya yetkisiz bilginin ulaşmasını engeller. Bu, yapay zekanın güvenli ve etik kullanımı için temel bir adımdır.

Belge Erişimi Denetim Listeleri (ACL) ve Vektör Araması Entegrasyonu

Rol Tabanlı Belge Erişimi (RBAC) geniş kategori ve rol bazlı erişim kontrolü sağlarken, Belge Erişimi Denetim Listeleri (ACL - Access Control List) daha granüler ve belge özelinde yetkilendirme imkanı sunar. RBAC, "İK departmanı çalışanları tüm İK politikalarını görebilir" derken, ACL "İK departmanından Ali Yılmaz, bu özel performans değerlendirme belgesini görebilir" diyebilir. Kurumsal RAG mimarilerinde her iki yaklaşımın bir arada kullanılması, hem esneklik hem de sıkı güvenlik sağlar.

ACL'leri RAG mimarisine entegre etmenin iki ana yolu vardır:

1. Metadata Olarak Gömme: Her belge parçacığına, doğrudan o parçacığa erişebilecek belirli kullanıcı kimliklerini veya kullanıcı gruplarını içeren bir ACL listesi metadata olarak eklenebilir. Örneğin:

   {
     "document_id": "performance_review_001",
     "document_type": "Performance_Review",
     "allowed_users": ["user_AliYilmaz", "user_AyseDemir"],
     "allowed_groups": ["HR_Managers"]
   }
   

   Sorgu sırasında, kullanıcının kimliği (user_AliYilmaz) ve ait olduğu gruplar alınır. Vektör arama motoruna gönderilen filtre, kullanıcının kimliğinin veya gruplarından birinin allowed_users veya allowed_groups listesinde yer almasını şart koşar. Bu yöntem, her parçacık için ayrı ACL yönetimi gerektirse de, en doğrudan ve güvenli entegrasyonu sunar.
2. Harici ACL Servisi ile Dinamik Sorgu Modifikasyonu: Daha büyük ve dinamik ACL yapıları için, her parçacığın doğrudan ACL'lerini metadata olarak tutmak yerine, belgeye veya belge grubuna referans veren bir document_id veya security_tag metadata olarak tutulur. Sorgu anında, bu document_id veya security_tag, harici bir ACL yönetim servisine (örneğin, bir yetkilendirme mikroservisi veya LDAP/Active Directory ile entegre bir sistem) gönderilir. Bu servis, sorguyu yapan kullanıcının o belgeye erişim yetkisi olup olmadığını kontrol eder ve yalnızca erişimi olan belgelerin ID'lerini döndürür. Ardından, vektör arama sorgusu, bu izinli belge ID'leriyle (document_id IN [...]) filtrelenerek çalıştırılır. Bu yaklaşım, ACL'lerin merkezi olarak yönetilmesine olanak tanır ve metadata yükünü azaltır, ancak sorgu performansına ek bir gecikme ekleyebilir.

Hangi yöntemin seçileceği, kurumun mevcut kimlik ve erişim yönetimi (IAM) altyapısı, belge sayısı ve erişim kontrolünün granülerlik ihtiyacına bağlıdır. Her iki durumda da amaç, kullanıcının kimliğinin ve yetkilerinin, vektör arama sonuçlarını şekillendiren kritik bir faktör haline gelmesini sağlamaktır. Bu entegrasyon, KVKK gibi veri koruma mevzuatlarına uyumluluk için temel bir gerekliliktir.

Güvenli RAG Mimarisi için Uygulama Adımları ve Dikkat Edilmesi Gerekenler

Kurumsal RAG mimarisinde veri sızıntısını önlemek için adım adım bir yaklaşım izlemek ve bazı önemli noktalara dikkat etmek gerekir:

1. Kapsamlı Veri Enjeksiyon ve Metadata Zenginleştirme:
   • Kaynak Entegrasyonu: Belgelerinizi çektiğiniz her kaynaktan (doküman yönetim sistemleri, kurumsal ERP sistemleri, dosya sunucuları vb.) belge ID'si, yazar, departman, hassasiyet seviyesi, oluşturulma tarihi gibi tüm ilgili metadata'yı alın.
   • Erişim Bilgilerinin Çıkarılması: Mevcut erişim kontrol sistemlerinizden (ACL'ler, RBAC rolleri) her belge için hangi kullanıcıların/grupların/rollerin erişebileceği bilgisini çıkarın. Bu bilgiyi, vektör veri tabanına gömülecek her parçacığın metadata'sına dahil edin.
   • Chunking ve Metadata İlişkilendirme: Belgeleri parçalara (chunk) ayırırken, her parçacığın orijinal belgenin tüm metadata'sını taşıdığından emin olun. Parçacık düzeyinde özel erişim kısıtlamaları varsa, bu kısıtlamaları da parçacık metadata'sına ekleyin.
2. Kimlik ve Erişim Yönetimi (IAM) Entegrasyonu:
   • Kullanıcı Kimliği ve Rol Çözümlemesi: RAG uygulamanızın, kullanıcının oturum açtığında kimliğini ve atanmış rollerini güvenli bir şekilde alabilmesi gerekir. Bu genellikle OAuth 2.0/OpenID Connect veya SAML gibi standart protokollerle sağlanır.
   • Yetkilendirme Servisi: Kullanıcının rollerini ve yetkilerini dinamik olarak sorgulayabilen bir yetkilendirme servisi oluşturun veya mevcut bir kurumsal IAM çözümüne entegre olun.
3. Sorgu Anında Metadata Filtreleme Mantığı:
   • Kullanıcı Bağlamı Entegrasyonu: Her kullanıcı sorgusundan önce, kullanıcının kimliğini ve rollerini kullanarak bir metadata filtresi oluşturun. Bu filtre, vektör veri tabanı sorgusuna eklenir.
   • Filtreleme Operasyonları: Vektör veri tabanınızın (örneğin Pinecone, Weaviate, Milvus, Chroma gibi popüler çözümlerin çoğu bu özelliği sunar) metadata filtreleme yeteneklerini kullanın. Bu filtreler genellikle anahtar-değer eşleşmeleri, aralık sorguları veya liste içerik kontrolleri şeklinde çalışır.
4. Performans ve Ölçeklenebilirlik:
   • İndeksleme Stratejisi: Metadata filtrelemesi, vektör arama performansını etkileyebilir. Özellikle sık kullanılan metadata alanları üzerinde indeksleme yapmak performansı artırır.
   • Sorgu Optimizasyonu: Karmaşık filtrelerin sorgu gecikmesini artırmaması için filtre mantığını optimize edin. Gerekirse, yaygın kullanıcı rolleri için önceden hesaplanmış filtre kümeleri kullanın.
5. Güvenlik Denetimi ve İzleme:
   • Erişim Günlükleri: Kimin hangi belge parçacıklarına eriştiğini veya erişmeye çalıştığını gösteren ayrıntılı günlükler tutun. Bu, olası veri sızıntılarını tespit etmek ve güvenlik denetimlerini sağlamak için kritik öneme sahiptir.
   • Periyodik İnceleme: Erişim kontrol politikalarını ve metadata etiketlemelerini düzenli olarak gözden geçirin ve güncelleyin. Kurumsal politika değişiklikleri veya yeni veri türleri, bu kontrollerin de güncellenmesini gerektirebilir.

Önemli Uyarı: RAG sistemlerinde güvenlik, sadece vektör veri tabanı filtrelemesiyle sınırlı değildir. LLM'ye gönderilen istemlerin (prompt) manipülasyonu (prompt injection) veya LLM'nin hatalı yanıtlar üretmesi (hallucination) gibi riskler de mevcuttur. Bu risklere karşı da ek güvenlik katmanları (örneğin, istem denetimi, yanıt filtreleme) düşünülmelidir. OWASP'ın LLM Top 10 güvenlik açıkları listesi, bu konuda değerli bir kaynaktır.

Bu adımları uygulayarak, kurum içi belgelerinizle beslenen RAG sisteminizin hem güçlü bir bilgi keşif aracı olmasını hem de hassas verilerinizi yetkisiz erişime karşı korumasını sağlayabilirsiniz. Kendi ekibinizle bu karmaşık entegrasyonları yönetmekte zorlanıyorsanız, bu alanda yetkin dış kaynaklardan destek almak, projenizin güvenliğini ve başarısını garantileyecektir.