RAG Güvenliği

Vektör Veritabanı Güvenliği: Sık Yapılandırma Hataları ve Kontrol Listesi

Vektör veritabanı güvenliği: kimlik doğrulama, ağ maruziyeti, anahtar ayrımı, snapshot ve yama hatalarını Qdrant, Weaviate ve Milvus örnekleriyle denetleyin.

Vektör veritabanı güvenliği sorunlarının çoğu gelişmiş saldırılardan değil, basit yapılandırma kusurlarından doğar: kimlik doğrulamasız erişim, internete açık yönetim ve iç portlar, şifresiz bağlantı, tek bir yönetici anahtarının her yerde kullanılması, korumasız snapshot'lar ve yamalanmamış sürümler. Bu altı alanı denetlemek bir RAG sisteminin risk yüzeyini belirgin biçimde küçültür. Bu yazı altyapı ve yapılandırma katmanını ele alır. Kiracılar arası yetki mantığı için RAG tenant izolasyonu ve multi-tenant RAG sızıntısı yazılarına bakabilirsiniz.

Vektör veritabanı güvenliği neden yapılandırmayla başlar?

Vektör veritabanları hızla prototipten üretime taşınan ürünlerdir. Varsayılan ayarlar kolay kurulum için seçilir ve güvenlik katmanları çoğu zaman sonradan açılır. Qdrant belgeleri bunu açıkça yazar: kendi sunucunuzda çalışan açık kaynak kurulumlar varsayılan olarak güvenli ve üretime hazır değildir, ulaşabilen herkesin isteğini kabul eder ve bağlantılar varsayılan olarak şifresizdir.

Sahadaki tablo bu uyarıyı doğruluyor. Legit Security araştırmacısı Naphtali Deutsch'un Ağustos 2024'te yayımladığı çalışma, internete açık vektör veritabanlarını taradı ve kurumsal ya da özel veri içeren yaklaşık 30 sunucu buldu. Açık kalan veriler arasında şirket içi e-posta yazışmaları, müşteri kişisel verileri, finansal kayıtlar ve aday özgeçmişleri vardı. Veriyi okumak için herhangi bir açık ya da araç gerekmedi, platformların kendi REST API'leri ve web arayüzleri yeterliydi. Bazı örneklerde veri değiştirilebilir durumdaydı. Bu, asistanın yanıtlarını değiştirmeye yarayan bir zehirleme kapısıdır.

Yanlış bir varsayım da riski büyütür: vektörlerin anlamsız sayılar olduğu düşüncesi. Çoğu kurulumda vektörün yanında özgün metin parçası saklanır ve vektörlerden metne dair bilgi geri kazanılabilir. Bu konu embedding inversion yazısında ayrıntılı ele alınır.

Varsayılan ayarlar ne kadar güvenli?

Üç yaygın açık kaynak ürünün belgelerindeki güvenlik varsayılanları ve dikkat noktaları şöyledir:

ÜrünBelgelenen varsayılanÜretimde yapılacakEk dikkat noktası
Qdrant (kendi sunucunuzda)Kimlik doğrulama kapalı, TLS kapalıapi_key, read_only_api_key, jwt_rbac, enable_tlsKüme içi iletişim portu 6335 varsayılan olarak korunmaz, dışarı açılmamalı
WeaviateAnonim erişim yapılandırmaya bağlıAnonim erişimi kapatıp API anahtarı ya da OIDC açmakBelgeler anonim erişimi yalnız geliştirme ve değerlendirme için önerir
MilvusKimlik doğrulama common.security.authorizationEnabled ile açılırDoğrulamayı açmak, root parolasını değiştirmekRoot kullanıcısı Milvus parolasıyla oluşturulur, 9091 metrik portu dışarı açılmamalı

Yönetilen bulut sürümleri genellikle kimlik doğrulamayı varsayılan olarak açar. Ama ağ kuralları, anahtar kapsamı ve erişim politikası yine sizin yapılandırmanızdır. "Yönetilen hizmet güvenlidir" varsayımı yapılandırma hatasını ortadan kaldırmaz.

Kimlik doğrulama ve anahtar ayrımı nasıl kurulur?

Paylaşılan tek bir yönetici anahtarı en sık görülen hatadır. Uygulamanın arama servisi, belge yükleme işi ve yönetici ayrı kimliklerle çalışmalıdır. Qdrant örneğinde yönetim anahtarı tüm işlemlere izin verir, salt okuma anahtarı yalnız okuma işlemlerine erişir, JWT tabanlı rol erişimi ise koleksiyon düzeyinde okuma ve yazma kapsamı tanımlamayı sağlar. Aşağıdaki örnekte anahtarlar sır yönetim sisteminden okunur, koda ya da imaja yazılmaz.

export QDRANT__SERVICE__API_KEY="$(vault kv get -field=yonetim qdrant/prod)"
export QDRANT__SERVICE__READ_ONLY_API_KEY="$(vault kv get -field=arama qdrant/prod)"
export QDRANT__SERVICE__JWT_RBAC=true
export QDRANT__SERVICE__HOST=192.0.2.15     # yalnız iç ağ arayüzü

TLS ise yapılandırma dosyasında service.enable_tls: true ve sertifika yollarıyla açılır. Qdrant belgeleri, API anahtarı kullanılıyorsa anahtarın şifresiz bağlantıda sızmaması için TLS'in zorunlu olduğunu vurgular.

Gözden kaçan bir ayrıntı vardır: Qdrant belgelerine göre salt okuma anahtarı snapshot listeleme ve indirme işlemlerine de erişebilir. Yani "yalnız arama yapıyor" diye geniş dağıtılan bir salt okuma anahtarı, koleksiyonun tamamının kopyalanmasına izin verebilir. Arama servisine koleksiyon düzeyinde kapsamı daraltılmış belirteç verin. Weaviate'te anonim erişimi kapatıp API anahtarını açın, Milvus'ta kimlik doğrulamayı etkinleştirip root yerine rol tabanlı kullanıcılar tanımlayın.

Ağ maruziyeti nasıl daraltılır?

Kimlik doğrulama kapalı ve servis internetten erişilebilir durumdaysa veri fiilen herkese açıktır. Ağ tarafında üç katman düşünün:

  1. Servisi genel internete değil, özel ağa ya da özel bağlantıya bağlayın. Geliştirme ortamında yalnız yerel arayüze bağlayın.
  2. Güvenlik grubu ya da ağ politikasıyla yalnız bilinen uygulama sunucularına izin verin.
  3. Küme içi iletişim, metrik ve yönetim portlarını ayrı ve daha dar kurallarla kapatın.

İç portlar sık atlanır. Qdrant'ın küme içi iletişim portu 6335 varsayılan olarak API anahtarıyla korunmaz. Milvus'ta 9091 metrik portundaki iki kimlik doğrulama atlatma açığı, Şubat 2026'da kritik önemde duyuruldu (CVE-2026-26190, CVSS 9,8). Danışma notu, bu portun dışarıya kapatılmasını önerir.

Dış görünürlüğü düzenli olarak kendi dış adreslerinizden ölçün. Hangi portların açık olduğunu ve hangi servislerin kimlik istemeden yanıt verdiğini kayda geçirin. Bu denetimi yalnız kendi sistemlerinizde yapın, başkasına ait bir sisteme izinsiz erişim TCK Madde 243 kapsamında suç oluşturabilir. Yerel model sunucuları için benzer bir denetim yaklaşımı yerel LLM sunucusu maruziyet denetimi yazısında anlatılır.

Meta veri filtresi neden yetkilendirme değildir?

Meta veri filtresi bir aramayı belirli etiketlerle daraltan sorgu parametresidir. Uygulama "kiracı" ya da "departman" filtresini kullanıcı arayüzünden alıp doğrudan veritabanına iletiyorsa kullanıcı bu değeri değiştirerek yetkisi olmayan belgeleri sonuçlara sokabilir. Doğru tasarımda filtre oturumdaki kimlikten sunucu tarafında üretilir, kullanıcı yalnız arama metnini verir ve sonuçlar döndürülmeden önce ikinci bir yetki kontrolü yapılır.

Meta veri alanlarının içeriği de dikkat ister. Bu alanlara kişisel veri, iç dosya yolları ya da hassas etiketler yazılmışsa arama sonucuyla birlikte ifşa olabilir. Yalnız gerekli alanları saklayın.

Snapshot, yedek ve test kopyaları nasıl korunur?

Snapshot ve yedekler canlı sistemle aynı içeriği taşır, ama çoğu zaman daha gevşek korunur. Depolama hesabındaki tek bir yanlış paylaşım izni sessiz bir sızıntıya dönüşebilir.

  • Snapshot'ları ayrı bir anahtarla şifreleyin, anahtarı yedekle aynı yerde tutmayın.
  • Snapshot oluşturma, indirme ve geri yükleme yetkisini ayrı bir role verin ve bu işlemleri kayda geçirin.
  • Snapshot geri yükleme uç noktasının dış adrese istek atmasını engelleyin. Qdrant belgeleri, giden ağ erişimini kısıtlamanın geri yükleme API'si üzerinden sunucu taraflı istek sahteciliğini azalttığını belirtir.
  • Üretim verisini geliştirme ortamına kopyalamayın, orada maskelenmiş ya da yapay veri kullanın.
  • Kaynak sistemden silinen bir belgenin vektör deposundan ve yedeklerden ne zaman temizleneceğini yazılı hale getirin.

Sürüm ve yama yönetimi neden kritik?

Vektör veritabanı yazılımı da başka her yazılım gibi açık taşır ve bu açıklar doğrudan tam yetkiye gidebilir. Kasım 2025'te duyurulan CVE-2025-64513, Milvus Proxy bileşeninde kimliği doğrulanmamış bir saldırganın kimlik doğrulamayı atlayıp kümede tam yönetici yetkisi almasına izin veriyordu. Düzeltme 2.4.24, 2.5.21 ve 2.6.5 sürümleriyle geldi. Hemen yükseltemeyenler için önerilen geçici önlem, sourceID başlığını ağ geçidinde ya da yük dengeleyicide istekten silmekti.

Sürüm disiplini için:

  1. Her vektör veritabanı örneğinin sürümünü envanterde tutun.
  2. Ürünün güvenlik danışma sayfasını ve CVE kayıtlarını izleyin.
  3. Yamaları önce test ortamında, sonra üretimde uygulayın.
  4. Kapsayıcı imajını güncel tutun, kullanılmayan eklenti ve uç noktaları kapatın.

Bu süreç için LLM framework yama yönetimi yazısındaki düzen uyarlanabilir.

Hızlı kontrol listesi: hangi sorular sorulmalı?

Her soruya "evet" diyemiyorsanız o madde bir iş kaydına dönüşmelidir.

AlanSoruBeklenen yanıt
KimlikHer istek kimlik doğrulanıyor mu?Evet, hizmet başına ayrı kimlik
AnahtarYönetim ve arama anahtarları ayrı mı?Evet, arama anahtarı koleksiyonla sınırlı
Varsayılan parolaRoot ya da yönetici parolası değiştirildi mi?Evet
AğAPI, iç iletişim ve metrik portları internetten erişilebilir mi?Hayır
Şifrelemeİstemci bağlantıları TLS ile mi?Evet
YetkiFiltre değeri sunucuda mı üretiliyor?Evet, oturum kimliğinden
SnapshotSnapshot'lar şifreli ve indirme yetkisi dar mı?Evet
SürümBilinen kritik açıklar yamalı mı?Evet
İzlemeOlağandışı sorgu ve dışa aktarma hacmi uyarı üretiyor mu?Evet

Açık bir vektör veritabanı fark edilirse ilk ne yapılmalı?

İlk adım erişimi daraltmaktır: servis özel ağa alınır, anahtarlar döndürülür ve erişim kayıtları silinmeden korunur. Ardından hangi koleksiyonların, hangi verilerle ve ne kadar süre açık kaldığı belirlenir. Kayıt tutulmuyorsa en kötü senaryo varsayılır.

Vektör veritabanında ikinci bir soru daha sorulmalıdır: veri değiştirildi mi? Yazma erişimi açık kaldıysa koleksiyonlar kaynak belgelerden yeniden oluşturulmalı ve asistanın son dönem yanıtları zehirli içerik açısından incelenmelidir.

İçeride kişisel veri varsa KVKK Madde 12 uyarınca veri sorumlusu ihlali Kurul'a ve ilgililere en kısa sürede bildirir. Kurul, 24.01.2019 tarihli ve 2019/10 sayılı kararıyla bu sürenin ihlalin öğrenilmesinden itibaren en geç 72 saat olarak uygulanacağını belirlemiştir. Hukuk ve veri koruma sorumluları süreçten hemen haberdar edilmelidir.

Sık Sorulan Sorular

Vektör veritabanı neden kaynak belgeler kadar korunmalı?

Çünkü vektör veritabanı yalnız sayı dizileri tutmaz. Çoğu kurulumda vektörün yanında özgün metin parçası, kaynak adı ve üst veri de saklanır. Ayrıca gömme vektörlerinden metne dair bilgi geri kazanılabildiği akademik olarak gösterilmiştir. Yazma yetkisi ele geçirilirse asistanın yanıtları da değiştirilebilir. Bu yüzden vektör deposu, beslendiği belgelerle aynı gizlilik sınıfında korunmalıdır.

Açık kaynak vektör veritabanları varsayılan olarak güvenli mi?

Genellikle hayır. Qdrant belgeleri, kendi sunucunuzda çalışan açık kaynak kurulumların varsayılan olarak güvenli ve üretime hazır olmadığını, ulaşabilen herkesin isteğini kabul ettiğini ve bağlantıların şifresiz olduğunu açıkça yazar. Milvus'ta kimlik doğrulama ayrı bir ayarla açılır ve root kullanıcısı bilinen bir varsayılan parolayla oluşturulur. Weaviate anonim erişimi yalnız geliştirme için önerir.

Meta veri filtresi yetkilendirme yerine geçer mi?

Geçmez. Filtre aramayı daraltan bir sorgu parametresidir. Filtre değeri istemciden geliyorsa değiştirilerek başka kullanıcıların verisine ulaşılabilir. Yetki kararı sunucu tarafında, doğrulanmış oturumdan türetilmeli ve sorgudan önce zorlanmalıdır. Çok kiracılı kurulumlarda ayrı koleksiyon, ayrı ad alanı ya da sunucuda zorunlu filtre gibi bir izolasyon modeli seçilmelidir.

Salt okuma anahtarı sızarsa ne olur?

Yalnız arama yapılabileceğini düşünmek yanıltıcıdır. Qdrant belgelerine göre salt okuma anahtarı snapshot listeleme ve indirme işlemlerine de erişebilir. Bu, tek bir anahtarla koleksiyonun tamamının kopyalanabileceği anlamına gelebilir. Arama servisi için koleksiyon düzeyinde kapsamı daraltılmış belirteç kullanın, anahtarları sır yönetiminde saklayın ve sızıntıda hemen döndürün.

Açık bir vektör veritabanı fark edilince ilk ne yapılmalı?

Önce erişimi daraltın: servisi özel ağa alın, anahtarları döndürün ve erişim kayıtlarını koruyun. Ardından hangi koleksiyonların ne kadar süre açık kaldığını belirleyin ve verinin değiştirilip değiştirilmediğini kontrol edin. İçeride kişisel veri varsa KVKK Madde 12 ve Kurul'un 2019/10 sayılı kararı uyarınca ihlali öğrendiğiniz andan itibaren en geç 72 saat içinde Kurul'a bildirim gündeme gelir.

Kaynaklar

İlgili Yazılar