Sırların Yönetimi: .env Dosyasından Sır Kasasına Geçiş

Sır yönetimi, çoğu projede tek bir cümleyle özetlenir: ".env dosyasını depoya koymuyoruz". Bu doğru ve gerekli bir kuraldır, ancak sır yönetiminin tamamı değil, yalnızca ilk adımıdır. Asıl sorular şunlardır: bu dosyanın kaç kopyası var, kimlerde duruyor, en son ne zaman değişti ve sızdığında ne kadar sürede iptal edilebilir?

.env dosyası neyi çözer, neyi çözmez?

Ortam değişkenleri, yapılandırmayı koddan ayırır ve aynı kod tabanının farklı ortamlarda çalışmasını sağlar. Bu iyi bir pratiktir. Ancak dosya tabanlı yaklaşımın çözemediği dört şey vardır:

• Dağıtım: Dosya sunucuya nasıl gidiyor? Genellikle biri elle kopyalar; bu, en az bir kopyanın o kişinin bilgisayarında kalması demektir.
• Erişim denetimi: Sunucuya erişimi olan herkes tüm sırları görebilir. Kim ne zaman okudu, kaydı yoktur.
• Rotasyon: Bir anahtarı değiştirmek, tüm sunuculardaki dosyaları elle güncellemeyi gerektirir. Bu zahmet, pratikte anahtarların hiç değişmemesine yol açar.
• İptal: Sır sızdığında hangi sistemlerin etkilendiğini ve nereleri güncellemeniz gerektiğini bilmiyorsanız, müdahale saatler sürer.

Sızıntı gerçekte nasıl oluyor?

Sırlar genellikle dramatik bir saldırıyla değil, sıradan yollarla dışarı çıkar.

Depoya bir kez girmiş olması. Dosya sonradan silinse bile sürüm geçmişinde durur. "Sildik" demek yeterli değildir; geçmişten temizlenmediği sürece erişilebilir kalır ve bu durumda anahtar mutlaka değiştirilmelidir.

Günlük kayıtları. Hata ayıklama sırasında tüm yapılandırmayı veya istek başlıklarını loglamak, sırları günlük sistemine kopyalar — üstelik oraya erişimi olan kişi listesi genellikle daha geniştir. Üretimde log yazımızdaki kurallar bu riski doğrudan ele alıyor.

Web'den erişilebilir konum. Yapılandırma dosyasının web kök dizininde durması, tek bir yanlış sunucu kuralıyla dosyanın tarayıcıdan okunabilmesi anlamına gelir. Bu, sanıldığından çok daha sık karşılaşılan bir durumdur ve web uygulama güvenliği yazımızda değindiğimiz temel yapılandırma hatalarındandır.

Yedekler ve durum dosyaları. Veritabanı yedekleri ve altyapı durum dosyaları sırları içerebilir; asıl dosya korunurken kopyaları korunmayabilir.

Sır kasası ne getiriyor?

Merkezi bir sır yönetimi servisi (bulut sağlayıcıların sır servisleri veya kendi kurduğunuz bir kasa) dört somut kazanç sağlar: sırlar şifreli olarak tek yerde durur, erişim kimlik bazlı verilir, her okuma kayda geçer ve rotasyon merkezî olarak yapılabilir.

En değerli özellik, sıklıkla göz ardı edilen denetim kaydıdır — aynı ilkenin iş verisi tarafındaki karşılığını denetim izi yazımızda ele alıyoruz: bir olay yaşandığında "bu anahtarı en son kim, ne zaman okudu?" sorusunun cevabı olur. İkinci değerli özellik ise kısa ömürlü kimlik bilgileridir — kalıcı bir parola yerine dakikalar içinde geçersizleşen bir belirteç kullanmak, sızıntının etkisini kökten küçültür.

Kademeli geçiş planı

Tüm sistemi bir anda kasaya taşımak gerekmez; sıralı bir yol daha güvenlidir:

1. Envanter çıkarın. Hangi sır nerede kullanılıyor, kimde kopyası var? Bu liste genellikle beklenenden uzun çıkar.
2. Geçmişi tarayın. Depo geçmişinde sır arayan bir denetim çalıştırın; bulunanları not edin.
3. Sızmış olabilecek her şeyi değiştirin. "Muhtemelen kimse görmedi" bir güvenlik stratejisi değildir.
4. En kritik sırları taşıyın. Ödeme, e-posta ve veritabanı kimlik bilgileri ilk sıradadır.
5. Depo taramasını otomatikleştirin. Yeni bir sırrın depoya girmesini engelleyen bir kontrol, dağıtım hattına eklenmelidir — bu, pipeline güvenliği yazımızda ele aldığımız kontrollerin en yüksek getirilisidir.
6. Rotasyon takvimi koyun. Yılda en az bir kez, personel değişikliğinde ise derhal.

Ortam ayrımı ve en az yetki

Test ve üretim sırlarının aynı olması, sık rastlanan ve maliyeti yüksek bir kısayoldur: geliştirme ortamındaki bir hata, üretim verisine dokunabilir hâle gelir. Ortamlar tamamen ayrı kimlik bilgileri kullanmalı ve her bileşene yalnızca ihtiyaç duyduğu yetki verilmelidir. Bir raporlama servisinin yazma yetkisi olmamalıdır — bu, sıfır güven mimarisi yazımızdaki en az yetki ilkesinin somut uygulamasıdır. Genel güvenlik kontrol listeleri için OWASP kaynakları başvurulabilir.

Sonuç

Sır yönetimi, dosyayı depodan uzak tutmakla başlar ama orada bitmez: asıl mesele kaç kopyanın olduğunu bilmek, erişimi kayıt altına almak, düzenli olarak değiştirmek ve sızıntı anında hızla iptal edebilmektir. Merkezi bir kasa bu dördünü tek seferde çözer; geçiş ise kademeli yapılabilir. Bugün yapabileceğiniz en değerli iş şudur: en kritik üç sırrınızın en son ne zaman değiştirildiğini öğrenin. Cevabı bilmiyorsanız, rotasyon takviminizin ilk maddesi de bulunmuş demektir.