API anahtarı sızdığında hangi sırayla işlem yapılır?

API anahtarının sızdığını düşündüğünüzde ilk olarak anahtarı kullanan servisin erişimini durdurun veya anahtarı iptal edin; ardından yeni bir anahtar üretip uygulamaları bu anahtara geçirerek eski anahtarı tamamen geçersiz kılın. Sonrasında kullanım kayıtlarını inceleyin, yetkileri daraltın ve sızıntının tekrarını önleyecek düzeltmeleri yapın. Anahtarı yalnızca koddan silmek yeterli değildir; saldırgan daha önce kopyaladıysa çalışmaya devam edebilir.

İşlem sırası neden önemlidir?​

Bu rehber, yetki sağlayan gizli API kimlik bilgisi içindir. Her public API anahtarı bir sır değildir; istemciye dağıtılması tasarlanan tanımlayıcıların kısıt ve kötüye kullanım modeli farklıdır. Sızıntı fark edildiğinde önce log toplamak için beklemek, saldırganın erişimini sürdürmesine neden olabilir. Buna karşılık yalnızca anahtarı iptal edip yeni anahtarı dağıtmak da olayın kapsamını anlamadan sistemi normale döndürür. En güvenli yaklaşım erişimi hızla kesmek, kanıtları korumak, kontrollü biçimde yeni kimlik bilgisine geçmek ve ardından incelemeyi tamamlamaktır.

Uygulanabilir işlem adımları​

1. Sızıntıyı doğrulayın ve kapsamı belirleyin. Anahtarın hangi servis, proje, ortam ve uygulamayla ilişkili olduğunu saptayın. Depo geçmişi, hata kayıtları, CI/CD değişkenleri, sunucu yapılandırmaları ve istemci kodunu kontrol edin. Anahtarın gerçek bir üretim kimliği olduğunu düşünüyorsanız doğrulama tamamlanana kadar sızmış kabul edin.
2. Anahtarı hemen iptal edin veya devre dışı bırakın. Sağlayıcının yönetim panelinden ya da API üzerinden mevcut anahtarı geçersiz kılın. Bu işlem mevcut istekleri durdurabilir; üretim trafiği etkileniyorsa önce erişimi geçici olarak kısıtlayın, fakat iptali gereksiz yere ertelemeyin. İptal işleminin başarıyla tamamlandığını sağlayıcının durum ekranı veya hata yanıtıyla doğrulayın.
3. Etkiyi ve kötüye kullanım belirtilerini inceleyin. Kimlik, zaman aralığı, kaynak IP, istek türü, oluşturulan kaynaklar, veri erişimi ve harcama kayıtlarını kontrol edin. Yetkisiz işlem görürseniz ilgili kaynakları durdurun, silme işlemlerini kanıtları koruduktan sonra yapın ve gerekiyorsa hizmet sağlayıcının olay bildirim kanalına başvurun.
4. Yeni ve ayrı bir anahtar üretin. Eski sızmış değeri yeniden kullanmayın; doğru servis ve ortam için oluşturun. Sadece gereken API işlemlerine, kaynaklara ve ağ konumlarına izin verin. Mümkünse üretim, test ve yerel geliştirme için ayrı kimlik bilgileri kullanın.
5. Yeni anahtarı güvenli biçimde dağıtın. Anahtarı kaynak koduna, istemci tarafı JavaScript'e, ekran görüntüsüne veya düz metin yapılandırmasına koymayın. Sunucu tarafı gizli değişken, secrets yöneticisi veya CI/CD gizli değişkeni kullanın. Uygulamayı yeniden başlatın ya da yeni yapılandırmanın okunmasını sağlayın ve başarılı bir yetkili isteği kontrollü biçimde test edin.
6. Eski anahtarı her yerde temizleyin. Dosyalar, depo geçmişi, derleme çıktıları, imajlar ve kayıtların erişimini inceleyin. Kanıtları, gerekli logları ve zorunlu yedekleri körlemesine silmeyin; güvenli erişim/saklama ve dar kapsamlı giderme planı uygulayın. Depodan silmek geçmiş commit'lerdeki değeri ortadan kaldırmaz; anahtarın iptal edilmesi bu nedenle zorunludur. Temizlikten sonra tarama aracını yeniden çalıştırın.
7. Kısıtları ve izlemeyi güçlendirin. En az yetki, alan adı veya IP kısıtı, kullanım kotası, süreli kimlik bilgisi ve uyarı mekanizmaları uygulanabiliyorsa etkinleştirin. Yeni anahtarın çalıştığını doğruladıktan sonra olağandışı kullanım uyarılarını bir süre yakından izleyin.
8. Olayı kaydedin ve kök nedeni düzeltin. Sızıntının kaynağını, etkilenen sistemleri, iptal ve yenileme zamanlarını, gözlenen işlemleri ve alınan önlemleri yazın. Anahtarın neden düz metin olarak bulunabildiğini düzeltmeden olayı kapatmayın.

Somut örnek: depo commit'inde üretim anahtarı​

Bir geliştirici üretim API anahtarını özel olması gereken bir yapılandırma dosyasıyla birlikte uzak depoya gönderirse, dosyayı silip yeni commit göndermek yeterli değildir. İzlenecek doğru yol; anahtarı sağlayıcı panelinden iptal etmek, kullanım kayıtlarını incelemek, yeni anahtar üretmek, uygulamayı gizli değişken üzerinden yeni değeri kullanacak şekilde dağıtmak ve eski değerin depo geçmişinde bulunabildiğini kabul ederek erişimi kalıcı olarak kapatmaktır. Depo herkese açıksa veya kopyalanmış olma ihtimali varsa, yalnızca erişim ayarını sonradan değiştirmek de çözüm değildir.

Aşağıdaki karar özeti, ilk müdahalede hangi eylemin öne alınacağını gösterir:


Bu tablo müdahale sırasını değiştirmenin gerekçesini de gösterir: aktif kötüye kullanım belirtisi varsa inceleme sürerken erişimi açık bırakmayın. Ancak iptal sonrasında logların, olay zaman çizelgesinin ve ilgili kaynakların korunmasını sağlayın.

Sık yapılan hatalar​

Anahtarı yalnızca koddan silmek: Daha önce kopyalanmış değer geçerliliğini korur. İptal veya rotasyon yapılmadan risk bitmez.

Yeni anahtarı da aynı yere koymak: Sorun sızıntının kendisi değil, saklama yöntemiyse olay tekrarlanır. Yeni gizli değişkeni güvenli bir depolama mekanizmasından okutun.

Loglarda anahtarı ararken yeniden ifşa etmek: Arama sonuçlarını herkese açık ticket'lara veya sohbet kanallarına yapıştırmayın. Hassas değerleri maskeleyin.

İncelemeyi tamamen atlamak: Anahtar iptal edilmiş olsa bile hangi verilerin okunduğu, hangi işlemlerin yapıldığı ve başka kimlik bilgilerinin etkilenip etkilenmediği belirsiz kalır.

Sık sorulan sorular​

Secret scanning uyarısı kapanınca anahtar da iptal olur mu?​

Uyarıyı kapatmak veya dosyayı silmek sağlayıcıdaki kimlik bilgisini otomatik iptal etmiş sayılmaz. Bazı sağlayıcılar kendi otomatik korumasını uygular; gerçek anahtar durumunu ilgili sağlayıcıdan doğrulayın. Kapalı uyarı ile geçersiz anahtar aynı kayıt değildir.

Yeni anahtar çalışırken eski oturumlar da sonlanır mı?​

Her zaman değil. Anahtarın ürettiği oturum, token veya yetkilendirdiği başka kaynak ayrı yaşam süresine sahip olabilir. Sağlayıcının kimlik zincirini ve iptal etkisini inceleyin. Sadece yeni bir anahtar oluşturmak eski anahtarın ve ondan türeyen erişimin kapandığını kanıtlamaz.