Yapay Zeka Altyapısında Zero Trust (Sıfır Güven) Mimarisini Kurgulamak

Modern işletmelerin büyük bir çoğunluğu, açık kaynaklı yapay zeka modellerini veya devasa RAG (Retrieval-Augmented Generation) mimarilerini kurumsal iç ağlarına büyük bir iştahla entegre ediyor. Veritabanlarına doğrudan bağlanan bu yapay zeka asistanları inanılmaz derecede verimli olmakla birlikte, ağ güvenliği açısından saatli birer bombadır.

Eğer bir yapay zeka modeli (LLM) dışarıdan Prompt Injection saldırısıyla ele geçirilirse (Jailbroken), o model artık kullanıcının esiri olur. Eğer şirketinizin ağ mimarisi geniş ve esnekse, LLM içine sızan bir saldırgan modeli adeta bir köprü gibi (Pivot noktası) kullanarak diğer iç sunucularınıza atlayabilir. İşte tam bu noktada siber güvenliğin en tartışılmaz konsepti devreye girer: Yapay Zeka için Zero Trust (Sıfır Güven) Mimarisi.

---

1. Zero Trust (Sıfır Güven) Nedir?

Geleneksel ağ güvenliği bir kaleye benzerdi: Dışarıda kalın bir güvenlik duvarı vardır (Firewall), ancak duvardan içeri bir kere girdiğinizde içerideki herkesin birbirine güveni tamdır. Fakat yapay zekanın olduğu yerde bu felsefe fatal (ölümcül) bir hatadır.

Sıfır Güven (Zero Trust) yaklaşımı şuna dayanır: Hiç kimseye, cihazın veya ağın konumuna bakmaksızın güvenme. Şirket içindeki bir sunucu diğer sunucuya bağlanmak istese bile her adımda kimliğini kanıtlamak zorundadır.

Makine öğrenimi sistemlerinde Zero Trust prensipleri:

• Kendi eğittiğiniz ve sunucunuzda çalışan AI modelini her zaman "Yabancı" ve "Tehdit Altında" kabul edin.
• AI ajanlarına sadece o anki isteği tamamlaması için gereken "minimum yetkiyi" verin (Least Privilege Principle).
• Bir siber vaka durumunda zararın büyümesini önlemek için uygulamaları mikro seviyede kafeslere hapsedin (Micro-segmentation).

---

2. LLM ve RAG Altyapılarında Sık Yapılan Tasarım Hataları

Uygulamalı sızma testlerimizde şirketlerin AI ağlarını kurarken düştükleri üç tipik hata tespit ettik:

A. Modeli Aynı Sunucuda (Monolithic) Tutmak

Geliştiriciler, Müşteri Hizmetleri uygulamasının backend kodları ile LLM'in Inference (tahmin/yanıt üretme) motorunu aynı sunucu veya aynı Linux makinesi üzerine kurarlar. Modelin içindeki Python kodu bir OS Command Injection veya Pickle RCE açığıyla manipüle edilirse, saldırgan ana sunucudaki tüm kullanıcılara erişir. Sistem Monolitik değil; tamamen ayrıştırılmış konteynerler (Docker/Kubernetes) içinde olmalıdır.

B. Vektör DB'ye Kök (Root) İzniyle Erişim

Bir RAG modeli oluştururken, uygulamanın Milvus veya Pinecone gibi vektör veritabanlarını sorgulaması gerekir. Yazılım ekipleri genellikle sisteme Root veya Admin DB yetkisi veren şifreyi gömerler. Model dışarıdan zehirlenir ve "Tüm veritabanı tablolarını sil" komutunu alırsa, bu işlem başarıyla gerçekleşir.

C. İnternet Erişiminin Açık Bırakılması

Kurum içindeki bir dökümanı özetlemekle görevli olan kapalı LLM nodu, çoğu zaman güncellemeleri çekebilmesi adına dış internete açık bırakılır. Başarılı bir Prompt Injection sonrasında, saldırgan LLM'i kendi komuta kontrol (C2) sunucusuna bağlayarak, okuduğu tüm özel dökümanları şirket dışına exfiltre (sızdırma) ettirebilir. Otonom yapay zekanın sadece belirlediğiniz spesifik API kapıları hariç dışarıyla tüm bağlantısı kesilmelidir.

---

3. Yapay Zeka Servislerini "Kafese Kapatmak" (Micro-Segmentation)

Yapay zeka operasyonlarını MLOps süreçlerine aktarırken Zero Trust mimarisinin kurulum adımları şunlardır:

1. Katı Ağ Politikaları (Network Policies): Eğer Kubernetes kullanıyorsanız Pod'lar arası network politikalarını sınırlandırın. AI Inference Pod'u sadece gelen porttan API dinlemeli, şirketin Active Directory'sine veya Faturalandırma veritabanı IP'lerine ping dahi atamamalıdır. Sadece yetkili mikroservislere konuşabilmelidir.
2. Dinamik Veri Erişim Maskeleri: LLM'e tüm veritabanı erişimini vermeyin. Veritabanından veriyi bir ara katman (Proxy veya Business Logic Katmanı) çeksin, hassas kişisel verileri (TC, Kredi kArtı) maskelesin (Data Redaction) ve ancak ondan sonra sadece özetleme/işleme amaçlı LLM motoruna göndersin.
3. Kalıcı (Persistent) Kimlik Doğrulama: LLM bir web eklentisi veya API çalıştırırken statik bir şifre (Hardcoded API Key) kullanmamalıdır. mTLS (Mutual TLS) ve kısa süreli JIT (Just-In-Time) token'lar kullanarak her bir mikro sorguda kimlik doğrulaması şart koşulmalıdır.

Sonuç

Yapay zeka modellerinin son kullanıcılarla esnek bir sohbet içinde olduğu gerçeği, güvenlik mimarisini de esnetmek zorunda olduğumuz anlamına gelmez. Tam aksine, algoritmaların ne zaman halüsinasyon göreceğini kestiremediğimiz bu ortamda, arka planda uygulanacak tavizsiz bir Sıfır Güven (Zero Trust) ağ politikası; modern işletmeleri siber fırtınalardan koruyan tek sigortadır. Eresus Security DevSecOps hizmetleriyle, kendi yapay zeka kafesinizi hemen inşa etmeye başlayın.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

• Model veya agent hangi ortamda çalışıyor?
• Hangi kullanıcı veya servis hesabı kullanılıyor?
• Hassas veri kaynakları ayrı etiketlenmiş mi?
• Model dosyası veya artefact kaynağı doğrulanmış mı?
• Yükleme anında kod çalıştırma riski var mı?
• Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
• Tool çağrıları ayrı loglanıyor mu?
• Kritik aksiyonlarda onay mekanizması var mı?
• Test ortamı production verisinden ayrılmış mı?
• Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

• Güvenilmeyen model dosyaları izole ortamda açılmalı.
• Model registry erişimi minimum yetkiyle çalışmalı.
• Hash, imza veya provenance bilgisi tutulmalı.
• Agent tool izinleri görev bazlı ayrılmalı.
• Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
• Prompt testleri runtime aksiyon testleriyle desteklenmeli.
• Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Operasyonel İnceleme Checklisti

• Model veya agent kaynağı doğrulandı mı?
• Tool izinleri minimum yetkiyle mi tanımlandı?
• Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
• Memory kalıcı talimat riskine karşı incelendi mi?
• Model artefact hash veya imza ile takip ediliyor mu?
• Yükleme işlemi sandbox içinde test edildi mi?
• Prompt testi runtime aksiyon testiyle desteklendi mi?
• MCP veya plugin server listesi çıkarıldı mı?
• Agent production API çağırıyorsa onay var mı?
• Veri sızıntısı senaryosu kontrollü denendi mi?
• Kapsam net yazıldı mı?
• Etkilenen varlık sahibi belli mi?
• Test ortamı production etkisinden ayrıldı mı?
• Kullanıcı rolleri doğru temsil ediliyor mu?
• Hassas veri sınıfı tanımlandı mı?
• Yetki sınırı teknik olarak doğrulandı mı?
• Log kaynağı ve saklama süresi belli mi?
• Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
• İş etkisi teknik etkiden ayrı açıklandı mı?
• Düzeltme sahibi belirlendi mi?
• Retest kriteri yazıldı mı?
• Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
• Monitoring veya alert tarafında görünürlük var mı?
• Olay müdahale adımı gerekiyorsa planlandı mı?
• Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?