Güven ve uyumluluk · 2026-05-25

Google API key çalındıysa ne yapmalı? Gemini faturası ve harcama limiti rehberi

Google API key çalındı, Gemini API key sızdı veya ani fatura riski oluştuysa ilk müdahale, harcama limiti, quota, proxy ve LLMTR gateway kontrollerini uygulayın.

Google API key sızıntısı, Gemini harcama limiti, quota, proxy ve LLMTR gateway kontrollerini gösteren güvenlik müdahale diyagramı.

İlk 15 dakikada yapılacaklar

Google API key çalındıysa ilk hedef yalnızca anahtarı silmek değildir. Aynı anda Gemini, Vertex AI, Maps ve projede açık olan diğer API yüzeylerinin kötüye kullanım ihtimali kontrol edilmelidir.

2026'da bildirilen vakalar, bazı silme ve faturalandırma sinyallerinin anlık çalışmayabileceğini gösterdi. Bu yüzden incident response akışı, key silme, API kapatma, kullanım kontrolü ve ödeme riskini aynı anda ele almalıdır.

  • Anahtarı rotate edin ve eski anahtarı iptal edin.
  • Generative Language API, Vertex AI ve gerekmeyen Google API'lerini geçici kapatın.
  • Credentials ekranında API restrictions ve application restrictions ekleyin.
  • Billing, quota ve usage ekranlarında son 24 saatlik spike kontrolü yapın.
  • Public repo, frontend bundle, mobil APK/IPA ve deploy loglarında `AIza` kalıbını arayın.

Budget alert neden yeterli değil?

Google Cloud budget alert, harcama oluştuğunda veya tahmin eşiği aşıldığında uyarı üretir; tek başına gerçek bir hard cap gibi davranmaz. Kullanım verisi gecikirse fatura, uyarıdan önce büyüyebilir.

Gemini API tarafında proje harcama limitleri ve billing tier cap kontrolleri daha iyi bir savunma katmanı sağlar; yine de resmi dokümantasyon billing sinyallerinde gecikme ve overage ihtimalini açıkça belirtir.

  • Budget alert: bildirim ve operasyon sinyali.
  • Spend cap: proje veya billing account düzeyinde durdurma hedefi.
  • Quota: istek, token veya günlük kullanım eşiği.
  • Gateway limiti: kullanıcı veya API key başına daha erken kesme noktası.

Spend cap, quota ve rate limit farkı

Gemini rate limitleri genellikle proje düzeyinde değerlendirilir. Aynı projede birden fazla API key varsa key sayısını artırmak bağımsız kota veya bağımsız fatura koruması sağlamaz.

Bu ayrım kritik: saldırgan sızan bir key ile yüksek hacimli istek atarsa proje kotası, billing account tier cap veya spend cap devreye girene kadar kullanım yazılabilir. Bu yüzden düşük quota, sıkı API restriction ve ayrı proje tasarımı birlikte düşünülmelidir.

  • Deneme ve üretim projelerini ayırın.
  • Kullanılmayan Google API servislerini kapalı tutun.
  • Server-side kullanımda IP restriction, frontend kullanımda referrer restriction ve her durumda API restriction uygulayın.
  • Yüksek maliyetli görsel, video ve uzun context modelleri için ayrı limit profili tanımlayın.

LLMTR proxy yaklaşımı ne sağlar?

LLM API proxy veya AI gateway kullanımı, provider API key'inin son kullanıcıya, frontend koduna veya mobil uygulama paketine taşınmasını önler. Uygulama kendi LLMTR API key'iyle konuşur; provider credential server-side ortamda kalır.

LLMTR tarafında kullanıcı bazlı kullanım ölçümü ve harcama limiti akışları bulunur. Bu, Google tarafındaki spend cap ve quota kontrollerinin yerine geçmez; onlara ek bir maliyet kesme katmanı sağlar.

  • Provider key frontend veya mobil app içine gömülmez.
  • Her kullanıcı veya entegrasyon için ayrı API key oluşturulabilir.
  • Kullanım metadata'sı, token, gecikme ve tahmini maliyet üzerinden takip edilir.
  • Bir anahtar şüpheli olursa LLMTR key hızlıca iptal edilip blast radius daraltılır.

Kontrol listesi

Kalıcı çözüm tek bir ayar değildir. En güvenli pratik, Google Cloud tarafındaki resmi key restriction ve spend cap ayarlarını, uygulama tarafındaki gateway limiti ve secret yönetimiyle birlikte kullanmaktır.

Canlı sistemlerde haftalık secret taraması, düşük varsayılan harcama limiti, anomali alarmı ve incident runbook'u birlikte tutulmalıdır.

  • GitHub, CI logları, web kaynak kodu ve mobil bundle içinde `AIza` arayın.
  • Google Cloud Credentials ekranında unrestricted key bırakmayın.
  • Gemini API spend cap ve quota değerlerini gerçek beklenen trafiğe yakın tutun.
  • LLMTR API key'leri kullanım senaryosuna göre ayırın.
  • Yüksek riskli model aileleri için ayrı alarm ve daha düşük harcama eşiği kullanın.

Google API key sızıntısında hızlı müdahale

Gemini API key veya Google API key sızıntısı şüphesinde ilk müdahale, maliyet kontrolü ve proxy sertleştirmesini sırayla uygulayın.

  1. Anahtarı rotate edin. Eski Google API key'i iptal edin, yeni anahtarı yalnızca server-side ortam değişkeni veya secret manager içinde kullanın.
  2. API yüzeyini daraltın. Generative Language API, Vertex AI ve diğer gereksiz servisleri kapatın; kalan key'e API ve application restrictions ekleyin.
  3. Harcama ve quota kontrolü yapın. Gemini usage, billing, spend cap ve quota ekranlarında spike var mı kontrol edin; gerekiyorsa projeyi veya billing bağını geçici durdurun.
  4. Proxy ve gateway limitini devreye alın. Provider key'i kullanıcıya göstermeden LLMTR gibi gateway üzerinden API key, rate limit ve harcama limitiyle erişim verin.

Sık sorulan sorular

Google API key silmek saldırıyı hemen durdurur mu?

Silme işlemi gerekli ama tek başına yeterli kabul edilmemelidir. Güncel araştırmalar bazı key revocation sinyallerinde dakikalar süren yayılım gecikmeleri olabileceğini gösterdiği için ilgili API'leri kapatmak, usage ekranını izlemek ve fatura riskini kontrol etmek gerekir.

Gemini API harcama limiti API key bazlı mı çalışır?

Resmi dokümantasyona göre API key'ler proje içindeki credential'lardır ve bağımsız billing ayarı taşımaz. Proje spend cap, quota ve billing account limitleri gateway limitlerinden ayrı tasarlanmalıdır.

LLMTR kullanmak Google tarafındaki limitleri gereksiz kılar mı?

Hayır. LLMTR proxy ve gateway limiti ek bir kontrol katmanıdır. Google Cloud tarafında API restriction, quota, spend cap ve billing alarmı yine yapılandırılmalıdır.

İlgili yazılar