Python ile AI Mikroservis Mimarisini Kurmak ve Güvenliğini Sağlamak (FastAPI Modeli)

Şirketinizin bünyesinde veri bilimciler (Data Scientists) tarafından eğitilmiş harika bir tahmin (prediciton) modeline veya kurum içi kullanım için ayağa kaldırdığınız açık kaynak Büyük Dil Modeline (LLM) sahip olabilirsiniz. Ancak bu modeli dış dünyaya, özellikle de üretim (Production) altyapısında sunmaya karar verdiğinizde işin "Siber Güvenlik" ve "Yazılım Mimarisi (Architecture)" boyutu baş döndürücü bir hal alır.

Genelde veri ekipleri modeli devasa bir Flask veya Django çatısı altında app.py içine gömerek monolitik bir sistem kurar. Bu en büyük teknolojik tuzağınızdır! AI işlemleri (Inference) devasa CPU/GPU yükü (Compute Bound) çeker. Normal web istekleri (I/O Bound) ile AI yükü aynı tek parça uygulamadayken bir siber saldırgan veya sadece aşırı trafik anında bile tüm sisteminiz kağıt kule gibi çöker (DDoS).

Temel Değerlendirme: Çözüm, yapay zeka modelinizi geri kalan API yapınızdan izole ederek Mikroservis Mimarisinde konumlandırmak ve asenkron yetenekleriyle performans artışı sunan Python FastAPI kütüphanesi ile sarmalamaktır. Bir model bir konteynerda (Dockerized Microservice) çalışırken, kullanıcı yetkilendirme (Auth Gateway) başka bir servisten yönetildiğinde; siber korsanların modelinizi tüketmesi veya aşırı yük bindirerek kaynaklarınızı tüketmesi (Resource Exhaustion) donanımsal ve mantıksal duvarlara (Rate Limiting) çarpacaktır.

---

1. Monolitik Modelden Mikroservis Modelinize Geçiş Neden Zorunludur?

Geleneksel web saldırılarının hedefinde veritabanından SQL ile şifre çalmak vardır, ancak yapay zeka sektörüne yönelecek hacker'ların ilk motivasyonu sisteminizin faturasını kabartmak veya uygulamanızı servis dışı (Denial of Service - DoS) bırakmaktır. LLM sorguları aşırı pahalıdır.

Eğer monolitik bir yapıda modeli çalıştırırsanız:

• Tek bir hacker, sonsuz döngüde karmaşık tahminler (predictions) sorarak makine kartınızı %100 yükte tutabilir. Web sitemindeki diğer kullanıcılar anında zaman aşımı (Timeout Error) yaşar.
• Modelde kullanılan eski bir Python kütüphanesinin (örneğin Pickle deserialization) yarattığı zafiyette tüm yetkiler ele geçtiğinde sadece model okuyucusu değil, tüm müşteri veri tabanına paralel sızma gerçekleştirilir. İzolasyon sıfırdır.

Çözüm: Asenkron FastAPI ve gRPC Ayrışımı

Modelinizi FastAPI kullanarak ayrı bir mikroservise gömün. Geleneksel HTTP üzerinden uzun süren hesaplamalar yerine mikroservisleri Redis Celery veya gRPC yapısı ile "olay güdümlü (Event Driven)" şeklinde haberleştirin. Gateway isteği alır, "Sıraya ekledim (202 Accepted)" der ve işlemi yapay zeka konteynerine devrederek kapıyı kilitler.

---

2. API Gateway ve AI Mikroservis Güvenliği Kuralları

Mimarinizi mikroservislere böldükten sonra güvenlik bariyerlerini (Hardening) devreye alma zamanı gelmiştir:

1. Katı Hız Sınırları (Throttling / Rate Limiting): FastAPI seviyesinde kullanıcıları saniyede değil "Sorguların CPU maliyetine" göre sınırlamanız gerekir (Token veya Timeout based Rate Limiting). Biri uzun ve anlamsız cümlelerle sunucuyu yormaya kilitlenirse Cloudflare (WAF) veya içerideki Nginx katmanından IP adresine gecikme (Tarpit) uygulanmalıdır.
2. Konteyner Düzeyi İzolasyon (AppArmor / Seccomp): Modelinizin olduğu (Dockerfile) container'da asla işletim sistemi seviyesinde "Root" yetkileri bulundurmayın. AI modelinin sadece belleği okuma yetkisi olsun, sisteme yeni bir kütüphane yazma veya yükleme yetkisi asla olmasın. Eğer Prompt Injection tarzı bir hileyle Python sunucusundan Remote Code Execution edilmek istenirse, sömürü kabuğu (Exploit Shell) container dışına çıkamasın.
3. Dahili İletişimi Maskelemek (mTLS): Mikroservisler arasındaki (Backend API -> AI Service) dikey iletişimi SSL şifrelemesi olmadan yürütmeyin. Kurum içi ağa (Internal Network) düşmüş bir korsan, LLM servisleri arasında giden gelen HTTP isteklerini dinleyerek anında kullanıcı verilerini çekebilir.

---

3. DevOps Sürecinde Test Edilebilir Mimari (Testable Architecture)

Eğer doğru Python mikroservis mimarisini kurarsanız, yapay zeka modelinin doğruluğunu (Quality) bozmadan güvenliğini (Security) otomatikleştirebilirsiniz. Pytest ile yazacağınız sınır testleri (Boundary Testing) devasa girdilerin (Large Inputs Payload) ve toksik promptların sisteme girip girmediğini daha CI/CD aşamasında ispatlayacaktır.

Modelinizin çalışması onun "GÜVENLİ" olduğu anlamına gelmez. Mimarideki çatlak sızıntıların, API zafiyetlerinin veya Bulut üzerindeki servis iletişimindeki eksiklerin analiz edilmesi, Sızma Testi uzmanları ve Cloud Security ekipleri tarafından incelenmelidir.

Eresus Security uzmanlarının Black Box ve White Box yaklaşımlarıyla donatılmış AppSec testlerinden destek almak için bize ulaşabilir, modellerinizin şirketinizin finansal veya veri bütünlüğünü tehdit etmesini önleyebilirsiniz.

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?