Saldırganlar repos'lara sızan cloud kimlik bilgilerini nasıl buluyor ve bunları durştan savunmalar

Dev.to'da yayımlanan bir rehber, bir cloud ihlaline giden en yaygın yollardan birini ele alıyor: bir geliştirici bir API anahtarını config dosyasına yapıştırıyor, commit'liyor ve push'luyor; otomatik araçlar da onu aynı hızda buluyor. Yapay zekâ yardımcısıyla oluşturulduğunu açıklayan yazı, saldırganların neye hedef olduğunu, bunu nasıl aradığını ve hangi karşı önlemlerin riski gerçekten azalttığını ele alıyor.

Sızdırılmış bir secret ne demek

Yazıya göre repos'larda ortaya çıkan hassas veriler birkaç kategoriye ayrılıyor: AWS access key ID'leri ve secret key'ler, GCP service account JSON dosyaları ve Azure storage account anahtarları; Stripe, Twilio, OpenAI ve SendGrid gibi üçüncü taraf servislerin API token'ları; SSH private key'ler, imza sertifikaları ve diğer .pem dosyaları; ile kullanıcı adı ve şifre gömülü veritabanı bağlantı dizileri. Kimlik bilgisi olmayan yapılandırma verileri bile — dahili endpoint'ler, bucket isimleri, mimari detayları — önem taşıyor; çünkü saldırganın içerideyken yolunu bulmasına yardımcı oluyorlar.

Saldırganların onları avladığı üç yol

Keşif büyük ölçüde otomatikleşmiş durumda, diye açıklıyor yazı, ve üç ana kanaldan gerçekleşiyor:

• Gitleaks, TruffleHog ve GitHub'ın yerleşik secret scanning'i gibi pattern eşleştirmeli tarayıcılar, herkese açık repos'ları tarayıp bilinen formatlarla eşleşen dizgileri işaretliyor — AWS anahtar biçimleri, Slack token'ları, private key başlıkları ve yüzlerce başka imza.
• GitHub dorking, dosya adlarına ve dizgilere yönelik hedefli arama sorguları kullanıyor; örneğin filename:.env, AWS_SECRET_ACCESS_KEY veya extension:pem ile bir private key işaretçisinin birleşimi.
• Toplu taramaya adanmış servisler, herkese açık commit aktivitesini günün her saati izliyor ve bulduklarını yayımlıyor ya da satıyor. Yazı, sızan bir anahtarın push'tan dakikalar içinde keşfedilebileceği konusunda uyarıyor.

Sızan bir kimlik bilgisinin değeri

Yazıya göre ortaya çıkmış bir anahtar teorik bir kaygı değil. Ele geçirilmiş bir veritabanı kimlik bilgisi tüm bir veri setini çekmek için kullanılabilir. Çalınan cloud anahtarları, kurbanın hesabına faturalanan compute iş yükleri başlatmak için rutin olarak kullanılıyor. CI veya build sunucusu kimlik bilgileri, dahili sistemlerin daha derinlerine ulaşmak için bir basamak olabilir; bir uygulamanın API token'ı ise saldırganın o servisi taklit etmesini sağlar.

Önlem, pipeline sırasıyla

Önerilen savunmalar geliştirme iş akışına karşılık geliyor:

• Asla secret'ları hardcode etmeyin; onları runtime'da ortam değişkenlerinden veya bir secrets manager'dan yükleyin. Yazının örneği, bir değeri dosyaya gömmek yerine tek bir CLI çağrısıyla AWS Secrets Manager'dan alıyor.

• Bir pre-commit hook kurun — yazı Gitleaks'ın protect --staged modunu öneriyor — böylece secret'lar remote'a hiç ulaşmadan yakalanır.

• Her push'ta CI'da secret taraması çalıştırın ve eşleşme yaratan merge'leri engelleyin.

• Production kimlik bilgilerini AWS Secrets Manager, HashiCorp Vault veya Azure Key Vault gibi bir vault'ta tutun ve onları build artefaktlarına gömmek yerine runtime'da enjekte edin.

Sızıntı yine de olduğunda

İzleyen bir commit'te ilgili dosyayı silmek yeterli değil, çünkü secret Git geçmişinde varlığını sürdürüyor. Yazıya göre doğru sıra şöyle: önce kimlik bilgisini iptal et (revoke), sonra yenile (rotate), ancak ondan sonra repo geçmişini git filter-repo ve bir force-push ile temizle. Yazı bunu üç adımlık bir runbook'a indirgiyor: iptal et, yenile, temizle.

Ayrıca kısa bir kontrol listesi sunuyor: kaynak kodda veya infrastructure-as-code şablonlarında secret olmaması, .env ve anahtar dosyalarının .gitignore'da listelenmesi, pre-commit taramasının etkin olması, CI'nın tespit edilen secret'lar üzerine merge'leri engellemesi, production secret'larının bir vault'tan sağlanması ve önceden hazırlanmış bir incident runbook'un bulunması.

Neden önemli

Repo'lara sızan secret'lar rahatsız edici bir kesişimde duruyor: hatanın yapılması saniyeler sürüyor, keşif otomatik ve neredeyse anlık, ve sonuçları — çalınan veriler, sahte cloud faturaları, yatay hareket — mühendislik ekibinin üzerine düşüyor. Yazının çerçevelediği gibi, bu, cloud ortamlarının ele geçirilmesinin en yaygın ve en önlenebilir yollarından biri. Önerdiği her kontrol ucuz ve iyi yerleşmiş durumda; bu da hook'ların, CI kapılarının ve bir rotasyon runbook'unun yokluğunu, bir anahtar bir commit'e düştüğünde savunulması zor bir boşluk hâline getiriyor.