.env dosyası ve gizli bilgiler: Şifreleri koddan ayırmanın doğru yolu

Yıllar içinde gördüğüm güvenlik olaylarının şaşırtıcı bir kısmı karmaşık bir saldırıyla değil, herkese açık bir depoda duran bir şifreyle başladı. GitHub'a yüklenen bir config.php, sunucuda unutulmuş bir config.php.bak ya da herkese açık bir .env dosyası...

Bunun önüne geçmenin yolu basit bir ilkedir: Kod ile yapılandırma ayrı yerlerde durur.

Neden ayırmalı?

Twelve-Factor App ilkelerinin en bilinen maddesi şudur: Ortama göre değişen her şey (veritabanı adresi, API anahtarları, e-posta şifresi) koddan ayrı tutulmalı ve ortam değişkenleriyle verilmelidir. Bunun üç faydası vardır:

1. Kod depoya, yedeğe ya da bir başkasına gittiğinde şifreler gitmez.
2. Aynı kod; geliştirme, test ve canlı ortamda, farklı ayarlarla çalışır.
3. Bir şifreyi değiştirmek için kodu değiştirip yeniden yayınlamanız gerekmez.

.env dosyası

Geliştirme ortamında ortam değişkenlerini tek tek tanımlamak zahmetlidir. Bu yüzden çoğu çatı (Laravel, Symfony, Node.js projeleri) bir .env dosyası okur:

DB_HOST=127.0.0.1
DB_NAME=magaza
DB_USER=magaza
DB_PASS=uzun-ve-rastgele-bir-sifre
SMTP_PASS=baska-bir-sifre

Kod bu değerleri dosyadan değil, ortamdan okur:

$pdo = new PDO(
    sprintf('mysql:host=%s;dbname=%s;charset=utf8mb4', getenv('DB_HOST'), getenv('DB_NAME')),
    getenv('DB_USER'),
    getenv('DB_PASS'),
);

Altın kurallar

1. .env asla depoya girmez. İlk commit'ten önce .gitignore dosyasına ekleyin:

.env
.env.*
!.env.example

2. Bunun yerine .env.example depoya girer. Bu dosya hangi değişkenlerin gerektiğini gösterir ama değer içermez:

DB_HOST=127.0.0.1
DB_NAME=
DB_USER=
DB_PASS=

Yeni bir geliştirici projeyi indirdiğinde bu dosyayı kopyalayıp kendi değerlerini girer.

3. .env web kök dizininin dışında durur. public_html/.env yanlış bir yerdir. Web sunucusu yanlış yapılandırılırsa https://site.com/.env adresi dosyayı olduğu gibi indirir. Botlar bu adresi her gün milyonlarca sitede tarar. Dosyayı bir üst dizine koyun ya da en azından web sunucusunda erişimi engelleyin:

# Apache
<Files ".env">
    Require all denied
</Files>

4. Dosya izinleri sıkı olsun. chmod 600 .env. Yalnızca uygulamayı çalıştıran kullanıcı okuyabilmeli.

5. Her ortamın şifresi farklı olsun. Geliştirme bilgisayarınızdaki .env, canlı veritabanının şifresini içermemelidir.

Şifre yanlışlıkla commit edildiyse

İlk refleks genellikle dosyayı silip yeni bir commit atmaktır. Bu yetmez. Şifre geçmişte durmaya devam eder ve depoyu klonlayan herkes onu görebilir. Doğru sıra şudur:

1. Önce şifreyi değiştirin. Veritabanı şifresini, API anahtarını hemen iptal edip yenisini üretin. En önemli adım budur; geri kalanı temizliktir.
2. Erişim kayıtlarına bakın. Anahtar, sızdığı andan itibaren kullanılmış mı?
3. İsterseniz git filter-repo gibi bir araçla geçmişi temizleyin. Ancak depo herkese açıksa, birilerinin onu çoktan kopyalamış olabileceğini varsayın.

GitHub, AWS, Stripe gibi pek çok servis herkese açık depolarda kendi anahtar biçimlerini tarar ve sızan anahtarı otomatik olarak iptal edebilir. Ama buna güvenmeyin; bu tarama sizin veritabanı şifrenizi tanımaz.

Daha büyük projelerde

Ekip büyüdükçe .env dosyalarını elden ele dolaştırmak sorun olmaya başlar. O noktada bir gizli bilgi yöneticisi (secret manager) düşünülmelidir. HashiCorp Vault, bulut sağlayıcılarının kendi servisleri ya da SOPS gibi şifreli dosya araçları; kimin hangi şifreye eriştiğini kayıt altına alır ve şifrelerin düzenli olarak yenilenmesini kolaylaştırır.

Küçük bir proje için ise kural yine aynı: Şifre koda değil, ortama aittir.