API Anahtarı Sızıntısı: GitHub’a Yanlışlıkla Yüklediyseniz Ne Yapmalısınız?

Kısa yanıt

Bir API anahtarı veya .env dosyasını GitHub’a yanlışlıkla yüklediğinizi fark ettiğinizde ilk işiniz dosyayı silmek değil, anahtarı servis sağlayıcıda derhal iptal edip yenisini üretmek olmalıdır. Commit geçmişi her zaman izlenebilir kaldığı için API anahtarı sızıntısı, dosya kaldırıldıktan sonra da sürer; gerçek çözüm anahtarı değersizleştirmek,

ardından git-filter-repo gibi bir araçla geçmişi temizlemektir..

API anahtarı sızıntısı neden bu kadar ciddi bir sorun?

Git, her commit’i kalıcı olarak saklayan bir sürüm kontrol sistemidir ve bu tasarım, geçmişte eklenmiş bir dosyayı sonradan silmenizi anlamsız kılar. Bir anahtar bir kez commit edildiğinde, dosyayı kaldıran yeni bir commit yazsanız bile eski sürüm depo geçmişinde durur; isteyen herkes git log ya da arşivlenmiş bir commit linkiyle o anahtara ulaşabilir. Public depolarda durum daha da hızlı ilerler, çünkü otomatik tarayıcı botlar dakikalar içinde yeni commit’leri inceleyip tanıdık anahtar formatlarını (AWS, Stripe, OpenAI gibi servislerin anahtar önekleri) arar.

Özel bir depoda çalışmak riski azaltır ama kapatmaz. Depoya erişimi olan her ortak çalışan, bağlı üçüncü taraf entegrasyon, CI/CD servisi ve geçmişte alınmış bir fork, anahtarı okuyabilir. Ekip üyelerinden biri işten ayrıldığında ya da erişim izinleri değiştiğinde, kimin hâlâ o anahtara ulaşabildiğini takip etmek pratikte zorlaşır. Bu yüzden özel depo kullanmak, anahtarı iptal etme zorunluluğunu asla ortadan kaldırmaz.

En sık görülen API anahtarı sızıntısı senaryoları

Senaryo	Tipik neden	İlk adım
.env dosyası .gitignore’a eklenmeden commit edilir	Proje kurulurken gizlilik dosyası unutulur	Anahtarları iptal et, .env’i geçmişten temizle
Örnek koddaki yer tutucu gerçek anahtarla değiştirilir	Hızlı test sırasında geçici anahtar kopyalanır	Test anahtarını da üretim gibi değerlendir
CI/CD betiğine anahtar doğrudan yazılır	Secrets yöneticisi kurulmadan hızlı çözüm aranır	Betikten çıkar, CI sağlayıcının secret deposuna taşı
Açık kaynak katkısı sırasında kişisel yapılandırma eklenir	Fork’ta yerel ayar dosyası git add . ile sürüklenir	Pull request’i geri çek, anahtarı yenile
Ekran görüntüsü veya log çıktısı issue’ya yapıştırılır	Hata ayıklama sırasında ortam değişkenleri görünür hâlde kalır	Issue’yu düzenle, anahtarı iptal et

Tablodaki her senaryonun ortak noktası, anahtarın bir noktada açık metin olarak depoya veya herkese görünür bir platforma ulaşmasıdır. Kaynak ne olursa olsun atılacak ilk adım aynıdır: anahtarı önce güvenilmez kabul edip sonra inceleme yapmak, incelemeyi önce yapıp sonra karar vermekten her zaman daha güvenlidir.

API anahtarı sızıntısı fark edildiğinde hangi adımlar izlenir?

1. Anahtarı hemen iptal edin ve yenileyin

Servis sağlayıcının API anahtarları veya kimlik bilgileri bölümüne girip sızan anahtarı derhal devre dışı bırakmak, atılacak ilk ve en kritik adımdır. Yeni bir anahtar üretip uygulamanızı buna göre güncellemek dakikalar sürer; bu süre, anahtarın kötüye kullanılma penceresini kapatmak için göze alınması gereken küçük bir maliyettir. Çoğu büyük servis sağlayıcı, panelinde anahtarların ne zaman ve hangi IP’den kullanıldığını gösterir; bu kayıtlara bakarak anahtarın gerçekten ele geçirilip geçirilmediğini de anlayabilirsiniz.

2. Kullanım kayıtlarını ve faturalandırmayı kontrol edin

Anahtarı yenilemeden önce veya hemen sonra, servisin kullanım panelinden son saatlerdeki istekleri gözden geçirmek, olası kötüye kullanımı erken yakalamanızı sağlar. Beklenmeyen bir ülkeden gelen istek hacmi, alışılmadık saatlerde yoğunlaşan çağrılar veya ani bir fatura sıçraması, anahtarın sızıntıdan sonra fiilen kullanıldığının işaretidir. Bu durumda servis sağlayıcıya bildirim yapmak ve varsa ilgili hesap güvenliği ekibini bilgilendirmek gerekir.

3. Git geçmişini temizleyin

Dosyayı silen yeni bir commit yazmak, anahtarı eski commit’lerden kaldırmaz; bu yüzden geçmişi fiilen yeniden yazmanız gerekir. GitHub’ın kendi dokümantasyonu, bu işlem için git-filter-repo aracını önerir: araç, belirttiğiniz dosya veya deseni tüm commit geçmişinden kalıcı olarak çıkarır. İşlemin ardından depo zorla (force) güncellenir ve her ekip üyesinin yerel kopyasını yeni geçmişle değiştirmesi gerekir, çünkü her commit’in hash değeri bu işlemden sonra değişir.

4. Ekibi bilgilendirip koordineli şekilde force push yapın

Geçmiş temizliği, kimsenin o anda depoya push yapmadığı bir zaman diliminde planlanmalıdır; aksi hâlde biri eski geçmişe dayanan bir commit gönderdiğinde çakışma ve kafa karışıklığı yaşanır. Ekibe kısa bir bildirim göndermek, herkesin işlemden sonra depoyu yeniden klonlaması veya yerel dalını yeni ana dala sıfırlaması gerektiğini açıkça belirtmek, sürecin sorunsuz geçmesini sağlar.

Dosyayı silmek neden yeterli olmaz?

Git’in temel tasarım felsefesi, hiçbir commit’i sessizce kaybetmemektir; bu özellik normalde büyük bir avantajdır ama sızan bir sırrı yok etmeye çalışırken dezavantaja dönüşür. Yeni bir commit’le dosyayı kaldırdığınızda, depo yalnızca en güncel anlık görüntüde (snapshot) dosyanın artık olmadığını gösterir. Eski commit’e git checkout <eski-hash> ile geri dönen ya da doğrudan commit linkine giden herkes, silinen içeriği hâlâ görebilir. GitHub’ın arama dizini ve bazı üçüncü taraf kod tarama servisleri de geçmiş commit’leri indeksleyebildiğinden, dosya arayüzden kaybolsa bile anahtar başka bir kanaldan erişilebilir kalabilir.

CI/CD hatlarında API anahtarı sızıntısı nasıl önlenir?

Otomasyon betikleri, hız kazanmak için anahtarları doğrudan kod içine veya yapılandırma dosyasına yazma eğilimindedir; bu alışkanlık, kurumsal projelerde görülen API anahtarı sızıntısı olaylarının en sık rastlanan kaynaklarından biridir. GitHub Actions, GitLab CI ve benzeri platformların sunduğu secrets (sır) depoları, anahtarları şifreli biçimde saklar ve yalnızca iş akışı çalışırken ortam değişkeni olarak enjekte eder; bu sayede anahtar hiçbir zaman depo dosyalarına yazılmaz. Pre-commit kancaları da ikinci bir güvenlik katmanı sağlar: git-secrets veya benzeri bir araç, bilinen anahtar desenlerini içeren bir commit’i tamamlanmadan önce durdurur ve geliştiriciyi uyarır.

GitHub’ın secret scanning özelliği de bu süreci tamamlar. Public depolarda varsayılan olarak etkin olan bu sistem, tanınan servis sağlayıcılarının anahtar formatlarını otomatik tarar; bir eşleşme bulunduğunda hem depo sahibine hem de genellikle ilgili servis sağlayıcıya bildirim gönderilir. Özel depolarda özelliği GitHub Advanced Security üzerinden açmak, kurumsal projelerde ek bir güvence katmanı oluşturur; yine de bu taramayı tek savunma hattı olarak görmemek gerekir, çünkü özel desenler veya az bilinen servis anahtarları her zaman tanınmaz.

Ekip içinde bu riski kalıcı olarak azaltmanın yolları

Sızıntıyı önlemenin en sağlam yöntemi, anahtarları koddan tamamen ayırmaktır. .env dosyasını proje açılır açılmaz .gitignore’a eklemek, ilk commit’ten önce atılması gereken bir adımdır; dosya hiçbir zaman depoya girmediyse geçmişten temizlenecek bir şey de olmaz. Yer tutucu değerler içeren bir .env.example dosyası tutmak, ekip arkadaşlarının hangi ortam değişkenlerine ihtiyaç olduğunu görmesini sağlarken gerçek anahtarları dışarıda bırakır.

Düzenli anahtar yenileme takvimi oluşturmak, bir API anahtarı sızıntısı fark edilmese bile riski sınırlı tutar; üç veya altı ayda bir anahtarların döndürülmesi, eski ve unutulmuş bir sızıntının etkisini zamanla sıfırlar. Kod incelemesi sürecine, değişen dosyalar arasında .env veya anahtar deseni olup olmadığını kontrol eden bir adım eklemek de ekip kültürünün parçası hâline gelmelidir. Yazılım projelerinizde bu tür güvenlik disiplinini baştan kurmak isterseniz, özel yazılım geliştirme hizmetimiz kapsamında kod inceleme süreçlerini ve CI/CD güvenlik kontrollerini projenize göre tasarlıyoruz.

Sık yapılan hatalar

Anahtarı yenilemeden önce sadece dosyayı silip işlemi kapatmak, en yaygın ve en tehlikeli hatadır; eski anahtar commit geçmişinde durduğu sürece risk sürer. Force push’u ekibe haber vermeden yapmak da ayrı bir sorun yaratır, çünkü diğer geliştiricilerin yerel kopyaları eski geçmişle çakışır ve karışık bir kurtarma sürecine girilir. Bir diğer sık görülen yanılgı, özel depoda çalıştığı için API anahtarı sızıntısı riskinin önemsiz olduğunu düşünmektir; oysa depoya erişimi olan herkes ve bağlı her entegrasyon potansiyel bir sızıntı noktasıdır. Son olarak, anahtarı yenileyip geçmişi temizledikten sonra kullanım kayıtlarını kontrol etmeyi atlamak, sızıntının gerçekten kötüye kullanılıp kullanılmadığını öğrenme şansını kaçırır.

Kontrol listesi

Sızıntıyı fark ettiğiniz anda sırayla şu soruları kendinize sorarak ilerleyin: anahtar iptal edilip yenisi üretildi mi, servisin kullanım kayıtlarında olağandışı bir hareket var mı, git geçmişi git-filter-repo ile temizlendi mi ve son olarak ekip force push sonrası depoyu yeniden klonladı mı. Bu dört soruyu sırayla yanıtlayabiliyorsanız, API anahtarı sızıntısı olayını teknik açıdan kapatmışsınız demektir; geriye kalan tek iş, aynı hatanın tekrarını önleyecek .gitignore ve secrets yönetimi düzenini kalıcı hâle getirmektir.

Sonraki adım

API anahtarı sızıntısı, fark edildiği anda doğru sırayla hareket edildiğinde dakikalar içinde kontrol altına alınabilecek bir olaydır; asıl hata, dosyayı silip sorunu kapanmış saymaktır. Projelerinizde secrets yönetimi, CI/CD güvenliği ve kod inceleme süreçlerini profesyonel bir disipline oturtmak isterseniz grup şirketimiz Web Tasarım Ofisi teknik altyapı danışmanlığı sağlıyor.

Yazılım projelerinizin güvenlik ve dağıtım süreçlerini uçtan uca kurmak için özel yazılım hizmetimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Git geçmişiyle ilgili başka bir çakışma yaşıyorsanız git merge conflict nasıl çözülür rehberimize, bağlantı/yetki hatası alıyorsanız git permission denied publickey hatası rehberimize göz atabilirsiniz.

Kaynaklar

• GitHub Docs, Removing sensitive data from a repository, sızan bir sırrı geçmişten temizlemek için önerilen resmî adımlar