Pratik Threat Model: Bir RAG Asistanı
Hayali ama gerçekçi bir kurumsal RAG asistanını adım adım threat-model eden uygulamalı oda. Sistem ayrıştırma → tehdit bulma → kontrol atama.
Pratik Tehdit Modeli (Threat Model): Bir RAG Asistanı
Önceki odada STRIDE metodolojisini, OWASP listesini ve MITRE ATLAS çerçevelerini teorik olarak tanıdık. Şimdi bu teorileri hayali ama son derece gerçekçi bir kurumsal RAG (Retrieval-Augmented Generation) asistanı üzerinde uygulayacağız. Bu oda bir bilgi dökümü değil, adım adım uygulamalı bir vaka egzersizidir.
Senaryomuz: Büyük bir hukuk bürosu, iç çalışanlarının (avukatların) kullanması için "LegalGPT" adında bir yapay zeka asistanı kurmaya karar verir. Asistan, firmanın geçmiş 50.000 sayfalık sözleşme arşivi ve müvekkil kayıtları üzerinden arama ve özetleme yapacaktır.
Siber Güvenlik Mimarı olarak görevimiz bu sistemi Tehdit Modellemesine (Threat-Model) tabi tutmaktır. Başlıyoruz.
Adım 1: Sistemi Ayrıştır (DFD Çıkarma)
Tehdit modellemenin ilk adımı her zaman aynıdır: Sistemi kuş bakışı bir Veri Akış Diyagramına (Data Flow Diagram - DFD) dökmek, bileşenleri ve Güven Sınırlarını (Trust Boundaries) çizmektir.
Güven Sınırları (Trust Boundaries - TB):
- TB1: Kullanıcı ↔ Ağ Geçidi (Kimlik doğrulama sınırıdır).
- TB2: Orkestratör ↔ Vektör DB (DB'ye dışarıdan kim, hangi yetkiyle veri yüklüyor?).
- TB3: LLM ↔ E-posta Aracı (Modelin düşünmekten çıkıp fiziksel eyleme geçtiği sınırdır).
- TB4: E-posta Aracı ↔ SMTP (Şirket içi sistemden dış dünyaya çıkış sınırıdır).
Adım 2: Her Bileşen İçin STRIDE Turlaması
Şimdi DFD'deki kritik bileşenlere "S, T, R, I, D, E" sorularını yöneltiyoruz.
Bileşen: AI Ağ Geçidi (Gateway)
| STRIDE Harfi | Kategori | Spesifik Tehdit Senaryosu |
|---|---|---|
| S | Spoofing (Kimlik Sahtekarlığı) | Sızdırılmış bir API anahtarı ile yetkili bir avukatın kimliğine bürünme. |
| T | Tampering (Veri Kurcalama) | Ağdaki trafiği (prompt'u) araya girip değiştirme (TLS eksikse). |
| R | Repudiation (İnkar Etme) | Bir avukatın "O kritik maili ben yazdırmadım" demesi (Log eksikliği). |
| I | Info Disclosure (Bilgi İfşası) | Ağ geçidi loglarının şifresiz tutulması sonucu tüm avukat-müvekkil konuşmalarının IT ekibine sızması. |
| D | Denial of Service (Hizmet Reddi) | Kötü niyetli bir çalışanın saniyede binlerce istek atarak şirketin tüm token bütçesini tüketmesi. |
| E | Elevation of Privilege (Yetki Yükseltme) | Yanlış yapılandırılmış RBAC yüzünden standart bir stajyerin Yönetici (Admin) fonksiyonlarını çağırması. |
Bileşen: Vektör Veritabanı (RAG Merkezi)
| STRIDE Harfi | Spesifik Tehdit Senaryosu |
|---|---|
| S (Spoofing) | Vektör DB'ye kimlik doğrulaması olmadan dışarıdan sahte bir sorgu atılması. |
| T (Tampering) | RAG Poisoning (RAG Zehirlenmesi) — Saldırganın DB'ye zararlı talimat içeren bir sözleşme sızdırması. |
| R (Repudiation) | DB'ye zehirli belgeyi kim, ne zaman ekledi? (Denetim izi yoksa bulunamaz). |
| I (Info Disclosure) | Vektör Inversion saldırısıyla sayılardan ibaret olan veritabanı dump'ının orijinal sözleşme metinlerine çevrilmesi. |
| D (DoS) | Vektör veritabanını yoğun ve karmaşık vektör sorgularıyla kilitleyip çökertme. |
| E (Elevation) | Çapraz Kiracı Sızıntısı: Müvekkil A'ya ait gizli bir sözleşmenin, Müvekkil B'nin dosyasına bakan bir avukata RAG tarafından sunulması. |
Bileşen: Yapay Zeka Modeli (LLM)
| STRIDE Harfi | Spesifik Tehdit Senaryosu |
|---|---|
| T (Tampering) | Dolaylı (Indirect) PI — Hukuk sözleşmesinin içine gizlenmiş beyaz metinlerle modelin manipüle edilmesi. |
| I (Info Disclosure) | Sistem İstemi Sızıntısı (System Prompt Extraction) ve geçmiş eğitim verisi ifşası. |
| D (DoS) | Sonsuz döngü yaratan karmaşık promptlarla (Many-shot, recursion) API işlem süresinin ve bütçesinin kilitlenmesi. |
| E (Elevation) | Jailbreak saldırısıyla modelin "Kibar Asistan" yerine "Kuralsız Geliştirici" moduna geçirilip tüm sınırların aşılması. |
Bileşen: Araç (send_email)
| STRIDE Harfi | Spesifik Tehdit Senaryosu |
|---|---|
| S (Spoofing) | Asistanın, avukatın onayı olmadan müvekkil adına sahte bir e-posta üretip göndermesi. |
| T (Tampering) | Hazırlanan e-posta içeriğinin Indirect PI ile değiştirilip müvekkile yanlış hukuki bilgi veya oltalama linki gönderilmesi. |
| I (Info Disclosure) | Atılan e-postanın içerisine yanlışlıkla başka bir müvekkile ait kimlik bilgisinin (TCKN) karışması. |
| E (Elevation) | "Sadece şirket içine mail atabilir" kuralının atlatılarak kurum dışındaki bir saldırgan hesabına mail (veri) çıkarılması. |
Adım 3: OWASP + ATLAS Haritalaması
STRIDE ile bulduğumuz bu spesifik tehditleri, sektörün ortak dili olan standart taksonomilere yerleştiriyoruz:
| Tespit Edilen Tehdit | İlgili OWASP Maddesi | MITRE ATLAS Taktiği |
|---|---|---|
| API Anahtarı Sızıntısı | (Klasik Web Zafiyeti) | Initial Access (İlk Erişim) |
| RAG Zehirlenmesi (Poisoning) | LLM01 (Indirect), LLM03 | Resource Development |
| Çapraz Kiracı (Cross-tenant) İfşası | LLM06 | Collection |
| Sistem İstemi Sızdırma | LLM01 + LLM06 | Discovery |
| Sahte/Yetkisiz E-posta | LLM02 + LLM08 | Execution / Exfiltration |
| Token / Maliyet Tüketimi (DoS) | LLM04 | Impact (Etki) |
| Müvekkil Verisi Sızıntısı | LLM06 | Exfiltration |
Adım 4: Risk Önceliklendirme (DREAD-Lite)
Yukarıda yaklaşık 20+ potansiyel tehdit bulduk. Tüm bunları aynı anda çözmek imkansızdır. Kaynaklarımızı risk skoruna (Risk = Hasar x Olasılık) göre önceliklendireceğiz.
Hızlı bir skorlama tablosu (1-5 Ölçeği):
| Tehdit | Hasar Potansiyeli | Gerçekleşme Olasılığı | Toplam Skor |
|---|---|---|---|
| RAG Zehirlenmesi → Müvekkil Verisi Sızıntısı | 5 (Kritik) | 4 (Yüksek) | 20 |
| Sistem İstemi (System Prompt) Sızıntısı | 4 | 5 (Çok Yüksek) | 20 |
| Çapraz Kiracı (Farklı Dava) Verisi İfşası | 5 (Kritik) | 3 | 15 |
| Asistan Adına Yetkisiz Dış E-posta | 5 (Kritik) | 3 | 15 |
| Maliyet / Token Tüketim Saldırısı (DoS) | 3 | 3 | 9 |
Bir Hukuk Bürosu için Bilgi İfşası (Information Disclosure) her zaman en yüksek skoru alır. KVKK/GDPR cezaları, baro soruşturmaları, müvekkil güveninin kaybı; bunların hepsi büro için doğrudan yıkım (Impact) demektir.
Adım 5: Tehditlere Kontrol Atama (Mitigation)
Sadece sorunları bulmak yetmez; önceliklendirdiğimiz tehditlere birer Savunma Kontrolü (Mitigation) atamalıyız. Her kontrol uygulanabilir olmalı ve sorumlu bir birime (Sahip) zimmetlenmelidir:
| Hedeflenen Tehdit | Savunma Kontrolü (Mitigation) | Sorumlu Birim (Sahip) |
|---|---|---|
| RAG Zehirlenmesi | Vektör DB'ye belge yükleme işlemi sıkı RBAC korumasına alınacak. | DevOps / IAM Ekibi |
| RAG Zehirlenmesi | LLM bağlamına (Context) giren Vektör DB belgeleri "Pasif Veri (Untrusted)" olarak etiketlenecek. | LLM Geliştiricisi |
| Sistem İstemi Sızıntısı | Hardened (Sıkılaştırılmış) System Prompt + Çıktıda Regex Maskeleme + LLM Judge entegrasyonu. | AI Güvenlik Mimarı |
| Çapraz Kiracı Sızıntısı | Vektör DB'de dava/müşteri numarasına göre Satır Bazlı Güvenlik (Row-level Security) filtresi konulacak. | Veritabanı Yöneticisi (DBA) |
| Yetkisiz E-posta (LLM08) | send_email aracı için Beyaz Liste (Sadece @firma.com.tr) ve zorunlu İnsan Onayı (HITL) şartı eklenecek. | Backend Geliştiricisi |
| Maliyet (Token) Saldırısı | AI Ağ Geçidinde (Gateway) kullanıcı bazlı saatlik/aylık Token Kotası devreye alınacak. | Finans + DevOps |
Adım 6: Çıktıyı Dokümante Et
Tehdit modellemesinin nihai çıktısı yaşayan bir dokümandır. Ekibin anlayabileceği standart bir yapı şu bölümlerden oluşur:
- Sistem Özeti ve Mimarisi (DFD).
- Tanımlanan Güven Sınırları (Trust Boundaries).
- STRIDE Bileşen Matrisi.
- OWASP / ATLAS Haritalaması.
- Risk Önceliklendirme Skoru.
- Uygulanacak Kontroller (Mitigations), Sorumluları ve Termin Tarihleri.
- Açık Riskler (Kabul edilen ve göze alınan riskler).
Bu doküman rafta tozlanmak için yapılmaz. Sisteme yeni bir özellik (Örn: Sesli asistan özelliği) eklendiğinde bu doküman açılır ve model güncellenir.
Sahada Sık Tekrar Eden Tuzaklar (Kaçının)
- STRIDE'a Ezbere Bağlanmak: "Her harfi her bileşene mutlaka uydurmalıyım" diye düşünmeyin. Mantıksız veya anlamsız olanı atlayın.
- Önceliklendirme (Skor) Yapmamak: "Bu 50 tehdidin hepsi çok önemli, hemen çözmeliyiz" derseniz hiçbirini çözemezsiniz. Mühendislik eforu sınırlıdır, en kritikten başlayın.
- Sahipsiz (Zimmetsiz) Kontroller: "Bütün veriler şifrelenmeli" yazıp bırakırsanız o iş yapılmaz. "Kim, ne zaman, hangi yöntemle şifreleyecek?" bunu belirleyin.
- "Tek Atımlık" Zihniyet: Tehdit modelini proje başında bir kez yapıp bir daha yüzüne bakmamak. Mimariler değişir, saldırılar evrilir; tehdit modeliniz de evrilmelidir.
Bölüm Özeti
- Tehdit Modellemesi (Threat Modeling) 6 adımlı analitik bir süreçtir: Ayrıştır → STRIDE Uygula → Eşleştir → Puanla → Kontrol Ata → Dokümante Et.
- Kurumsal bir LLM uygulamasında en yüksek siber güvenlik riskini genellikle Bilgi İfşası (Information Disclosure - LLM06 ve LLM01) taşır.
- Kontrollerin bir Sahibi ve Termin Tarihi olmazsa, tehdit modeliniz sadece süslü bir kağıt parçası olarak kalır.
Sıradaki Modül: Artık yapay zeka sistemlerinin nasıl tasarlandığını ve kağıt üzerinde nasıl güvenli hale getirileceğini biliyoruz. Şimdi sahaya inip Üretim Ortamı Savunma Desenlerine (Production Patterns) geçiyoruz. OWASP LLM02 (Güvensiz Çıktı) ve LLM07 (Güvensiz Eklenti) zafiyetlerini kod seviyesinde nasıl engelleyeceğimizi göreceğiz.
Görevler
-
01Threat modeling sürecinin **birinci adımı** genelde hangisidir?15 P
-
02Threat modeling pratiğinde, her tehdide karşılık atadığımız azaltma/önleme mekanizmasına ne ad verilir? (tek kelime, İngilizce veya Türkçe)15 P
-
03DREAD veya CVSS gibi skorlama sistemlerinin threat modeling'deki temel amacı nedir?15 P
-
04Bir kurumsal RAG asistanında **en yüksek riskli** STRIDE kategorisi genellikle hangisidir?15 P