Vektör DB Savunması ve Sıkılaştırma

İki modül boyunca RAG mimarisini ve bu mimariye yönelik sinsi saldırıları inceledik. Şimdi masanın diğer tarafına, savunma katmanına geçiyoruz. Bu odanın ana odağı vektör veritabanının kendisini sıkılaştırmak (hardening): Kiracı (tenant) izolasyonu, şifreleme (encryption at rest), veri kökeni (provenance) ve kriptografik doğrulama.

Bir sonraki oda ise modelin etrafına örülecek RAG'a özel güvenlik korkuluklarını (guardrails) işleyecek.

1) Kiracı (Tenant) İzolasyonu

Çok kiracılı (multi-tenant) RAG sistemlerinde alınması gereken en kritik mimari karar şudur: A müşterisinin/departmanının verisi, B kullanıcısının sorgusunda asla dönmemelidir.

Hatalı Tasarım (Anti-Pattern)

# Tüm tenant'lar tek bir collection'da; hiçbir tenant filtresi yok
results = vector_db.query(
    query_vector=embed(user_question),
    top_k=5
)

Bu yapıda kiracılar arası (cross-tenant) veri sızıntısı yaşanması bir ihtimal değil, kaçınılmaz bir sondur — sadece zaman meselesidir.

Doğru Tasarım — Satır Bazlı Filtreleme (Row-Level Filter)

results = vector_db.query(
    query_vector=embed(user_question),
    top_k=5,
    filter={
        "tenant_id": current_user.tenant_id,
        "department": {"$in": current_user.allowed_departments},
        "classification": {"$lte": current_user.clearance_level}
    }
)

Pinecone, Qdrant, Weaviate, Chroma, pgvector — güncel vektör veritabanlarının hepsi metadata filtreleme yeteneği sunar. Bunu ilk günden kullanın.

Daha İleri Seviye: Namespace / Collection İzolasyonu

Mantıksal filtreye ek olarak verileri fiziksel/yapısal olarak da ayırmak gerekir:

Yüksek güvenlik gerektiren sektörlerde (sağlık, finans, savunma sanayii vb.) her kiracı için ayrı collection (veya fiziksel instance) kullanmak zorunludur.

Bonus: Embedding Modeli İzolasyonu

Çok daha sıkı bir senaryoda: Her kiracı (tenant) için farklı bir embedding modeli veya versiyonu kullanılır. Böylece bir saldırgan, A şirketinin vektör uzayını çözse (inversion) bile B şirketinin verilerine müdahale edemez. Sahada nadir görülse de "ultra-yüksek güvenlikli" tasarımların bir parçasıdır.

2) Durağan Veri Şifrelemesi (Encryption at Rest)

Embedding Inversion (vec2text) saldırısı artık teorik değil, kanıtlanmış bir gerçektir: Vektörleriniz şifrelenmemişse, orijinal metin %90+ doğrulukla geri çıkarılabilir.

Vektör DB Disk Şifrelemesi

Modern yönetilen (managed) vektör veritabanlarının birçoğu varsayılan olarak durağan veri şifrelemesi (encryption at rest) sunar. Ancak mimar olarak bunu kontrol etmek sizin işinizdir:

• Pinecone: AWS KMS ile şifrelidir (Konsoldan Security sekmesini kontrol edin).
• Qdrant Cloud: AES-256 seviyesinde disk şifrelemesi kullanır.
• Weaviate Cloud: Altyapıyı sağlayan bulut servisinin (AWS/GCP/Azure) varsayılan şifrelemesini devralır.
• Self-Hosted (Kurum İçi): Şifrelemeyi KENDİNİZ kurmalısınız (LUKS, dm-crypt veya AWS EBS Encryption).

Kendi sunucunuzda barındırıyorsanız (self-host), diskin kendisi kesinlikle şifrelenmelidir. Vektör DB servisi çalıştığında veri bellekte okunabilir durumdadır, ancak sunucu diski çalınırsa veya yedekleme dosyası sızarsa, saldırgan hiçbir döküm (dump) alamaz.

Alan Bazlı Şifreleme (Field-Level Encryption - İleri Seviye)

Daha katı regülasyonlar için: Vektörlerin kendisini ve kritik metadata alanlarını ek bir simetrik anahtarla şifreleyin. RAG sistemi bu veriyi çekerken (retrieval) anlık olarak deşifre (decrypt) eder. Bunun bir performans maliyeti vardır (her sorguda ekstra deşifre işlemi), ancak:

• Disk şifrelemesi tek başına kötü niyetli bir sistem yöneticisinin (admin) veritabanı yedeğini çalmasını engellemez.
• Alan bazlı şifreleme, anahtar yönetim sisteminden (KMS) bağımsız hiçbir sızıntıya izin vermez.

Şifreleme Anahtarı Yönetimi (Key Management)

Şifreleme anahtarınız nerede duruyor? Tek bir hata noktası (SPOF) yaratmayın:

• AWS KMS / GCP KMS / Azure Key Vault gibi donanımsal güvenlik modülleri (HSM) destekli servisler kullanın.
• Mümkünse her kiracı için ayrı bir anahtar (per-tenant key) atayın.
• Anahtarları düzenli rotasyona sokun (örn. her 90 günde bir).
• Her deşifre (decrypt) işlemini denetim günlüklerine (audit log) kaydedin.

3) IAM ve RBAC (Kimlik ve Erişim Yönetimi)

Vektör veritabanına kimin, hangi yetkiyle erişebildiği, sıkılaştırmanın en temel adımıdır.

Tipik Rol Dağılımı

Hatalı Tasarım (Anti-Pattern): Tek API Anahtarı

# ❌ Tüm sistem için tek bir "Master" anahtar kullanmak
pinecone.init(api_key=APP_MASTER_KEY)  # Bu anahtar hem okur hem de tüm DB'yi silebilir!

# Uygulamanızda yaşanacak basit bir SSRF zafiyeti veya anahtar sızıntısı,
# tüm Vektör DB'nin silinmesine veya zehirlenmesine yol açar.

Doğru Tasarım: Yetki Ayrılığı

# Arama (Read) işlemleri için asistan servisinde kullanılacak anahtar
read_client = pinecone.init(api_key=READ_ONLY_KEY)

# İndeksleme/Yazma işlemleri için arka plandaki worker servisinde kullanılacak anahtar
write_client = pinecone.init(api_key=WRITE_KEY)

Okuma ve yazma yetkilerini ayırmak, "bir güvenlik açığı = tüm veritabanının ele geçirilmesi" zincirini anında kırar.

Ağ İzolasyonu (Network Isolation)

Vektör veritabanınız asla public (açık) internetten erişilebilir olmamalıdır.

• Pinecone: AWS PrivateLink veya GCP Private Service Connect kullanın.
• Qdrant Cloud: VPC Peering (Ağ Eşleme) kurun.
• Self-Host: Doğrudan kurum içi izole edilmiş bir VPC (Sanal Özel Ağ) içinde çalıştırın, IP beyaz listesi (whitelist) uygulayın.

4) Veri Kökeni (Provenance) ve İmzalı Parçalar (Signed Chunks)

RAG sistemine giren her bilgi parçası (chunk) için sisteme bir kaynak kanıtı sunulmalıdır.

Belge Metadata Standardı

Vektör veritabanına eklenen her vektörün yanına mutlaka şu standart metadata bloğunu ekleyin:

{
  "vector": [0.12, -0.34, ...],
  "metadata": {
    "tenant_id": "abc-corp",
    "department": "engineering",
    "classification": "internal_confidential",
    "source_url": "https://confluence.abc/page/12345",
    "source_revision": "rev:abc123",
    "uploaded_by": "[email protected]",
    "uploaded_at": "2024-05-01T10:00:00Z",
    "content_hash": "sha256:f3a2b1c...",
    "content_signature": "ed25519:..."
  }
}

İmzalı Parçalar (Signed Chunks)

Her metin parçasına kriptografik bir imza ekleyin ve arama (retrieval) sırasında bu imzayı LLM'e göndermeden önce mutlaka doğrulayın:

def retrieve_with_verification(query_vector):
    results = vector_db.query(query_vector, top_k=10)
    verified_results = []
    
    for r in results:
        # Metnin bütünlüğünü ve kaynağını doğrula
        if verify_signature(r.content, r.metadata.content_signature):
            verified_results.append(r)
        else:
            # İmzasız, bozuk veya sonradan manipüle edilmiş chunk!
            audit_log.warning("Chunk doğrulama başarısız! Potansiyel RAG Poisoning.", r.metadata.source_url)
            
    return verified_results[:5]  # Sadece doğrulanmış ilk 5 sonucu LLM'e gönder

Bu yapı, Siber Güvenlikteki "Getirmeden Önce Doğrula" (Verify-Before-Retrieve) prensibinin koda dökülmüş halidir.

Bu Tasarım Hangi Saldırıları Engeller?

5) Denetim Günlükleri (Audit Logging)

Vektör DB'ye yapılan her erişim ve işlem yapısal (JSON) olarak loglanmalıdır:

Kesinlikle Loglanması Gerekenler:

• Her arama (Query): Kim yaptı, ne zaman, hangi tenant filtresi kullanıldı, kaç sonuç döndü?
• Her CRUD işlemi: Kim ekledi/sildi, hangi belge etkilendi, dosya hash değeri neydi?
• İmza doğrulama (Signature Verification) hataları.
• Çok kısa sürede aşırı sorgu atan anormal aktiviteler (örn. 1 dakikada 1000 sorgu).
• Kiracılar arası (Cross-tenant) sınır ihlali denemeleri.

Bu logların doğrudan SIEM (Splunk, Elastic, Datadog vb.) sisteminize akması zorunludur.

Kritik SIEM Alarm Kuralları:

• Tek kullanıcıdan 1 saatte 1000+ query → UYARI (Olası Veri Çekme)
• Metadata filtresi olmadan veritabanına query atılması → KRİTİK (Sızıntı Riski)
• İmzasız chunk tespiti → KRİTİK (Veri Zehirlenmesi Şüphesi)
• Tenant-A'ya ait bir servisin/kullanıcının, Tenant-B'ye ait bir veriyi çekmeye çalışması → EN ÜST DÜZEY ALARM (İzolasyon İhlali)

6) Geri Getirme Sürecinde Anomali Tespiti (Anomaly Detection)

Çok daha ileri düzey bir savunma katmanı: Sistemdeki belgelerin çağrılma (retrieval) davranışlarını (pattern) izlemek.

• Normal Belge Davranışı:

  • Sadece kendi konu başlığıyla ilgili spesifik sorularda çağrılır.
  • Günde ortalama 5 ila 50 kez arası döner.
  • Genellikle ilgili departmanın kullanıcıları tarafından tetiklenir.

• Şüpheli Belge (Potansiyel Retrieval Hijack):

  • İçeriğiyle tamamen alakasız, çok geniş bir soru yelpazesinde sürekli olarak sonuçlar arasına girer.
  • Çağrılma sıklığı aniden günde 5000+ gibi anormal seviyelere fırlar.
  • Şirketteki alakasız tüm kullanıcı segmentlerinin (Örn: Hem İK, Hem Yazılım, Hem Pazarlama) ekranına düşer.

Bu anormallikleri tespit eden makine öğrenmesi tabanlı istatistiksel analizler (Control Charts, Z-Score), saldırıyı daha LLM zehirlenmeden erken aşamada karantinaya almanızı sağlar.

7) Periyodik Tarama ve Temizlik (Cleanup)

Vektör veritabanı durağan bir yapı değil, canlı ve sürekli büyüyen bir organizmadır. Düzenli güvenlik hijyeni şarttır:

• Haftalık: Anormal arama davranışına (retrieval pattern) sahip şüpheli belgelerin taranması.
• Aylık: Veritabanındaki tüm veri parçalarının (chunks) dijital imzalarının baştan sona yeniden doğrulanması.
• Üç Aylık (Çeyrek): Kiracı izolasyonunun (Tenant Isolation) sızma testleri ve Red Team simülasyonları ile test edilmesi.
• Yıllık: Tüm Vektör DB'nin Felaket Kurtarma (Disaster Recovery) ve yedekten dönme (Restore) tatbikatının yapılması.

Sıkılaştırma Kontrol Listesi

Olgun ve güvenli bir vektör veritabanı konfigürasyonu için kendinizi test edin:

• Tüm veritabanı sorgularında tenant_id metadata filtresi zorunlu tutuldu mu?
• Yüksek güvenlikli veriler için Namespace veya Collection izolasyonu yapıldı mı?
• Durağan Veri Şifrelemesi (Encryption at rest) aktif mi?
• Şifreleme anahtarları (KMS / Key Vault) ile güvenli bir şekilde yönetiliyor mu?
• API anahtarları Okuma (Read-Only) ve Yazma (Write) olarak fiziksel olarak ayrıldı mı?
• Veritabanı ağ seviyesinde izole edildi mi (VPC Peering, Private Endpoint, IP Whitelist)?
• Eklenen her metin parçası (chunk) kriptografik olarak imzalanıyor mu?
• Yazılımsal olarak "Getirmeden Önce Doğrula" (Verify-before-retrieve) mantığı koda entegre edildi mi?
• Tüm erişimler loglanıp SIEM platformuna aktarılıyor mu?
• Anormal belge çağrılma frekansları için SIEM üzerinde alarmlar (Anomaly Detection) oluşturuldu mu?

Bölüm Özeti

• Kiracı (Tenant) İzolasyonu, uygulamanın temel mimari kararıdır; sonradan yama yapılarak eklenemez. Satır bazlı filtreleme ve fiziksel izolasyon zorunludur.
• Durağan Veri Şifrelemesi (Encryption at rest), vec2text gibi vektörden metin çalma saldırılarına karşı en temel ve şart olan savunma hattıdır.
• IAM / RBAC: Tek API anahtarı kullanmak intihardır. Okuma/Yazma yetkileri ve ağ izolasyonu kesinlikle ayrılmalıdır.
• İmzalı Chunk'lar: Sistemin içine zararlı veri sızdırma (RAG Poisoning) saldırılarını kaynağında reddetmenin en etkili matematiksel yoludur.
• Denetim ve Loglama: Gözlemleyemediğiniz bir veritabanını koruyamazsınız. SIEM entegrasyonu lüks değil, gereksinimdir.

Sıradaki Oda: Vektör veritabanımızın altyapısını başarıyla sıkılaştırdık. Şimdi tüm bu sistemin beyni olan LLM çevresine öreceğimiz RAG'a özel Girdi ve Çıktı Korkuluklarına (Input/Output Guardrails) — temellendirme, atıf zorunluluğu, güvenilmez etiketleme ve URL beyaz listesi gibi konulara geçiyoruz.