Blog details
Bir LLM uygulamasında risk, large language models tabanlı modelin yanlış yanıt vermesiyle sınırlı değildir. Doküman erişimi, API çağrıları veya müşteri verisi söz konusuysa güvenlik riskleri (security risks) iş sürecine yansıyabilir.
Bu nedenle LLM tehdit modelleme, uygulamayı yayına almadan önce hangi varlıkların korunacağını ve saldırganın hangi yolu izleyebileceğini görünür kılar. STRIDE yaklaşımı, LLM güvenliği (LLM security) kapsamında sorumlulukları ayrıştırır. Model sağlayıcısı, veri bağlantıları ve araç yetkileri konusunda ekiplerin aynı dili konuşmasına yardım eder.
Önce mimariyi ve korunacak varlıkları netleştirin; model ağırlıkları, API davranışı ve çıkarım uç noktaları da model theft riskine karşı korunmalıdır. Ardından her veri akışını sorgulayın; STRIDE, threat modeling yaklaşımıyla bu yolları görünür kılar.
Önemli Çıkarımlar
- LLM tehdit modelleme, model seçiminden önce başlamalı; veri kaynaklarını, araçları, kullanıcı rollerini, güven sınırlarını ve korunacak varlıkları birlikte kapsamalıdır.
- STRIDE; kimliğe bürünme, veri veya talimat değiştirme, işlemi inkâr etme, bilgi sızıntısı, hizmet engelleme ve yetki yükseltme tehditlerini LLM mimarisine uyarlamak için kullanılabilir.
- Prompt injection ve dolaylı prompt injection risklerine karşı yalnızca sistem prompt’unu gizlemek yeterli değildir. RAG katmanında sunucu tarafı yetkilendirme, dar araç izinleri, çıktı doğrulama ve kritik işlemler için insan onayı uygulanmalıdır.
- Model, prompt, veri seti, belge ve araç yetkisi değişiklikleri MLOps süreçlerinde sürümlenmeli; günlükler, kırmızı ekip testleri ve bağımsız değerlendirmelerle tehdit modeli sürekli güncel tutulmalıdır.
- LLM çıktısını HTML, SQL, komut satırı veya iş akışına doğrudan aktarmayın. Yapılandırılmış çıktı şemaları, parametre doğrulama, kaçışlama, oran sınırlama ve devre kesici gibi katmanlı kontroller kullanın.
Tehdit modeli, model seçiminden önce başlar
Bu threat modeling yaklaşımı, model seçiminden önce başlar ve yalnızca modeli değil, bağlanacağı verileri ve erişeceği araçları da kapsar. LLM güvenliği yalnızca model sağlayıcısının sorumluluğu değildir. Bağladığınız veri kaynakları, verdiğiniz araç erişimleri ve yanıtı kullandığınız sistem yeni saldırı yüzeyleri oluşturur.
Bir kurumsal asistanın tipik mimarisinde şu bileşenler bulunur:
- Kullanıcının sohbet ettiği web, mobil uygulama veya çalışan paneli
- Kimlik doğrulama katmanı, oturum belirteçleri ve kullanıcı rolü bilgileri
- Orkestrasyon servisi, sistem prompt’u ve güvenlik kuralları
- LLM API’si veya kurum içinde çalışan model
- retrieval augmented generation (RAG) katmanı, belge deposu, vector databases, belge parçaları, indeksler ve erişim metaverileri
- CRM, ERP, e-posta, takvim veya reklam platformu gibi araç entegrasyonları
- Günlükler, analitik veriler, değerlendirme kayıtları ve izleme sistemleri
Bu bileşenleri tek bir “yapay zekâ uygulaması” olarak görmek riskleri saklar. Bunun yerine veri akış diyagramı çıkarın. Kullanıcının sorgusunun hangi servislerden geçtiğini, hangi veriyi okuduğunu ve hangi kimlik veya rol adına işlendiğini işaretleyin. Dış sisteme erişim noktalarını ayrıca gösterin.
Örneğin, satış temsilcisi müşteri adını yazdığında istek kimlik katmanından geçer. RAG sistemi, kullanıcı rolüne uygun fiyat listesini bulur ve yanıtı CRM ekranına döndürür. access control sunucu tarafında uygulanmalı, arama filtreleri prompt içine bırakılmamalıdır. Her geçiş noktası bir güven sınırıdır.
OWASP tehdit modelleme süreci, veri akış diyagramlarının saldırı noktalarını belirlemedeki yerini açık biçimde tanımlar. Diyagramınızda sadece teknik servisleri değil, kullanıcı rollerini, üçüncü taraf sağlayıcıları ve insan onay adımlarını da gösterin. Belge kaynağını, yükleyen kişiyi, sürümü ve onay durumunu eklemek, belge kaynağının izlenebilirliği için data provenance sağlar.
Korumanız gereken varlıklar şunlardır:
- Kişisel veriler, müşteri kayıtları, fiyatlar ve sözleşmeler
- Sistem prompt’ları, politika kuralları ve gizli iş akışları
- API anahtarları, servis hesapları ve erişim belirteçleri
- Eğitim, fine-tuning ve değerlendirme veri kümeleri ile bütünlük kayıtları. Veri setinin kötü amaçlı bozulması, training data poisoning sonucunda oluşan ayrı bir risktir.
- Vektör indeksleri, belge parçaları ve erişim metaverileri
- Araç çağrı kayıtları, denetim günlükleri ve model çıktıları
Bir varlık için “sızarsa ne olur?” sorusuna yanıt veremiyorsanız, o varlığın güvenlik gereksinimini henüz tanımlamamışsınızdır. Model veya hassas veri örüntülerinin sorgularla çıkarılması, bazı sistemlerde model inversion attacks riski taşır. Bu riski özellikle eğitim verileri, gizli belgeler ve model çıktıları için değerlendirin.
STRIDE’i LLM mimarisine uyarlayın
STRIDE, klasik yazılım güvenliğinde kullanılan altı tehdit kategorisinden oluşur: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service ve Elevation of Privilege. LLM mimarisinde bu sınıflar farklı adversarial attacks senaryolarını sınıflandırmaya yardımcı olur, ancak modelin olasılıksal davranışı ve araç kullanma yeteneği yeni ayrıntılar ekler.
Aşağıdaki tablo, her STRIDE kategorisini LLM uygulamalarına uyarlamanıza yardım eder.
| STRIDE kategorisi | LLM uygulamasındaki örnek | Öncelikli kontrol |
|---|---|---|
| Kimliğe bürünme | Çalınmış oturumla başka bir çalışanın bilgi tabanına erişim | Çok faktörlü doğrulama, kısa ömürlü belirteçler, servis kimliği |
| Veri veya talimat değiştirme | RAG belgesine gizli yönlendirme eklenmesi | Onaylı belge alımı, bütünlük kontrolü, sürümleme |
| İşlemi inkâr etme | Kullanıcının araç çağrısını reddetmesi | Korelasyon kimliği, zaman damgalı denetim kaydı |
| Bilgi sızıntısı (sensitive information disclosure) | Modelin başka müşteriye ait fiyatı yanıta eklemesi | Satır ve belge düzeyi yetkilendirme, veri maskeleme |
| Hizmet engelleme (denial of service) | Sonsuz araç döngüsü veya aşırı uzun sorgular | Kota, oran sınırlama, maliyet eşiği, devre kesici |
| Yetki yükseltme | Sohbet asistanının onaysız ödeme veya silme işlemi yapması | En az yetki, araç izin listesi, insan onayı |
Kimliğe bürünme ve yetki yükseltme
Kimliğe bürünme tehdidinde saldırgan, kullanıcıyı, eklentiyi veya güvenilir bir servisi taklit eder. LLM’in kullanıcı adını prompt içinden görmesi kimlik doğrulama değildir. Yetkiyi her araç çağrısında sunucu tarafında yeniden doğrulamanız gerekir.
Örneğin model, “Bu müşteri finans ekibindendir” cümlesini doğru kabul edebilir. Ancak CRM’den müşteri verisi isterken rolü kimlik sağlayıcınızdan doğrulamalısınız. Prompt, erişim kararı veren bir kaynak olmamalıdır.
Yetki yükseltme, agentic yapay zekâ uygulamalarında daha ağır sonuçlar doğurur. Takvim okuyabilen bir asistanın toplantı silmesi, rapor hazırlayan bir sistemin üretim veritabanında sorgu çalıştırmasıyla aynı risk düzeyinde değildir. Her araca ayrı kapsamlı belirteç atayın. Yazma, silme, ödeme ve dışarıya veri gönderme işlemlerinde insan onayı isteyin.
Değiştirme, inkâr ve bilgi sızıntısı
Tampering, yalnızca kod değişikliği anlamına gelmez. Saldırgan, bilgi bankanıza yüklenen PDF dosyasına “önceki kuralları yok say” türü bir talimat yerleştirebilir. Model bu metni kaynak bilgi yerine komut olarak algılarsa dolaylı prompt injection gerçekleşir.
Bu nedenle belge alım hattında dosya kaynağını, yükleyen kişiyi, sürümünü ve onay durumunu kaydedin. Embedding üretmeden önce içeriği kötü amaçlı talimat kalıpları açısından tarayın. Hassas dosyaları yalnızca doğru kullanıcı grubuna ait indekslere ekleyin.
İnkâr edilemezlik için ise model yanıtını tek başına kaydetmek yetmez. Kullanıcı kimliği, kullanılan belge kimlikleri, model sürümü, politika sürümü, araç çağrısı, onay kaydı ve sonuç aynı işlem kimliği altında tutulmalıdır. Buna rağmen günlüklerde gereksiz kişisel veri biriktirmeyin.
Bir modelin yanıtını kaydetmek denetim izi oluşturmaz. Yanıtın hangi kimlik, belge sürümü, araç izni ve politika ile üretildiğini de göstermeniz gerekir.
Referans mimaride veri akışını adım adım inceleyin
Kurumsal bilgi asistanı için tehdit modelini soyut kavramlardan çıkarıp gerçek akışa bağlayın. Bu threat modeling oturumunda ürün sahibi, yazılım mimarı, güvenlik sorumlusu, veri sahibi ve operasyon ekibi aynı veri akışı üzerinde çalışmalıdır.
Süreci aşağıdaki sırayla yürütebilirsiniz:
- İş amacını sınırlandırın. Asistanın ne yapacağını ve ne yapmayacağını yazılı hale getirin. “Müşteri sözleşmelerini özetler” ile “sözleşme koşullarını değiştirir” farklı risk profilleridir.
- Veri akış diyagramını oluşturun. Kullanıcı, uygulama, kimlik servisi, RAG katmanı, model, araçlar ve günlük sistemi arasındaki her bağlantıyı gösterin. İnternet üzerinden geçen ve kurum ağı içinde kalan veriyi ayırın.
- Güven sınırlarını işaretleyin. Kullanıcının tarayıcısından API’ye geçiş, RAG deposundan modele içerik aktarımı ve modelin üçüncü taraf araca çağrı yapması kritik sınırlardır.
- Her akışa STRIDE sorularını uygulayın. “Bu isteği kim taklit edebilir?” sorusuyla başlayın; veri kümesi için “training data poisoning gerçekleşebilir mi?” sorusunu sorun. Model çıktısının aşağı akışta işlenmesi için “insecure output handling hangi riski doğurur?” diye değerlendirin.
- Riski puanlayın ve sorumlu atayın. Olasılık, iş etkisi, istismar kolaylığı ve mevcut kontrol gücünü birlikte değerlendirin. Her kabul edilmiş riskin sahibi ve gözden geçirme tarihi olmalıdır.
OWASP’ın tehdit modelleme kontrol listesi, uygulamayı parçalama, tehditleri sıralama ve azaltıcı kontrolleri seçme adımlarını pratik bir çerçeveye oturtur. Uygulama risklerinin genel sınıflandırılması için bu listeyi OWASP Top 10 ile tamamlayıcı bir referans olarak kullanın.
MAESTRO gibi artificial intelligence odaklı çerçeveler de model, veri, altyapı ve operasyon katmanlarını birlikte ele alır. Özellikle generative AI projelerinde model, prompt ve veri kaynağı değişikliklerini MLOps workflows içinde izleyin. Model sürümü, kaynak belge sürümü ve araç yetkisi kayıtlarını her değişiklikte güncelleyin. Bu kayıtlar, tehdit modelinin güncel sistemi yansıtmasını sağlar. Ayrıca STRIDE-AI çalışması, klasik tehdit kategorilerini üretken yapay zekâ risk standartlarıyla birleştirmeyi hedefler. Bu tür çerçeveleri hazır şablon olarak değil, kendi mimarinizi sorgulayan bir çalışma planı olarak kullanın.
Prompt injection, RAG ve vektör veritabanı riskleri
Prompt injection, saldırganın modelin davranışını kendi talimatıyla değiştirmeye çalışmasıdır. Doğrudan saldırıda kullanıcı sohbet kutusuna zararlı komut yazar. Dolaylı saldırıda ise bu komut bir web sayfasına, e-postaya, ürün açıklamasına veya RAG belgesine saklanır.
Sistem prompt’unu gizlemek tek başına savunma değildir. Modelin talimatları yanlış yorumlayabileceğini kabul edin ve etkiyi sınırlayın. Girdi ve çıktıları content moderation politikalarıyla denetleyin. Araç erişimini daraltın, beklenmedik veri taleplerini durdurun ve hassas işlemleri kural motoruyla doğrulayın.
RAG, güncel kurumsal bilgiyi modele bağladığı için faydalıdır; aynı zamanda yeni güvenlik yüzeyleri açar. vector databases içindeki her belge parçasına müşteri, departman, gizlilik seviyesi ve erişim rolü metaverisi ekleyin. Arama sonuçlarını modele göndermeden önce bu yetkileri uygulayın. Veri ve embeddinglerdeki gizli örüntüler model inversion attacks yoluyla çıkarılabilir; bu risk, belge erişim yetkilerinin yerine geçmez.
Sadece sorguyu filtrelemek yetersizdir. Yetkisiz bir kullanıcı, uygun anahtar kelimelerle arama yaparak başka departmanın belge başlıklarını veya parçalarını elde edebilir. Belge başlıklarının ya da parçalarının sızması da data leakage sayılır. Bu nedenle retrieval katmanında belge düzeyinde access control kurun. Çok kiracılı sistemlerde her müşterinin indeksini mantıksal veya fiziksel olarak ayırın.
Eklentiler ve araçlar da saldırı yüzeyini büyütür. Bir modelin web araması yapması, dosya indirmesi veya API üzerinden işlem gerçekleştirmesi, excessive agency riskini artırır. Araç çıktısını güvenilir kabul etmeyin. Modelin dış sistemden aldığı her metin, saldırgan kontrollü talimat içerebilir ve adversarial attacks kapsamında değerlendirilmelidir.
Sonsuz araç döngüleri ve aşırı uzun sorgular denial of service riskine yol açabilir. Kota, oran sınırlama, maliyet eşiği ve devre kesici uygulayın.
Araç çıktısını doğrudan iş akışına aktarmak da risklidir. HTML, SQL veya komut satırına kontrolsüz aktarım, insecure output handling riskini doğurur. Sorun yalnızca model yanıtının kalitesi değildir; çıktı sonraki sistemde kod veya komut olarak çalışabilir.
training data poisoning ise eğitim veya fine tuning data kümesine kasıtlı olarak zararlı, yanıltıcı ya da taraflı örnekler eklenmesidir. Model, belirli tetikleyicilere istenmeyen davranışlarla yanıt verebilir. Veri kaynağını doğrulayın, veri seti karmalarını kaydedin, bağımsız değerlendirme kümeleri kullanın ve dağıtımdan önce geri dönüş testleri yapın. Bu akışların tamamındaki bulguları düzenli threat modeling çalışmalarına geri besleyin.
MLOps ve model sunum hattında savunmayı katmanlayın
LLM security, application security yaklaşımının dışında değil, doğrudan bir parçasıdır. Girdi filtresi, RAG yetkilendirmesi, araç izinleri ve çıktı denetimi, birlikte uygulanması gereken security controls örnekleridir. Tek bir guardrail, tüm security risks için yeterli değildir.
İlk katmanda kullanıcı girdisini boyut, biçim ve kötüye kullanım kalıpları açısından input validation kapsamında denetleyin. Güvenli content moderation politikaları, yüksek riskli talimatları, hassas veri taleplerini ve araç çağrısı niyetini değerlendirmelidir. Uzun metin veya karmaşık kod bloklarını otomatik olarak zararlı saymayın.
İkinci katman RAG ve orkestrasyondur. Belge kaynağı, kullanıcı yetkisi ve sorgu bağlamı burada kontrol edilir. Sistem prompt’unu sürümleyin. Politika değişikliğini kod incelemesi ve test olmadan üretime taşımayın.
Üçüncü katman araç çağrılarıdır; model sunum uç noktaları ve model artefact’ları da korunmalıdır. Yetkisiz API erişimi, model ağırlıklarının kopyalanması veya çıkarım davranışının sistematik taklidi model theft riskini artırır. Modelin “müşteri sil” komutunu üretmesi, işlem yapılacağı anlamına gelmemelidir. Sunucu tarafındaki uygulama, izin kapsamını doğrulamalı, parametreleri şemaya uygunluk açısından denetlemeli ve kritik işlemler için onay istemelidir.
Dördüncü katman çıktı yönetimidir. Model yanıtının filtrelenmeden HTML, SQL, komut satırı veya iş akışına aktarılması, insecure output handling olarak adlandırılır. Yanıtı çalıştırılabilir komut gibi ele almayın. Yapılandırılmış çıktı şeması kullanın, kaçışlama uygulayın ve kullanıcıya gösterilecek alanları ayrı kontrol edin.
MLOps workflows kapsamında model, prompt, bağımlılık ve yapılandırma değişikliklerini yazılım sürümü gibi yönetin. Onaylı artifact registry kullanın. Model ve bağımlılık imzalarını doğrulayın; imzalanmamış model dosyalarını, bilinmeyen paketleri ve erişim anahtarı içeren yapılandırmaları dağıtım hattından engelleyin. Bu kontroller, supply chain vulnerabilities kaynaklı riskleri sınırlar. Ayrıca geri alma planını test edin.
Eğitim ve model sürümü geçişlerinde training data poisoning riskini veri bütünlüğü kontrolleriyle değerlendirin. Veri seti karmalarını doğrulayın, bağımsız değerlendirme kümeleri kullanın ve geri dönüş testlerini çalıştırın.
İzleme tarafında varlık, kontrol ve olay görünürlüğünü sürekli sağlayan bir AI security posture management yaklaşımı benimseyin. Şu sinyalleri takip edin:
- Engellenen prompt injection denemelerindeki artış
- Yetkisiz belge erişimi ve araç çağrısı reddi
- Beklenmeyen token tüketimi, maliyet sıçramaları, sonsuz döngüler ve denial of service belirtileri
- Hassas veri maskelenmesi gerektiren yanıtlar
- Model, prompt veya bilgi tabanı sürüm değişiklikleri
- Güvenlik olayının tespiti ile kapatılması arasındaki süre
Kırmızı ekip testleri yalnızca yayına çıkışta yapılmamalıdır. Genel adversarial attacks senaryolarını ve model veya veri örüntüsü çıkarımını ölçen model inversion attacks testlerini uygulayın. Yeni model sürümü, yeni eklenti, yeni veri kaynağı veya yeni iş akışı her eklendiğinde threat modeling sürecini güncelleyin.
Pazarlama süreçlerinde LLM erişimini ayrıca sınırlandırın
LLM’ler, müşteri iletişimi ve büyüme ekiplerinde hızla yaygınlaşıyor. Üretken yapay zekâ (generative AI) bu kullanımı hızlandırıyor. SEO uzmanına içerik öneren bir asistanın Search Console, Google Ads veya CRM notlarına erişimi farklı hassasiyetler doğurur.
SEO, arama motoru optimizasyonu, teknik SEO, yerel SEO ve içerik pazarlamasında kullanılan asistanlar; sorgu verileri, müşteri brief’leri ve yayın planları için ayrı bağlamlarda çalışmalıdır. Bu verileri aynı anda modele göndermemek, data leakage riskini azaltır ve organik trafik hedeflerinizle marka görünürlüğünüzü korur. İçerik üretiminde content moderation, model önerilerinin marka ve mevzuat açısından gözden geçirilmesini, gerektiğinde insan onayını içeren bir yayın adımıdır. SEO danışmanlığı ile organik görünürlüğünüzü güçlendirin.
Benzer şekilde Google Ads yönetimi, Google Ads danışmanlığı, SEM danışmanlığı ve reklam yönetimi için kullanılan araçlara yalnızca okuma yetkisiyle başlayın. Bütçe değişikliği, teklif güncellemesi veya kampanya yayına alma gibi işlemler için onay akışı kurun. Böylece performans pazarlama ve dönüşüm optimizasyonu kararlarında model öneri sunar, nihai kontrol sizde kalır. Google Ads bütçenizi daha verimli yönetin.
Dijital pazarlama ajansı ekipleri için dijital pazarlama danışmanlığı, yapay zekâ pazarlama ve AI marketing çalışmaları aynı veri disiplinini gerektirir. Web tasarım veya kurumsal web tasarım projesinde LLM’e form kayıtları ve analitik erişimi veriyorsanız, bu verileri test ortamında anonimleştirin. Dönüşüm odaklı web tasarım çözümlerini inceleyin.
Aynı erişim kapsamı, SEO görünürlüğü, reklam bütçesi ve müşteri verileri için security risks oluşturabilir. Kurumsal LLM kullanım senaryolarını iş hedefleriyle ve güvenlik gereksinimleriyle birlikte değerlendirmek için yapay zekâ danışmanlığı sürecinden yararlanabilirsiniz.
Sıkça Sorulan Sorular
Prompt injection nedir?
Prompt injection, saldırganın modelin davranışını kendi talimatlarıyla değiştirmeye çalışmasıdır. Saldırı doğrudan sohbet girdisinden gelebileceği gibi web sayfası, e-posta veya RAG belgesi gibi harici içeriklere de gizlenebilir.
Sistem prompt’unu gizlemek prompt injection saldırılarını önler mi?
Hayır. Sistem prompt’unu gizlemek tek başına yeterli bir savunma değildir; araç izinlerini sınırlandırmak, girdileri ve çıktıları denetlemek, hassas işlemleri sunucu tarafında doğrulamak gerekir.
RAG sistemlerinde erişim kontrolü nasıl uygulanmalıdır?
Belge ve belge parçalarına müşteri, departman, gizlilik seviyesi ve erişim rolü gibi metaveriler eklenmelidir. Arama sonuçları modele gönderilmeden önce belge düzeyinde yetkilendirme uygulanmalı, erişim kararları prompt’a bırakılmamalıdır.
LLM araç çağrıları neden yetki yükseltme riski oluşturur?
Modelin bir komut üretmesi, işlemin otomatik olarak güvenli veya yetkili olduğu anlamına gelmez. Her araç çağrısında sunucu tarafı kimlik ve izin doğrulaması yapılmalı; yazma, silme, ödeme ve dışarıya veri gönderme işlemleri için insan onayı istenmelidir.
Sonuç: Kontrolü modelin yanıtından değil mimariden alın
Güvenli bir LLM uygulaması, iyi yazılmış bir sistem prompt’undan daha fazlasını ister. Veri akışını görünür kılan, STRIDE ile tehditleri sınıflandıran mimari gerçek korumayı sağlar. Çıktıları doğrulamak ve araç yetkilerini sınırlandırmak, insecure output handling riskini azaltır.
LLM tehdit modelleme çalışmasını tek seferlik belge olarak bırakmayın. Model, veri kaynağı veya entegrasyon değiştiğinde risk kaydını yeniden değerlendirin; yeni modeller ve entegrasyonlar adversarial attacks senaryolarını değiştirebilir. Model uç noktalarını ve artefact’larını model theft riskine karşı koruyun.
Threat modeling, mimari değiştikçe güncellenen sürekli bir çalışma olmalıdır.
Kurumsal yapay zekâ, SEO ve reklam sistemlerinizi ölçülebilir hedeflerle bir araya getirirken Dijital pazarlama stratejinizi birlikte planlayalım.
