Skip to content

Cross-Tenant Cache Leak: Multi-Tenant Güvenlik Açığı

Bir tenant'ın cache'inin başka tenant'a sızması. Modül 10'da değindik; şimdi exploit senaryoları + önleme.

Şükrü Yusuf KAYA
11 min read
Advanced

Anti-Pattern 3: Cross-Tenant Cache Leak

Modül 10 Ders 68'de değindik. Şimdi exploit senaryosunu detaylandırıyoruz.
Senaryo: SaaS LLM platform. 100 farklı şirket aynı altyapıyı kullanıyor. Tenant A'nın cache'i Tenant B'ye sızar mı?

Exploit: Timing-Based Side Channel#

Tenant A bir prompt cache'lemiş olsun:
[System: "Sen Acme Corp asistanısın"]
[Tools: ...Acme tools]
[KB: "Acme'nin satış stratejisi 2026: ..."]
Tenant B aynı sistemi araştırıyor. Naive shared pool'da Tenant B şu şekilde prompt deniyor:
# Prompt 1: Acme'nin satış stratejisi 2026: kuzey av (3sn) → cache miss
# Prompt 2: Acme'nin satış stratejisi 2026: kuzey kıbrıs (3sn) → cache miss
# Prompt 3: Acme'nin satış stratejisi 2026: kuzey amerika (0.3sn) → CACHE HIT!
Latency farkı (cache hit hızlı, cache miss yavaş) ile Tenant B, Tenant A'nın stratejisinin "kuzey amerika" olduğunu öğreniyor. Veri sızdı.
Gerçek Tehdit
Bu gerçek bir saldırı vektörü. Multi-tenant SaaS LLM service'leri için en kritik güvenlik tehditlerinden biri.

Önleme 1: Tenant-Prefixed Prompts (Modül 10 Ders 68)#

python
def make_request(tenant_id, prompt):
    # Her tenant'a unique prefix
    isolated_prompt = f"[TENANT:{tenant_id}]\n\n{prompt}"
    return client.messages.create(
        system=[{"text": isolated_prompt, "cache_control": {"type": "ephemeral"}}],
        ...
    )
Tenant prefix ile cache isolation
Tenant B "TENANT
"'yi bilse bile, exact ID'yi tahmin edemediği sürece cache hit alamaz. Genelde UUID veya hash kullan.

Önleme 2: Provider-Level Isolation#

Anthropic, OpenAI, Gemini hepsi per-org cache isolation yapıyor. Yani farklı API key'ler arasında cache paylaşılmıyor.
Bu durumda her tenant kendi API key'ini kullanırsa otomatik izolasyon.
Multi-tenant pattern:
# Tenant başına ayrı API key
TENANT_API_KEYS = {
    "tenant-a": "sk-ant-...",
    "tenant-b": "sk-ant-...",
}

def get_client_for(tenant_id):
    return anthropic.Anthropic(api_key=TENANT_API_KEYS[tenant_id])
Avantaj: Provider tarafında izolasyon garantili. Dezavantaj: Her tenant için ayrı billing — şirketin overhead.

Önleme 3: Per-Tenant Latency Padding#

Eğer izolasyon gerçekten kritikse, response time'ı kasten dengele:
import random

def make_request_with_padding(prompt, target_latency=2.0):
    start = time.time()
    resp = client.messages.create(...)
    elapsed = time.time() - start
    if elapsed < target_latency:
        time.sleep(target_latency - elapsed)  # padding
    return resp
Cache hit (0.3s) ile miss (3s) ikisi de ~2s gibi gözükür. Timing attack engellenir.
Trade-off: UX bozulur, latency suni yüksek.
Provider vs Self-Hosted
Provider'lar bu önlemleri zaten alıyor. Self-hosted (vLLM/SGLang) kullanıyorsan sen sağlamalısın.

✓ Pekiştir#

Bir Sonraki Derste#

Cache stampede — yeni model deploy edildiğinde ne olur?

Yorumlar & Soru-Cevap

(0)
Yorum yazmak için giriş yap.
Yorumlar yükleniyor...

Related Content

1. Temeller — Context Penceresi Ekonomisi

Bu Eğitim Hakkında ve Prompt Caching Neden Önemli?

Start Learning
1. Temeller — Context Penceresi Ekonomisi

Token Ekonomisi 101: Input vs Output Cost Asimetrisi

Start Learning
1. Temeller — Context Penceresi Ekonomisi

Context Window Evrimi: 4K'dan 1M'a 5 Yılda Ne Oldu?

Start Learning