API Key Güvenliği: LLM Anahtarları Nasıl Sızar, Nasıl Korunur, Sızarsa Ne Yapılır?

API anahtarı güvenliğinin özü üç kuraldır: anahtarı koda değil ortam değişkenine veya secret manager'a koyun, her ortam için ayrı anahtar kullanıp düzenli döndürün ve sızıntı ihtimaline karşı harcamayı teknik olarak sınırlayan bir katman kurun. Onysoft AI Gateway'de anahtar bazlı token limitleri ve ön ödemeli bakiye tavanı, sızan bir anahtarın verebileceği zararı baştan sınırlar.

LLM API anahtarlarını sıradan API anahtarlarından ayıran şey, doğrudan paraya çevrilebilir olmalarıdır: her token'ın katalogda yazılı bir fiyatı vardır ve sızan bir anahtar, otomatik tarayıcı botlarının elinde saatler içinde faturaya dönüşür. Klasik "API güvenliği" yazılarının OAuth ve HTTPS anlatısı bu riski kapsamaz — burada tehdit yetkisiz veri erişiminden önce yetkisiz harcamadır.

Bu rehberde sızıntıların gerçekte nereden kaynaklandığını, anahtarın doğru saklanışını ve — bu sorguda başka yerde bulamayacağınız — canlı satış fiyatlarıyla hesaplanmış bir hasar senaryosu tablosunu, harcamayı mimari düzeyde sınırlayan gateway katmanlarını ve sızıntı anı kontrol listesini bulacaksınız.

API Anahtarları En Çok Nereden Sızıyor?

En yaygın beş sızıntı kaynağı şunlardır: anahtarın frontend koduna gömülmesi, git deposuna commit edilmesi, log ve hata kayıtlarına yazılması, ekip içi paylaşım kanalları ve CI/CD yapılandırmaları. Beşinin ortak özelliği, anahtarın "geçici olarak" güvenli sanılan bir yere yazılması ve orada unutulmasıdır.

• Frontend'e gömme: Tarayıcıda çalışan JavaScript paketine giren anahtar, DevTools'un Network sekmesini açan herkese açıktır. LLM çağrısı tarayıcıdan doğrudan yapılmamalı; istek her zaman sizin backend'inizden geçmeli, anahtar yalnızca sunucuda durmalıdır.
• Repoya commit: Herkese açık depolar, sızıntı avcısı botlar tarafından sürekli taranır; commit edilen anahtar dakikalar içinde kullanılmaya başlanabilir. Özel depo da güvenli sayılmaz — fork, erişim genişlemesi ve depo geçmişi kalıcıdır. Dosyayı silmek yetmez; geçmişte kalan anahtar geçerliliğini korur.
• Log ve hata kayıtları: İstek loglayan bir ara katmanın Authorization başlığını olduğu gibi yazması ya da hata izleme aracına giden payload'da anahtarın bulunması sık görülen ve geç fark edilen bir sızıntıdır. Log yazarken başlıkları maskelemek zorunludur.
• Paylaşım kanalları: Slack mesajına, e-postaya veya bilet sistemine düz metin yapıştırılan anahtar, o kanalın arşivinde süresiz yaşar ve kanala erişen herkese açılır.
• CI/CD yapılandırmaları: Pipeline loglarına echo ile düşen değişkenler ve derleme çıktısına paketlenen .env dosyaları, gözden en uzak sızıntı yüzeyidir.

Anahtar Nasıl Doğru Saklanır: Ortam Değişkeni ve Secret Manager

Doğru saklamanın tek temel kuralı vardır: anahtar kaynak koduna hiçbir biçimde girmez — yerel geliştirmede .env dosyası ve ortam değişkeni, üretimde bir secret manager kullanılır. Kodda yalnızca değişkenin adı geçer, değeri çalışma anında dışarıdan gelir.

# .env — asla repoya girmez
ONYSOFT_API_KEY=sk-ony-ANAHTARINIZ

# .gitignore — ilk commit'ten önce eklenir
.env

Üretimde .env dosyası yerine bulut sağlayıcınızın secret store'u veya Vault benzeri bir secret manager tercih edilmelidir: anahtar şifreli durur, erişim yetkiyle sınırlanır, kim ne zaman okumuş kaydı tutulur ve değer, uygulamaya dağıtım anında ortam değişkeni olarak enjekte edilir. İki tamamlayıcı alışkanlık da riski belirgin azaltır: her uygulamaya ve servise kendi anahtarını vermek (tek anahtarın her yerde kullanılması, tek sızıntıyı topyekûn felakete çevirir) ve commit öncesi gitleaks benzeri bir sır tarayıcısını pre-commit kancasına bağlamak — anahtar repoya girmeden yakalanır.

Sızan Anahtar Kaç Paraya Patlar? Gerçek Fiyatlarla Hasar Senaryosu

Sızan bir LLM anahtarının hasarı soyut bir "güvenlik riski" değildir; token fiyatı üzerinden doğrudan hesaplanır. Somut bir senaryo kuralım: anahtarınız ele geçirildi ve fark edene kadar saldırgan 10 milyon çıktı token'ı üretti (otomatik kötüye kullanımda gerçekçi bir hacim). Faturanın büyüklüğünü hangi modelin çağrıldığı belirler — aşağıdaki tutarlar api.onysoft.com canlı kataloğundaki gerçek satış fiyatlarıyla hesaplanmıştır:

Model	Çıktı ($/1M token)	10M token hasarı (USD)	10M token hasarı (TL)
anthropic/claude-opus-5	$37.50	$375.00	17.833,13 TL
anthropic/claude-sonnet-5	$15.00	$150.00	7.133,25 TL
google/gemini-3.6-flash	$11.25	$112.50	5.349,94 TL
openai/gpt-5.6-terra	$9.00	$90.00	4.279,95 TL
openai/gpt-5.6-luna	$0.90	$9.00	428,00 TL
deepseek/deepseek-v4-flash	$0.42	$4.20	199,73 TL

Ölçüm: 5 Ağustos 2026 — api.onysoft.com canlı katalog. TL karşılıkları 5 Ağustos 2026 TCMB kuru (1 USD = 47,555 TL) ile hesaplanmıştır.

İki sonuç çıkıyor. Birincisi, hasar model seçimine göre yaklaşık 90 kat değişir — saldırgan doğal olarak en pahalı modeli tercih eder. İkincisi ve daha önemlisi: kredi kartına bağlı, kullandıkça faturalanan bir hesapta bu tutarların üst sınırı harcama limitinizdir; ön ödemeli modelde ise üst sınır yüklü bakiyenizdir. Sızıntı senaryosunda maksimum kaybınızı sözleşme değil mimari belirlemelidir — bir sonraki bölümün konusu tam olarak bu.

Onysoft'ta Nasıl Çalışıyor: Limitli Anahtar, Maliyet Ön Kontrolü ve 402

Onysoft'ta anahtar güvenliği yalnızca saklama tavsiyesi değil, gateway'e gömülü üç teknik katmandır: anahtar bazlı model token limitleri, her istekte maliyet ön kontrolü ve ön ödemeli bakiye tavanı. Önce kod — anahtar ortam değişkeninden okunur, kodda hiçbir sır geçmez:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.onysoft.com/v1",
    api_key=os.environ["ONYSOFT_API_KEY"],  # anahtar kodda değil, ortamda
)

response = client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{"role": "user", "content": "Bu log satırındaki hatayı açıkla."}],
)
print(response.choices[0].message.content)
# Her yanıtın gövdesinde cost alanı döner: bu isteğin USD maliyeti.
# Log'a istek kimliğiyle birlikte yazın — anormallik tespitinin ham verisi budur.

Katmanlar şöyle çalışır:

• Anahtar bazlı model token limitleri: Panelden her anahtara model bazında token limiti tanımlarsınız. Sızan bir anahtar bakiyenizin tamamına değil, o anahtara tanıdığınız limite kadar harcama yapabilir — frontend'e yakın, riskli servislerin anahtarını dar limitle vermek doğru pratiktir.
• Maliyet ön kontrolü → 402: Gateway her istekte tahmini maliyeti 1,2 katsayısıyla bakiyenize karşı kontrol eder; bakiye yetmiyorsa istek modele hiç iletilmeden HTTP 402 döner. Sızan anahtar bakiye üstü tek token harcayamaz — sonradan gelen kredi kartı sürprizi bu mimaride yoktur.
• İstek bazlı cost alanı ve kullanım raporları: Her yanıttaki cost alanı ve paneldeki tarih/model filtreli kullanım raporları, anormalliği görünür kılar: gece 03:00'te hiç kullanmadığınız bir amiral modele giden istek dizisi, raporda ilk bakışta ayrışır.

Katalogdaki 739+ modelin tamamı aynı sk-ony- anahtarıyla çalışır; harcama tarafını derinlemesine kurgulamak için maliyet kontrolü rehberine, uç ayrıntıları için API dokümantasyonuna bakın.

Anahtar Yaşam Döngüsü: Ortam Ayrımı, Rotasyon, İptal

Sağlıklı bir anahtar yaşam döngüsü üç alışkanlıktan oluşur: her ortama ayrı anahtar, takvimli rotasyon ve tek adımda iptal edilebilirlik. Geliştirme, test ve üretim aynı anahtarı paylaşıyorsa, en korumasız ortamdaki sızıntı doğrudan üretim bütçenizi açar; ayrı anahtarlarda ise geliştirme anahtarına dar token limiti verir, üretim anahtarını yalnızca secret manager'da tutarsınız.

Rotasyon parola değişiminin API karşılığıdır: anahtarları düzenli aralıklarla (örneğin 90 günde bir) ve anahtara erişimi olan bir ekip üyesi ayrıldığında derhal yenileyin. Doğru sıra kesintisizdir: yeni anahtarı üret → secret manager üzerinden dağıt → trafiğin geçtiğini kullanım raporundan doğrula → eski anahtarı iptal et. Bu sıra izlendiğinde rotasyon kullanıcıya hissettirilmez.

Son parça envanterdir: hangi anahtarın hangi serviste, hangi ortamda ve hangi limitle kullanıldığının güncel bir listesi olmadan ne rotasyon planlanabilir ne de sızıntıda hangi anahtarın iptal edileceğine hızla karar verilebilir. Anahtar sayınız üçü geçtiği anda bu listeyi tutmaya başlayın.

Anahtar Sızdıysa: İlk 30 Dakika Kontrol Listesi

Sızıntı anında doğru sıralama şudur: önce anahtarı iptal edin, sonra hasarı ölçün, en son kaynağı kapatın — tersini yapıp önce "temizlik" ile uğraşmak, saldırganın harcamaya devam ettiği dakikalar demektir.

1. Anahtarı derhal iptal edin (dakika 0-5): Panelden sızan anahtarı devre dışı bırakın, servisin ihtiyacı için yeni anahtar üretin. İptal, harcamayı o an durdurur; kalan adımların tamamı artık zaman baskısı olmadan yapılır.
2. Hasarı ölçün (dakika 5-15): Kullanım raporunu sızıntı penceresine tarih filtresiyle daraltın, model filtresiyle tanımadığınız trafiği ayıklayın ve cost toplamını çıkarın. Ön ödemeli mimaride bu toplamın üst sınırı bakiyeniz, anahtar limitliyse tanımladığınız limittir.
3. Kaynağı kapatın (dakika 15-30): Anahtar repoya girdiyse geçmişten temizleyin ama bunun tek başına yeterli olmadığını bilin — iptal asıl güvencedir. Log maskelemesini, frontend paketini ve CI yapılandırmasını aynı gözle denetleyin.
4. Diğer anahtarları gözden geçirin: Sızıntı bir kanaldan olduysa (repo, log, Slack) aynı kanaldan başka anahtar da sızmış olabilir; envanter listesindeki tüm anahtarları aynı pencerede kontrol edin.
5. Süreci güncelleyin: Ekibi bilgilendirin, rotasyon takvimini öne çekin ve sızıntıyı mümkün kılan adımı (eksik .gitignore, maskelenmemiş log) kalıcı olarak düzeltin.

Sızıntı yaşanmadan bu listeyi bir kez prova etmek, yaşandığında paniği plana çevirir. Başlamak için ücretsiz hesap açıp anahtarlarınızı ortam bazında ayırabilir, genel çerçeve için Yapay Zeka API rehberine göz atabilirsiniz.

Son güncelleme: 5 Ağustos 2026 · Veriler: api.onysoft.com canlı katalog