Yapay Zeka Uygulamalarında Kimlik Doğrulama (Auth): LLM Oturumları ve Veri Gizliliği

Modern yazılım dünyasında "Kendi ChatGPT'nizi Geliştirin" furyası, her kurumu telaşla bir yapay zeka (AI) sohbet botu veya veri analiz asistanı yayınlamaya itti. İş ilanlarını özetleyen İK botlarından, müşteri faturalarını analiz eden finansal asistanlara (RAG) kadar devasa bir "Generative AI" ekosistemi kuruluyor.

Ancak ortada ölümcül bir sorun var: Geleneksel Backend geliştiricileri, standart bir SQL veri tabanına kimlik doğrulama (JWT/Session) entegre etmeyi yıllardır yapsa da, "Durum Bilgisi Tutmayan" (Stateless) karmaşık bir LLM modeliyle kullanıcı rollerini ilişkilendirme konusunda büyük güvenlik boşlukları bırakıyor.

Bir hacker, AI sohbet asistanınızın oturum bağlamını (Session Context) atlatarak, kendi yetkisiz hesabıyla başka bir şirketin faturaları hakkında sohbette derinlemesine sırlar alabiliyor olabilir!

Bu detaylı backend siber güvenlik analizinde, Yapay Zeka botlarının arkasındaki oturum mimarilerinde yatan zaafiyetleri (Context Hijacking, Broken JWT) ve bu uygulamalarda aşılmaz bir Authentication/Authorization kalkanı kurmanın sırlarını paylaşacağız.

---

1. Geleneksel Session Yönetimi ile AI Agent Arasındaki Uyumsuzluk

Geleneksel monolotik veya REST tabanlı mikroservis uygulamalarında bir GET /users/14 isteği gönderildiğinde sistem sizin JWT (JSON Web Token) imzanızı okur, Role'ünüz Admin değilse sizi engeller (HTTP 403 Forbidden). Süreç saniyeliktir.

Ama RAG (Retrieval-Augmented Generation) kullanan bir AI uygulamasındaki API isteğiniz farklıdır. Orada istek şu formattadır: {"prompt": "Son çeyreğe ait raporları özetle ve 14 nolu kullanıcı bilgilerini ekle."} Büyük Dil Modeli (LLM) bir veri tabanı değildir; kendisine gelen cümleyi anlar. Modeli çalıştıran LangChain, LlamaIndex benzeri aracı Python servisleri promptunuzu alır ve eğer JWT Role bilginizi (Claims) doğrudan LLM filtresinin içine sert bir bariyer (Middleware) olarak gömmediyse; AI modeli o cümlenin kendisine gerçekten admin olan birinden gelip gelmediği ayrımını kendi kendine yapamaz.

2. Derin Zafiyetler: Context Hijacking (Oturum Bağlamı Kaçırma)

Sızma testlerinde sıklıkla rastladığımız senaryolar şunlardır:

A. Thread ID Tahmin Edilebilirliği (Insecure Direct Object Reference)

Çoklu LLM konuşmaları genellikle bir thread_id veya session_id ile açık veri tabanlarında (Redis, ChromaDB, PostgreSQL vb.) tutulur. Eğer sisteminizde konuşma geçmişi (Chat History), kullanıcının Access Token'ına kriptografik (Cryptographic Binding) olarak bağlı değilse sadece thread_id=1055 değerini 1056 yaparak başka bir CEO'nun veya yöneticinin bot ile olan özel görüşme geçmişini kolaylıkla ekranınıza dökebilirsiniz. Bot, "Önceki konuşmamıza istinaden ne demiştin?" Promptunuzda seve seve başkasının verilerini size ifşa edecektir.

B. Persistent Chat Token Sızması (JWT Refresh Tehdidi)

LLM botlarıyla konuşmalar bazen günlerce aynı bağlam üzerinden gidebilir (Kalıcı Oturum). Ancak frontend sistemlerini yöneten geliştiriciler, kullanıcının sistemde "oturum süresini" uzatmak için Refresh Token mekanizmalarını Secure/HttpOnly sınırlarında (Cookie) değil de tarayıcı LocalStorage'inda tutarsa, XSS zafiyetiyle çalınabilir duruma getirirler. Hacker çaldığı token ile kendi bot arayüzünde mağdurun hesabından sisteme zehirli prompt'lar (Poisoned Prompt) ekleyebilir.

---

3. Kurşun Geçirmez Bir AI Authentication Mimarisi Nasıl Kurulur?

AI Backend'i geliştirirken sıfır güven (Zero-Trust) kurallarını makine öğrenimine taşımak gerekir:

1. Bağlam Bağlılığı (Context Bound Tokens): Sadece Bearer token ile işlem yapmayı bırakın. session_id'yi JWT imzasının kendi "Payload" içerisine (Custom Claim olarak) şifreyle mühürleyin. Backend, JWT içindeki session_id ile, Redis'te sorgulanan thread_id uyuşmadığında (Mismatch) isteği API Gateway seviyesinde anında koparsın (Dropping Request).
2. Kapsamlı Middleware Kontrolü (Hard Filter Bypass): LLM'e veriyi besleyen RAG fonksiyonlarına (Örn: Vector Search Engine fonksiyonları) kullanıcının rol bilgisini zorunlu (mandatory) bir argüman olarak dahil edin. LLM, "Tüm C-Level raporları" getirmeye çalışsa bile, Vektör Veritabanına inen sorgu Middleware uyarınca user_role=Employee filtresini aşamamalıdır.
3. Stateless Olarak Tasarlanmış Kriptografik Oturum (PASETO veya Şifrelenmiş JWT): State bilgilerinin (Önceki 5 mesaj) JWT'nin kendisinde tutulması payload'u patlatabilir (Çok uzun olması). Bunları sunucuda Redis / Memcached de tutup, sadece JWE (JSON Web Encryption) ile şifrelenmiş, kripto güvenli bir session key'i kullanıcıya vererek veri tutarlılığını garantiye alın.

Geliştirdiğiniz veya kurumsal entegrasyonla şirketinizin merkezine aldığınız AI ajanlarınız, basit bir prompt enjeksiyonu veya oturum hırsızlığı kurbanı olabilir. Red Team hizmetlerimiz ve Backend API Audit çalışmalarımız kapsamında, altyapınızdaki kritik mantık boşluklarını (Logic Flaws) ortaya çıkarıyoruz.

Temel Değerlendirme

Yapay Zeka Uygulamalarında Kimlik Doğrulama: LLM Oturumları (Session) ve Veri Gizliliği konusu yalnızca teknik bir ayrıntı değildir; yanlış ele alındığında veri sızıntısı, yetki aşımı, operasyon kesintisi veya regülasyon riski doğurur. En doğru yaklaşım, varlıkları ve kullanıcı rollerini netleştirip gerçek saldırı yolunu kanıtla test etmek, ardından düzeltmeyi ölçülebilir retest kriterine bağlamaktır.

Neden Kritik?

• Saldırganlar çoğu zaman en zayıf teknik kontrolü değil, en zayıf varsayımı hedefler.
• Otomatik taramalar bilinen kalıpları yakalayabilir ama iş etkisini ve zincirleme saldırı yolunu tek başına göstermez.
• Güvenlik çıktısı geliştirici, yönetici ve uyum ekibi tarafından aynı şekilde anlaşılmıyorsa aksiyona dönüşmez.

Pratik Senaryo

Bir ekip sistemi güvenli kabul eder çünkü login çalışır, pipeline yeşildir veya model beklenen cevabı üretir. Ancak saldırgan aynı akışta farklı kullanıcı, farklı tenant, farklı dosya veya farklı token ile deneme yaptığında tasarımın sakladığı gerçek risk ortaya çıkar. Bu yüzden testler mutlu yol yerine kötüye kullanım senaryolarıyla yazılmalıdır.

Yanlış Bilinenler

• “Araç taradı, kritik yok” güvenlik onayı değildir.
• “İç sistem, saldırgan erişemez” varsayımı modern saldırı zincirlerinde zayıftır.
• “Bu sadece teknik borç” denilen konu çoğu zaman müşteri verisi veya production erişimiyle birleşir.

Karar Tablosu

| Durum | Risk seviyesi | Önerilen aksiyon | | --- | --- | --- | | Demo veya izole test ortamı | Düşük-Orta | Mimari kararları ve veri akışını belgeleyin | | Staging production verisine yakın | Orta-Yüksek | Yetki, log ve abuse testlerini ekleyin | | Production veya müşteri verisi | Yüksek | Profesyonel assessment, remediation ve retest planlayın |

Kontrol Listesi

• Hangi veri modele veya retrieval katmanına giriyor?
• Kullanıcı yetkisi retrieval sonucuna uygulanıyor mu?
• Tool çağrıları insan onayı veya policy kontrolünden geçiyor mu?
• Prompt, cevap ve hata loglarında hassas veri maskeleniyor mu?
• Model/prompt değiştiğinde regresyon testi koşuyor mu?

Ne Zaman Profesyonel Destek Gerekir?

Sistem gerçek müşteri verisine, kurum içi dokümana, harici tool çağrılarına veya otomatik karar akışına bağlıysa profesyonel AI security assessment gerekir.

Eresus Yaklaşımı

Eresus Security bulguları yalnızca başlık olarak raporlamaz. Her bulgu için tekrar üretilebilir kanıt, iş etkisi, önerilen düzeltme, sorumlu ekip ve retest koşulu yazılır.

Eresus Security, AI uygulamalarında veri sınırı, tool kullanımı, RAG erişimi, oturum yönetimi ve üretim öncesi abuse senaryolarını birlikte test eder. Canlıya çıkmadan önce kısa bir AI Security Review ile riskleri kanıta bağlayabiliriz.

Uygulama Planı

1. Kapsamı Netleştir

• Etkilenen varlıkları, kullanıcı rollerini ve veri sınıflarını çıkarın.
• Normal kullanıcı akışıyla saldırgan akışını ayrı ayrı yazın.
• Hariç tutulan sistemleri ve test sınırlarını açıkça belirtin.

2. Kanıt Üret

• Bulguyu tek ekran görüntüsüne değil, tekrar üretilebilir adımlara bağlayın.
• Etkiyi teknik hata ve iş sonucu olarak ayrı açıklayın.
• Log, request ID, test hesabı ve zaman bilgisini not edin.

3. Retest Kriterini Belirle

• Düzeltmenin ne zaman tamam sayılacağını önceden yazın.
• Aynı sınıf hatanın başka endpoint veya akışlarda olup olmadığını kontrol edin.
• Bulguyu kapatmadan önce negatif test senaryosunu yeniden çalıştırın.

Sık Sorulan Sorular

Yapay Zeka Uygulamalarında Kimlik Doğrulama: LLM Oturumları (Session) ve Veri Gizliliği için ilk adım nedir?

İlk adım sistemin hangi veriye, hangi kimlikle ve hangi iş akışı üzerinden eriştiğini çıkarmaktır. Araç seçimi bundan sonra anlamlı hale gelir.

Otomatik araçlar bu riski tamamen yakalar mı?

Hayır. Otomatik araçlar başlangıç için faydalıdır, fakat yetki sınırı, iş mantığı, zincirleme etki ve gerçek istismar kanıtı manuel analiz gerektirir.

Bu çalışma çıktısı nasıl aksiyona dönüşür?

Her bulgu bir remediation sahibi, öncelik, iş etkisi ve retest kriteriyle yazıldığında doğrudan güvenlik backlog’una veya sprint planına girebilir.

Eresus bu konuda nasıl destek olur?

Eresus Security kapsam çıkarma, teknik test, kanıt üretimi, remediation danışmanlığı ve retest aşamalarını tek çalışma akışında destekler.

Raporlama ve İç Link Stratejisi

• Yazı ilgili hub sayfasına bağlanmalı ve okuyucuya bir sonraki teknik adımı göstermelidir.
• Aynı pillar içindeki en az iki destekleyici bloga bağlantı verilmelidir.
• Hizmet CTA’sı genel iletişim çağrısı gibi değil, okuyucunun karar anına uygun şekilde yazılmalıdır.
• Raporlama dili teknik kanıt, iş etkisi ve düzeltme önceliğini aynı yerde göstermelidir.

Retest Kapanış Kriteri

Bir bulgu yalnızca düzeltme yapıldı diye kapanmış sayılmaz. Aynı saldırı adımı tekrar denendiğinde başarısız olmalı, loglarda beklenen kayıt oluşmalı ve benzer akışlarda aynı sınıf hata bulunmamalıdır. Bu yaklaşım içeriği sadece bilgilendirici olmaktan çıkarıp uygulamaya dönük hale getirir.