LLM Güvenliği Nedir? Büyük Dil Modellerine Yönelik Siber Saldırılar ve Korunma Yöntemleri

LLM güvenliği nedir? Büyük dil modellerinde Prompt Injection, veri sızıntısı, güvensiz çıktı işleme, model kötüye kullanımı ve kurumsal güvenlik önlemleri.

Giriş: Yapay Zekâ Modeli Güçlendikçe Güvenlik Sorumluluğu da Büyüyor

Bir kurumun müşteri hizmetleri için büyük dil modeli kullandığını düşünelim.

Başlangıçta sistemin görevi oldukça basittir.

Müşterilerin sık sorulan sorularını cevaplamak.

Ürün bilgilerini açıklamak.

Destek taleplerini sınıflandırmak.

Ancak zaman içerisinde uygulamaya yeni özellikler eklenir.

Önce müşteri veritabanına bağlanır.

Ardından sipariş bilgilerini sorgulamaya başlar.

Daha sonra destek kayıtlarını güncelleyebilir hale gelir.

Son aşamada belirli müşteri işlemlerini otomatik gerçekleştirebilir.

Bu noktada yapay zekâ uygulaması artık yalnızca metin üreten bir sistem değildir.

Kurumsal bilgi kaynaklarına erişebilen ve gerçek iş süreçleri üzerinde etkisi bulunan bir yazılım bileşenidir.

Dolayısıyla güvenlik değerlendirmesi de değişmelidir.

Geleneksel bir uygulamada geliştirici, kullanıcı girdisinin hangi fonksiyona aktarılacağını ve hangi işlemin gerçekleştirileceğini büyük ölçüde önceden tanımlar.

Büyük dil modeli kullanılan sistemlerde ise kullanıcıların doğal dilde verdiği talepler yorumlanır ve modelin ürettiği çıktılar uygulama davranışını etkileyebilir.

Bu durum yeni güvenlik riskleri ortaya çıkarır.

Örneğin bir saldırgan modelin güvenlik talimatlarını aşmaya çalışabilir.

Güvenilmeyen bir dokümanın içerisine kötü niyetli talimatlar yerleştirebilir.

Modelden hassas bilgileri açıklamasını isteyebilir.

Model çıktısının başka bir sistem tarafından güvenli olmayan biçimde işlenmesini hedefleyebilir.

Veya modelin bağlı olduğu araçları kullanarak yetkisiz işlemler gerçekleştirmeye çalışabilir.

Bütün bu riskler LLM Security, yani Büyük Dil Modeli Güvenliği kapsamında değerlendirilir.

Ancak burada önemli bir nokta vardır:

LLM güvenliği yalnızca modelin zararlı cevaplar üretmesini engellemek değildir. Modelin bağlı olduğu uygulama, veri ve işlem sistemlerinin güvenliğini korumaktır.

Bu makalede LLM güvenliğinin temel kavramlarını, büyük dil modellerinin saldırı yüzeylerini, kritik güvenlik risklerini ve kurumların uygulaması gereken koruma yöntemlerini ayrıntılı şekilde inceleyeceğiz.

1. LLM Nedir?

LLM, Large Language Model ifadesinin kısaltmasıdır.

Türkçede Büyük Dil Modeli olarak adlandırılır.

Büyük dil modelleri, geniş veri kümeleri üzerinde eğitilmiş ve doğal dil ile ilişkili çeşitli görevleri gerçekleştirebilen yapay zekâ modelleridir.

Bu modeller:

Metin oluşturabilir.
Soruları cevaplayabilir.
Doküman özetleyebilir.
Kaynak kod yazabilir.
Metin sınıflandırabilir.
Bilgi çıkarımı yapabilir.
Çeviri gerçekleştirebilir.
Yapılandırılmış çıktı üretebilir.
Uygulamalarla entegre çalışabilir.

LLM teknolojileri yalnızca sohbet uygulamalarında kullanılmaz.

Günümüzde yazılım geliştirme, müşteri hizmetleri, hukuk, finans, insan kaynakları, bilgi yönetimi ve operasyonel süreçlerde de kullanılabilir.

Ancak modelin bir görevi yerine getirebilmesi, o görevi güvenli biçimde gerçekleştireceğini garanti etmez.

Örneğin model bir müşterinin sipariş bilgilerini doğru şekilde özetleyebilir.

Ancak uygulama gerekli yetkilendirme kontrollerini uygulamıyorsa başka bir müşterinin sipariş bilgilerini de açıklayabilir.

Bu durumda sorun modelin dil yeteneğinden değil, uygulamanın güvenlik mimarisinden kaynaklanır.

2. LLM Güvenliği Nedir?

LLM güvenliği, büyük dil modellerinin ve bu modelleri kullanan uygulamaların güvenlik tehditlerine karşı korunması için uygulanan teknik ve organizasyonel kontrollerin bütünüdür.

Bu kapsamda yalnızca modelin kendisi değil, modelin çalıştığı bütün sistem değerlendirilir.

Örneğin:

Kullanıcı → Uygulama → LLM → Veri Kaynağı → Araçlar → Çıktı

şeklindeki bir mimaride güvenlik riskleri farklı noktalarda ortaya çıkabilir.

Kullanıcı kötü niyetli talimat gönderebilir.

Uygulama yetkilendirme kontrolünü eksik uygulayabilir.

Model güvenilmeyen içeriği talimat olarak yorumlayabilir.

Veri kaynağı hassas bilgileri yetkisiz kullanıcıya sunabilir.

Araç entegrasyonu gereğinden fazla yetkiyle çalışabilir.

Model çıktısı başka bir sistemde güvenli olmayan işlem başlatabilir.

Dolayısıyla LLM güvenliği tek bir güvenlik filtresiyle sağlanamaz.

Güvenli LLM uygulaması, modelin çevresinde oluşturulan güvenlik mimarisinin sonucudur.

3. LLM Güvenliği ile Geleneksel Uygulama Güvenliği Arasındaki Fark

Geleneksel uygulama güvenliğinde kullanıcı girdileri belirli fonksiyonlar ve programlama kuralları çerçevesinde işlenir.

Örneğin bir web uygulamasında kullanıcıdan alınan customer_id parametresi veritabanı sorgusunda kullanılabilir.

Güvenlik kontrolleri parametrenin doğrulanması, sorgunun güvenli oluşturulması ve kullanıcının ilgili kayda erişim yetkisinin kontrol edilmesi gibi aşamalardan oluşur.

LLM uygulamalarında ise doğal dil girdileri de uygulamanın davranışını etkileyebilir.

Örneğin kullanıcı şu talimatı verebilir:

“Son üç aylık satış raporunu hazırla.”

Model bu talebi yorumlayarak hangi verilerin gerekli olduğunu belirlemeye çalışabilir.

Eğer araç kullanımı etkinse ilgili API çağrılarını önerebilir.

Bu durum güvenlik açısından yeni sorular doğurur.

Model hangi verileri isteyebilir?

Kullanıcının hangi raporlara erişim yetkisi vardır?

Modelin önerdiği araç çağrısı güvenilir midir?

Modelin okuduğu dokümanlar davranışını manipüle edebilir mi?

Bu nedenle geleneksel uygulama güvenliği ile LLM güvenliği birlikte uygulanmalıdır.

4. LLM Uygulamalarında Güven Sınırı Nedir?

Güven sınırı, farklı güven seviyelerine sahip bileşenlerin birbirinden ayrıldığı noktadır.

Örneğin internet üzerinden gelen kullanıcı girdisi güvenilmeyen veri olarak değerlendirilir.

Buna karşılık uygulamanın server-side yetkilendirme politikası daha yüksek güven seviyesine sahiptir.

LLM sistemlerinde güven sınırları daha karmaşık hale gelebilir.

Çünkü model aynı bağlam içerisinde hem güvenilir talimatları hem de güvenilmeyen içerikleri işleyebilir.

Örneğin bir kurumsal asistanın sistem talimatı şu olabilir:

“Yalnızca kullanıcının erişim yetkisi bulunan kurumsal belgeleri özetle.”

Ancak modelin okuduğu bir dokümanda farklı bir talimat bulunabilir.

Bu talimat dokümanın içeriğidir.

Gerçek sistem politikası değildir.

Modelin bu ayrımı her durumda doğru yapacağı varsayılmamalıdır.

Güven sınırlarının korunması

Güvenli mimaride:

Sistem politikaları uygulama katmanında desteklenmelidir.
Kullanıcı yetkileri backend tarafından doğrulanmalıdır.
Harici dokümanlar güvenilmeyen içerik olarak ele alınmalıdır.
Model çıktıları güvenli olmayan işlemleri doğrudan başlatmamalıdır.
Kritik araç çağrıları bağımsız kontrollerden geçmelidir.

Bu prensipler LLM uygulama güvenliğinin temelini oluşturur.

5. System Prompt, Developer Prompt ve User Prompt Nedir?

LLM uygulamalarında modele farklı kaynaklardan talimatlar sağlanabilir.

Kullanılan model ve API'ye göre bu talimatlar farklı rollerle temsil edilebilir.

System Prompt

System Prompt, modelin genel davranışını yönlendirmek için kullanılan üst düzey talimatları ifade eder.

Örneğin modelin hangi görev için kullanılacağı veya hangi davranış sınırlarının beklendiği tanımlanabilir.

Developer Prompt

Developer Prompt, uygulamayı geliştiren tarafın modele sağladığı görev ve davranış talimatlarını ifade edebilir.

Bu rolün kullanılabilirliği ve önceliği model sağlayıcısına bağlıdır.

User Prompt

User Prompt, son kullanıcının modele ilettiği talimat veya sorudur.

Örneğin:

“Bu dokümanı özetle.”

“Bu kodu açıkla.”

“Satış raporu oluştur.”

gibi talepler kullanıcı girdisidir.

Güvenlik açısından önemli ayrım

Bu rollerin bulunması uygulamanın otomatik olarak güvenli olduğu anlamına gelmez.

Modelin talimat önceliklerini nasıl uyguladığı kullanılan modele bağlıdır.

Ayrıca güvenilmeyen dokümanların veya araç çıktılarının yüksek öncelikli talimat gibi değerlendirilmemesi gerekir.

Prompt rolleri davranışı yönlendirmeye yardımcı olur; ancak erişim kontrolü ve yetkilendirme mekanizmasının yerine geçmez.

6. Prompt Injection: LLM Güvenliğinin Temel Tehditlerinden Biri

Prompt Injection, güvenilmeyen içeriklerin modelin davranışını değiştirmek amacıyla talimat gibi kullanılmasını hedefleyen saldırı yaklaşımıdır.

Bu saldırılar LLM güvenliğinin en önemli konularından biridir.

Örneğin bir yapay zekâ asistanı kullanıcıya ürün dokümanlarını özetlemektedir.

Saldırgan, asistanın okuyacağı bir dokümana farklı bir talimat yerleştirebilir.

Model bu içeriği özetlenmesi gereken veri olarak değerlendirmek yerine talimat gibi yorumlarsa güvenlik problemi oluşabilir.

Prompt Injection neden önemlidir?

Çünkü büyük dil modelleri doğal dil talimatlarını yorumlamak üzere tasarlanmıştır.

Ancak doğal dil içeriğinin hangi kısmının güvenilir talimat, hangi kısmının işlenecek veri olduğu her zaman teknik olarak kesin sınırlarla ayrılmayabilir.

Bu nedenle yalnızca prompt içerisine güvenlik kuralı yazmak yeterli değildir.

Uygulama mimarisi de modelin yapabileceklerini sınırlandırmalıdır.

Prompt Injection saldırılarını, doğrudan ve dolaylı saldırı yöntemlerini, örnek senaryoları ve korunma tekniklerini serimizin dördüncü bölümünde ayrıca inceleyeceğiz.

7. Jailbreak Saldırıları

Jailbreak, bir büyük dil modelinin davranış veya güvenlik kısıtlamalarını aşmaya yönelik girişimleri ifade eder.

Bu saldırılar farklı yöntemlerle gerçekleştirilebilir.

Örneğin saldırgan modelin belirli kısıtlamaları dikkate almamasını sağlamaya çalışabilir.

Ancak güvenlik değerlendirmesinde önemli bir ayrım yapılmalıdır.

Modelin beklenmeyen bir cevap üretmesi ile gerçek sistemde yetkisiz işlem gerçekleştirilmesi aynı şey değildir.

Örneğin model kullanıcıya erişim izni olmayan bir raporu oluşturabileceğini söyleyebilir.

Ancak backend yetkilendirmesi doğru uygulanıyorsa rapor verilerine erişim engellenebilir.

Bu nedenle Jailbreak testlerinde yalnızca modelin cevapları değil, uygulamanın gerçek güvenlik etkisi de değerlendirilmelidir.

8. LLM Veri Sızıntısı Nedir?

LLM veri sızıntısı, yapay zekâ uygulamasının hassas veya yetkisiz bilgileri uygun olmayan kişilere ya da sistemlere açıklaması veya aktarmasıdır.

Bu risk farklı kaynaklardan doğabilir.

Örneğin:

Kullanıcıya ait kişisel veriler.
Kurumsal finansal bilgiler.
Müşteri kayıtları.
Kaynak kod.
API anahtarları.
Sistem yapılandırmaları.
Ticari sırlar.
Gizli dokümanlar.

Bir LLM uygulamasında veri sızıntısı yalnızca modelin cevap metninde ortaya çıkmaz.

Veri, harici model servisine gönderilirken de güvenlik problemi oluşabilir.

Örneğin kurum içi bir uygulama, kullanıcı talebini karşılamak için gereğinden fazla müşteri verisini harici LLM API'sine aktarabilir.

Bu durumda modelin kullanıcıya hassas bilgi açıklamaması tek başına yeterli değildir.

Verinin hangi sisteme aktarıldığı ve nasıl işlendiği de değerlendirilmelidir.

9. Model Çıktısında Hassas Bilgi İfşası

Bir LLM uygulaması kurumsal bilgi kaynaklarına erişebilir.

Örneğin müşteri destek sistemi, müşteri kayıtlarını sorgulayabilir.

Ancak uygulama kullanıcı yetkilerini doğru uygulamıyorsa model başka müşterilere ait bilgileri açıklayabilir.

Örnek senaryo

Bir müşteri destek asistanı sipariş sorgulama API'sine bağlıdır.

Kullanıcı şu soruyu sorar:

“12345 numaralı siparişin teslimat adresini göster.”

Uygulama yalnızca sipariş numarasına göre veri getiriyorsa ve kullanıcının siparişin sahibi olduğunu kontrol etmiyorsa başka müşterinin adresi açıklanabilir.

Bu problem yalnızca LLM davranışı değildir.

Temelde nesne düzeyinde yetkilendirme eksikliğidir.

Güvenli yaklaşım

Kullanıcının kimliği doğrulanmalıdır.

Siparişin ilgili kullanıcıya ait olduğu kontrol edilmelidir.

Modelin erişebildiği veri kapsamı sınırlandırılmalıdır.

Gereksiz hassas alanlar modele gönderilmemelidir.

Bu yaklaşım, veri güvenliğinin prompt seviyesinde değil uygulama seviyesinde sağlanması gerektiğini gösterir.

10. System Prompt Leakage Nedir?

System Prompt Leakage, modelin sistem veya geliştirici talimatlarının bazı bölümlerini yetkisiz biçimde açıklaması riskini ifade eder.

Bazı kurumlar system prompt içerisinde uygulama davranışını tanımlayan ayrıntılı talimatlar kullanır.

Örneğin:

Uygulamanın rolü.
İş akışları.
Cevap formatı.
Kullanım politikaları.
Araç çağırma kuralları.

Ancak system prompt içerisinde parola, API key veya başka hassas erişim bilgileri tutulmamalıdır.

Çünkü prompt içeriğinin model tarafından hiçbir koşulda açıklanmayacağı garanti edilemez.

Güvenli yaklaşım

System prompt, güvenli secrets management sisteminin yerine kullanılmamalıdır.

Hassas erişim bilgileri uygulama katmanında korunmalıdır.

Yetkilendirme kararları prompt üzerinden verilmemelidir.

System prompt içerisinde güvenlik açısından kritik bilgiler mümkün olduğunca azaltılmalıdır.

11. LLM Çıktıları Neden Güvenilmeyen Veri Olarak Değerlendirilmelidir?

Bir LLM uygulamasında önemli güvenlik prensiplerinden biri model çıktılarının otomatik olarak güvenilir kabul edilmemesidir.

Model metin üretebilir.

JSON oluşturabilir.

SQL sorgusu önerebilir.

HTML içerik hazırlayabilir.

Terminal komutu oluşturabilir.

Ancak bu çıktılar güvenlik açısından doğrulanmadan çalıştırılmamalıdır.

Örneğin modelin ürettiği HTML içerik doğrudan web sayfasına eklenirse uygun çıktı kodlaması ve içerik güvenliği kontrolleri bulunmadığında XSS riski ortaya çıkabilir.

Benzer şekilde modelin oluşturduğu SQL sorgusunun doğrudan çalıştırılması gereksiz veri erişimi veya değişiklik riski oluşturabilir.

Güvenli çıktı işleme

Model çıktıları kullanılacakları bağlama göre doğrulanmalıdır.

HTML çıktıları güvenli biçimde işlenmelidir.

SQL işlemleri izin verilen sorgu ve veri erişim politikalarıyla sınırlandırılmalıdır.

Shell komutları doğrudan çalıştırılmamalıdır.

Yapılandırılmış çıktılar beklenen şemaya göre doğrulanmalıdır.

Kritik işlemler için bağımsız yetkilendirme ve onay mekanizmaları uygulanmalıdır.

12. Insecure Output Handling

Insecure Output Handling, model tarafından üretilen çıktının uygulama tarafından güvenli olmayan biçimde kullanılmasıyla ilişkili riskleri ifade eder.

Bu risk geleneksel yazılım güvenliği problemleriyle yakından ilişkilidir.

Örneğin bir uygulama LLM çıktısını kullanarak otomatik e-posta hazırlayabilir.

Başka bir uygulama modelin oluşturduğu komutu terminalde çalıştırabilir.

Bir başka sistem modelin önerdiği API parametreleriyle işlem gerçekleştirebilir.

Bu işlemlerin her biri farklı güvenlik seviyesine sahiptir.

Örnek: SQL raporlama asistanı

Bir kurum doğal dilde rapor hazırlayan yapay zekâ sistemi geliştirmiş olsun.

Kullanıcı:

“Son üç aylık satışları göster.”

talebini iletir.

Model SQL sorgusu oluşturur.

Eğer uygulama modelin ürettiği sorguyu hiçbir kontrol olmadan production veritabanında çalıştırıyorsa ciddi risk ortaya çıkabilir.

Daha güvenli yaklaşım, izin verilen sorgu türlerini sınırlandırmak, veritabanı hesabına yalnızca gerekli yetkileri vermek ve sorguları bağımsız güvenlik kontrollerinden geçirmektir.

13. LLM Tool Calling Güvenliği

Tool Calling, modelin uygulama tarafından tanımlanan fonksiyonları veya araçları kullanmak üzere çağrı önermesini sağlayan mekanizmadır.

Örneğin bir LLM:

Müşteri bilgisi sorgulayabilir.

Destek talebi oluşturabilir.

Takvim kaydı hazırlayabilir.

Raporlama servisini çağırabilir.

Ancak modelin bir araç çağrısı önermesi, bu işlemin yetkili olduğu anlamına gelmez.

Güvenli Tool Calling prensipleri

Her araç için ayrı yetki tanımlanmalıdır.

Kullanıcının işlem yetkisi doğrulanmalıdır.

Araç parametreleri kontrol edilmelidir.

Kritik işlemler için onay mekanizması uygulanmalıdır.

Araç çağrıları kayıt altına alınmalıdır.

Gereksiz araçlar modele sunulmamalıdır.

Özellikle para transferi, veri silme, kullanıcı yetkisi değiştirme ve altyapı yönetimi gibi işlemler yüksek riskli kabul edilmelidir.

14. Excessive Agency Nedir?

Excessive Agency, yapay zekâ sistemine iş ihtiyacının ötesinde işlem yetkisi verilmesiyle ilişkili güvenlik riskidir.

Örneğin bir kurumsal asistanın görevi yalnızca rapor hazırlamak olabilir.

Ancak aynı asistana müşteri kayıtlarını silme veya değiştirme yetkisi verilmişse gereksiz risk oluşur.

Bu durum özellikle AI Agent sistemlerinde önemlidir.

Örnek senaryo

Bir çalışan AI asistanına:

“Bu müşterinin son siparişlerini özetle.”

talimatını verir.

Asistan sipariş sistemine erişir.

Ancak kullandığı API hesabı yalnızca okuma değil, sipariş iptal etme yetkisine de sahiptir.

Bu durumda Prompt Injection veya model hatası, gereksiz işlem yetkileriyle birleştiğinde daha ciddi sonuçlara yol açabilir.

Korunma yöntemleri

En az yetki uygulanmalıdır.

Okuma ve yazma işlemleri ayrılmalıdır.

Kritik işlemler için insan onayı değerlendirilmelidir.

Araçların erişim kapsamı sınırlandırılmalıdır.

Kullanıcı bağlamına uygun yetkilendirme yapılmalıdır.

15. LLM Uygulamalarında RAG Güvenliği

RAG, Retrieval-Augmented Generation yaklaşımıdır.

Bu mimaride model, harici bilgi kaynaklarından getirilen içerikleri kullanarak cevap oluşturur.

RAG sistemleri kurumsal bilgi yönetiminde önemli avantajlar sağlayabilir.

Ancak güvenlik açısından farklı riskler içerir.

Örneğin:

Yetkisiz belge erişimi.

Doküman zehirleme.

Güvenilmeyen içerikten gelen talimatlar.

Hassas bilgi sızıntısı.

Tenant izolasyonu problemleri.

RAG güvenliğinin temel prensibi

Arama sisteminin bir dokümanı bulabilmesi, kullanıcının o dokümana erişim yetkisi olduğu anlamına gelmez.

Bu nedenle belge erişim politikaları arama ve veri getirme aşamasında uygulanmalıdır.

Modelin yalnızca prompt ile yetkisiz belgeyi gizlemesinin beklenmesi yeterli değildir.

16. Vector Database ve Embedding Riskleri

Vector Database sistemleri, embedding verilerini saklamak ve benzerlik aramaları gerçekleştirmek için kullanılabilir.

Bu sistemler RAG mimarilerinde yaygındır.

Ancak embedding verileri de veri güvenliği açısından değerlendirilmelidir.

Özellikle:

Veri erişim kontrolü.
Tenant izolasyonu.
Veri saklama.
Şifreleme.
Audit logging.
Veri silme.
Arama sonucu yetkilendirmesi.

gibi konular önemlidir.

Bir kurumun farklı müşterilere ait dokümanları aynı altyapıda tutması mümkündür.

Ancak müşteriler arasında veri izolasyonu sağlanmalıdır.

Bu kontrolün yalnızca model talimatına bırakılması doğru değildir.

17. LLM Denial of Service ve Kaynak Tüketimi

LLM sistemleri geleneksel web uygulamalarına göre farklı kaynak tüketim özelliklerine sahip olabilir.

Örneğin büyük bağlam pencereleri, uzun çıktılar veya yoğun model çağrıları yüksek işlem maliyetine yol açabilir.

Bir saldırgan uygulamanın kaynaklarını tüketmeyi hedefleyebilir.

Bu durum hizmet kalitesini düşürebilir veya maliyetleri artırabilir.

Risk örnekleri

Çok sayıda eşzamanlı model isteği.

Aşırı uzun girdiler.

Gereksiz tekrar eden araç çağrıları.

Kontrolsüz token tüketimi.

Uzun süreli agent iş akışları.

Korunma yöntemleri

Rate limiting uygulanmalıdır.

Kullanıcı bazlı kota belirlenmelidir.

Token ve maliyet limitleri tanımlanmalıdır.

Araç çağrısı sayısı sınırlandırılmalıdır.

İstek zaman aşımı politikaları oluşturulmalıdır.

Anormal kullanım davranışları izlenmelidir.

Bu kontroller hem güvenlik hem de operasyonel sürdürülebilirlik açısından önemlidir.

18. Model Denial of Service ile Geleneksel DDoS Arasındaki Fark

Geleneksel DDoS saldırılarında hedef çoğunlukla ağ veya uygulama kaynaklarını yoğun trafikle tüketmektir.

LLM sistemlerinde ise saldırgan modelin hesaplama maliyetini artıran isteklerden yararlanabilir.

Örneğin çok uzun bağlamlar veya tekrar eden model işlemleri yüksek kaynak tüketimi oluşturabilir.

Bu durum her zaman klasik ağ seviyesinde DDoS şeklinde görünmeyebilir.

Dolayısıyla yalnızca firewall veya WAF kontrolleri yeterli olmayabilir.

Uygulama seviyesinde model kullanım politikaları da gereklidir.

Örneğin kullanıcı başına token kotası ve eşzamanlı istek limiti uygulanabilir.

19. Model Extraction ve Model Theft

Model Extraction, bir modelin davranışının veya işlevinin yetkisiz biçimde çıkarılmasına yönelik girişimleri ifade eder.

Model Theft ise modelin kendisinin veya değerli özelliklerinin yetkisiz elde edilmesiyle ilişkili daha geniş bir kavramdır.

Bu riskler özellikle ticari olarak geliştirilen veya özel verilerle özelleştirilen modeller için önemlidir.

Örneğin saldırgan bir modele çok sayıda sorgu göndererek davranışını taklit eden başka bir sistem oluşturmaya çalışabilir.

Ancak bu tür saldırıların başarısı modelin erişim biçimine, koruma mekanizmalarına ve saldırganın kaynaklarına bağlıdır.

Korunma yöntemleri

API erişimi kimlik doğrulama ile korunmalıdır.

Rate limiting uygulanmalıdır.

Anormal sorgu davranışları izlenmelidir.

Model dosyalarına erişim sınırlandırılmalıdır.

Model ve altyapı erişimleri kayıt altına alınmalıdır.

Bu kontroller fikri mülkiyetin korunmasına da katkı sağlayabilir.

20. Training Data Extraction

Training Data Extraction, modelin eğitim verilerinde bulunan belirli bilgilerin çıktılar üzerinden elde edilmeye çalışılmasıyla ilişkili riskleri ifade eder.

Bu risk her modelde aynı seviyede değildir.

Modelin eğitim yöntemi, veri içeriği ve kullanım biçimi önemlidir.

Özellikle hassas verilerin model eğitimi veya fine-tuning süreçlerinde kullanılması durumunda veri koruma kontrolleri gereklidir.

Güvenli yaklaşım

Eğitim verileri sınıflandırılmalıdır.

Gereksiz kişisel veriler kullanılmamalıdır.

Veri kullanım yetkileri doğrulanmalıdır.

Uygun gizlilik ve veri minimizasyonu yöntemleri değerlendirilmelidir.

Model çıktılarında hassas bilgi ifşası test edilmelidir.

Bu yaklaşım model güvenliği ile veri koruma yönetimini birleştirir.

21. LLM Supply Chain Güvenliği

LLM uygulamaları çok sayıda üçüncü taraf bileşen kullanabilir.

Örneğin:

Model dosyaları.

Tokenizer bileşenleri.

Inference framework'leri.

Python paketleri.

Container image'ları.

Vector database sistemleri.

Model serving servisleri.

Harici API sağlayıcıları.

Bu bileşenlerin her biri tedarik zinciri güvenliği açısından değerlendirilmelidir.

Güvenilir model kaynağı

Modelin hangi kaynaktan temin edildiği doğrulanmalıdır.

Model bütünlüğü

Uygun mekanizmalarla model dosyalarının bütünlüğü kontrol edilmelidir.

Dependency güvenliği

Üçüncü taraf yazılım bileşenleri SCA kontrollerine dahil edilmelidir.

Güvenli model yükleme

Model dosyalarının yüklenmesi sırasında kullanılan mekanizmalar değerlendirilmelidir.

Güncelleme yönetimi

Model serving altyapısı ve ilgili bileşenlerin güvenlik güncellemeleri takip edilmelidir.

22. LLM Güvenliğinde Logging ve Monitoring

LLM uygulamalarının güvenli işletilmesi için uygun izleme ve kayıt mekanizmaları gereklidir.

Ancak loglama yapılırken hassas verilerin gereksiz biçimde kaydedilmemesine dikkat edilmelidir.

Örneğin bütün kullanıcı prompt'larının açık metin olarak saklanması veri koruma açısından yeni riskler oluşturabilir.

Bu nedenle loglama politikası risk bazlı tasarlanmalıdır.

İzlenebilecek olaylar

Başarısız authentication girişimleri.

Yetkisiz araç çağrıları.

Anormal model kullanım hacmi.

Yüksek token tüketimi.

Kritik işlem onayları.

Güvenlik politikası ihlalleri.

Şüpheli veri erişimleri.

Güvenli loglama

Hassas veriler uygun şekilde maskelenmelidir.

Log erişimleri sınırlandırılmalıdır.

Saklama süreleri belirlenmelidir.

Audit kayıtlarının bütünlüğü korunmalıdır.

Gerekli durumlarda SIEM veya SOC süreçlerine entegrasyon sağlanabilir.

23. LLM Security Testing Nedir?

LLM Security Testing, büyük dil modellerini kullanan uygulamaların güvenlik risklerinin sistematik biçimde değerlendirilmesidir.

Bu testler yalnızca modelin verdiği cevapların incelenmesiyle sınırlı değildir.

Uygulamanın mimarisi, veri erişimleri, araç entegrasyonları ve güvenlik kontrolleri de değerlendirilmelidir.

Test kapsamı

Prompt Injection dayanıklılığı.

Hassas veri ifşası.

System Prompt Leakage.

Yetkisiz araç çağrıları.

RAG erişim kontrolü.

Güvensiz çıktı işleme.

Kaynak tüketimi.

Model ve dependency güvenliği.

Test yaklaşımı

Öncelikle uygulamanın mimarisi anlaşılmalıdır.

Ardından güven sınırları belirlenmelidir.

Modelin erişebildiği veri ve araçlar envantere alınmalıdır.

Risk bazlı test senaryoları hazırlanmalıdır.

Bulguların gerçek sistem etkisi doğrulanmalıdır.

Son olarak düzeltme önerileri ve retest gerçekleştirilmelidir.

24. LLM Pentest ile Geleneksel Pentest Arasındaki Fark

Geleneksel pentest web, mobil, API, ağ ve sistem bileşenlerindeki güvenlik açıklarını değerlendirebilir.

LLM Pentest ise bunlara ek olarak model davranışını ve yapay zekâya özgü saldırı yüzeylerini ele alır.

Örneğin geleneksel pentest sırasında API authentication problemi tespit edilebilir.

LLM Pentest sırasında ise modelin bağlı olduğu araçları yetkisiz biçimde kullanmaya çalışması test edilebilir.

Ancak iki yaklaşım birbirinin alternatifi değildir.

Kritik yapay zekâ uygulamalarında birlikte kullanılması daha kapsamlı güvenlik görünürlüğü sağlayabilir.

25. LLM Güvenliğinde Defense in Depth

LLM uygulamalarında tek bir güvenlik kontrolüne güvenilmemelidir.

Katmanlı güvenlik yaklaşımı uygulanmalıdır.

Örneğin:

Kimlik Doğrulama

Kullanıcının kimliği doğrulanır.

Yetkilendirme

Veri ve işlem erişimleri sınırlandırılır.

Veri Güvenliği

Hassas veri kullanımı kontrol edilir.

Prompt ve Model Güvenliği

Güvenilmeyen içeriklerin etkisi azaltılmaya çalışılır.

Araç Güvenliği

Tool Calling yetkileri sınırlandırılır.

Çıktı Güvenliği

Model çıktıları kullanılacakları bağlama göre doğrulanır.

İzleme

Kritik işlemler ve anormal davranışlar takip edilir.

Sürekli Test

Güvenlik değerlendirmeleri düzenli olarak tekrarlanır.

Bu katmanlar birlikte çalıştığında tek bir kontrolün başarısızlığı daha sınırlı etkiye sahip olabilir.

26. AI Gateway ve LLM Güvenliği

AI Gateway, yapay zekâ uygulamaları ile model servisleri arasındaki iletişimin merkezi güvenlik ve yönetim politikaları altında yürütülmesini sağlayabilir.

Örneğin bir kurum farklı LLM servislerini kullanıyor olabilir.

Bazı uygulamalar bulut tabanlı modellerden yararlanır.

Bazıları kurum içi modeller kullanır.

Bazıları ise farklı sağlayıcılar arasında geçiş yapar.

Bu durumda merkezi görünürlük ve politika yönetimi önem kazanır.

AI Gateway çözümleri ürün yeteneklerine bağlı olarak:

Kimlik ve erişim kontrolü.
Model kullanım politikaları.
Hassas veri tespiti.
Veri maskeleme.
Prompt güvenlik kontrolleri.
Model yönlendirme.
Kullanım izleme.
Audit logging.
Maliyet ve kota yönetimi.

gibi özellikler sunabilir.

Ancak AI Gateway bütün güvenlik risklerini tek başına ortadan kaldırmaz.

Örneğin backend authorization problemi veya güvensiz API entegrasyonu ayrıca düzeltilmelidir.

27. Kurumsal LLM Güvenlik Politikası Nasıl Oluşturulur?

Kurumsal LLM Security Policy, yapay zekâ uygulamalarının hangi güvenlik kuralları altında kullanılacağını tanımlar.

Bu politika hem teknik hem de organizasyonel kontrolleri içermelidir.

Model seçimi

Kullanılacak model ve sağlayıcılar değerlendirilmelidir.

Veri paylaşımı

Hangi veri türlerinin modele gönderilebileceği belirlenmelidir.

Erişim yönetimi

Kullanıcı, servis ve araç yetkileri tanımlanmalıdır.

Güvenlik testleri

LLM uygulamaları risk seviyelerine göre test edilmelidir.

İzleme

Kritik işlemler ve güvenlik olayları kayıt altına alınmalıdır.

Değişiklik yönetimi

Model, prompt, veri kaynağı ve araç değişiklikleri güvenlik etkisi açısından değerlendirilmelidir.

Olay müdahalesi

LLM uygulamalarına özgü güvenlik olayları için müdahale süreçleri oluşturulmalıdır.

Bu politika kurumun AI Governance programının bir parçası olabilir.

28. Örnek Senaryo: Finansal LLM Asistanı

Bir finans kuruluşunun çalışanları için LLM tabanlı raporlama asistanı geliştirdiğini düşünelim.

Asistan finansal raporları özetlemektedir.

Ayrıca belirli veritabanı sorgularını gerçekleştirebilmektedir.

İlk aşamada sistem yalnızca bilgi sunmaktadır.

Ancak zamanla yeni araçlar eklenir.

Örneğin rapor dışa aktarma ve e-posta gönderme özellikleri sisteme dahil edilir.

Bu durumda güvenlik riskleri artabilir.

Risk 1: Yetkisiz veri erişimi

Çalışan erişim yetkisi olmayan finansal raporları sorgulayabilir.

Risk 2: Prompt Injection

Sistemin okuduğu bir doküman model davranışını manipüle etmeye çalışabilir.

Risk 3: Güvensiz araç kullanımı

Model beklenmeyen alıcılara rapor göndermeyi önerebilir.

Risk 4: Veri sızıntısı

Hassas finansal bilgiler harici model servisine gereksiz biçimde aktarılabilir.

Risk 5: Yetersiz izleme

Kritik rapor erişimleri kayıt altına alınmıyor olabilir.

Önerilen güvenlik yaklaşımı

Kullanıcı bazlı erişim kontrolü uygulanmalıdır.

Veri kaynakları yetkilendirilmelidir.

Araç çağrıları sınırlandırılmalıdır.

Hassas veri aktarımı kontrol edilmelidir.

Kritik işlemler için onay mekanizması değerlendirilmelidir.

Güvenlik testleri ve izleme süreçleri oluşturulmalıdır.

Bu örnek LLM güvenliğinin yalnızca model cevabını kontrol etmekten ibaret olmadığını gösterir.

29. SECURESYS LLM Güvenliği Yaklaşımı

SECURESYS olarak LLM güvenliğinin geleneksel uygulama güvenliğinden bağımsız değerlendirilmemesi gerektiğini düşünüyoruz.

Çünkü büyük dil modelleri gerçek iş süreçlerine bağlandıkça klasik uygulama güvenliği problemleriyle daha fazla etkileşime girer.

Örneğin bir LLM uygulamasında Prompt Injection riski bulunabilir.

Ancak aynı uygulamanın API yetkilendirmesi de hatalı olabilir.

Modelin kullandığı RAG veri kaynağında tenant izolasyonu eksik olabilir.

Veya Tool Calling entegrasyonu gereğinden fazla yetkiyle çalışabilir.

Bu nedenle güvenlik değerlendirmesi bütün uygulama mimarisini kapsamalıdır.

Proje ihtiyaçlarına göre aşağıdaki güvenlik alanları birlikte ele alınabilir:

LLM Security Assessment

Model davranışlarının ve uygulama güvenlik kontrollerinin değerlendirilmesi.

Prompt Injection Testing

Güvenilmeyen içeriklerin model davranışına etkisinin incelenmesi.

Data Leakage Assessment

Hassas veri erişimi ve aktarım risklerinin değerlendirilmesi.

API Security Testing

LLM uygulamasının bağlı olduğu servislerin güvenlik kontrollerinin incelenmesi.

AI Agent Security

Tool Calling, MCP ve ajan yetkilendirme mekanizmalarının değerlendirilmesi.

RAG Security

Kurumsal bilgi kaynakları ve belge erişim kontrollerinin incelenmesi.

Source Code Security

Uygulama kaynak kodunun SAST ve manuel analiz yöntemleriyle değerlendirilmesi.

AI Gateway Architecture

Merkezi politika, veri koruma ve model kullanım kontrollerinin tasarlanması.

Bu yaklaşımın temel amacı yalnızca güvenlik açıklarını bulmak değildir.

Kurumun LLM uygulamalarını daha kontrollü ve güvenli biçimde geliştirmesine yardımcı olmaktır.

Çünkü güçlü bir model tek başına güvenli bir uygulama oluşturmaz.

Güvenli LLM uygulaması; doğru mimari, doğru yetkilendirme ve sürekli güvenlik kontrolleriyle oluşturulur.

30. LLM Güvenliği Kontrol Listesi

Kurumsal LLM uygulamaları için aşağıdaki kontrol listesi başlangıç noktası olarak kullanılabilir.

Mimari güvenlik

Model ve uygulama bileşenleri envantere alındı mı?
Güven sınırları belirlendi mi?
Harici veri kaynakları değerlendirildi mi?
Araç entegrasyonları belgelendi mi?

Kimlik ve erişim

Kullanıcı kimliği doğrulanıyor mu?
Veri erişimi kullanıcı yetkilerine göre sınırlandırılıyor mu?
Araç çağrıları bağımsız yetkilendirmeden geçiyor mu?
Tenant izolasyonu sağlanıyor mu?

Veri güvenliği

Hassas veriler sınıflandırıldı mı?
Model sağlayıcısının veri işleme koşulları değerlendirildi mi?
Gereksiz veri aktarımı engelleniyor mu?
Loglarda hassas veri korunuyor mu?

Model ve prompt güvenliği

Prompt Injection senaryoları test edildi mi?
System Prompt Leakage değerlendirildi mi?
Güvenilmeyen dokümanlar uygun şekilde ele alınıyor mu?
Model çıktıları güvenli biçimde işleniyor mu?

Operasyonel güvenlik

Rate limiting uygulanıyor mu?
Token ve maliyet limitleri var mı?
Anormal kullanım izleniyor mu?
Kritik işlemler kayıt altına alınıyor mu?
Güvenlik olaylarına müdahale planı bulunuyor mu?

Güvenlik testleri

LLM Security Testing yapıldı mı?
API güvenliği değerlendirildi mi?
RAG erişim kontrolleri test edildi mi?
Tool Calling yetkileri incelendi mi?
Kritik bulgular için retest uygulandı mı?

Bu kontrol listesi kurumun kullanım senaryosuna ve risk seviyesine göre genişletilebilir.

Sık Sorulan Sorular

LLM güvenliği nedir?

LLM güvenliği, büyük dil modellerinin ve bu modelleri kullanan uygulamaların manipülasyon, veri sızıntısı, yetkisiz erişim ve diğer güvenlik risklerine karşı korunmasıdır.

LLM Security ile AI Security arasındaki fark nedir?

AI Security daha geniş bir alandır. LLM Security ise büyük dil modellerine ve bunları kullanan uygulamalara özgü güvenlik risklerine odaklanır.

Prompt Injection nedir?

Prompt Injection, güvenilmeyen içeriklerin modelin davranışını değiştirmek amacıyla talimat gibi kullanılmasını hedefleyen saldırı yaklaşımıdır.

Jailbreak nedir?

Jailbreak, modelin davranış veya güvenlik kısıtlamalarını aşmaya yönelik girişimleri ifade eder.

System Prompt Leakage nedir?

System Prompt Leakage, modelin sistem veya geliştirici talimatlarının bazı bölümlerini yetkisiz biçimde açıklaması riskidir.

LLM veri sızıntısı nasıl oluşur?

Yetkisiz veri erişimi, aşırı veri paylaşımı, güvensiz araç entegrasyonları veya model çıktılarında hassas bilgi ifşası gibi nedenlerle oluşabilir.

LLM çıktıları güvenilir midir?

Model çıktıları kullanılacakları bağlama göre doğrulanmalıdır. Özellikle SQL, HTML, komut veya API işlemlerinde doğrudan güvenilir kabul edilmemelidir.

LLM Pentest nedir?

LLM Pentest, büyük dil modeli kullanan uygulamaların güvenlik risklerinin gerçekçi saldırı senaryolarıyla değerlendirilmesidir.

LLM güvenliği için WAF yeterli midir?

Hayır. WAF bazı geleneksel web saldırılarına karşı koruma sağlayabilir ancak LLM'ye özgü bütün riskleri tek başına kapsamaz.

AI Gateway LLM güvenliğini sağlar mı?

AI Gateway belirli güvenlik ve yönetim kontrollerini merkezi hale getirebilir. Ancak uygulama yetkilendirmesi, veri erişimi ve güvenli kodlama gibi diğer kontrollerin yerine geçmez.

LLM uygulamalarında RAG güvenliği neden önemlidir?

RAG sistemleri harici bilgi kaynaklarını kullanır. Bu nedenle belge yetkilendirmesi, veri izolasyonu ve güvenilmeyen içeriklerin yönetimi kritik önem taşır.

LLM güvenliği için ISO/IEC 42001 yeterli midir?

ISO/IEC 42001 yapay zekâ yönetim sistemine yönelik bir standarttır. Teknik LLM güvenlik testlerinin yerine geçmez.

LLM güvenlik testleri ne sıklıkla yapılmalıdır?

Test sıklığı uygulamanın kritik seviyesine, değişikliklere ve risklere göre belirlenmelidir. Model, prompt, veri kaynağı veya araç değişiklikleri ek değerlendirme gerektirebilir.