Yapay Zeka Uygulamalarında Kimlik Doğrulama: LLM Oturumları (Session) ve Veri Gizliliği
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:
- 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). - 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=Employeefiltresini aşamamalıdır. - 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.