Secrets Yönetimi ve Kimlik Bilgisi Sızıntısının Gerçek Maliyeti

Secret Sızıntısı Çoğunlukla Sistemik Bir Sorun, Tek Bir Hata Değil

Ekipler bazen secret ifşasını tek bir başarısızlık noktası olarak okuyor: bir anahtar yanlış dosyaya kopyalandı ya da yanlışlıkla repoya commit edildi. Bu yaşanıyor; ancak daha ciddi problem genellikle sistemik. Kurumlar fazla sayıda secret üretiyor, bunları fazla sayıda yere kopyalıyor ve gereğinden çok daha uzun süre geçerli bırakıyor. Sızan herhangi bir kimlik bilgisi bu yüzden daha derin bir erişim modeli başarısızlığının yüzey tezahürü.

Secret Sprawl Gerçekte Neye Benziyor?

Secret sprawl yalnızca Git geçmişi problemi değil. Şunları kapsıyor:

deploy'lar arasında kalan, zayıf yaşam döngüsü yönetimine sahip environment variable'lar.

pipeline'ın gerçekte ihtiyaç duyduğundan daha geniş biçimde CI/CD pipeline'larına dağıtılmış kimlik bilgileri.

bazen geliştiricinin aktif farkındalığı olmaksızın geliştirici iş istasyonlarında yaşayan uzun ömürlü erişim token'ları.

destek script'lerinde, konfigürasyon yedeklerinde ve log toplama artifakt'larında unutulan token'lar.

Secret'ın her ek kopyası, gelecekteki bir sızıntının blast radius'unu genişletiyor. Kilit soru yalnızca "bu secret nereye gitti?" değil, "kaç kopyası var ve bunlardan herhangi birini önemli bir şeyi bozmadan iptal edebilir miyiz?"

Uzun Ömürlü Kimlik Bilgileri Neden Orantısız Risk Taşıyor?

Aylarca veya yıllarca geçerli kalan bir secret, kısa süreli düşük olasılıklı bir ifşa olayını kalıcı yüksek olasılıklı bir risk penceresine dönüştürüyor. Kısa ömürlü kimlik bilgileri ve dar izin kapsamı, sızıntı gerçekleşse bile etkisini dramatik biçimde düşürüyor. Dört saatte sona eren ve tek bir kaynağa okuma erişimi veren bir API anahtarı ele geçiren saldırganın hareket alanı, süresiz geçerli ve geniş yönetici erişimi veren bir anahtara sahip saldırgana kıyasla çok daha kısıtlı.

Olgun Bir Secrets Disiplini Neye Benziyor?

Olgun secret yönetim programlarının ortak özellikleri var:

Merkezi depolama: konfigürasyon dosyaları, environment variable'lar ve kaynak repolar arasına dağılmak yerine özel bir secret yöneticisinde (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault veya muadili) saklanan secret'lar.

Kısa rotasyon döngüleri: sızan bir secret başlangıçta tespit edilmemiş olsa bile kısa bir geçerlilik penceresine sahip olacak şekilde yeterince sık döndürülen kimlik bilgileri.

Varsayılan olarak en az yetki: spesifik kullanım senaryosu için tam olarak ihtiyaç duyulan izinlere — daha fazlasına değil — sahip her kimlik bilgisi.

Otomatik tespit: yanlışlıkla commit edilen secret'ları taramak için repolar, CI/CD pipeline'ları ve artifakt depolarını tayan araçlar.

İptal kapasitesi: bağımlı servisleri devre dışı bırakmadan herhangi bir kimlik bilgisini anında iptal edebilme.

Son nokta operasyonel açıdan hafife alınıyor. Bir kimlik bilgisini iptal etmek üretim değişiklik penceresi gerektiriyorsa, bu kimlik bilgisi makul hiçbir programa göre döndürülmüyor.

Kimlik Bilgisi Sınıflandırma Tablosu: Risk ve Rotasyon

Tüm kimlik bilgileri eşit risk taşımaz. Hepsini aynı şekilde ele almak ya aşırı rotasyona (operasyonel sürtünme) ya da yetersiz rotasyona (uzun maruziyet pencereleri) yol açar. Aşağıdaki tablo kimlik bilgisi türlerini risk düzeyine ve önerilen rotasyon süresine göre eşliyor:

| Kimlik Bilgisi Türü | Risk Düzeyi | Önerilen Rotasyon | Notlar |

| --- | --- | --- | --- |

| Bulut sağlayıcı root/yönetici kimlik bilgileri | Kritik | Maks. 90 gün; MFA zorunlu | Asla koda veya CI/CD'ye gömme |

| CI/CD pipeline kimlik bilgileri (deploy anahtarları) | Yüksek | 180 gün veya proje başına | Tek repo/ortama kapsam sınırla |

| Veritabanı bağlantı dizeleri | Yüksek | 90 gün | Secrets manager otomasyonuyla döndür |

| API anahtarları (üçüncü taraf servisler) | Orta-Yüksek | 180 gün | Kapsamı denetle; çoğu gereğinden geniş |

| Geliştirici SSH anahtarları | Orta | Yıllık gözden geçirme + ayrılışta iptal | Paylaşımlı anahtarlar kritik risk |

| Servis-servis token'ları (kısa ömürlü) | Düşük | 1-24 saat (otomatik) | Mümkün olan yerde dinamik kimlik bilgisi kullan |

| Uzun ömürlü kişisel erişim token'ları | Yüksek | Maks. 90 gün; kısa ömürlüyü tercih et | Secret sprawl'ın en yaygın kaynağı |

Tespit Sinyalleri: Kimlik Bilgisi Sızıntısı Günlüklerde Nasıl Görünür?

Kimlik bilgisi sızıntısı gerçekleştiğinde nadiren dramatik bir olay gibi görünür. Bunlar, bir kimlik bilgisinin çalınmış ve kullanılmış olabileceğine işaret eden günlük sinyalleri:

Beklenmedik coğrafya veya ASN'den kimlik doğrulama — normalde veri merkezi IP aralığından kimlik doğrulayan bir servis hesabı aniden bulut sağlayıcısının çıkış IP'sinden görünüyor.

Normal mesai saatleri dışında API çağrıları — tahmin edilebilir bir programda API çağrısı yapan otomatik kimlik bilgileri aniden 03:00 UTC'de etkinlik gösteriyor.

Kimlik doğrulamanın hemen ardından yetki yükseltme — yeni doğrulanan oturum hemen IAM rollerini listelemeye, depolama bucket'larını sıralamaya veya secret'ları sorgulamaya çalışıyor.

Hassas kaynaklarda yüksek hacimli okuma işlemleri — normalde bir veritabanı kaydı okuyan kimlik bilgisi tüm tabloları taramaya başlıyor.

Kimlik doğrulama başarısızlıklarının ardından farklı IP'den başarı — credential stuffing veya ilk başarısızlığın ardından çalınan kimlik bilgisi kullanımına işaret ediyor.

Bu sinyallerin hiçbiri tek başına sızıntıyı doğrulamıyor. Birlikte, kimlik bilgisinin normal davranış temeliyle ilişkilendirildiğinde, derhal araştırma gerektiren bir erişim kalıbı tanımlıyorlar.

Secret'ın Arkasındaki Erişim Modeli

Kimlik bilgisi hijyeni, daha geniş bir erişim modeli sorusunun tezahürü: hangi kimlikler — insan, servis veya makine — hangi kaynaklara, hangi koşullar altında ve ne kadar süreliğine erişmeli? Secret yönetimi bir erişim yönetişimi sorunu yerine depolama sorunu olarak ele alındığında, programlar vault uygulamasına odaklanırken temeldeki uzun ömürlü, geniş kapsamlı kimlik bilgisi yayılmasını büyük ölçüde değişmeden bırakıyor.

Daha kullanışlı çerçeveleme şu: her kullanım senaryosu için minimum uygun kimlik bilgisi ne ve maksimum kabul edilebilir geçerlilik süresi ne kadar? Bu soruları yanıtlamak, herhangi bir vault ürün seçiminden daha iyi bir secrets mimarisi ortaya koyuyor.

MyVuln Yaklaşımı

MyVuln, kimlik bağlamı, secret ifşa göstergeleri ve maruz servis durumunu aynı yerde okuyabildiğinde değer üretiyor. İzole haldeki düşük değerli bir kimlik bilgisi sızıntısı bulgusu ev düzeni sorunu gibi görünüyor. Kimlik bilgisinin erişim yetkisi verdiği dışarıdan erişilebilir servislerle ilişkilendirilen aynı bulgu, derhal remediation önceliğini hak eden doğrulanmış bir saldırı yoluna dönüşüyor. Dahası, MyVuln'un maruziyet ilişkilendirme görünümü kimlik bilgisi ile ilgili CVE'leri — örneğin tedarikçi yazılımındaki hardcoded kimlik bilgisi zafiyetleri — doğrudan etkilenen servisin internetten erişilebilir olup olmadığıyla bağlıyor; tarama bulgusu önceliklendirilmiş remediation biletine dönüşüyor.