Sırları Koddan Çıkarmak: .env, Gizli Anahtar Yönetimi ve Rotasyon

Projelerimizi devraldığımızda ya da güvenlik gözden geçirmesi yaptığımızda en sık karşılaştığımız sorunlardan biri, veritabanı parolasının, ödeme sağlayıcısı anahtarının ya da bir bulut servis kimliğinin kodun içinde durması. Bazen bir .env dosyası yanlışlıkla depoya girmiş, bazen anahtar doğrudan bir sınıfa yazılmış. Bu yazıda sırları kodun dışına çıkarmanın, yönetmenin ve düzenli değiştirmenin pratik yolunu anlatıyoruz.

Sır nedir, nerede durmamalıdır

Parola, API anahtarı, imzalama anahtarı, veritabanı bağlantı bilgisi ve webhook gizli değerleri birer sırdır. Kural basit: sırlar sürüm kontrolüne girmez, günlüğe yazılmaz, hata mesajında görünmez ve istemci uygulamasına gömülmez. Bu listedeki en kritik madde sürüm kontrolü. Çünkü Git geçmişi unutmaz; bir sırrı sonradan silseniz bile eski commit'lerde durmaya devam eder.

Laravel'de .env kullanımının doğru yolu

Laravel'de ortam değerleri .env dosyasında durur ve bu dosya .gitignore içinde olmalıdır. Depoya ise değerleri boş bırakılmış bir .env.example koyarız; yeni geliştirici hangi değişkenlerin gerektiğini buradan görür. Önemli bir ayrıntı daha var: env() çağrısını yalnızca config/ dosyalarında kullanın, uygulama kodunda ise config('services.odeme.anahtar') gibi erişin. Üretimde php artisan config:cache çalıştırıldığında yapılandırma önbelleğe alınır ve config dışındaki env() çağrıları beklenmedik biçimde null dönebilir.

Mobil uygulamada sır saklanmaz

Bu, Flutter projelerinde sık yanlış anlaşılan bir konu. --dart-define ile derleme zamanında değer vermek, anahtarı kaynak koddan ayırır ama uygulamanın içinden çıkarılabilir olmasını engellemez; paketi açan biri değeri bulabilir. Bu yüzden istemciye yalnızca herkese açık olması sorun yaratmayan tanımlayıcıları koyun. Ödeme sağlayıcısı gizli anahtarı, yapay zeka servisi anahtarı gibi değerler her zaman kendi backend'inizde durmalı; uygulama o backend ile konuşmalı, backend de dış servisi çağırmalı.

Depo, hat ve sunucuda koruma katmanları

• Commit öncesi gitleaks gibi bir tarayıcıyı pre-commit kancası olarak çalıştırın.
• Depo platformunuzun secret scanning ve push protection özelliklerini açın.
• CI/CD hattında sırları platformun secrets alanında saklayın; günlüklerde maskelendiğinden emin olun.
• Sunucuda .env dosyasını yalnızca uygulama kullanıcısının okuyabileceği izinle tutun, örneğin chmod 600.
• Ortam başına ayrı anahtar kullanın; geliştirme, test ve canlı ortam aynı anahtarı paylaşmasın.
• Ekip büyüdükçe merkezi bir sır yöneticisine (bulut sağlayıcınızın servisi ya da Vault gibi bir çözüm) geçin.

Sızıntı olduğunda ve düzenli rotasyon

Bir sır depoya girdiyse ilk adım geçmişi temizlemek değil, o sırrı iptal edip yenisini üretmektir. Geçmişi yeniden yazmak sonradan yapılır; çünkü sır bir kez yayılmışsa güvenli sayılamaz. Rotasyonu sızıntıya bırakmamak için düzenli bir takvim de kurun. Sorunsuz rotasyonun püf noktası, eski ve yeni değerin kısa süre birlikte geçerli olabilmesidir: önce yeni anahtarı üretin, sistemi ona geçirin, eskisini bir süre izleyip kullanılmadığından emin olduktan sonra iptal edin. Laravel'de APP_KEY değişimi şifrelenmiş çerezleri ve verileri etkiler; bu yüzden değiştirmeden önce framework'ün önceki anahtarları destekleyen ayarını kontrol edin.

Hepsini bir günde yapmaya çalışmayın. Önce depoda geçmiş dahil sır taraması yapın, bulduklarınızı yenileyin, sonra tarayıcıyı pre-commit hattına ekleyin. Ardından hangi sırrın nerede kullanıldığını bir envanterde toplayın; envanteri olmayan sırrı rotasyona sokmak mümkün değildir. Envanterde her sır için sahibini, kullanıldığı yeri ve son değişim tarihini tutmanız yeterli; basit bir tablo bile ilk sızıntıda saatler kazandırır.

Mevcut projenizde sır yönetimini gözden geçirmek, güvenlik taraması yapmak ya da dağıtım hattınızı bu açıdan sağlamlaştırmak isterseniz iletişim sayfamızdan bize yazın. Uzun yıllardır devraldığımız projelerde gördüğümüz tablo net: sızıntıların çoğu karmaşık saldırılardan değil, depoya yanlışlıkla giren tek bir dosyadan çıkıyor.