Gizli Bilgi Yönetimi (Secrets Management) Nedir?

Hangi değerler “secret” sayılır?

Basit bir ölçüt işe yarar: bir değeri bilen kişi, normalde yetkisi olmayan bir sisteme erişebiliyor ya da başkası adına işlem yapabiliyorsa o değer gizlidir. Tipik bir web projesinde bunlar şunlardır:

• Veritabanı kullanıcı adı ve parolası, bağlantı dizesi
• Ödeme, kargo, e-posta veya SMS sağlayıcılarının API anahtarları
• OAuth client secret değerleri ve JWT imzalama anahtarları
• TLS özel anahtarları ve SSH anahtarları
• Webhook doğrulamasında kullanılan imza anahtarları

Sitenin adı, varsayılan dil ya da bir özelliğin açık olup olmadığı ise yapılandırmadır, gizli bilgi değildir. İkisini aynı dosyada ve aynı özensizlikle tutmak, sızıntıların en sık başlangıç noktasıdır.

Sızıntılar genellikle nereden olur?

• Koda gömülen anahtarlar: Değer bir kez commit edildiğinde sonraki commit'te silinse bile Git geçmişinde kalır; repository klonlandığı, fork'landığı veya yedeklendiği her yere taşınır.
• Loglar: Hata ayıklamak için gelen isteğin tüm başlıklarını yazdırmak, Authorization başlığını da log sistemine ve oradan erişimi geniş olan izleme araçlarına taşır.
• Yanlış yerdeki dosyalar: .env dosyasının depoya eklenmesi ya da web kök dizininde kalıp tarayıcıdan indirilebilir olması.
• Elden ele paylaşım: Anahtarın sohbet uygulamasında, e-postada veya bir destek kaydında paylaşılması.
• Derleme çıktıları: CI/CD adımlarının ekrana yazdırdığı değerler veya ön yüz paketine yanlışlıkla gömülen sunucu anahtarları.

Kodun dışında tutmak: kötü ve doğru örnek

// Kaçınılması gereken: anahtar kaynak kodun içinde
const client = new PaymentClient("canli-gizli-anahtar-buraya");

// Doğrusu: değer çalışma anında dışarıdan gelir
const client = new PaymentClient(process.env.PAYMENT_SECRET_KEY);

İkinci satır kodu temizler ama sorunu tamamen çözmez; değerin ortama nasıl girdiği hâlâ önemlidir. Ortam değişkenleri yaygın ve pratik bir taşıma yoludur, ancak OWASP'ın uyardığı gibi aynı makinedeki süreçlerce okunabilir ve hata dökümlerine ya da loglara karışabilir. Bu yüzden büyüyen projelerde değerler merkezi bir kasadan alınır.

Merkezi kasa ile çalışmak

Secrets manager veya “vault” olarak anılan araçlar gizli değerleri şifreli olarak saklar, her servise yalnızca kendi ihtiyaç duyduğu değerleri okuma izni verir ve her erişimi kayıt altına alır. Böylece en az yetki ilkesi gizli bilgilere de uygulanmış olur: geliştiricilerin hepsinin canlı ortam parolalarını bilmesi gerekmez.

Daha olgun kurulumlarda uygulama, kalıcı bir parola yerine istek anında üretilen ve kısa süre sonra geçersizleşen geçici kimlik bilgileri (dynamic secrets) kullanır. Sızan bir değerin değeri, ömrüyle sınırlı kalır.

Rotation ve sızıntı sonrası sıra

Anahtarlar planlı olarak belirli aralıklarla yenilenmelidir. Kesinti yaşamamak için geçiş süresince eski ve yeni anahtarın birlikte geçerli olduğu bir düzen kurulur: önce yeni anahtar dağıtılır, tüm servisler ona geçince eskisi iptal edilir. Bir sızıntı fark edildiğinde ise OWASP Secrets Management Cheat Sheet'in önerdiği sıra izlenir:

1. İptal et: Sızan değeri sağlayıcı tarafında hemen geçersiz kıl.
2. Yenile: Yeni değeri üret ve kasaya koy; servislerin yenisini almasını sağla.
3. Temizle: Değeri depo geçmişinden, loglardan ve paylaşıldığı yerlerden kaldır.
4. Etkiyi incele: Erişim kayıtlarından değerin sızdığı süre içinde kullanılıp kullanılmadığına bak.

Sık yapılan hata, yalnızca üçüncü adımı uygulamaktır. Commit'i geçmişten silmek değeri güvenli hâle getirmez; birinin onu çoktan kopyalamış olduğu varsayılmalıdır. Commit öncesi çalışan tarama araçları ve depo tarafındaki secret scanning özellikleri, bu tür sızıntıları kod paylaşılmadan yakalamaya yardımcı olur.