Yapay Zeka Kod Çalıştırma Ortamı Nasıl İzole Edilir?

Yazar: Deniz AltanYayın: 12 Eyl 2026Güncelleme: 12 Eyl 202614 dk Okuma

Yapay zeka kod çalıştırma ortamları; Docker konteynerleri, gVisor sandboxing ve sanal makineler kullanılarak izole edilir. Bu yöntemler sistem ve veri güvenliğini sağlar.

Yapay Zeka Kod Çalıştırma Ortamı Nasıl İzole Edilir? için öne çıkan görsel
Yapay Zeka Kod Çalıştırma Ortamı Nasıl İzole Edilir? için öne çıkan görsel

Yapay zeka kod çalıştırma ortamları; büyük dil modellerinin (LLM), otonom yapay zeka ajanlarının ve kod yorumlayıcıların (code interpreter) ürettiği dinamik kod parçacıklarının güvenli, izole ve kontrol edilebilir bir sandbox mimarisi içinde çalıştırılmasını zorunlu kılan kritik altyapılardır.

Üretken yapay zeka sistemlerinin yazılım geliştirme, veri analitiği ve otonom iş akışlarına entegre edilmesiyle birlikte, dinamik olarak üretilen kodların güvenli bir şekilde yürütülmesi altyapı mühendisleri ve teknik karar vericiler için öncelikli bir odak noktası haline gelmiştir. Büyük dil modelleri (LLM) tarafından üretilen Python, JavaScript, Bash veya SQL gibi betiklerin doğrudan ana sunucuda çalıştırılması; yetkisiz erişim, veri sızıntısı, kaynak tükenmesi ve uzaktan kod çalıştırma (RCE) gibi ciddi siber güvenlik açıklarına zemin hazırlar. İşletmelerin kurumsal verilerini, sunucu altyapılarını ve kullanıcı gizliliğini korumak adına yapay zeka kod çalıştırma ortamı nasıl izole edilir sorusu; Docker konteynerleri, gVisor sandboxing mekanizmaları, MicroVM mimarileri ve WebAssembly tabanlı modern güvenlik katmanlarının doğru tasarlanmasını gerektirir. Bu rehberde, yapay zeka ajanları ve kod yorumlayıcı sistemler için sıfır güven (Zero Trust) ilkelerine dayalı, kurumsal standartlarda yalıtılmış kod çalıştırma mimarilerinin nasıl kurulacağını inceliyoruz.

Yapay Zeka Kod Yürütme Güvenliği Neden Kritik Bir İhtiyaçtır?

Geleneksel yazılım mühendisliğinde yürütülen kodlar, geliştiriciler tarafından yazılır, statik kod analiz araçlarından (SAST/DAST) geçer ve denetimli test süreçlerinin ardından sunucu ortamına deploy edilir. Ancak yapay zeka ajanları (AI agents) ve LLM tabanlı kod yorumlayıcılar (code interpreter) devreye girdiğinde bu paradigma kökten değişir. Yapay zeka, kullanıcı promptlarına veya otonom görev zincirlerine bağlı olarak anlık ve öngörülemez kod blokları oluşturur. Üretilen kodun deterministik olmaması, her çalıştırma işleminin potansiyel bir bilinmeyen tehdit vektörü taşıdığı anlamına gelir.

Kurumsal sistemlerde yapay zekanın dinamik kod yürütmesine olanak tanımak, işletmelere üst düzey analitik yetenekler, otomatik raporlama ve yazılım geliştirme otomasyonu kazandırır. Bununla birlikte, gerekli güvenlik sınırları çizilmediğinde sunucu çekirdeği (kernel), dahili veritabanları, API anahtarları ve mikroservis iletişim hatları doğrudan hedef haline gelir. Sıfır güven (Zero Trust) felsefesi doğrultusunda, modelin ürettiği her komut satırı "kötü niyetli bir saldırgan tarafından yazılmış olabilecek kod" ciddiyetinde ele alınmalı ve mutlak bir izolasyon süzgecinden geçirilmelidir.

LLM Halüsinasyonları ve Kontrolsüz Kod Üretim Riskleri

Büyük dil modelleri olasılıksal mimarilerdir. Bu durum, modelin teknik olarak geçerli görünen ancak mantıksal veya operasyonel olarak yıkıcı olan kod parçacıkları üretmesine (halüsinasyon) yol açabilir. Örneğin, veri temizleme görevi verilen bir yapay zeka ajanı, dosya yolu hesaplamasında yaptığı bir hata neticesinde rm -rf / veya geçici dizin yerine kritik sistem dizinlerini silmeye çalışan bir Bash komutu üretebilir.

Halüsinasyon riski yalnızca yıkıcı komutlarla sınırlı değildir. Model, var olmayan harici kütüphaneleri yüklemeye çalışabilir (package hallucination), sonsuz döngüler (while True) veya aşırı bellek tüketen özyinelemeli (recursive) fonksiyonlar yazarak sunucuda hizmet reddine (Denial of Service - DoS) sebep olabilir. Ayrıca dolaylı prompt enjeksiyonu (Indirect Prompt Injection) saldırılarında, yapay zekanın okuduğu harici bir belgede gizlenen zararlı bir talimat, modelin kötü niyetli bir komut üretmesine neden olabilir. Bu nedenle, kodun niyetinden bağımsız olarak, çalışma ortamının bu komutların sisteme zarar vermesini fiziksel ve mantıksal olarak engellemesi gerekir.

Uzaktan Kod Çalıştırma (RCE) ve Veri Sızıntısı Tehditleri

Yapay zeka modellerinin dinamik kod yürütmesi, doğası gereği kontrollü bir Uzaktan Kod Çalıştırma (Remote Code Execution - RCE) işlevidir. Geleneksel siber güvenlikte RCE en kritik zafiyetlerden biri kabul edilirken, yapay zeka kod yorumlayıcı sistemlerinde bu zafiyet ürünün temel bir özelliği haline gelir. Bu durum, saldırganların prompt manipülasyonu yoluyla ortam değişkenlerini (ENV), bulut sağlayıcı meta veri uç noktalarını (http://169.254.169.254/latest/meta-data/) veya dosya sistemindeki hassas konfigürasyon dosyalarını okumaya çalışmasına olanak tanır.

İzole edilmemiş bir ortamda çalışan yapay zeka kodu, işletim sisteminin soket kütüphanelerini kullanarak harici bir komut-kontrol (C2) sunucusuna veri sızdırabilir (data exfiltration) veya yerel ağdaki diğer servisleri (Redis, PostgreSQL, dahili Kubernetes podları) tarayarak yatayda ilerleme (lateral movement) gerçekleştirebilir. Veri gizliliği, KVKK ve GDPR uyumluluğu açısından, kod çalıştırma ortamının hem ana makineden hem de kurumsal iç ağdan bütünüyle tecrit edilmesi yasal ve operasyonel bir zorunluluktur.

Adım Adım Yapay Zeka Kod Çalıştırma Ortamı İzolasyon Yöntemleri

Yapay zeka için izole bir çalışma alanı (sandbox) kurarken tek bir doğru yöntem bulunmamaktadır. Tercih edilecek teknoloji; güvenlik gereksinimlerine, sistemin milisaniye bazındaki başlatma süresi (cold start latency) toleransına, desteklenecek programlama dillerine ve altyapı maliyetine göre şekillenir. Sektör standardı olarak kabul edilen dört ana izolasyon metodolojisi aşağıda detaylandırılmıştır.

+-------------------------------------------------------------------------+
|                  YAPAY ZEKA KOD İZOLASYON SEVİYELERİ                    |
+-------------------+-----------------------------------------------------+
| Seviye 1: Docker  | Namespaces + cgroups (Paylaşımlı Linux Çekirdeği)   |
| Seviye 2: gVisor  | runsc Runtime (Kullanıcı Alanında Sanal Çekirdek)   |
| Seviye 3: MicroVM | KVM + Firecracker (Donanım Tabanlı Tam Yalıtım)     |
| Seviye 4: Wasm    | WebAssembly Sandbox (Deterministik Bytecode Alanı)  |
+-------------------+-----------------------------------------------------+

1. Docker Konteynerleri ile Temel İzolasyon (Hafif ve Hızlı)

Docker ve OCI (Open Container Initiative) uyumlu konteyner sistemleri, Linux çekirdeğinin iki temel özelliğine dayanır: namespaces (süreç, ağ, kullanıcı ve dosya sistemi yalıtımı) ve cgroups (CPU, bellek, I/O kaynak kısıtlaması). Yapay zeka kod çalıştırma senaryolarında Docker, son derece hızlı başlatma süreleri (genellikle 100-300 milisaniye) ve düşük bellek ayak izi sunması nedeniyle yaygın olarak kullanılır.

Ancak standart Docker çalışma zamanı (runc), ana makinenin Linux çekirdeğini (host kernel) doğrudan paylaşır. Bu durum, yapay zekanın ürettiği bir kodun çekirdekteki bilinen bir güvenlik açığını (örneğin Dirty COW veya use-after-free zafiyetleri) tetikleyerek konteyner dışına kaçmasına (container escape) yol açabilir. Bu nedenle standart Docker, tek başına çok kiracılı (multi-tenant) ve tamamen güvenilmeyen kodların çalıştırıldığı sistemlerde yeterli bir güvenlik sınırı kabul edilmez; ek güvenlik politikalarıyla sıkılaştırılması şarttır.

2. gVisor ile Kernel Seviyesinde Sandboxing (Güçlendirilmiş Güvenlik)

Google tarafından geliştirilen ve açık kaynak olarak sunulan gVisor, konteyner güvenliğini radikal bir şekilde artıran bir uygulama çekirdeğidir (application kernel). Standart bir konteynerde çalışan kod, doğrudan ana makine çekirdeğine sistem çağrısı (syscall) yaparken; gVisor'ın OCI uyumlu çalışma zamanı olan runsc, bu çağrıları kullanıcı alanında (user space) karşılar.

gVisor, Go dilinde yazılmış bağımsız bir çekirdek gibi davranarak yaklaşık 300'den fazla Linux sistem çağrısını sanallaştırır. Çalıştırılan yapay zeka kodu dosya açmak, bellek tahsis etmek veya soket oluşturmak istediğinde bu çağrı ana makinenin çekirdeğine değil, gVisor'ın Sentry bileşenine gider. Böylece ana makine çekirdeğindeki sıfırıncı gün (0-day) zafiyetleri yapay zeka kodu tarafından doğrudan istismar edilemez. Performans açısından %5-15 arasında bir syscall ek yükü (overhead) getirse de, sağladığı güçlü güvenlik katmanı sayesinde yapay zeka ajanları için en dengeli çözümlerden biridir.

3. MicroVM (AWS Firecracker) ile Donanım Destekli Sanallaştırma

AWS tarafından Lambda ve Fargate altyapılarını güçlendirmek için geliştirilen Firecracker, Linux Kernel-based Virtual Machine (KVM) teknolojisini kullanan açık kaynaklı bir sanallaştırma aracıdır. Geleneksel sanal makinelerin (QEMU tabanlı VM'ler) dakikalar süren açılış sürelerine ve gigabaytlarca bellek tüketimine karşın Firecracker, gereksiz aygıt sürücülerini kaldırarak yaklaşık 5-10 milisaniyede sıfırdan bir MicroVM başlatabilir.

MicroVM mimarisinde her bir yapay zeka kod çalıştırma oturumu, kendi bağımsız Linux çekirdeğine ve sanallaştırılmış donanım sınırlarına sahip olur. Ana makine ile paylaşılan hiçbir çekirdek alanı bulunmaz. Bu durum, donanım seviyesinde (Intel VT-x veya AMD-V) mutlak bir izolasyon sağlar. Finans, sağlık veya kritik kurumsal verilerin işlendiği ve birden fazla müşterinin kodlarının aynı fiziksel donanımda çalıştırıldığı çok kiracılı (multi-tenant) yapay zeka platformları için Firecracker altın standarttır.

4. WebAssembly (Wasm) ile Tarayıcı ve Sunucu Tarafı Güvenli Alanlar

WebAssembly (Wasm), başlangıçta web tarayıcılarında yüksek performanslı kod çalıştırmak için tasarlanmış olsa da, WASI (WebAssembly System Interface) standardı sayesinde sunucu tarafında da güvenli bir sandbox haline gelmiştir. Wasm modülleri, varsayılan olarak sıfır yetkiyle başlar; dosya sistemine, çevre birimlerine veya ağ soketlerine doğrudan erişimleri yoktur.

Wasm motorları (Wasmtime, Wasmer veya V8), yapay zekanın ürettiği C, Rust, Go veya Python (Wasm derlemesi üzerinden) kodlarını deterministik bir bellek alanında yürütür. Mikrosaniyeler mertebesindeki başlatma süresi ve son derece düşük bellek tüketimi ile öne çıkar. Ancak saf Wasm ortamlarında standart Python veya C kütüphanelerinin (örneğin yerel C bağımlılığı olan NumPy, Pandas gibi veri bilimi paketlerinin) çalıştırılması ek derleme süreçleri gerektirdiği için veri analitiği odaklı AI kodlarında entegrasyon zorlukları barındırabilir.

SÜREÇ ADIMLARI

Güvenli İzolasyon Mimarisi Kurulum Adımları

Bir yapay zeka kod çalıştırma altyapısının devreye alınmasında izlenmesi gereken operasyonel sıra.

01

İzolasyon Seviyesinin Belirlenmesi

Uygulamanın performans, gecikme ve regülasyon (KVKK/SOC2) gereksinimlerine göre gVisor veya MicroVM altyapısını seçin.

02

Temel İmaj ve Kütüphane Optimizasyonu

Yalnızca ihtiyaç duyulan dil çalışma zamanlarını içeren minimal ve root yetkisi olmayan (distroless/Alpine) imajlar hazırlayın.

03

Çekirdek ve Sistem Çağrısı Filtreleme

Docker daemon üzerinde gVisor runsc runtime'ını tanımlayın veya seccomp profillerini uygulayarak çekirdek erişimini sınırlandırın.

04

Ağ ve Kaynak Kısıtlamalarının Devreye Alınması

cgroups ile CPU/RAM tavanlarını belirleyin, iptables veya Kubernetes NetworkPolicy ile tüm harici ağ çıkışlarını kapatın.

05

Dinamik Yaşam Döngüsü ve Temizlik

Her kod çalıştırma işlemi için geçici (ephemeral) bir konteyner oluşturup işlem bittiğinde ortamı tüm verileriyle imha edin.

Docker Konteyner Kaçışını (Container Escape) Önleme Yolları

Docker tabanlı bir sandbox mimarisi kurulduğunda, varsayılan Docker konfigürasyonunun yapay zeka güvenliği için yetersiz olduğu kabul edilmelidir. Standart bir Docker konteyneri, saldırganın konteyner kaçışı (container escape) gerçekleştirerek ana işletim sisteminde (host OS) tam yetki elde etmesine imkan tanıyan birden fazla potansiyel açık bırakabilir. Bu açıkları kapatmak için konteyner çalışma zamanının kapsamlı bir şekilde sıkılaştırılması (hardening) gerekir.

Konteyner kaçışlarının büyük bölümü; aşırı yetkilendirilmiş kullanıcı izinleri, paylaşımlı hassas ana makine dizinleri, güvensiz Linux yetenekleri (capabilities) ve filtrelenmemiş sistem çağrılarından kaynaklanır. Aşağıdaki yapılandırmalar, yapay zeka kod çalıştırma konteynerlerinde tavizsiz bir şekilde uygulanmalıdır.

Read-Only Dosya Sistemleri Kullanımı

Yapay zeka tarafından yürütülen zararlı bir kodun sisteme kalıcı bir arka kapı (backdoor) yerleştirmesini, ikili dosyaları (binaries) değiştirmesini veya zararlı yazılım indirmesini engellemenin en etkili yolu, kök dosya sistemini salt okunur (read-only) olarak bağlamaktır.

Docker üzerinde --read-only bayrağı kullanıldığında konteyner içerisindeki hiçbir dosya değiştirilemez veya yeni dosya oluşturulamaz. Yapay zeka kodunun çalışması sırasında geçici dosya yazma ihtiyacı varsa (örneğin bir Python betiğinin grafik çizmesi veya veri işlemesi), yalnızca /tmp dizini bellek tabanlı (tmpfs) olarak bağlanmalı ve bu dizine kota getirilmelidir (--tmpfs /tmp:rw,noexec,nosuid,size=64m). noexec bayrağı sayesinde /tmp dizinine yazılan herhangi bir dosyanın çalıştırılabilir bir ikili dosya olarak yürütülmesi çekirdek seviyesinde engellenir.

Ağ (Network) Erişimini Sınırlandırma ve 'Air-gapped' Çalışma

Yapay zeka kod yürütme ortamları için en büyük risklerden biri, kodun harici sunucularla iletişim kurabilmesidir. Kodun internete erişebilmesi; veri sızdırma, harici zararlı komut dosyaları çekme veya iç ağdaki diğer sunuculara saldırma ihtimalini doğurur.

# Tamamen ağdan yalıtılmış, salt okunur ve kısıtlı kaynaklı örnek çalıştırma komutu:
docker run --rm \
  --network none \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=32m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 256m \
  --cpus 0.5 \
  --user 10001:10001 \
  ai-sandbox-python:latest python3 script.py

Eğer kodun internet erişimine ihtiyacı yoksa konteyner --network none bayrağı ile başlatılmalı ve tamamen hava boşluklu (air-gapped) hale getirilmelidir. Kodun belirli API'lere erişmesi zorunluysa, rastgele dış ağ erişimine izin verilmemeli; gidiş trafiği (egress traffic) yalnızca izin verilen IP adreslerine ve alan adlarına (whitelist) sınırlandırılmalı, DNS sorguları merkezi ve filtrelenmiş bir proxy üzerinden yönlendirilmelidir.

Kullanıcı Yetkilerini Kısıtlama (Non-root Execution ve Syscall Filtreleme)

Konteyner içinde çalışan varsayılan kullanıcı kimliği (UID 0) yani root kullanıcısıdır. Konteyner içinde root yetkisine sahip olmak, çekirdekte oluşabilecek bir sızıntıda ana makinede de root yetkisi kazanılması riskini taşır. Bu nedenle yapay zeka kodları kesinlikle ayrıcalıksız (non-root) bir kullanıcı altında (örneğin UID 10001) çalıştırılmalıdır.

Buna ek olarak aşağıdaki çekirdek güvenlik adımları uygulanmalıdır:

  • Capabilities Kısıtlaması: Linux çekirdeğinin sunduğu ayrıcalıkları temsil eden CAP_* bayraklarının tamamı kaldırılmalıdır (--cap-drop ALL). Kod ortamının raw soket açma (CAP_NET_RAW), dosya sahipliği değiştirme (CAP_CHOWN) veya sistem saatini değiştirme gibi yetkilere ihtiyacı yoktur.

  • Yetki Yükseltme Engeli: --security-opt no-new-privileges:true parametresi ile süreçlerin setuid veya setgid ikili dosyalarını kullanarak yetki yükseltmesi (privilege escalation) engellenmelidir.

  • Seccomp Profili: Güvenli Bilgi İşlem Modu (Secure Computing Mode - seccomp), bir sürecin yapabileceği sistem çağrılarını kısıtlar. Özel bir seccomp JSON profili oluşturularak, yapay zeka kodunun yalnızca dosya okuma/yazma ve bellek tahsisi gibi temel syscall'ları (read, write, exit, futex) yapmasına izin verilmeli; ptrace, sys_chroot veya reboot gibi tehlikeli sistem çağrıları engellenmelidir.

Güvenli Yapay Zeka Entegrasyonu İçin En İyi Mimari Uygulamalar

Kod çalıştırma ortamının işletim sistemi düzeyinde izole edilmesi, altyapı güvenliğinin yalnızca bir boyutunu oluşturur. Kurumsal bir yapay zeka entegrasyonunda sistemin sürdürülebilir, yüksek erişilebilir ve maliyet etkin kalabilmesi için uygulama mimarisi düzeyinde de koruma bariyerleri inşa edilmelidir. Bir yapay zeka modelinin mantıksal hataları, altyapının çökmesine veya fahiş bulut faturalarına yol açmamalıdır.

Modern bir yapay zeka kod yürütme mimarisi; dinamik yaşam döngüsü yönetimi, orkestrasyon, gerçek zamanlı telemetri ve insan denetim süreçlerini birleştiren bütünsel bir savunma yaklaşımını benimsemelidir.

Kaynak Sınırlandırma (cgroups, CPU, RAM ve Disk Kotası Belirleme)

Yapay zeka modelleri tarafından yazılan kodlar, optimize edilmemiş algoritmalar veya sonsuz döngüler içerebilir. Bellek sızıntısı (memory leak) yaratan veya tüm işlemci çekirdeklerini %100 yükte çalıştıran kontrolsüz bir kod parçası, aynı sunucudaki diğer kritik servisleri kilitleyebilir (noisy neighbor problemi).

Linux Kontrol Grupları (cgroups v2) kullanılarak her sandbox oturumuna katı limitler konulmalıdır:

  • CPU Kısıtlaması: Konteyner başına maksimum 0.5 veya 1 CPU çekirdeği tahsis edilmeli (--cpus=0.5), işlemci zamanı dilimlenmelidir.

  • Bellek (RAM) ve Swap Sınırı: Her çalıştırma için görev türüne göre 128MB - 512MB arası bellek kotası konulmalı (--memory=256m) ve belleğin diske taşmasını önlemek için swap alanı tamamen devre dışı bırakılmalıdır (--memory-swap=256m). Bellek aşımı durumunda çekirdeğin OOM (Out Of Memory) Killer mekanizması süreci anında sonlandırmalıdır.

  • Disk I/O ve Boyut Kotası: Kodun diski doldurarak sunucuyu kilitlemesini engellemek için disk okuma/yazma hızlarına (IOPS) limit konulmalı ve yazılabilir geçici alan maksimum 50-100 MB ile sınırlandırılmalıdır.

Zaman Aşımı (Timeout) ve Otomatik Kapanma Mekanizmaları

Hiçbir yapay zeka kod çalıştırma işlemi süresiz olarak arka planda çalışmaya bırakılmamalıdır. Bir veri analitiği veya hesaplama kodunun normal şartlarda birkaç saniye içinde tamamlanması beklenir.

Uygulama katmanında çift yönlü bir zaman aşımı (timeout) mimarisi kurulmalıdır:

  1. İç Zaman Aşımı (Process Level): Kodun çalıştığı çalışma zamanı düzeyinde (örneğin Python'ın signal kütüphanesi veya subprocess modülü üzerinden) belirlenen bir süre limiti (örneğin 10 saniye) aşıldığında SIGTERM, yanıt alınamazsa SIGKILL sinyali gönderilerek işlem sonlandırılmalıdır.

  2. Dış Zaman Aşımı (Orchestrator Level): Konteyneri yöneten servis (Kubernetes Job, Docker API veya özel bir orkestratör) bağımsız bir sayaç tutmalıdır. İç süreç kilitlense veya sinyalleri yakalasa dahi, dış orkestratör 15. saniyede konteyneri zorla imha etmelidir.

Ayrıca geçici (ephemeral) çalışma prensibi uygulanmalıdır. Her kod çalıştırma işlemi için sıfırdan bir sandbox ayağa kaldırılmalı, kod yürütülüp çıktı alındıktan sonra bu sandbox bütünüyle yok edilmelidir. Oturumlar arası durum (state) saklanmamalıdır.

İnsan Denetimi (Human-in-the-Loop) ve Çıktı Doğrulama Süreçleri

Yapay zeka sistemleri otonom kararlar alabildiği durumlarda dahi, yüksek riskli işlemler için insan denetimi (Human-in-the-Loop - HITL) zorunlu tutulmalıdır. Kod çalıştırma ortamı ne kadar izole olursa olsun, kodun ürettiği mantıksal çıktının bir veritabanına yazılması veya bir API çağrısını tetiklemesi işletme süreçlerinde geri dönülemez hatalara yol açabilir.

Kritik aksiyonlar öncesinde bir onay mekanizması kurulmalıdır:

  • Kodun içeriği çalıştırılmadan önce bir statik analiz katmanından (AST - Abstract Syntax Tree analizi) geçirilmeli; şüpheli fonksiyon çağrıları (eval, exec, os.system, subprocess) tespit edilirse işlem durdurulmalıdır.

  • Kodun ürettiği sonuçlar (JSON, metin, grafik) doğrudan son kullanıcıya veya üretim veritabanına aktarılmadan önce şema doğrulamasından (schema validation) ve veri temizleme (sanitization) aşamasından geçirilmelidir.

  • Tüm çalıştırma geçmişi, üretilen kod blokları, kaynak tüketim grafikleri ve sistem günlükleri (stdout/stderr) merkezi bir SIEM (Security Information and Event Management) sistemine kriptografik olarak imzalanıp kaydedilmelidir.

İşletmeler İçin Stratejik Karar Rehberi: Hangi İzolasyon Yöntemi Seçilmeli?

Teknik karar vericiler ve işletme yöneticileri için yapay zeka kod çalıştırma altyapısı seçimi; güvenlik seviyesi, operasyonel karmaşıklık, donanım maliyeti ve kullanıcı deneyimi (gecikme süresi) arasındaki dengenin doğru kurulmasını gerektirir. Her işletmenin risk profili ve kullanım senaryosu farklıdır.

Aşağıdaki karşılaştırma tablosu, işletmenizin mimari gereksinimlerine en uygun sandbox teknolojisini belirlemenize yardımcı olacak teknik ve operasyonel kriterleri özetlemektedir:

KARŞILAŞTIRMA TABLOSU

Karşılaştırma Tablosu

Kriter bazında avantajlar ve dezavantajları karşılaştırın.

Kriter
Avantajlar
Dezavantajlar
01 Sertleştirilmiş Docker
Orta (Kernel Paylaşımlı)
100 - 300 ms
02 gVisor (runsc)
Yüksek (Syscall Yalıtımı)
150 - 400 ms
03 AWS Firecracker
Çok Yüksek (Donanım KVM)
5 - 15 ms
04 WebAssembly (WASI)
Yüksek (Deterministik Wasm)
< 5 ms
01

Sertleştirilmiş Docker

Avantaj

Orta (Kernel Paylaşımlı)

Dezavantaj

100 - 300 ms

02

gVisor (runsc)

Avantaj

Yüksek (Syscall Yalıtımı)

Dezavantaj

150 - 400 ms

03

AWS Firecracker

Avantaj

Çok Yüksek (Donanım KVM)

Dezavantaj

5 - 15 ms

04

WebAssembly (WASI)

Avantaj

Yüksek (Deterministik Wasm)

Dezavantaj

< 5 ms

Karar alma sürecinde şu stratejik yol haritası izlenebilir:

  1. Dahili Otomasyon ve Düşük Risk: Yalnızca şirket içi personelin kullandığı, harici kullanıcı girdisi almayan ve hassas veritabanı erişimi bulunmayan projelerde; read-only, no-network, cgroups ve non-root parametreleriyle sıkılaştırılmış standart Docker konteynerleri yeterli ve maliyet etkin bir başlangıçtır.

  2. Son Kullanıcıya Açık SaaS ve AI Ajanları: Dış dünyadan gelen kullanıcıların serbestçe prompt girebildiği, yapay zekanın veri analitiği kodları (Pandas, Matplotlib vb.) çalıştırdığı B2B/B2C SaaS ürünlerinde gVisor tercih edilmelidir. Mevcut Docker ve Kubernetes altyapılarına sorunsuz entegre olur ve sıfırıncı gün çekirdek açıklarına karşı güçlü bir koruma sağlar.

  3. Kritik Çok Kiracılı Platformlar ve Regüle Sektörler: Birden fazla kurumsal müşterinin rastgele kodlarının aynı sunucu havuzunda çalıştırıldığı büyük ölçekli platformlarda, SOC2, HIPAA ve ISO 27001 gereksinimlerini eksiksiz karşılamak adına AWS Firecracker MicroVM mimarisi kurulmalıdır.

Yapay zeka altyapılarının güvenliği, tek seferlik bir kurulum değil, sürekli güncellenen bir savunma hattıdır. Kullanılan çalışma zamanı imajları düzenli olarak güvenlik açıklarına (CVE) karşı taranmalı, Linux çekirdeği güncel tutulmalı ve yapay zeka modellerinin ürettiği kod desenleri telemetri araçlarıyla kesintisiz izlenmelidir.

Sıkça Sorulan Sorular

Yapay zeka tarafından üretilen kodlar neden doğrudan sunucuda çalıştırılmamalıdır?

Büyük dil modelleri halüsinasyon veya prompt manipülasyonu nedeniyle zararlı, kaynak tüketen ya da yıkıcı sistem komutları üretebilir. Bu kodların doğrudan ana sunucuda çalıştırılması veri sızıntısına, dosya sistemi hasarına ve uzaktan kod çalıştırma (RCE) açıklarına yol açar.

Standart Docker konteynerleri AI kod izolasyonu için neden tek başına yeterli değildir?

Standart Docker konteynerleri ana makinenin Linux çekirdeğini doğrudan paylaşır. Çekirdekte ortaya çıkabilecek bir güvenlik açığı veya yetki yükseltme durumu, kodun konteyner sınırlarını aşarak ana makineye erişmesine (container escape) neden olabilir.

gVisor teknolojisi konteyner güvenliğini nasıl sağlar?

gVisor, sistem çağrılarını doğrudan ana çekirdeğe iletmek yerine kullanıcı alanında sanallaştıran bağımsız bir uygulama çekirdeğidir. Bu sayede çalıştırılan yapay zeka kodu ana işletim sistemi çekirdeğiyle doğrudan temas kuramaz ve çekirdek seviyesindeki açıklar engellenir.

AWS Firecracker MicroVM mimarisinin geleneksel sanal makinelerden farkı nedir?

Firecracker, KVM tabanlı donanım sanallaştırmasını kullanırken gereksiz aygıt sürücülerini devre dışı bırakır. Bu sayede geleneksel sanal makineler dakikalar içinde açılırken, Firecracker 5-10 milisaniye gibi kısa sürede tam izole bir sanal makine başlatır.

Sandbox ortamında ağ erişimini kapatmak neden önemlidir?

Ağ erişiminin kapatılması ( --network none ), yapay zeka kodunun harici sunuculara veri sızdırmasını, komut-kontrol sunucularından zararlı ikili dosyalar indirmesini ve yerel ağdaki diğer mikroservislere saldırmasını fiziksel olarak imkansız kılar.

Yapay zeka kod çalıştırma ortamlarında kaynak kısıtlaması (cgroups) nasıl uygulanmalıdır?

Linux cgroups aracılığıyla her çalışma oturumuna katı CPU kotası, maksimum bellek limiti (örneğin 256MB) ve disk I/O sınırları atanmalıdır. Bu yapılandırma, yapay zekanın sonsuz döngüler veya aşırı bellek kullanımıyla sunucuyu kilitlemesini önler.

WebAssembly (Wasm) yapay zeka kod çalıştırmada hangi senaryolar için uygundur?

WebAssembly, mikrosaniyelik açılış süresi ve varsayılan sıfır yetki mimarisi ile son derece güvenlidir. Ancak yerel C bağımlılığı olan ağır veri bilimi kütüphaneleri yerine hafif matematiksel algoritmalar ve kural tabanlı betikler için daha uygundur.

İzole kod ortamlarında geçici (ephemeral) çalışma prensibi ne anlama gelir?

Geçici çalışma prensibinde, her yapay zeka kod yürütme görevi için sıfırdan temiz bir sandbox oluşturulur ve kod tamamlandığında ortam tüm geçici verileriyle birlikte imha edilir. Bu yaklaşım, oturumlar arası durum kalmasını ve veri sızıntılarını engeller.

Son Adım

Dijital projenizi bugün planlayalım

Web, yazılım, e-ticaret, mobil uygulama, entegrasyon, SEO veya GEO ihtiyacınızı net bir kapsama dönüştürelim.

Yapay Zeka Kod Çalıştırma Ortamı Nasıl İzole Edilir? | Webizm