LLM API Anahtarı Sızdı: İlk İki Saatte Yapılacaklar

LLM API anahtarı sızdığında ilk on beş dakikada ne yapılır?

API anahtarı, uygulamanızın model sağlayıcısına kendini tanıttığı gizli bir değerdir. Anahtarı ele geçiren kişi sizin hesabınız adına istek gönderir, fatura size kesilir. Anahtarın yetkisine göre yüklenmiş dosyalara ya da toplu iş sonuçlarına da erişebilir. Yeni anahtar üretmek ya da dosyayı depodan silmek eski anahtarı geçersiz kılmaz. İptal, yenileme ve dağıtım ayrı adımlardır.

OWASP Secrets Management Cheat Sheet de olay müdahalesinde ilk adımı aynı biçimde tanımlar: açığa çıkan anahtar derhal iptal edilir, yenisi hızla ve tercihen otomatik bir süreçle devreye alınır. İlk on beş dakikanın iskeleti şöyledir:

1. Sağlayıcı konsolunda anahtarı silin ya da devre dışı bırakın. İptal saatini olay kaydına yazın.
2. Aynı proje ya da çalışma alanında yeni bir anahtar üretin. Yetkisini yalnız gereken uç noktalarla sınırlayın.
3. Yeni anahtarı gizli bilgi kasasına koyun. Sohbet kanalına, bilete ya da e-postaya yazmayın.
4. Uygulamayı yeni anahtarla yeniden dağıtın ve sağlık kontrolüyle doğrulayın.
5. Olay kaydını açın: kim, ne zaman, hangi kanaldan fark etti.

Anahtar herkese açık bir GitHub deposuna düştüyse sağlayıcı sizden önce haberdar olmuş olabilir. OpenAI ve Anthropic anahtarları GitHub'ın gizli bilgi tarama ortaklık programındadır. Anthropic, herkese açık depoda bulunan anahtarı otomatik olarak devre dışı bıraktığını ve hesap sahibine e-posta gönderdiğini belirtir. Bu otomatik koruma özel depoları, sohbet kanallarını ve uygulama paketlerini kapsamaz, bu yüzden iptali hiçbir durumda otomasyona bırakmayın.

Sızıntıyı bildiren kişiyi suçlamayın. Hızlı bildirim, ilk saatlerin en değerli kazanımıdır. Genel olay müdahale çerçevesi için AI olay müdahale playbook'u yazısına bakabilirsiniz.

Kullanım kayıtlarında hangi izlere bakılır?

İptalden sonraki amaç, sızıntı ile iptal arasındaki pencerede anahtarla ne yapıldığını anlamaktır. Sağlayıcının kullanım ve maliyet raporlarını anahtar, proje ya da çalışma alanı bazında süzün. Kayıtların ne kadar geriye gittiğini baştan kontrol edin, çünkü saklama süresi sağlayıcıya ve hesap türüne göre değişir. Raporu olay kaydına ekleyecek biçimde dışa aktarın.

Son satır kritik ayrımdır. Yalnız metin üretimine yetkili bir anahtarın zararı çoğunlukla maliyettir. Dosya yükleme, toplu iş ya da kayıtlı içerik uçlarına erişebilen bir anahtar ise kurum verisine kapı açar.

Harcama limiti ve kota nasıl daraltılır?

Harcama limiti, bir proje ya da çalışma alanının belirli bir dönemde ulaşabileceği en yüksek maliyeti sınırlar. Hız limiti ise dakikalık istek ve token hacmini kısıtlar. Sızıntıdan sonra ikisini geçici olarak düşürmek, yeni anahtar da ele geçirilirse zararı küçültür. Bu sınırlar kalıcı tasarımın parçası da olmalıdır.

Sağlayıcıların ayar adları farklıdır. Anthropic konsolunda her çalışma alanı için aylık harcama limiti, eşik uyarıları ve model bazında dakikalık istek ve token limitleri tanımlanabilir. Çalışma alanı limiti organizasyon limitinin üstüne çıkamaz. Bir anahtar tek bir çalışma alanına bağlanabilir ve yalnız o alanın kaynaklarına erişir. Diğer sağlayıcılarda benzer ayarlar proje düzeyinde bulunur. Kendi panelinizde limitin istekleri gerçekten durduran bir sınır mı, yoksa yalnız uyarı mı olduğunu kontrol edin.

• Proje ya da çalışma alanı bazında aylık bütçe ve uyarı eşiği tanımlayın.
• Kullanılmayan modelleri projenin erişim listesinden çıkarın.
• Anahtarlara yalnız gereken uç noktaları açın.
• Bütçe uyarısını nöbetçinin göreceği bir kanala yönlendirin.

Maliyet saldırılarının OWASP karşılığı ve oran sınırlama reçetesi LLM10 sınırsız tüketim yazısında yer alır.

Depo geçmişini temizlemek neden yetmez?

GitHub'ın hassas veri kaldırma belgesi işe iptal ya da rotasyonla başlamayı önerir ve bunun çoğu durumda yeterli olabileceğini belirtir. Geçmişi yeniden yazmak ayrıca yapılabilir, ama sınırları vardır. Yalnızca geçmişi yeniden yazıp zorla gönderirseniz, hassas veriyi içeren commit'ler başka yerlerde erişilebilir kalabilir.

Belgede sayılan yan etkiler şunlardır:

• Başka kullanıcıların yerel kopyalarından veri silinemez, eski kopyadan yeniden gönderilebilir.
• Commit bir çatalda varsa orada erişilebilir kalır.
• Eski commit'ler, özet değeriyle önbelleğe alınmış görünümlerden açılabilir. Bunlar için GitHub Destek ile iletişime geçilir.
• Açık birleştirme istekleri bozulur, commit özetleri ve imzalar değişir.

GitHub geçmiş temizliği için git-filter-repo aracını önerir. Temizlik sırasında derleme kayıtlarını, hata izleme araçlarını, bilet sistemlerini ve yayımlanmış paket sürümlerini de tarayın. Yayımlanmış bir paket, kalıcı bir kopya olarak dışarıda kalır.

Sızıntının kaynağı nasıl bulunur?

Kaynağı bilmeden yapılan yenileme geçici bir çözümdür, aynı kanal yeni anahtarı da sızdırır. Önce anahtarın en son meşru kullanıldığı yeri, sonra yetkisiz kullanımın ilk görüldüğü zamanı bulun. İki zaman arasındaki aralık, inceleme alanını daraltır.

Sık görülen kaynaklar şunlardır:

• Herkese açık ya da yanlışlıkla açılmış kod depoları
• Depoya eklenmiş ortam dosyaları
• Açık bırakılmış hata ayıklama günlükleri
• Paylaşılan not defterleri ve örnek kod parçaları
• İstemci tarafı JavaScript ya da mobil uygulama paketi
• Yapay zekâ sohbet araçlarına yapıştırılan yapılandırma dosyaları

Mobil paketten çıkan anahtar mimari bir sorundur, çünkü pakete gömülü her değer çıkarılabilir. Bu durum için mobil uygulamaya gömülü LLM anahtarı yazısına bakın. Depo kaynaklı sızıntılarda ise hem geçmişe dönük tarama yapın hem de push protection gibi gönderim anında engelleyen bir kontrol açın. GitHub, OpenAI ve Anthropic anahtar desenleri için push protection desteği sunar.

Kişisel veri etkilendiyse KVKK bildirimi gerekir mi?

Anahtar yalnız metin üretimine yetkiliyse ve uygulama sağlayıcı tarafında içerik saklamıyorsa, kişisel veri ihlali olasılığı düşüktür. Anahtarla yüklenmiş dosyalara, toplu iş sonuçlarına ya da kayıtlı konuşmalara erişilebiliyorsa ve bunlar kişisel veri içeriyorsa değerlendirme zorunludur.

6698 sayılı Kanun'un 12. maddesinin 5. fıkrası, işlenen kişisel verilerin kanuni olmayan yollarla başkalarınca elde edilmesi halinde veri sorumlusunun bunu en kısa sürede ilgilisine ve Kurul'a bildirmesini öngörür. Kurul, 24.01.2019 tarihli ve 2019/10 sayılı kararında "en kısa süre" ifadesini 72 saat olarak yorumlamıştır. Süre, veri sorumlusunun ihlali öğrendiği andan başlar. Bilgilerin tamamı bu sürede toplanamıyorsa bildirim aşamalı yapılabilir. Gecikme olursa gerekçesi bildirime eklenir.

Bu yüzden kullanım kaydı incelemesinin ilk bulgularını veri koruma sorumlusuyla aynı saatlerde paylaşın. Bildirim yapılmasa bile kararı ve gerekçesini yazılı saklayın.

İlk iki saatin zaman çizelgesi nasıl olmalı?

İlk iki saat üç aşamaya bölünür: durdur, anla, düzelt. Süreler olaya göre değişir, sıralama sabit kalır. Aşağıdaki çizelgeyi nöbetçinin elinde hazır duran bir şablon olarak kullanabilirsiniz.

İki saat sonunda iş bitmiş sayılmaz. Ancak anahtar iptal edilmiş, limit daraltılmış, ilgililer bilgilendirilmiş ve KVKK değerlendirmesi başlamış olmalıdır. Sağlayıcı destek birimine yazarken iptal saatini, şüpheli kullanım aralığını ve etkilenen projeyi belirtin. Haksız harcamanın iadesi sağlayıcının politikasına bağlıdır, iade varsaymayın.

Tekrarını önlemek için hangi kontroller kurulmalı?

Kalıcı çözüm üç katmandan oluşur: anahtarın ömrünü kısaltmak, yetkisini daraltmak ve sızıntıyı otomatik fark etmek. Anthropic, anahtarların örneğin 90 günde bir yenilenmesini önerir. OpenAI ise anahtarın tarayıcı ya da mobil uygulama gibi istemci ortamlarına konmamasını, isteklerin kendi arka uç sunucunuzdan geçmesini önerir.

• Anahtarlar kaynak koda değil, gizli bilgi kasasına yazılsın.
• Her uygulama, ortam ve ekip için ayrı anahtar kullanılsın.
• Rotasyon takvimli ve mümkünse otomatik olsun.
• İstemciler sağlayıcıya doğrudan değil, sunucu tarafındaki bir ara katman üzerinden gitsin.
• Her birleştirme isteğinde sır taraması zorunlu olsun.
• Harcama uyarıları nöbetçiye gitsin.
• Sızıntı senaryosu yılda en az bir kez masa başı tatbikatla denensin.

Kurumsal ölçekte anahtar yönetimi, kota ve kayıt tek bir noktada toplanabilir. Bu yaklaşımın mimarisi LLM gateway yazısında anlatılır. Sır taramasını birleştirme politikasına bağlamak için AI üretimi kod için CI güvenlik kapısı yazısındaki kapı tasarımı kullanılabilir.

Sık Sorulan Sorular

Sızan anahtar iptal edilince uygulama durur mu?

Canlı uygulama aynı anahtarı kullanıyorsa durur, çünkü iptal edilen anahtarla gelen istekler reddedilir. Planlı yenilemede önce yeni anahtar dağıtılır, sonra eskisi iptal edilir. Sızıntı kesinse bu sıra tersine döner: önce iptal, sonra dağıtım. Birkaç dakikalık kesinti, kontrolsüz harcamadan ve veri erişiminden neredeyse her zaman daha ucuzdur.

Depodan anahtarı silmek yeterli olur mu?

Olmaz. GitHub belgeleri, geçmişi yeniden yazmanın tek başına yetmediğini açıkça söyler. Çatallarda, yerel kopyalarda ve önbelleğe alınmış görünümlerde eski commit erişilebilir kalabilir. Asıl güvenlik adımı anahtarı sağlayıcı tarafında iptal etmektir. İptal edilmiş bir anahtar geçmişte kalsa bile kimseye erişim kazandırmaz. Geçmiş temizliği bu nedenle iptalden sonra yapılan bir düzenleme işidir.

Anahtar sızıntısı kişisel veri ihlali sayılır mı?

Anahtarla yüklenmiş dosyalara, kayıtlı konuşmalara ya da toplu iş çıktılarına erişilebiliyorsa ve bunlarda kişisel veri varsa ihlal söz konusu olabilir. Kurul'un 2019/10 sayılı kararına göre bildirim, ihlalin öğrenilmesinden itibaren en geç 72 saat içinde yapılır. Değerlendirmeyi veri koruma sorumlusu ve hukuk birimiyle birlikte yapın, kararı gerekçesiyle yazılı saklayın.

Anahtarları ayrı projelere bölmek neden işe yarar?

Her uygulama, ortam ve ekip için ayrı anahtar kullanıldığında bir sızıntının etkisi tek bir alanla sınırlı kalır. İptal ettiğinizde diğer sistemler çalışmaya devam eder. Kullanım raporunda hangi anahtarın ne yaptığı ayrışır, harcama limiti de yalnız o alana uygulanır. Anthropic gibi sağlayıcılar çalışma alanı başına ayrı harcama ve hız limiti tanımlamaya izin verir.

Kaynaklar

• GitHub Docs: Removing sensitive data from a repository
• GitHub Docs: Supported secret scanning patterns
• Anthropic: API key best practices
• Claude Platform Docs: Workspaces
• OWASP: Secrets Management Cheat Sheet
• KVKK: 2019/10 sayılı Kurul Kararına ilişkin veri ihlali bildirimi duyurusu

İlgili Yazılar

• AI Incident Response Playbook LLM Olaylarında Saat-Saat Müdahale
• Mobil Uygulamada API Anahtarı: Gömülü LLM Anahtarı Riski
• Denial-of-Wallet: LLM'lerde Sınırsız Tüketim OWASP LLM10:2025 ve Token Maliyet Saldırıları
• AI Üretimi Kod Güvenliği: CI Hattında Güvenlik Kapısı